From sip-bounces@ietf.org Fri Feb 1 01:52:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06873A68F2; Fri, 1 Feb 2008 01:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1XB-dIe+nk6; Fri, 1 Feb 2008 01:52:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F133A689A; Fri, 1 Feb 2008 01:52:35 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEC33A686F for ; Fri, 1 Feb 2008 01:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95qh74yWqLtb for ; Fri, 1 Feb 2008 01:52:32 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 287A43A689A for ; Fri, 1 Feb 2008 01:52:31 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DCCA7213CC; Fri, 1 Feb 2008 10:54:04 +0100 (CET) X-AuditID: c1b4fb3e-ad5edbb0000007e1-d4-47a2ec3c080e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B7BF02023F; Fri, 1 Feb 2008 10:54:04 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 10:54:04 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Feb 2008 10:54:03 +0100 Message-ID: <2C685FA24AE8004CA8F0DCCC7AF6AD080197DD8F@esealmw109.eemea.ericsson.se> In-Reply-To: <47A093AC.9090507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Delivering request-URI and parameters to UAS via proxy Thread-Index: AchjUoDfAeYPKbbSTsyIGr/C2gnivwAoZ99Q References: <2AF8FF7D89242541B12E7A47F6ECB4BE069C088F@ftrdmel3> <47A093AC.9090507@cisco.com> From: "Hans Erik van Elburg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 01 Feb 2008 09:54:04.0444 (UTC) FILETIME=[610385C0:01C864B8] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, drage@alcatel-lucent.com Subject: Re: [Sip] Delivering request-URI and parameters to UAS via proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > From the point of view of the registrar this seems similar to IMS implici= t registration, = > except that the scale is much larger - there may be *very many* implicit = registrations = > generated by this one explicit registration. For this reason the Wildcarded Public User Identity concept is introduced i= n IMS. This allows efficient implicit registration of ranges of numbers or = sets of sip uri's. Best Regards, /Hans Erik -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] = Sent: Wednesday, January 30, 2008 4:12 PM To: youssef.chadli@orange-ftgroup.com Cc: sip@ietf.org; drage@alcatel-lucent.com Subject: Re: [Sip] Delivering request-URI and parameters to UAS via proxy youssef.chadli@orange-ftgroup.com wrote: > I think there is a misunderstanding on these use cases: Quite possible. > - The intermediate entity in the customer side does perform only one reg= istration to the network. > The AoRs associated to the served terminals inside the client domain a= re registred automatically > by the home network, using implicit registration for example. In fact,= it's not conceivable to > register individually all the users of a corporate network for example. You seem to be describing one of the models covered by the SIPForum in thei= r SIPConnect specification. Is that what you mean? From the point of view of the registrar this seems similar to IMS implicit= registration, except that the scale is much larger - there may be *very ma= ny* implicit registrations generated by this one explicit registration. > - The "intermediate entity" should be able to route incoming requests ins= ide its domain based on > standard RFC3261 behaviour, that is, based on the Request-URI. I find the case much less compelling than the IMS case. IMO this is an abuse of REGISTER to a purpose for which it is not well suit= ed. Treating it as registration means that there is an *expectation* that the R= -URI will be translated. That isn't really appropriate in this case. The re= gistration doesn't specify the mapping anyway - it is configuration in the = network of all the addresses that belong to the "pbx" that does that. This = is more appropriately viewed as just a routing operation, and so pushing th= e address of the enterprise server as a Route header is by far the best cho= ice. Its only because this has been done using REGISTER that brings up how = to preserve the old address when it is translated. Thanks, Paul > Best regards > = > Youssef > = > = > = > = > = >> -----Message d'origine----- >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : lundi 28 = >> janvier 2008 21:46 =C0 : CHADLI Youssef RD-CORE-ISS Cc : = >> drage@alcatel-lucent.com; sip@ietf.org Objet : Re: [Sip] Delivering = >> request-URI and parameters to UAS via proxy >> >> These cases can all be handled by having intermediate entity use a = >> unique user part, together with its own domain name, to construct a = >> contact address for each terminal UA that it is registering. Then = >> when it receives an incoming request to one of these uris it can = >> simply translate it, using the user part as a key to its own local = >> mappings. >> >> We don't need anything new to solve these cases. >> >> Paul >> >> youssef.chadli@orange-ftgroup.com wrote: >>> = >>> There are other cases similar to what is described in >> section 2.1 Unknown Aliases of J. Rosenberg draft that should be = >> taken into account. >>> Those cases are where the customer side is composed of >> several SIP terminals that access the network through an intermediate = >> entity which registers their associated aliases with its contact = >> address. Thus, such client side is seen from the network as a single = >> client having several aliases (aggregated endpoints). Moreover, such = >> client side may be a mini private network composed of several = >> entities. In these configurations, the intermediate entity is in = >> charge of routeing incoming calls inside the client domain and may = >> need to behave as a SIP proxy for incoming SIP messages. >>> As examples of such configuration: >>> - Corporate networks: in that case the PBX register all the >> served individual user identities with its contact address and routes = >> incoming calls toward the individual called users. >>> - Home networks: the Home Gateway may need to register on >> behalf of all the served terminals. The Home Gateway is in charge of = >> routeing incoming calls toward the individual called users. >>> J. Rosenberg draft seems give a good solution to take into >> account these configurations. >>> = >>> Best regards, >>> >>> Youssef >>> >>> >>>> -----Message d'origine----- >>>> De : DRAGE, Keith (Keith) >> [mailto:drage@alcatel-lucent.com] Envoy=E9 : = >>>> lundi 14 janvier 2008 17:58 =C0 : sip@ietf.org Objet : [Sip] >> Delivering >>>> request-URI and parameters to UAS via proxy >>>> >>>> (As WG chair) >>>> >>>> In fulfilment of our charter items of >>>> >>>> Dec 2007 Delivering request-URI and parameters to UAS = >> via proxy to >>>> WGLC = >>>> Feb 2008 Delivering request-URI and parameters to UAS = >> via proxy to >>>> IESG (PS) >>>> >>>> We now have a couple of proposals on the table for solving the = >>>> problem. >>>> >>>> The original draft from Jonathan and which led to the >> creation of the >>>> charter items by the WG is unfortunately expired, but is at: >>>> >>>> http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt >>>> >>>> The alternative document from Christer, etc is at: >>>> >>>> http://www.ietf.org/internet-drafts/draft-holmberg-sip-target- >>>> uri-delive >>>> ry-00.txt >>>> >>>> We obviously need to make a decision between the two approaches so = >>>> please attempt to address the following specific points via the = >>>> mailing >>>> list: >>>> >>>> 1) Problem cases: These are summarised in section 4.4 of >>>> draft-rosenberg-sip-ua-loose-route-01 and from my read of >> the other >>>> draft, I don't believe that this draft adds any others. >>>> If you believe there are other cases that should be covered by the = >>>> solution, then please identify them. If there is support >> on any new >>>> problem cases, I would encourage the authors of both drafts to add = >>>> text concerning these problem cases. >>>> >>>> 2) Clarifications: If for any reason you don't understand either >>>> draft, or believe that there are technical issues that are not = >>>> represented in the current draft, please post your questions / = >>>> comments to the list. I would encourage authors of both drafts to = >>>> revise as frequently as appropriate to reflect the current >> state of >>>> discussion. >>>> >>>> 3) Support for either position. If you wish to indicate support for >>>> either position please do so, but please accompany this is >> technical >>>> reasoning as to why you have this position, as that will >> help other >>>> members of the WG form a position. >>>> >>>> I would encourage as much list discussion as possible before = >>>> Philadelphia. I suspect we will need to have a discussion at the = >>>> face-to-face meeting in Philadephia, but list discussion >> is essential >>>> prior to that. If we can solve this positions on list, >> then well and >>>> good, and even better (that is how we are meant to make decisions). >>>> >>>> Regards >>>> >>>> >>>> Keith >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use = >>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use = >>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>> sipping@ietf.org for new developments on the application of sip >>> > = _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sracily@nmt.com.tr Fri Feb 1 02:54:49 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BC43A6913 for ; Fri, 1 Feb 2008 02:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 35.568 X-Spam-Level: *********************************** X-Spam-Status: Yes, score=35.568 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_MORE_SIZE=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_ILLEGAL_IP=1.908, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 2.1 FH_HOST_EQ_VERIZON_P Host is pool-.+verizon.net * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.5 HELO_EQ_VERIZON_POOL HELO_EQ_VERIZON_POOL * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 1.9 RCVD_ILLEGAL_IP Received: contains illegal IP address * 10 FB_MORE_SIZE BODY: Phrase: more size * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [72.89.150.238 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [72.89.150.238 listed in dnsbl.sorbs.net] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaE00hg91v4V for ; Fri, 1 Feb 2008 02:54:48 -0800 (PST) Received: from pool-72-89-150-238.nycmny.fios.verizon.net (pool-72-89-150-238.nycmny.fios.verizon.net [72.89.150.238]) by core3.amsl.com (Postfix) with SMTP id 530333A690F for ; Fri, 1 Feb 2008 02:54:47 -0800 (PST) Received: from [224.167.187.83] (helo=pcr) by pool-72-89-150-238.nycmny.fios.verizon.net with smtp (Exim 4.62 (FreeBSD)) id 1JLTdC-0001ht-Eh; Fri, 1 Feb 2008 06:00:26 -0500 Message-ID: <001601c864c1$1409a020$53bba7e0@pcr> From: To: Subject: ***SPAM*** 35.568 (5) Convenient and private ordering! Date: Fri, 1 Feb 2008 05:56:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Get more size for your enjoyment! http://125.179.156.23/qoohjp/ From mailman-bounces@core3.amsl.com Fri Feb 1 05:27:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649752938AE for ; Fri, 1 Feb 2008 05:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEsv9C7DMMgh for ; Fri, 1 Feb 2008 05:26:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022E6294682 for ; Fri, 1 Feb 2008 05:05:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: sip-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:02:19 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/sip/sip-archive%40optimus.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 05:27:54 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E03728CA35 for ; Fri, 1 Feb 2008 05:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhNQkGGWytGp for ; Fri, 1 Feb 2008 05:26:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AAA429460D for ; Fri, 1 Feb 2008 05:05:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: sip-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:02:18 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/sip/sip-archive%40optimus.ietf.org From dunford@indorama.com.tr Fri Feb 1 09:52:31 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF563A698A for ; Fri, 1 Feb 2008 09:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 61.664 X-Spam-Level: ************************************************************* X-Spam-Status: Yes, score=61.664 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.5 HELO_EQ_CPE HELO_EQ_CPE * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.0 HOST_EQ_CPE HOST_EQ_CPE * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 71.230.219.209] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 71.230.219.209] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 71.230.219.209] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [76.90.226.164 listed in zen.spamhaus.org] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtMdOrAUECCF for ; Fri, 1 Feb 2008 09:52:30 -0800 (PST) Received: from cpe-76-90-226-164.socal.res.rr.com (cpe-76-90-226-164.socal.res.rr.com [76.90.226.164]) by core3.amsl.com (Postfix) with SMTP id 5C9DD3A6982 for ; Fri, 1 Feb 2008 09:52:29 -0800 (PST) Received: from wpfiw ([44.165.145.208]) by cpe-76-90-226-164.socal.res.rr.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 09:54:03 -0800 Message-ID: <002401c864fb$6eaf99f0$d091a52c@wpfiw> From: To: Subject: ***SPAM*** 61.664 (5) You're the One Date: Fri, 1 Feb 2008 09:54:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4131.1600 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4131.1600 A Kiss So Gentle http://71.230.219.209/ From carlepiderma891134@yahoo.com Fri Feb 1 09:52:49 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17F33A697F; Fri, 1 Feb 2008 09:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 246.425 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=246.425 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE=10.357, GB_H_WATCH_1=50, GB_REPLICA=50, GB_WATCH_1=50, HELO_EQ_DE=0.35, HELO_EQ_DSL=1.129, INVALID_MSGID=1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_DOUBLE_IP_SPAM=3.798, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_RECV_IP_FROMIP1=1.666, SARE_SPEC_REPL_OBFU1=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 0.3 HELO_EQ_DE HELO_EQ_DE * 50 GB_H_WATCH_1 Misspelled Watch Watch Seller * 10 FH_FAKE_RCVD_LINE RCVD line looks faked (A) * 1.7 SARE_RECV_IP_FROMIP1 Received line is IP address from IP address * 1.7 SARE_SPEC_REPL_OBFU1 BODY: SARE_SPEC_REPL_OBFU1 * 0.6 J_CHICKENPOX_42 BODY: 4alpha-pock-2alpha * 0.6 J_CHICKENPOX_15 BODY: 1alpha-pock-5alpha * 50 GB_REPLICA BODY: Misspelled Replica Watch Seller * 50 GB_WATCH_1 BODY: Misspelled Watch Watch Seller * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: ghetsyye.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: ghetsyye.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [85.180.179.149 listed in dnsbl.sorbs.net] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [85.180.179.149 listed in zen.spamhaus.org] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: ghetsyye.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: ghetsyye.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: ghetsyye.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: ghetsyye.com] * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 3.8 RCVD_DOUBLE_IP_SPAM Bulk email fingerprint (double IP) found Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0j2PWcqdZHg; Fri, 1 Feb 2008 09:52:49 -0800 (PST) Received: from e180179149.adsl.alicedsl.de (e180179149.adsl.alicedsl.de [85.180.179.149]) by core3.amsl.com (Postfix) with SMTP id 5AB7B3A681A; Fri, 1 Feb 2008 09:52:34 -0800 (PST) Received: from 7.132.15.100 by 85.180.179.149; Fri, 01 Feb 2008 11:46:08 -0600 Message-ID: From: "Gus Murray" Reply-To: "Gus Murray" To: sherri.hilton@ietf.org Subject: ***SPAM*** 246.425 (5) January promo on w4tches Date: Fri, 01 Feb 2008 12:54:08 -0500 MIME-Version: 1.0 Winter is hitting and New Year is coming. Do you need perfect gift? 0rder high qual1ty repl1ca of w4tches, purses & bags from 2008! http://www.ghetsyye.com/ From jcstarnes@llog.lynden.com Fri Feb 1 09:53:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8073A697D for ; Fri, 1 Feb 2008 09:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 23.883 X-Spam-Level: *********************** X-Spam-Status: Yes, score=23.883 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, TVD_SPACE_RATIO=2.219] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.5 HELO_EQ_CPE HELO_EQ_CPE * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.0 HOST_EQ_CPE HOST_EQ_CPE * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 63] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 63] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [76.90.226.164 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0Ho4vaaaG5L for ; Fri, 1 Feb 2008 09:53:33 -0800 (PST) Received: from cpe-76-90-226-164.socal.res.rr.com (cpe-76-90-226-164.socal.res.rr.com [76.90.226.164]) by core3.amsl.com (Postfix) with SMTP id 71C483A67F2 for ; Fri, 1 Feb 2008 09:53:33 -0800 (PST) Received: from lzdq ([131.55.236.81]) by cpe-76-90-226-164.socal.res.rr.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Feb 2008 09:55:07 -0800 Message-ID: <001301c864fb$94de88c0$51ec3783@lzdq> From: To: Subject: ***SPAM*** 23.883 (5) Love Remains Date: Fri, 1 Feb 2008 09:55:07 -0800 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 5.50.4133.2499 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2499 Our Journey http://67.36.58.240/ From sip-bounces@ietf.org Fri Feb 1 12:45:13 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18CD3A69F4; Fri, 1 Feb 2008 12:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkN5H6W+AUFm; Fri, 1 Feb 2008 12:45:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C14C28C276; Fri, 1 Feb 2008 12:45:07 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5B6973A68A6; Fri, 1 Feb 2008 12:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080201204502.5B6973A68A6@core3.amsl.com> Date: Fri, 1 Feb 2008 12:45:02 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-certs-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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-05.txt Pages : 30 Date : 2008-02-01 This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service, which returns an authenticated response containing that certificate. The Credential Service also allows users to store and retrieve their own certificates and private keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-certs-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-certs-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-01124159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-certs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-certs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-01124159.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Sun Feb 3 08:37:30 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD613A6CBA; Sun, 3 Feb 2008 08:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=1.287, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3DFDV6Lyx9p; Sun, 3 Feb 2008 08:37:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CA73A6C9B; Sun, 3 Feb 2008 08:37:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58AE53A6C9A for ; Sun, 3 Feb 2008 08:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td7Zg3Rr95JG for ; Sun, 3 Feb 2008 08:37:26 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0AF233A6C68 for ; Sun, 3 Feb 2008 08:37:25 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m13GcxGP000607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 3 Feb 2008 10:39:00 -0600 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <20080201204502.5B6973A68A6@core3.amsl.com> References: <20080201204502.5B6973A68A6@core3.amsl.com> Message-Id: <61C96F5E-46CB-4806-B45C-9EBF4C5B8C09@softarmor.com> From: Dean Willis Date: Sun, 3 Feb 2008 10:38:50 -0600 To: IETF SIP List X-Mailer: Apple Mail (2.753) Subject: [Sip] pub request for draft-ietf-sip-certs-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 1, 2008, at 2:45 PM, 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-05.txt > Pages : 30 > Date : 2008-02-01 > I've requested publication for this draft. Here's the writeup I submitted along with the pub request, should you = be interested. ---------------- The SIP working group hereby requests publication of the document = draft-ietf-sip-certs-05 as a Proposed Standard. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd is working group chair Dean Willis, who has = personally reviewed this version of the document and believes it is = ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been extensively reviewed within the working group = and by external reviewers, including security area review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No further review required. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the = document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this = document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document enjoys a high level of working group concurrence, = relative to the majority of security-related documents. Essentially = the working group as a whole agree with the document, including the = ones who actually understand it. (1.f) Has anyone threatened an appeal or otherwise indicated = extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. = (It should be in a separate email because this questionnaire is entered into the ID Tracker.) This shepherd is unaware of any discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the = document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The shepherd applied idnits 2.06.01. Note that the document does = contain a downref to RFC 2898. This downref is explained in the = references section of the document and appears to be justified under = the procedures of RFC 3967. The following text is quoted from the = document: This reference is normative. The mechanisms used in this specification from RFC2898 are stable and sutable for use in a standards track specification. RFC2898 has been = used as a normative reference in several prior standards track documents including RFC3185, RFC3370, RFC3962, and RFC4656. The document also received appropriate review from the MIME Types = alias and SIP events alias. (1.h) Has the document split its references into normative and informative? Are there normative references to documents = that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative = references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are properly split, with one valid downward reference as = described above. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA actions section appears to be correct, and has undergone = appropriate expert review. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document appears to contain no formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This draft defines a Credential Service that allows Session = Initiation Protocol (SIP) User Agents (UAs) to use a SIP event = package to discover the certificates of other users. This mechanism = allows user agents that want to contact a given Address-of-Record = (AOR) to retrieve that AOR's certificate by subscribing to the = Credential Service, which returns an authenticated response = containing that certificate. The Credential Service also allows = users to store and retrieve their own certificates and private keys. = Several operational modes are defined, wherein the credential service = may act only as a distributor of the public key, may also act as a = distributor of the encrypted private key, or as the repository and = distributor of both the public and private key. Working Group Summary The working group process for this draft was unusually long, spanning = several years. Document Quality Are there existing implementations of the protocol? = Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive = issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media = Type review, on what date was the request posted? We are currently not aware of any publicly announced implementations = of this specification, although one can be built relatively trivially = on top of general purpose SIP Events servers, and we are aware of at = least one internal prototype implemented in this manner. MIME type review was non-controversial and was initiated on March 12, = 2007. Bj=F6rn H=F6hrmann raised several points, which were resolved in = the -04 version of this specification. SIP Events review was performed by Adam Roach, with several issues = being noted and resolved in -03 of this specification. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From jqyay@travelgolf.com Tue Feb 5 10:34:07 2008 Return-Path: X-Original-To: sip-archive@ietf.org Delivered-To: ietfarch-sip-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id B1C8E3A90F7; Tue, 5 Feb 2008 10:52:55 -0800 (PST) Received: from sufi-isis.org (unknown [85.103.43.173]) by mail.ietf.org (Postfix) with SMTP id 30F1A3A8B97 for ; Mon, 4 Feb 2008 23:18:14 -0800 (PST) Received: from 206.191.20.150 (HELO magmail.travelgolf.com) by ietf.org with esmtp (EGTWSRBXOZ SBNZH) id F4Cqj3-v3jbdq-o1 for sip-archive@ietf.org; Mon, 04 Feb 2008 09:21:41 +0200 Message-ID: <000301c866fe$96abb1a0$c0a80121@Billy> From: "Billy Q. Allen" To: "Jacob B. Young" Subject: Give your loved people items of dazzling beauty! Date: Mon, 04 Feb 2008 09:21:41 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 080203-0, 03/02/2008), Outbound message X-Antivirus-Status: Clean


____________________________
EMAIL ID: 0HXfM From jramos@apu.edu Tue Feb 5 10:34:14 2008 Return-Path: X-Original-To: sip-archive@ietf.org Delivered-To: ietfarch-sip-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 38A9E3A8B65; Tue, 5 Feb 2008 10:52:46 -0800 (PST) Received: from 5ac86af9.bb.sky.com (5ac86af9.bb.sky.com [90.200.106.249]) by mail.ietf.org (Postfix) with SMTP id 26A323A94D7 for ; Tue, 5 Feb 2008 02:25:24 -0800 (PST) Received: from 199.184.238.20 (HELO mx1.apu.edu) by ietf.org with esmtp (GNGIMUIDM WMHFHI) id sdTK2W-mMNCHj-62 for sip-archive@ietf.org; Tue, 05 Feb 2008 10:26:59 +0000 Message-ID: <0afb01c867e1$a3c9e800$f96ac85a@Leo> From: "Leo Murray" To: "Andre Freeman" Subject: don.t wait, change your life today! Date: Tue, 05 Feb 2008 10:26:59 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_2809_0B63_01C867E1.A3C9E800" 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 This is a multi-part message in MIME format. ------=_NextPart_2809_0B63_01C867E1.A3C9E800 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your phallus grows into the thickest, biggest, hardest, and most power= ful tool=20 you`ve ever imagined - the one you`ve always interested about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - THE BEST}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PEN|S OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! CHECK IT OUT NOW TO MAKE YOUR PEN|S BIGGER AND HARDER IN THIS YEAR! http://uiseegge=2Ecom/ results=2E The precise cause of death is still beingfrom the Cretaceous p= eriod ofshocked, but uninjured at a press conference with Iraqi of which were captured in 2003=2E ELA took responsibilityState University= 's chief researcher, David Varricchio=2E ------=_NextPart_2809_0B63_01C867E1.A3C9E800 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
#1 DOCTOR RECOMMENDED PEN|S= EN'L@RGEMENT FORMULA!

In just= a few short weeks,=20 you`ll watch with amazement as your phallus
grows into the thickest, = biggest, hardest, and most powerful tool
you`ve ever imagined - the one you`ve always interested about
having!= No pen!s en`l@rgement=20 system is faster, easier to use, or
more effective than VPXL+= - THE BEST!

VPXL+ IS=20 GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PE= N|S OR=20 YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARG= E TODAY!

CHECK IT OUT NOW TO MAKE YOUR PEN= |S BIGGER AND HARDER IN THIS YEAR!



services=2EToronto man claims $18 million jackpot
workresults=2E The precise cause of death is still being
from the Cret= aceous period ofshocked, but uninjured at a press conference with Iraqiof which were captured in 2003=2E ELA took responsibilityState Universi= ty's chief researcher, David Varricchio=2E ------=_NextPart_2809_0B63_01C867E1.A3C9E800-- From xxf@celsoc.org Tue Feb 5 10:35:16 2008 Return-Path: X-Original-To: sip-archive@lists.ietf.org Delivered-To: ietfarch-sip-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id DADAB28C26F; Tue, 5 Feb 2008 10:53:04 -0800 (PST) Received: from client-190.40.58.66.speedy.net.pe (unknown [190.40.58.66]) by mail.ietf.org (Postfix) with SMTP id 059B83A71A7 for ; Mon, 4 Feb 2008 13:44:25 -0800 (PST) Received: from nlte ([223.50.61.89]) by client-190.40.58.66.speedy.net.pe (8.13.1/8.13.1) with SMTP id m14LmCIf055201; Mon, 4 Feb 2008 16:48:12 -0500 Message-ID: <003001c86777$4d9c09a0$593d32df@nlte> From: To: Subject: Size truly does matter! Date: Mon, 4 Feb 2008 16:45:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Blue-pill ...the only way to go... http://vl.speakpound.com From cjames@radianmi.com Tue Feb 5 10:37:38 2008 Return-Path: X-Original-To: sip-archive@ietf.org Delivered-To: ietfarch-sip-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 93BD63A8675; Tue, 5 Feb 2008 10:52:57 -0800 (PST) Received: from mumbai-119-82.primenet.in (mumbai-119-82.primenet.in [203.115.119.82]) by mail.ietf.org (Postfix) with SMTP id CBCAB3A88FC for ; Mon, 4 Feb 2008 22:35:35 -0800 (PST) Received: from ixsa ([210.181.157.97]) by mumbai-119-82.primenet.in with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Feb 2008 12:07:05 +0530 Message-ID: <47A80411.7030707@radianmi.com> Date: Tue, 5 Feb 2008 12:07:05 +0530 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: sip-archive@ietf.org Subject: My Love Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eternity of Your Love http://121.135.110.242/ From ismaelanton@bekaert.com Tue Feb 5 10:43:01 2008 Return-Path: X-Original-To: sip-archive@ietf.org Delivered-To: ietfarch-sip-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id E2F843A7499; Tue, 5 Feb 2008 10:53:06 -0800 (PST) Received: from dsl88-244-13462.ttnet.net.tr (unknown [88.224.52.150]) by mail.ietf.org (Postfix) with SMTP id 4F2B43A96A4 for ; Tue, 5 Feb 2008 02:34:24 -0800 (PST) Received: from [71.213.50.205] (helo=iisy) by dsl88-244-13462.ttnet.net.tr with smtp (Exim 4.62 (FreeBSD)) id 1JMLBF-0005NY-15; Tue, 5 Feb 2008 12:37:33 +0200 Message-ID: <002701c867e2$eb62ce10$cd32d547@iisy> From: To: Subject: Be happy with manpower candy! Date: Tue, 5 Feb 2008 12:36:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4131.1600 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4131.1600 The baby-maker grows and develops GRADUALLY, not over night! http://unzomo.speakpound.com From larry@blomadvocaten.nl Tue Feb 5 10:44:01 2008 Return-Path: X-Original-To: sip-archive@lists.ietf.org Delivered-To: ietfarch-sip-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 4405B3A688B; Tue, 5 Feb 2008 10:52:54 -0800 (PST) Received: from dsl88-244-13462.ttnet.net.tr (unknown [88.224.52.150]) by mail.ietf.org (Postfix) with SMTP id 167FC3A96B1 for ; Tue, 5 Feb 2008 02:35:35 -0800 (PST) Received: from [154.151.119.73] (helo=ete) by dsl88-244-13462.ttnet.net.tr with smtp (Exim 4.62 (FreeBSD)) id 1JMLBR-0002RR-2S; Tue, 5 Feb 2008 12:37:45 +0200 Message-ID: <000e01c867e3$159bac60$4977979a@ete> From: To: Subject: Hey, can a man make love more that 10 minutes? Yes, you can with our "manpower candies" Date: Tue, 5 Feb 2008 12:37:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4029.2901 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 Be attractive! http://doni.andconsider.com From ayptykonyd@net24.it Tue Feb 5 11:02:53 2008 Return-Path: X-Original-To: sip-archive@lists.ietf.org Delivered-To: ietfarch-sip-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 3E7CB3A794D; Tue, 5 Feb 2008 10:37:54 -0800 (PST) Received: from net24.it (adsl-ull-56-165.46-151.net24.it [151.46.165.56]) by mail.ietf.org (Postfix) with SMTP id EDB0D3A9D7D; Tue, 5 Feb 2008 04:01:21 -0800 (PST) Received: from unknown (71.207.128.47) by rsmail.alkoholic.net with NNFMP; Tue, 05 Feb 2008 08:01:19 -0500 Message-ID: <21010E9F.A590391D@net24.it> Date: Tue, 05 Feb 2008 08:01:05 -0500 Reply-To: "Landon 52" From: "Landon 52" User-Agent: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; U) MIME-Version: 1.0 To: "Bianca" , "Beverly" , "Beverley" Subject: Don't forget, tomorrow is Scottie's anniversary party Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit When we first started studying life stories, people thought it was just idle curiosity — stories, isn’t that cool?

RO
 LEX    
OM
 EGA    
BREIT
 LING
  from € 155.-
  from € 143.-
  from € 154.-

All top brands with over 1'531 models are available at: http://ryod.minavergalo.com

  • 15% discount when you buy 2 ore more watches
  • Free shipping worldwide
  • Perfect quality
  • Secure payment system
  • Even professionals are unable to tell the difference
    • From sip-bounces@ietf.org Tue Feb 5 13:59:43 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593E428C29D; Tue, 5 Feb 2008 13:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=1, IP_NOT_FRIENDLY=0.334] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBRjMbFcOPP8; Tue, 5 Feb 2008 13:59:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2133A6FA8; Tue, 5 Feb 2008 13:42:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1DFD3A6FA8 for ; Tue, 5 Feb 2008 13:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa6vF4Dv-iQ4 for ; Tue, 5 Feb 2008 13:42:21 -0800 (PST) Received: from web63215.mail.re1.yahoo.com (web63215.mail.re1.yahoo.com [69.147.97.25]) by core3.amsl.com (Postfix) with SMTP id 63C4E3A7CAE for ; Tue, 5 Feb 2008 13:22:21 -0800 (PST) Received: (qmail 60159 invoked by uid 60001); 5 Feb 2008 21:23:54 -0000 X-YMail-OSG: HWCmQOIVM1m57J9HZ_IT5jkg_f.cuqRw9ZI_xEvLqur3dldoy27nOJYFrH6LxidiGyuxHN7FECdxG7ebDCcgQGaoAA-- Received: from [216.191.234.70] by web63215.mail.re1.yahoo.com via HTTP; Tue, 05 Feb 2008 13:23:53 PST Date: Tue, 5 Feb 2008 13:23:53 -0800 (PST) From: Jerry Yin To: IETF SIP List In-Reply-To: <61C96F5E-46CB-4806-B45C-9EBF4C5B8C09@softarmor.com> MIME-Version: 1.0 Message-ID: <2263.58408.qm@web63215.mail.re1.yahoo.com> Cc: rohan@ekabal.com, vkg@acm.org, jerry_yin@mitel.com, brett@broadsoft.com Subject: [Sip] Comments on draft-ietf-sip-connect-reuse-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0425071843==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0425071843== Content-Type: multipart/alternative; boundary="0-922860791-1202246633=:58408" Content-Transfer-Encoding: 8bit --0-922860791-1202246633=:58408 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Rohan and all, I can't find the discussing about the connection reuse when NAT/Firewall involved. Sorry if it is documented somewhere already. Here's my comments: SIP UA behind a NAT/Firewall using TCP: According to the current draft (08), the UA and proxy have to create bi-direction connections. It seems that it is impossible for the proxy (at the public side of the firewall) to make a new TCP connection to the phone for incoming requests without reusing the phone’s existing TCP connection with the proxy. SIP UA behind a NAT using TCP to register to the server: The only possible way a UA can receive incoming calls is to reuse the TCP connection that it has created to register with the proxy/registrar. For the above two reasons, I think it would be better to treat the TCP/SCTP the same way as the TLS. It would make the design and implementation simple. The SIP routing behavior would be consistent when supporting the “connection reuse” draft. As the TCP security concerns are discussed in the section 9.3 “Security Considerations for the TCP Transport”, the first 3 attacks can be prevented by Digest authentications. I can’t figure out what is the last case all about (Proxy enter an aliasing agreement with downstream proxy)? If there are services between these two proxies, they will create connections, one or two, anyway. What are really the concerns here? Regards, Jerry --------------------------------- Never miss a thing. Make Yahoo your homepage. --0-922860791-1202246633=:58408 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    Hi Rohan and all,
     
    I can't find the discussing about the connection reuse when NAT/Firewall involved. Sorry if it is documented somewhere already. Here's my comments:
     
     
    1. SIP UA behind a NAT/Firewall using TCP: According to the current draft (08), the UA and proxy have to create bi-direction connections. It seems that it is impossible for the proxy (at the public side of the firewall) to make a new TCP connection to the phone for incoming requests without reusing the phone’s existing TCP connection with the proxy.
    2. SIP UA behind a NAT using TCP to register to the server: The only possible way a UA can receive incoming calls is to reuse the TCP connection that it has created to register with the proxy/registrar.
     
    For the above two reasons, I think it would be better to treat the TCP/SCTP the same way as the TLS. It would make the design and implementation simple. The SIP routing behavior would be consistent when supporting the “connection reuse” draft.
     
    As the TCP security concerns are discussed in the section 9.3 “Security Considerations for the TCP Transport”, the first 3 attacks can be prevented by Digest authentications. I can’t figure out what is the last case all about (Proxy enter an aliasing agreement with downstream proxy)?  If there are services between these two proxies, they will create connections, one or two, anyway. What are really the concerns here?
     
    Regards,
    Jerry
     

    Never miss a thing. Make Yahoo your homepage. --0-922860791-1202246633=:58408-- --===============0425071843== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0425071843==-- From sip-bounces@ietf.org Tue Feb 5 14:25:57 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5872F3A6EBD; Tue, 5 Feb 2008 14:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKpesVSGdS-M; Tue, 5 Feb 2008 14:25:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073DA3A74D3; Tue, 5 Feb 2008 14:03:58 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E23E3A6C3F for ; Tue, 5 Feb 2008 14:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St61Wlbp479V for ; Tue, 5 Feb 2008 14:03:55 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 1F9813A9A1B for ; Tue, 5 Feb 2008 13:41:26 -0800 (PST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m15Lge6p025769; Tue, 5 Feb 2008 15:42:40 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m15Lfij27958; Tue, 5 Feb 2008 15:42:37 -0600 (CST) Message-ID: <47A8D818.6040400@alcatel-lucent.com> Date: Tue, 05 Feb 2008 15:41:44 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jerry Yin References: <2263.58408.qm@web63215.mail.re1.yahoo.com> In-Reply-To: <2263.58408.qm@web63215.mail.re1.yahoo.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: IETF SIP List , rohan@ekabal.com, jerry_yin@mitel.com, brett@broadsoft.com Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jerry Yin wrote: > Hi Rohan and all, Jerry: Thank you for your time reviewing the draft. > I can't find the discussing about the connection reuse when NAT/Firewall = > involved. Sorry if it is documented somewhere already. = That particular behavior is documented in sip-outbound (see Section 2 of connect-reuse for a reference to the discussion delineating connect-reuse and sip-outbound.) sip-outbound can be accessed from: http://tools.ietf.org/html/draft-ietf-sip-outbound-11 > For the above two reasons, I think it would be better to treat the = > TCP/SCTP the same way as the TLS. It would make the design and = > implementation simple. The SIP routing behavior would be consistent when = > supporting the =93connection reuse=94 draft. > = > As the TCP security concerns are discussed in the section 9.3 =93*Securit= y = > Considerations for the TCP Transport=94, *the first 3 attacks can be = > prevented by Digest authentications. I can=92t figure out what is the las= t = > case all about (Proxy enter an aliasing agreement with downstream = > proxy)? If there are services between these two proxies, they will = > create connections, one or two, anyway. What are really the concerns here? As it turns out, we are about to release -09 based on the WGLC review in November. Brett and I are trying to close an open issue between us, and once that is done, -09 will be released later this week. -09 provides more succinct reasons why TCP/SCTP cannot be reused and it also shortens considerably Section 9.3 based on the WGLC review feedback. Thanks, - vijay -- = Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 5 15:31:43 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB603A69D6; Tue, 5 Feb 2008 15:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSu6YA8cvNYU; Tue, 5 Feb 2008 15:31:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047D93A699F; Tue, 5 Feb 2008 15:28:22 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69583A68ED for ; Tue, 5 Feb 2008 15:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HhxHNF-6zyf for ; Tue, 5 Feb 2008 15:28:19 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by core3.amsl.com (Postfix) with ESMTP id 37C0C3A6B6D for ; Tue, 5 Feb 2008 15:22:51 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id i10so2420111mue.3 for ; Tue, 05 Feb 2008 15:24:22 -0800 (PST) Received: by 10.82.174.20 with SMTP id w20mr16514968bue.28.1202253862229; Tue, 05 Feb 2008 15:24:22 -0800 (PST) Received: by 10.82.190.13 with HTTP; Tue, 5 Feb 2008 15:24:22 -0800 (PST) Message-ID: Date: Tue, 5 Feb 2008 17:24:22 -0600 From: "David Roan" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] Remote Target on Established Dialog and Remote Target Refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1113884552==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1113884552== Content-Type: multipart/alternative; boundary="----=_Part_16244_21313479.1202253862223" ------=_Part_16244_21313479.1202253862223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks to everyone who responded to my earlier query (Target Refresh Request and Contact Header thread). I now have a similar query for establishing the Remote Target. Please forgive the length in advance and feel free to insert corrections/input as necessary. From section 12.1 of RFC 3261, the following is stated: Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. This seems to indicate that either a 2xx or 101-199 response (with a To tag) to the initial INVITE can establish a dialog (confirmed vs early dialog respectively), correct? Then, from section 12.1.1 of RFC 3261, the following is added about the response that establishes the dialog: When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. The UAS MUST add a Contact header field to the response. This seems to indicate that the first 101-199 response sent from the UAS/received at the UAC (with a To Tag) must contain a Contact header (to set the Remote Target at the UAC), correct? So, if the Contact header is not received in this response, this would be considered a violation of the spec and an invalid response, correct? Also, according to the following section ( 12.1.2), this also sets up the dialog state (items like the route set, if not empty, and the Remote Target). Section 12.2 of RFC 3261 goes into additional details of when the Remote Target can be changed (ie, Remote Target Refresh): Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways. Note that an ACK is NOT a target refresh request. Target refresh requests only update the dialog's remote target URI, and not the route set formed from the Record-Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems. This seems to indicate that after the 101-199 response is received (that establishes the dialog), only the re-INVITE and its 2xx response and UPDATE (per RFC 3311) and its 2xx response can change the Remote Target. Therefore, if a subsequent provisional response to the INVITE (ie, 180 Ringing that followed a 183 Session Progress) is received, it is not allowed to update the Remote Target if it contains a Contact header, correct? What about an UPDATE received in the early dialog state? This would also allow the Remote Target to be updated, correct? Thanks again, David Roan ------=_Part_16244_21313479.1202253862223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
    Thanks to everyone who responded to my earlier query (Target Refresh Request and Contact Header thread).

    I now have a similar query for establishing the Remote Target. Please forgive the length in advance and feel free to insert corrections/input as necessary.

    From section 12.1 of RFC 3261, the following is stated:
    Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog.

    This seems to indicate that either a 2xx or 101-199 response (with a To tag) to the initial INVITE can establish a dialog (confirmed vs early dialog respectively), correct?

    Then, from section 12.1.1 of RFC 3261, the following is added about the response that establishes the dialog:
    When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. The UAS MUST add a Contact header field to the response.

    This seems to indicate that the first 101-199 response sent from the UAS/received at the UAC (with a To Tag) must contain a Contact header (to set the Remote Target at the UAC), correct? So, if the Contact header is not received in this response, this would be considered a violation of the spec and an invalid response, correct? Also, according to the following section (12.1.2), this also sets up the dialog state (items like the route set, if not empty, and the Remote Target).

    Section 12.2 of RFC 3261 goes into additional details of when the Remote Target can be changed (ie, Remote Target Refresh):  
    Requests within a dialog MAY contain Record-Route and Contact header fields.  However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do.  For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14).  Other extensions may define different target refresh requests for dialogs established in other ways.
          Note that an ACK is NOT a target refresh request.
    Target refresh requests only update the dialog's remote target URI, and not the route set formed from the Record-Route.  Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems.

    This seems to indicate that after the 101-199 response is received (that establishes the dialog), only the re-INVITE and its 2xx response and UPDATE (per RFC 3311) and its 2xx response can change the Remote Target. Therefore, if a subsequent provisional response to the INVITE (ie, 180 Ringing that followed a 183 Session Progress) is received, it is not allowed to update the Remote Target if it contains a Contact header, correct? What about an UPDATE received in the early dialog state? This would also allow the Remote Target to be updated, correct?

    Thanks again,
    David Roan
    ------=_Part_16244_21313479.1202253862223-- --===============1113884552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1113884552==-- From sip-bounces@ietf.org Tue Feb 5 16:06:22 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531653A68AB; Tue, 5 Feb 2008 16:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrywnwrALLSQ; Tue, 5 Feb 2008 16:06:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3D53A6868; Tue, 5 Feb 2008 16:06:20 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642F23A6868 for ; Tue, 5 Feb 2008 16:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHttl-y3oLm6 for ; Tue, 5 Feb 2008 16:06:17 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AF4743A6842 for ; Tue, 5 Feb 2008 16:05:58 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Feb 2008 19:07:31 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1607VHZ019985; Tue, 5 Feb 2008 19:07:31 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1607UMb025481; Wed, 6 Feb 2008 00:07:31 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 19:07:13 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 19:07:13 -0500 Message-ID: <47A8FA38.1080200@cisco.com> Date: Tue, 05 Feb 2008 19:07:20 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Roan References: In-Reply-To: X-OriginalArrivalTime: 06 Feb 2008 00:07:13.0571 (UTC) FILETIME=[39C36F30:01C86854] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Remote Target on Established Dialog and Remote Target Refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org David, I think everything you have said is right. These are some very fuzzy areas. Note that an *unreliable* provisional response can establish an early dialog. But because it is unreliable the UAS can't immediately know if the UAC is aware of the dialog. It is somewhere between very tricky and impossible to change the target during an early dialog. If you haven't found it yet, you should take a look at the race-examples draft (draft-ietf-sipping-race-examples-04.txt) for more discussion of this sort of subtle point. Thanks, Paul David Roan wrote: > Thanks to everyone who responded to my earlier query (Target Refresh > Request and Contact Header thread). > > I now have a similar query for establishing the Remote Target. Please > forgive the length in advance and feel free to insert corrections/input > as necessary. > > From section 12.1 of RFC 3261, the following is stated: > Within this specification, only 2xx and 101-199 responses with a To tag, > where the request was INVITE, will establish a dialog. > > This seems to indicate that either a 2xx or 101-199 response (with a To > tag) to the initial INVITE can establish a dialog (confirmed vs early > dialog respectively), correct? > > Then, from section 12.1.1 of RFC 3261, the following is added about the > response that establishes the dialog: > When a UAS responds to a request with a response that establishes a > dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route > header field values from the request into the response (including the > URIs, URI parameters, and any Record-Route header field parameters, > whether they are known or unknown to the UAS) and MUST maintain the > order of those values. The UAS MUST add a Contact header field to the > response. > > This seems to indicate that the first 101-199 response sent from the > UAS/received at the UAC (with a To Tag) must contain a Contact header > (to set the Remote Target at the UAC), correct? So, if the Contact > header is not received in this response, this would be considered a > violation of the spec and an invalid response, correct? Also, according > to the following section (12.1.2), this also sets up the dialog state > (items like the route set, if not empty, and the Remote Target). > > Section 12.2 of RFC 3261 goes into additional details of when the Remote > Target can be changed (ie, Remote Target Refresh): > Requests within a dialog MAY contain Record-Route and Contact header > fields. However, these requests do not cause the dialog's route set to > be modified, although they may modify the remote target URI. > Specifically, requests that are not target refresh requests do not > modify the dialog's remote target URI, and requests that are target > refresh requests do. For dialogs that have been established with an > INVITE, the only target refresh request defined is re-INVITE (see > Section 14). Other extensions may define different target refresh > requests for dialogs established in other ways. > Note that an ACK is NOT a target refresh request. > Target refresh requests only update the dialog's remote target URI, and > not the route set formed from the Record-Route. Updating the latter > would introduce severe backwards compatibility problems with RFC > 2543-compliant systems. > > This seems to indicate that after the 101-199 response is received (that > establishes the dialog), only the re-INVITE and its 2xx response and > UPDATE (per RFC 3311) and its 2xx response can change the Remote Target. > Therefore, if a subsequent provisional response to the INVITE (ie, 180 > Ringing that followed a 183 Session Progress) is received, it is not > allowed to update the Remote Target if it contains a Contact header, > correct? What about an UPDATE received in the early dialog state? This > would also allow the Remote Target to be updated, correct? > > Thanks again, > David Roan > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 5 18:25:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97BF3A6833; Tue, 5 Feb 2008 18:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WyiiTonqujZ; Tue, 5 Feb 2008 18:25:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D426F3A67FE; Tue, 5 Feb 2008 18:25:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2589A3A67FE for ; Tue, 5 Feb 2008 18:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G180VnAMC3A for ; Tue, 5 Feb 2008 18:25:31 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by core3.amsl.com (Postfix) with ESMTP id 989333A67FC for ; Tue, 5 Feb 2008 18:25:30 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w8so2077506mue.4 for ; Tue, 05 Feb 2008 18:27:02 -0800 (PST) Received: by 10.82.118.2 with SMTP id q2mr16824538buc.23.1202264821805; Tue, 05 Feb 2008 18:27:01 -0800 (PST) Received: by 10.82.190.13 with HTTP; Tue, 5 Feb 2008 18:27:01 -0800 (PST) Message-ID: Date: Tue, 5 Feb 2008 20:27:01 -0600 From: "David Roan" To: "Paul Kyzivat" In-Reply-To: <47A8FA38.1080200@cisco.com> MIME-Version: 1.0 References: <47A8FA38.1080200@cisco.com> Cc: sip@ietf.org Subject: Re: [Sip] Remote Target on Established Dialog and Remote Target Refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0957482565==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0957482565== Content-Type: multipart/alternative; boundary="----=_Part_16845_12650959.1202264821800" ------=_Part_16845_12650959.1202264821800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Paul, Thanks for the response. So, if the provisional responses are sent reliably, the provisional response would have an acking mechanism similar to the 2xx to ensure the dialog is established (ie, the chance of lost messaging is greatly diminished by the resending of Provisional Responses and the PRACK request), correct? I checked RFC 3262 wrt this and found the following: If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. The provisional response MUST establish a dialog if one is not yet created. This does not really indicate a dialog state, but this would still be an early dialog, right? Or, would it be confirmed since, like the 2xx, there is an ACK mechanism to ensure it is received? Thanks again for the insight and the pointer to the race condition draft, David Roan On Feb 5, 2008 6:07 PM, Paul Kyzivat wrote: > David, > > I think everything you have said is right. These are some very fuzzy > areas. > > Note that an *unreliable* provisional response can establish an early > dialog. But because it is unreliable the UAS can't immediately know if > the UAC is aware of the dialog. > > It is somewhere between very tricky and impossible to change the target > during an early dialog. If you haven't found it yet, you should take a > look at the race-examples draft > (draft-ietf-sipping-race-examples-04.txt) for more discussion of this > sort of subtle point. > > Thanks, > Paul > > David Roan wrote: > > Thanks to everyone who responded to my earlier query (Target Refresh > > Request and Contact Header thread). > > > > I now have a similar query for establishing the Remote Target. Please > > forgive the length in advance and feel free to insert corrections/input > > as necessary. > > > > From section 12.1 of RFC 3261, the following is stated: > > Within this specification, only 2xx and 101-199 responses with a To tag, > > where the request was INVITE, will establish a dialog. > > > > This seems to indicate that either a 2xx or 101-199 response (with a To > > tag) to the initial INVITE can establish a dialog (confirmed vs early > > dialog respectively), correct? > > > > Then, from section 12.1.1 of RFC 3261, the following is added about the > > response that establishes the dialog: > > When a UAS responds to a request with a response that establishes a > > dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route > > header field values from the request into the response (including the > > URIs, URI parameters, and any Record-Route header field parameters, > > whether they are known or unknown to the UAS) and MUST maintain the > > order of those values. The UAS MUST add a Contact header field to the > > response. > > > > This seems to indicate that the first 101-199 response sent from the > > UAS/received at the UAC (with a To Tag) must contain a Contact header > > (to set the Remote Target at the UAC), correct? So, if the Contact > > header is not received in this response, this would be considered a > > violation of the spec and an invalid response, correct? Also, according > > to the following section (12.1.2), this also sets up the dialog state > > (items like the route set, if not empty, and the Remote Target). > > > > Section 12.2 of RFC 3261 goes into additional details of when the Remote > > Target can be changed (ie, Remote Target Refresh): > > Requests within a dialog MAY contain Record-Route and Contact header > > fields. However, these requests do not cause the dialog's route set to > > be modified, although they may modify the remote target URI. > > Specifically, requests that are not target refresh requests do not > > modify the dialog's remote target URI, and requests that are target > > refresh requests do. For dialogs that have been established with an > > INVITE, the only target refresh request defined is re-INVITE (see > > Section 14). Other extensions may define different target refresh > > requests for dialogs established in other ways. > > Note that an ACK is NOT a target refresh request. > > Target refresh requests only update the dialog's remote target URI, and > > not the route set formed from the Record-Route. Updating the latter > > would introduce severe backwards compatibility problems with RFC > > 2543-compliant systems. > > > > This seems to indicate that after the 101-199 response is received (that > > establishes the dialog), only the re-INVITE and its 2xx response and > > UPDATE (per RFC 3311) and its 2xx response can change the Remote Target. > > Therefore, if a subsequent provisional response to the INVITE (ie, 180 > > Ringing that followed a 183 Session Progress) is received, it is not > > allowed to update the Remote Target if it contains a Contact header, > > correct? What about an UPDATE received in the early dialog state? This > > would also allow the Remote Target to be updated, correct? > > > > Thanks again, > > David Roan > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_16845_12650959.1202264821800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
    Hi Paul,
     
    Thanks for the response.
     
    So, if the provisional responses are sent reliably, the provisional response would have an acking mechanism similar to the 2xx to ensure the dialog is established (ie, the chance of lost messaging is greatly diminished by the resending of Provisional Responses and the PRACK request), correct?
     
    I checked RFC 3262 wrt this and found the following:
    If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably.  If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used.
    The provisional response MUST establish a dialog if one is not yet created.
     
    This does not really indicate a dialog state, but this would still be an early dialog, right? Or, would it be confirmed since, like the 2xx, there is an ACK mechanism to ensure it is received?
     
    Thanks again for the insight and the pointer to the race condition draft,
    David Roan

    On Feb 5, 2008 6:07 PM, Paul Kyzivat <pkyzivat@cisco.com> wrote:
    David,

    I think everything you have said is right. These are some very fuzzy areas.

    Note that an *unreliable* provisional response can establish an early
    dialog. But because it is unreliable the UAS can't immediately know if
    the UAC is aware of the dialog.

    It is somewhere between very tricky and impossible to change the target
    during an early dialog. If you haven't found it yet, you should take a
    look at the race-examples draft
    (draft-ietf-sipping-race-examples-04.txt) for more discussion of this
    sort of subtle point.

           Thanks,
           Paul

    David Roan wrote:
    > Thanks to everyone who responded to my earlier query (Target Refresh
    > Request and Contact Header thread).
    >
    > I now have a similar query for establishing the Remote Target. Please
    > forgive the length in advance and feel free to insert corrections/input
    > as necessary.
    >
    >  From section 12.1 of RFC 3261, the following is stated:
    > Within this specification, only 2xx and 101-199 responses with a To tag,
    > where the request was INVITE, will establish a dialog.
    >
    > This seems to indicate that either a 2xx or 101-199 response (with a To
    > tag) to the initial INVITE can establish a dialog (confirmed vs early
    > dialog respectively), correct?
    >
    > Then, from section 12.1.1 of RFC 3261, the following is added about the
    > response that establishes the dialog:
    > When a UAS responds to a request with a response that establishes a
    > dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
    > header field values from the request into the response (including the
    > URIs, URI parameters, and any Record-Route header field parameters,
    > whether they are known or unknown to the UAS) and MUST maintain the
    > order of those values. The UAS MUST add a Contact header field to the
    > response.
    >
    > This seems to indicate that the first 101-199 response sent from the
    > UAS/received at the UAC (with a To Tag) must contain a Contact header
    > (to set the Remote Target at the UAC), correct? So, if the Contact
    > header is not received in this response, this would be considered a
    > violation of the spec and an invalid response, correct? Also, according
    > to the following section (12.1.2), this also sets up the dialog state
    > (items like the route set, if not empty, and the Remote Target).
    >
    > Section 12.2 of RFC 3261 goes into additional details of when the Remote
    > Target can be changed (ie, Remote Target Refresh):
    > Requests within a dialog MAY contain Record-Route and Contact header
    > fields.  However, these requests do not cause the dialog's route set to
    > be modified, although they may modify the remote target URI.
    > Specifically, requests that are not target refresh requests do not
    > modify the dialog's remote target URI, and requests that are target
    > refresh requests do.  For dialogs that have been established with an
    > INVITE, the only target refresh request defined is re-INVITE (see
    > Section 14).  Other extensions may define different target refresh
    > requests for dialogs established in other ways.
    >       Note that an ACK is NOT a target refresh request.
    > Target refresh requests only update the dialog's remote target URI, and
    > not the route set formed from the Record-Route.  Updating the latter
    > would introduce severe backwards compatibility problems with RFC
    > 2543-compliant systems.
    >
    > This seems to indicate that after the 101-199 response is received (that
    > establishes the dialog), only the re-INVITE and its 2xx response and
    > UPDATE (per RFC 3311) and its 2xx response can change the Remote Target.
    > Therefore, if a subsequent provisional response to the INVITE (ie, 180
    > Ringing that followed a 183 Session Progress) is received, it is not
    > allowed to update the Remote Target if it contains a Contact header,
    > correct? What about an UPDATE received in the early dialog state? This
    > would also allow the Remote Target to be updated, correct?
    >
    > Thanks again,
    > David Roan
    >
    >
    > ------------------------------------------------------------------------
    >
    > _______________________________________________
    > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
    > This list is for NEW development of the core SIP Protocol
    > Use sip-implementors@cs.columbia.edu for questions on current sip
    > Use sipping@ietf.org for new developments on the application of sip

    ------=_Part_16845_12650959.1202264821800-- --===============0957482565== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0957482565==-- From sip-bounces@ietf.org Tue Feb 5 19:15:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B4A3A6A2E; Tue, 5 Feb 2008 19:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmZnMkYuM3bG; Tue, 5 Feb 2008 19:15:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DED3A6A07; Tue, 5 Feb 2008 19:15:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337B63A69FB for ; Tue, 5 Feb 2008 19:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOZD-taJvxAT for ; Tue, 5 Feb 2008 19:15:20 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 79F623A69F3 for ; Tue, 5 Feb 2008 19:15:15 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2008 22:16:45 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m163GjET012588; Tue, 5 Feb 2008 22:16:45 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m163GhMR020102; Wed, 6 Feb 2008 03:16:45 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 22:16:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Feb 2008 22:16:41 -0500 Message-ID: <5C5630E45267B642894988A97570D32228D111@xmb-rtp-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Remote Target on Established Dialog and Remote TargetRefresh Thread-Index: AchoZ97IvMeLVwQJQBu3uo520CXmhQABsbWw From: "Sanjay Sinha (sanjsinh)" To: "David Roan" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 06 Feb 2008 03:16:42.0926 (UTC) FILETIME=[B26D54E0:01C8686E] Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Remote Target on Established Dialog and Remote TargetRefresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1661613146==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1661613146== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8686E.B1F6DC22" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8686E.B1F6DC22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This will be an early dialog. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of David Roan Sent: Tuesday, February 05, 2008 9:27 PM To: Paul Kyzivat (pkyzivat) Cc: sip@ietf.org Subject: Re: [Sip] Remote Target on Established Dialog and Remote TargetRefresh =09 =09 Hi Paul, =20 Thanks for the response. =20 So, if the provisional responses are sent reliably, the provisional response would have an acking mechanism similar to the 2xx to ensure the dialog is established (ie, the chance of lost messaging is greatly diminished by the resending of Provisional Responses and the PRACK request), correct? =20 I checked RFC 3262 wrt this and found the following: If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. The provisional response MUST establish a dialog if one is not yet created. =20 This does not really indicate a dialog state, but this would still be an early dialog, right? Or, would it be confirmed since, like the 2xx, there is an ACK mechanism to ensure it is received? =20 Thanks again for the insight and the pointer to the race condition draft, David Roan =09 =09 On Feb 5, 2008 6:07 PM, Paul Kyzivat wrote: =09 David, =09 I think everything you have said is right. These are some very fuzzy areas. =09 Note that an *unreliable* provisional response can establish an early dialog. But because it is unreliable the UAS can't immediately know if the UAC is aware of the dialog. =09 It is somewhere between very tricky and impossible to change the target during an early dialog. If you haven't found it yet, you should take a look at the race-examples draft (draft-ietf-sipping-race-examples-04.txt) for more discussion of this sort of subtle point. =09 Thanks, Paul =09 David Roan wrote: > Thanks to everyone who responded to my earlier query (Target Refresh > Request and Contact Header thread). > > I now have a similar query for establishing the Remote Target. Please > forgive the length in advance and feel free to insert corrections/input > as necessary. > > From section 12.1 of RFC 3261, the following is stated: > Within this specification, only 2xx and 101-199 responses with a To tag, > where the request was INVITE, will establish a dialog. > > This seems to indicate that either a 2xx or 101-199 response (with a To > tag) to the initial INVITE can establish a dialog (confirmed vs early > dialog respectively), correct? > > Then, from section 12.1.1 of RFC 3261, the following is added about the > response that establishes the dialog: > When a UAS responds to a request with a response that establishes a > dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route > header field values from the request into the response (including the > URIs, URI parameters, and any Record-Route header field parameters, > whether they are known or unknown to the UAS) and MUST maintain the > order of those values. The UAS MUST add a Contact header field to the > response. > > This seems to indicate that the first 101-199 response sent from the > UAS/received at the UAC (with a To Tag) must contain a Contact header > (to set the Remote Target at the UAC), correct? So, if the Contact > header is not received in this response, this would be considered a > violation of the spec and an invalid response, correct? Also, according > to the following section (12.1.2), this also sets up the dialog state > (items like the route set, if not empty, and the Remote Target). > > Section 12.2 of RFC 3261 goes into additional details of when the Remote > Target can be changed (ie, Remote Target Refresh): > Requests within a dialog MAY contain Record-Route and Contact header > fields. However, these requests do not cause the dialog's route set to > be modified, although they may modify the remote target URI. > Specifically, requests that are not target refresh requests do not > modify the dialog's remote target URI, and requests that are target > refresh requests do. For dialogs that have been established with an > INVITE, the only target refresh request defined is re-INVITE (see > Section 14). Other extensions may define different target refresh > requests for dialogs established in other ways. > Note that an ACK is NOT a target refresh request. > Target refresh requests only update the dialog's remote target URI, and > not the route set formed from the Record-Route. Updating the latter > would introduce severe backwards compatibility problems with RFC > 2543-compliant systems. > > This seems to indicate that after the 101-199 response is received (that > establishes the dialog), only the re-INVITE and its 2xx response and > UPDATE (per RFC 3311) and its 2xx response can change the Remote Target. > Therefore, if a subsequent provisional response to the INVITE (ie, 180 > Ringing that followed a 183 Session Progress) is received, it is not > allowed to update the Remote Target if it contains a Contact header, > correct? What about an UPDATE received in the early dialog state? This > would also allow the Remote Target to be updated, correct? > > Thanks again, > David Roan > > =09 > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C8686E.B1F6DC22 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    This will be an early = dialog.

    From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of David = Roan
    Sent:=20 Tuesday, February 05, 2008 9:27 PM
    To: Paul Kyzivat=20 (pkyzivat)
    Cc: sip@ietf.org
    Subject: Re: [Sip] = Remote=20 Target on Established Dialog and Remote = TargetRefresh

    Hi Paul,
     
    Thanks for the response.
     
    So, if the provisional responses are sent reliably, the = provisional=20 response would have an acking mechanism similar to the 2xx = to ensure=20 the dialog is established (ie, the chance of lost messaging is greatly = diminished by the resending of Provisional Responses and the PRACK = request),=20 correct?
     
    I checked RFC 3262 wrt this and found the following:
    If a provisional response is received for an initial request, and = that=20 response contains a Require header field containing the option tag = 100rel, the=20 response is to be sent reliably.  If the response is a 100 = (Trying) (as=20 opposed to 101 to 199), this option tag MUST be ignored, and the = procedures=20 below MUST NOT be used.
    The provisional response MUST establish a = dialog if=20 one is not yet created.
     
    This does not really indicate a dialog state, but this = would still=20 be an early dialog, right? Or, would it be confirmed since, like the = 2xx,=20 there is an ACK mechanism to ensure it is received?
     
    Thanks again for the insight and the pointer to the race = condition=20 draft,
    David Roan

    On Feb 5, 2008 6:07 PM, Paul Kyzivat <pkyzivat@cisco.com> = wrote:
    David,

    I=20 think everything you have said is right. These are some very fuzzy=20 areas.

    Note that an *unreliable* provisional response can = establish=20 an early
    dialog. But because it is unreliable the UAS can't = immediately=20 know if
    the UAC is aware of the dialog.

    It is somewhere = between=20 very tricky and impossible to change the target
    during an early = dialog.=20 If you haven't found it yet, you should take a
    look at the = race-examples=20 draft
    (draft-ietf-sipping-race-examples-04.txt) for more = discussion of=20 this
    sort of subtle point.

         =20  Thanks,
           Paul

    David Roan wrote:
    > Thanks to everyone = who=20 responded to my earlier query (Target Refresh
    > Request and = Contact=20 Header thread).
    >
    > I now have a similar query for = establishing=20 the Remote Target. Please
    > forgive the length in advance and = feel=20 free to insert corrections/input
    > as = necessary.
    >
    >=20  From section 12.1 of RFC 3261, the following is = stated:
    > Within=20 this specification, only 2xx and 101-199 responses with a To = tag,
    >=20 where the request was INVITE, will establish a = dialog.
    >
    > This=20 seems to indicate that either a 2xx or 101-199 response (with a = To
    >=20 tag) to the initial INVITE can establish a dialog (confirmed vs=20 early
    > dialog respectively), correct?
    >
    > Then, = from=20 section 12.1.1 of RFC 3261, the following is added about the
    > = response that establishes the dialog:
    > When a UAS responds to = a=20 request with a response that establishes a
    > dialog (such as a = 2xx to=20 INVITE), the UAS MUST copy all Record-Route
    > header field = values from=20 the request into the response (including the
    > URIs, URI = parameters,=20 and any Record-Route header field parameters,
    > whether they = are known=20 or unknown to the UAS) and MUST maintain the
    > order of those = values.=20 The UAS MUST add a Contact header field to the
    >=20 response.
    >
    > This seems to indicate that the first = 101-199=20 response sent from the
    > UAS/received at the UAC (with a To = Tag) must=20 contain a Contact header
    > (to set the Remote Target at the = UAC),=20 correct? So, if the Contact
    > header is not received in this = response,=20 this would be considered a
    > violation of the spec and an = invalid=20 response, correct? Also, according
    > to the following section=20 (12.1.2), this also sets up the dialog state
    > (items like the = route=20 set, if not empty, and the Remote Target).
    >
    > Section = 12.2 of=20 RFC 3261 goes into additional details of when the Remote
    > = Target can=20 be changed (ie, Remote Target Refresh):
    > Requests within a = dialog MAY=20 contain Record-Route and Contact header
    > fields. =  However, these=20 requests do not cause the dialog's route set to
    > be modified, = although they may modify the remote target URI.
    > = Specifically,=20 requests that are not target refresh requests do not
    > modify = the=20 dialog's remote target URI, and requests that are target
    > = refresh=20 requests do.  For dialogs that have been established with = an
    >=20 INVITE, the only target refresh request defined is re-INVITE = (see
    >=20 Section 14).  Other extensions may define different target=20 refresh
    > requests for dialogs established in other = ways.
    >=20       Note that an ACK is NOT a target refresh=20 request.
    > Target refresh requests only update the dialog's = remote=20 target URI, and
    > not the route set formed from the = Record-Route.=20  Updating the latter
    > would introduce severe backwards=20 compatibility problems with RFC
    > 2543-compliant=20 systems.
    >
    > This seems to indicate that after the = 101-199=20 response is received (that
    > establishes the dialog), only the = re-INVITE and its 2xx response and
    > UPDATE (per RFC 3311) and = its 2xx=20 response can change the Remote Target.
    > Therefore, if a = subsequent=20 provisional response to the INVITE (ie, 180
    > Ringing that = followed a=20 183 Session Progress) is received, it is not
    > allowed to = update the=20 Remote Target if it contains a Contact header,
    > correct? What = about=20 an UPDATE received in the early dialog state? This
    > would = also allow=20 the Remote Target to be updated, correct?
    >
    > Thanks=20 again,
    > David Roan
    >
    >
    >=20 = ------------------------------------------------------------------------<= BR>>
    >=20 _______________________________________________
    > Sip mailing = list=20  http://www.ietf.org/mailman/listinfo/sip
    > = This list=20 is for NEW development of the core SIP Protocol
    > Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
    > Use sipping@ietf.org for new = developments on=20 the application of = sip

    ------_=_NextPart_001_01C8686E.B1F6DC22-- --===============1661613146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1661613146==-- From sip-bounces@ietf.org Wed Feb 6 03:08:38 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7FC3A6D00; Wed, 6 Feb 2008 03:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUungMxByUzJ; Wed, 6 Feb 2008 03:08:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B983A6AFA; Wed, 6 Feb 2008 03:08:33 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615F83A6AA3 for ; Wed, 6 Feb 2008 03:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0A44JMPKJIN for ; Wed, 6 Feb 2008 03:08:28 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 87D553A6AFA for ; Wed, 6 Feb 2008 03:08:28 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m16B93p2004629 for ; Wed, 6 Feb 2008 05:09:54 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 05:09:52 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 12:09:48 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 12:09:47 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001BB8A97@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF mailing list problems Thread-index: AchosMkb2PhHWyG3Q7eCaQJtPX3rTA== From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 06 Feb 2008 11:09:48.0552 (UTC) FILETIME=[C9942080:01C868B0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [Sip] IETF mailing list problems X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Because TMDA has been removed from all the IETF lists, SPAM is now making its way through the SIP list. It is clear that the alternative mechanisms are not working effectively. It you fail to receive this message it is because it is too late.... 1) Please check that when you post a message, that it is distributed. You can check the archives to do this at: http://www.ietf.org/mail-archive/web/sip/index.html 2) If you are failing to receive messages from the SIP list, then check whether ietf.org, or any part of it, has been blacklisted by either your local or company SPAM filtering. Any issues, mail ietf-action@ietf.org This is the transition team responsible for these changes. Regards Keith _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 6 04:00:55 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6693A6DD4; Wed, 6 Feb 2008 04:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWa6nDhkfv91; Wed, 6 Feb 2008 04:00:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A623A6FDA; Wed, 6 Feb 2008 03:58:07 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DE13A6F1C for ; Wed, 6 Feb 2008 03:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3AJMgoDKg6M for ; Wed, 6 Feb 2008 03:58:06 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id B06673A6FDA for ; Wed, 6 Feb 2008 03:56:19 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m16Bvc98017776 for ; Wed, 6 Feb 2008 05:57:51 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 05:57:27 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 12:57:24 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 12:57:24 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001BB8ABE@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001BB8A97@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] IETF mailing list problems Thread-index: AchosMkb2PhHWyG3Q7eCaQJtPX3rTAABl7YQ References: <5D1A7985295922448D5550C94DE2918001BB8A97@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 06 Feb 2008 11:57:24.0926 (UTC) FILETIME=[701C35E0:01C868B7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Sip] IETF mailing list problems X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Further, if you send a message that you think needs to be released from the moderation queue, then send me a mail directly. The moderation queue of the SIP list is now filling up with SPAM messages, and I will probably find it impossible to separate your speck of gold from the crap. Regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Wednesday, February 06, 2008 11:10 AM > To: IETF SIP List > Subject: [Sip] IETF mailing list problems > > Because TMDA has been removed from all the IETF lists, SPAM > is now making its way through the SIP list. It is clear that > the alternative mechanisms are not working effectively. > > It you fail to receive this message it is because it is too late.... > > 1) Please check that when you post a message, that it is > distributed. You can check the archives to do this at: > > http://www.ietf.org/mail-archive/web/sip/index.html > > 2) If you are failing to receive messages from the SIP list, then > check whether ietf.org, or any part of it, has been > blacklisted by either your local or company SPAM filtering. > > Any issues, mail ietf-action@ietf.org > > This is the transition team responsible for these changes. > > Regards > > Keith > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 6 07:20:21 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48173A6EA6; Wed, 6 Feb 2008 07:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=1, IP_NOT_FRIENDLY=0.334] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiGAw7tGAsSZ; Wed, 6 Feb 2008 07:20:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FE83A6CB3; Wed, 6 Feb 2008 07:20:20 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BCC03A6CB3 for ; Wed, 6 Feb 2008 07:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsL+mQNrwbHQ for ; Wed, 6 Feb 2008 07:20:15 -0800 (PST) Received: from web63209.mail.re1.yahoo.com (web63209.mail.re1.yahoo.com [69.147.97.19]) by core3.amsl.com (Postfix) with SMTP id D64853A6C26 for ; Wed, 6 Feb 2008 07:20:14 -0800 (PST) Received: (qmail 39321 invoked by uid 60001); 6 Feb 2008 15:21:46 -0000 X-YMail-OSG: RffxAkEVM1m1M68NUaJIUJVJcPsMJK0YBLZT4KMk Received: from [216.191.234.70] by web63209.mail.re1.yahoo.com via HTTP; Wed, 06 Feb 2008 07:21:46 PST Date: Wed, 6 Feb 2008 07:21:46 -0800 (PST) From: Jerry Yin To: "Vijay K. Gurbani" In-Reply-To: <47A8D818.6040400@alcatel-lucent.com> MIME-Version: 1.0 Message-ID: <487118.39294.qm@web63209.mail.re1.yahoo.com> Cc: IETF SIP List , rohan@ekabal.com, jerry_yin@mitel.com, brett@broadsoft.com Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2015106505==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2015106505== Content-Type: multipart/alternative; boundary="0-39073566-1202311306=:39294" Content-Transfer-Encoding: 8bit --0-39073566-1202311306=:39294 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit "Vijay K. Gurbani" wrote: Jerry Yin wrote: > Hi Rohan and all, Jerry: Thank you for your time reviewing the draft. > I can't find the discussing about the connection reuse when NAT/Firewall > involved. Sorry if it is documented somewhere already. That particular behavior is documented in sip-outbound (see Section 2 of connect-reuse for a reference to the discussion delineating connect-reuse and sip-outbound.) sip-outbound can be accessed from: http://tools.ietf.org/html/draft-ietf-sip-outbound-11 [Jerry Yin] Hi Vijay, thanks for the response. The outbound draft is exactly reuse the client started connection as I indicated in the previous mail. It seems there's an inconsistency between these two drafts. > For the above two reasons, I think it would be better to treat the > TCP/SCTP the same way as the TLS. It would make the design and > implementation simple. The SIP routing behavior would be consistent when > supporting the “connection reuse” draft. > > As the TCP security concerns are discussed in the section 9.3 “*Security > Considerations for the TCP Transport”, *the first 3 attacks can be > prevented by Digest authentications. I can’t figure out what is the last > case all about (Proxy enter an aliasing agreement with downstream > proxy)? If there are services between these two proxies, they will > create connections, one or two, anyway. What are really the concerns here? As it turns out, we are about to release -09 based on the WGLC review in November. Brett and I are trying to close an open issue between us, and once that is done, -09 will be released later this week. -09 provides more succinct reasons why TCP/SCTP cannot be reused and it also shortens considerably Section 9.3 based on the WGLC review feedback. [Jerry Yin] Looking forward to read your new draft. thanks, Jerry Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs --------------------------------- Never miss a thing. Make Yahoo your homepage. --0-39073566-1202311306=:39294 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

    "Vijay K. Gurbani" <vkg@alcatel-lucent.com> wrote:
    Jerry Yin wrote:
    > Hi Rohan and all,

    Jerry: Thank you for your time reviewing the draft.

    > I can't find the discussing about the connection reuse when NAT/Firewall
    > involved. Sorry if it is documented somewhere already.

    That particular behavior is documented in sip-outbound
    (see Section 2 of connect-reuse for a reference to the discussion
    delineating connect-reuse and sip-outbound.) sip-outbound can be
    accessed from: http://tools.ietf.org/html/draft-ietf-sip-outbound-11
     
    [Jerry Yin] Hi Vijay, thanks for the response. The outbound draft is exactly reuse the client started connection as I indicated in the previous mail. It seems there's an inconsistency between these two drafts.

    > For the above two reasons, I think it would be better to treat the
    > TCP/SCTP the same way as the TLS. It would make the design and
    > implementation simple. The SIP routing behavior would be consistent when
    > supporting the “connection reuse” draft.
    >
    > As the TCP security concerns are discussed in the section 9.3 “*Security
    > Considerations for the TCP Transport”, *the first 3 attacks can be
    > prevented by Digest authentications. I can’t figure out what is the last
    > case all about (Proxy enter an aliasing agreement with downstream
    > proxy)? If there are services between these two proxies, they will
    > create connections, one or two, anyway. What are really the concerns here?

    As it turns out, we are about to release -09 based on the WGLC review
    in November. Brett and I are trying to close an open issue between
    us, and once that is done, -09 will be released later this week.
    -09 provides more succinct reasons why TCP/SCTP cannot be reused and
    it also shortens considerably Section 9.3 based on the WGLC review
    feedback.

    [Jerry Yin] Looking forward to read your new draft.
    thanks,
    Jerry
     

    Thanks,

    - vijay
    --
    Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
    2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
    Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
    WWW: http://www.alcatel-lucent.com/bell-labs

    Never miss a thing. Make Yahoo your homepage. --0-39073566-1202311306=:39294-- --===============2015106505== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2015106505==-- From sip-bounces@ietf.org Wed Feb 6 08:54:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9064B3A6FF1; Wed, 6 Feb 2008 08:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkxy2OVnU7Pt; Wed, 6 Feb 2008 08:54:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6459C3A6C5E; Wed, 6 Feb 2008 08:54:26 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D513A6C5E for ; Wed, 6 Feb 2008 08:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUMF51MbFXkl for ; Wed, 6 Feb 2008 08:54:24 -0800 (PST) Received: from out003.iad.hostedmail.net (out003.iad.hostedmail.net [209.225.56.66]) by core3.amsl.com (Postfix) with ESMTP id 95AA13A683D for ; Wed, 6 Feb 2008 08:54:24 -0800 (PST) Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out003.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Feb 2008 11:55:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 11:55:56 -0500 Message-ID: In-Reply-To: <487118.39294.qm@web63209.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-sip-connect-reuse-08 Thread-Index: Acho0/y9DbGnFY0ZRfmYP+/RFE7GbAACyPHA From: "Brett Tate" To: "Jerry Yin" , "Vijay K. Gurbani" X-OriginalArrivalTime: 06 Feb 2008 16:55:55.0073 (UTC) FILETIME=[2363C310:01C868E1] Cc: IETF SIP List , rohan@ekabal.com, jerry_yin@mitel.com Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1841999256==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1841999256== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C868E1.22AB14A6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C868E1.22AB14A6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jerry, =20 Please read the section 2. The NAT/Firewall issues are not to be solved by the reuse draft. =20 Thanks, Brett ________________________________ From: Jerry Yin [mailto:jerry.yin@yahoo.com]=20 Sent: Wednesday, February 06, 2008 10:22 AM To: Vijay K. Gurbani Cc: IETF SIP List; rohan@ekabal.com; Brett Tate; jerry_yin@mitel.com Subject: Re: Comments on draft-ietf-sip-connect-reuse-08 =09 =09 "Vijay K. Gurbani" wrote:=20 Jerry Yin wrote: > Hi Rohan and all, =09 Jerry: Thank you for your time reviewing the draft. =09 > I can't find the discussing about the connection reuse when NAT/Firewall=20 > involved. Sorry if it is documented somewhere already. =09 That particular behavior is documented in sip-outbound (see Section 2 of connect-reuse for a reference to the discussion delineating connect-reuse and sip-outbound.) sip-outbound can be accessed from: http://tools.ietf.org/html/draft-ietf-sip-outbound-11 =09 =20 [Jerry Yin] Hi Vijay, thanks for the response. The outbound draft is exactly reuse the client started connection as I indicated in the previous mail. It seems there's an inconsistency between these two drafts. =20 ------_=_NextPart_001_01C868E1.22AB14A6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hi Jerry,
     
    Please read the section 2.  The = NAT/Firewall=20 issues are not to be solved by the reuse draft.
     
    Thanks,
    Brett

    From: Jerry Yin = [mailto:jerry.yin@yahoo.com]=20
    Sent: Wednesday, February 06, 2008 10:22 AM
    To: = Vijay K.=20 Gurbani
    Cc: IETF SIP List; rohan@ekabal.com; Brett Tate;=20 jerry_yin@mitel.com
    Subject: Re: Comments on=20 draft-ietf-sip-connect-reuse-08



    "Vijay K. Gurbani"=20 <vkg@alcatel-lucent.com> wrote:=20
    Jerry Yin wrote:
    > Hi Rohan and all,

    Jerry: Thank = you for=20 your time reviewing the draft.

    > I can't find the = discussing about=20 the connection reuse when NAT/Firewall
    > involved. Sorry if = it is=20 documented somewhere already.

    That particular behavior is = documented=20 in sip-outbound
    (see Section 2 of connect-reuse for a reference = to the=20 discussion
    delineating connect-reuse and sip-outbound.) = sip-outbound can=20 be
    accessed from: http://too= ls.ietf.org/html/draft-ietf-sip-outbound-11
     
    [Jerry Yin] Hi Vijay, thanks for the response. The outbound=20 draft is exactly reuse the client started connection as I = indicated in=20 the previous mail. It seems there's an inconsistency between = these two=20 drafts.

     
    ------_=_NextPart_001_01C868E1.22AB14A6-- --===============1841999256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1841999256==-- From sip-bounces@ietf.org Wed Feb 6 09:08:49 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0443A6DFB; Wed, 6 Feb 2008 09:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKg4ZA47xKnr; Wed, 6 Feb 2008 09:08:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC9C3A6F01; Wed, 6 Feb 2008 09:08:47 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5EB73A6F0B for ; Wed, 6 Feb 2008 09:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53K8VuwoPKEx for ; Wed, 6 Feb 2008 09:08:45 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 59D233A6DFB for ; Wed, 6 Feb 2008 09:08:45 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Feb 2008 12:10:17 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m16HAG9V011018; Wed, 6 Feb 2008 12:10:16 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m16HABMV023531; Wed, 6 Feb 2008 17:10:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 12:10:15 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 12:10:15 -0500 Message-ID: <47A9E9FF.7000601@cisco.com> Date: Wed, 06 Feb 2008 12:10:23 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Roan References: <47A8FA38.1080200@cisco.com> In-Reply-To: X-OriginalArrivalTime: 06 Feb 2008 17:10:15.0657 (UTC) FILETIME=[24567590:01C868E3] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Remote Target on Established Dialog and Remote Target Refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org David Roan wrote: > Hi Paul, > > Thanks for the response. > > So, if the provisional responses are sent reliably, the provisional > response would have an acking mechanism similar to the 2xx to ensure the > dialog is established (ie, the chance of lost messaging is greatly > diminished by the resending of Provisional Responses and the PRACK > request), correct? Right. 3261 is very carefully worded, because it only provides one way of establishing a dialog, and doesn't include reliable provisionals, but the specs for reliable provisionals were progressed in parallal so 3261 "left room" for them as well as for other ways of establishing a dialog (like SUB/NOT). > I checked RFC 3262 wrt this and found the following: > If a provisional response is received for an initial request, and that > response contains a Require header field containing the option tag > 100rel, the response is to be sent reliably. If the response is a 100 > (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, > and the procedures below MUST NOT be used. > The provisional response MUST establish a dialog if one is not yet created. > > This does not really indicate a dialog state, but this would still be an > early dialog, right? Or, would it be confirmed since, like the 2xx, > there is an ACK mechanism to ensure it is received? It is still an early dialog, but its a way of *knowing* you have one. Thanks, Paul > Thanks again for the insight and the pointer to the race condition draft, > David Roan > > On Feb 5, 2008 6:07 PM, Paul Kyzivat > wrote: > > David, > > I think everything you have said is right. These are some very fuzzy > areas. > > Note that an *unreliable* provisional response can establish an early > dialog. But because it is unreliable the UAS can't immediately know if > the UAC is aware of the dialog. > > It is somewhere between very tricky and impossible to change the target > during an early dialog. If you haven't found it yet, you should take a > look at the race-examples draft > (draft-ietf-sipping-race-examples-04.txt) for more discussion of this > sort of subtle point. > > Thanks, > Paul > > David Roan wrote: > > Thanks to everyone who responded to my earlier query (Target Refresh > > Request and Contact Header thread). > > > > I now have a similar query for establishing the Remote Target. Please > > forgive the length in advance and feel free to insert > corrections/input > > as necessary. > > > > From section 12.1 of RFC 3261, the following is stated: > > Within this specification, only 2xx and 101-199 responses with a > To tag, > > where the request was INVITE, will establish a dialog. > > > > This seems to indicate that either a 2xx or 101-199 response > (with a To > > tag) to the initial INVITE can establish a dialog (confirmed vs early > > dialog respectively), correct? > > > > Then, from section 12.1.1 of RFC 3261, the following is added > about the > > response that establishes the dialog: > > When a UAS responds to a request with a response that establishes a > > dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route > > header field values from the request into the response (including the > > URIs, URI parameters, and any Record-Route header field parameters, > > whether they are known or unknown to the UAS) and MUST maintain the > > order of those values. The UAS MUST add a Contact header field to the > > response. > > > > This seems to indicate that the first 101-199 response sent from the > > UAS/received at the UAC (with a To Tag) must contain a Contact header > > (to set the Remote Target at the UAC), correct? So, if the Contact > > header is not received in this response, this would be considered a > > violation of the spec and an invalid response, correct? Also, > according > > to the following section (12.1.2), this also sets up the dialog state > > (items like the route set, if not empty, and the Remote Target). > > > > Section 12.2 of RFC 3261 goes into additional details of when the > Remote > > Target can be changed (ie, Remote Target Refresh): > > Requests within a dialog MAY contain Record-Route and Contact header > > fields. However, these requests do not cause the dialog's route > set to > > be modified, although they may modify the remote target URI. > > Specifically, requests that are not target refresh requests do not > > modify the dialog's remote target URI, and requests that are target > > refresh requests do. For dialogs that have been established with an > > INVITE, the only target refresh request defined is re-INVITE (see > > Section 14). Other extensions may define different target refresh > > requests for dialogs established in other ways. > > Note that an ACK is NOT a target refresh request. > > Target refresh requests only update the dialog's remote target > URI, and > > not the route set formed from the Record-Route. Updating the latter > > would introduce severe backwards compatibility problems with RFC > > 2543-compliant systems. > > > > This seems to indicate that after the 101-199 response is > received (that > > establishes the dialog), only the re-INVITE and its 2xx response and > > UPDATE (per RFC 3311) and its 2xx response can change the Remote > Target. > > Therefore, if a subsequent provisional response to the INVITE > (ie, 180 > > Ringing that followed a 183 Session Progress) is received, it is not > > allowed to update the Remote Target if it contains a Contact header, > > correct? What about an UPDATE received in the early dialog state? > This > > would also allow the Remote Target to be updated, correct? > > > > Thanks again, > > David Roan > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu > for questions on current sip > > Use sipping@ietf.org for new > developments on the application of sip > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 6 09:47:30 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA293A7029; Wed, 6 Feb 2008 09:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM3xB2FYgfn1; Wed, 6 Feb 2008 09:47:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2DE3A7062; Wed, 6 Feb 2008 09:47:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DCC3A6DFB for ; Wed, 6 Feb 2008 09:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n-z67EvuRDp for ; Wed, 6 Feb 2008 09:47:17 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4F3AF3A7044 for ; Wed, 6 Feb 2008 09:46:23 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C6EF7208AA; Wed, 6 Feb 2008 18:47:51 +0100 (CET) X-AuditID: c1b4fb3c-ab2eebb0000007e0-de-47a9f2c71f86 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A63CC2086F; Wed, 6 Feb 2008 18:47:51 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 18:47:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 18:47:49 +0100 Message-ID: In-Reply-To: <47A9E9FF.7000601@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Remote Target on Established Dialog and Remote TargetRefresh thread-index: Acho4znburwUOhgaRO+iNSPYzn5FZAABFqUw References: <47A8FA38.1080200@cisco.com> <47A9E9FF.7000601@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "David Roan" X-OriginalArrivalTime: 06 Feb 2008 17:47:50.0381 (UTC) FILETIME=[644209D0:01C868E8] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Remote Target on Established Dialog and Remote TargetRefresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >>So, if the provisional responses are sent reliably, the provisional >>response would have an acking mechanism similar to the 2xx to ensure >>the dialog is established (ie, the chance of lost messaging is greatly >>diminished by the resending of Provisional Responses and the PRACK >>request), correct? > >Right. > >3261 is very carefully worded, because it only provides one >way of establishing a dialog, and doesn't include reliable >provisionals, but the specs for reliable provisionals were >progressed in parallal so 3261 "left room" for them as well >as for other ways of establishing a dialog (like SUB/NOT). Even if you don't use PRACK, I guess any other mid-dialog request from the UAC to the UAS would also "indication" that the early dialog has been established. However, that does NOT mean that any SDP previously sent in an unreliable 18x would be regarded as an offer/answer. Also, regarding Paul's earlier comment that a target cannot be updated during the early dialog. It is possible using UPDATE, isn't it (yes, I agree with possible race condition issues)? Regards, Christer >>I checked RFC 3262 wrt this and found the following: >>If a provisional response is received for an initial >>request, and that response contains a Require header field containing the option tag >>100rel, the response is to be sent reliably. If the response is a 100 >>(Trying) (as opposed to 101 to 199), this option tag MUST be ignored, >>and the procedures below MUST NOT be used. >>The provisional response MUST establish a dialog if one is not yet created. >> >>This does not really indicate a dialog state, but this would still be >>an early dialog, right? Or, would it be confirmed since, like the 2xx, >>there is an ACK mechanism to ensure it is received? > >It is still an early dialog, but its a way of *knowing* you have one. > > Thanks, > Paul > > > Thanks again for the insight and the pointer to the race condition > > draft, David Roan > > > > On Feb 5, 2008 6:07 PM, Paul Kyzivat > > wrote: > > > > David, > > > > I think everything you have said is right. These are > some very fuzzy > > areas. > > > > Note that an *unreliable* provisional response can > establish an early > > dialog. But because it is unreliable the UAS can't > immediately know if > > the UAC is aware of the dialog. > > > > It is somewhere between very tricky and impossible to > change the target > > during an early dialog. If you haven't found it yet, > you should take a > > look at the race-examples draft > > (draft-ietf-sipping-race-examples-04.txt) for more > discussion of this > > sort of subtle point. > > > > Thanks, > > Paul > > > > David Roan wrote: > > > Thanks to everyone who responded to my earlier query > (Target Refresh > > > Request and Contact Header thread). > > > > > > I now have a similar query for establishing the > Remote Target. Please > > > forgive the length in advance and feel free to insert > > corrections/input > > > as necessary. > > > > > > From section 12.1 of RFC 3261, the following is stated: > > > Within this specification, only 2xx and 101-199 > responses with a > > To tag, > > > where the request was INVITE, will establish a dialog. > > > > > > This seems to indicate that either a 2xx or 101-199 response > > (with a To > > > tag) to the initial INVITE can establish a dialog > (confirmed vs early > > > dialog respectively), correct? > > > > > > Then, from section 12.1.1 of RFC 3261, the following is added > > about the > > > response that establishes the dialog: > > > When a UAS responds to a request with a response > that establishes a > > > dialog (such as a 2xx to INVITE), the UAS MUST copy > all Record-Route > > > header field values from the request into the > response (including the > > > URIs, URI parameters, and any Record-Route header > field parameters, > > > whether they are known or unknown to the UAS) and > MUST maintain the > > > order of those values. The UAS MUST add a Contact > header field to the > > > response. > > > > > > This seems to indicate that the first 101-199 > response sent from the > > > UAS/received at the UAC (with a To Tag) must contain > a Contact header > > > (to set the Remote Target at the UAC), correct? So, > if the Contact > > > header is not received in this response, this would > be considered a > > > violation of the spec and an invalid response, correct? Also, > > according > > > to the following section (12.1.2), this also sets up > the dialog state > > > (items like the route set, if not empty, and the > Remote Target). > > > > > > Section 12.2 of RFC 3261 goes into additional > details of when the > > Remote > > > Target can be changed (ie, Remote Target Refresh): > > > Requests within a dialog MAY contain Record-Route > and Contact header > > > fields. However, these requests do not cause the > dialog's route > > set to > > > be modified, although they may modify the remote target URI. > > > Specifically, requests that are not target refresh > requests do not > > > modify the dialog's remote target URI, and requests > that are target > > > refresh requests do. For dialogs that have been > established with an > > > INVITE, the only target refresh request defined is > re-INVITE (see > > > Section 14). Other extensions may define different > target refresh > > > requests for dialogs established in other ways. > > > Note that an ACK is NOT a target refresh request. > > > Target refresh requests only update the dialog's > remote target > > URI, and > > > not the route set formed from the Record-Route. > Updating the latter > > > would introduce severe backwards compatibility > problems with RFC > > > 2543-compliant systems. > > > > > > This seems to indicate that after the 101-199 response is > > received (that > > > establishes the dialog), only the re-INVITE and its > 2xx response and > > > UPDATE (per RFC 3311) and its 2xx response can > change the Remote > > Target. > > > Therefore, if a subsequent provisional response to the INVITE > > (ie, 180 > > > Ringing that followed a 183 Session Progress) is > received, it is not > > > allowed to update the Remote Target if it contains a > Contact header, > > > correct? What about an UPDATE received in the early > dialog state? > > This > > > would also allow the Remote Target to be updated, correct? > > > > > > Thanks again, > > > David Roan > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu > > for questions > on current sip > > > Use sipping@ietf.org for new > > developments on the application of sip > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 6 10:03:04 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29733A70FE; Wed, 6 Feb 2008 10:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5xrZH5k4C7k; Wed, 6 Feb 2008 10:03:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A1B3A6FF6; Wed, 6 Feb 2008 10:02:58 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67FB3A6928 for ; Wed, 6 Feb 2008 10:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1Qpilws632n for ; Wed, 6 Feb 2008 10:02:55 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E7F923A7032 for ; Wed, 6 Feb 2008 10:01:48 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Feb 2008 10:03:20 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m16I3KWx018667; Wed, 6 Feb 2008 10:03:20 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m16I3CHp025507; Wed, 6 Feb 2008 18:03:20 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 13:03:05 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 13:03:05 -0500 Message-ID: <47A9F660.8000502@cisco.com> Date: Wed, 06 Feb 2008 13:03:12 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg References: <47A8FA38.1080200@cisco.com> <47A9E9FF.7000601@cisco.com> In-Reply-To: X-OriginalArrivalTime: 06 Feb 2008 18:03:05.0237 (UTC) FILETIME=[858DFC50:01C868EA] Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Remote Target on Established Dialog and Remote TargetRefresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >>> So, if the provisional responses are sent reliably, the provisional >>> response would have an acking mechanism similar to the 2xx to ensure >>> the dialog is established (ie, the chance of lost messaging is greatly > >>> diminished by the resending of Provisional Responses and the PRACK >>> request), correct? >> Right. >> >> 3261 is very carefully worded, because it only provides one >> way of establishing a dialog, and doesn't include reliable >> provisionals, but the specs for reliable provisionals were >> progressed in parallal so 3261 "left room" for them as well >> as for other ways of establishing a dialog (like SUB/NOT). > > Even if you don't use PRACK, I guess any other mid-dialog request from > the UAC to the UAS would also "indication" that the early dialog has > been established. Yes, I think an intelligent UA can infer that receipt of an in-dialog request implies that the other end knows of the dialog. I am however unaware of any normative language about this. As a result YMMV when attempting such usage. > However, that does NOT mean that any SDP previously sent in an > unreliable 18x would be regarded as an offer/answer. I'm not certain what you are saying. To paraphrase what I think you might mean: A new offer MUST NOT be sent within an early dialog that has not been confirmed with reliable response. > Also, regarding Paul's earlier comment that a target cannot be updated > during the early dialog. It is possible using UPDATE, isn't it (yes, I > agree with possible race condition issues)? The mechanisms are there to refresh the target, but are fraught with race conditions to the point that it is unwise to attempt. Paul > Regards, > > Christer > > > > > > > >>> I checked RFC 3262 wrt this and found the following: >>> If a provisional response is received for an initial >>> request, and that response contains a Require header field containing > the option tag >>> 100rel, the response is to be sent reliably. If the response is a 100 >>> (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, >>> and the procedures below MUST NOT be used. >>> The provisional response MUST establish a dialog if one is not yet > created. >>> >>> This does not really indicate a dialog state, but this would still be >>> an early dialog, right? Or, would it be confirmed since, like the 2xx, > >>> there is an ACK mechanism to ensure it is received? >> It is still an early dialog, but its a way of *knowing* you have one. >> >> Thanks, >> Paul >> >>> Thanks again for the insight and the pointer to the race condition >>> draft, David Roan >>> >>> On Feb 5, 2008 6:07 PM, Paul Kyzivat >> > wrote: >>> >>> David, >>> >>> I think everything you have said is right. These are >> some very fuzzy >>> areas. >>> >>> Note that an *unreliable* provisional response can >> establish an early >>> dialog. But because it is unreliable the UAS can't >> immediately know if >>> the UAC is aware of the dialog. >>> >>> It is somewhere between very tricky and impossible to >> change the target >>> during an early dialog. If you haven't found it yet, >> you should take a >>> look at the race-examples draft >>> (draft-ietf-sipping-race-examples-04.txt) for more >> discussion of this >>> sort of subtle point. >>> >>> Thanks, >>> Paul >>> >>> David Roan wrote: >>> > Thanks to everyone who responded to my earlier query >> (Target Refresh >>> > Request and Contact Header thread). >>> > >>> > I now have a similar query for establishing the >> Remote Target. Please >>> > forgive the length in advance and feel free to insert >>> corrections/input >>> > as necessary. >>> > >>> > From section 12.1 of RFC 3261, the following is stated: >>> > Within this specification, only 2xx and 101-199 >> responses with a >>> To tag, >>> > where the request was INVITE, will establish a dialog. >>> > >>> > This seems to indicate that either a 2xx or 101-199 response >>> (with a To >>> > tag) to the initial INVITE can establish a dialog >> (confirmed vs early >>> > dialog respectively), correct? >>> > >>> > Then, from section 12.1.1 of RFC 3261, the following is added >>> about the >>> > response that establishes the dialog: >>> > When a UAS responds to a request with a response >> that establishes a >>> > dialog (such as a 2xx to INVITE), the UAS MUST copy >> all Record-Route >>> > header field values from the request into the >> response (including the >>> > URIs, URI parameters, and any Record-Route header >> field parameters, >>> > whether they are known or unknown to the UAS) and >> MUST maintain the >>> > order of those values. The UAS MUST add a Contact >> header field to the >>> > response. >>> > >>> > This seems to indicate that the first 101-199 >> response sent from the >>> > UAS/received at the UAC (with a To Tag) must contain >> a Contact header >>> > (to set the Remote Target at the UAC), correct? So, >> if the Contact >>> > header is not received in this response, this would >> be considered a >>> > violation of the spec and an invalid response, correct? Also, >>> according >>> > to the following section (12.1.2), this also sets up >> the dialog state >>> > (items like the route set, if not empty, and the >> Remote Target). >>> > >>> > Section 12.2 of RFC 3261 goes into additional >> details of when the >>> Remote >>> > Target can be changed (ie, Remote Target Refresh): >>> > Requests within a dialog MAY contain Record-Route >> and Contact header >>> > fields. However, these requests do not cause the >> dialog's route >>> set to >>> > be modified, although they may modify the remote target URI. >>> > Specifically, requests that are not target refresh >> requests do not >>> > modify the dialog's remote target URI, and requests >> that are target >>> > refresh requests do. For dialogs that have been >> established with an >>> > INVITE, the only target refresh request defined is >> re-INVITE (see >>> > Section 14). Other extensions may define different >> target refresh >>> > requests for dialogs established in other ways. >>> > Note that an ACK is NOT a target refresh request. >>> > Target refresh requests only update the dialog's >> remote target >>> URI, and >>> > not the route set formed from the Record-Route. >> Updating the latter >>> > would introduce severe backwards compatibility >> problems with RFC >>> > 2543-compliant systems. >>> > >>> > This seems to indicate that after the 101-199 response is >>> received (that >>> > establishes the dialog), only the re-INVITE and its >> 2xx response and >>> > UPDATE (per RFC 3311) and its 2xx response can >> change the Remote >>> Target. >>> > Therefore, if a subsequent provisional response to the INVITE >>> (ie, 180 >>> > Ringing that followed a 183 Session Progress) is >> received, it is not >>> > allowed to update the Remote Target if it contains a >> Contact header, >>> > correct? What about an UPDATE received in the early >> dialog state? >>> This >>> > would also allow the Remote Target to be updated, correct? >>> > >>> > Thanks again, >>> > David Roan >>> > >>> > >>> > >>> >> -------------------------------------------------------------- >> ---------- >>> > >>> > _______________________________________________ >>> > Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>> > This list is for NEW development of the core SIP Protocol >>> > Use sip-implementors@cs.columbia.edu >>> for questions >> on current sip >>> > Use sipping@ietf.org for new >>> developments on the application of sip >>> >>> >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 6 10:09:21 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AC03A6FF6; Wed, 6 Feb 2008 10:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5PacD2xW+ni; Wed, 6 Feb 2008 10:09:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0BE3A6D92; Wed, 6 Feb 2008 10:09:20 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161093A6D92 for ; Wed, 6 Feb 2008 10:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgciMy4W9krA for ; Wed, 6 Feb 2008 10:09:15 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E3D543A6D82 for ; Wed, 6 Feb 2008 10:09:14 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F112020A4A; Wed, 6 Feb 2008 19:10:44 +0100 (CET) X-AuditID: c1b4fb3c-aaaedbb0000007e0-9e-47a9f824e581 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 189D920833; Wed, 6 Feb 2008 19:10:44 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 19:10:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 19:10:42 +0100 Message-ID: In-Reply-To: <47A9F660.8000502@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Remote Target on Established Dialog and Remote TargetRefresh thread-index: Acho6pJ/j34sy/5fQ7Op74o/tqoOowAACKtw References: <47A8FA38.1080200@cisco.com> <47A9E9FF.7000601@cisco.com> <47A9F660.8000502@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 06 Feb 2008 18:10:43.0665 (UTC) FILETIME=[96CC8C10:01C868EB] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Remote Target on Established Dialog and Remote TargetRefresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >>>>So, if the provisional responses are sent reliably, the provisional >>>>response would have an acking mechanism similar to the 2xx to ensure >>>>the dialog is established (ie, the chance of lost messaging is >>>>greatly diminished by the resending of Provisional Responses and >>>>the PRACK request), correct? >>>Right. >>> >>>3261 is very carefully worded, because it only provides one way of >>>establishing a dialog, and doesn't include reliable provisionals, but >>>the specs for reliable provisionals were progressed in parallal so >>>3261 "left room" for them as well as for other ways of establishing a >>>dialog (like SUB/NOT). >> >>Even if you don't use PRACK, I guess any other mid-dialog >>request from the UAC to the UAS would also "indication" that the early >>dialog has been established. > >Yes, I think an intelligent UA can infer that receipt of an >in-dialog request implies that the other end knows of the >dialog. I am however unaware of any normative language about >this. As a result YMMV when attempting such usage. I am not sure whether we would need any extra text: the 18x creates the early dialog (as far as the UAC is concerned), and on early dialogs you can send mid-dialog requests. Now, whether all implementations out there work that way I don't know :) >>However, that does NOT mean that any SDP previously sent in an >>unreliable 18x would be regarded as an offer/answer. > >I'm not certain what you are saying. To paraphrase what I >think you might mean: > >A new offer MUST NOT be sent within an early dialog that has >not been confirmed with reliable response. Correct. And, an SDP that was sent unreliably is NOT an answer (or offer) even if mid-dialog requests has been received from the UAC after that. Regards, Christer >>Also, regarding Paul's earlier comment that a target cannot be updated >>during the early dialog. It is possible using UPDATE, isn't it (yes, I >>agree with possible race condition issues)? > >The mechanisms are there to refresh the target, but are >fraught with race conditions to the point that it is unwise >to attempt. > > Paul > > > Regards, > > > > Christer > > > > > > > > > > > > > > > >>> I checked RFC 3262 wrt this and found the following: > >>> If a provisional response is received for an initial request, and > >>> that response contains a Require header field containing > > the option tag > >>> 100rel, the response is to be sent reliably. If the > response is a > >>> 100 > >>> (Trying) (as opposed to 101 to 199), this option tag MUST be > >>> ignored, and the procedures below MUST NOT be used. > >>> The provisional response MUST establish a dialog if one is not yet > > created. > >>> > >>> This does not really indicate a dialog state, but this > would still > >>> be an early dialog, right? Or, would it be confirmed > since, like the > >>> 2xx, > > > >>> there is an ACK mechanism to ensure it is received? > >> It is still an early dialog, but its a way of *knowing* > you have one. > >> > >> Thanks, > >> Paul > >> > >>> Thanks again for the insight and the pointer to the race > condition > >>> draft, David Roan > >>> > >>> On Feb 5, 2008 6:07 PM, Paul Kyzivat >>> > wrote: > >>> > >>> David, > >>> > >>> I think everything you have said is right. These are > >> some very fuzzy > >>> areas. > >>> > >>> Note that an *unreliable* provisional response can > >> establish an early > >>> dialog. But because it is unreliable the UAS can't > >> immediately know if > >>> the UAC is aware of the dialog. > >>> > >>> It is somewhere between very tricky and impossible to > >> change the target > >>> during an early dialog. If you haven't found it yet, > >> you should take a > >>> look at the race-examples draft > >>> (draft-ietf-sipping-race-examples-04.txt) for more > >> discussion of this > >>> sort of subtle point. > >>> > >>> Thanks, > >>> Paul > >>> > >>> David Roan wrote: > >>> > Thanks to everyone who responded to my earlier query > >> (Target Refresh > >>> > Request and Contact Header thread). > >>> > > >>> > I now have a similar query for establishing the > >> Remote Target. Please > >>> > forgive the length in advance and feel free to insert > >>> corrections/input > >>> > as necessary. > >>> > > >>> > From section 12.1 of RFC 3261, the following is stated: > >>> > Within this specification, only 2xx and 101-199 > >> responses with a > >>> To tag, > >>> > where the request was INVITE, will establish a dialog. > >>> > > >>> > This seems to indicate that either a 2xx or > 101-199 response > >>> (with a To > >>> > tag) to the initial INVITE can establish a dialog > >> (confirmed vs early > >>> > dialog respectively), correct? > >>> > > >>> > Then, from section 12.1.1 of RFC 3261, the > following is added > >>> about the > >>> > response that establishes the dialog: > >>> > When a UAS responds to a request with a response > >> that establishes a > >>> > dialog (such as a 2xx to INVITE), the UAS MUST copy > >> all Record-Route > >>> > header field values from the request into the > >> response (including the > >>> > URIs, URI parameters, and any Record-Route header > >> field parameters, > >>> > whether they are known or unknown to the UAS) and > >> MUST maintain the > >>> > order of those values. The UAS MUST add a Contact > >> header field to the > >>> > response. > >>> > > >>> > This seems to indicate that the first 101-199 > >> response sent from the > >>> > UAS/received at the UAC (with a To Tag) must contain > >> a Contact header > >>> > (to set the Remote Target at the UAC), correct? So, > >> if the Contact > >>> > header is not received in this response, this would > >> be considered a > >>> > violation of the spec and an invalid response, > correct? Also, > >>> according > >>> > to the following section (12.1.2), this also sets up > >> the dialog state > >>> > (items like the route set, if not empty, and the > >> Remote Target). > >>> > > >>> > Section 12.2 of RFC 3261 goes into additional > >> details of when the > >>> Remote > >>> > Target can be changed (ie, Remote Target Refresh): > >>> > Requests within a dialog MAY contain Record-Route > >> and Contact header > >>> > fields. However, these requests do not cause the > >> dialog's route > >>> set to > >>> > be modified, although they may modify the remote > target URI. > >>> > Specifically, requests that are not target refresh > >> requests do not > >>> > modify the dialog's remote target URI, and requests > >> that are target > >>> > refresh requests do. For dialogs that have been > >> established with an > >>> > INVITE, the only target refresh request defined is > >> re-INVITE (see > >>> > Section 14). Other extensions may define different > >> target refresh > >>> > requests for dialogs established in other ways. > >>> > Note that an ACK is NOT a target refresh request. > >>> > Target refresh requests only update the dialog's > >> remote target > >>> URI, and > >>> > not the route set formed from the Record-Route. > >> Updating the latter > >>> > would introduce severe backwards compatibility > >> problems with RFC > >>> > 2543-compliant systems. > >>> > > >>> > This seems to indicate that after the 101-199 response is > >>> received (that > >>> > establishes the dialog), only the re-INVITE and its > >> 2xx response and > >>> > UPDATE (per RFC 3311) and its 2xx response can > >> change the Remote > >>> Target. > >>> > Therefore, if a subsequent provisional response to > the INVITE > >>> (ie, 180 > >>> > Ringing that followed a 183 Session Progress) is > >> received, it is not > >>> > allowed to update the Remote Target if it contains a > >> Contact header, > >>> > correct? What about an UPDATE received in the early > >> dialog state? > >>> This > >>> > would also allow the Remote Target to be updated, correct? > >>> > > >>> > Thanks again, > >>> > David Roan > >>> > > >>> > > >>> > > >>> > >> -------------------------------------------------------------- > >> ---------- > >>> > > >>> > _______________________________________________ > >>> > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >>> > This list is for NEW development of the core SIP Protocol > >>> > Use sip-implementors@cs.columbia.edu > >>> for questions > >> on current sip > >>> > Use sipping@ietf.org for new > >>> developments on the application of sip > >>> > >>> > >> _______________________________________________ > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu for questions on current sip Use > >> sipping@ietf.org for new developments on the application of sip > >> > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 6 10:11:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6310E3A6F86; Wed, 6 Feb 2008 10:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTGOye2HQcv2; Wed, 6 Feb 2008 10:11:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BD83A6E2C; Wed, 6 Feb 2008 10:11:31 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558923A6E2C for ; Wed, 6 Feb 2008 10:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM9Z8bXG4OaP for ; Wed, 6 Feb 2008 10:11:29 -0800 (PST) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id BFEA33A6D92 for ; Wed, 6 Feb 2008 10:11:28 -0800 (PST) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id mHNf1Y00p0cQ2SLA203f00; Wed, 06 Feb 2008 18:12:53 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id mJCw1Y00D0umElk8W00000; Wed, 06 Feb 2008 18:12:58 +0000 X-Authority-Analysis: v=1.0 c=1 a=UKm78YyBX8EA:10 a=yfPBi_U9inc-uEEqnpMA:9 a=xknArUecRM-WyMKoZtcA:7 a=WJ__12JQvysSf5bdo85PAaawoVEA:4 a=MSl-tDqOz04A:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m16ICu07026880 for ; Wed, 6 Feb 2008 13:12:56 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m16ICu8w026876; Wed, 6 Feb 2008 13:12:56 -0500 Date: Wed, 6 Feb 2008 13:12:56 -0500 Message-Id: <200802061812.m16ICu8w026876@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (j.d.roan@gmail.com) References: Subject: Re: [Sip] Remote Target on Established Dialog and Remote Target Refresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "David Roan" This seems to indicate that after the 101-199 response is received (that establishes the dialog), only the re-INVITE and its 2xx response and UPDATE (per RFC 3311) and its 2xx response can change the Remote Target. Therefore, if a subsequent provisional response to the INVITE (ie, 180 Ringing that followed a 183 Session Progress) is received, it is not allowed to update the Remote Target if it contains a Contact header, correct? Everything you say is correct, as far as I know. But there is one treacherous point that many phones do not get right: If a 1xx is received, it establishes an early dialog, and sets the remote target. If a second 1xx is received *with a different to-tag*, it establishes *another* early dialog, and sets the remote target of that dialog. Thus, the remote targets in the two 1xx responses are entirely unconnected. Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From loc706@acm.org Wed Feb 6 10:42:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22EA3A6DC1 for ; Wed, 6 Feb 2008 10:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.381 X-Spam-Level: X-Spam-Status: No, score=-73.381 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_MISMATCH_NET=0.611, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, TVD_RCVD_IP=1.931, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9JpHUAcM10A for ; Wed, 6 Feb 2008 10:42:48 -0800 (PST) Received: from 64-190-179-130.static.cypresscom.net (unknown [64.190.179.130]) by core3.amsl.com (Postfix) with SMTP id D58203A6EC6 for ; Wed, 6 Feb 2008 10:42:47 -0800 (PST) Received: from gzfku ([41.117.85.222]) by 64-190-179-130.static.cypresscom.net (8.13.3/8.13.3) with SMTP id m16IeLH8057813; Wed, 6 Feb 2008 12:40:21 -0600 Message-ID: <47A9FEE9.7030400@acm.org> Date: Wed, 6 Feb 2008 12:39:37 -0600 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sip-archive@ietf.org Subject: A Is For Attitude Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Why I Love You http://71.137.248.213/ From sip-bounces@ietf.org Wed Feb 6 11:40:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437B63A6F76; Wed, 6 Feb 2008 11:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHRsqFP5xiJT; Wed, 6 Feb 2008 11:40:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4E23A6D2E; Wed, 6 Feb 2008 11:40:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39F73A6D5F for ; Wed, 6 Feb 2008 11:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5vBAAGjRwz9 for ; Wed, 6 Feb 2008 11:40:31 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 89A3D3A6E2C for ; Wed, 6 Feb 2008 11:40:31 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Feb 2008 14:42:03 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m16Jg2NQ002136; Wed, 6 Feb 2008 14:42:02 -0500 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 m16JfvR2024728; Wed, 6 Feb 2008 19:41:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 14:41:57 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 14:41:56 -0500 Message-ID: <47AA0D8C.3080006@cisco.com> Date: Wed, 06 Feb 2008 14:42:04 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg References: <47A8FA38.1080200@cisco.com> <47A9E9FF.7000601@cisco.com> <47A9F660.8000502@cisco.com> In-Reply-To: X-OriginalArrivalTime: 06 Feb 2008 19:41:56.0570 (UTC) FILETIME=[54E793A0:01C868F8] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Remote Target on Established Dialog and Remote TargetRefresh X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Paul Christer Holmberg wrote: > Hi, > >>>>> So, if the provisional responses are sent reliably, the provisional >>>>> response would have an acking mechanism similar to the 2xx to ensure > >>>>> the dialog is established (ie, the chance of lost messaging is >>>>> greatly diminished by the resending of Provisional Responses and >>>>> the PRACK request), correct? >>>> Right. >>>> >>>> 3261 is very carefully worded, because it only provides one way of >>>> establishing a dialog, and doesn't include reliable provisionals, but > >>>> the specs for reliable provisionals were progressed in parallal so >>>> 3261 "left room" for them as well as for other ways of establishing a > >>>> dialog (like SUB/NOT). >>> Even if you don't use PRACK, I guess any other mid-dialog >>> request from the UAC to the UAS would also "indication" that the early > >>> dialog has been established. >> Yes, I think an intelligent UA can infer that receipt of an >> in-dialog request implies that the other end knows of the >> dialog. I am however unaware of any normative language about >> this. As a result YMMV when attempting such usage. > > I am not sure whether we would need any extra text: the 18x creates the > early dialog (as far as the UAC is concerned), and on early dialogs you > can send mid-dialog requests. That works for the UAC. The UAS sent the 1xx and thinks there is an early dialog, and the UAC received it and agrees, so it can send a new request in-dialog. The problem is for the UAS. It has *sent* the 1xx with to-tag so it thinks there is a dialog, but the UAC may never receive it. Now if the UAS sends an in-dialog request, it is a *bit* of a stretch to assume the UAC will be prepared to receive and handle it. This *is* discussed in the race-examples draft. The assumption is that the UAC *ought* to make this inference, but there may be no normative support for it. The exception is for SUB/NOT, where there is a requirement to handle a NOTIFY where no dialog has yet been established. This is a very similar case. > Now, whether all implementations out there work that way I don't know :) Yes, that *is* the question. And further, whether an implementation that *doesn't* act that way can be declared non-compliant. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 7 03:38:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B293A7768; Thu, 7 Feb 2008 03:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmXy0BVLLanm; Thu, 7 Feb 2008 03:38:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6F73A689A; Thu, 7 Feb 2008 03:38:52 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A8F3A765E for ; Thu, 7 Feb 2008 03:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9HVX8nCTMNX for ; Thu, 7 Feb 2008 03:38:50 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 09AE33A67D5 for ; Thu, 7 Feb 2008 03:38:49 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2FC7420EE3 for ; Thu, 7 Feb 2008 12:40:19 +0100 (CET) X-AuditID: c1b4fb3c-ad31ebb0000007e0-44-47aaee23dafa Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 19A2220E46 for ; Thu, 7 Feb 2008 12:40:19 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 12:40:18 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 12:40:18 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 90E1C27AB for ; Thu, 7 Feb 2008 13:40:18 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5A9334DC63 for ; Thu, 7 Feb 2008 13:40:18 +0200 (EET) Received: from n93.nomadiclab.com (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0FEA34DB16 for ; Thu, 7 Feb 2008 13:40:18 +0200 (EET) Message-ID: <47AAEE21.1070802@ericsson.com> Date: Thu, 07 Feb 2008 13:40:17 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: "sip@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 07 Feb 2008 11:40:18.0575 (UTC) FILETIME=[36C539F0:01C8697E] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] gruu and SIP MESSAGE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I haven't found any references that GRUU can be used in SIP MESSAGE. So, how do I ensure routing back to a specific client for SIP MESSAGE, without be forced to associate a MESSAGE with an existing INVITE? regards Sal _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 7 06:38:10 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7963A6DCC; Thu, 7 Feb 2008 06:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYb1TrnbsgIq; Thu, 7 Feb 2008 06:38:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4013A6F0B; Thu, 7 Feb 2008 06:38:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC3F3A6F0B for ; Thu, 7 Feb 2008 06:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+U3FIVgoMIw for ; Thu, 7 Feb 2008 06:38:07 -0800 (PST) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.119.2.190]) by core3.amsl.com (Postfix) with ESMTP id 8E6FD3A6DCC for ; Thu, 7 Feb 2008 06:38:07 -0800 (PST) Received: from rly32f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly32f.srv.mailcontrol.com (MailControl) with ESMTP id m17EdXMB017306 for ; Thu, 7 Feb 2008 14:39:35 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly32f.srv.mailcontrol.com (MailControl) id m17EcuMC013428 for sip@ietf.org; Thu, 7 Feb 2008 14:38:56 GMT Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly32f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id m17EcTfr010738; Thu, 07 Feb 2008 14:38:56 +0000 (GMT) Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 14:39:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Feb 2008 14:39:02 -0000 Message-ID: <680808427CF931459462C3D78CB5EC60014687E7@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] gruu and SIP MESSAGE Thread-Index: AchpfoHrExyFMM7OTc+cI9vTcFhm4QAGFMvQ From: "Attila Sipos" To: "Salvatore Loreto" , X-OriginalArrivalTime: 07 Feb 2008 14:39:52.0146 (UTC) FILETIME=[4C51B320:01C86997] X-Scanned-By: MailControl A-08-00-01 (www.mailcontrol.com) on 10.70.1.142 Subject: Re: [Sip] gruu and SIP MESSAGE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org You can use gruu in any non-REGISTER request. You don't need an INVITE, you only need to REGISTER the UA to get a gruu. from http://www.jdrosen.net/papers/draft-ietf-sip-gruu-13.txt : 3.3. Using a GRUU Once a user agent obtains GRUUs from the registrar, it uses them in several ways. First, it uses them as the contents of the Contact header field in non-REGISTER requests and responses that it emits (for example, an INVITE request and 200 OK response). Regards, Attila -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Salvatore Loreto Sent: 07 February 2008 11:40 To: sip@ietf.org Subject: [Sip] gruu and SIP MESSAGE Hi, I haven't found any references that GRUU can be used in SIP MESSAGE. So, how do I ensure routing back to a specific client for SIP MESSAGE, without be forced to associate a MESSAGE with an existing INVITE? regards Sal _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 7 07:25:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD853A79F8; Thu, 7 Feb 2008 07:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT1wouDRYRYC; Thu, 7 Feb 2008 07:25:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0338D3A799F; Thu, 7 Feb 2008 07:25:36 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03363A79E9 for ; Thu, 7 Feb 2008 07:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyUUcvcCgpEd for ; Thu, 7 Feb 2008 07:25:29 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CDEB03A78C1 for ; Thu, 7 Feb 2008 07:25:28 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4AF8F216FC; Thu, 7 Feb 2008 16:26:58 +0100 (CET) X-AuditID: c1b4fb3e-ad5edbb0000007e1-3c-47ab2342a9f1 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 33EC2212E5; Thu, 7 Feb 2008 16:26:58 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 16:26:57 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 16:26:57 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 30CEA245F; Thu, 7 Feb 2008 17:26:57 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EB8DC4DC63; Thu, 7 Feb 2008 17:26:56 +0200 (EET) Received: from n93.nomadiclab.com (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A58574DB16; Thu, 7 Feb 2008 17:26:56 +0200 (EET) Message-ID: <47AB2340.3060301@ericsson.com> Date: Thu, 07 Feb 2008 17:26:56 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Attila Sipos References: <680808427CF931459462C3D78CB5EC60014687E7@EXVS02.nasstar-t1.net> In-Reply-To: <680808427CF931459462C3D78CB5EC60014687E7@EXVS02.nasstar-t1.net> X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 07 Feb 2008 15:26:57.0394 (UTC) FILETIME=[E04C5520:01C8699D] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] gruu and SIP MESSAGE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Attila, sorry maybe I wasn't clear in my question. My problem is: I send out a MESSAGE to a AoR, and I want be sure that the receiver of the MESSAGE (if he wants to reply to the MESSAGE) will send out the reply to the same UA I used to send out the MESSAGE. Now, how is it possible if I can not insert a Contact header with my GRUU within the MESSAGE ? /sal Attila Sipos wrote: > You can use gruu in any non-REGISTER request. > > You don't need an INVITE, you only need to REGISTER the UA > to get a gruu. > > from http://www.jdrosen.net/papers/draft-ietf-sip-gruu-13.txt : > > 3.3. Using a GRUU > > Once a user agent obtains GRUUs from the registrar, it uses them in > several ways. First, it uses them as the contents of the Contact > header field in non-REGISTER requests and responses that it emits > (for example, an INVITE request and 200 OK response). > > Regards, > Attila > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Salvatore Loreto > Sent: 07 February 2008 11:40 > To: sip@ietf.org > Subject: [Sip] gruu and SIP MESSAGE > > Hi, > > I haven't found any references that GRUU can be used in SIP MESSAGE. > So, how do I ensure routing back to a specific client for SIP MESSAGE, > without be forced to associate a MESSAGE with an existing INVITE? > > regards > Sal > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 7 07:45:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26F413A7A60; Thu, 7 Feb 2008 07:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EF7Hd7if0Jn; Thu, 7 Feb 2008 07:45:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DFAD3A79DC; Thu, 7 Feb 2008 07:45:47 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24DF3A78D2 for ; Thu, 7 Feb 2008 07:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4KhHgg7Fyx6 for ; Thu, 7 Feb 2008 07:45:44 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 496BD3A790D for ; Thu, 7 Feb 2008 07:45:44 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2008 10:47:15 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m17FlEx8029579; Thu, 7 Feb 2008 10:47:14 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m17FhSIa016360; Thu, 7 Feb 2008 15:47:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 10:47:08 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 10:47:08 -0500 Message-ID: <47AB2804.5020508@cisco.com> Date: Thu, 07 Feb 2008 10:47:16 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Salvatore Loreto References: <680808427CF931459462C3D78CB5EC60014687E7@EXVS02.nasstar-t1.net> <47AB2340.3060301@ericsson.com> In-Reply-To: <47AB2340.3060301@ericsson.com> X-OriginalArrivalTime: 07 Feb 2008 15:47:08.0537 (UTC) FILETIME=[B2321690:01C869A0] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, Attila Sipos Subject: Re: [Sip] gruu and SIP MESSAGE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Salvatore Loreto wrote: > Hi Attila, > > sorry maybe I wasn't clear in my question. > > My problem is: > I send out a MESSAGE to a AoR, and I want be sure that the receiver of > the MESSAGE > (if he wants to reply to the MESSAGE) will send out the reply to the > same UA I used to send out the MESSAGE. > Now, how is it possible if I can not insert a Contact header with my > GRUU within the MESSAGE ? MESSAGE forbids the inclusion of Contact because it was not intended for message sessions. If you want to include a place you can be reached, you could use the Reply-To header. What you put in such a header is up to you. Paul > /sal > > Attila Sipos wrote: >> You can use gruu in any non-REGISTER request. >> >> You don't need an INVITE, you only need to REGISTER the UA >> to get a gruu. >> >> from http://www.jdrosen.net/papers/draft-ietf-sip-gruu-13.txt : >> >> 3.3. Using a GRUU >> >> Once a user agent obtains GRUUs from the registrar, it uses them in >> several ways. First, it uses them as the contents of the Contact >> header field in non-REGISTER requests and responses that it emits >> (for example, an INVITE request and 200 OK response). >> >> Regards, >> Attila >> >> >> >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Salvatore Loreto >> Sent: 07 February 2008 11:40 >> To: sip@ietf.org >> Subject: [Sip] gruu and SIP MESSAGE >> >> Hi, >> >> I haven't found any references that GRUU can be used in SIP MESSAGE. >> So, how do I ensure routing back to a specific client for SIP MESSAGE, >> without be forced to associate a MESSAGE with an existing INVITE? >> >> regards >> Sal >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 7 08:55:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C4F3A799C; Thu, 7 Feb 2008 08:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.795 X-Spam-Level: X-Spam-Status: No, score=-5.795 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJTuDXtJINjd; Thu, 7 Feb 2008 08:55:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150D53A78B3; Thu, 7 Feb 2008 08:55:47 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FDB83A78B3 for ; Thu, 7 Feb 2008 08:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYbqmhbzQaae for ; Thu, 7 Feb 2008 08:55:45 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9703A3A789F for ; Thu, 7 Feb 2008 08:55:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,316,1199692800"; d="scan'208";a="11981169" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 07 Feb 2008 08:57:12 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m17GvB5R030737 for ; Thu, 7 Feb 2008 08:57:11 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m17GvBWt014354 for ; Thu, 7 Feb 2008 16:57:11 GMT From: "Dan Wing" To: Date: Thu, 7 Feb 2008 08:57:11 -0800 Message-ID: <31e401c869aa$7b5e17e0$18726b80@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchpqnsK6WALzFBiRWi3p4WUo7pUpg== Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Sip] R-REUSE, media-security-requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In draft-ietf-sip-media-security-requirements-02, I changed the following requirement from MAY to MUST: R-REUSE The media security key management protocol MUST support the re-use of a previously established security context, and implementations SHOULD implement the re-use mechanism. A discussion of this requirement appears in Section 4.6 of the document, http://tools.ietf.org/html/draft-ietf-sip-media-security-requirements-02#secti on-4.6 Does anyone have equipment that they would implement this feature in? In the past, I have heard that some embedded devices (intelligent SIMs) could benefit from key re-use. Would it be reasonable to soften this requirement back to a MAY? -d _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 7 09:22:41 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A143A79B6; Thu, 7 Feb 2008 09:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPwmUR7IMt3N; Thu, 7 Feb 2008 09:22:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D603A7A88; Thu, 7 Feb 2008 09:22:37 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EF13A78EC for ; Thu, 7 Feb 2008 09:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yRXClu-TrmN for ; Thu, 7 Feb 2008 09:22:31 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1F6513A79D9 for ; Thu, 7 Feb 2008 09:21:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,316,1199692800"; d="scan'208";a="5373285" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2008 09:22:35 -0800 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 m17HMZiU019503; Thu, 7 Feb 2008 09:22:35 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m17HMYEJ009755; Thu, 7 Feb 2008 17:22:34 GMT 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.1830); Thu, 7 Feb 2008 09:22:34 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 09:22:33 -0800 Message-ID: <47AB3E4A.80004@cisco.com> Date: Thu, 07 Feb 2008 12:22:18 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Salvatore Loreto References: <680808427CF931459462C3D78CB5EC60014687E7@EXVS02.nasstar-t1.net> <47AB2340.3060301@ericsson.com> In-Reply-To: <47AB2340.3060301@ericsson.com> X-OriginalArrivalTime: 07 Feb 2008 17:22:33.0836 (UTC) FILETIME=[06BD62C0:01C869AE] Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org, Attila Sipos Subject: Re: [Sip] gruu and SIP MESSAGE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is what session mode is for. -Jonathan R. Salvatore Loreto wrote: > Hi Attila, > > sorry maybe I wasn't clear in my question. > > My problem is: > I send out a MESSAGE to a AoR, and I want be sure that the receiver of > the MESSAGE > (if he wants to reply to the MESSAGE) will send out the reply to the > same UA I used to send out the MESSAGE. > Now, how is it possible if I can not insert a Contact header with my > GRUU within the MESSAGE ? > > /sal > > Attila Sipos wrote: >> You can use gruu in any non-REGISTER request. >> >> You don't need an INVITE, you only need to REGISTER the UA >> to get a gruu. >> >> from http://www.jdrosen.net/papers/draft-ietf-sip-gruu-13.txt : >> >> 3.3. Using a GRUU >> >> Once a user agent obtains GRUUs from the registrar, it uses them in >> several ways. First, it uses them as the contents of the Contact >> header field in non-REGISTER requests and responses that it emits >> (for example, an INVITE request and 200 OK response). >> >> Regards, >> Attila >> >> >> >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Salvatore Loreto >> Sent: 07 February 2008 11:40 >> To: sip@ietf.org >> Subject: [Sip] gruu and SIP MESSAGE >> >> Hi, >> >> I haven't found any references that GRUU can be used in SIP MESSAGE. >> So, how do I ensure routing back to a specific client for SIP MESSAGE, >> without be forced to associate a MESSAGE with an existing INVITE? >> >> regards >> Sal >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 7 13:34:29 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488E43A790F; Thu, 7 Feb 2008 13:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=1, SPF_PASS=-0.001] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXw3UwoE2j6r; Thu, 7 Feb 2008 13:34:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4713A7AD0; Thu, 7 Feb 2008 13:34:25 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67143A7C09 for ; Thu, 7 Feb 2008 13:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4dOWFdy+tA6 for ; Thu, 7 Feb 2008 13:34:21 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6958E3A7C35 for ; Thu, 7 Feb 2008 13:33:09 -0800 (PST) Received: from [192.168.2.235] (pool-71-170-151-127.dllstx.fios.verizon.net [71.170.151.127]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id m17LYbaH021156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Feb 2008 15:34:38 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v753) To: sip List Message-Id: References: <20080207212223.2EF3B3A6F42@core3.amsl.com> From: Robert Sparks Date: Thu, 7 Feb 2008 15:34:35 -0600 X-Mailer: Apple Mail (2.753) Received-SPF: pass (nostrum.com: 71.170.151.127 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92/5728/Thu Feb 7 06:51:05 2008 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0233728974==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0233728974== Content-Type: multipart/alternative; boundary=Apple-Mail-7-774576094 --Apple-Mail-7-774576094 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Based on the feedback from the -00 draft, I've added a section that details the changes this draft makes in a more descriptive form (in addition to the patching-the-text form that already exists). Please look at the new section 7 and see if this addresses the concerns around the document format. I also spent some time experimenting with the suggestions to provide the changes in a diff format and have not found anything promising. For the sake of discussion, I did prepare a patch file that I'll send in a separate message. I'm becoming more convinced that that's the wrong approach to take though. We really don't want to create some form of derived document that's the "current spec". If we really want a new document, lets create a bis and be done with it. The point of creating the patch-the-text form in the first place was not to facilitate creating a new document out of the old document. It was done so that the impact of the changes on the spec is expressed in as unambiguous a form as possible. The worst outcome would be an update that _didn't_ make these explicit statements and half of the implementors in the world end up looking at a section and saying "Oh, I didn't know it meant to change _that_". RjS Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 7, 2008 3:22:23 PM CST > To: RjS@nostrum.com > Subject: New Version Notification for draft-sparks-sip-invfix-01 > > > A new version of I-D, draft-sparks-sip-invfix-01.txt has been > successfuly submitted by Robert Sparks and posted to the IETF > repository. > > Filename: draft-sparks-sip-invfix > Revision: 01 > Title: Correct transaction handling for 200 responses to Session > Initiation Protocol INVITE requests > Creation_date: 2008-02-07 > WG ID: Independent Submission > Number_of_pages: 18 > > Abstract: > This document normatively updates RFC 3261, the Session Initiation > Protocol (SIP), to address an error in the specified handling of > success (200 class) responses to INVITE requests. Elements following > RFC 3261 exactly will misidentify retransmissions of the request as a > new, unassociated, request. The correction involves modifying the > INVITE transaction state machines. The correction also changes the > way responses that cannot be matched to an existing transaction are > handled to address a security risk. > > > > The IETF Secretariat. > > --Apple-Mail-7-774576094 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Based on the feedback from the = -00 draft, I've added a section that details the changes this draft = makes
    in a more descriptive form (in addition to the = patching-the-text form that already exists).

    Please look at the new = section 7 and see if this addresses the concerns around the document = format.

    I = also spent some time experimenting with the suggestions to provide the = changes in a diff format and have
    not found anything = promising. For the sake of discussion, I did prepare a patch file that = I'll send in a separate
    message. I'm becoming more convinced = that that's the wrong approach to take though. We really don't = want
    to create some form of derived document that's the = "current spec". If we really want a new document, lets = create
    a bis and be done with it.

    The point of creating the = patch-the-text form in the first place was not to facilitate creating a = new
    document out of the old document. It was done so that the = impact of the changes on the spec is
    expressed in as = unambiguous a form as possible. The worst outcome would be an update = that
    _didn't_ make these explicit statements and half of the = implementors in the world end up looking=A0
    at a section=A0and = saying "Oh, I didn't know it meant to change _that_".

    RjS

    Begin forwarded = message:

    From: IETF I-D Submission Tool <idsubmission@ietf.org>=
    Date: February 7, 2008 3:22:23 PM = CST
    Subject: = New Version Notification for = draft-sparks-sip-invfix-01=A0


    A new version = of I-D, draft-sparks-sip-invfix-01.txt has been successfuly submitted by = Robert Sparks and posted to the IETF repository.

    = draft-sparks-sip-invfix
    = 01
    Title: Correct = transaction handling for 200 responses to Session Initiation Protocol = INVITE requests
    Creation_date: = 2008-02-07
    WG ID: = Independent Submission
    Number_of_pages: = 18

    Abstract:
    This document = normatively updates RFC 3261, the Session Initiation
    Protocol (SIP), to address an error in the specified = handling of
    success (200 class) responses to = INVITE requests.=A0 = Elements following
    RFC 3261 = exactly will misidentify retransmissions of the request as a
    new, unassociated, request.=A0 The correction involves = modifying the
    INVITE transaction state = machines.=A0 The correction = also changes the
    way responses that cannot be = matched to an existing transaction are
    handled = to address a security risk.



    The IETF = Secretariat.


    =

    = --Apple-Mail-7-774576094-- --===============0233728974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0233728974==-- From sip-bounces@ietf.org Thu Feb 7 14:49:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2393A7CD8; Thu, 7 Feb 2008 14:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcmFjeTtS+d3; Thu, 7 Feb 2008 14:49:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B513A79E3; Thu, 7 Feb 2008 14:49:28 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AEFF73A78AA; Thu, 7 Feb 2008 14:49:26 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20080207224926.AEFF73A78AA@core3.amsl.com> Date: Thu, 7 Feb 2008 14:49:26 -0800 (PST) Cc: sip mailing list , sip chair , Internet Architecture Board , RFC Editor Subject: [Sip] Protocol Action: 'A Framework for Consent-based Communications in the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has approved the following document: - 'A Framework for Consent-based Communications in the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-04.txt Technical summary. The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification, and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP. Working group summary. There is consensus in the working group to publish this document. The document came about due to security area concerns about the need to protect against denial of service attacks and amplification attacks when various relay and uri-list mechanisms are used in SIP. Document Quality The document has been extensively reviewed and discussed by the SIP WG since 2004. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 7 22:27:08 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780A828C0E4; Thu, 7 Feb 2008 22:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkciEwOwNe3Q; Thu, 7 Feb 2008 22:27:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7493A815E; Thu, 7 Feb 2008 22:26:39 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7403A78B3 for ; Thu, 7 Feb 2008 13:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQW4zlji+l2L for ; Thu, 7 Feb 2008 13:40:24 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E826A3A78AA for ; Thu, 7 Feb 2008 13:40:22 -0800 (PST) Received: from [192.168.2.235] (pool-71-170-151-127.dllstx.fios.verizon.net [71.170.151.127]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id m17Lfo9P021602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Feb 2008 15:41:50 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v753) To: sip List Message-Id: <1C8616C8-5BBC-4924-946A-7B0624DC27D8@nostrum.com> Content-Type: multipart/mixed; boundary=Apple-Mail-8-775008144 From: Robert Sparks Date: Thu, 7 Feb 2008 15:41:47 -0600 X-Mailer: Apple Mail (2.753) Received-SPF: pass (nostrum.com: 71.170.151.127 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92/5728/Thu Feb 7 06:51:05 2008 on shaman.nostrum.com X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 07 Feb 2008 22:26:38 -0800 Subject: [Sip] patch file for discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --Apple-Mail-8-775008144 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed As I said in my last message, I think this kind of thing is the wrong thing to do. But it came up in both Chicago and Vancouver, so to inform the discussion, here's a patch file that you can run against rfc3261 to render the invfix changes. Among the other evils this path seems to tend towards - it creates something that looks like an RFC that isn't. In what I hope isn't too feeble an attempt to create confusion, a lot of the patch is to the footer line of each page saying that the result is NOT 3261. To use this, put it, and a copy of 3261 you don't mind destroying, into a directory and run patch < invfix.patch RjS --Apple-Mail-8-775008144 Content-Transfer-Encoding: quoted-printable Content-Type: application/octet-stream; x-unix-mode=0644; name=invfix.patch Content-Disposition: attachment; filename=invfix.patch ---=20rfc3261.txt=092008-02-07=2014:37:26.000000000=20-0600=0A+++=20= rfc3261-mod.txt=092008-02-07=2015:38:52.000000000=20-0600=0A@@=20-55,7=20= +55,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20= =20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[Page=201]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20=20[Page=20= 1]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20= Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=20= 2002=0A=20=0A@@=20-111,7=20+111,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20= et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=202]=0A+Rosenberg,=20= et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20= =20=20=20=20=20=20=20=20[Page=202]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20= =20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20= =20=20=20=20=20=20June=202002=0A=20=0A@@=20-167,7=20+167,7=20@@=0A=20=0A=20= =0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [Page=203]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20=20[Page=203]=0A=20= =0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-223,7=20+223,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20= =20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=204]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= =20=20[Page=204]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-279,7=20+279,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=205]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20=20[Page=205]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-335,7=20= +335,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20[Page=206]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20= IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20=20= [Page=206]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-391,7=20+391,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=207]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20=20[Page=207]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-447,7=20= +447,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20[Page=208]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20= IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20=20= [Page=208]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-503,7=20+503,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=209]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20=20[Page=209]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-559,7=20= +559,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[Page=2010]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20= IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=20= 10]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20= Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=20= 2002=0A=20=0A@@=20-615,7=20+615,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20= et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2011]=0A+Rosenberg,=20= et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20= =20=20=20=20=20=20=20[Page=2011]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20= =20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20= =20=20=20=20=20June=202002=0A=20=0A@@=20-671,7=20+671,7=20@@=0A=20=0A=20=0A= =20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20= 12]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20= DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2012]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-727,7=20= +727,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[Page=2013]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20= IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=20= 13]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20= Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=20= 2002=0A=20=0A@@=20-783,7=20+783,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20= et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2014]=0A+Rosenberg,=20= et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20= =20=20=20=20=20=20=20[Page=2014]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20= =20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20= =20=20=20=20=20June=202002=0A=20=0A@@=20-839,7=20+839,7=20@@=0A=20=0A=20=0A= =20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20= 15]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20= DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2015]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-895,7=20= +895,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[Page=2016]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20= IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=20= 16]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20= Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=20= 2002=0A=20=0A@@=20-951,7=20+951,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20= et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2017]=0A+Rosenberg,=20= et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20= =20=20=20=20=20=20=20[Page=2017]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20= =20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20= =20=20=20=20=20June=202002=0A=20=0A@@=20-1007,7=20+1007,7=20@@=0A=20=0A=20= =0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20= 18]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20= DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2018]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20= -1063,7=20+1063,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20= =20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[Page=2019]=0A+Rosenberg,=20et.=20al.=20=20=20=20= THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20= [Page=2019]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-1119,7=20+1119,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2020]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2020]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-1175,7=20+1175,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2021]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2021]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-1231,7=20+1231,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2022]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2022]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-1287,7=20+1287,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2023]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2023]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-1343,7=20+1343,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2024]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2024]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-1399,7=20+1399,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2025]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2025]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-1455,7=20+1455,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2026]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2026]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-1511,7=20+1511,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2027]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2027]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-1567,7=20+1567,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2028]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2028]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-1623,7=20+1623,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2029]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2029]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-1679,7=20+1679,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2030]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2030]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-1735,7=20+1735,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2031]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2031]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-1791,7=20+1791,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2032]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2032]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-1847,7=20+1847,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2033]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2033]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-1903,7=20+1903,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2034]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2034]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-1959,7=20+1959,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2035]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2035]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-2015,7=20+2015,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2036]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2036]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-2071,7=20+2071,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2037]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2037]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-2127,7=20+2127,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2038]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2038]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-2183,7=20+2183,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2039]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2039]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-2239,7=20+2239,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2040]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2040]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-2295,7=20+2295,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2041]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2041]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-2351,7=20+2351,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2042]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2042]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-2407,7=20+2407,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2043]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2043]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-2463,7=20+2463,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2044]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2044]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-2519,7=20+2519,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2045]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2045]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-2575,7=20+2575,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2046]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2046]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-2631,7=20+2631,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2047]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2047]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-2687,7=20+2687,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2048]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2048]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-2743,7=20+2743,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2049]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2049]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-2799,7=20+2799,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2050]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2050]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-2855,7=20+2855,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2051]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2051]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-2911,7=20+2911,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2052]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2052]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-2967,7=20+2967,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2053]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2053]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-3023,7=20+3023,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2054]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2054]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-3079,7=20+3079,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2055]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2055]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-3135,7=20+3135,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2056]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2056]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-3191,7=20+3191,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2057]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2057]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-3247,7=20+3247,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2058]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2058]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-3303,7=20+3303,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2059]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2059]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-3359,7=20+3359,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2060]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2060]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-3415,7=20+3415,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2061]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2061]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-3471,7=20+3471,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2062]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2062]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-3527,7=20+3527,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2063]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2063]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-3583,7=20+3583,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2064]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2064]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-3639,7=20+3639,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2065]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2065]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-3695,7=20+3695,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2066]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2066]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-3751,7=20+3751,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2067]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2067]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-3807,7=20+3807,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2068]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2068]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-3863,7=20+3863,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2069]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2069]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-3919,7=20+3919,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2070]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2070]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-3975,7=20+3975,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2071]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2071]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-4031,7=20+4031,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2072]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2072]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-4087,7=20+4087,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2073]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2073]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-4143,7=20+4143,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2074]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2074]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-4199,7=20+4199,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2075]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2075]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-4255,7=20+4255,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2076]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2076]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-4311,7=20+4311,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2077]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2077]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-4367,7=20+4367,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2078]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2078]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-4423,7=20+4423,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2079]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2079]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-4479,7=20+4479,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2080]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2080]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-4535,7=20+4535,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2081]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2081]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-4591,7=20+4591,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2082]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2082]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-4647,7=20+4647,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2083]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2083]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-4703,7=20+4703,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2084]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2084]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-4745,21=20+4745,20=20@@=0A=20=20=20=20not=20yet=20sent=20an=20= offer.=0A=20=0A=20=20=20=20Once=20the=20response=20has=20been=20= constructed,=20it=20is=20passed=20to=20the=20INVITE=0A-=20=20=20server=20= transaction.=20=20Note,=20however,=20that=20the=20INVITE=20server=0A-=20=20= =20transaction=20will=20be=20destroyed=20as=20soon=20as=20it=20receives=20= this=20final=0A-=20=20=20response=20and=20passes=20it=20to=20the=20= transport.=20=20Therefore,=20it=20is=20necessary=0A-=20=20=20to=20= periodically=20pass=20the=20response=20directly=20to=20the=20transport=20= until=20the=0A-=20=20=20ACK=20arrives.=20=20The=202xx=20response=20is=20= passed=20to=20the=20transport=20with=20an=0A-=20=20=20interval=20that=20= starts=20at=20T1=20seconds=20and=20doubles=20for=20each=0A-=20=20=20= retransmission=20until=20it=20reaches=20T2=20seconds=20(T1=20and=20T2=20= are=20defined=20in=0A-=20=20=20Section=2017).=20=20Response=20= retransmissions=20cease=20when=20an=20ACK=20request=20for=0A-=20=20=20= the=20response=20is=20received.=20=20This=20is=20independent=20of=20= whatever=20transport=0A+=20=20=20server=20transaction.=20=20In=20order=20= to=20ensure=20reliable=20end-to-end=0A+=20=20=20transport=20of=20the=20= response,=20it=20is=20necessary=20to=20periodically=20pass=0A+=20=20=20= the=20response=20directly=20to=20the=20transport=20until=20the=20ACK=20= arrives.=20=20The=0A+=20=20=202xx=20response=20is=20passed=20to=20the=20= transport=20with=20an=20interval=20that=0A+=20=20=20starts=20at=20T1=20= seconds=20and=20doubles=20for=20each=20retransmission=20until=20it=0A+=20= =20=20reaches=20T2=20seconds=20(T1=20and=20T2=20are=20defined=20in=20= Section=2017).=0A+=20=20=20Response=20retransmissions=20cease=20when=20= an=20ACK=20request=20for=20the=0A+=20=20=20response=20is=20received.=20=20= This=20is=20independent=20of=20whatever=20transport=0A=20=20=20=20= protocols=20are=20used=20to=20send=20the=20response.=0A=20=0A=20=0A=20=0A= =20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20= 85]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20= DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2085]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20= -4815,7=20+4814,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20= =20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[Page=2086]=0A+Rosenberg,=20et.=20al.=20=20=20=20= THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20= [Page=2086]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-4871,7=20+4870,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2087]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2087]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-4927,7=20+4926,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2088]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2088]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-4983,7=20+4982,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2089]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2089]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-5039,7=20+5038,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2090]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2090]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-5095,7=20+5094,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2091]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2091]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-5151,7=20+5150,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2092]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2092]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-5207,7=20+5206,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2093]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2093]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-5263,7=20+5262,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2094]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2094]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-5319,7=20+5318,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2095]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2095]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-5375,7=20+5374,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2096]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2096]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-5431,7=20+5430,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=2097]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2097]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-5487,7=20+5486,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=2098]=0A+Rosenberg,=20et.=20al.=20=20= =20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20= =20=20[Page=2098]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-5543,7=20+5542,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=2099]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20=20[Page=2099]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-5599,7=20+5598,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20100]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20100]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-5655,7=20+5654,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20101]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20101]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-5711,7=20+5710,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20102]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20102]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-5767,7=20+5766,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20103]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20103]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-5823,7=20+5822,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20104]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20104]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-5879,7=20+5878,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20105]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20105]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-5935,23=20= +5934,18=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20106]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20106]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= =20=0A=2016.7=20Response=20Processing=0A=20=0A-=20=20=20When=20a=20= response=20is=20received=20by=20an=20element,=20it=20first=20tries=20to=20= locate=20a=0A-=20=20=20client=20transaction=20(Section=2017.1.3)=20= matching=20the=20response.=20=20If=20none=0A-=20=20=20is=20found,=20the=20= element=20MUST=20process=20the=20response=20(even=20if=20it=20is=20an=0A= -=20=20=20informational=20response)=20as=20a=20stateless=20proxy=20= (described=20below).=20=20If=20a=0A-=20=20=20match=20is=20found,=20the=20= response=20is=20handed=20to=20the=20client=20transaction.=0A-=0A-=20=20=20= =20=20=20Forwarding=20responses=20for=20which=20a=20client=20transaction=20= (or=20more=0A-=20=20=20=20=20=20generally=20any=20knowledge=20of=20= having=20sent=20an=20associated=20request)=20is=0A-=20=20=20=20=20=20not=20= found=20improves=20robustness.=20=20In=20particular,=20it=20ensures=20= that=0A-=20=20=20=20=20=20"late"=202xx=20responses=20to=20INVITE=20= requests=20are=20forwarded=20properly.=0A+=20=20=20When=20a=20response=20= is=20received=20by=20an=20element,=20it=20first=20tries=20to=0A+=20=20=20= locate=20a=20client=20transaction=20(Section=2017.1.3)=20matching=20the=0A= +=20=20=20response.=20=20If=20none=20is=20found,=20the=20element=20MUST=20= NOT=20forward=20the=0A+=20=20=20response.=20=20If=20a=20transaction=20is=20= found,=20the=20response=20is=20handed=20to=0A+=20=20=20the=20client=20= transaction.=0A=20=0A=20=20=20=20As=20client=20transactions=20pass=20= responses=20to=20the=20proxy=20layer,=20the=0A=20=20=20=20following=20= processing=20MUST=20take=20place:=0A@@=20-5991,7=20+5985,7=20@@=0A=20=0A=20= =0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20= 107]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20= DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20107]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20= -6047,7=20+6041,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20= =20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[Page=20108]=0A+Rosenberg,=20et.=20al.=20=20=20=20= THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20108]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-6103,7=20+6097,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20109]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20109]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-6159,7=20+6153,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20110]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20110]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-6215,7=20+6209,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20111]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20111]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-6271,7=20+6265,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20112]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20112]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-6327,7=20+6321,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20113]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20113]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-6338,9=20+6332,8=20@@=0A=20=20=20=20=20=20=20=20=20=20associated=20= with=20the=20response=20context.=20=20This=20will=20result=20in=20the=0A=20= =20=20=20=20=20=20=20=20=20response=20being=20sent=20to=20the=20location=20= now=20indicated=20in=20the=0A=20=20=20=20=20=20=20=20=20=20topmost=20Via=20= header=20field=20value.=20=20If=20the=20server=20transaction=20is=0A-=20=20= =20=20=20=20=20=20=20no=20longer=20available=20to=20handle=20the=20= transmission,=20the=20element=0A-=20=20=20=20=20=20=20=20=20MUST=20= forward=20the=20response=20statelessly=20by=20sending=20it=20to=20the=0A= -=20=20=20=20=20=20=20=20=20server=20transport.=20=20The=20server=20= transaction=20might=20indicate=0A+=20=20=20=20=20=20=20=20=20no=20longer=20= available=20to=20handle=20the=20transmission,=20the=20response=0A+=20=20=20= =20=20=20=20=20=20is=20simply=20discarded.=20=20The=20server=20= transaction=20might=20indicate=0A=20=20=20=20=20=20=20=20=20=20failure=20= to=20send=20the=20response=20or=20signal=20a=20timeout=20in=20its=20= state=0A=20=20=20=20=20=20=20=20=20=20machine.=20=20These=20errors=20= would=20be=20logged=20for=20diagnostic=20purposes=0A=20=20=20=20=20=20=20= =20=20=20as=20appropriate,=20but=20the=20protocol=20requires=20no=20= remedial=20action=0A@@=20-6383,7=20+6376,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20114]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20114]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-6439,7=20+6432,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20115]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20115]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-6495,7=20+6488,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20116]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20116]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-6551,7=20+6544,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20117]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20117]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-6607,7=20+6600,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20118]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20118]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-6663,7=20+6656,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20119]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20119]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-6719,7=20+6712,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20120]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20120]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-6775,7=20+6768,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20121]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20121]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-6831,7=20+6824,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20122]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20122]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-6887,7=20+6880,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20123]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20123]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-6943,7=20+6936,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20124]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20124]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-6999,7=20+6992,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20125]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20125]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-7037,44=20+7030,67=20@@=0A=20=20=20=20passed=20= to=20the=20TU.=20=20Any=20further=20provisional=20responses=20MUST=20be=20= passed=0A=20=20=20=20up=20to=20the=20TU=20while=20in=20the=20= "Proceeding"=20state.=0A=20=0A-=20=20=20When=20in=20either=20the=20= "Calling"=20or=20"Proceeding"=20states,=20reception=20of=20a=0A-=20=20=20= response=20with=20status=20code=20from=20300-699=20MUST=20cause=20the=20= client=0A+=20=20=20When=20in=20either=20the=20"Calling"=20or=20= "Proceeding"=20states,=20reception=20of=0A+=20=20=20a=20response=20with=20= status=20code=20from=20300-699=20MUST=20cause=20the=20client=0A=20=20=20=20= transaction=20to=20transition=20to=20"Completed".=20=20The=20client=20= transaction=0A=20=20=20=20MUST=20pass=20the=20received=20response=20up=20= to=20the=20TU,=20and=20the=20client=0A=20=20=20=20transaction=20MUST=20= generate=20an=20ACK=20request,=20even=20if=20the=20transport=20is=0A-=20=20= =20reliable=20(guidelines=20for=20constructing=20the=20ACK=20from=20the=20= response=20are=0A-=20=20=20given=20in=20Section=2017.1.1.3)=20and=20then=20= pass=20the=20ACK=20to=20the=20transport=0A-=20=20=20layer=20for=20= transmission.=20=20The=20ACK=20MUST=20be=20sent=20to=20the=20same=20= address,=0A-=20=20=20port,=20and=20transport=20to=20which=20the=20= original=20request=20was=20sent.=20=20The=0A-=20=20=20client=20= transaction=20SHOULD=20start=20timer=20D=20when=20it=20enters=20the=0A-=20= =20=20"Completed"=20state,=20with=20a=20value=20of=20at=20least=2032=20= seconds=20for=20unreliable=0A-=20=20=20transports,=20and=20a=20value=20= of=20zero=20seconds=20for=20reliable=20transports.=0A-=20=20=20Timer=20D=20= reflects=20the=20amount=20of=20time=20that=20the=20server=20transaction=20= can=0A-=20=20=20remain=20in=20the=20"Completed"=20state=20when=20= unreliable=20transports=20are=20used.=0A-=20=20=20This=20is=20equal=20to=20= Timer=20H=20in=20the=20INVITE=20server=20transaction,=20whose=0A+=20=20=20= reliable=20(guidelines=20for=20constructing=20the=20ACK=20from=20the=20= response=0A+=20=20=20are=20given=20in=20Section=2017.1.1.3)=20and=20then=20= pass=20the=20ACK=20to=20the=0A+=20=20=20transport=20layer=20for=20= transmission.=20=20The=20ACK=20MUST=20be=20sent=20to=20the=0A+=20=20=20= same=20address,=20port,=20and=20transport=20to=20which=20the=20original=20= request=0A+=20=20=20was=20sent.=0A=20=0A+=20=20=20When=20in=20either=20= the=20"Calling"=20or=20"Proceeding"=20states,=20reception=20of=0A+=20=20=20= a=202xx=20response=20MUST=20cause=20the=20client=20transaction=20to=20= transition=20to=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20= =20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20[Page=20126]=0A+=0A+=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20= IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20= 126]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20= Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=20= 2002=0A=20=0A=20=0A-=20=20=20default=20is=2064*T1.=20=20However,=20the=20= client=20transaction=20does=20not=20know=20the=0A-=20=20=20value=20of=20= T1=20in=20use=20by=20the=20server=20transaction,=20so=20an=20absolute=20= minimum=0A-=20=20=20of=2032s=20is=20used=20instead=20of=20basing=20Timer=20= D=20on=20T1.=0A+=20=20=20"Completed",=20and=20the=20response=20MUST=20be=20= passed=20up=20to=20the=20TU.=20=20The=0A+=20=20=20client=20transaction=20= MUST=20NOT=20generate=20an=20ACK=20to=20the=202xx=20response=20-=0A+=20=20= =20its=20handling=20is=20delegated=20to=20the=20TU.=20=20A=20UAC=20core=20= will=20send=20an=20ACK=0A+=20=20=20to=20the=202xx=20response=20using=20a=20= new=20transaction.=20=20A=20proxy=20core=20will=0A+=20=20=20always=20= forward=20the=202xx=20response=20upstream.=0A=20=0A-=20=20=20Any=20= retransmissions=20of=20the=20final=20response=20that=20are=20received=20= while=20in=0A-=20=20=20the=20"Completed"=20state=20MUST=20cause=20the=20= ACK=20to=20be=20re-passed=20to=20the=0A-=20=20=20transport=20layer=20for=20= retransmission,=20but=20the=20newly=20received=20response=0A-=20=20=20= MUST=20NOT=20be=20passed=20up=20to=20the=20TU.=20=20A=20retransmission=20= of=20the=20response=20is=0A-=20=20=20defined=20as=20any=20response=20= which=20would=20match=20the=20same=20client=20transaction=0A-=20=20=20= based=20on=20the=20rules=20of=20Section=2017.1.3.=0A+=20=20=20The=20= client=20transaction=20SHOULD=20start=20timer=20D=20when=20it=20enters=20= the=0A+=20=20=20"Completed"=20state=20for=20any=20reason,=20with=20a=20= value=20of=20at=20least=2032=0A+=20=20=20seconds=20for=20unreliable=20= transports,=20and=20a=20value=20of=20zero=20seconds=20for=0A+=20=20=20= reliable=20transports.=20=20Timer=20D=20reflects=20the=20amount=20of=20= time=20that=20the=0A+=20=20=20server=20transaction=20can=20remain=20in=20= the=20"Completed"=20state=20when=0A+=20=20=20unreliable=20transports=20= are=20used.=20=20This=20is=20equal=20to=20Timer=20H=20in=20the=0A+=20=20=20= INVITE=20server=20transaction,=20whose=20default=20is=2064*T1,=20and=20= is=20also=0A+=20=20=20equal=20to=20the=20time=20a=20UAS=20core=20will=20= wait=20for=20an=20ACK=20once=20it=20sends=20a=0A+=20=20=202xx=20= response.=20=20However,=20the=20client=20transaction=20does=20not=20know=20= the=0A+=20=20=20value=20of=20T1=20in=20use=20by=20the=20server=20= transaction=20or=20any=20downstream=20UAS=0A+=20=20=20cores,=20so=20an=20= absolute=20minimum=20of=2032s=20is=20used=20instead=20of=20basing=0A+=20=20= =20Timer=20D=20on=20T1.=0A=20=0A+=20=20=20Any=20retransmissions=20of=20a=20= response=20with=20status=20code=20300-699=20that=0A+=20=20=20are=20= received=20while=20in=20the=20"Completed"=20state=20MUST=20cause=20the=20= ACK=20to=0A+=20=20=20be=20re-passed=20to=20the=20transport=20layer=20for=20= retransmission,=20but=20the=0A+=20=20=20newly=20received=20response=20= MUST=20NOT=20be=20passed=20up=20to=20the=20TU.=0A=20=0A+=20=20=20Any=20= retransmissions=20of=20a=202xx=20response=20that=20are=20received=20= while=20in=0A+=20=20=20the=20"Completed"=20state=20MUST=20be=20passed=20= up=20to=20the=20TU.=20=20The=20client=0A+=20=20=20transaction=20MUST=20= NOT=20generate=20an=20ACK=20to=20the=202xx=20response.=20=20The=0A+=20=20= =20client=20transaction=20takes=20no=20further=20action.=0A=20=0A+=20=20=20= A=20retransmission=20of=20the=20response=20is=20defined=20as=20any=20= response=20which=0A+=20=20=20would=20match=20the=20same=20client=20= transaction=20based=20on=20the=20rules=20of=0A+=20=20=20Section=20= 17.1.3.=0A=20=0A+=20=20=20If=20timer=20D=20fires=20while=20the=20client=20= transaction=20is=20in=20the=0A+=20=20=20"Completed"=20state,=20the=20= client=20transaction=20MUST=20move=20to=20the=0A+=20=20=20terminated=20= state.=0A=20=0A+=20=20=20The=20client=20transaction=20MUST=20be=20= destroyed=20the=20instant=20it=20enters=20the=0A+=20=20=20"Terminated"=20= state.=0A=20=0A=20=0A=20=0A@@=20-7086,8=20+7102,52=20@@=0A=20=0A=20=0A=20= =0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20127]=0A+=0C=0A+RFC=203261=20=20=20= =20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20=20=20= =20=20=20=20=20=20=20=20June=202002=0A=20=0A+=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= |INVITE=20from=20TU=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20Timer=20= A=20fires=20=20=20=20=20|INVITE=20sent=0A+=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Reset=20A,=20=20=20=20=20=20=20=20=20=20V=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20Timer=20B=20fires=0A+=20=20=20=20= =20=20=20=20=20=20=20=20=20=20INVITE=20sent=20+-----------+=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20or=20Transport=20Err.=0A+=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20+---------|=20=20=20=20=20=20=20=20=20=20= =20|---------------+inform=20TU=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20|=20=20=20=20=20=20=20=20=20|=20=20Calling=20=20|=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20+-------->|=20=20=20=20=20=20=20=20=20=20=20|-----------+=20=20=20= |=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20+-----------+=202xx=20=20=20=20=20=20=20|=20=20=20|=0A+=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20|=20=20|=20=20=20=20=20=20=202xx=20to=20TU=20|=20=20=20|=0A+=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= |=20=20|1xx=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20|=0A+=20=20= =20=20=20300-699=20+---------------+=20=20|1xx=20to=20TU=20=20=20=20=20=20= =20=20|=20=20=20|=0A+=20=20=20=20ACK=20sent=20|=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=20=20=20|=0A+=20resp.=20to=20TU=20|=20=201xx=20=20=20=20=20=20=20= =20=20=20=20=20=20V=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20= =20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=201xx=20to=20TU=20= =20-----------+=20=20=20=20=20=20=20=20=20=20=20|=20=20=20|=0A+=20=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20+---------|=20=20=20=20=20=20=20=20=20=20= =20|=20=20=20=20=20=20=20=20=20=20=20|=20=20=20|=0A+=20=20=20=20=20=20=20= =20=20=20=20=20=20|=20=20|=20=20=20=20=20=20=20=20=20|Proceeding=20= |---------->|=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20= +-------->|=20=20=20=20=20=20=20=20=20=20=20|=202xx=20=20=20=20=20=20=20= |=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20= =20=20=20=20=20=20+-----------+=202xx=20to=20TU=20|=20=20=20|=0A+=20=20=20= =20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20300-699=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20|=0A+=20=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20ACK=20sent,=20=20|=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20|=0A+=20=20=20=20=20= =20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20resp.=20to=20TU|=20=20=20= +-------------+=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20|=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20NOTE:=0A+=20=20=20= =20=20=20=20=20=20=20=20=20=20|=20=20300-699=20=20=20=20=20=20=20=20=20V=20= =20=20V=20=20Transport=20Err.=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20|=20=20ACK=20sent=20=20+-----------+Inform=20TU=20=20=20=20=20=20|=20=20= transitions=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20+---------|=20= =20=20=20=20=20=20=20=20=20=20|-------------->|=20=20labeled=20with=0A+=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20|=20=20=20=20=20=20=20=20=20|=20= Completed=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20the=20= event=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20+-------->|=20=20=20= =20=20=20=20=20=20=20=20|---+=20=20=20=20=20=20=20=20=20=20=20|=20=20= over=20the=20action=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20= =20=20=20=20=20=20=20=20+-----------+=20=20=20|=202xx=20=20=20=20=20=20=20= |=20=20to=20take=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20= =20=20=20=20=20=20=20=20=20^=20=20=20|=20=20=20^=20=20=20=20=20|=202xx=20= to=20TU=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20= =20=20=20=20=20=20=20=20|=20=20=20|=20=20=20|=20=20=20=20=20|=20=20=20=20= =20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= +--------------+=20=20=20|=20=20=20+-----+=20=20=20=20=20=20=20=20=20=20=20= |=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20Timer=20D=20fires=20=20=20= =20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20|=20-=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20V=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20+-----------+=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20= Terminated|<--------------+=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20|=0A= +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20+-----------+=0A=20=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Figure=205:=20INVITE=20client=20transaction=0A=20=0A=20=0A=20=0A@@=20= -7099,6=20+7159,9=20@@=0A=20=0A=20=0A=20=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20128]=0A+=0C=0A+RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A=20=0A=20=0A@@=20-7111,86=20+7174,15=20@@=0A=20=0A=20= =0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20= 127]=0A-=0C=0A-RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20= Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=20= 2002=0A=20=0A=20=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20|INVITE=20from=20TU=0A-=20=20=20=20= =20=20=20=20=20=20=20=20=20Timer=20A=20fires=20=20=20=20=20|INVITE=20= sent=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20Reset=20A,=20=20=20=20=20=20= =20=20=20=20V=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Timer=20B=20fires=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20INVITE=20= sent=20+-----------+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20or=20= Transport=20Err.=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= +---------|=20=20=20=20=20=20=20=20=20=20=20|---------------+inform=20TU=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20= |=20=20Calling=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20+-------->|=20=20=20=20=20=20=20= =20=20=20=20|-------------->|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20+-----------+=202xx=20=20=20=20=20=20=20= =20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20|=20=20=20=20=20=20=202xx=20to=20TU=20=20= =20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20|=20=20|1xx=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=0A-=20=20=20=20300-699=20+---------------+=20=20|1xx=20= to=20TU=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20ACK=20sent=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-resp.=20to=20TU=20|=20=20= 1xx=20=20=20=20=20=20=20=20=20=20=20=20=20V=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20= |=20=201xx=20to=20TU=20=20-----------+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20|=20=20+---------|=20=20= =20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= |=0A-=20=20=20=20=20=20=20=20=20=20=20=20|=20=20|=20=20=20=20=20=20=20=20= =20|Proceeding=20|-------------->|=0A-=20=20=20=20=20=20=20=20=20=20=20=20= |=20=20+-------->|=20=20=20=20=20=20=20=20=20=20=20|=202xx=20=20=20=20=20= =20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20= =20=20=20=20=20=20=20+-----------+=202xx=20to=20TU=20=20=20=20=20|=0A-=20= =20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20300-699=20=20=20=20= |=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20= =20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20ACK=20sent,=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20resp.=20to=20TU|=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20= =20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20= =20=20=20=20NOTE:=0A-=20=20=20=20=20=20=20=20=20=20=20=20|=20=20300-699=20= =20=20=20=20=20=20=20=20V=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20|=20=20ACK=20= sent=20=20+-----------+Transport=20Err.=20|=20=20transitions=0A-=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20+---------|=20=20=20=20=20=20=20=20=20=20= =20|Inform=20TU=20=20=20=20=20=20|=20=20labeled=20with=0A-=20=20=20=20=20= =20=20=20=20=20=20=20|=20=20|=20=20=20=20=20=20=20=20=20|=20Completed=20= |-------------->|=20=20the=20event=0A-=20=20=20=20=20=20=20=20=20=20=20=20= |=20=20+-------->|=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20|=20=20over=20the=20action=0A-=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20+-----------+=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20to=20take=0A-=20=20=20=20=20=20= =20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20^=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20= =20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20= =20=20|=20Timer=20D=20fires=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20= =20=20=20=20=20+--------------+=20=20=20|=20-=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20V=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= +-----------+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20= =20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20|=20Terminated|<--------------+=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20= |=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20+-----------+=0A=20=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Figure=205:=20INVITE=20client=20transaction=0A=20=0A-=20=20=20If=20= timer=20D=20fires=20while=20the=20client=20transaction=20is=20in=20the=20= "Completed"=0A-=20=20=20state,=20the=20client=20transaction=20MUST=20= move=20to=20the=20terminated=20state.=0A=20=0A-=20=20=20When=20in=20= either=20the=20"Calling"=20or=20"Proceeding"=20states,=20reception=20of=20= a=0A-=20=20=202xx=20response=20MUST=20cause=20the=20client=20transaction=20= to=20enter=20the=0A-=20=20=20"Terminated"=20state,=20and=20the=20= response=20MUST=20be=20passed=20up=20to=20the=20TU.=0A-=20=20=20The=20= handling=20of=20this=20response=20depends=20on=20whether=20the=20TU=20is=20= a=20proxy=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20= =20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20[Page=20128]=0A-=0C=0A-RFC=203261=20=20=20=20=20=20=20=20=20=20=20= =20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A-=0A=20=0A-=20=20=20core=20or=20a=20UAC=20core.=20=20A=20= UAC=20core=20will=20handle=20generation=20of=20the=20ACK=20for=0A-=20=20=20= this=20response,=20while=20a=20proxy=20core=20will=20always=20forward=20= the=20200=20(OK)=0A-=20=20=20upstream.=20=20The=20differing=20treatment=20= of=20200=20(OK)=20between=20proxy=20and=20UAC=0A-=20=20=20is=20the=20= reason=20that=20handling=20of=20it=20does=20not=20take=20place=20in=20= the=0A-=20=20=20transaction=20layer.=0A-=0A-=20=20=20The=20client=20= transaction=20MUST=20be=20destroyed=20the=20instant=20it=20enters=20the=0A= -=20=20=20"Terminated"=20state.=20=20This=20is=20actually=20necessary=20= to=20guarantee=20correct=0A-=20=20=20operation.=20=20The=20reason=20is=20= that=202xx=20responses=20to=20an=20INVITE=20are=20treated=0A-=20=20=20= differently;=20each=20one=20is=20forwarded=20by=20proxies,=20and=20the=20= ACK=20handling=0A-=20=20=20in=20a=20UAC=20is=20different.=20=20Thus,=20= each=202xx=20needs=20to=20be=20passed=20to=20a=20proxy=0A-=20=20=20core=20= (so=20that=20it=20can=20be=20forwarded)=20and=20to=20a=20UAC=20core=20= (so=20it=20can=20be=0A-=20=20=20acknowledged).=20=20No=20transaction=20= layer=20processing=20takes=20place.=0A-=20=20=20Whenever=20a=20response=20= is=20received=20by=20the=20transport,=20if=20the=20transport=0A-=20=20=20= layer=20finds=20no=20matching=20client=20transaction=20(using=20the=20= rules=20of=0A-=20=20=20Section=2017.1.3),=20the=20response=20is=20passed=20= directly=20to=20the=20core.=20=20Since=0A-=20=20=20the=20matching=20= client=20transaction=20is=20destroyed=20by=20the=20first=202xx,=0A-=20=20= =20subsequent=202xx=20will=20find=20no=20match=20and=20therefore=20be=20= passed=20to=20the=0A-=20=20=20core.=0A=20=0A=2017.1.1.3=20Construction=20= of=20the=20ACK=20Request=0A=20=0A@@=20-7223,7=20+7215,7=20@@=0A=20=0A=20=0A= =20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20= 129]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20= DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20129]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20= -7279,7=20+7271,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20= =20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[Page=20130]=0A+Rosenberg,=20et.=20al.=20=20=20=20= THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20130]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-7335,7=20+7327,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20131]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20131]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-7391,7=20+7383,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20132]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20132]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-7447,7=20+7439,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20133]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20133]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-7503,14=20+7495,14=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20134]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20134]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A=20=0A=20=20=20=20= retransmitted=20by=20the=20server=20transaction;=20retransmissions=20of=20= 2xx=0A=20=20=20=20responses=20are=20handled=20by=20the=20TU.=20=20The=20= server=20transaction=20MUST=20then=0A-=20=20=20transition=20to=20the=20= "Terminated"=20state.=0A+=20=20=20transition=20to=20the=20"Accepted"=20= state.=0A=20=0A=20=20=20=20While=20in=20the=20"Proceeding"=20state,=20if=20= the=20TU=20passes=20a=20response=20with=0A=20=20=20=20status=20code=20= from=20300=20to=20699=20to=20the=20server=20transaction,=20the=20= response=0A@@=20-7559,52=20+7551,53=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20= et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20135]=0A+Rosenberg,=20et.=20= al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20= =20=20=20=20[Page=20135]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20= =20=20=20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20= =20=20=20June=202002=0A=20=0A=20=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|INVITE=0A-=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20|pass=20INV=20to=20TU=0A-=20=20=20=20=20=20=20=20=20=20=20=20= INVITE=20=20=20=20=20=20=20=20=20=20=20=20=20V=20send=20100=20if=20TU=20= won't=20in=20200ms=0A-=20=20=20=20=20=20=20=20=20=20=20=20send=20= response+-----------+=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= +--------|=20=20=20=20=20=20=20=20=20=20=20|--------+101-199=20from=20TU=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= |=20Proceeding|=20=20=20=20=20=20=20=20|send=20response=0A-=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20+------->|=20=20=20=20=20=20=20=20=20=20= =20|<-------+=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20= =20=20=20Transport=20Err.=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20|=20=20=20= =20=20=20=20=20=20=20Inform=20TU=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20= |--------------->+=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20+-----------+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20300-699=20from=20TU=20= |=20=20=20=20=20|2xx=20from=20TU=20=20=20=20=20=20=20=20|=0A-=20=20=20=20= =20=20=20=20=20=20=20=20send=20response=20=20=20|=20=20=20=20=20|send=20= response=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20= +------------------>+=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20= =20=20INVITE=20=20=20=20=20=20=20=20=20=20V=20=20=20=20=20=20=20=20=20=20= Timer=20G=20fires=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20send=20= response+-----------+=20send=20response=20=20|=0A-=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20+--------|=20=20=20=20=20=20=20=20=20=20=20= |--------+=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20|=20=20=20=20=20=20=20=20|=20Completed=20|=20=20=20=20=20=20=20=20= |=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= +------->|=20=20=20=20=20=20=20=20=20=20=20|<-------+=20=20=20=20=20=20=20= |=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20+-----------+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20ACK=20|=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20-=20=20=20|=20=20=20=20=20+------------------>+=0A-=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20|=20=20=20=20=20=20=20=20Timer=20H=20fires=20=20=20=20|=0A-=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= V=20=20=20=20=20=20=20=20or=20Transport=20Err.|=0A-=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20+-----------+=20=20= Inform=20TU=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20|=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20Confirmed=20|=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20= =20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= +-----------+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20|Timer=20I=20fires=20=20=20=20=20=20=20=20=20= |=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20|-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20V=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20+-----------+=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20= =20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A-=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20= Terminated|<---------------+=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20|=0A-=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= +-----------+=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|INVITE=0A+=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20|pass=20INV=20to=20TU=0A+=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20INVITE=20=20=20=20=20=20= =20=20=20=20=20=20=20V=20send=20100=20if=20TU=20won't=20in=20200ms=0A+=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20send=20= response+-----------+=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20+--------|=20=20=20=20=20=20=20=20=20=20=20= |--------+101-199=20from=20TU=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20|=20Proceeding|=20= =20=20=20=20=20=20=20|send=20response=0A+=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20+------->|=20=20=20=20=20=20=20=20= =20=20=20|<-------+=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20|=20=20=20=20=20=20=20=20=20=20Transport=20Err.=0A+=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20|=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20= Inform=20TU=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20= |--------------->+=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20+-----------+=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20300-699=20from=20TU=20|=20=20=20=20=20|2xx=20= from=20TU=20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20send=20response=20=20=20|=20=20=20=20=20|send=20= response=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20+--------------+=20=20=20=20=20+-------------+=20=20= =20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20|=0A+=20=20=20=20=20= INVITE=20=20=20=20=20=20=20=20=20=20V=20=20=20=20=20=20=20=20=20=20Timer=20= G=20fires=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20|=0A+=20=20=20=20= =20send=20response+-----------+=20send=20response=20=20=20=20=20=20=20=20= =20=20=20=20|=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20+--------|=20=20= =20=20=20=20=20=20=20=20=20|--------+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20|=20=20=20=20= =20=20=20=20|=20Completed=20|=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20|=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20= +------->|=20=20=20=20=20=20=20=20=20=20=20|<-------+=20=20=20INVITE=20=20= =20=20=20=20=20=20|=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20+-----------+=20=20=20=20=20=20=20=20=20=20=20=20-=20=20=20= =20=20=20=20=20=20=20=20=20=20|=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20|=20ACK=20=20=20=20=20= =20=20=20=20=20=20+-----+=20=20=20=20=20=20=20|=20=20=20=20|=0A+=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20|=20= -=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20|=20=20=20=20=20=20= =20V=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20|=20=20=20=20=20+--+=20=20=20=20=20=20=20=20=20=20=20=20|=20=20= +------------+=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20= =20|=20=20|=20=20=20=20=20=20=20=20=20=20=20=20|=20=20|=0A+=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= V=20=20=20=20=20=20=20=20=20=20=20=20+->|=20=20Accepted=20=20|=20=20|=0A= +=20=20=20=20=20Timer=20H=20fires=20=20=20|=20=20=20=20+-----------+=20=20= =20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20|=20=20|=0A+=20=20=20= =20=20=20=20=20=20=20=20or=20=20=20=20=20=20=20=20|=20=20=20=20|=20=20=20= =20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20+------------+=20=20|=0A+=20= =20=20=20=20Transport=20Error=20|=20=20=20=20|=20Confirmed=20|=20=20=20=20= =20=20=20=20=20|=20=20=20^=20=20=20=20=20|=20=20=20|=0A+=20=20=20=20=20=20= =20=20Inform=20TU=20=20=20=20|=20=20=20=20|=20=20=20=20=20=20=20=20=20=20= =20|=20=20=20=20=20=20+--+=20=20=20|=20=20=20=20=20|=20=20=20|=0A+=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20= +-----------+=20=20=20=20=20=20|=20=20=20=20=20=20+-----+=20=20=20|=0A+=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20= =20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=202xx=20from=20= TU=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=20=20=20=20=20|=20Timer=20I=20fires=20=20=20|=20=20send=20= response=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20|=20=20=20=20=20|=20-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= |=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20|=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20Timer=20L=20fires=20=20|=0A+=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20= |=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20-=20=20=20=20=20=20= =20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20|=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20V=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A+=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20|=20= =20=20=20=20+------------+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A= +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20= =20=20+---->|=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20+---------->|=20Terminated=20|<--------------+=0A+=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20|=0A+=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20+------------+=0A=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Figure=207:=20INVITE=20server=20transaction=0A=20=0A@@=20-7615,7=20= +7608,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20136]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20136]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-7627,9=20+7620,29=20@@=0A=20=20=20=20transports.=20=20Once=20timer=20= I=20fires,=20the=20server=20MUST=20transition=20to=20the=0A=20=20=20=20= "Terminated"=20state.=0A=20=0A+=20=20=20The=20purpose=20of=20the=20= "Accepted"=20state=20is=20to=20absorb=20retransmissions=0A+=20=20=20of=20= an=20accepted=20INVITE=20request.=20=20Any=20such=20retransmissions=20= are=0A+=20=20=20absorbed=20entirely=20within=20the=20server=20= transaction.=20=20They=20are=20not=0A+=20=20=20passed=20up=20to=20the=20= TU=20since=20any=20downstream=20UAS=20cores=20that=20accepted=0A+=20=20=20= the=20request=20have=20taken=20responsibility=20for=20reliability=20and=20= will=0A+=20=20=20already=20retransmit=20their=202xx=20responses=20if=20= neccessary.=20=20=20=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A+=20=20=20While=20in=20the=20"Accepted"=20state,=20if=20the=20= TU=20passes=20a=202xx=20response,=0A+=20=20=20the=20server=20transaction=20= MUST=20pass=20the=20response=20to=20the=20transport=0A+=20=20=20layer=20= for=20transmission.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A+=20=20=20=20=20=0A+=20=20=20When=20the=20= INVITE=20server=20transaction=20enters=20the=20"Accepted"=20state,=0A+=20= =20=20Timer=20L=20MUST=20be=20set=20to=20fire=20in=2064*T1=20for=20all=20= transports.=20=20This=0A+=20=20=20value=20matches=20both=20Timer=20B=20= in=20the=20next=20upstream=20client=20state=0A+=20=20=20machine=20(the=20= amount=20of=20time=20the=20previous=20hop=20will=20wait=20for=20a=0A+=20=20= =20response=20when=20no=20provisionals=20have=20been=20sent)=20and=20the=20= amount=20of=0A+=20=20=20time=20this=20(or=20any=20downstream)=20UAS=20= core=20might=20be=20retransmitting=20the=0A+=20=20=202xx=20while=20= waiting=20for=20an=20ACK.=20=20If=20Timer=20L=20fires=20while=20the=20= INVITE=0A+=20=20=20server=20transaction=20is=20in=20the=20"Accepted"=20= state,=20the=20transaction=0A+=20=20=20MUST=20transition=20to=20the=20= "Terminated"=20state.=20=20=20=20=20=20=20=20=20=20=20=0A+=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20Once=20= the=20transaction=20is=20in=20the=20"Terminated"=20state,=20it=20MUST=20= be=0A-=20=20=20destroyed=20immediately.=20=20As=20with=20client=20= transactions,=20this=20is=20needed=0A-=20=20=20to=20ensure=20reliability=20= of=20the=202xx=20responses=20to=20INVITE.=0A+=20=20=20destroyed=20= immediately.=20=20=0A=20=0A=2017.2.2=20Non-INVITE=20Server=20Transaction=0A= =20=0A@@=20-7671,7=20+7684,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20137]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20137]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-7727,7=20+7740,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20138]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20138]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-7783,7=20+7796,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20139]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20139]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-7839,7=20+7852,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20140]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20140]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-7895,7=20+7908,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20141]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20141]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-7951,7=20+7964,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20142]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20142]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-8007,7=20+8020,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20143]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20143]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-8048,22=20+8061,21=20@@=0A=20=20=20=20client=20= transport=20is=20configured=20to=20insert=20into=20requests,=20the=20= response=0A=20=20=20=20MUST=20be=20silently=20discarded.=0A=20=0A-=20=20=20= If=20there=20are=20any=20client=20transactions=20in=20existence,=20the=20= client=0A-=20=20=20transport=20uses=20the=20matching=20procedures=20of=20= Section=2017.1.3=20to=20attempt=0A-=20=20=20to=20match=20the=20response=20= to=20an=20existing=20transaction.=20=20If=20there=20is=20a=0A-=20=20=20= match,=20the=20response=20MUST=20be=20passed=20to=20that=20transaction.=20= =20Otherwise,=0A-=20=20=20the=20response=20MUST=20be=20passed=20to=20the=20= core=20(whether=20it=20be=20stateless=0A-=20=20=20proxy,=20stateful=20= proxy,=20or=20UA)=20for=20further=20processing.=20=20Handling=20of=0A-=20= =20=20these=20"stray"=20responses=20is=20dependent=20on=20the=20core=20= (a=20proxy=20will=0A-=20=20=20forward=20them,=20while=20a=20UA=20will=20= discard,=20for=20example).=0A=20=0A=20=0A+=20=20=20The=20client=20= transport=20uses=20the=20matching=20procedures=20of=20Section=0A+=20=20=20= 17.1.3=20to=20attempt=20to=20match=20the=20response=20to=20an=20existing=20= =20=0A+=20=20=20transaction.=20=20If=20there=20is=20a=20match,=20the=20= response=20MUST=20be=20passed=20to=0A+=20=20=20that=20transaction.=20=20= Otherwise,=20the=20response=20MUST=20be=20silently=0A+=20=20=20= discarded.=20=20=0A=20=0A=20=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20144]=0A+=0A+=0A+Rosenberg,=20et.=20= al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20= =20=20=20=20[Page=20144]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20= =20=20=20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20= =20=20=20June=202002=0A=20=0A@@=20-8119,7=20+8131,7=20@@=0A=20=0A=20=0A=20= =0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20= 145]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20= DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20145]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20= -8129,11=20+8141,11=20@@=0A=20=20=20=20Section=2017.2.3.=20=20If=20a=20= matching=20server=20transaction=20is=20found,=20the=0A=20=20=20=20= request=20is=20passed=20to=20that=20transaction=20for=20processing.=20=20= If=20no=20match=20is=0A=20=20=20=20found,=20the=20request=20is=20passed=20= to=20the=20core,=20which=20may=20decide=20to=0A-=20=20=20construct=20a=20= new=20server=20transaction=20for=20that=20request.=20=20Note=20that=20= when=0A-=20=20=20a=20UAS=20core=20sends=20a=202xx=20response=20to=20= INVITE,=20the=20server=20transaction=20is=0A-=20=20=20destroyed.=20=20= This=20means=20that=20when=20the=20ACK=20arrives,=20there=20will=20be=20= no=0A-=20=20=20matching=20server=20transaction,=20and=20based=20on=20= this=20rule,=20the=20ACK=20is=0A-=20=20=20passed=20to=20the=20UAS=20= core,=20where=20it=20is=20processed.=0A+=20=20=20construct=20a=20new=20= server=20transaction=20for=20that=20request.=20=20=0A+=0A+=0A+=0A+=0A=20=0A= =2018.2.2=20Sending=20Responses=0A=20=0A@@=20-8175,7=20+8187,7=20@@=0A=20= =0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20= Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [Page=20146]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20146]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-8231,7=20+8243,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20147]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20147]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-8287,7=20+8299,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20148]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20148]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-8343,7=20+8355,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20149]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20149]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-8399,7=20+8411,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20150]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20150]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-8455,7=20+8467,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20151]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20151]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-8511,7=20+8523,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20152]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20152]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-8567,7=20+8579,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20153]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20153]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-8623,7=20+8635,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20154]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20154]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-8679,7=20+8691,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20155]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20155]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-8735,7=20+8747,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20156]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20156]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-8791,7=20+8803,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20157]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20157]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-8847,7=20+8859,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20158]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20158]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-8903,7=20+8915,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20159]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20159]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-8959,7=20+8971,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20160]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20160]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-9015,7=20+9027,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20161]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20161]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-9071,7=20+9083,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20162]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20162]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-9127,7=20+9139,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20163]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20163]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-9183,7=20+9195,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20164]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20164]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-9239,7=20+9251,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20165]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20165]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-9295,7=20+9307,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20166]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20166]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-9351,7=20+9363,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20167]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20167]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-9407,7=20+9419,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20168]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20168]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-9463,7=20+9475,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20169]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20169]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-9519,7=20+9531,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20170]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20170]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-9575,7=20+9587,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20171]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20171]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-9631,7=20+9643,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20172]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20172]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-9687,7=20+9699,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20173]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20173]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-9743,7=20+9755,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20174]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20174]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-9799,7=20+9811,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20175]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20175]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-9855,7=20+9867,7=20= @@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20= =20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[Page=20176]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20= RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20176]=0A=20=0C= =0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-9911,7=20+9923,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20= =20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=20177]=0A+Rosenberg,=20et.=20al.=20=20=20= =20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20177]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-9967,7=20+9979,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20178]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20178]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-10023,7=20= +10035,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20179]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20179]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-10079,7=20+10091,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20180]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20180]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-10135,7=20+10147,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20181]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20181]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-10191,7=20= +10203,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20182]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20182]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-10247,7=20+10259,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20183]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20183]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-10303,7=20+10315,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20184]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20184]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-10359,7=20= +10371,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20185]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20185]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-10415,7=20+10427,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20186]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20186]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-10471,7=20+10483,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20187]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20187]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-10527,7=20= +10539,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20188]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20188]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-10583,7=20+10595,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20189]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20189]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-10639,7=20+10651,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20190]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20190]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-10695,7=20= +10707,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20191]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20191]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-10751,7=20+10763,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20192]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20192]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-10807,7=20+10819,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20193]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20193]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-10863,7=20= +10875,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20194]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20194]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-10919,7=20+10931,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20195]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20195]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-10975,7=20+10987,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20196]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20196]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-11031,7=20= +11043,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20197]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20197]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-11087,7=20+11099,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20198]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20198]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-11143,7=20+11155,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20199]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20199]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-11199,7=20= +11211,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20200]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20200]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-11255,7=20+11267,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20201]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20201]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-11311,7=20+11323,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20202]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20202]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-11367,7=20= +11379,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20203]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20203]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-11423,7=20+11435,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20204]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20204]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-11479,7=20+11491,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20205]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20205]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-11535,7=20= +11547,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20206]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20206]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-11591,7=20+11603,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20207]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20207]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-11647,7=20+11659,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20208]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20208]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-11703,7=20= +11715,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20209]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20209]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-11759,7=20+11771,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20210]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20210]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-11815,7=20+11827,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20211]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20211]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-11871,7=20= +11883,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20212]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20212]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-11927,7=20+11939,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20213]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20213]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-11983,7=20+11995,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20214]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20214]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-12039,7=20= +12051,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20215]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20215]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-12095,7=20+12107,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20216]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20216]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-12151,7=20+12163,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20217]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20217]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-12207,7=20= +12219,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20218]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20218]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-12263,7=20+12275,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20219]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20219]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-12319,7=20+12331,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20220]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20220]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-12375,7=20= +12387,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20221]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20221]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-12431,7=20+12443,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20222]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20222]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-12487,7=20+12499,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20223]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20223]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-12543,7=20= +12555,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20224]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20224]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-12599,7=20+12611,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20225]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20225]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-12655,7=20+12667,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20226]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20226]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-12711,7=20= +12723,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20227]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20227]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-12767,7=20+12779,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20228]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20228]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-12823,7=20+12835,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20229]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20229]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-12879,7=20= +12891,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20230]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20230]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-12935,7=20+12947,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20231]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20231]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-12991,7=20+13003,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20232]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20232]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-13047,7=20= +13059,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20233]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20233]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-13103,7=20+13115,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20234]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20234]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-13159,7=20+13171,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20235]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20235]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-13215,7=20= +13227,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20236]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20236]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-13271,7=20+13283,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20237]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20237]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-13327,7=20+13339,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20238]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20238]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-13383,7=20= +13395,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20239]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20239]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-13439,7=20+13451,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20240]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20240]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-13495,7=20+13507,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20241]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20241]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-13551,7=20= +13563,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20242]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20242]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-13607,7=20+13619,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20243]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20243]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-13663,7=20+13675,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20244]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20244]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-13719,7=20= +13731,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20245]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20245]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-13775,7=20+13787,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20246]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20246]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-13831,7=20+13843,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20247]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20247]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-13887,7=20= +13899,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20248]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20248]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-13943,7=20+13955,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20249]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20249]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-13999,7=20+14011,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20250]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20250]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-14055,7=20= +14067,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20251]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20251]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-14111,7=20+14123,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20252]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20252]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-14167,7=20+14179,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20253]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20253]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-14223,7=20= +14235,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20254]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20254]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-14279,7=20+14291,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20255]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20255]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-14335,7=20+14347,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20256]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20256]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-14391,7=20= +14403,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20257]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20257]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-14447,7=20+14459,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20258]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20258]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-14503,7=20+14515,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20259]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20259]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-14559,7=20= +14571,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20260]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20260]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-14615,7=20+14627,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20261]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20261]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-14671,7=20+14683,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20262]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20262]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-14727,7=20= +14739,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20263]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20263]=0A= =20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20= Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A= @@=20-14783,7=20+14795,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20= al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[Page=20264]=0A+Rosenberg,=20et.=20al.=20= =20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20= =20=20[Page=20264]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20= =20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20= =20June=202002=0A=20=0A@@=20-14827,6=20+14839,9=20@@=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20retransmits=0A=20= Timer=20K=20=20T4=20for=20UDP=20=20=20=20=20=20=20Section=2017.1.2.2=20=20= =20=20=20Wait=20time=20for=0A=20=20=20=20=20=20=20=20=20=200s=20for=20= TCP/SCTP=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20response=20retransmits=0A+Timer=20L=20=2064*T1=20=20=20=20=20=20=20=20= =20=20=20=20Section=2017.2.1=20=20=20=20=20=20=20Wait=20time=20for=0A+=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20accepted=20= INVITE=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20request=20retransmits=0A=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20Table=204:=20Summary=20of=20timers=0A=20=0A@@=20= -14836,10=20+14851,7=20@@=0A=20=0A=20=0A=20=0A-=0A-=0A-=0A-Rosenberg,=20= et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20265]=0A+Rosenberg,=20et.=20= al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20= =20=20=20=20[Page=20265]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20= =20=20=20=20SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20= =20=20=20June=202002=0A=20=0A@@=20-14895,7=20+14907,7=20@@=0A=20=0A=20=0A= =20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20= Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20= 266]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20= DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20266]=0A=20=0C=0A=20RFC=20= 3261=20=20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20= Protocol=20=20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20= -14951,7=20+14963,7=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20= =20=20=20=20=20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20[Page=20267]=0A+Rosenberg,=20et.=20al.=20=20=20=20= THIS=20IS=20NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20= [Page=20267]=0A=20=0C=0A=20RFC=203261=20=20=20=20=20=20=20=20=20=20=20=20= SIP:=20Session=20Initiation=20Protocol=20=20=20=20=20=20=20=20=20=20=20= June=202002=0A=20=0A@@=20-15007,7=20+15019,7=20@@=0A=20=0A=20=0A=20=0A= -Rosenberg,=20et.=20al.=20=20=20=20=20=20=20=20=20=20Standards=20Track=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=20268]=0A= +Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20NOT=20RFC3261=20-=20DO=20= NOT=20USE=20=20=20=20=20=20=20=20[Page=20268]=0A=20=0C=0A=20RFC=203261=20= =20=20=20=20=20=20=20=20=20=20=20SIP:=20Session=20Initiation=20Protocol=20= =20=20=20=20=20=20=20=20=20=20June=202002=0A=20=0A@@=20-15036,7=20= +15048,7=20@@=0A=20=20=20=20This=20document=20and=20the=20information=20= contained=20herein=20is=20provided=20on=20an=0A=20=20=20=20"AS=20IS"=20= basis=20and=20THE=20INTERNET=20SOCIETY=20AND=20THE=20INTERNET=20= ENGINEERING=0A=20=20=20=20TASK=20FORCE=20DISCLAIMS=20ALL=20WARRANTIES,=20= EXPRESS=20OR=20IMPLIED,=20INCLUDING=0A-=20=20=20BUT=20NOT=20LIMITED=20TO=20= ANY=20WARRANTY=20THAT=20THE=20USE=20OF=20THE=20INFORMATION=0A+=20=20=20= BUT=20NOT=20LIMITED=20TO=20ANY=20WARRANTY=20THAT=20THE=20USEOF=20THE=20= INFORMATION=0A=20=20=20=20HEREIN=20WILL=20NOT=20INFRINGE=20ANY=20RIGHTS=20= OR=20ANY=20IMPLIED=20WARRANTIES=20OF=0A=20=20=20=20MERCHANTABILITY=20OR=20= FITNESS=20FOR=20A=20PARTICULAR=20PURPOSE.=0A=20=0A@@=20-15063,5=20= +15075,5=20@@=0A=20=0A=20=0A=20=0A-Rosenberg,=20et.=20al.=20=20=20=20=20=20= =20=20=20=20Standards=20Track=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20[Page=20269]=0A+Rosenberg,=20et.=20al.=20=20=20=20THIS=20IS=20= NOT=20RFC3261=20-=20DO=20NOT=20USE=20=20=20=20=20=20=20=20[Page=20269]=0A= =20=0C=0A= --Apple-Mail-8-775008144 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-8-775008144 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-8-775008144-- From sip-bounces@ietf.org Thu Feb 7 22:29:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872173A8179; Thu, 7 Feb 2008 22:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlheF-7kM2gS; Thu, 7 Feb 2008 22:29:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79CE23A80ED; Thu, 7 Feb 2008 22:29:01 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9405E3A800A for ; Thu, 7 Feb 2008 22:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4W32JgCY6k1 for ; Thu, 7 Feb 2008 22:28:58 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2F51D3A8172 for ; Thu, 7 Feb 2008 22:28:50 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m186UHFa012427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 8 Feb 2008 00:30:19 -0600 Message-Id: <4A9537C1-B5F6-4CB1-9260-0A23E1CBC926@softarmor.com> From: Dean Willis To: sip@ietf.org Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 8 Feb 2008 00:30:12 -0600 X-Mailer: Apple Mail (2.915) Subject: [Sip] Test, and Warning X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've heard that a number of folks are not getting messages off this list correctly. This may or may not have to do with the IETF's server transition, but things have been in play since lat Friday. Hopefully, they're settling down now. But if you post something to the list, please doublecheck that it made it into the Mailman archive, which you can see online at: http://www.ietf.org/mail-archive/web/sip/current/index.html' And if you're missing messages: 1) Try resubscribing - -some people apaprently got dropped 2) Try checking that you haven't been set "nomail" due to bounces 3) Read your missing mail on the web archive, as linked above 4) and let me know if there is a chronic problem. I can't do anything, but I can share your pain. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 7 23:30:29 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DCD3A7C25; Thu, 7 Feb 2008 23:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+EEgQ0nUBA5; Thu, 7 Feb 2008 23:30:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676C828C0E0; Thu, 7 Feb 2008 23:30:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18CA3A7C25 for ; Thu, 7 Feb 2008 23:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DsH4eNMlAe0 for ; Thu, 7 Feb 2008 23:30:24 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 86D713A771E for ; Thu, 7 Feb 2008 23:30:23 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JVW0043WSX3AA@siemenscomms.co.uk> for sip@ietf.org; Fri, 08 Feb 2008 07:31:52 +0000 (GMT) Date: Fri, 08 Feb 2008 07:31:50 +0000 From: "Elwell, John" In-reply-to: To: Robert Sparks , sip List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0602AEF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01 Thread-Index: Achp0aF7M4Rdp62pRR+9XbxbF/Z/UwAUp7xQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20080207212223.2EF3B3A6F42@core3.amsl.com> Subject: Re: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1875352180==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1875352180== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C86A24.ABC6D6AD" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C86A24.ABC6D6AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, =20 So we have two sections containing RFC 2119 language and saying the same thing in different ways. If section 7 is just a description, as it claims, then should it not avoid RFC 2119 language. Otherwise, which section takes precedence in the event of a conflict? =20 John ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Robert Sparks Sent: 07 February 2008 21:35 To: sip List Subject: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01 =09 =09 Based on the feedback from the -00 draft, I've added a section that details the changes this draft makes=20 in a more descriptive form (in addition to the patching-the-text form that already exists). Please look at the new section 7 and see if this addresses the concerns around the document format. I also spent some time experimenting with the suggestions to provide the changes in a diff format and have not found anything promising. For the sake of discussion, I did prepare a patch file that I'll send in a separate message. I'm becoming more convinced that that's the wrong approach to take though. We really don't want to create some form of derived document that's the "current spec". If we really want a new document, lets create a bis and be done with it. The point of creating the patch-the-text form in the first place was not to facilitate creating a new document out of the old document. It was done so that the impact of the changes on the spec is expressed in as unambiguous a form as possible. The worst outcome would be an update that _didn't_ make these explicit statements and half of the implementors in the world end up looking=20 at a section and saying "Oh, I didn't know it meant to change _that_". RjS Begin forwarded message: From: IETF I-D Submission Tool Date: February 7, 2008 3:22:23 PM CST To: RjS@nostrum.com Subject: New Version Notification for draft-sparks-sip-invfix-01=20 A new version of I-D, draft-sparks-sip-invfix-01.txt has been successfuly submitted by Robert Sparks and posted to the IETF repository. Filename: draft-sparks-sip-invfix Revision: 01 Title: Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests Creation_date: 2008-02-07 WG ID: Independent Submission Number_of_pages: 18 Abstract: This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. The IETF Secretariat. ------_=_NextPart_001_01C86A24.ABC6D6AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Robert,
     
    So we have two sections containing RFC 2119 = language and=20 saying the same thing in different ways. If section 7 is just a = description, as=20 it claims, then should it not avoid RFC 2119 language. Otherwise, which = section=20 takes precedence in the event of a conflict?
     
    John

    From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Robert=20 Sparks
    Sent: 07 February 2008 21:35
    To: sip=20 List
    Subject: [Sip] Fwd: New Version Notification for=20 draft-sparks-sip-invfix-01

    Based on the feedback from the -00 draft, I've added a = section that=20 details the changes this draft makes
    in a more descriptive form (in addition to the patching-the-text = form=20 that already exists).

    Please look at the new section 7 and see if this addresses the = concerns=20 around the document format.

    I also spent some time experimenting with the suggestions to = provide the=20 changes in a diff format and have
    not found anything promising. For the sake of discussion, I did = prepare a=20 patch file that I'll send in a separate
    message. I'm becoming more convinced that that's the wrong = approach to=20 take though. We really don't want
    to create some form of derived document that's the "current = spec". If we=20 really want a new document, lets create
    a bis and be done with it.

    The point of creating the patch-the-text form in the first place = was not=20 to facilitate creating a new
    document out of the old document. It was done so that the impact = of the=20 changes on the spec is
    expressed in as unambiguous a form as possible. The worst outcome = would=20 be an update that
    _didn't_ make these explicit statements and half of the = implementors in=20 the world end up looking 
    at a section and saying "Oh, I didn't know it meant to = change=20 _that_".

    RjS

    Begin forwarded message:

    From: IETF I-D = Submission Tool=20 <idsubmission@ietf.org>
    Date: February 7, = 2008 3:22:23=20 PM CST
    To: RjS@nostrum.com
    Subject: = New = Version=20 Notification for draft-sparks-sip-invfix-01 


    A new version of I-D,=20 draft-sparks-sip-invfix-01.txt has been successfuly submitted by = Robert=20 Sparks and posted to the IETF repository.

    Filename: draft-sparks-sip-invfix
    Revision: 01
    Title: Correct transaction handling for = 200=20 responses to Session Initiation Protocol INVITE requests
    Creation_date: 2008-02-07
    WG ID: Independent Submission
    Number_of_pages: 18

    Abstract:
    This document normatively updates RFC = 3261, the=20 Session Initiation
    Protocol (SIP), to address an error in = the=20 specified handling of
    success (200 class) responses to INVITE=20 requests.  Elements=20 following
    RFC 3261 exactly will misidentify = retransmissions=20 of the request as a
    new, unassociated, request.  The correction involves = modifying=20 the
    INVITE transaction state machines.  The correction also = changes=20 the
    way responses that cannot be matched to = an existing=20 transaction are
    handled to address a security risk.



    The IETF Secretariat.



    ------_=_NextPart_001_01C86A24.ABC6D6AD-- --===============1875352180== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1875352180==-- From sip-bounces@ietf.org Fri Feb 8 01:22:03 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8C428C1CD; Fri, 8 Feb 2008 01:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UflxO-3KbFCq; Fri, 8 Feb 2008 01:22:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5908B28C0EB; Fri, 8 Feb 2008 01:22:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5100628C17B for ; Fri, 8 Feb 2008 01:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8qLUuZk9RBi for ; Fri, 8 Feb 2008 01:21:59 -0800 (PST) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.119.2.190]) by core3.amsl.com (Postfix) with ESMTP id 2078428C1B1 for ; Fri, 8 Feb 2008 01:21:11 -0800 (PST) Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly37f.srv.mailcontrol.com (MailControl) with ESMTP id m189M8WR026377 for ; Fri, 8 Feb 2008 09:22:40 GMT Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 09:21:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Feb 2008 09:20:49 -0000 Message-ID: <680808427CF931459462C3D78CB5EC6001468ADD@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] gruu and SIP MESSAGE Thread-Index: AchpnhnrI4+6wb1OS6SE3EI8LjQNwgAlb1GQ From: "Attila Sipos" To: X-OriginalArrivalTime: 08 Feb 2008 09:21:47.0092 (UTC) FILETIME=[07275140:01C86A34] X-Scanned-By: MailControl A-08-00-01 (www.mailcontrol.com) on 10.70.0.147 Subject: Re: [Sip] gruu and SIP MESSAGE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sorry Salvatore, Clearly, my MESSAGE knowledge is not complete (didn't realise there was a special requirement not to include Contact). Thankfully, Paul and Jonathan have answered your questions. Regards, Attila -----Original Message----- From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] Sent: 07 February 2008 15:27 To: Attila Sipos Cc: sip@ietf.org Subject: Re: [Sip] gruu and SIP MESSAGE Hi Attila, sorry maybe I wasn't clear in my question. My problem is: I send out a MESSAGE to a AoR, and I want be sure that the receiver of the MESSAGE (if he wants to reply to the MESSAGE) will send out the reply to the same UA I used to send out the MESSAGE. Now, how is it possible if I can not insert a Contact header with my GRUU within the MESSAGE ? /sal Attila Sipos wrote: > You can use gruu in any non-REGISTER request. > > You don't need an INVITE, you only need to REGISTER the UA to get a > gruu. > > from http://www.jdrosen.net/papers/draft-ietf-sip-gruu-13.txt : > > 3.3. Using a GRUU > > Once a user agent obtains GRUUs from the registrar, it uses them in > several ways. First, it uses them as the contents of the Contact > header field in non-REGISTER requests and responses that it emits > (for example, an INVITE request and 200 OK response). > > Regards, > Attila > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Salvatore Loreto > Sent: 07 February 2008 11:40 > To: sip@ietf.org > Subject: [Sip] gruu and SIP MESSAGE > > Hi, > > I haven't found any references that GRUU can be used in SIP MESSAGE. > So, how do I ensure routing back to a specific client for SIP MESSAGE, > without be forced to associate a MESSAGE with an existing INVITE? > > regards > Sal > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 8 14:30:15 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C4B3A822B; Fri, 8 Feb 2008 14:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azhy85pYp-Ad; Fri, 8 Feb 2008 14:30:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22EBF3A81E2; Fri, 8 Feb 2008 14:30:07 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C43563A7E12; Fri, 8 Feb 2008 14:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080208223001.C43563A7E12@core3.amsl.com> Date: Fri, 8 Feb 2008 14:30:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-connect-reuse-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy, et al. Filename : draft-ietf-sip-connect-reuse-09.txt Pages : 20 Date : 2008-02-08 This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forward and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse should be predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TLS. For this reason, we only consider connection reuse for TLS over TCP and TLS over SCTP. A single connection cannot be reused for the TCP or SCTP transport between two peers, and this document provides insight into why this is the case. As a remedy, it suggests using two TCP connections (or two SCTP associations), each opened pro- actively towards the recipient by the sender. Finally, this document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-connect-reuse-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-connect-reuse-09.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: <2008-02-08142849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-08142849.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Feb 8 14:42:32 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63EC928C6CE; Fri, 8 Feb 2008 14:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbtmZK8ZOG0X; Fri, 8 Feb 2008 14:42:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0683328C6D7; Fri, 8 Feb 2008 14:37:46 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A4528C6D0 for ; Fri, 8 Feb 2008 14:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-bU7CIKKCZm for ; Fri, 8 Feb 2008 14:37:43 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 297E228C6F4 for ; Fri, 8 Feb 2008 14:35:07 -0800 (PST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m18MaVId017884 for ; Fri, 8 Feb 2008 16:36:31 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m18MaVj03628 for ; Fri, 8 Feb 2008 16:36:31 -0600 (CST) Message-ID: <47ACD96F.4090708@alcatel-lucent.com> Date: Fri, 08 Feb 2008 16:36:31 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF SIP List X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [Sip] connect-reuse-09 available X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Folks: I have just submitted connect-reuse-09 that includes Dale's and Hadriel's extensive WGLC review. The following is a synopsis of changes: - Added definitions for persistent connections, connect reuse and shared connections. - Updated S2 to stress that connection reuse is best done for TLS; for TCP and SCTP it should only be used with certain caveats. - Took out S5.2 and S5.3. - Added text saying that the alias table is not mandatory. - Considerably shortened S9.3 (Security considerations for TCP transports). - The malware and hi-jacking scenario is fairly convoluted to follow; replaced it with Hadriel's suggestion to keep it simple. - Redid the discussion on virtual servers based on Dale's review and subsequent WG discussion. The resulting section is much shorter and considerably clearer than before. The -09 version is available in the IETF archives for your review and comments: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-09.txt Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 8 15:32:58 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C813528C345; Fri, 8 Feb 2008 15:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjTqXF7pEMAJ; Fri, 8 Feb 2008 15:32:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D850A3A768F; Fri, 8 Feb 2008 15:32:57 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721A83A768F for ; Fri, 8 Feb 2008 15:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0zu53MQ28xu for ; Fri, 8 Feb 2008 15:32:55 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id A1EE33A6C33 for ; Fri, 8 Feb 2008 15:32:55 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k40so836569wah.25 for ; Fri, 08 Feb 2008 15:34:24 -0800 (PST) Received: by 10.115.92.2 with SMTP id u2mr7651529wal.139.1202513664348; Fri, 08 Feb 2008 15:34:24 -0800 (PST) Received: by 10.114.27.10 with HTTP; Fri, 8 Feb 2008 15:34:24 -0800 (PST) Message-ID: Date: Sat, 9 Feb 2008 00:34:24 +0100 From: "Lee Dryburgh" To: "IETF SIP List" MIME-Version: 1.0 Content-Disposition: inline Subject: [Sip] Skype Interview - SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The other week I interviewed Skype's general manager of audio and video. When asked a question regarding SIP, he responded: "I think that the vision of the early SIP founders has been largely unreal in the SIP world. SIP is typically just used for this mundane trunking application like the one we have or sending calls between two networks and it is just calls. The vision of multi-modal communications and rich end points has largely failed within the same and I think that a big part of this is that they did not pragmatically just solve basic problems like NAT traversal for example and they also evolved the specification to the point that it is no longer had its light weight appeal. So, we will see, SIP will continue to be dominant protocol in terms of this sort of narrowly defined scenarios but I think when it comes to rich communications, you are going to see more of this fragmentation. You are going to see some islands of providers who are just solving the problems. Just making it work for the user and not being religious about the protocol for example." For full transcript see: http://ecommmedia.com/blog/2008/02/jonathan-christensen-skype.html Thought this may be of interest. Regards Lee _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 11 21:06:09 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF7428CBEF; Mon, 11 Feb 2008 21:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcCptse+SSyl; Mon, 11 Feb 2008 21:06:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506CD3A6CAE; Mon, 11 Feb 2008 21:06:06 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E632A3A6AE5 for ; Mon, 11 Feb 2008 21:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nuM22szACmb for ; Mon, 11 Feb 2008 21:06:02 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 5140B28CBC2 for ; Mon, 11 Feb 2008 21:04:17 -0800 (PST) Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 12 Feb 2008 10:35:41 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1C55eac001625 for ; Tue, 12 Feb 2008 13:05:40 +0800 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 m1C55XGD016496 for ; Tue, 12 Feb 2008 05:05:40 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 13:03:48 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 13:04:26 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Sip] Target Refresh Request and Contact Header Thread-Index: AchtNL1u4WHRhTHxTJC/MlAREYbTeA== From: "Rockson Li (zhengyli)" To: , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 12 Feb 2008 05:03:48.0742 (UTC) FILETIME=[A6FD8A60:01C86D34] Authentication-Results: hkg-dkim-1; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Subject: Re: [Sip] Target Refresh Request and Contact Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1421906669==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1421906669== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86D34.A6D9896E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86D34.A6D9896E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Agree with Paul, =20 looks like Bug#: 723 was raised against this issue. =20 =20 >>IMO it should be MUST. I suspect is is weaker for 2543 compatibility. =20 >> Paul =20 Regards, Rockson Li (Zhengyu Li) Software Engineer Cisco R&D Center, Shanghai, PRC Phone(Office) : (8621) 24057003 Email: zhengyli@cisco.com =20 ------_=_NextPart_001_01C86D34.A6D9896E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
    Agree = with=20 Paul,
     
    looks = like Bug#:=20  723 was raised against this issue.
     
     
    >>IMO it=20 should be MUST. I suspect is is weaker for 2543=20 compatibility.
     
    >> Paul
     

    Regards,
    Rockson Li (Zhengyu Li)

    Software=20 Engineer
    Cisco R&D Center, Shanghai, PRC
    Phone(Office) : = (8621)=20 24057003
    Email: zhengyli@cisco.com

     
    ------_=_NextPart_001_01C86D34.A6D9896E-- --===============1421906669== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1421906669==-- From sip-bounces@ietf.org Wed Feb 13 22:37:23 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E762F28CCB4; Wed, 13 Feb 2008 22:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.374 X-Spam-Level: X-Spam-Status: No, score=0.374 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvh5Db-WmJqZ; Wed, 13 Feb 2008 22:37:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77D828C8DA; Wed, 13 Feb 2008 22:37:22 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E563A7037 for ; Wed, 13 Feb 2008 22:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh9dmStFcUXJ for ; Wed, 13 Feb 2008 22:37:20 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 752083A68B2 for ; Wed, 13 Feb 2008 22:37:20 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k40so539557wah.25 for ; Wed, 13 Feb 2008 22:38:42 -0800 (PST) Received: by 10.114.121.1 with SMTP id t1mr1064630wac.67.1202971121388; Wed, 13 Feb 2008 22:38:41 -0800 (PST) Received: by 10.114.76.17 with HTTP; Wed, 13 Feb 2008 22:38:41 -0800 (PST) Message-ID: <66cd252f0802132238y2b43fdd3x9398575316960ad4@mail.gmail.com> Date: Thu, 14 Feb 2008 17:38:41 +1100 From: "Hisham Khartabil" To: "Dean Willis" In-Reply-To: <236D2A23-6234-4F05-9308-952C5D14F767@softarmor.com> MIME-Version: 1.0 References: <236D2A23-6234-4F05-9308-952C5D14F767@softarmor.com> Cc: IETF SIP List Subject: Re: [Sip] Request to consider media control framework and requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1688686466==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1688686466== Content-Type: multipart/alternative; boundary="----=_Part_159_22231998.1202971121374" ------=_Part_159_22231998.1202971121374 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline My opinion is that those requirements need to go to sipping first for discussion as sipping is, as I understand it, chartered to agree on requirements before any extension work is taken up by the sip wg. Thanks, Hisham On 01/02/2008, Dean Willis wrote: > > > The media control group has produced a requirements-oriented draft > that they would like to meet with SIP, and would like the SIP working > group to take on the work of meeting those requirements. > > Here's a link to the draft: > > http://tools.ietf.org/html/draft-ietf-mediactrl-sip-control-framework-00 > > > Do you folks think these requirements are sufficiently cooked to work > with, or do we need to punt this football back to the senders or > perhaps lateral it to SIPPING for a little more thought? > > -- > Dean > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_159_22231998.1202971121374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
    My opinion is that those requirements need to go to sipping first for discussion as sipping is, as I understand it, chartered to agree on requirements before any extension work is taken up by the sip wg.
     
    Thanks,
    Hisham

     
    On 01/02/2008, Dean Willis <dean.willis@softarmor.com> wrote:

    The media control group has produced a requirements-oriented draft
    that they would like to meet with SIP, and would like the SIP working
    group to take on the work of meeting those requirements.

    Here's a link to the draft:

    http://tools.ietf.org/html/draft-ietf-mediactrl-sip-control-framework-00


    Do you folks think these requirements are sufficiently cooked to work
    with, or do we need to punt this football back to the senders or
    perhaps lateral it to SIPPING for a little more thought?

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

    ------=_Part_159_22231998.1202971121374-- --===============1688686466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1688686466==-- From sip-bounces@ietf.org Thu Feb 14 01:39:17 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48EDE28CDA9; Thu, 14 Feb 2008 01:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.674 X-Spam-Level: X-Spam-Status: No, score=-0.674 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SWJUO5c4AEz; Thu, 14 Feb 2008 01:39:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59EAD28CD71; Thu, 14 Feb 2008 01:38:47 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCC628CCC6 for ; Thu, 14 Feb 2008 01:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imNfTelG9vsk for ; Thu, 14 Feb 2008 01:38:45 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9096F28CCDC for ; Thu, 14 Feb 2008 01:38:40 -0800 (PST) Received: (qmail invoked by alias); 14 Feb 2008 09:40:01 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp012) with SMTP; 14 Feb 2008 10:40:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gzZY9xO+gJbYTK400CiKPMK11ffuATdcTZD5rCz +PWDKztlqfLMzq Message-ID: <47B40C71.60409@gmx.net> Date: Thu, 14 Feb 2008 11:40:01 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dan Wing References: <31e401c869aa$7b5e17e0$18726b80@cisco.com> In-Reply-To: <31e401c869aa$7b5e17e0$18726b80@cisco.com> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org Subject: Re: [Sip] R-REUSE, media-security-requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Dan, MUST specify, SHOULD implement and MAY use seems fine for me. I can imagine that not only end hosts would benefit from this mechanisms. There are two mechanisms that offered slightly different functionality regarding this security context reuse, namely * Re-use of a previously established security context based on state that has been established by both end points * Re-use of a previously established security context by caching security context only on the client side. I can imagine that both approaches are useful in certain scenarios. The requirement does not differentiate these two cases. Ciao Hannes Dan Wing wrote: > In draft-ietf-sip-media-security-requirements-02, I changed the following > requirement from MAY to MUST: > > R-REUSE The media security key management protocol MUST support the > re-use of a previously established security context, and > implementations SHOULD implement the re-use mechanism. > > A discussion of this requirement appears in Section 4.6 of the document, > http://tools.ietf.org/html/draft-ietf-sip-media-security-requirements-02#secti > on-4.6 > > > Does anyone have equipment that they would implement this feature in? In the > past, I have heard that some embedded devices (intelligent SIMs) could benefit > from key re-use. > > Would it be reasonable to soften this requirement back to a MAY? > > -d > > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 14 02:34:25 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03C33A7083; Thu, 14 Feb 2008 02:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA11QWRcFawi; Thu, 14 Feb 2008 02:34:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62E33A706A; Thu, 14 Feb 2008 02:34:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C2F3A6F65 for ; Thu, 14 Feb 2008 02:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NwcTe+-1EfJ for ; Thu, 14 Feb 2008 02:34:22 -0800 (PST) Received: from gws03.hcl.in (gws03.hcl.in [203.105.186.19]) by core3.amsl.com (Postfix) with ESMTP id 9678F3A706D for ; Thu, 14 Feb 2008 02:34:21 -0800 (PST) Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 8ABC237C570; Thu, 14 Feb 2008 16:05:39 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTPid 769D537C382; Thu, 14 Feb 2008 16:05:15 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 16:05:14 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Feb 2008 16:05:16 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound flow-token and (instance-id + reg-id) use case? Thread-Index: Achu9Umm9CagGIf5Rh+0ipCy/SoS/Q== From: "Karthikeyan Gopal , TLS-Chennai" To: , X-OriginalArrivalTime: 14 Feb 2008 10:35:15.0291 (UTC) FILETIME=[491F9AB0:01C86EF5] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-11.4905 TC:1F TRN:44 TV:5.0.1023(15728.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [Sip] Outbound flow-token and (instance-id + reg-id) use case? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2097678224==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2097678224== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86EF5.4719E6BF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86EF5.4719E6BF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, In SIP outbound draft 11 it was mentioned that flow back to particular UA can be Identified based on instance-id and reg-id=2E Then what is the need for flow-token=2E Is this flow-token is used only in case of edge-proxy support? If it is so what is the need of instance-id in case of edge-proxy=2E Thanks & Regards, Karthikeyan=2EG =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C86EF5.4719E6BF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    Hi All,

        In SIP outbound draft 11 it was= mentioned that flow back to particular UA can be Identified based on instance-id and reg-id=2E

    Then what is the need for flow-token= =2E

    Is this flow-token is used only in case of edge-proxy support?

    If it is so what is the need of instance-id in case of edge-proxy=2E

    Thanks & Regards,

    Karthikeyan=2EG

     

    DISCLAIMER:
    ---------------------------------------------------------------------------= --------------------------------------------

    The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
    It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
    this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
    Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
    this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
    received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
    attachments please check them for viruses and defect=2E

    ---------------------------------------------------------------------------= --------------------------------------------
    ------_=_NextPart_001_01C86EF5.4719E6BF-- --===============2097678224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2097678224==-- From sip-bounces@ietf.org Thu Feb 14 02:42:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BAC28CDEB; Thu, 14 Feb 2008 02:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvY6TQc9O1LT; Thu, 14 Feb 2008 02:42:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E0C3A7066; Thu, 14 Feb 2008 02:42:33 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F0B28C9AA for ; Thu, 14 Feb 2008 02:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1zvnyAU7vM0 for ; Thu, 14 Feb 2008 02:42:28 -0800 (PST) Received: from gws04.hcl.in (gws04.hcl.in [203.105.186.20]) by core3.amsl.com (Postfix) with ESMTP id 93EFC3A7066 for ; Thu, 14 Feb 2008 02:42:27 -0800 (PST) Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id C14CC360753; Thu, 14 Feb 2008 16:13:47 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid A0E523606D6; Thu, 14 Feb 2008 16:13:47 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 16:13:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Feb 2008 16:13:23 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Outbound : How to identify edge-proxy ? Thread-Index: Achu9mwM5rXwELScSFugZlxyN6oL1w== From: "Karthikeyan Gopal , TLS-Chennai" To: , X-OriginalArrivalTime: 14 Feb 2008 10:43:47.0476 (UTC) FILETIME=[7A68D540:01C86EF6] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-10.3791 TC:03 TRN:46 TV:5.0.1023(15728.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [Sip] SIP Outbound : How to identify edge-proxy ? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0268987901==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0268987901== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86EF6.68B22895" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86EF6.68B22895 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, How to identify edge-proxy in this topology? =20 UA - P1 - P2 - P3 - REGISTRAR=20 =20 Here in this case P1 and P3 are Edge proxy's as per Path header RFC 3327=2E =20 =20 Edge proxy P1 can be identified based on VIA=2E =20 Then how to edge proxy identify P3? =20 Thanks & Regards, Karthikeyan=2EG =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C86EF6.68B22895 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    Hi All,

       How to identify edge-proxy in this= topology?

     

    UA – P1 – P2 – P3 – REGISTRAR=

     

    Here in this case P1 and P3 are Edge proxy’s as= per Path header RFC 3327=2E

     

     

    Edge proxy P1 can be identified based on VIA= =2E

     

    Then how to edge proxy identify= P3?

     

    Thanks & Regards,

    Karthikeyan=2EG

     

    DISCLAIMER:
    ---------------------------------------------------------------------------= --------------------------------------------

    The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
    It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
    this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
    Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
    this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
    received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
    attachments please check them for viruses and defect=2E

    ---------------------------------------------------------------------------= --------------------------------------------
    ------_=_NextPart_001_01C86EF6.68B22895-- --===============0268987901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0268987901==-- From sip-bounces@ietf.org Thu Feb 14 02:48:39 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B1A28C9AA; Thu, 14 Feb 2008 02:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.493 X-Spam-Level: * X-Spam-Status: No, score=1.493 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04cSgB7hfdPZ; Thu, 14 Feb 2008 02:48:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B2828CDB7; Thu, 14 Feb 2008 02:48:37 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815D828C9AA for ; Thu, 14 Feb 2008 02:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5-daJeCFCWZ for ; Thu, 14 Feb 2008 02:48:34 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id AE42528CDF8 for ; Thu, 14 Feb 2008 02:48:33 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so189169fgg.41 for ; Thu, 14 Feb 2008 02:49:54 -0800 (PST) Received: by 10.86.81.14 with SMTP id e14mr1047079fgb.42.1202986194537; Thu, 14 Feb 2008 02:49:54 -0800 (PST) Received: by 10.86.83.15 with HTTP; Thu, 14 Feb 2008 02:49:54 -0800 (PST) Message-ID: <14b80930802140249o407c5fefy737dddcacb02fa52@mail.gmail.com> Date: Thu, 14 Feb 2008 16:19:54 +0530 From: "Hulbut hulbut" To: "Karthikeyan Gopal , TLS-Chennai" In-Reply-To: MIME-Version: 1.0 References: Cc: sip@ietf.org, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Outbound flow-token and (instance-id + reg-id) use case? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1308926543==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1308926543== Content-Type: multipart/alternative; boundary="----=_Part_528_6841575.1202986194490" ------=_Part_528_6841575.1202986194490 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Pls see comments inline: -- regards Hul On Thu, Feb 14, 2008 at 4:05 PM, Karthikeyan Gopal , TLS-Chennai < g_karthikeyan@hcl.in> wrote: > Hi All, > > In SIP outbound draft 11 it was mentioned that flow back to particular > UA can be Identified based on instance-id and reg-id. > [Hb] I dont think Instance-id and reg-id can be used to identify the ip address of user. They are just used to identify the uniqueness of device. > Then what is the need for flow-token. > [Hb]Flow token actually contains information of src ip address and port(Flow token = HMAC(users address, local address, key)). Thus a stateless proxy need not have any other information to correctly send the request to UE. > > Is this flow-token is used only in case of edge-proxy support? > [Hb] Yes, it appears that flow token is used only by edge proxy. > If it is so what is the need of instance-id in case of edge-proxy. > [Hb] Flow token may not be usefull in case of edge proxy, but surely as per outbound section 7(bullet 3), its usefull for Authoritative proxies and SCSCF (in IMS) . > Thanks & Regards, > > Karthikeyan.G > > > DISCLAIMER: > > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect > the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > > ----------------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_528_6841575.1202986194490 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

    Pls see comments inline:

    -- regards
    Hul

    On Thu, Feb 14, 2008 at 4:05 PM, Karthikeyan Gopal , TLS-Chennai <g_karthikeyan@hcl.in> wrote:

    Hi All,

        In SIP outbound draft 11 it was mentioned that flow back to particular UA can be Identified based on instance-id and reg-id.

    [Hb] I dont think Instance-id and reg-id can be used to identify the ip address of user. They are just used to identify the uniqueness of device.

    Then what is the need for flow-token.

    [Hb]Flow token actually contains information of src ip address and port(Flow token  = HMAC(users address, local address, key)). Thus a stateless proxy need not have any other information to correctly send the request to UE.


    Is this flow-token is used only in case of edge-proxy support?

    [Hb] Yes, it appears that flow token is used only by edge proxy.
     

    If it is so what is the need of instance-id in case of edge-proxy.

    [Hb] Flow token may not be usefull in case of edge proxy, but surely as per outbound section 7(bullet 3), its usefull for Authoritative proxies and SCSCF (in IMS)  .

    Thanks & Regards,

    Karthikeyan.G

     

    DISCLAIMER:
    -----------------------------------------------------------------------------------------------------------------------

    The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
    It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
    this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
    Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
    this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
    received this email in error please delete it and notify the sender immediately. Before opening any mail and
    attachments please check them for viruses and defect.

    -----------------------------------------------------------------------------------------------------------------------

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

    ------=_Part_528_6841575.1202986194490-- --===============1308926543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1308926543==-- From sip-bounces@ietf.org Thu Feb 14 08:06:55 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8A528D031; Thu, 14 Feb 2008 08:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z08sx2LWpUvx; Thu, 14 Feb 2008 08:06:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E956828CF42; Thu, 14 Feb 2008 08:06:53 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B5B28CF42 for ; Thu, 14 Feb 2008 08:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31SVS4WwBz3N for ; Thu, 14 Feb 2008 08:06:50 -0800 (PST) Received: from ds3000.pernau.at (ds3000.pernau.at [88.198.53.113]) by core3.amsl.com (Postfix) with ESMTP id 8A99928CEC3 for ; Thu, 14 Feb 2008 08:06:50 -0800 (PST) Received: from [10.10.0.51] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTP id DCC6D1080023; Thu, 14 Feb 2008 17:08:10 +0100 (CET) Message-ID: <47B4676A.70501@pernau.at> Date: Thu, 14 Feb 2008 17:08:10 +0100 From: Klaus Darilion User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jeroen van Bemmel References: <47610985.6080108@zonnet.nl> In-Reply-To: <47610985.6080108@zonnet.nl> Cc: IETF SIP List Subject: Re: [Sip] ABNF error in RFC4474 (SIP Identity)? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Jeroen! Have you received any answers on this? regards klaus Jeroen van Bemmel schrieb: > Jon, Cullen, > > In RFC4474 there is an example (page 19): > > Identity: > "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa > ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn > FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" > > while the ABNF says: > > Identity = "Identity" HCOLON signed-identity-digest > signed-identity-digest = LDQUOT *32LHEX *RDQUOT > > "32LHEX" means 32 hex digits in lower case (as used for e.g. > request-digest in RFC3261), but this does not seem to be the intention > 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 14 10:17:03 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53CA3A70CD; Thu, 14 Feb 2008 10:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE2+ehGQY+GU; Thu, 14 Feb 2008 10:17:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E1D3A68A4; Thu, 14 Feb 2008 10:17:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4C03A68A4 for ; Thu, 14 Feb 2008 10:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66Pw32cW3BN9 for ; Thu, 14 Feb 2008 10:17:00 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 02E1C3A6824 for ; Thu, 14 Feb 2008 10:16:59 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m1EIILPb012785 for ; Thu, 14 Feb 2008 12:18:21 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 12:18:10 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 19:18:08 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Feb 2008 19:18:07 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001C2F61F@DEEXC1U01.de.lucent.com> In-Reply-To: <66cd252f0802132238y2b43fdd3x9398575316960ad4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Request to consider media control framework andrequirements Thread-index: Achu1EdjrYV7aFVDRh29WmnjbMEytQAXx8vg References: <236D2A23-6234-4F05-9308-952C5D14F767@softarmor.com> <66cd252f0802132238y2b43fdd3x9398575316960ad4@mail.gmail.com> From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 14 Feb 2008 18:18:08.0435 (UTC) FILETIME=[F3351030:01C86F35] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Sip] Request to consider media control framework andrequirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The SIP, SIPPING and MEDIACTRL chairs (or at least a representative collection of them) did get together to consider this issue, and decided that as the work (as currently proposed) did not in fact extend SIP, that MEDIACTRL should retain the work. SDP extensions are proposed to MMUSIC, and that would appear to be appropriate. At some point when the work is complete enough for review, it was agreed that RAI wide review of this document should occur, and one of the review experts in the SIP WG will be jumped on at that point to review the solution. We did not discuss whether the solution adopted by the draft was the correct solution - if people in the SIP WG have concerns, then please address them to the MEDIACTRL WG. If you are not participants in that WG then we (the SIP chairs) will be pleased to forward on comments. Regards Keith PS: My understanding of the various charters is that SIP does not generate requirements for development of SIP, except in the security area. However it can charter work based on requirements from any appropriate working group, which includes among others, both SIPPING and MEDIACTRL. I suspect the ADs would want to be confident that the appropriate experts had contributed to the appropriate requirements. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hisham Khartabil Sent: Thursday, February 14, 2008 6:39 AM To: Dean Willis Cc: IETF SIP List Subject: Re: [Sip] Request to consider media control framework andrequirements My opinion is that those requirements need to go to sipping first for discussion as sipping is, as I understand it, chartered to agree on requirements before any extension work is taken up by the sip wg. Thanks, Hisham On 01/02/2008, Dean Willis wrote: The media control group has produced a requirements-oriented draft that they would like to meet with SIP, and would like the SIP working group to take on the work of meeting those requirements. Here's a link to the draft: http://tools.ietf.org/html/draft-ietf-mediactrl-sip-control-framework-00 Do you folks think these requirements are sufficiently cooked to work with, or do we need to punt this football back to the senders or perhaps lateral it to SIPPING for a little more thought? -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 14 11:53:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2299E28D14B; Thu, 14 Feb 2008 11:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3E7df3dm2Fb; Thu, 14 Feb 2008 11:53:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E62A28D106; Thu, 14 Feb 2008 11:53:33 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C9F28D106 for ; Thu, 14 Feb 2008 11:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l80HkJ7YeKZ4 for ; Thu, 14 Feb 2008 11:53:31 -0800 (PST) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id D757328C582 for ; Thu, 14 Feb 2008 11:53:31 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id pXTX1Y0060lTkoCAA01o00; Thu, 14 Feb 2008 19:54:14 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id pXus1Y0040umElk8Q00000; Thu, 14 Feb 2008 19:54:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=N_PsSKeB4D8A:10 a=zIhgnLap_1hwP7fPEh8A:9 a=fQcXxe-VPRWcajDIoxZ0Vr0y1coA:4 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m1EJsp07012268 for ; Thu, 14 Feb 2008 14:54:51 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m1EJspRp012264; Thu, 14 Feb 2008 14:54:51 -0500 Date: Thu, 14 Feb 2008 14:54:51 -0500 Message-Id: <200802141954.m1EJspRp012264@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <47B4676A.70501@pernau.at> (klaus.mailinglists@pernau.at) References: <47610985.6080108@zonnet.nl> <47B4676A.70501@pernau.at> Subject: Re: [Sip] ABNF error in RFC4474 (SIP Identity)? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jeroen van Bemmel schrieb: > > In RFC4474 there is an example (page 19): > > Identity: > "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa > ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn > FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" > > while the ABNF says: > > Identity = "Identity" HCOLON signed-identity-digest > signed-identity-digest = LDQUOT *32LHEX *RDQUOT > > "32LHEX" means 32 hex digits in lower case (as used for e.g. > request-digest in RFC3261), but this does not seem to be the intention > here? Even more informative is this section: When the 'rsa-sha1' algorithm [the default - DW] is specified in the 'alg' parameter of Identity-Info, the hash and signature MUST be generated as follows: compute the results of signing this string with sha1WithRSAEncryption as described in RFC 3370 [7] and base64 encode the results as specified in RFC 3548 [8]. [...] The result is placed in the Identity header field. So the text of the specification says that the Identity value must be a base64 string, while the ABNF gives it as hex digits. Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 15 07:44:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2935728D262; Fri, 15 Feb 2008 07:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dS1-phz4aW7; Fri, 15 Feb 2008 07:44:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D98328D1F1; Fri, 15 Feb 2008 07:43:46 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419A028D1F1 for ; Fri, 15 Feb 2008 07:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnKShFGrtiiz for ; Fri, 15 Feb 2008 07:43:41 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 28E1A28D070 for ; Fri, 15 Feb 2008 07:43:41 -0800 (PST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m1FFiw92024930; Fri, 15 Feb 2008 09:44:59 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m1FFiwj10272; Fri, 15 Feb 2008 09:44:58 -0600 (CST) Message-ID: <47B5B37A.1000901@alcatel-lucent.com> Date: Fri, 15 Feb 2008 09:44:58 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF SIP List X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: Brian E Carpenter , Brett Tate Subject: [Sip] draft-ietf-sip-ipv6-abnf-fix-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Folks: We have submitted draft-ietf-sip-ipv6-abnf-fix-00 as part of the SIP Essential Corrections Process. This memo corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. Until the draft is available in the archives, you can get a copy from: https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/draft-ietf-sip-ipv6-abnf-fix-00.txt https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-ipv6-abnf/draft-ietf-sip-ipv6-abnf-fix-00.html The ABNF part of the draft was already documented in the predecessor version (draft-gurbani-sip-ipv6-abnf-fix-00). The new draft includes the additional discussion we had on the WG list around URI comparison when textual IP addresses occur in the URI. Please review sections related to that portion. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 15 08:01:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729D028D2C7; Fri, 15 Feb 2008 08:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx8Ytbw4cN0A; Fri, 15 Feb 2008 08:01:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F2D28D2B4; Fri, 15 Feb 2008 08:00:04 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B468D28D2A2; Fri, 15 Feb 2008 08:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080215160001.B468D28D2A2@core3.amsl.com> Date: Fri, 15 Feb 2008 08:00:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-ipv6-abnf-fix-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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 : Essential correction for IPv6 ABNF and URI comparison in RFC3261 Author(s) : V. Gurbani, et al. Filename : draft-ietf-sip-ipv6-abnf-fix-00.txt Pages : 9 Date : 2008-02-15 This memo corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-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-ipv6-abnf-fix-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-ipv6-abnf-fix-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: <2008-02-15074555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-ipv6-abnf-fix-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-ipv6-abnf-fix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-15074555.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Feb 15 14:07:30 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49BA28C397; Fri, 15 Feb 2008 14:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.889 X-Spam-Level: X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=-3.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjSrvoJAv3C4; Fri, 15 Feb 2008 14:07:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA573A6AE0; Fri, 15 Feb 2008 14:07:29 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872FD3A6B57 for ; Fri, 15 Feb 2008 14:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WIGLNaxaBt4 for ; Fri, 15 Feb 2008 14:07:27 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8B7153A68CB for ; Fri, 15 Feb 2008 14:07:27 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 15 Feb 2008 14:08:48 -0800 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 m1FM8me6014483; Fri, 15 Feb 2008 14:08:48 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1FM8SJi014657; Fri, 15 Feb 2008 22:08:43 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 17:08:40 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 17:08:39 -0500 Message-ID: <47B60D74.9030403@cisco.com> Date: Fri, 15 Feb 2008 17:08:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: SIP IETF , "Elwell, John" References: <008501c8701a$b492a870$c4f0200a@cisco.com> In-Reply-To: <008501c8701a$b492a870$c4f0200a@cisco.com> X-OriginalArrivalTime: 15 Feb 2008 22:08:39.0945 (UTC) FILETIME=[51D7BF90:01C8701F] Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Sip] draft-elwell-sip-e164-problem-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John, Thanks for opening this can of worms. It is a very important problem to solve. Did you intend for this to be discussed on the SIP WG mailing list? > When a UA receives an E.164 number represented as a SIP URI in a From > header field, what does this say about the source of the request? Of > course, it should indicate that the request originated at a user who > has a right to use that E.164 number and who can be reached by > submitting a request targeted at that E.164 number. I'm not convinced about the above. It depends on what you mean by "should". The existing rules for use of SIP URIs don't require that the user be reachable from the PSTN, or that the user have any relationship to the pstn number. The user part is still wholly the responsibility of the domain. A corollary is that there are significant issues about how the recipient displays the identity of the caller. If the identity is displayed based solely on the e.164 number, without the domain, then it is a misrepresentation precisely because reverse routing using the e.164 number may well not reach the same place. > However, the last > of these issues is a far more serious problem: the user expects a > communication partner to be from a particular domain (the E.164 > number is not necessarily an important factor). Seeing that domain > in the From: URI, coupled with authentication by means of the > Identity header field, would satisfy the user's expectation. Seeing > a different domain, that of an intermediate service provider, which > may or may not be known to the user, would not satisfy the user's > expectation. The user might not be prepared to accept the unexpected > URI and might decide not to proceed with the communication. This argument isn't very compelling to me. Nobody using the PSTN expects to see the enterprise name as part of the calling "number". PSTN caller id with calling name might be relevant, but it isn't a domain name. If you want to use sip domain names for authorization purposes, then it makes more sense to use *real* sip URIs. > REQ2: When a UAS receives a SIP request that includes a SIP or SIPS > URI identifying the originating user, if that URI contains an > E.164 number that number alone, when placed in a TEL URI, must be > suitable for routing a request back to the originating user. Your examples all include ;user=phone, but none of the text says that you mean that when talking about sip URIs that contain E.164 numbers. I am somewhat inclined to agree with this requirement if user=phone is present, but otherwise not. IMO, rather than trying to fix up the handling of sip URIs containing phone numbers we would be better off trying to fix up the use of TEL URIs. The main limitation of TEL URIs is the inability of sip identity to deal with them. What we need is a way to extend identity to them in such a way that it truly proves ownership of the number, in whatever sense of ownership we want it to mean. I think that can be achieved by translating a TEL URI to its ENUM dotted inverted number domain name format, and then applying sip identity to that. It means that if I am the end user assigned usage of TEL:+1978-555-1234 then *I* or some middle box acting as my agent, must have a certificate for 4.3.2.1.5.5.5.8.7.9.1.e164.ansi. Thanks, Paul _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 15 15:11:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EADAA3A6BCB; Fri, 15 Feb 2008 15:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=-2.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UuZQFZq3JYr; Fri, 15 Feb 2008 15:11:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F163A6B8C; Fri, 15 Feb 2008 15:11:46 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982433A6B8C for ; Fri, 15 Feb 2008 15:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeH8rvTLPteR for ; Fri, 15 Feb 2008 15:11:44 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id 48AB23A6B46 for ; Fri, 15 Feb 2008 15:11:43 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Fri, 15 Feb 2008 15:13:03 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m1FNAHin017826; Fri, 15 Feb 2008 15:10:17 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id m1FNCnFV018461; Fri, 15 Feb 2008 15:12:50 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 08:12:47 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 15:12:37 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22019E073F@namail5.corp.adobe.com> In-Reply-To: <47B60D74.9030403@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-elwell-sip-e164-problem-statement-00.txt Thread-Index: AchwH2p0LRIK24lpSNSB3YWwX8cy9AACBtwg References: <008501c8701a$b492a870$c4f0200a@cisco.com> <47B60D74.9030403@cisco.com> From: "Henry Sinnreich" To: "Paul Kyzivat" , "SIP IETF" , "Elwell, John" X-OriginalArrivalTime: 15 Feb 2008 23:12:47.0832 (UTC) FILETIME=[475CB580:01C87028] Subject: Re: [Sip] draft-elwell-sip-e164-problem-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree and have an additional question: What happens if the phone number is actually owned by the end user due to number portability? It seems in this case a database service is the essential ingredient. This is an excellent I-D and I suggest we use it to clear up all these issues. Thanks, Henry -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, February 15, 2008 4:09 PM To: SIP IETF; Elwell, John Subject: Re: [Sip] draft-elwell-sip-e164-problem-statement-00.txt John, Thanks for opening this can of worms. It is a very important problem to solve. Did you intend for this to be discussed on the SIP WG mailing list? > When a UA receives an E.164 number represented as a SIP URI in a From > header field, what does this say about the source of the request? Of > course, it should indicate that the request originated at a user who > has a right to use that E.164 number and who can be reached by > submitting a request targeted at that E.164 number. I'm not convinced about the above. It depends on what you mean by "should". The existing rules for use of SIP URIs don't require that the user be reachable from the PSTN, or that the user have any relationship to the pstn number. The user part is still wholly the responsibility of the domain. A corollary is that there are significant issues about how the recipient displays the identity of the caller. If the identity is displayed based solely on the e.164 number, without the domain, then it is a misrepresentation precisely because reverse routing using the e.164 number may well not reach the same place. > However, the last > of these issues is a far more serious problem: the user expects a > communication partner to be from a particular domain (the E.164 > number is not necessarily an important factor). Seeing that domain > in the From: URI, coupled with authentication by means of the > Identity header field, would satisfy the user's expectation. Seeing > a different domain, that of an intermediate service provider, which > may or may not be known to the user, would not satisfy the user's > expectation. The user might not be prepared to accept the unexpected > URI and might decide not to proceed with the communication. This argument isn't very compelling to me. Nobody using the PSTN expects to see the enterprise name as part of the calling "number". PSTN caller id with calling name might be relevant, but it isn't a domain name. If you want to use sip domain names for authorization purposes, then it makes more sense to use *real* sip URIs. > REQ2: When a UAS receives a SIP request that includes a SIP or SIPS > URI identifying the originating user, if that URI contains an > E.164 number that number alone, when placed in a TEL URI, must be > suitable for routing a request back to the originating user. Your examples all include ;user=phone, but none of the text says that you mean that when talking about sip URIs that contain E.164 numbers. I am somewhat inclined to agree with this requirement if user=phone is present, but otherwise not. IMO, rather than trying to fix up the handling of sip URIs containing phone numbers we would be better off trying to fix up the use of TEL URIs. The main limitation of TEL URIs is the inability of sip identity to deal with them. What we need is a way to extend identity to them in such a way that it truly proves ownership of the number, in whatever sense of ownership we want it to mean. I think that can be achieved by translating a TEL URI to its ENUM dotted inverted number domain name format, and then applying sip identity to that. It means that if I am the end user assigned usage of TEL:+1978-555-1234 then *I* or some middle box acting as my agent, must have a certificate for 4.3.2.1.5.5.5.8.7.9.1.e164.ansi. Thanks, Paul _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 15 16:54:17 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37613A6B18; Fri, 15 Feb 2008 16:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwhUGNEL-uqg; Fri, 15 Feb 2008 16:54:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C67D28C281; Fri, 15 Feb 2008 16:53:46 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99A428C281 for ; Fri, 15 Feb 2008 16:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6+wHc3a9sCa for ; Fri, 15 Feb 2008 16:53:45 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1608928C277 for ; Fri, 15 Feb 2008 16:53:45 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Feb 2008 19:55:05 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1G0t5Mu005031 for ; Fri, 15 Feb 2008 19:55:05 -0500 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 m1G0t5SC017549 for ; Sat, 16 Feb 2008 00:55:05 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 19:55:04 -0500 Received: from [10.82.249.68] ([10.82.249.68]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 19:55:04 -0500 Message-ID: <47B6345B.4030807@cisco.com> Date: Fri, 15 Feb 2008 19:54:51 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List X-OriginalArrivalTime: 16 Feb 2008 00:55:04.0718 (UTC) FILETIME=[913B32E0:01C87036] Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I just submitted a new I-D, which proposes a protocol called TOTE: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt Basically, TOTE provides the ability to exchange MIME objects of any type and "purpose" over a tcp/tls connection established e2e through SDP O/A procedures and ICE-tcp. This ties into the INFO disussion; it provides the media-plane equivalent of the INFO-events framework. This draft should arguably go in mmusic but since the INFO debate is happening here I submitted it as a -sip. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 15 17:31:25 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B149E3A6877; Fri, 15 Feb 2008 17:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=-1.671, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9T5ztjAEJ5O; Fri, 15 Feb 2008 17:31:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9871F3A68CB; Fri, 15 Feb 2008 17:31:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E3C3A68CB for ; Fri, 15 Feb 2008 17:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8qxd-FNY9+U for ; Fri, 15 Feb 2008 17:31:18 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B50D23A6877 for ; Fri, 15 Feb 2008 17:31:18 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Feb 2008 17:32:39 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1G1Wcnd015646; Fri, 15 Feb 2008 17:32:38 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1G1WbJg018603; Sat, 16 Feb 2008 01:32:38 GMT From: "Dan Wing" To: References: <31e401c869aa$7b5e17e0$18726b80@cisco.com> <47B40C71.60409@gmx.net> Date: Fri, 15 Feb 2008 17:32:37 -0800 Message-ID: <02b701c8703b$d0929d70$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47B40C71.60409@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achu7ZU6/RPtClgdQrqh0XpKMmmM0wBTY/lA Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] R-REUSE, media-security-requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, February 14, 2008 1:40 AM > To: Dan Wing > Cc: sip@ietf.org > Subject: Re: [Sip] R-REUSE, media-security-requirements > > Hi Dan, > > MUST specify, SHOULD implement and MAY use seems fine for me. So far you're the only person to respond to my email. I had asked for feedback because I had received push-back on the requirement to store state from previous sessions, because such storage weakens the security of the system by destroying perfect forward secrecy. PFS is a 'must be able to support' requirement in the document right now. Any thoughts on this requirements collision? > I can imagine that not only end hosts would benefit from this > mechanisms. > > There are two mechanisms that offered slightly different > functionality regarding this security context reuse, namely > * Re-use of a previously established security context based on state > that has been established by both end points > * Re-use of a previously established security context by caching > security context only on the client side. On the second bullet, I assume you are referring to RFC5077 ("TLS Session Resumption without Server-Side State")? > I can imagine that both approaches are useful in certain > scenarios. The requirement does not differentiate these two cases. Should the requirement be reworded to differentiate between those two cases? -d > Ciao > Hannes > > > > > Dan Wing wrote: > > In draft-ietf-sip-media-security-requirements-02, I changed > the following > > requirement from MAY to MUST: > > > > R-REUSE The media security key management protocol MUST > support the > > re-use of a previously established security context, and > > implementations SHOULD implement the re-use mechanism. > > > > A discussion of this requirement appears in Section 4.6 of > the document, > > > http://tools.ietf.org/html/draft-ietf-sip-media-security-requi > rements-02#secti > > on-4.6 > > > > > > Does anyone have equipment that they would implement this > feature in? In the > > past, I have heard that some embedded devices (intelligent > SIMs) could benefit > > from key re-use. > > > > Would it be reasonable to soften this requirement back to a MAY? > > > > -d > > > > > > > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 16 00:23:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00D628C0E4; Sat, 16 Feb 2008 00:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8ebElYfjyp2; Sat, 16 Feb 2008 00:23:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B123C3A6959; Sat, 16 Feb 2008 00:23:44 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC2F3A693D for ; Sat, 16 Feb 2008 00:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxifrt3p-HVt for ; Sat, 16 Feb 2008 00:23:42 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 68BE43A67B3 for ; Sat, 16 Feb 2008 00:23:42 -0800 (PST) Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1G8NeHd002829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 16 Feb 2008 02:23:41 -0600 Message-ID: <47B69D8C.8060605@softarmor.com> Date: Sat, 16 Feb 2008 02:23:40 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: [Sip] Headsup on Short Agenda for IETF 71 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It appears that we will get only 2 hours of working group meeting time in Philadelphia. That means we're going to have to be VERY efficient with our use of time. What are the mosr important things? The things we REALLY need to talk about? Inquiring minds want to know. Here are the things on our charter we're currently late on: 1) Outbound 2) SIPS (which I think is pretty much done) 3) Diagnostic Responses 4) Example security flows 5) Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP 6) Location Conveyance with SIP 7) Connection reuse mechanism 8) Session Policies 9) Etags in conditional notification 10) Using SAML for SIP 11) New resource priority namespaces for DISA 12) Requirements for media keying 13) X.509 Certificates for TLS use in SIP (done?) 14) X.509 extended key usage for SIP (done?) 15) Roadmap for SIP 16) Delivering request-URI and parameters to UAS via proxy 17) Establishment of secure media sessions using DTLS-SRT 18) MIME body handling in SIP 19) Identify requirements for test matrix to move SIP to Draft Standard And the things we aren't late on yet: 1) Essential corrections to RFC 3261 (1st batch) 2) Mechanisms for UA initiated privacy to WGLC So c'mon, people. What do we need to talk about? And why aren't we talking about it on the list already? -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 16 00:41:59 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7FC28C0EA; Sat, 16 Feb 2008 00:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtz4LYjt88OZ; Sat, 16 Feb 2008 00:41:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5833A696B; Sat, 16 Feb 2008 00:41:57 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C023A6974 for ; Sat, 16 Feb 2008 00:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+vJlZ1Ys6cN for ; Sat, 16 Feb 2008 00:41:54 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5B5353A696B for ; Sat, 16 Feb 2008 00:41:54 -0800 (PST) Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1G8fkow002991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Feb 2008 02:41:48 -0600 Message-ID: <47B6A1CB.1080603@softarmor.com> Date: Sat, 16 Feb 2008 02:41:47 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List References: <47B6345B.4030807@cisco.com> In-Reply-To: <47B6345B.4030807@cisco.com> Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > I just submitted a new I-D, which proposes a protocol called TOTE: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt > > Basically, TOTE provides the ability to exchange MIME objects of any > type and "purpose" over a tcp/tls connection established e2e through SDP > O/A procedures and ICE-tcp. This ties into the INFO disussion; it > provides the media-plane equivalent of the INFO-events framework. > > This draft should arguably go in mmusic but since the INFO debate is > happening here I submitted it as a -sip. Very cool draft. So with the right MIME object (octet-stream?) and Purpose token (iptunnel?), we appear to have an instant answer for the "How do we use SIP to set up a VPN connection" problem. Subject to the constraints of TCP, of course, which some people don't like. And we have a solution for the problem of establishing a device management connection with a device that's behind a NAT router. Seriously: This draft is an exact answer to the question "what is the extension model for SIP?" We very much need to come to an agreement on that model, and stop extending SIP along three different and incompatible axes. If we choose the model of TOTE, then we might start considering deprecation of INFO, MESSAGE, SUBSCRIBE, and NOTIFY. We can also probably deprecate MSRP. And PUBLISH, of course. This would really clean up the protocol suite, at least for one way of looking at it. This is a lot to think about. So start thinking! -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 16 02:17:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC4328C15C; Sat, 16 Feb 2008 02:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.58 X-Spam-Level: X-Spam-Status: No, score=-0.58 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oINCFQpfScwt; Sat, 16 Feb 2008 02:17:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57D03A69A3; Sat, 16 Feb 2008 02:17:50 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4C428C120 for ; Sat, 16 Feb 2008 02:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lb20JBhGTBu for ; Sat, 16 Feb 2008 02:17:48 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 24CA73A67DF for ; Sat, 16 Feb 2008 02:17:47 -0800 (PST) Received: (qmail invoked by alias); 16 Feb 2008 10:17:46 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp041) with SMTP; 16 Feb 2008 11:17:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+s+v0CMcyshvtAivw5iKa30WXFpyaTJgSLBYu3mK YmuQQGLIQ9IMmK Message-ID: <47B6B843.4050809@gmx.net> Date: Sat, 16 Feb 2008 12:17:39 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dan Wing References: <31e401c869aa$7b5e17e0$18726b80@cisco.com> <47B40C71.60409@gmx.net> <02b701c8703b$d0929d70$c4f0200a@cisco.com> In-Reply-To: <02b701c8703b$d0929d70$c4f0200a@cisco.com> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org Subject: Re: [Sip] R-REUSE, media-security-requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Dan, >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Thursday, February 14, 2008 1:40 AM >> To: Dan Wing >> Cc: sip@ietf.org >> Subject: Re: [Sip] R-REUSE, media-security-requirements >> >> Hi Dan, >> >> MUST specify, SHOULD implement and MAY use seems fine for me. >> > > So far you're the only person to respond to my email. I had asked for > feedback because I had received push-back on the requirement to store state > from previous sessions, because such storage weakens the security of the > system by destroying perfect forward secrecy. PFS is a 'must be able to > support' requirement in the document right now. Any thoughts on this > requirements collision? > > I would like to comment on PFS: The definition of the PFS in the Handbook of Applied Cryptography says: "A protocol is said to have perfect forward secrecy if compromise of long-term keys does not compromise past session keys." Now, there is only the question what "long-term key" means in this context. Hence, I am not so sure that PFS is destroyed with the ability to store session state. Furthermore, both parties can decide not to use it. >> I can imagine that not only end hosts would benefit from this >> mechanisms. >> >> There are two mechanisms that offered slightly different >> functionality regarding this security context reuse, namely >> * Re-use of a previously established security context based on state >> that has been established by both end points >> * Re-use of a previously established security context by caching >> security context only on the client side. >> > > On the second bullet, I assume you are referring to RFC5077 ("TLS Session > Resumption without Server-Side State")? > > Yep >> I can imagine that both approaches are useful in certain >> scenarios. The requirement does not differentiate these two cases. >> > > Should the requirement be reworded to differentiate between those two cases? > > I would at least indicate that there are two forms of caching with somewhat different properties here. Ciao Hannes > -d > > > >> Ciao >> Hannes >> >> >> >> >> Dan Wing wrote: >> >>> In draft-ietf-sip-media-security-requirements-02, I changed >>> >> the following >> >>> requirement from MAY to MUST: >>> >>> R-REUSE The media security key management protocol MUST >>> >> support the >> >>> re-use of a previously established security context, and >>> implementations SHOULD implement the re-use mechanism. >>> >>> A discussion of this requirement appears in Section 4.6 of >>> >> the document, >> >> http://tools.ietf.org/html/draft-ietf-sip-media-security-requi >> rements-02#secti >> >>> on-4.6 >>> >>> >>> Does anyone have equipment that they would implement this >>> >> feature in? In the >> >>> past, I have heard that some embedded devices (intelligent >>> >> SIMs) could benefit >> >>> from key re-use. >>> >>> Would it be reasonable to soften this requirement back to a MAY? >>> >>> -d >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 16 02:32:18 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7678F28C140; Sat, 16 Feb 2008 02:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=-1.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76EGmInPNd3A; Sat, 16 Feb 2008 02:32:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E24D3A69A3; Sat, 16 Feb 2008 02:32:17 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009BC3A69A3 for ; Sat, 16 Feb 2008 02:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUh92LuEeHA9 for ; Sat, 16 Feb 2008 02:32:15 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AF30B3A67DF for ; Sat, 16 Feb 2008 02:32:14 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E87EB203F8; Sat, 16 Feb 2008 11:32:12 +0100 (CET) X-AuditID: c1b4fb3e-aa9ffbb000000b15-08-47b6bbaa8a1a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 505B4200E0; Sat, 16 Feb 2008 11:32:10 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 11:32:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 16 Feb 2008 11:28:50 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Headsup on Short Agenda for IETF 71 thread-index: AchwdXURAaoEZRLVSpOvUJ/veJmw4gAEUM7f References: <47B69D8C.8060605@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , X-OriginalArrivalTime: 16 Feb 2008 10:32:09.0628 (UTC) FILETIME=[2F492DC0:01C87087] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Headsup on Short Agenda for IETF 71 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Dean, One thing missing from your list is INFO. I am not sure whether we are "late" or not, but just keep in minds that there are other SDOs which may need the output. I am not sure how much time we would need to discuss it, but since we now have collected use-cases etc I think we should make some kind of decission on how to move forward. Another thing missing, which has been discussed (again) lately is the how-to-reject-an-offer-in-PRACK. I wouldn't say that we are late on that, and for now I guess we can keep the discussion on the list if there is no time at the meeting. Regards, Christer ________________________________ From: sip-bounces@ietf.org on behalf of Dean Willis Sent: Sat 16/02/2008 09:23 To: sip@ietf.org Subject: [Sip] Headsup on Short Agenda for IETF 71 It appears that we will get only 2 hours of working group meeting time in Philadelphia. That means we're going to have to be VERY efficient with our use of time. What are the mosr important things? The things we REALLY need to talk about? Inquiring minds want to know. Here are the things on our charter we're currently late on: 1) Outbound 2) SIPS (which I think is pretty much done) 3) Diagnostic Responses 4) Example security flows 5) Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP 6) Location Conveyance with SIP 7) Connection reuse mechanism 8) Session Policies 9) Etags in conditional notification 10) Using SAML for SIP 11) New resource priority namespaces for DISA 12) Requirements for media keying 13) X.509 Certificates for TLS use in SIP (done?) 14) X.509 extended key usage for SIP (done?) 15) Roadmap for SIP 16) Delivering request-URI and parameters to UAS via proxy 17) Establishment of secure media sessions using DTLS-SRT 18) MIME body handling in SIP 19) Identify requirements for test matrix to move SIP to Draft Standard And the things we aren't late on yet: 1) Essential corrections to RFC 3261 (1st batch) 2) Mechanisms for UA initiated privacy to WGLC So c'mon, people. What do we need to talk about? And why aren't we talking about it on the list already? -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 16 02:34:18 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF58B28C15E; Sat, 16 Feb 2008 02:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDSxUlFIMP0m; Sat, 16 Feb 2008 02:34:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C866F3A6952; Sat, 16 Feb 2008 02:34:17 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BFD28C12D for ; Sat, 16 Feb 2008 02:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC1iGWlL7c42 for ; Sat, 16 Feb 2008 02:34:16 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E138128C108 for ; Sat, 16 Feb 2008 02:33:56 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2612021448; Sat, 16 Feb 2008 11:33:55 +0100 (CET) X-AuditID: c1b4fb3e-ab200bb000000b15-43-47b6bc13dd37 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1B40721304; Sat, 16 Feb 2008 11:33:55 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 11:33:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 16 Feb 2008 11:32:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D - TOTE - "INFO" on the media path thread-index: AchwNr7Kkf6i4xsGSv2z5DD7aLteFgAUHwNm References: <47B6345B.4030807@cisco.com> From: "Christer Holmberg" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 16 Feb 2008 10:33:54.0423 (UTC) FILETIME=[6DBFA070:01C87087] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Jonathan, Interesting draft. One question: is your intention that this would be the ONLY way of using INFO in SIP, or would it be one alternative? The drawback with media planes based solutions is of course that any intermediate interested in the information must have access to the media plane, which may not always be the case. Regards, Christer ________________________________ From: sip-bounces@ietf.org on behalf of Jonathan Rosenberg Sent: Sat 16/02/2008 01:54 To: IETF SIP List Subject: [Sip] New I-D - TOTE - "INFO" on the media path I just submitted a new I-D, which proposes a protocol called TOTE: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt Basically, TOTE provides the ability to exchange MIME objects of any type and "purpose" over a tcp/tls connection established e2e through SDP O/A procedures and ICE-tcp. This ties into the INFO disussion; it provides the media-plane equivalent of the INFO-events framework. This draft should arguably go in mmusic but since the INFO debate is happening here I submitted it as a -sip. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 16 04:42:21 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DB128C19A; Sat, 16 Feb 2008 04:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MGmUCkE-zsr; Sat, 16 Feb 2008 04:42:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4469828C17C; Sat, 16 Feb 2008 04:42:20 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E2C28C0EB for ; Sat, 16 Feb 2008 04:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXsKqEZU5xFl for ; Sat, 16 Feb 2008 04:42:18 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1541F28C186 for ; Sat, 16 Feb 2008 04:42:17 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A021520699; Sat, 16 Feb 2008 13:42:15 +0100 (CET) X-AuditID: c1b4fb3c-ae0bbbb000007e19-ff-47b6da2747dd Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 88F1120055; Sat, 16 Feb 2008 13:42:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 13:42:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 16 Feb 2008 13:42:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TOTE - "INFO" on the media path: Comment on TCP ICE lite thread-index: AchwNr7Kkf6i4xsGSv2z5DD7aLteFgAYUQnr References: <47B6345B.4030807@cisco.com> From: "Christer Holmberg" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 16 Feb 2008 12:42:15.0388 (UTC) FILETIME=[5BE1A1C0:01C87099] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] TOTE - "INFO" on the media path: Comment on TCP ICE lite X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Jonathan, Chapter 2 of the draft says: "All TOTE implementations support at least the lite versionof Interactive Connectivity Establishment (ICE) for TCP [I-D.ietf-mmusic-ice-tcp]." Now, as far as I know we haven't specified any ICE lite procedures for TCP. ice-tcp-05 (do I read the wrong version?) also says: "Because this specification requires multiple candidates for a media stream, it is not compatible with ICE's lite implementation, and can only be used by full implementations." Now, different alternatives regarding this were discussed in Vancouver, and one of the proposals discussed was to implementing "TCP ICE lite" simply by removing the candidates, use the RFC 4145 "fallback" - and specify that ICE could still be used for UDP based streams. As you said, though, I guess the detailed discussion of the proposal belongs to MMUSIC... Regards, Christer ________________________________ From: sip-bounces@ietf.org on behalf of Jonathan Rosenberg Sent: Sat 16/02/2008 01:54 To: IETF SIP List Subject: [Sip] New I-D - TOTE - "INFO" on the media path I just submitted a new I-D, which proposes a protocol called TOTE: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt Basically, TOTE provides the ability to exchange MIME objects of any type and "purpose" over a tcp/tls connection established e2e through SDP O/A procedures and ICE-tcp. This ties into the INFO disussion; it provides the media-plane equivalent of the INFO-events framework. This draft should arguably go in mmusic but since the INFO debate is happening here I submitted it as a -sip. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 16 07:15:30 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EB1628C230; Sat, 16 Feb 2008 07:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzc7DxUg2+Zk; Sat, 16 Feb 2008 07:15:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B74F28C1D7; Sat, 16 Feb 2008 07:15:29 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6D328C1D7 for ; Sat, 16 Feb 2008 07:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff-p1doK-Xu3 for ; Sat, 16 Feb 2008 07:15:26 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5630A3A6A8A for ; Sat, 16 Feb 2008 07:15:26 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Feb 2008 07:15:25 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1GFFPpF015224; Sat, 16 Feb 2008 07:15:25 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1GFFOvn028421; Sat, 16 Feb 2008 15:15:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 07:15:24 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 07:15:23 -0800 Message-ID: <47B6FDFD.3000201@cisco.com> Date: Sat, 16 Feb 2008 10:15:09 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg References: <47B6345B.4030807@cisco.com> In-Reply-To: X-OriginalArrivalTime: 16 Feb 2008 15:15:23.0593 (UTC) FILETIME=[C07A7390:01C870AE] Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi Jonathan, > > Interesting draft. > > One question: is your intention that this would be the ONLY way of > using INFO in SIP, or would it be one alternative? It would be one of three alternatives for "application signaling". The other two being the existing event framework, and the other being the newly proposed info framework. I am nearly done with a draft which I'll submit shortly that provides guidance on selection of a mechanism. I think there are cases for all three. > > The drawback with media planes based solutions is of course that any > intermediate interested in the information must have access to the > media plane, which may not always be the case. Exactly. In those cases you'd use a signaling path solution. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 16 07:16:15 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD1B28C24C; Sat, 16 Feb 2008 07:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kprZErGZMHcX; Sat, 16 Feb 2008 07:16:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0CF3A6A8A; Sat, 16 Feb 2008 07:16:14 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D61E28C1D7 for ; Sat, 16 Feb 2008 07:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmg-DZeYHkwU for ; Sat, 16 Feb 2008 07:16:12 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 41AC03A6A8A for ; Sat, 16 Feb 2008 07:16:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,361,1199692800"; d="scan'208";a="13129428" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2008 07:16:09 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1GFG9Jx015700; Sat, 16 Feb 2008 07:16:09 -0800 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 m1GFG8uL020403; Sat, 16 Feb 2008 15:16:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 07:16:08 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 07:16:08 -0800 Message-ID: <47B6FE2A.9010108@cisco.com> Date: Sat, 16 Feb 2008 10:15:54 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg References: <47B6345B.4030807@cisco.com> In-Reply-To: X-OriginalArrivalTime: 16 Feb 2008 15:16:08.0140 (UTC) FILETIME=[DB07C8C0:01C870AE] Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: IETF SIP List Subject: Re: [Sip] TOTE - "INFO" on the media path: Comment on TCP ICE lite X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The pending ice-tcp draft, which will be out before the non-00 deadline, will describe ICE-lite for tcp. -Jonathan R. Christer Holmberg wrote: > > Hi Jonathan, > > Chapter 2 of the draft says: > > "All TOTE implementations support at least the lite versionof > Interactive Connectivity Establishment (ICE) for TCP > [I-D.ietf-mmusic-ice-tcp]." > > Now, as far as I know we haven't specified any ICE lite procedures > for TCP. ice-tcp-05 (do I read the wrong version?) also says: > > "Because this specification requires multiple candidates for a media > stream, it is not compatible with ICE's lite implementation, and can > only be used by full implementations." > > Now, different alternatives regarding this were discussed in > Vancouver, and one of the proposals discussed was to implementing > "TCP ICE lite" simply by removing the candidates, use the RFC 4145 > "fallback" - and specify that ICE could still be used for UDP based > streams. > > As you said, though, I guess the detailed discussion of the proposal > belongs to MMUSIC... > > Regards, > > Christer > > > > > ________________________________ > > From: sip-bounces@ietf.org on behalf of Jonathan Rosenberg Sent: Sat > 16/02/2008 01:54 To: IETF SIP List Subject: [Sip] New I-D - TOTE - > "INFO" on the media path > > > > I just submitted a new I-D, which proposes a protocol called TOTE: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt > > Basically, TOTE provides the ability to exchange MIME objects of any > type and "purpose" over a tcp/tls connection established e2e through > SDP O/A procedures and ICE-tcp. This ties into the INFO disussion; it > provides the media-plane equivalent of the INFO-events framework. > > This draft should arguably go in mmusic but since the INFO debate is > happening here I submitted it as a -sip. > > Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. > 499 Thornall St. Cisco Fellow > Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com > http://www.jdrosen.net > PHONE: (408) 902-3084 http://www.cisco.com > _______________________________________________ Sip mailing list > http://www.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 16 08:53:40 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A9A28C25D; Sat, 16 Feb 2008 08:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur2IOuVNu3dw; Sat, 16 Feb 2008 08:53:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B12128C24E; Sat, 16 Feb 2008 08:53:39 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA8528C24E for ; Sat, 16 Feb 2008 08:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0BcSWlYbhXd for ; Sat, 16 Feb 2008 08:53:37 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D732F28C247 for ; Sat, 16 Feb 2008 08:53:37 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Feb 2008 08:53:37 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1GGra5w014396 for ; Sat, 16 Feb 2008 08:53:36 -0800 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 m1GGrauL005688 for ; Sat, 16 Feb 2008 16:53:36 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 08:53:36 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 08:53:35 -0800 Message-ID: <47B71502.20907@cisco.com> Date: Sat, 16 Feb 2008 11:53:22 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List X-OriginalArrivalTime: 16 Feb 2008 16:53:35.0832 (UTC) FILETIME=[7886C580:01C870BC] Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Sip] New I-D: Litmus tests for INFO vs. TOTE vs. SIP events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I just submitted the following short I-D: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-info-litmus-00.txt This proposes some litmus tests in evaluating whether an application should use the INFO framework, TOTE or the sip events framework. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 17 14:26:59 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75AB13A6B34; Sun, 17 Feb 2008 14:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=-1.631, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4DdNjzHU7sW; Sun, 17 Feb 2008 14:26:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250E33A6880; Sun, 17 Feb 2008 14:26:58 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D504B3A67F8 for ; Sun, 17 Feb 2008 14:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J7isQdpHOQr for ; Sun, 17 Feb 2008 14:26:55 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BCB943A67F7 for ; Sun, 17 Feb 2008 14:26:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,367,1199692800"; d="scan'208";a="13194822" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 17 Feb 2008 10:38:39 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1HIcdkP008899; Sun, 17 Feb 2008 10:38:39 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1HIcaJg011554; Sun, 17 Feb 2008 18:38:36 GMT From: "Dan Wing" To: References: <31e401c869aa$7b5e17e0$18726b80@cisco.com> <47B40C71.60409@gmx.net> <02b701c8703b$d0929d70$c4f0200a@cisco.com> <47B6B843.4050809@gmx.net> Date: Sun, 17 Feb 2008 10:38:36 -0800 Message-ID: <00dd01c87194$4ed8f900$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchwhS5PMY98jFfLT4amYn2GR9jQuAAPMjDg In-Reply-To: <47B6B843.4050809@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] R-REUSE, media-security-requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, February 16, 2008 2:18 AM > To: Dan Wing > Cc: sip@ietf.org > Subject: Re: [Sip] R-REUSE, media-security-requirements > > Hi Dan, > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Thursday, February 14, 2008 1:40 AM > >> To: Dan Wing > >> Cc: sip@ietf.org > >> Subject: Re: [Sip] R-REUSE, media-security-requirements > >> > >> Hi Dan, > >> > >> MUST specify, SHOULD implement and MAY use seems fine for me. > >> > > > > So far you're the only person to respond to my email. I > had asked for > > feedback because I had received push-back on the > requirement to store state > > from previous sessions, because such storage weakens the > security of the > > system by destroying perfect forward secrecy. PFS is a > 'must be able to > > support' requirement in the document right now. Any > thoughts on this > > requirements collision? > > > > > > I would like to comment on PFS: > > The definition of the PFS in the Handbook of Applied > Cryptography says: > > "A protocol is said to have perfect forward secrecy if compromise of > long-term keys > does not compromise past session keys." > > Now, there is only the question what "long-term key" means in > this context. A DTLS-SRTP implementation would have both the server and client cache the TLS Session Id, and remember the Session Id between phone calls. This means the TLS security parameters and keys, and thus the SRTP key (which is derived from the TLS security parametersa and keys), are remembered between phone calls. As far as I am aware, there is no guidance for how long (hours) this information is expected to be retained. > Hence, I am not so sure that PFS is destroyed with the > ability to store > session state. Furthermore, both parties can decide not to use it. If _either_ party stores the information, compromise of that device (the one which stored the information) destroys PFS. So even if I have configured my device to not store such information, whoever I'm calling might not have configured it that way. There is no mechanism, currently, to negotiate or communicate if you want the remote party to cache TLS session information. Perhaps RFC5077 could be used as the negotiation mechanism, such that if both sides implement RFC5077 they are agreeing to caching session information. I am not too interested in RFC5077's ability to have one side (the TLS client) store the state, but rather I am interested in a negotiation mechanism such that both sides agree to break PFS. > >> I can imagine that not only end hosts would benefit from this > >> mechanisms. > >> > >> There are two mechanisms that offered slightly different > >> functionality regarding this security context reuse, namely > >> * Re-use of a previously established security context > based on state > >> that has been established by both end points > >> * Re-use of a previously established security context by caching > >> security context only on the client side. > >> > > > > On the second bullet, I assume you are referring to RFC5077 > ("TLS Session > > Resumption without Server-Side State")? > > > > > Yep > > >> I can imagine that both approaches are useful in certain > >> scenarios. The requirement does not differentiate these two cases. > >> > > > > Should the requirement be reworded to differentiate between > those two cases? > > > > > I would at least indicate that there are two forms of caching with > somewhat different properties here. Suggestions? I am now leaning towards something like this; I am now leaning towards MAY because no-one has said this feature is necessary for equipment they envision in the field: R-REUSE, a system MAY describe how to cache state between SRTP sessions in order to reduce CPU processing for future calls. Note that such caching destroys PFS. R-CACHING, if a system does implement R-REUSE, both peers MUST agree to such caching. Thoughts? -d > Ciao > Hannes > > > -d > > > > > > > >> Ciao > >> Hannes > >> > >> > >> > >> > >> Dan Wing wrote: > >> > >>> In draft-ietf-sip-media-security-requirements-02, I changed > >>> > >> the following > >> > >>> requirement from MAY to MUST: > >>> > >>> R-REUSE The media security key management protocol MUST > >>> > >> support the > >> > >>> re-use of a previously established security context, and > >>> implementations SHOULD implement the re-use mechanism. > >>> > >>> A discussion of this requirement appears in Section 4.6 of > >>> > >> the document, > >> > >> http://tools.ietf.org/html/draft-ietf-sip-media-security-requi > >> rements-02#secti > >> > >>> on-4.6 > >>> > >>> > >>> Does anyone have equipment that they would implement this > >>> > >> feature in? In the > >> > >>> past, I have heard that some embedded devices (intelligent > >>> > >> SIMs) could benefit > >> > >>> from key re-use. > >>> > >>> Would it be reasonable to soften this requirement back to a MAY? > >>> > >>> -d > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the > application of sip > >>> > >>> > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 17 21:07:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A093A6C59; Sun, 17 Feb 2008 21:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwK6EHCuBwmB; Sun, 17 Feb 2008 21:07:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3683A6C90; Sun, 17 Feb 2008 21:07:15 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B2B3A6892 for ; Sun, 17 Feb 2008 21:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOJCRXURcWNA for ; Sun, 17 Feb 2008 21:07:11 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8B46E3A6C76 for ; Sun, 17 Feb 2008 21:06:52 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Feb 2008 21:06:50 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1I56owF013734 for ; Sun, 17 Feb 2008 21:06:50 -0800 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 m1I56ouL026483 for ; Mon, 18 Feb 2008 05:06:50 GMT 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.1830); Sun, 17 Feb 2008 21:06:49 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Feb 2008 21:06:48 -0800 Message-ID: <47B9125B.2060104@cisco.com> Date: Mon, 18 Feb 2008 00:06:35 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List X-OriginalArrivalTime: 18 Feb 2008 05:06:48.0913 (UTC) FILETIME=[10DBF410:01C871EC] Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I just submitted: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns-00.txt This is basically a discussion on the security properties of rfc4474 with phone numbers, and a comparison to rfc3325 in this case. Also a discussion on what happens to dtls-srtp. Comments welcome. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 17 22:00:38 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6800F28C12F; Sun, 17 Feb 2008 22:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.114 X-Spam-Level: X-Spam-Status: No, score=0.114 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMaIECBp6bAj; Sun, 17 Feb 2008 22:00:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1025F3A6CAE; Sun, 17 Feb 2008 22:00:35 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E161C3A6CAE for ; Sun, 17 Feb 2008 22:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdsdxlAlOUHT for ; Sun, 17 Feb 2008 22:00:31 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 73BEE3A6CB4 for ; Sun, 17 Feb 2008 22:00:31 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 01:00:16 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 01:00:16 -0500 From: Hadriel Kaplan To: IETF SIP List Date: Mon, 18 Feb 2008 00:59:14 -0500 Thread-Topic: New I-D on an attack using RFC4474: a Baiting attack Thread-Index: Achx82PhBp4aHLePRWSeOmg0Nqkzmw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Dan Wing Subject: [Sip] New I-D on an attack using RFC4474: a Baiting attack X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0982034984==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0982034984== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC30BC467BEF0mailacmepacke_" --_000_E6C2E8958BA59A4FB960963D475F7AC30BC467BEF0mailacmepacke_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Dan Wing and I wrote up a draft identifying a method for using RFC-4474 sig= ned requests as "bait" for a SIP Phishing or SPIT attack. Comments welcome= , of course. http://www.ietf.org/internet-drafts/draft-kaplan-sip-baiting-attack-01.txt -hadriel --_000_E6C2E8958BA59A4FB960963D475F7AC30BC467BEF0mailacmepacke_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi,

    Dan Wing and I wrote up a draft identifying a method for using RFC-= 4474 signed requests as “bait” for a SIP Phishing or SPIT attack. &n= bsp;Comments welcome, of course.

     

    http://www.ietf.org/internet-drafts/draft-kaplan-sip-baiting-attack= -01.txt

     

    -hadriel

     

    --_000_E6C2E8958BA59A4FB960963D475F7AC30BC467BEF0mailacmepacke_-- --===============0982034984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0982034984==-- From sip-bounces@ietf.org Sun Feb 17 23:36:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602D93A69F5; Sun, 17 Feb 2008 23:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.573 X-Spam-Level: X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsGOvlhoOGIo; Sun, 17 Feb 2008 23:36:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8863A6B23; Sun, 17 Feb 2008 23:36:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687D43A69F5 for ; Sun, 17 Feb 2008 23:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anXTJR3KCvys for ; Sun, 17 Feb 2008 23:36:32 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3E6D93A69AC for ; Sun, 17 Feb 2008 23:36:32 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWF0058OBSRAL@siemenscomms.co.uk> for sip@ietf.org; Mon, 18 Feb 2008 07:36:28 +0000 (GMT) Date: Mon, 18 Feb 2008 07:36:27 +0000 From: "Elwell, John" In-reply-to: <47B60D74.9030403@cisco.com> To: Paul Kyzivat , SIP IETF Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0697DB2@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: draft-elwell-sip-e164-problem-statement-00.txt Thread-Index: AchwH1hLStNXpUpuTwSQHLe1OC6N2wBdDiMQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <008501c8701a$b492a870$c4f0200a@cisco.com> <47B60D74.9030403@cisco.com> Subject: Re: [Sip] draft-elwell-sip-e164-problem-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, Thanks for reading and commenting on this draft. See below. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 15 February 2008 22:09 > To: SIP IETF; Elwell, John > Subject: Re: draft-elwell-sip-e164-problem-statement-00.txt > > John, > > Thanks for opening this can of worms. It is a very important > problem to > solve. > > Did you intend for this to be discussed on the SIP WG mailing list? [JRE] Yes > > > When a UA receives an E.164 number represented as a SIP > URI in a From > > header field, what does this say about the source of the > request? Of > > course, it should indicate that the request originated > at a user who > > has a right to use that E.164 number and who can be reached by > > submitting a request targeted at that E.164 number. > > I'm not convinced about the above. It depends on what you > mean by "should". [JRE] Perhaps I should have phrased it as "one might expect". > > The existing rules for use of SIP URIs don't require that the user be > reachable from the PSTN, or that the user have any > relationship to the > pstn number. The user part is still wholly the responsibility > of the domain. > > A corollary is that there are significant issues about how > the recipient > displays the identity of the caller. If the identity is > displayed based > solely on the e.164 number, without the domain, then it is a > misrepresentation precisely because reverse routing using the e.164 > number may well not reach the same place. > > > However, the last > > of these issues is a far more serious problem: the user > expects a > > communication partner to be from a particular domain (the E.164 > > number is not necessarily an important factor). Seeing > that domain > > in the From: URI, coupled with authentication by means of the > > Identity header field, would satisfy the user's > expectation. Seeing > > a different domain, that of an intermediate service > provider, which > > may or may not be known to the user, would not satisfy the user's > > expectation. The user might not be prepared to accept > the unexpected > > URI and might decide not to proceed with the communication. > > This argument isn't very compelling to me. Nobody using the > PSTN expects > to see the enterprise name as part of the calling "number". > PSTN caller > id with calling name might be relevant, but it isn't a domain name. > > If you want to use sip domain names for authorization > purposes, then it > makes more sense to use *real* sip URIs. [JRE] Yes, but E.164 numbers are used extensively, and a big advantage is that they can be reached from PSTN as well as being reachable from within the SIP world. So it would make sense to be able to use E.164 numbers but also be able to draw the same conclusions about domain as one can for "real" SIP URIs. > > > REQ2: When a UAS receives a SIP request that includes a > SIP or SIPS > > URI identifying the originating user, if that URI contains an > > E.164 number that number alone, when placed in a TEL > URI, must be > > suitable for routing a request back to the originating user. > > Your examples all include ;user=phone, but none of the text says that > you mean that when talking about sip URIs that contain E.164 > numbers. I > am somewhat inclined to agree with this requirement if user=phone is > present, but otherwise not. [JRE] That was my intention - with user=phone. > > IMO, rather than trying to fix up the handling of sip URIs containing > phone numbers we would be better off trying to fix up the use > of TEL URIs. > > The main limitation of TEL URIs is the inability of sip > identity to deal > with them. What we need is a way to extend identity to them in such a > way that it truly proves ownership of the number, in whatever > sense of > ownership we want it to mean. > > I think that can be achieved by translating a TEL URI to its > ENUM dotted > inverted number domain name format, and then applying sip identity to > that. It means that if I am the end user assigned usage of > TEL:+1978-555-1234 then *I* or some middle box acting as my > agent, must > have a certificate for 4.3.2.1.5.5.5.8.7.9.1.e164.ansi. [JRE] This brings us firmly back to the concept of ownership of E.164 numbers, since clearly if a recognised CA is going to sign a certificate for such a domain, that domain would need to demonstrate some kind of ownership. I gather in North America this would fit well with the idea that enterprises "own" their E.164 numbers (I am referring here to a comment from Henry), and if this is true elsewhere it might be a realistic proposition. I do like your suggestion. > > Thanks, > Paul > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 06:50:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768E528C371; Mon, 18 Feb 2008 06:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=-2.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs6CRpiRnnSf; Mon, 18 Feb 2008 06:50:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A143A6CB2; Mon, 18 Feb 2008 06:50:33 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E883A6CB2 for ; Mon, 18 Feb 2008 06:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCu4c2nJIk5I for ; Mon, 18 Feb 2008 06:50:31 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 93D663A6BB9 for ; Mon, 18 Feb 2008 06:50:31 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2008 09:50:30 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1IEoT4b022711 for ; Mon, 18 Feb 2008 09:50:29 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IEoLWN007039 for ; Mon, 18 Feb 2008 14:50:29 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 09:50:23 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 09:50:23 -0500 Message-ID: <47B99B39.6040105@cisco.com> Date: Mon, 18 Feb 2008 09:50:33 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Rosenberg References: <47B9125B.2060104@cisco.com> In-Reply-To: <47B9125B.2060104@cisco.com> X-OriginalArrivalTime: 18 Feb 2008 14:50:23.0499 (UTC) FILETIME=[972DC5B0:01C8723D] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, I guess the time has come for this discussion, since John Ewell has also submitted a draft on this subject. I thought the problem was already well known, but perhaps not. IMO the main thing now is to figure out the *solution* to the problem! IMO a solution is to use a 4474-style approach, but where the certificate is tied to just the phone number, not to some arbitrary domain name. That of course would depend on a model where the "owner" of the phone number is the one who may obtain the certificate for that number. My thought is that we already have an algorithmic mapping from an E.164 phone number to a domain name, defined by enum. If the sender puts an E.164 number in From, and can sign it with a cert for the enum mapped domain name corresponding to that number, then that ought to be valid proof of the validity of the sender. In those places where public enum is in operation, I think there is already a legal mechanism in place to give the owner of record of a particular phone number control over the contents of the corresponding DNS entry. That should also be sufficient to allow a certificate authority to assign a cert to that same owner. Combine all that and you have a complete e2e identity model for phone numbers, based on public enum. And that can be true even if public enum isn't used to *route* the calls to that number. So it could be used for "unlisted" numbers. To use this approach the From header should contain either a TEL URI, or a sip/sips URI containing the enum-mapped domain name corresponding to the phone number. (I would rather see the TEL used for this - it is more user friendly.) Thanks, Paul Jonathan Rosenberg wrote: > I just submitted: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns-00.txt > > This is basically a discussion on the security properties of rfc4474 > with phone numbers, and a comparison to rfc3325 in this case. Also a > discussion on what happens to dtls-srtp. > > Comments welcome. > > -Jonathan R. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 08:08:01 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E5128C415; Mon, 18 Feb 2008 08:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4AOivSfMDcf; Mon, 18 Feb 2008 08:07:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F5D28C3B4; Mon, 18 Feb 2008 08:07:56 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F93B28C27B for ; Mon, 18 Feb 2008 08:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFC8YPfdn3rF for ; Mon, 18 Feb 2008 08:07:50 -0800 (PST) Received: from m5tmail1.m5t.com (m5tmail1.m5t.com [207.134.65.96]) by core3.amsl.com (Postfix) with ESMTP id B215628C377 for ; Mon, 18 Feb 2008 08:07:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 11:08:24 -0500 Message-ID: <6EF4CC794ECF2B409390605FDEA90122452E3B@m5tmail1.m5t.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification for multipart/alternative handling Thread-Index: AchySHzSCtfcKK6HSXagQ94kV4XDpA== From: "Eric Tremblay" To: "Gonzalo Camarillo" Cc: IETF SIP List Subject: [Sip] Clarification for multipart/alternative handling X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1558328674==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1558328674== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87248.6234567D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87248.6234567D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Gonzalo, I have been going through draft-ietf-sip-body-handling-01 and noticed something that is either en error or counter-intuitive. Section 5.1 states: The body parts are ordered so that the last one is the richest representation of the information. This way, the recipient of a 'multipart/alternative' body chooses the last body part it understands. Section 6.2 states: If the handling of a 'multipart/alternative' body is required, the UA MUST set the 'handling' parameter of the 'multipart/alternative' body to 'required'. The UA MUST also set the 'handling' parameter of the last body part within the 'multipart/alternative' to 'required'. Why the last body part? Somehow, I would have expected that the 'handling' parameter of first body part to be set to 'required', not the last one, as the last one should hold the richest representation of the information, and possibly the one most difficult to understand/implement... And thinking about it a little bit more, I think that an application should always set the 'handling' parameter in the internal parts of a 'multipart/alternative' to 'optional', as this is pretty much what 'multipart/alternative' is. If 'multipart/alternative' itself is has its 'handling' set to 'required', then it means at least one of its internal part must be understood and handled. The sender cannot really decide which one has to be understood. Maybe my suggestion is going against things already defined in MIME or somewhere else. If this is the case, I think a simple clarification in the draft would do, something in the line: Even though the last part of the 'multipart/alternative' has its 'handling' parameter set to 'required', the receiving UA (or UAS) does not necessarly have to be able to handle this specific body part, it only has to be able to handle any body part within the 'multipart/alternative' body parts. Best Regards, EricT ------_=_NextPart_001_01C87248.6234567D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Clarification for multipart/alternative handling

    Hi = Gonzalo,

    I have been going = through draft-ietf-sip-body-handling-01 and noticed something that is = either en error or counter-intuitive.

    Section 5.1 = states:
       The body = parts are
       ordered so that the last one is the richest representation = of the
       information.  This way, the recipient of a = 'multipart/alternative'
       body chooses the last body part it = understands.

    Section 6.2 = states:
       If the handling of a 'multipart/alternative' body is = required, the UA
       MUST set the 'handling' parameter of the = 'multipart/alternative' body
       to 'required'.  The UA MUST also set the 'handling' = parameter of the
       last body part within the 'multipart/alternative' to = 'required'.

    Why the last body = part? Somehow, I would have expected that the 'handling' parameter of = first body part to be set to 'required', not the last one, as the last = one should hold the richest representation of the information, and = possibly the one most difficult to = understand/implement…

    And thinking about = it a little bit more, I think that an application should always set the = 'handling' parameter in the internal parts of a 'multipart/alternative' = to 'optional', as this is pretty much what 'multipart/alternative' is. = If 'multipart/alternative' itself is has its 'handling' set to = 'required', then it means at least one of its internal part must be = understood and handled. The sender cannot really decide which one has to = be understood.

    Maybe my = suggestion is going against things already defined in MIME or somewhere = else. If this is the case, I think a simple clarification in the draft = would do, something in the line:

    Even though the = last part of the 'multipart/alternative' has its 'handling' parameter = set to 'required', the receiving UA (or UAS) does not necessarly have to = be able to handle this specific body part, it only has to be able to = handle any body part within the 'multipart/alternative' body = parts.

    Best = Regards,

    EricT

    ------_=_NextPart_001_01C87248.6234567D-- --===============1558328674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1558328674==-- From sip-bounces@ietf.org Mon Feb 18 08:26:14 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E583A6CCC; Mon, 18 Feb 2008 08:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=-1.446, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zhtS7ZahbQ1; Mon, 18 Feb 2008 08:26:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767BF28C135; Mon, 18 Feb 2008 08:26:10 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCB943A6CCC for ; Mon, 18 Feb 2008 08:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqd0TGA+8QzE for ; Mon, 18 Feb 2008 08:26:08 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by core3.amsl.com (Postfix) with ESMTP id 0EF873A68FE for ; Mon, 18 Feb 2008 08:26:06 -0800 (PST) Received: from source ([192.150.20.142]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Mon, 18 Feb 2008 08:26:03 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m1IGQ1Gb018765; Mon, 18 Feb 2008 08:26:01 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id m1IGPxFV006246; Mon, 18 Feb 2008 08:26:00 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 01:25:58 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 08:25:45 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22019E0755@namail5.corp.adobe.com> In-Reply-To: <47B99B39.6040105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyPaUwZNySpUlPSZ2WJ432wEU9pAADJbXA References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> From: "Henry Sinnreich" To: "Paul Kyzivat" , "Shockey, Richard" X-OriginalArrivalTime: 18 Feb 2008 16:25:58.0791 (UTC) FILETIME=[F1ADE170:01C8724A] Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, >My thought is that we already have an algorithmic mapping from an E.164 >phone number to a domain name, defined by enum. If the sender puts an >E.164 number in From, and can sign it with a cert for the enum mapped >domain name corresponding to that number, then that ought to be valid >proof of the validity of the sender. This seems indeed to be cutting the Gordian Knot! (http://en.wikipedia.org/wiki/Gordian_Knot) Should this not be a joint I-D with the ENUM WG, or have at least have some coordination? The exact mechanism to do this is certainly of interest to the ENUM folks. Henry -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, February 18, 2008 8:51 AM To: Jonathan Rosenberg Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers Jonathan, I guess the time has come for this discussion, since John Ewell has also submitted a draft on this subject. I thought the problem was already well known, but perhaps not. IMO the main thing now is to figure out the *solution* to the problem! IMO a solution is to use a 4474-style approach, but where the certificate is tied to just the phone number, not to some arbitrary domain name. That of course would depend on a model where the "owner" of the phone number is the one who may obtain the certificate for that number. My thought is that we already have an algorithmic mapping from an E.164 phone number to a domain name, defined by enum. If the sender puts an E.164 number in From, and can sign it with a cert for the enum mapped domain name corresponding to that number, then that ought to be valid proof of the validity of the sender. In those places where public enum is in operation, I think there is already a legal mechanism in place to give the owner of record of a particular phone number control over the contents of the corresponding DNS entry. That should also be sufficient to allow a certificate authority to assign a cert to that same owner. Combine all that and you have a complete e2e identity model for phone numbers, based on public enum. And that can be true even if public enum isn't used to *route* the calls to that number. So it could be used for "unlisted" numbers. To use this approach the From header should contain either a TEL URI, or a sip/sips URI containing the enum-mapped domain name corresponding to the phone number. (I would rather see the TEL used for this - it is more user friendly.) Thanks, Paul Jonathan Rosenberg wrote: > I just submitted: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns -00.txt > > This is basically a discussion on the security properties of rfc4474 > with phone numbers, and a comparison to rfc3325 in this case. Also a > discussion on what happens to dtls-srtp. > > Comments welcome. > > -Jonathan R. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 08:30:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B73C28C499; Mon, 18 Feb 2008 08:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1ky3SCOUyIa; Mon, 18 Feb 2008 08:30:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0ED128C3A7; Mon, 18 Feb 2008 08:30:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCA93A6CD9 for ; Mon, 18 Feb 2008 08:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVVZmNsllvtr for ; Mon, 18 Feb 2008 08:30:30 -0800 (PST) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id 637C93A6CA6 for ; Mon, 18 Feb 2008 08:30:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 84FAE7DD1 for ; Mon, 18 Feb 2008 08:30:27 -0800 (PST) Received: from [192.168.0.100] (pool-71-161-50-169.clppva.east.verizon.net [71.161.50.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 203387DF7 for ; Mon, 18 Feb 2008 08:30:24 -0800 (PST) Message-ID: <47B9B294.7010700@joelhalpern.com> Date: Mon, 18 Feb 2008 11:30:12 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List References: <47B9125B.2060104@cisco.com> In-Reply-To: <47B9125B.2060104@cisco.com> X-Enigmail-Version: 0.95.6 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net Subject: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I have been pestering various people off list, and have decided to see whether someone else understands and can explain this in a way I can follow. The following is somewhat longer than I like. Sorry. The pair of questions is: When should the user part of a SIP URI be considered an E.164 number? And what assertion is being made by such consideration? Taking them backwards, as far as I can tell from reading the RFCs and the I-Ds, the assertion that is supposed to hold is that if a SIP URI can be properly understood to have an E.164 number in it's user part, and if it legitimately has that number, then the party the SIP URI represents can also be reached by calling the E.164 number on the PSTN. There are some interesting ambiguities left even with that definition, but we can live with it. So, when does the user part have an E.164 number, so that it is reasonable to ask if the assertion holds? As far as I can tell, there are three cases: Case 1 - No ;user=phone option In the absence of a ;user=phone option, the user part of the SIP URI should be considered an opaque string. It should not be considered an E.164 number, even if it is formatted as a telephone subscriber number. I can legitimately use +17035555555@joelhalpern.com as a SIP URI. And if the whitehouse.com deliberate confusion is still active, they could use +12024561414@whitehouse.com as a SIP URI. It is reported that some SIP devices will display the phone number without the domain for such URIs. That is a UI error, not a protocol error. The protocol can not make the UI do the right thing. Case 2 - ;user=phone option present, no ;phone-context= option I believe this is an assertion that the user part of the SIP URI is an E.164 number, and that if one is doing validation E.164 validation is appropriate. The whole question of the meaning of the domain, and whether we are better off with tel: URIs applies to this form of SIP URI. While it is possible (any character string is possible) to have a SIP URI with ;user=phone and no ;phone-context and not have the user part formatted as a telephone-subscriber number, such a mismatch looks to me to be a violation of RFC 3261. The only reasonable handling is that if one is trying to perform E.164 validation, such validation will fail on such a SIP URI. Case 3 - ;user=phone and ;phone-context= options present The RFCs seem to say explicitly that the user part of the SIP URI can not be considered an E.164 number, and that one can not even expect to concatenate the phone context and the user part to get an E.164 number. So there can be no E.164 validation because there is no E.164 number. Some folks seem to have suggested that one should observe the format of the user part of the SIP URI in order to decide if an E.164 number is intended. I sincerely hope that is note the case. Yours, Joel M. Halpern _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 09:08:04 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F9928C3C0; Mon, 18 Feb 2008 09:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2-qNT7TTazM; Mon, 18 Feb 2008 09:08:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C889B28C31F; Mon, 18 Feb 2008 09:08:03 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D51C28C31F for ; Mon, 18 Feb 2008 09:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fWqtvIhsdHv for ; Mon, 18 Feb 2008 09:08:01 -0800 (PST) Received: from smtpauth01.csee.onr.siteprotect.com (smtpauth01.csee.onr.siteprotect.com [64.26.60.145]) by core3.amsl.com (Postfix) with ESMTP id 7C2C028C256 for ; Mon, 18 Feb 2008 09:08:01 -0800 (PST) Received: from cornfed (unknown [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id DB8531C8065; Mon, 18 Feb 2008 10:19:43 -0600 (CST) From: "Frank W. Miller" To: "'Henry Sinnreich'" , "'Paul Kyzivat'" , "'Shockey, Richard'" Date: Mon, 18 Feb 2008 10:07:47 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchyPaUwZNySpUlPSZ2WJ432wEU9pAADJbXAAAGO2yA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D22019E0755@namail5.corp.adobe.com> Message-Id: <20080218161943.DB8531C8065@smtpauth01.csee.onr.siteprotect.com> Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm a little confused by the need to "sign" phone numbers. I mean, whomever uses the number makes a call to or from it right? If the receiver of the call doesn't want to talk to whomever calls, don't they just hang up? This seems like a lot of extra work for little gain. Thanks, FM -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Monday, February 18, 2008 9:26 AM To: Paul Kyzivat; Shockey, Richard Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers Paul, >My thought is that we already have an algorithmic mapping from an E.164 >phone number to a domain name, defined by enum. If the sender puts an >E.164 number in From, and can sign it with a cert for the enum mapped >domain name corresponding to that number, then that ought to be valid >proof of the validity of the sender. This seems indeed to be cutting the Gordian Knot! (http://en.wikipedia.org/wiki/Gordian_Knot) Should this not be a joint I-D with the ENUM WG, or have at least have some coordination? The exact mechanism to do this is certainly of interest to the ENUM folks. Henry -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, February 18, 2008 8:51 AM To: Jonathan Rosenberg Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers Jonathan, I guess the time has come for this discussion, since John Ewell has also submitted a draft on this subject. I thought the problem was already well known, but perhaps not. IMO the main thing now is to figure out the *solution* to the problem! IMO a solution is to use a 4474-style approach, but where the certificate is tied to just the phone number, not to some arbitrary domain name. That of course would depend on a model where the "owner" of the phone number is the one who may obtain the certificate for that number. My thought is that we already have an algorithmic mapping from an E.164 phone number to a domain name, defined by enum. If the sender puts an E.164 number in From, and can sign it with a cert for the enum mapped domain name corresponding to that number, then that ought to be valid proof of the validity of the sender. In those places where public enum is in operation, I think there is already a legal mechanism in place to give the owner of record of a particular phone number control over the contents of the corresponding DNS entry. That should also be sufficient to allow a certificate authority to assign a cert to that same owner. Combine all that and you have a complete e2e identity model for phone numbers, based on public enum. And that can be true even if public enum isn't used to *route* the calls to that number. So it could be used for "unlisted" numbers. To use this approach the From header should contain either a TEL URI, or a sip/sips URI containing the enum-mapped domain name corresponding to the phone number. (I would rather see the TEL used for this - it is more user friendly.) Thanks, Paul Jonathan Rosenberg wrote: > I just submitted: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns -00.txt > > This is basically a discussion on the security properties of rfc4474 > with phone numbers, and a comparison to rfc3325 in this case. Also a > discussion on what happens to dtls-srtp. > > Comments welcome. > > -Jonathan R. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 09:40:57 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8166F28C495; Mon, 18 Feb 2008 09:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukuDDgVNx9Fd; Mon, 18 Feb 2008 09:40:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCAD28C2E2; Mon, 18 Feb 2008 09:40:56 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD66828C2E2 for ; Mon, 18 Feb 2008 09:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibViblh-Q7CY for ; Mon, 18 Feb 2008 09:40:55 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DC87528C1D1 for ; Mon, 18 Feb 2008 09:40:54 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1IHejrT024459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2008 11:40:47 -0600 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <47B99B39.6040105@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 18 Feb 2008 11:40:40 -0600 References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 18, 2008, at 8:50 AM, Paul Kyzivat wrote: > > I thought the problem was already well known, but perhaps not. IMO the > main thing now is to figure out the *solution* to the problem! > IMO a solution is to use a 4474-style approach, but where the > certificate is tied to just the phone number, not to some arbitrary > domain name. That of course would depend on a model where the > "owner" of > the phone number is the one who may obtain the certificate for that > number. You might take a look at "Identity Based Authentication in the Session Initiation Protocol", draft-kupwade-sip-iba-00. This draft is a bit incomplete, but it's the reduction of a far longer master's thesis that I'm familiar with. It seems reasonably feasible to consider the phone number an "identity" within the domain of an identity-based private key generator. The math is now available to handle multiple levels of PKG hierarchy, which allows key-generation delegation along the ENUM tree lines. On an operational basis, it seems a lot easier to work with than a CA model. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 09:45:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844FB28C528; Mon, 18 Feb 2008 09:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOy98HEHPj2C; Mon, 18 Feb 2008 09:45:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D35428C494; Mon, 18 Feb 2008 09:45:13 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B768528C3FE; Mon, 18 Feb 2008 09:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080218174501.B768528C3FE@core3.amsl.com> Date: Mon, 18 Feb 2008 09:45:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-eku-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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 : Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates Author(s) : S. Lawrence, V. Gurbani Filename : draft-ietf-sip-eku-01.txt Pages : 10 Date : 2008-02-18 This memo documents an extended key usage (EKU) X.509 certificate extension for identifying the holder of a certificate as authoritative for a Session Initiation Protocol (SIP) service in the domain named by the DNS name in the certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-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-eku-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-eku-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: <2008-02-18094351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-eku-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-eku-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-18094351.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Feb 18 09:46:14 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5327528C513; Mon, 18 Feb 2008 09:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ButNVaaqj-J; Mon, 18 Feb 2008 09:46:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D6328C408; Mon, 18 Feb 2008 09:46:10 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28FA128C486 for ; Mon, 18 Feb 2008 09:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFpV4bPkDQSE for ; Mon, 18 Feb 2008 09:46:08 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0671C28C4F5 for ; Mon, 18 Feb 2008 09:46:04 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 12:45:49 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 12:45:49 -0500 From: Hadriel Kaplan To: "Frank W. Miller" , 'Henry Sinnreich' , 'Paul Kyzivat' , "'Shockey, Richard'" Date: Mon, 18 Feb 2008 12:44:47 -0500 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyPaUwZNySpUlPSZ2WJ432wEU9pAADJbXAAAGO2yAAAIRnUA== Message-ID: References: <24CCCC428EFEA2469BF046DB3C7A8D22019E0755@namail5.corp.adobe.com> <20080218161943.DB8531C8065@smtpauth01.csee.onr.siteprotect.com> In-Reply-To: <20080218161943.DB8531C8065@smtpauth01.csee.onr.siteprotect.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think we're trying to get something out of the signature that currently isn't fully there: caller-id. Currently rfc4474 just tells you that the signer sent the request to someone (not necessarily you), within the past hour, with the attached body unchanged between it and you. Per rfc4474 that signer should have verified the authenticity of the AoR in the From before sending it. If the signing domain didn't do strong verification of the From before signing an email-style URI, the impact of such is really against the signing domain. In other words its in the signing domain's best interest to get it right, because it's affecting their own customers' identity legitimacy. But when a signing domain signs an e164 that is not its own, it's affecting a global number's legitimacy - its spoofing the identity of someone outside of the signing domain. Without some way to verify the signing domain *owns* that e164, you have no way to know if it's good or not. For example, if a provider gets a call from a PSTN tandem trunk, and passes it on in SIP, they really shouldn't sign its From, because they have no way to verify the authenticity of its user part. (CLID spoofing is not a new phenomenon) And likewise if an enterprise signs an e164 other than their own, it would be an error. But there is currently no way to detect such errors or intentional mischief. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Frank W. Miller > Sent: Monday, February 18, 2008 12:08 PM > To: 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' > Cc: 'IETF SIP List' > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > I'm a little confused by the need to "sign" phone numbers. I mean, > whomever > uses the number makes a call to or from it right? If the receiver of the > call doesn't want to talk to whomever calls, don't they just hang up? > This > seems like a lot of extra work for little gain. > > Thanks, > FM _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 09:49:22 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE1C28C4AD; Mon, 18 Feb 2008 09:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYlHp7hbf6RN; Mon, 18 Feb 2008 09:49:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E649A28C3FE; Mon, 18 Feb 2008 09:49:21 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4D228C35F for ; Mon, 18 Feb 2008 09:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9izj1Rh3HbU for ; Mon, 18 Feb 2008 09:49:19 -0800 (PST) Received: from smtpauth03.csee.onr.siteprotect.com (smtpauth03.csee.onr.siteprotect.com [64.26.60.137]) by core3.amsl.com (Postfix) with ESMTP id BE27928C1D1 for ; Mon, 18 Feb 2008 09:49:19 -0800 (PST) Received: from cornfed (unknown [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth03.csee.onr.siteprotect.com (Postfix) with ESMTP id 3CF0D1038007; Mon, 18 Feb 2008 11:49:17 -0600 (CST) From: "Frank W. Miller" To: "'Hadriel Kaplan'" , "'Henry Sinnreich'" , "'Paul Kyzivat'" , "'Shockey, Richard'" Date: Mon, 18 Feb 2008 10:49:05 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchyPaUwZNySpUlPSZ2WJ432wEU9pAADJbXAAAGO2yAAAIRnUAAA8Gsg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: Message-Id: <20080218174917.3CF0D1038007@smtpauth03.csee.onr.siteprotect.com> Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Intesting point. But again, I'll ask the question. So what? If the call goes to or come from somewhere that's unintended, one or the other party just hangs up (I do it all the time when the telemarketers call ;) ). Why do we need all this infrastructure if a simple operational usage solves this problem well enough? Thanks, FM -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Monday, February 18, 2008 10:45 AM To: Frank W. Miller; 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' Cc: 'IETF SIP List' Subject: RE: [Sip] New I-D on RFC4474 and phone numbers I think we're trying to get something out of the signature that currently isn't fully there: caller-id. Currently rfc4474 just tells you that the signer sent the request to someone (not necessarily you), within the past hour, with the attached body unchanged between it and you. Per rfc4474 that signer should have verified the authenticity of the AoR in the From before sending it. If the signing domain didn't do strong verification of the From before signing an email-style URI, the impact of such is really against the signing domain. In other words its in the signing domain's best interest to get it right, because it's affecting their own customers' identity legitimacy. But when a signing domain signs an e164 that is not its own, it's affecting a global number's legitimacy - its spoofing the identity of someone outside of the signing domain. Without some way to verify the signing domain *owns* that e164, you have no way to know if it's good or not. For example, if a provider gets a call from a PSTN tandem trunk, and passes it on in SIP, they really shouldn't sign its From, because they have no way to verify the authenticity of its user part. (CLID spoofing is not a new phenomenon) And likewise if an enterprise signs an e164 other than their own, it would be an error. But there is currently no way to detect such errors or intentional mischief. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Frank W. Miller > Sent: Monday, February 18, 2008 12:08 PM > To: 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' > Cc: 'IETF SIP List' > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > I'm a little confused by the need to "sign" phone numbers. I mean, > whomever > uses the number makes a call to or from it right? If the receiver of the > call doesn't want to talk to whomever calls, don't they just hang up? > This > seems like a lot of extra work for little gain. > > Thanks, > FM _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 09:49:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E269428C53F; Mon, 18 Feb 2008 09:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.633 X-Spam-Level: X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiZo2IOjiwsT; Mon, 18 Feb 2008 09:49:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FCD3A6C75; Mon, 18 Feb 2008 09:49:27 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4137228C1D1 for ; Mon, 18 Feb 2008 09:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIboUtduNenD for ; Mon, 18 Feb 2008 09:49:25 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4CE3D28C499 for ; Mon, 18 Feb 2008 09:49:24 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1IHnJ8r024612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2008 11:49:21 -0600 Message-Id: From: Dean Willis To: "Frank W. Miller" In-Reply-To: <20080218161943.DB8531C8065@smtpauth01.csee.onr.siteprotect.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 18 Feb 2008 11:49:14 -0600 References: <20080218161943.DB8531C8065@smtpauth01.csee.onr.siteprotect.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 18, 2008, at 11:07 AM, Frank W. Miller wrote: > I'm a little confused by the need to "sign" phone numbers. I mean, > whomever > uses the number makes a call to or from it right? If the receiver > of the > call doesn't want to talk to whomever calls, don't they just hang > up? This > seems like a lot of extra work for little gain. How do they know who called? Can the thing being presented as caller- ID be trusted? Example use case: You get a call from "Memorial Hospital" at 999-454-5678. Your child was apparently injured at school and is claimed to be in ICU, but your signature is urgently needed before a life-saving procedure can be administered. You double-check by calling back 999-454-5678 and get the front desk at Memorial Hospital. Just to be sure, you look in the phone book, and yep, that's their number. Of course, you rush to the hospital. While you're out, the burglar who faked the call cleans out your house. Or even more fun: Your neighbors are having a really noisy party. Call 911, faking their phone number as the source, and report a murder-in- progress. Stand by and wait for the SWAT team to show up. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 09:52:40 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D15628C489; Mon, 18 Feb 2008 09:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id futaTh5zTtWC; Mon, 18 Feb 2008 09:52:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5AE3A6CD8; Mon, 18 Feb 2008 09:52:39 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BB83A6C75 for ; Mon, 18 Feb 2008 09:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8C4KBXpaaSg for ; Mon, 18 Feb 2008 09:52:36 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 02F403A68FE for ; Mon, 18 Feb 2008 09:52:35 -0800 (PST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m1IHqW4k029034; Mon, 18 Feb 2008 11:52:33 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m1IHqWj13665; Mon, 18 Feb 2008 11:52:32 -0600 (CST) Message-ID: <47B9C5E0.3060307@alcatel-lucent.com> Date: Mon, 18 Feb 2008 11:52:32 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis References: <47B69D8C.8060605@softarmor.com> In-Reply-To: <47B69D8C.8060605@softarmor.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: sip@ietf.org Subject: Re: [Sip] Headsup on Short Agenda for IETF 71 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Here are the things on our charter we're currently late on: > > 7) Connection reuse mechanism -09 was submitted on Feb 8 and it included the comments raised during WGLC review and subsequent list discussion. > 13) X.509 Certificates for TLS use in SIP (done?) Yes. Needs WG review. > 14) X.509 extended key usage for SIP (done?) Just submitted an updated -01 for sip-eku. Needs WG review, probably along with PKIX's as well. Thanks, Dean. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 09:52:55 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF1F28C543; Mon, 18 Feb 2008 09:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.686 X-Spam-Level: X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijoPV5q6-G7f; Mon, 18 Feb 2008 09:52:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0047028C52C; Mon, 18 Feb 2008 09:52:54 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6161828C40B for ; Mon, 18 Feb 2008 09:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vMwNT7lQZRT for ; Mon, 18 Feb 2008 09:52:52 -0800 (PST) Received: from smtpauth02.csee.onr.siteprotect.com (smtpauth02.csee.onr.siteprotect.com [64.26.60.136]) by core3.amsl.com (Postfix) with ESMTP id 8B67B28C52C for ; Mon, 18 Feb 2008 09:52:52 -0800 (PST) Received: from cornfed (unknown [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth02.csee.onr.siteprotect.com (Postfix) with ESMTP id 43ED4E38024; Mon, 18 Feb 2008 11:52:50 -0600 (CST) From: "Frank W. Miller" To: "'Dean Willis'" Date: Mon, 18 Feb 2008 10:52:38 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchyVpc6WzUBtjD9Q4GEhiBZNTJJMQAACUqw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: Message-Id: <20080218175250.43ED4E38024@smtpauth02.csee.onr.siteprotect.com> Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org K, got this just after my response. Inline... -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, February 18, 2008 10:49 AM To: Frank W. Miller Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers On Feb 18, 2008, at 11:07 AM, Frank W. Miller wrote: > I'm a little confused by the need to "sign" phone numbers. I mean, > whomever > uses the number makes a call to or from it right? If the receiver > of the > call doesn't want to talk to whomever calls, don't they just hang > up? This > seems like a lot of extra work for little gain. How do they know who called? Can the thing being presented as caller- ID be trusted? Example use case: You get a call from "Memorial Hospital" at 999-454-5678. Your child was apparently injured at school and is claimed to be in ICU, but your signature is urgently needed before a life-saving procedure can be administered. You double-check by calling back 999-454-5678 and get the front desk at Memorial Hospital. Just to be sure, you look in the phone book, and yep, that's their number. Of course, you rush to the hospital. FM: Call me crazy but I get weird caller-ids on my phones all the time now, with the trusted PSTN. You don't think that people won't figure out how to circumvent what we do if they really want to? While you're out, the burglar who faked the call cleans out your house. Or even more fun: Your neighbors are having a really noisy party. Call 911, faking their phone number as the source, and report a murder-in- progress. Stand by and wait for the SWAT team to show up. FM: Any reasonable person would call the hospital back first before rushing out. Besides, this same trick can be done now with Private or Blocked in the PSTN. FM _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 10:16:20 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4725F28C44B; Mon, 18 Feb 2008 10:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvNr9czbc0FG; Mon, 18 Feb 2008 10:16:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003BA28C3CA; Mon, 18 Feb 2008 10:16:19 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B2228C3D0 for ; Mon, 18 Feb 2008 10:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrfBjCK8KpaC for ; Mon, 18 Feb 2008 10:16:16 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 91A2928C342 for ; Mon, 18 Feb 2008 10:16:16 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 13:16:01 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 13:15:58 -0500 From: Hadriel Kaplan To: "Frank W. Miller" , 'Henry Sinnreich' , 'Paul Kyzivat' , "'Shockey, Richard'" Date: Mon, 18 Feb 2008 13:14:56 -0500 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyPaUwZNySpUlPSZ2WJ432wEU9pAADJbXAAAGO2yAAAIRnUAAA8GsgAAATa7A= Message-ID: References: <20080218174917.3CF0D1038007@smtpauth03.csee.onr.siteprotect.com> In-Reply-To: <20080218174917.3CF0D1038007@smtpauth03.csee.onr.siteprotect.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Two reasons off the top of my head: SPIT and Phishing. Phishing: how do you know who the caller is? If a call comes in claiming your Bank's phone number, or the local Police, or whatever, would you hang up? How would you know to? You probably would be suspicious, being a technically savvy individual, but plenty of people click on the false PayPal links in email. My wife did, for example, and needless to say two hours later the credit card company called saying there had been suspicious charges. (at which point I asked her how did she know it was the credit card company!) If the Caller-id was at least verifiable, there'd be recourse for law enforcement to find the caller. SPIT: Your phone rang, you answered, and then learned it was a telemarketer. They succeeded. You hung up, but many don't. A "telemarketer" call actually isn't SPIT in my book, if they use a legitimate CLID. (for some people it still is though) But if they can just pick random E.164's as CLIDs, SIP will turn into email, and that ain't good. I don't want my phone to ring constantly. Current email form of spam detection doesn't make sense for VoIP. IF we can get a verifiable caller-id, then there's a chance of stopping it with blacklists/whitelists or reputation systems or whatever. (I think that task is rather daunting in itself, but that's the premise anyway) -hadriel > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > Sent: Monday, February 18, 2008 12:49 PM > To: Hadriel Kaplan; 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' > Cc: 'IETF SIP List' > Subject: RE: [Sip] New I-D on RFC4474 and phone numbers > > > > Intesting point. But again, I'll ask the question. So what? If the call > goes to or come from somewhere that's unintended, one or the other party > just hangs up (I do it all the time when the telemarketers call ;) ). > Why > do we need all this infrastructure if a simple operational usage solves > this > problem well enough? > > Thanks, > FM > > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, February 18, 2008 10:45 AM > To: Frank W. Miller; 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' > Cc: 'IETF SIP List' > Subject: RE: [Sip] New I-D on RFC4474 and phone numbers > > I think we're trying to get something out of the signature that currently > isn't fully there: caller-id. Currently rfc4474 just tells you that the > signer sent the request to someone (not necessarily you), within the past > hour, with the attached body unchanged between it and you. Per rfc4474 > that > signer should have verified the authenticity of the AoR in the From before > sending it. > > If the signing domain didn't do strong verification of the From before > signing an email-style URI, the impact of such is really against the > signing > domain. In other words its in the signing domain's best interest to get > it > right, because it's affecting their own customers' identity legitimacy. > But > when a signing domain signs an e164 that is not its own, it's affecting a > global number's legitimacy - its spoofing the identity of someone outside > of > the signing domain. Without some way to verify the signing domain *owns* > that e164, you have no way to know if it's good or not. > > For example, if a provider gets a call from a PSTN tandem trunk, and > passes > it on in SIP, they really shouldn't sign its From, because they have no > way > to verify the authenticity of its user part. (CLID spoofing is not a new > phenomenon) And likewise if an enterprise signs an e164 other than their > own, it would be an error. But there is currently no way to detect such > errors or intentional mischief. > > -hadriel > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > > Frank W. Miller > > Sent: Monday, February 18, 2008 12:08 PM > > To: 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' > > Cc: 'IETF SIP List' > > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > > > I'm a little confused by the need to "sign" phone numbers. I mean, > > whomever > > uses the number makes a call to or from it right? If the receiver of > the > > call doesn't want to talk to whomever calls, don't they just hang up? > > This > > seems like a lot of extra work for little gain. > > > > Thanks, > > FM _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 10:28:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869EB3A6C71; Mon, 18 Feb 2008 10:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=-2.617, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD7j0JfI1fhs; Mon, 18 Feb 2008 10:28:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CFD3A6C5C; Mon, 18 Feb 2008 10:28:26 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E4328C3DE for ; Mon, 18 Feb 2008 10:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iydkmVGF54d4 for ; Mon, 18 Feb 2008 10:28:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2B4943A6899 for ; Mon, 18 Feb 2008 10:28:22 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2008 13:28:19 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1IISJRJ008740; Mon, 18 Feb 2008 13:28:19 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IISGWF016192; Mon, 18 Feb 2008 18:28:19 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 13:28:15 -0500 Received: from [161.44.183.216] ([161.44.183.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 13:28:15 -0500 Message-ID: <47B9CE49.7080504@cisco.com> Date: Mon, 18 Feb 2008 13:28:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Frank W. Miller" References: <20080218175250.43ED4E38024@smtpauth02.csee.onr.siteprotect.com> In-Reply-To: <20080218175250.43ED4E38024@smtpauth02.csee.onr.siteprotect.com> X-OriginalArrivalTime: 18 Feb 2008 18:28:15.0555 (UTC) FILETIME=[06BB3930:01C8725C] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'IETF SIP List' , 'Dean Willis' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Frank, So are you asserting that reliable callerid is not needed, or that it is not possible? If its not needed, then I guess sip identity was a waste of time, as is P-Asserted-ID. From should be good enough. The PSTN callerid is to a large extend based on transitive trust, and is reliable if the providers are careful. It breaks when providers trust sources that they shouldn't. Apparently that is becoming an increasingly common case. If we create a cert-based mechanism similar to 4474 that works for phone numbers then there should be no way around it other than stealing the certs. So it should be better than the PSTN. Paul Frank W. Miller wrote: > > K, got this just after my response. Inline... > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, February 18, 2008 10:49 AM > To: Frank W. Miller > Cc: IETF SIP List > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > > On Feb 18, 2008, at 11:07 AM, Frank W. Miller wrote: > >> I'm a little confused by the need to "sign" phone numbers. I mean, >> whomever >> uses the number makes a call to or from it right? If the receiver >> of the >> call doesn't want to talk to whomever calls, don't they just hang >> up? This >> seems like a lot of extra work for little gain. > > How do they know who called? Can the thing being presented as caller- > ID be trusted? > > Example use case: > > You get a call from "Memorial Hospital" at 999-454-5678. Your child > was apparently injured at school and is claimed to be in ICU, but your > signature is urgently needed before a life-saving procedure can be > administered. You double-check by calling back 999-454-5678 and get > the front desk at Memorial Hospital. Just to be sure, you look in the > phone book, and yep, that's their number. Of course, you rush to the > hospital. > > FM: Call me crazy but I get weird caller-ids on my phones all the time now, > with the trusted PSTN. You don't think that people won't figure out how to > circumvent what we do if they really want to? > > > While you're out, the burglar who faked the call cleans out your house. > > Or even more fun: Your neighbors are having a really noisy party. Call > 911, faking their phone number as the source, and report a murder-in- > progress. Stand by and wait for the SWAT team to show up. > > > FM: Any reasonable person would call the hospital back first before rushing > out. Besides, this same trick can be done now with Private or Blocked in > the PSTN. > > FM > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 10:33:55 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BD728C3DE; Mon, 18 Feb 2008 10:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aqtoXpWPApj; Mon, 18 Feb 2008 10:33:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C933A6CCA; Mon, 18 Feb 2008 10:33:54 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9C53A6CE0 for ; Mon, 18 Feb 2008 10:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ju+rk05D9V1 for ; Mon, 18 Feb 2008 10:33:51 -0800 (PST) Received: from smtpauth01.csee.onr.siteprotect.com (smtpauth01.csee.onr.siteprotect.com [64.26.60.145]) by core3.amsl.com (Postfix) with ESMTP id 2B31F3A6CE1 for ; Mon, 18 Feb 2008 10:33:51 -0800 (PST) Received: from cornfed (unknown [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id 23DEC1C8043; Mon, 18 Feb 2008 11:45:33 -0600 (CST) From: "Frank W. Miller" To: "'Hadriel Kaplan'" , "'Henry Sinnreich'" , "'Paul Kyzivat'" , "'Shockey, Richard'" Date: Mon, 18 Feb 2008 11:33:37 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchyPaUwZNySpUlPSZ2WJ432wEU9pAADJbXAAAGO2yAAAIRnUAAA8GsgAAATa7AAAQmpgA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: Message-Id: <20080218174533.23DEC1C8043@smtpauth01.csee.onr.siteprotect.com> Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Again, interesting. Inline... FM -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, February 18, 2008 11:15 AM To: Frank W. Miller; 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers Two reasons off the top of my head: SPIT and Phishing. Phishing: how do you know who the caller is? If a call comes in claiming your Bank's phone number, or the local Police, or whatever, would you hang up? How would you know to? You probably would be suspicious, being a technically savvy individual, but plenty of people click on the false PayPal links in email. My wife did, for example, and needless to say two hours later the credit card company called saying there had been suspicious charges. (at which point I asked her how did she know it was the credit card company!) If the Caller-id was at least verifiable, there'd be recourse for law enforcement to find the caller. FM: I don't think we can equate email Phishing with Phishing in the phone system. There are two reasons. First, email is just a lot easier to do this with. I don't mean its easier because its easier to disguise your identity with email. I mean its easier because it takes less effort economically to actual fire off a million emails than it does to make a million phone calls, even with automated systems. Second, Phishing exists in the PSTN now. Yes it's a problem but, if we can't stop it there, what makes you think we'll be able to stop it here. While we can do lots of fancy (and expensive) things to protect ourselves in the IP world, the counterbalance is that hacking IP based systems is a lot easier than hacking the PSTN. The best thing to do is to tell your wife and kids what I've told mine, never, ever, ever click on a link that you're not absolutely sure where it came from or who it is. Unsolicited emails don't fall into that category. SPIT: Your phone rang, you answered, and then learned it was a telemarketer. They succeeded. You hung up, but many don't. A "telemarketer" call actually isn't SPIT in my book, if they use a legitimate CLID. (for some people it still is though) But if they can just pick random E.164's as CLIDs, SIP will turn into email, and that ain't good. I don't want my phone to ring constantly. Current email form of spam detection doesn't make sense for VoIP. IF we can get a verifiable caller-id, then there's a chance of stopping it with blacklists/whitelists or reputation systems or whatever. (I think that task is rather daunting in itself, but that's the premise anyway) FM: I'd luv to be able to do this but... What do you do when a number comes in that is just a number, i.e. it doesn't have a "caller id" associated with it? That happens all the time to me and would probably happen all the time for IP systems as well. It may be signed but so what? You may not know where that number is, but what do you do? Most people just answer it. If its SPIT, you hangup. Why is that so hard? If we're going to stay with the anachronism of phone numbers, why can't we just stay with the remedies that have been developed for it, Do-Not-Call lists and laws governing telemarketers and legal action against them and such. Those are the things that modify the behavior of humans ultimately, not our technology. -hadriel > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > Sent: Monday, February 18, 2008 12:49 PM > To: Hadriel Kaplan; 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' > Cc: 'IETF SIP List' > Subject: RE: [Sip] New I-D on RFC4474 and phone numbers > > > > Intesting point. But again, I'll ask the question. So what? If the call > goes to or come from somewhere that's unintended, one or the other party > just hangs up (I do it all the time when the telemarketers call ;) ). > Why > do we need all this infrastructure if a simple operational usage solves > this > problem well enough? > > Thanks, > FM > > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, February 18, 2008 10:45 AM > To: Frank W. Miller; 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' > Cc: 'IETF SIP List' > Subject: RE: [Sip] New I-D on RFC4474 and phone numbers > > I think we're trying to get something out of the signature that currently > isn't fully there: caller-id. Currently rfc4474 just tells you that the > signer sent the request to someone (not necessarily you), within the past > hour, with the attached body unchanged between it and you. Per rfc4474 > that > signer should have verified the authenticity of the AoR in the From before > sending it. > > If the signing domain didn't do strong verification of the From before > signing an email-style URI, the impact of such is really against the > signing > domain. In other words its in the signing domain's best interest to get > it > right, because it's affecting their own customers' identity legitimacy. > But > when a signing domain signs an e164 that is not its own, it's affecting a > global number's legitimacy - its spoofing the identity of someone outside > of > the signing domain. Without some way to verify the signing domain *owns* > that e164, you have no way to know if it's good or not. > > For example, if a provider gets a call from a PSTN tandem trunk, and > passes > it on in SIP, they really shouldn't sign its From, because they have no > way > to verify the authenticity of its user part. (CLID spoofing is not a new > phenomenon) And likewise if an enterprise signs an e164 other than their > own, it would be an error. But there is currently no way to detect such > errors or intentional mischief. > > -hadriel > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > > Frank W. Miller > > Sent: Monday, February 18, 2008 12:08 PM > > To: 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard' > > Cc: 'IETF SIP List' > > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > > > I'm a little confused by the need to "sign" phone numbers. I mean, > > whomever > > uses the number makes a call to or from it right? If the receiver of > the > > call doesn't want to talk to whomever calls, don't they just hang up? > > This > > seems like a lot of extra work for little gain. > > > > Thanks, > > FM _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 10:38:04 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED4D28C4B8; Mon, 18 Feb 2008 10:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b2Tsnf1ymIa; Mon, 18 Feb 2008 10:38:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C60F3A6CE9; Mon, 18 Feb 2008 10:38:03 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712CC3A68A7 for ; Mon, 18 Feb 2008 10:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCa54vJVM1GZ for ; Mon, 18 Feb 2008 10:38:00 -0800 (PST) Received: from smtpauth00.csee.onr.siteprotect.com (smtpauth00.csee.onr.siteprotect.com [64.26.60.144]) by core3.amsl.com (Postfix) with ESMTP id 4C5D928C4B4 for ; Mon, 18 Feb 2008 10:38:00 -0800 (PST) Received: from cornfed (unknown [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id E892C758072; Mon, 18 Feb 2008 12:37:57 -0600 (CST) From: "Frank W. Miller" To: "'Paul Kyzivat'" Date: Mon, 18 Feb 2008 11:37:46 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchyXAqSwatk5ygPS3Sg1J8IqVO50gAAMYHg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <47B9CE49.7080504@cisco.com> Message-Id: <20080218183757.E892C758072@smtpauth00.csee.onr.siteprotect.com> Cc: 'IETF SIP List' , 'Dean Willis' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Inline... -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, February 18, 2008 11:28 AM To: Frank W. Miller Cc: 'Dean Willis'; 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers Frank, So are you asserting that reliable callerid is not needed, or that it is not possible? FM: Not possible enough to justify the expense. If its not needed, then I guess sip identity was a waste of time, as is P-Asserted-ID. From should be good enough. FM: Well, waste of time would not be the exact words I would use... ;) The PSTN callerid is to a large extend based on transitive trust, and is reliable if the providers are careful. It breaks when providers trust sources that they shouldn't. Apparently that is becoming an increasingly common case. FM: Yes and no. Its definitely based on trust that we don't assume in IP based systems. And its still relatively easy to get around. If we create a cert-based mechanism similar to 4474 that works for phone numbers then there should be no way around it other than stealing the certs. So it should be better than the PSTN. FM: Look, I'm sure this community is going to probably go off and spend a lot of time doing this. And there may ultimately be large, expensive deployments of certs and signatures, etc. etc. Just don't kid yourself that its going to stop phishing or spit cuz it won't _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 11:44:01 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63FF28C1D6; Mon, 18 Feb 2008 11:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUQ2duKoDv-C; Mon, 18 Feb 2008 11:44:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB8A28C59A; Mon, 18 Feb 2008 11:39:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C7428C593 for ; Mon, 18 Feb 2008 11:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc4VXCAnRBTZ for ; Mon, 18 Feb 2008 11:39:22 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A11E83A6D6E for ; Mon, 18 Feb 2008 11:36:43 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2008 11:36:41 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1IJafjS010311 for ; Mon, 18 Feb 2008 11:36:41 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1IJaZK2028575 for ; Mon, 18 Feb 2008 19:36:41 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 11:36:39 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 11:36:39 -0800 Message-ID: <47B9DE39.60608@cisco.com> Date: Mon, 18 Feb 2008 14:36:25 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Paul Kyzivat References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> In-Reply-To: <47B99B39.6040105@cisco.com> X-OriginalArrivalTime: 18 Feb 2008 19:36:39.0250 (UTC) FILETIME=[94B96320:01C87265] Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree that something along the lines of enum could solve this problem, and I believe there was a draft that proposed such a thing. This has been discussed since the start of rfc4474. However, I fear that saying, 'use enum' is kind of like saying, we'll just use an All-Knowing Oracle, so lets figure out the interface protocol to the Oracle. The easy part is the interface (the enum mechanism). The actual hard problem is how to get those entries populated. The deployment of public enum has been - shall we say - less than spectacular. I'd hate for that to be our only solution. Not that its obvious what else to do; though I do suggest in my draft how domain based authentication, when combined with whitelists and blacklists, can help. -Jonathan R. Paul Kyzivat wrote: > Jonathan, > > I guess the time has come for this discussion, since John Ewell has also > submitted a draft on this subject. > > I thought the problem was already well known, but perhaps not. IMO the > main thing now is to figure out the *solution* to the problem! > IMO a solution is to use a 4474-style approach, but where the > certificate is tied to just the phone number, not to some arbitrary > domain name. That of course would depend on a model where the "owner" of > the phone number is the one who may obtain the certificate for that number. > > My thought is that we already have an algorithmic mapping from an E.164 > phone number to a domain name, defined by enum. If the sender puts an > E.164 number in From, and can sign it with a cert for the enum mapped > domain name corresponding to that number, then that ought to be valid > proof of the validity of the sender. > > In those places where public enum is in operation, I think there is > already a legal mechanism in place to give the owner of record of a > particular phone number control over the contents of the corresponding > DNS entry. That should also be sufficient to allow a certificate > authority to assign a cert to that same owner. > > Combine all that and you have a complete e2e identity model for phone > numbers, based on public enum. And that can be true even if public enum > isn't used to *route* the calls to that number. So it could be used for > "unlisted" numbers. > > To use this approach the From header should contain either a TEL URI, or > a sip/sips URI containing the enum-mapped domain name corresponding to > the phone number. (I would rather see the TEL used for this - it is more > user friendly.) > > Thanks, > Paul > > Jonathan Rosenberg wrote: >> I just submitted: >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns-00.txt >> >> >> This is basically a discussion on the security properties of rfc4474 >> with phone numbers, and a comparison to rfc3325 in this case. Also a >> discussion on what happens to dtls-srtp. >> >> Comments welcome. >> >> -Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 11:48:12 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5081A28C335; Mon, 18 Feb 2008 11:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[AWL=-1.266, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMjv3TxhDPSn; Mon, 18 Feb 2008 11:48:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F1E28C40B; Mon, 18 Feb 2008 11:45:38 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B453E3A6D67 for ; Mon, 18 Feb 2008 11:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2bQIY5ajgng for ; Mon, 18 Feb 2008 11:45:36 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5CBBB28C645 for ; Mon, 18 Feb 2008 11:40:57 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2008 11:40:55 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1IJetKf018445; Mon, 18 Feb 2008 11:40:55 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1IJenuR021036; Mon, 18 Feb 2008 19:40:55 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 11:40:50 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 11:40:49 -0800 Message-ID: <47B9DF33.9070604@cisco.com> Date: Mon, 18 Feb 2008 14:40:35 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Joel M. Halpern" References: <47B9125B.2060104@cisco.com> <47B9B294.7010700@joelhalpern.com> In-Reply-To: <47B9B294.7010700@joelhalpern.com> X-OriginalArrivalTime: 18 Feb 2008 19:40:49.0782 (UTC) FILETIME=[2A0D8960:01C87266] Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: IETF SIP List Subject: Re: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I don't think it is very clear anywhere in our current RFCs, that the presence of a + in the user part, along with user=phone, actually implies that the user is reachable by that e164 directly. Overall this remains a messy area for us. I took a stab at trying to sort some of it out in an I-D I published a while back: http://www.watersprings.org/pub/id/draft-rosenberg-rai-phone-names-numbers-00.txt and John's draft discusses similar issues. -Jonathan R. Joel M. Halpern wrote: > I have been pestering various people off list, and have decided to see > whether someone else understands and can explain this in a way I can > follow. The following is somewhat longer than I like. Sorry. > > The pair of questions is: > When should the user part of a SIP URI be considered an E.164 number? > And what assertion is being made by such consideration? > > Taking them backwards, as far as I can tell from reading the RFCs and > the I-Ds, the assertion that is supposed to hold is that if a SIP URI > can be properly understood to have an E.164 number in it's user part, > and if it legitimately has that number, then the party the SIP URI > represents can also be reached by calling the E.164 number on the PSTN. > > There are some interesting ambiguities left even with that definition, > but we can live with it. > > So, when does the user part have an E.164 number, so that it is > reasonable to ask if the assertion holds? > As far as I can tell, there are three cases: > > Case 1 - No ;user=phone option > In the absence of a ;user=phone option, the user part of the SIP URI > should be considered an opaque string. It should not be considered an > E.164 number, even if it is formatted as a telephone subscriber number. > I can legitimately use +17035555555@joelhalpern.com as a SIP URI. And > if the whitehouse.com deliberate confusion is still active, they could > use +12024561414@whitehouse.com as a SIP URI. > It is reported that some SIP devices will display the phone number > without the domain for such URIs. That is a UI error, not a protocol > error. The protocol can not make the UI do the right thing. > > Case 2 - ;user=phone option present, no ;phone-context= option > I believe this is an assertion that the user part of the SIP URI is an > E.164 number, and that if one is doing validation E.164 validation is > appropriate. The whole question of the meaning of the domain, and > whether we are better off with tel: URIs applies to this form of SIP URI. > While it is possible (any character string is possible) to have a SIP > URI with ;user=phone and no ;phone-context and not have the user part > formatted as a telephone-subscriber number, such a mismatch looks to me > to be a violation of RFC 3261. The only reasonable handling is that if > one is trying to perform E.164 validation, such validation will fail on > such a SIP URI. > > Case 3 - ;user=phone and ;phone-context= options present > The RFCs seem to say explicitly that the user part of the SIP URI can > not be considered an E.164 number, and that one can not even expect to > concatenate the phone context and the user part to get an E.164 number. > So there can be no E.164 validation because there is no E.164 number. > > > Some folks seem to have suggested that one should observe the format of > the user part of the SIP URI in order to decide if an E.164 number is > intended. I sincerely hope that is note the case. > > Yours, > Joel M. Halpern > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 11:56:55 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7BF928C586; Mon, 18 Feb 2008 11:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+ySg7S-i8YV; Mon, 18 Feb 2008 11:56:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620413A6C3F; Mon, 18 Feb 2008 11:56:23 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D90F3A689E for ; Mon, 18 Feb 2008 11:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev1Hr-Y+KDlf for ; Mon, 18 Feb 2008 11:56:19 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id F18BC28C364 for ; Mon, 18 Feb 2008 11:55:07 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1IJsli4006825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 20:54:47 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1IJsjW2007789; Mon, 18 Feb 2008 20:54:45 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Feb 2008 20:54:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 20:54:39 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> In-Reply-To: <47B9DE39.60608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyZulElgl5PP+qQYG8DvAYAxoq4AAABmmg References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Jonathan Rosenberg" , "Paul Kyzivat" X-OriginalArrivalTime: 18 Feb 2008 19:54:45.0085 (UTC) FILETIME=[1BEEA8D0:01C87268] Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Jonathan, = Hi Paul, thanks for raising the aspect of E.164 and ENUM usage. There was an offline= discussion between Dan Wing, Klaus Darilion, Kai Fischer, David Schwartz, = Hadriel Kaplan, John Elwell, and myself about E.164 and SIP Identity. As pa= rt of the discussion Klaus and I polished a former document of Alexander Ma= yrhofer on the usage of ENUM for E.164 numbers (see draft-mayrhofer-enum-do= mainkeys-00). As we moved along with the work we obviously came across a co= uple of problems (as one can easily imagine) and the document triggered a l= ong discussion among us. Dispite a couple of challenges, we published the d= ocument today (see http://www.ietf.org/internet-drafts/draft-darilion-sip-e= 164-enum-00.txt). I learned a lot while working on that document. = In addition to publishing the document a few of us have also worked on a do= cument that captures some of our discussion on E.164 number ownership. I wi= ll publish it very soon -- just a bit more proof-reading. = Ciao Hannes = > -----Urspr=FCngliche Nachricht----- > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im = > Auftrag von ext Jonathan Rosenberg > Gesendet: Montag, 18. Februar 2008 21:36 > An: Paul Kyzivat > Cc: IETF SIP List > Betreff: Re: [Sip] New I-D on RFC4474 and phone numbers > = > I agree that something along the lines of enum could solve = > this problem, = > and I believe there was a draft that proposed such a thing. This has = > been discussed since the start of rfc4474. > = > However, I fear that saying, 'use enum' is kind of like saying, we'll = > just use an All-Knowing Oracle, so lets figure out the interface = > protocol to the Oracle. The easy part is the interface (the enum = > mechanism). The actual hard problem is how to get those entries = > populated. The deployment of public enum has been - shall we = > say - less = > than spectacular. I'd hate for that to be our only solution. Not that = > its obvious what else to do; though I do suggest in my draft = > how domain = > based authentication, when combined with whitelists and = > blacklists, can = > help. > = > -Jonathan R. > = > Paul Kyzivat wrote: > > Jonathan, > > = > > I guess the time has come for this discussion, since John = > Ewell has also = > > submitted a draft on this subject. > > = > > I thought the problem was already well known, but perhaps = > not. IMO the = > > main thing now is to figure out the *solution* to the problem! > > IMO a solution is to use a 4474-style approach, but where the = > > certificate is tied to just the phone number, not to some arbitrary = > > domain name. That of course would depend on a model where = > the "owner" of = > > the phone number is the one who may obtain the certificate = > for that number. > > = > > My thought is that we already have an algorithmic mapping = > from an E.164 = > > phone number to a domain name, defined by enum. If the = > sender puts an = > > E.164 number in From, and can sign it with a cert for the = > enum mapped = > > domain name corresponding to that number, then that ought = > to be valid = > > proof of the validity of the sender. > > = > > In those places where public enum is in operation, I think there is = > > already a legal mechanism in place to give the owner of record of a = > > particular phone number control over the contents of the = > corresponding = > > DNS entry. That should also be sufficient to allow a certificate = > > authority to assign a cert to that same owner. > > = > > Combine all that and you have a complete e2e identity model = > for phone = > > numbers, based on public enum. And that can be true even if = > public enum = > > isn't used to *route* the calls to that number. So it could = > be used for = > > "unlisted" numbers. > > = > > To use this approach the From header should contain either = > a TEL URI, or = > > a sip/sips URI containing the enum-mapped domain name = > corresponding to = > > the phone number. (I would rather see the TEL used for this = > - it is more = > > user friendly.) > > = > > Thanks, > > Paul > > = > > Jonathan Rosenberg wrote: > >> I just submitted: > >> = > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc447 > 4-concerns-00.txt = > >> > >> > >> This is basically a discussion on the security properties = > of rfc4474 = > >> with phone numbers, and a comparison to rfc3325 in this = > case. Also a = > >> discussion on what happens to dtls-srtp. > >> > >> Comments welcome. > >> > >> -Jonathan R. > > = > = > -- = > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 11:57:32 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AECDE3A6C3F; Mon, 18 Feb 2008 11:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4ZtzIXDjVGZ; Mon, 18 Feb 2008 11:57:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410FC28C49F; Mon, 18 Feb 2008 11:56:58 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F6428C490 for ; Mon, 18 Feb 2008 11:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuLVRWX9f9qQ for ; Mon, 18 Feb 2008 11:56:55 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 90B2528C46F for ; Mon, 18 Feb 2008 11:56:23 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 14:56:08 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 14:56:03 -0500 From: Hadriel Kaplan To: "Frank W. Miller" , 'Henry Sinnreich' , 'Paul Kyzivat' , "'Shockey, Richard'" Date: Mon, 18 Feb 2008 14:55:01 -0500 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyPaUwZNySpUlPSZ2WJ432wEU9pAADJbXAAAGO2yAAAIRnUAAA8GsgAAATa7AAAQmpgAABpXvw Message-ID: References: <20080218174533.23DEC1C8043@smtpauth01.csee.onr.siteprotect.com> In-Reply-To: <20080218174533.23DEC1C8043@smtpauth01.csee.onr.siteprotect.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > Sent: Monday, February 18, 2008 1:34 PM > > FM: I don't think we can equate email Phishing with Phishing in the phone > system. There are two reasons. First, email is just a lot easier to do > this with. I don't mean its easier because its easier to disguise your > identity with email. I mean its easier because it takes less effort > economically to actual fire off a million emails than it does to make a > million phone calls, even with automated systems. Yes, there is no debate that cost/expense and closed networks have kept phone calls from being hammered like email. Unfortunately/fortunately, that cost is dropping. This topic isn't about today - it's about 5-20+ years from now. If the call cost drops at the current rate, and if enough SIP providers peer with each other and/or it opens up more, then we'll have a problem. For me, it's particularly the peering problem that concerns me. (for obvious reasons) That's a lot of "ifs", but really the IETF's time has been spent on protocols and methods with far less chance of success or potential need. ;) With regard to performance, we already have a tool which can generate 1 Million call attempts, each to different targets, each with random From's, in approximately 5 seconds. This tool is purely software running on MS Windows. It can do it (and has) running on my laptop, which has a GigE interface. The tool can send pre-recorded RTP media to as many destinations as 200K packets/sec can cover for the codec rate and ptime. It's not able to complete dialogs, or make full calls, and trying to do so would reduce it immensely I'm sure. But it would only have to do that for the calls that answer. The only thing that stops such a thing from succeeding other than cost is that the SIP infrastructure can't deal with that kind of rate, so certain devices at provider borders are built to stop it. But as the performance of the provider equipment increases, or more entry points are available, it's the per-call cost (or bulk cost) that will prevent it, and once that's down enough we could be in trouble without some form of strong identity. > SPIT: Your phone rang, you answered, and then learned it was a > telemarketer. > They succeeded. You hung up, but many don't. A "telemarketer" call > actually isn't SPIT in my book, if they use a legitimate CLID. (for some > people it still is though) But if they can just pick random E.164's as > CLIDs, SIP will turn into email, and that ain't good. I don't want my > phone > to ring constantly. Current email form of spam detection doesn't make > sense > for VoIP. IF we can get a verifiable caller-id, then there's a chance of > stopping it with blacklists/whitelists or reputation systems or whatever. > (I > think that task is rather daunting in itself, but that's the premise > anyway) > > > FM: I'd luv to be able to do this but... What do you do when a number > comes in that is just a number, i.e. it doesn't have a "caller id" > associated with it? Then you know not to show a caller-id, and it is suspect. In other words the signing de-values those that aren't signed. > That happens all the time to me and would probably > happen all the time for IP systems as well. It may be signed but so what? > You may not know where that number is, but what do you do? Most people > just > answer it. If its SPIT, you hangup. Why is that so hard? If we're going > to stay with the anachronism of phone numbers, why can't we just stay with > the remedies that have been developed for it, Do-Not-Call lists and laws > governing telemarketers and legal action against them and such. Those are > the things that modify the behavior of humans ultimately, not our > technology. Do-not-call-lists and legal action are only possible if the source is verifiable, no? Calls originate and transit through providers outside of the local nationality, too. The "if it's SPIT you hang up" model doesn't work if the rate of SPIT is even a fraction of email's spam. You wouldn't put up with it, or at least most people wouldn't. -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 12:31:26 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5746728C78E; Mon, 18 Feb 2008 12:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+4CY43cNHM6; Mon, 18 Feb 2008 12:31:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8526D3A6D8F; Mon, 18 Feb 2008 12:27:44 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733493A6D89 for ; Mon, 18 Feb 2008 12:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRAZUy+piA1l for ; Mon, 18 Feb 2008 12:27:42 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9CA653A6D77 for ; Mon, 18 Feb 2008 12:21:19 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 15:21:04 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 15:21:04 -0500 From: Hadriel Kaplan To: IETF SIP List Date: Mon, 18 Feb 2008 15:20:02 -0500 Thread-Topic: New I-D on why From/To-URIs are changed at provider borders Thread-Index: AchyZulElgl5PP+qQYG8DvAYAxoq4AAABmmgAACz7qA= Message-ID: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> In-Reply-To: <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Sip] New I-D on why From/To-URIs are changed at provider borders X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org As part of an off-line discussion regarding Kai Fischer's draft on e2e-security-media and whether his From-URI copying tactic would succeed or not at a policy level, if rfc4474 fails to do so, I gave my 2 cents on what some providers had been telling me. Dan asked me to write up a draft on it, in case people are interested. This is the draft: http://www.ietf.org/internet-drafts/draft-kaplan-sip-uris-change-00.txt -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 12:55:23 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794EF28C3E3; Mon, 18 Feb 2008 12:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=-2.543, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDBXA8OcUZWA; Mon, 18 Feb 2008 12:55:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8428E28C521; Mon, 18 Feb 2008 12:52:21 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF083A6DC6 for ; Mon, 18 Feb 2008 12:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHqcCDSa+EN1 for ; Mon, 18 Feb 2008 12:52:17 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B28163A6D61 for ; Mon, 18 Feb 2008 12:49:51 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2008 12:49:49 -0800 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 m1IKnnQL013154; Mon, 18 Feb 2008 12:49:49 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IKngwB025193; Mon, 18 Feb 2008 20:49:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 15:49:48 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 15:49:48 -0500 Message-ID: <47B9EF77.8090201@cisco.com> Date: Mon, 18 Feb 2008 15:49:59 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> In-Reply-To: X-OriginalArrivalTime: 18 Feb 2008 20:49:48.0597 (UTC) FILETIME=[CCFA9650:01C8726F] Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, I took a look but didn't spend a lot of time. I can't understand it enough to figure out how it might apply. To me the basic points are that enum provides the basis for a *legal* definition of ownership of numbers, which could be tied to a CA scheme. Enum also provides a mapping from numbers to domain names, which provides a direct way to map to DNS-based certs. If this new scheme can be related to e.164 numbers then maybe it can apply as well. One thing I don't understand is how it would tie to a legal definition of ownership of the numbers. Paul Dean Willis wrote: > > On Feb 18, 2008, at 8:50 AM, Paul Kyzivat wrote: >> >> I thought the problem was already well known, but perhaps not. IMO the >> main thing now is to figure out the *solution* to the problem! >> IMO a solution is to use a 4474-style approach, but where the >> certificate is tied to just the phone number, not to some arbitrary >> domain name. That of course would depend on a model where the "owner" of >> the phone number is the one who may obtain the certificate for that >> number. > > > You might take a look at "Identity Based Authentication in the Session > Initiation Protocol", draft-kupwade-sip-iba-00. > > This draft is a bit incomplete, but it's the reduction of a far longer > master's thesis that I'm familiar with. > > It seems reasonably feasible to consider the phone number an "identity" > within the domain of an identity-based private key generator. The math > is now available to handle multiple levels of PKG hierarchy, which > allows key-generation delegation along the ENUM tree lines. On an > operational basis, it seems a lot easier to work with than a CA model. > > -- > Dean > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 13:07:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE58F28C34C; Mon, 18 Feb 2008 13:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.963 X-Spam-Level: X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=-2.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESzwDnroq9q3; Mon, 18 Feb 2008 13:07:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99DA43A6D74; Mon, 18 Feb 2008 13:07:25 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7693A6D5F for ; Mon, 18 Feb 2008 13:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DULdBNJ2pgP for ; Mon, 18 Feb 2008 13:07:22 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B32623A6D5C for ; Mon, 18 Feb 2008 13:07:20 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2008 16:07:17 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1IL7GV7006896; Mon, 18 Feb 2008 16:07:16 -0500 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 m1IL76SU023210; Mon, 18 Feb 2008 21:07:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 16:07:06 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 16:07:05 -0500 Message-ID: <47B9F385.4010804@cisco.com> Date: Mon, 18 Feb 2008 16:07:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Joel M. Halpern" References: <47B9125B.2060104@cisco.com> <47B9B294.7010700@joelhalpern.com> In-Reply-To: <47B9B294.7010700@joelhalpern.com> X-OriginalArrivalTime: 18 Feb 2008 21:07:05.0886 (UTC) FILETIME=[374053E0:01C87272] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: IETF SIP List Subject: Re: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Joel M. Halpern wrote: > I have been pestering various people off list, and have decided to see > whether someone else understands and can explain this in a way I can > follow. The following is somewhat longer than I like. Sorry. > > The pair of questions is: > When should the user part of a SIP URI be considered an E.164 number? > And what assertion is being made by such consideration? > > Taking them backwards, as far as I can tell from reading the RFCs and > the I-Ds, the assertion that is supposed to hold is that if a SIP URI > can be properly understood to have an E.164 number in it's user part, > and if it legitimately has that number, then the party the SIP URI > represents can also be reached by calling the E.164 number on the PSTN. The question about whether it "legitimately has that number" is troublesome. And whether the person can be reached via the PSTN is also questionable. For instance, suppose you received a call with only MSRP as media from such an address, and tried to return the call. If you used MSRP they it would almost certainly fail. (Unless there was an MSRP - SMS GW.) If you used voice it might still fail if the owner has no voice terminal registered. > There are some interesting ambiguities left even with that definition, > but we can live with it. > > So, when does the user part have an E.164 number, so that it is > reasonable to ask if the assertion holds? > As far as I can tell, there are three cases: > > Case 1 - No ;user=phone option > In the absence of a ;user=phone option, the user part of the SIP URI > should be considered an opaque string. It should not be considered an > E.164 number, even if it is formatted as a telephone subscriber number. > I can legitimately use +17035555555@joelhalpern.com as a SIP URI. And > if the whitehouse.com deliberate confusion is still active, they could > use +12024561414@whitehouse.com as a SIP URI. > It is reported that some SIP devices will display the phone number > without the domain for such URIs. That is a UI error, not a protocol > error. The protocol can not make the UI do the right thing. I agree with you. But common practice is otherwise. > Case 2 - ;user=phone option present, no ;phone-context= option > I believe this is an assertion that the user part of the SIP URI is an > E.164 number, and that if one is doing validation E.164 validation is > appropriate. I always interpreted this as meaning that the *syntax* of the user part conformed to the TEL URI. IMO it is much less clear that you have any guarantee that this identifies the same place you would reach if you made a PSTN call. > The whole question of the meaning of the domain, and > whether we are better off with tel: URIs applies to this form of SIP URI. > While it is possible (any character string is possible) to have a SIP > URI with ;user=phone and no ;phone-context and not have the user part > formatted as a telephone-subscriber number, such a mismatch looks to me > to be a violation of RFC 3261. Yes, syntax wise I agree. > The only reasonable handling is that if > one is trying to perform E.164 validation, such validation will fail on > such a SIP URI. > > Case 3 - ;user=phone and ;phone-context= options present > The RFCs seem to say explicitly that the user part of the SIP URI can > not be considered an E.164 number, and that one can not even expect to > concatenate the phone context and the user part to get an E.164 number. > So there can be no E.164 validation because there is no E.164 number. Yes, I agree. This is more a question about TEL URIs in general than about sip URIs. IMO there is opportunity for further standardization of how to generate routing to TEL URIs with phone-context parameters. But that is for the future. > Some folks seem to have suggested that one should observe the format of > the user part of the SIP URI in order to decide if an E.164 number is > intended. I sincerely hope that is note the case. Yes, I agree. IMO we have no business reserving that whole subset of the username space. However there is a sticky point. Registration is done without regard for parameters in the user part of the AOR, and translations based on the location service also ignore the parameters. So its impossible for a domain to have both: sip:+12024561414@whitehouse.com;user=phone sip:+12024561414@whitehouse.com as distinct AORs. In practice that reserves the whole e.164 space in domains that want to honor e.164 numbers. Paul > Yours, > Joel M. Halpern > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 13:39:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EAC3A6D7A; Mon, 18 Feb 2008 13:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=-2.483, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPPbUgtPw18d; Mon, 18 Feb 2008 13:39:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5399A3A6918; Mon, 18 Feb 2008 13:39:26 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93153A68A4 for ; Mon, 18 Feb 2008 13:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPZ-0He1gyjG for ; Mon, 18 Feb 2008 13:39:24 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C2E783A6918 for ; Mon, 18 Feb 2008 13:39:23 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2008 16:39:22 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1ILdLwX031136 for ; Mon, 18 Feb 2008 16:39:21 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1ILdFWV009605 for ; Mon, 18 Feb 2008 21:39:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 16:39:20 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 16:39:20 -0500 Message-ID: <47B9FB13.4010304@cisco.com> Date: Mon, 18 Feb 2008 16:39:31 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Rosenberg References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> In-Reply-To: <47B9DE39.60608@cisco.com> X-OriginalArrivalTime: 18 Feb 2008 21:39:20.0779 (UTC) FILETIME=[B88991B0:01C87276] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree that the problem exists. But in the end for any signing based on number to work there must be a tie to the legal notion of ownership of e.164 numbers. There is no getting around that. Its just a matter of whether there is *one* system for tying to ownership, or two. In this case it doesn't require that dns entries in the e164.ansi tree be populated. Rather it requires that some CAs support the legal framework for assigning certs, based on the same definitions of ownership. It isn't essential that the certs be distributed to the end users owning the numbers. A SP could act as an agent for the user in managing the cert and doing the signing. (But an end user who wants to sign his own requests should be able to get the cert.) Paul Jonathan Rosenberg wrote: > I agree that something along the lines of enum could solve this problem, > and I believe there was a draft that proposed such a thing. This has > been discussed since the start of rfc4474. > > However, I fear that saying, 'use enum' is kind of like saying, we'll > just use an All-Knowing Oracle, so lets figure out the interface > protocol to the Oracle. The easy part is the interface (the enum > mechanism). The actual hard problem is how to get those entries > populated. The deployment of public enum has been - shall we say - less > than spectacular. I'd hate for that to be our only solution. Not that > its obvious what else to do; though I do suggest in my draft how domain > based authentication, when combined with whitelists and blacklists, can > help. > > -Jonathan R. > > Paul Kyzivat wrote: >> Jonathan, >> >> I guess the time has come for this discussion, since John Ewell has >> also submitted a draft on this subject. >> >> I thought the problem was already well known, but perhaps not. IMO the >> main thing now is to figure out the *solution* to the problem! >> IMO a solution is to use a 4474-style approach, but where the >> certificate is tied to just the phone number, not to some arbitrary >> domain name. That of course would depend on a model where the "owner" >> of the phone number is the one who may obtain the certificate for that >> number. >> >> My thought is that we already have an algorithmic mapping from an >> E.164 phone number to a domain name, defined by enum. If the sender >> puts an E.164 number in From, and can sign it with a cert for the enum >> mapped domain name corresponding to that number, then that ought to be >> valid proof of the validity of the sender. >> >> In those places where public enum is in operation, I think there is >> already a legal mechanism in place to give the owner of record of a >> particular phone number control over the contents of the corresponding >> DNS entry. That should also be sufficient to allow a certificate >> authority to assign a cert to that same owner. >> >> Combine all that and you have a complete e2e identity model for phone >> numbers, based on public enum. And that can be true even if public >> enum isn't used to *route* the calls to that number. So it could be >> used for "unlisted" numbers. >> >> To use this approach the From header should contain either a TEL URI, >> or a sip/sips URI containing the enum-mapped domain name corresponding >> to the phone number. (I would rather see the TEL used for this - it is >> more user friendly.) >> >> Thanks, >> Paul >> >> Jonathan Rosenberg wrote: >>> I just submitted: >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns-00.txt >>> >>> >>> This is basically a discussion on the security properties of rfc4474 >>> with phone numbers, and a comparison to rfc3325 in this case. Also a >>> discussion on what happens to dtls-srtp. >>> >>> Comments welcome. >>> >>> -Jonathan R. >> > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:25:13 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEE43A6927; Mon, 18 Feb 2008 14:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni4Jx7vEBcxZ; Mon, 18 Feb 2008 14:25:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44493A6DC6; Mon, 18 Feb 2008 14:22:41 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163823A693B for ; Mon, 18 Feb 2008 14:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q3wmwP+Il5L for ; Mon, 18 Feb 2008 14:22:39 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 4DAA93A6D8F for ; Mon, 18 Feb 2008 14:19:48 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1IMIf60011114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2008 14:18:42 -0800 From: "Richard Shockey" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Jonathan Rosenberg'" , "'Paul Kyzivat'" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> In-Reply-To: <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> Date: Mon, 18 Feb 2008 17:17:27 -0500 Message-ID: <134a01c8727c$0d3530c0$279f9240$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchyZulElgl5PP+qQYG8DvAYAxoq4AAABmmgAAU/XSA= Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org So did you guys want a slot during the ENUM WG? > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Monday, February 18, 2008 2:55 PM > To: ext Jonathan Rosenberg; Paul Kyzivat > Cc: IETF SIP List > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > = > Hi Jonathan, > Hi Paul, > = > thanks for raising the aspect of E.164 and ENUM usage. There was an > offline discussion between Dan Wing, Klaus Darilion, Kai Fischer, > David Schwartz, Hadriel Kaplan, John Elwell, and myself about E.164 > and SIP Identity. As part of the discussion Klaus and I polished a > former document of Alexander Mayrhofer on the usage of ENUM for E.164 > numbers (see draft-mayrhofer-enum-domainkeys-00). As we moved along > with the work we obviously came across a couple of problems (as one > can easily imagine) and the document triggered a long discussion among > us. Dispite a couple of challenges, we published the document today > (see http://www.ietf.org/internet-drafts/draft-darilion-sip-e164-enum- > 00.txt). I learned a lot while working on that document. > = > In addition to publishing the document a few of us have also worked on > a document that captures some of our discussion on E.164 number > ownership. I will publish it very soon -- just a bit more proof- > reading. > = > Ciao > Hannes > = > > -----Urspr=FCngliche Nachricht----- > > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im > > Auftrag von ext Jonathan Rosenberg > > Gesendet: Montag, 18. Februar 2008 21:36 > > An: Paul Kyzivat > > Cc: IETF SIP List > > Betreff: Re: [Sip] New I-D on RFC4474 and phone numbers > > > > I agree that something along the lines of enum could solve > > this problem, > > and I believe there was a draft that proposed such a thing. This has > > been discussed since the start of rfc4474. > > > > However, I fear that saying, 'use enum' is kind of like saying, > we'll > > just use an All-Knowing Oracle, so lets figure out the interface > > protocol to the Oracle. The easy part is the interface (the enum > > mechanism). The actual hard problem is how to get those entries > > populated. The deployment of public enum has been - shall we > > say - less > > than spectacular. I'd hate for that to be our only solution. Not > that > > its obvious what else to do; though I do suggest in my draft > > how domain > > based authentication, when combined with whitelists and > > blacklists, can > > help. > > > > -Jonathan R. > > > > Paul Kyzivat wrote: > > > Jonathan, > > > > > > I guess the time has come for this discussion, since John > > Ewell has also > > > submitted a draft on this subject. > > > > > > I thought the problem was already well known, but perhaps > > not. IMO the > > > main thing now is to figure out the *solution* to the problem! > > > IMO a solution is to use a 4474-style approach, but where the > > > certificate is tied to just the phone number, not to some > arbitrary > > > domain name. That of course would depend on a model where > > the "owner" of > > > the phone number is the one who may obtain the certificate > > for that number. > > > > > > My thought is that we already have an algorithmic mapping > > from an E.164 > > > phone number to a domain name, defined by enum. If the > > sender puts an > > > E.164 number in From, and can sign it with a cert for the > > enum mapped > > > domain name corresponding to that number, then that ought > > to be valid > > > proof of the validity of the sender. > > > > > > In those places where public enum is in operation, I think there > is > > > already a legal mechanism in place to give the owner of record of > a > > > particular phone number control over the contents of the > > corresponding > > > DNS entry. That should also be sufficient to allow a certificate > > > authority to assign a cert to that same owner. > > > > > > Combine all that and you have a complete e2e identity model > > for phone > > > numbers, based on public enum. And that can be true even if > > public enum > > > isn't used to *route* the calls to that number. So it could > > be used for > > > "unlisted" numbers. > > > > > > To use this approach the From header should contain either > > a TEL URI, or > > > a sip/sips URI containing the enum-mapped domain name > > corresponding to > > > the phone number. (I would rather see the TEL used for this > > - it is more > > > user friendly.) > > > > > > Thanks, > > > Paul > > > > > > Jonathan Rosenberg wrote: > > >> I just submitted: > > >> > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc447 > > 4-concerns-00.txt > > >> > > >> > > >> This is basically a discussion on the security properties > > of rfc4474 > > >> with phone numbers, and a comparison to rfc3325 in this > > case. Also a > > >> discussion on what happens to dtls-srtp. > > >> > > >> Comments welcome. > > >> > > >> -Jonathan R. > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > > Cisco Fellow Edison, NJ 08837 > > Cisco, Voice Technology Group > > jdrosen@cisco.com > > http://www.jdrosen.net PHONE: (408) 902-3084 > > http://www.cisco.com > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:28:13 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DC928C3A8; Mon, 18 Feb 2008 14:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3QulXiFXtpv; Mon, 18 Feb 2008 14:28:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5093A6D8F; Mon, 18 Feb 2008 14:25:23 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EECFE3A6D8D for ; Mon, 18 Feb 2008 14:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUHtewhKxsiK for ; Mon, 18 Feb 2008 14:25:20 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id B8B773A6D85 for ; Mon, 18 Feb 2008 14:24:28 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1IMNJ5w015953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2008 14:23:20 -0800 From: "Richard Shockey" To: "'Jonathan Rosenberg'" , "'Paul Kyzivat'" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> In-Reply-To: <47B9DE39.60608@cisco.com> Date: Mon, 18 Feb 2008 17:22:05 -0500 Message-ID: <134b01c8727c$b2b90440$182b0cc0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchyZq+yP2uwaP9yRieGSY9bY0JaGQAE707Q Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In line > I agree that something along the lines of enum could solve this > problem, > and I believe there was a draft that proposed such a thing. This has > been discussed since the start of rfc4474. > > However, I fear that saying, 'use enum' is kind of like saying, we'll > just use an All-Knowing Oracle, so lets figure out the interface > protocol to the Oracle. Yea and lets end world hunger while we're at it ... The easy part is the interface (the enum > mechanism). The actual hard problem is how to get those entries > populated. The deployment of public enum has been - shall we say - > less than spectacular. "less than spectacular .." now there is an understatement, if there ever was one. Though private non DNS visible enum systems are going like gangbusters as TCAP/SS7 replacements all over the place. I find this entire discussion somewhat hilarious, almost side splitting, considering what some us had to go through to get A. get public ENUM defined B. then see what happened with delegations in the e164.arpa domain in the intervening 6 years or so. The very idea that there is going to be some consensus on who "owns" a phone number, much less a deployable system considering the various competing interests here is a complete fantasy. I'd hate for that to be our only solution. Not that > its obvious what else to do; though I do suggest in my draft how > domain > based authentication, when combined with whitelists and blacklists, > can > help. > > -Jonathan R. > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:28:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7B028C66E; Mon, 18 Feb 2008 14:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxHDhNoivccx; Mon, 18 Feb 2008 14:28:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8323A6DAF; Mon, 18 Feb 2008 14:26:45 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26DFB3A6937 for ; Mon, 18 Feb 2008 14:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfevhByzjklE for ; Mon, 18 Feb 2008 14:26:42 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5ED4B3A6DCB for ; Mon, 18 Feb 2008 14:24:39 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 17:24:23 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 17:24:23 -0500 From: Hadriel Kaplan To: Paul Kyzivat , Jonathan Rosenberg Date: Mon, 18 Feb 2008 17:23:15 -0500 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchydrYrLNuYuM0XQa2wutuVxC/p1QAA2p0Q Message-ID: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <47B9FB13.4010304@cisco.com> In-Reply-To: <47B9FB13.4010304@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Actually, I'm not even sure it really requires that. It is debatable if you truly own your number, and certainly debatable if CA roots would be willing to sign off on certs that are given to direct end users if the SP acts as an agent middle-man. (that basically breaks their vetting process, no?) On the other hand, if you'll allow solely for the UAC's and UAS's local providers/enterprise's to do the authentication *and* verification, and give up on the UAS being able to verify directly, then it may be more palatable and potentially succeed. For example, if you are willing to ignore DNS' lack of security (assuming there is no dnssec), then all you really need is a DNS root to get ownership domain names from for the numbers, rather than certs per number or entry. In other words let enum return the naptr identifying the owner's domain name, rather than a next-hop route resolution or certificate directly. Then just check that the 4474-provided cert matches that name. Obviously if DNS is subverted, or the DNS request intercepted or response spoofed, it breaks. But it's a lot lighter weight and manageable than putting a cert per number into the DNS. Heck, even using dnssec it would probably be lighter weight. Whether providers would be willing to put that ownership info into a public dns tree I don't know. But they might be willing to in a non-public tree only other providers could use. (since that info is essentially already available in SS7) Or even exchange that info with each other. I believe that is one possible logical outcome of Peppermint, for example. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: Monday, February 18, 2008 4:40 PM > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > I agree that the problem exists. But in the end for any signing based on > number to work there must be a tie to the legal notion of ownership of > e.164 numbers. There is no getting around that. Its just a matter of > whether there is *one* system for tying to ownership, or two. > > In this case it doesn't require that dns entries in the e164.ansi tree > be populated. Rather it requires that some CAs support the legal > framework for assigning certs, based on the same definitions of ownership. > > It isn't essential that the certs be distributed to the end users owning > the numbers. A SP could act as an agent for the user in managing the > cert and doing the signing. (But an end user who wants to sign his own > requests should be able to get the cert.) > > Paul > > Jonathan Rosenberg wrote: > > I agree that something along the lines of enum could solve this problem, > > and I believe there was a draft that proposed such a thing. This has > > been discussed since the start of rfc4474. > > > > However, I fear that saying, 'use enum' is kind of like saying, we'll > > just use an All-Knowing Oracle, so lets figure out the interface > > protocol to the Oracle. The easy part is the interface (the enum > > mechanism). The actual hard problem is how to get those entries > > populated. The deployment of public enum has been - shall we say - less > > than spectacular. I'd hate for that to be our only solution. Not that > > its obvious what else to do; though I do suggest in my draft how domain > > based authentication, when combined with whitelists and blacklists, can > > help. > > > > -Jonathan R. > > > > Paul Kyzivat wrote: > >> Jonathan, > >> > >> I guess the time has come for this discussion, since John Ewell has > >> also submitted a draft on this subject. > >> > >> I thought the problem was already well known, but perhaps not. IMO the > >> main thing now is to figure out the *solution* to the problem! > >> IMO a solution is to use a 4474-style approach, but where the > >> certificate is tied to just the phone number, not to some arbitrary > >> domain name. That of course would depend on a model where the "owner" > >> of the phone number is the one who may obtain the certificate for that > >> number. > >> > >> My thought is that we already have an algorithmic mapping from an > >> E.164 phone number to a domain name, defined by enum. If the sender > >> puts an E.164 number in From, and can sign it with a cert for the enum > >> mapped domain name corresponding to that number, then that ought to be > >> valid proof of the validity of the sender. > >> > >> In those places where public enum is in operation, I think there is > >> already a legal mechanism in place to give the owner of record of a > >> particular phone number control over the contents of the corresponding > >> DNS entry. That should also be sufficient to allow a certificate > >> authority to assign a cert to that same owner. > >> > >> Combine all that and you have a complete e2e identity model for phone > >> numbers, based on public enum. And that can be true even if public > >> enum isn't used to *route* the calls to that number. So it could be > >> used for "unlisted" numbers. > >> > >> To use this approach the From header should contain either a TEL URI, > >> or a sip/sips URI containing the enum-mapped domain name corresponding > >> to the phone number. (I would rather see the TEL used for this - it is > >> more user friendly.) > >> > >> Thanks, > >> Paul > >> > >> Jonathan Rosenberg wrote: > >>> I just submitted: > >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474- > concerns-00.txt > >>> > >>> > >>> This is basically a discussion on the security properties of rfc4474 > >>> with phone numbers, and a comparison to rfc3325 in this case. Also a > >>> discussion on what happens to dtls-srtp. > >>> > >>> Comments welcome. > >>> > >>> -Jonathan R. > >> > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:28:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E551428C647; Mon, 18 Feb 2008 14:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=-2.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynWOqEfS7rRs; Mon, 18 Feb 2008 14:28:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E5628C5A5; Mon, 18 Feb 2008 14:27:48 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C9628C3E6 for ; Mon, 18 Feb 2008 14:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMVLtoBfTfkQ for ; Mon, 18 Feb 2008 14:27:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8E1AB28C63A for ; Mon, 18 Feb 2008 14:26:36 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2008 17:26:35 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1IMQYOJ017938 for ; Mon, 18 Feb 2008 17:26:34 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IMQXWD024493 for ; Mon, 18 Feb 2008 22:26:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 17:26:33 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 17:26:33 -0500 Message-ID: <47BA0624.3060401@cisco.com> Date: Mon, 18 Feb 2008 17:26:44 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: SIP IETF References: <127f01c87277$c61615f0$524241d0$@us> In-Reply-To: <127f01c87277$c61615f0$524241d0$@us> X-OriginalArrivalTime: 18 Feb 2008 22:26:33.0434 (UTC) FILETIME=[50EE6BA0:01C8727D] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Sip] [Enum] FW: I-D Action:draft-schwartz-sip-e164-ownership-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Nice draft. One thing this highlights is that even if we solve the identity problem for E.164 numbers in sip-sip cases, the identity problem will remain for the pstn-sip case. The solutions for the sip-sip case will presumably require that somebody actually *know* the sender is the owner of the number. The GW in a pstn-sip call will in general not know that. In reality the callerid in pstn calls cannot be trusted, so a true assertion of it cannot be done with a pstn source. Yet from a practical perspective most will consider a pstn assertion of identity to be something they want to know about. That suggests to me that a weaker form of assertion is needed in that case, and that for suitably smart phones different forms of callerid presentation be used in those cases, reflecting the degree of confidence in the value being presented. Thanks, Paul _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:33:19 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED773A6DC4; Mon, 18 Feb 2008 14:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD4bbL8Yo1ez; Mon, 18 Feb 2008 14:33:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001EC3A6927; Mon, 18 Feb 2008 14:33:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428CF3A6D8A for ; Mon, 18 Feb 2008 14:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvAbwm0gihML for ; Mon, 18 Feb 2008 14:33:07 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EC59628C57C for ; Mon, 18 Feb 2008 14:30:50 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 17:30:35 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 17:30:35 -0500 From: Hadriel Kaplan To: Paul Kyzivat , "Joel M. Halpern" Date: Mon, 18 Feb 2008 17:29:30 -0500 Thread-Topic: [Sip] SIP & E.164 assertions Thread-Index: Achycl0pK6v2F2BQQAOYpwNA+mw5yAACqtsg Message-ID: References: <47B9125B.2060104@cisco.com> <47B9B294.7010700@joelhalpern.com> <47B9F385.4010804@cisco.com> In-Reply-To: <47B9F385.4010804@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: Monday, February 18, 2008 4:07 PM > > Joel M. Halpern wrote: > > Case 1 - No ;user=phone option > > In the absence of a ;user=phone option, the user part of the SIP URI > > should be considered an opaque string. It should not be considered an > > E.164 number, even if it is formatted as a telephone subscriber number. > > I can legitimately use +17035555555@joelhalpern.com as a SIP URI. And > > if the whitehouse.com deliberate confusion is still active, they could > > use +12024561414@whitehouse.com as a SIP URI. > > It is reported that some SIP devices will display the phone number > > without the domain for such URIs. That is a UI error, not a protocol > > error. The protocol can not make the UI do the right thing. > > I agree with you. But common practice is otherwise. Definitely. If the user part even smells like an e164, it's treated as one by a lot of folks. :( -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:33:24 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07A328C558; Mon, 18 Feb 2008 14:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozsMWgihRG-7; Mon, 18 Feb 2008 14:33:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246B028C50A; Mon, 18 Feb 2008 14:33:17 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C8C3A6D8A for ; Mon, 18 Feb 2008 14:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZTR6rwKSIXR for ; Mon, 18 Feb 2008 14:33:13 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 1644128C670 for ; Mon, 18 Feb 2008 14:32:09 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1IMUJUF023709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2008 14:30:21 -0800 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Frank W. Miller'" References: <20080218175250.43ED4E38024@smtpauth02.csee.onr.siteprotect.com> <47B9CE49.7080504@cisco.com> In-Reply-To: <47B9CE49.7080504@cisco.com> Date: Mon, 18 Feb 2008 17:29:06 -0500 Message-ID: <134c01c8727d$ad9ec0c0$08dc4240$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchyW/W2m7qBAo9bRMq+7qFrB+uDZQAIQbYw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'IETF SIP List' , 'Dean Willis' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Frank, > > So are you asserting that reliable callerid is not needed, or that it > is not possible? > > If its not needed, then I guess sip identity was a waste of time, as > is P-Asserted-ID. From should be good enough. > > The PSTN callerid is to a large extend based on transitive trust, and > is> reliable if the providers are careful. It breaks when providers trust > sources that they shouldn't. Apparently that is becoming an > increasingly common case. Really ??? Transitive trust seems to have worked reasonable well for the time being .what examples have you found of sources that providers thought they could trust but found they shouldn't have? > If we create a cert-based mechanism similar to 4474 that works for > phone numbers then there should be no way around it other than stealing the > certs. So it should be better than the PSTN. > > Paul > > Frank W. Miller wrote: > > > > K, got this just after my response. Inline... > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Monday, February 18, 2008 10:49 AM > > To: Frank W. Miller > > Cc: IETF SIP List > > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > > > > > On Feb 18, 2008, at 11:07 AM, Frank W. Miller wrote: > > > >> I'm a little confused by the need to "sign" phone numbers. I mean, > >> whomever > >> uses the number makes a call to or from it right? If the receiver > >> of the > >> call doesn't want to talk to whomever calls, don't they just hang > >> up? This > >> seems like a lot of extra work for little gain. > > > > How do they know who called? Can the thing being presented as > caller- > > ID be trusted? > > > > Example use case: > > > > You get a call from "Memorial Hospital" at 999-454-5678. Your child > > was apparently injured at school and is claimed to be in ICU, but > your > > signature is urgently needed before a life-saving procedure can be > > administered. You double-check by calling back 999-454-5678 and get > > the front desk at Memorial Hospital. Just to be sure, you look in > the > > phone book, and yep, that's their number. Of course, you rush to the > > hospital. > > > > FM: Call me crazy but I get weird caller-ids on my phones all the > time now, > > with the trusted PSTN. You don't think that people won't figure out > how to > > circumvent what we do if they really want to? > > > > > > While you're out, the burglar who faked the call cleans out your > house. > > > > Or even more fun: Your neighbors are having a really noisy party. > Call > > 911, faking their phone number as the source, and report a murder- > in- > > progress. Stand by and wait for the SWAT team to show up. > > > > > > FM: Any reasonable person would call the hospital back first before > rushing > > out. Besides, this same trick can be done now with Private or > Blocked in > > the PSTN. > > > > FM > > > > > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:37:33 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C0028C361; Mon, 18 Feb 2008 14:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK3lvVKUm5HX; Mon, 18 Feb 2008 14:37:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED873A693A; Mon, 18 Feb 2008 14:37:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A892D3A693A for ; Mon, 18 Feb 2008 14:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAl5Vdxyz6n6 for ; Mon, 18 Feb 2008 14:37:30 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id A652D3A68E3 for ; Mon, 18 Feb 2008 14:37:30 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1IMaf6C031750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2008 14:36:42 -0800 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Jonathan Rosenberg'" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <47B9FB13.4010304@cisco.com> In-Reply-To: <47B9FB13.4010304@cisco.com> Date: Mon, 18 Feb 2008 17:35:27 -0500 Message-ID: <134d01c8727e$908f3810$b1ada830$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchydqRnhnV9FmbFTIGmFFpRtUHYRgABwxrQ Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > I agree that the problem exists. But in the end for any signing based > on number to work there must be a tie to the legal notion of ownership of > e.164 numbers. There is no getting around that. Its just a matter of > whether there is *one* system for tying to ownership, or two. Well just as a small side bar here ... by International Treaty ...yes our friends in Geneva, no one "owns" phone numbers. The governance of E.164 phone numbers are strictly nation state matters. So anything that touches the namespace gets to be vetted by each and every country. See the IAB-ITU agreements on e164.arpa for instance. You are starting from a fallacy aka "ownership" already and fast going downhill. "Right to usage" is even more a slippery slope...been there done that. :-) > In this case it doesn't require that dns entries in the e164.ansi tree > be populated. Rather it requires that some CAs support the legal > framework for assigning certs, based on the same definitions of > ownership. > > It isn't essential that the certs be distributed to the end users > owning the numbers. A SP could act as an agent for the user in managing the > cert and doing the signing. (But an end user who wants to sign his own > requests should be able to get the cert.) _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:44:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1583828C549; Mon, 18 Feb 2008 14:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=-2.410, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOeXo6yKxoBL; Mon, 18 Feb 2008 14:44:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6844828C46E; Mon, 18 Feb 2008 14:44:33 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C97A28C46E for ; Mon, 18 Feb 2008 14:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0aREK8sjOrB for ; Mon, 18 Feb 2008 14:44:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2225D28C462 for ; Mon, 18 Feb 2008 14:44:30 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2008 17:44:28 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1IMiRwR022172; Mon, 18 Feb 2008 17:44:27 -0500 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 m1IMiNSE000637; Mon, 18 Feb 2008 22:44:27 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 17:44:23 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 17:44:23 -0500 Message-ID: <47BA0A52.7050807@cisco.com> Date: Mon, 18 Feb 2008 17:44:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <47B9FB13.4010304@cisco.com> In-Reply-To: X-OriginalArrivalTime: 18 Feb 2008 22:44:23.0463 (UTC) FILETIME=[CEB7E370:01C8727F] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org IMO its up to the owner of the UA and his SP whether the UA has the cert and does the signing, or the SP acts as an agent for the UA, holding the cert and doing the signing. While I would like it to be possible for a user to do this himself, most probably won't want to, and most providers won't want to let them. While sad, it would probably be good enough if I had to go looking for a provider that would let me manage my own cert. Similarly, on the verification side I can see how many UASs would prefer to have a SP do the hard verification and just relay the results on via a P-A-ID header. It would however be good if a UAS *could* do the verification itself - which means that the public key must be accessible to it in some way. IMO the part that gives me the most worry is if there is reluctance to *define* ownership. But I don't think I believe that is a real problem. I will bet that if somebody shows up with a warrant demanding the disclosure of the owner of some phone number, the SP will be willing and able to provide an answer, and defend it in court. I presume the real reluctance is to *disclose* the ownership to anyone who asks, for both business and legal reasons. But if its not the identity, but simply the public key or cert that is disclosed, then I would hope it would be hard to justify keeping it private. But perhaps that is just wishful thinking on my part. Paul Hadriel Kaplan wrote: > Actually, I'm not even sure it really requires that. It is debatable if you truly own your number, and certainly debatable if CA roots would be willing to sign off on certs that are given to direct end users if the SP acts as an agent middle-man. (that basically breaks their vetting process, no?) On the other hand, if you'll allow solely for the UAC's and UAS's local providers/enterprise's to do the authentication *and* verification, and give up on the UAS being able to verify directly, then it may be more palatable and potentially succeed. > > For example, if you are willing to ignore DNS' lack of security (assuming there is no dnssec), then all you really need is a DNS root to get ownership domain names from for the numbers, rather than certs per number or entry. In other words let enum return the naptr identifying the owner's domain name, rather than a next-hop route resolution or certificate directly. Then just check that the 4474-provided cert matches that name. Obviously if DNS is subverted, or the DNS request intercepted or response spoofed, it breaks. But it's a lot lighter weight and manageable than putting a cert per number into the DNS. Heck, even using dnssec it would probably be lighter weight. > > Whether providers would be willing to put that ownership info into a public dns tree I don't know. But they might be willing to in a non-public tree only other providers could use. (since that info is essentially already available in SS7) Or even exchange that info with each other. I believe that is one possible logical outcome of Peppermint, for example. > > -hadriel > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> Sent: Monday, February 18, 2008 4:40 PM >> To: Jonathan Rosenberg >> Cc: IETF SIP List >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >> >> I agree that the problem exists. But in the end for any signing based on >> number to work there must be a tie to the legal notion of ownership of >> e.164 numbers. There is no getting around that. Its just a matter of >> whether there is *one* system for tying to ownership, or two. >> >> In this case it doesn't require that dns entries in the e164.ansi tree >> be populated. Rather it requires that some CAs support the legal >> framework for assigning certs, based on the same definitions of ownership. >> >> It isn't essential that the certs be distributed to the end users owning >> the numbers. A SP could act as an agent for the user in managing the >> cert and doing the signing. (But an end user who wants to sign his own >> requests should be able to get the cert.) >> >> Paul >> >> Jonathan Rosenberg wrote: >>> I agree that something along the lines of enum could solve this problem, >>> and I believe there was a draft that proposed such a thing. This has >>> been discussed since the start of rfc4474. >>> >>> However, I fear that saying, 'use enum' is kind of like saying, we'll >>> just use an All-Knowing Oracle, so lets figure out the interface >>> protocol to the Oracle. The easy part is the interface (the enum >>> mechanism). The actual hard problem is how to get those entries >>> populated. The deployment of public enum has been - shall we say - less >>> than spectacular. I'd hate for that to be our only solution. Not that >>> its obvious what else to do; though I do suggest in my draft how domain >>> based authentication, when combined with whitelists and blacklists, can >>> help. >>> >>> -Jonathan R. >>> >>> Paul Kyzivat wrote: >>>> Jonathan, >>>> >>>> I guess the time has come for this discussion, since John Ewell has >>>> also submitted a draft on this subject. >>>> >>>> I thought the problem was already well known, but perhaps not. IMO the >>>> main thing now is to figure out the *solution* to the problem! >>>> IMO a solution is to use a 4474-style approach, but where the >>>> certificate is tied to just the phone number, not to some arbitrary >>>> domain name. That of course would depend on a model where the "owner" >>>> of the phone number is the one who may obtain the certificate for that >>>> number. >>>> >>>> My thought is that we already have an algorithmic mapping from an >>>> E.164 phone number to a domain name, defined by enum. If the sender >>>> puts an E.164 number in From, and can sign it with a cert for the enum >>>> mapped domain name corresponding to that number, then that ought to be >>>> valid proof of the validity of the sender. >>>> >>>> In those places where public enum is in operation, I think there is >>>> already a legal mechanism in place to give the owner of record of a >>>> particular phone number control over the contents of the corresponding >>>> DNS entry. That should also be sufficient to allow a certificate >>>> authority to assign a cert to that same owner. >>>> >>>> Combine all that and you have a complete e2e identity model for phone >>>> numbers, based on public enum. And that can be true even if public >>>> enum isn't used to *route* the calls to that number. So it could be >>>> used for "unlisted" numbers. >>>> >>>> To use this approach the From header should contain either a TEL URI, >>>> or a sip/sips URI containing the enum-mapped domain name corresponding >>>> to the phone number. (I would rather see the TEL used for this - it is >>>> more user friendly.) >>>> >>>> Thanks, >>>> Paul >>>> >>>> Jonathan Rosenberg wrote: >>>>> I just submitted: >>>>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474- >> concerns-00.txt >>>>> >>>>> This is basically a discussion on the security properties of rfc4474 >>>>> with phone numbers, and a comparison to rfc3325 in this case. Also a >>>>> discussion on what happens to dtls-srtp. >>>>> >>>>> Comments welcome. >>>>> >>>>> -Jonathan R. >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:47:08 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D112B3A6DA5; Mon, 18 Feb 2008 14:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.841 X-Spam-Level: X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=-2.404, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jtomZPAUPLx; Mon, 18 Feb 2008 14:47:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76C63A6D96; Mon, 18 Feb 2008 14:46:58 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC9C3A6DF0 for ; Mon, 18 Feb 2008 14:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMkkSy8Yqw6B for ; Mon, 18 Feb 2008 14:46:51 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 453533A6DD1 for ; Mon, 18 Feb 2008 14:46:35 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2008 17:46:34 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1IMkWq8022932; Mon, 18 Feb 2008 17:46:32 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IMkMWH001109; Mon, 18 Feb 2008 22:46:32 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 17:46:27 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 17:46:27 -0500 Message-ID: <47BA0ACE.2020408@cisco.com> Date: Mon, 18 Feb 2008 17:46:38 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Richard Shockey References: <20080218175250.43ED4E38024@smtpauth02.csee.onr.siteprotect.com> <47B9CE49.7080504@cisco.com> <134c01c8727d$ad9ec0c0$08dc4240$@us> In-Reply-To: <134c01c8727d$ad9ec0c0$08dc4240$@us> X-OriginalArrivalTime: 18 Feb 2008 22:46:27.0346 (UTC) FILETIME=[188EEF20:01C87280] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'IETF SIP List' , "'Frank W. Miller'" , 'Dean Willis' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Richard Shockey wrote: >> Frank, >> >> So are you asserting that reliable callerid is not needed, or that it >> is not possible? >> >> If its not needed, then I guess sip identity was a waste of time, as >> is P-Asserted-ID. From should be good enough. >> >> The PSTN callerid is to a large extend based on transitive trust, and >> is> reliable if the providers are careful. It breaks when providers > trust >> sources that they shouldn't. Apparently that is becoming an >> increasingly common case. > > Really ??? Transitive trust seems to have worked reasonable well for the > time being .what examples have you found of sources that providers thought > they could trust but found they shouldn't have? All the cases of callerid spoofing. Paul >> If we create a cert-based mechanism similar to 4474 that works for >> phone numbers then there should be no way around it other than stealing > the >> certs. So it should be better than the PSTN. > > > > > >> >> Paul >> >> Frank W. Miller wrote: >> > >> > K, got this just after my response. Inline... >> > >> > -----Original Message----- >> > From: Dean Willis [mailto:dean.willis@softarmor.com] >> > Sent: Monday, February 18, 2008 10:49 AM >> > To: Frank W. Miller >> > Cc: IETF SIP List >> > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >> > >> > >> > On Feb 18, 2008, at 11:07 AM, Frank W. Miller wrote: >> > >> >> I'm a little confused by the need to "sign" phone numbers. I mean, >> >> whomever >> >> uses the number makes a call to or from it right? If the receiver >> >> of the >> >> call doesn't want to talk to whomever calls, don't they just hang >> >> up? This >> >> seems like a lot of extra work for little gain. >> > >> > How do they know who called? Can the thing being presented as >> caller- >> > ID be trusted? >> > >> > Example use case: >> > >> > You get a call from "Memorial Hospital" at 999-454-5678. Your child >> > was apparently injured at school and is claimed to be in ICU, but >> your >> > signature is urgently needed before a life-saving procedure can be >> > administered. You double-check by calling back 999-454-5678 and get >> > the front desk at Memorial Hospital. Just to be sure, you look in >> the >> > phone book, and yep, that's their number. Of course, you rush to the >> > hospital. >> > >> > FM: Call me crazy but I get weird caller-ids on my phones all the >> time now, >> > with the trusted PSTN. You don't think that people won't figure out >> how to >> > circumvent what we do if they really want to? >> > >> > >> > While you're out, the burglar who faked the call cleans out your >> house. >> > >> > Or even more fun: Your neighbors are having a really noisy party. >> Call >> > 911, faking their phone number as the source, and report a murder- >> in- >> > progress. Stand by and wait for the SWAT team to show up. >> > >> > >> > FM: Any reasonable person would call the hospital back first before >> rushing >> > out. Besides, this same trick can be done now with Private or >> Blocked in >> > the PSTN. >> > >> > FM >> > >> > >> > >> > >> > _______________________________________________ >> > Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:47:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583C33A6DAC; Mon, 18 Feb 2008 14:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq46BwHUwsQt; Mon, 18 Feb 2008 14:47:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC9C3A6DDC; Mon, 18 Feb 2008 14:47:27 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E273A6821 for ; Mon, 18 Feb 2008 14:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN3laHDjKM+R for ; Mon, 18 Feb 2008 14:47:24 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2C2F23A6D86 for ; Mon, 18 Feb 2008 14:47:24 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 17:47:08 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 17:47:08 -0500 From: Hadriel Kaplan To: Richard Shockey , 'Jonathan Rosenberg' , 'Paul Kyzivat' Date: Mon, 18 Feb 2008 17:47:08 -0500 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyZq+yP2uwaP9yRieGSY9bY0JaGQAE707QAADoq/A= Message-ID: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> In-Reply-To: <134b01c8727c$b2b90440$182b0cc0$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In your experience would there be a quorum of incumbent providers who would be willing to publish their numbers in an infrastructure enum, available only to other "club members"? Such a thing is essentially the logical conclusion of Peppermint, isn't it? Just in a distributed form. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Richard Shockey > Sent: Monday, February 18, 2008 5:22 PM > To: 'Jonathan Rosenberg'; 'Paul Kyzivat' > Cc: 'IETF SIP List' > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > In line > > > I agree that something along the lines of enum could solve this > > problem, > > and I believe there was a draft that proposed such a thing. This has > > been discussed since the start of rfc4474. > > > > However, I fear that saying, 'use enum' is kind of like saying, we'll > > just use an All-Knowing Oracle, so lets figure out the interface > > protocol to the Oracle. > > Yea and lets end world hunger while we're at it ... > > > The easy part is the interface (the enum > > mechanism). The actual hard problem is how to get those entries > > populated. The deployment of public enum has been - shall we say - > > less than spectacular. > > "less than spectacular .." now there is an understatement, if there ever > was > one. Though private non DNS visible enum systems are going like > gangbusters > as TCAP/SS7 replacements all over the place. > > I find this entire discussion somewhat hilarious, almost side splitting, > considering what some us had to go through to get A. get public ENUM > defined > B. then see what happened with delegations in the e164.arpa domain in the > intervening 6 years or so. > > The very idea that there is going to be some consensus on who "owns" a > phone > number, much less a deployable system considering the various competing > interests here is a complete fantasy. > > > > I'd hate for that to be our only solution. Not that > > its obvious what else to do; though I do suggest in my draft how > > domain > > based authentication, when combined with whitelists and blacklists, > > can > > help. > > > > -Jonathan R. > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 14:55:12 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5A428C4B5; Mon, 18 Feb 2008 14:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=-2.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZtMbXpvMP9r; Mon, 18 Feb 2008 14:55:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE2F3A686E; Mon, 18 Feb 2008 14:55:10 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87C83A686E for ; Mon, 18 Feb 2008 14:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGnDtX61J7ec for ; Mon, 18 Feb 2008 14:55:07 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7A6773A697A for ; Mon, 18 Feb 2008 14:54:43 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2008 14:54:41 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1IMsf42001528; Mon, 18 Feb 2008 14:54:41 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m1IMsPNi011764; Mon, 18 Feb 2008 22:54:41 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 17:54:34 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 17:54:34 -0500 Message-ID: <47BA0CB5.7020109@cisco.com> Date: Mon, 18 Feb 2008 17:54:45 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Richard Shockey References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <47B9FB13.4010304@cisco.com> <134d01c8727e$908f3810$b1ada830$@us> In-Reply-To: <134d01c8727e$908f3810$b1ada830$@us> X-OriginalArrivalTime: 18 Feb 2008 22:54:34.0162 (UTC) FILETIME=[3AB92920:01C87281] Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Richard Shockey wrote: >> I agree that the problem exists. But in the end for any signing based >> on number to work there must be a tie to the legal notion of ownership of >> e.164 numbers. There is no getting around that. Its just a matter of >> whether there is *one* system for tying to ownership, or two. > > Well just as a small side bar here ... by International Treaty ...yes our > friends in Geneva, no one "owns" phone numbers. The governance of E.164 > phone numbers are strictly nation state matters. So anything that touches > the namespace gets to be vetted by each and every country. See the IAB-ITU > agreements on e164.arpa for instance. > > You are starting from a fallacy aka "ownership" already and fast going > downhill. "Right to usage" is even more a slippery slope...been there done > that. :-) I haven't been involved in the space like you have. I realize that "ownership" iss probably too strong a word. Pick whatever word you like. Some entity is entitled to have a phone associated with a particular number, and other entities are not entitled to have phones associated with that same number. Whatever you want to call that is ok with me. When the feds show up with the warrant, what does the SP tell them? That is what defines it. In those places where public enum is supported, some entity is entitled to give instructions on how it shall be populated for a given number. What do you call that entity? Thanks, Paul >> In this case it doesn't require that dns entries in the e164.ansi tree >> be populated. Rather it requires that some CAs support the legal >> framework for assigning certs, based on the same definitions of >> ownership. >> >> It isn't essential that the certs be distributed to the end users >> owning the numbers. A SP could act as an agent for the user in managing > the >> cert and doing the signing. (But an end user who wants to sign his own >> requests should be able to get the cert.) > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 15:27:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000A928C32B; Mon, 18 Feb 2008 15:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-1.239, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-nfRVoHNlGe; Mon, 18 Feb 2008 15:27:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71C03A6897; Mon, 18 Feb 2008 15:27:49 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9298B3A6785 for ; Mon, 18 Feb 2008 15:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0Td8rjQUnd4 for ; Mon, 18 Feb 2008 15:27:47 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by core3.amsl.com (Postfix) with ESMTP id D052A3A68F4 for ; Mon, 18 Feb 2008 15:27:43 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP; Mon, 18 Feb 2008 15:27:40 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m1INP4in000966; Mon, 18 Feb 2008 15:25:04 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m1INRSRM022943; Mon, 18 Feb 2008 15:27:39 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 08:27:35 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 15:27:32 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22019E0762@namail5.corp.adobe.com> In-Reply-To: <20080218161943.DB8531C8065@smtpauth01.csee.onr.siteprotect.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyPaUwZNySpUlPSZ2WJ432wEU9pAADJbXAAAGO2yAADIKDIA== References: <24CCCC428EFEA2469BF046DB3C7A8D22019E0755@namail5.corp.adobe.com> <20080218161943.DB8531C8065@smtpauth01.csee.onr.siteprotect.com> From: "Henry Sinnreich" To: "Frank W. Miller" , "Paul Kyzivat" , "Shockey, Richard" X-OriginalArrivalTime: 18 Feb 2008 23:27:35.0894 (UTC) FILETIME=[D7ED7760:01C87285] Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > If the receiver of the call doesn't want to talk to whomever calls, > don't they just hang up? It takes far more time to listen than deleting an email and is far more annoying than email spam. IMO the efforts proposed here are fully justified, though it will not be easy to accomplish. One of the main reasons for giving up PSTN service may be to just get relief from telemarketing calls. Henry -----Original Message----- From: Frank W. Miller [mailto:fwmiller@cornfed.com] Sent: Monday, February 18, 2008 11:08 AM To: Henry Sinnreich; 'Paul Kyzivat'; 'Shockey, Richard' Cc: 'IETF SIP List' Subject: RE: [Sip] New I-D on RFC4474 and phone numbers I'm a little confused by the need to "sign" phone numbers. I mean, whomever uses the number makes a call to or from it right? If the receiver of the call doesn't want to talk to whomever calls, don't they just hang up? This seems like a lot of extra work for little gain. Thanks, FM -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Monday, February 18, 2008 9:26 AM To: Paul Kyzivat; Shockey, Richard Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers Paul, >My thought is that we already have an algorithmic mapping from an E.164 >phone number to a domain name, defined by enum. If the sender puts an >E.164 number in From, and can sign it with a cert for the enum mapped >domain name corresponding to that number, then that ought to be valid >proof of the validity of the sender. This seems indeed to be cutting the Gordian Knot! (http://en.wikipedia.org/wiki/Gordian_Knot) Should this not be a joint I-D with the ENUM WG, or have at least have some coordination? The exact mechanism to do this is certainly of interest to the ENUM folks. Henry -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, February 18, 2008 8:51 AM To: Jonathan Rosenberg Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers Jonathan, I guess the time has come for this discussion, since John Ewell has also submitted a draft on this subject. I thought the problem was already well known, but perhaps not. IMO the main thing now is to figure out the *solution* to the problem! IMO a solution is to use a 4474-style approach, but where the certificate is tied to just the phone number, not to some arbitrary domain name. That of course would depend on a model where the "owner" of the phone number is the one who may obtain the certificate for that number. My thought is that we already have an algorithmic mapping from an E.164 phone number to a domain name, defined by enum. If the sender puts an E.164 number in From, and can sign it with a cert for the enum mapped domain name corresponding to that number, then that ought to be valid proof of the validity of the sender. In those places where public enum is in operation, I think there is already a legal mechanism in place to give the owner of record of a particular phone number control over the contents of the corresponding DNS entry. That should also be sufficient to allow a certificate authority to assign a cert to that same owner. Combine all that and you have a complete e2e identity model for phone numbers, based on public enum. And that can be true even if public enum isn't used to *route* the calls to that number. So it could be used for "unlisted" numbers. To use this approach the From header should contain either a TEL URI, or a sip/sips URI containing the enum-mapped domain name corresponding to the phone number. (I would rather see the TEL used for this - it is more user friendly.) Thanks, Paul Jonathan Rosenberg wrote: > I just submitted: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns -00.txt > > This is basically a discussion on the security properties of rfc4474 > with phone numbers, and a comparison to rfc3325 in this case. Also a > discussion on what happens to dtls-srtp. > > Comments welcome. > > -Jonathan R. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 16:16:15 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140D128C2E5; Mon, 18 Feb 2008 16:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.975 X-Spam-Level: X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8olJqySxvDT; Mon, 18 Feb 2008 16:16:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8353A6890; Mon, 18 Feb 2008 16:16:13 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560813A69D7 for ; Mon, 18 Feb 2008 16:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-8fs0IWQFvm for ; Mon, 18 Feb 2008 16:16:11 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 8B1EC3A6833 for ; Mon, 18 Feb 2008 16:16:11 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1J0F0is021747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2008 16:15:06 -0800 From: "Richard Shockey" To: "'Paul Kyzivat'" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <47B9FB13.4010304@cisco.com> <134d01c8727e$908f3810$b1ada830$@us> <47BA0CB5.7020109@cisco.com> In-Reply-To: <47BA0CB5.7020109@cisco.com> Date: Mon, 18 Feb 2008 19:13:43 -0500 Message-ID: <148501c8728c$5038b260$f0aa1720$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchygSgm5GcamXb0ToOX/L57fDZNZAABcyfA Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > >> whether there is *one* system for tying to ownership, or two. > > > > Well just as a small side bar here ... by International Treaty > ...yes our > > friends in Geneva, no one "owns" phone numbers. The governance of > E.164 > > phone numbers are strictly nation state matters. So anything that > touches > > the namespace gets to be vetted by each and every country. See the > IAB-ITU > > agreements on e164.arpa for instance. > > > > You are starting from a fallacy aka "ownership" already and fast > going > > downhill. "Right to usage" is even more a slippery slope...been > there done > > that. :-) > > I haven't been involved in the space like you have. I realize that > "ownership" iss probably too strong a word. Pick whatever word you > like. > Some entity is entitled to have a phone associated with a particular > number, and other entities are not entitled to have phones associated > with that same number. Whatever you want to call that is ok with me. That is the problem .. first you have the service provider of record that actually issued the number under the authority of a nation state then the entity that actually uses that number (consumer or enterprise) all of this is complicated by the issue of Local Number Portability, of course and lastly the fact that the number could be used by multiple applications, delivered by different application service providers etc. > > When the feds show up with the warrant, what does the SP tell them? > That is what defines it. Ah if it were only that simple :-) Well that's when you get into the real fun of the fact that numbers could be issued by a wholesale service provider to a downstream application provider so the carrier of record in many nation states is not the entity providing the service ..aka Vonage and Level3 for instance. This is a problem that is vexing our friends in the LEA's even as we speak. The numbering databases do not completely reflect the reality of service deployments. > > In those places where public enum is supported, some entity is > entitled > to give instructions on how it shall be populated for a given number. > What do you call that entity? > > Thanks, > Paul > > >> In this case it doesn't require that dns entries in the e164.ansi > tree > >> be populated. Rather it requires that some CAs support the legal > >> framework for assigning certs, based on the same definitions of > >> ownership. > >> > >> It isn't essential that the certs be distributed to the end users > >> owning the numbers. A SP could act as an agent for the user in > managing > > the > >> cert and doing the signing. (But an end user who wants to sign his > own > >> requests should be able to get the cert.) > > > > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 16:21:42 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB743A6DBC; Mon, 18 Feb 2008 16:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn3dPTQD0Ozd; Mon, 18 Feb 2008 16:21:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEFF3A6890; Mon, 18 Feb 2008 16:21:41 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956193A6881 for ; Mon, 18 Feb 2008 16:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhwVvcFIenJ3 for ; Mon, 18 Feb 2008 16:21:38 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id ADC403A6833 for ; Mon, 18 Feb 2008 16:21:38 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1J0KYIK026877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2008 16:20:36 -0800 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Jonathan Rosenberg'" , "'Paul Kyzivat'" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> In-Reply-To: Date: Mon, 18 Feb 2008 19:19:17 -0500 Message-ID: <148601c8728d$14002c50$3c0084f0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchyZq+yP2uwaP9yRieGSY9bY0JaGQAE707QAADoq/AAAeTgMA== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > In your experience would there be a quorum of incumbent providers who > would be willing to publish their numbers in an infrastructure enum, > available only to other "club members"? Such a thing is essentially > the logical conclusion of Peppermint, isn't it? Just in a distributed > form. > > -hadriel Short answer NO but that is IMHO. Not in a global DNS tree, it's too fraught with real politics and I mean REAL politics. It not entirely clear the pain threshold has been reached on the overriding identity problem you all are addressing and yes the ITU is definitely looking at the issue. PEPPERMINT is not about the provisioning of public, infrastructure (carrier of record) or private ENUM trees. It could easily encompass bilateral or multilateral arrangements or PBX to SP data exchanges. PEPPERMINT does not presume any business model for the exchange of data ( which certainly could include a cert tree ) only a standard methodology for the exchange of data itself. And yes you all are welcome to come to the 2nd PEPPERMINT BOF, alas beer will not be served. > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf > Of > > Richard Shockey > > Sent: Monday, February 18, 2008 5:22 PM > > To: 'Jonathan Rosenberg'; 'Paul Kyzivat' > > Cc: 'IETF SIP List' > > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > > > In line > > > > > I agree that something along the lines of enum could solve this > > > problem, > > > and I believe there was a draft that proposed such a thing. This > has > > > been discussed since the start of rfc4474. > > > > > > However, I fear that saying, 'use enum' is kind of like saying, > we'll > > > just use an All-Knowing Oracle, so lets figure out the interface > > > protocol to the Oracle. > > > > Yea and lets end world hunger while we're at it ... > > > > > > The easy part is the interface (the enum > > > mechanism). The actual hard problem is how to get those entries > > > populated. The deployment of public enum has been - shall we say > - > > > less than spectacular. > > > > "less than spectacular .." now there is an understatement, if there > ever > > was > > one. Though private non DNS visible enum systems are going like > > gangbusters > > as TCAP/SS7 replacements all over the place. > > > > I find this entire discussion somewhat hilarious, almost side > splitting, > > considering what some us had to go through to get A. get public ENUM > > defined > > B. then see what happened with delegations in the e164.arpa domain > in the > > intervening 6 years or so. > > > > The very idea that there is going to be some consensus on who "owns" > a > > phone > > number, much less a deployable system considering the various > competing > > interests here is a complete fantasy. > > > > > > > > I'd hate for that to be our only solution. Not that > > > its obvious what else to do; though I do suggest in my draft how > > > domain > > > based authentication, when combined with whitelists and > blacklists, > > > can > > > help. > > > > > > -Jonathan R. > > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 18:34:00 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3F028C312; Mon, 18 Feb 2008 18:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn6tftB9uauA; Mon, 18 Feb 2008 18:33:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77A1A3A6803; Mon, 18 Feb 2008 18:33:59 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FBE3A6803 for ; Mon, 18 Feb 2008 18:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbKu4fI2EzD8 for ; Mon, 18 Feb 2008 18:33:57 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 8893E3A67A1 for ; Mon, 18 Feb 2008 18:33:56 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA05.westchester.pa.mail.comcast.net with comcast id rDTW1Y00S0cZkys5504600; Tue, 19 Feb 2008 02:33:27 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA10.westchester.pa.mail.comcast.net with comcast id rEZt1Y0040umElk3W00000; Tue, 19 Feb 2008 02:33:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=1pTY7SXa-7wSGj7xv5QA:9 a=GiidYerUAZIa9QclvVDZaqy6F_AA:4 a=HwvHyInW8OUA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m1J2XrMj021645 for ; Mon, 18 Feb 2008 21:33:53 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m1J2XqcV021641; Mon, 18 Feb 2008 21:33:52 -0500 Date: Mon, 18 Feb 2008 21:33:52 -0500 Message-Id: <200802190233.m1J2XqcV021641@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (HKaplan@acmepacket.com) References: <20080218174533.23DEC1C8043@smtpauth01.csee.onr.siteprotect.com> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Hadriel Kaplan Yes, there is no debate that cost/expense and closed networks have kept phone calls from being hammered like email. Unfortunately/fortunately, that cost is dropping. This topic isn't about today - it's about 5-20+ years from now. Of course, the entire economic driver of SIP adoption is the hope of reducing the cost of phone calls ... to the point that SPIT would be easy and inexpensive! Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 18:47:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543783A6E73; Mon, 18 Feb 2008 18:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haGz3336+McA; Mon, 18 Feb 2008 18:47:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB28B3A6DFE; Mon, 18 Feb 2008 18:45:11 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 057B43A6DF6; Mon, 18 Feb 2008 18:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080219024502.057B43A6DF6@core3.amsl.com> Date: Mon, 18 Feb 2008 18:45:02 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-ua-privacy-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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 : UA-Driven Privacy Mechanism for SIP Author(s) : M. Munakata, et al. Filename : draft-ietf-sip-ua-privacy-01.txt Pages : 10 Date : 2008-02-18 To withhold a user's identity and related information, RFC 3323 defines a Privacy mechanism for SIP, which requires the use of an privacy service. This document proposes a new privacy mechanism that a user agent can facilitate to conceal privacy-sensitive information without the need for aid from a privacy service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-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-ua-privacy-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-ua-privacy-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: <2008-02-18183650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-ua-privacy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-ua-privacy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-18183650.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Feb 18 18:53:16 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927263A6D81; Mon, 18 Feb 2008 18:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id strg0zP9rkxo; Mon, 18 Feb 2008 18:53:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A9C3A69ED; Mon, 18 Feb 2008 18:53:15 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0283A69ED for ; Mon, 18 Feb 2008 18:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEbFh30cH9NC for ; Mon, 18 Feb 2008 18:53:14 -0800 (PST) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id E5C023A6890 for ; Mon, 18 Feb 2008 18:53:13 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA06.westchester.pa.mail.comcast.net with comcast id rDRt1Y0080cZkys5606o00; Tue, 19 Feb 2008 02:52:49 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA10.westchester.pa.mail.comcast.net with comcast id rEtA1Y00D0umElk3W00000; Tue, 19 Feb 2008 02:53:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=lemdlZ8-B9nUmePoQBIA:9 a=JLD4SP93sFVbJd-PsuAA:7 a=wkk7Y0mavNIHzVuONicMPKR4PboA:4 a=chC_agHSu74A:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m1J2rAMj021901 for ; Mon, 18 Feb 2008 21:53:10 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m1J2rAK8021897; Mon, 18 Feb 2008 21:53:10 -0500 Date: Mon, 18 Feb 2008 21:53:10 -0500 Message-Id: <200802190253.m1J2rAK8021897@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <47B9B294.7010700@joelhalpern.com> (jmh@joelhalpern.com) References: <47B9125B.2060104@cisco.com> <47B9B294.7010700@joelhalpern.com> Subject: Re: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Joel M. Halpern" The pair of questions is: When should the user part of a SIP URI be considered an E.164 number? And what assertion is being made by such consideration? I would start by saying "the user part is never an E.164 number, unless a particular domain uses it that way (and you have to route the call to that domain for it to make that determination)". I appear to be wrong, since RFC 3261 gives examples of SIP URIs with user=phone and phone-context URI parameters. But the best information I can find is RFC 2848, and it appears that that RFC is about identifying the user-part as a *dial string* to be interpreted within the context of the dial plan at the specified SIP proxy. Where is the normative description of when SIP user-parts are to be interpreted as "phone numbers"? Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 19:05:26 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42E23A6DA8; Mon, 18 Feb 2008 19:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id win7EXheeGHD; Mon, 18 Feb 2008 19:05:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59EC3A6826; Mon, 18 Feb 2008 19:05:25 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4956E3A6890 for ; Mon, 18 Feb 2008 19:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hNYHCGVdMBB for ; Mon, 18 Feb 2008 19:05:23 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 877183A6826 for ; Mon, 18 Feb 2008 19:05:23 -0800 (PST) Received: from [10.0.1.192] (adsl-68-94-53-35.dsl.rcsntx.swbell.net [68.94.53.35]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1J35BWL030315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2008 21:05:13 -0600 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <47B9EF77.8090201@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 18 Feb 2008 21:05:11 -0600 References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9EF77.8090201@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 18, 2008, at 2:49 PM, Paul Kyzivat wrote: > > If this new scheme can be related to e.164 numbers then maybe it can > apply as well. One thing I don't understand is how it would tie to a > legal definition of ownership of the numbers. That's on a different level of Dean;s 7-Layer Model -- the Political. The simplest approach is that a top-level authority (say, ITU) operate a top-level PKG that then provides private keys to the national authorities, who then act as PKGs for lower-level delegations, and on down to the individual phone number. So, if you're in possession of a private key for your phone number, from the PKG that's authoritative for your phone number (according to whichever definition of that authority we adopt), you are in possession of the identity indicated by that phone number. Not all that different from enum, just a different algorithm for the key management and crypto. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 19:13:43 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DB53A6DC1; Mon, 18 Feb 2008 19:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.473 X-Spam-Level: X-Spam-Status: No, score=-0.473 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3SSQ3BH-rYH; Mon, 18 Feb 2008 19:13:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1892C3A6D91; Mon, 18 Feb 2008 19:13:42 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8473A694E for ; Mon, 18 Feb 2008 19:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5In7F83mPXR4 for ; Mon, 18 Feb 2008 19:13:40 -0800 (PST) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id 8E5473A6890 for ; Mon, 18 Feb 2008 19:13:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 7B42E7DE6; Mon, 18 Feb 2008 19:13:38 -0800 (PST) Received: from [192.168.0.100] (pool-71-161-50-169.clppva.east.verizon.net [71.161.50.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 6686F7DE4; Mon, 18 Feb 2008 19:13:36 -0800 (PST) Message-ID: <47BA495C.5000204@joelhalpern.com> Date: Mon, 18 Feb 2008 22:13:32 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan References: <47B9125B.2060104@cisco.com> <47B9B294.7010700@joelhalpern.com> <47B9F385.4010804@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.6 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net Cc: IETF SIP List , Paul Kyzivat Subject: Re: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org That, treating anything that smells like an E.164 like an E.164, may well be common practice. But it seems to me a) it is a practice which is inherently misleading and error prone b) it is a practice we can not sensibly design for / around. c) It is not the working group's problem to repair security flaws introduced by such behavior. It is the vendor's problem. Yours, Joel M. Halpern Hadriel Kaplan wrote: >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> Sent: Monday, February 18, 2008 4:07 PM >> >> Joel M. Halpern wrote: >>> Case 1 - No ;user=phone option >>> In the absence of a ;user=phone option, the user part of the SIP URI >>> should be considered an opaque string. It should not be considered an >>> E.164 number, even if it is formatted as a telephone subscriber number. >>> I can legitimately use +17035555555@joelhalpern.com as a SIP URI. And >>> if the whitehouse.com deliberate confusion is still active, they could >>> use +12024561414@whitehouse.com as a SIP URI. >>> It is reported that some SIP devices will display the phone number >>> without the domain for such URIs. That is a UI error, not a protocol >>> error. The protocol can not make the UI do the right thing. >> I agree with you. But common practice is otherwise. > > Definitely. If the user part even smells like an e164, it's treated as one by a lot of folks. :( > > -hadriel > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 19:58:29 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A423A67A3; Mon, 18 Feb 2008 19:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.136 X-Spam-Level: X-Spam-Status: No, score=-0.136 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd4EyL2Ovq+C; Mon, 18 Feb 2008 19:58:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B283A697C; Mon, 18 Feb 2008 19:58:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CCDC3A697C for ; Mon, 18 Feb 2008 19:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHlxLwGEIs0j for ; Mon, 18 Feb 2008 19:58:26 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AEAB93A67A3 for ; Mon, 18 Feb 2008 19:58:26 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 22:58:10 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 22:58:02 -0500 From: Hadriel Kaplan To: "Joel M. Halpern" Date: Mon, 18 Feb 2008 22:54:23 -0500 Thread-Topic: [Sip] SIP & E.164 assertions Thread-Index: AchypWVn6x6BdABGRH6H40s3oxSjywAAkxyQ Message-ID: References: <47B9125B.2060104@cisco.com> <47B9B294.7010700@joelhalpern.com> <47B9F385.4010804@cisco.com> <47BA495C.5000204@joelhalpern.com> In-Reply-To: <47BA495C.5000204@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List , Paul Kyzivat Subject: Re: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org What you say sound like the arguments against dealing with consumer NATs. :) Inline... > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, February 18, 2008 10:14 PM > To: Hadriel Kaplan > Cc: Paul Kyzivat; IETF SIP List > Subject: Re: [Sip] SIP & E.164 assertions > > That, treating anything that smells like an E.164 like an E.164, may > well be common practice. > But it seems to me > a) it is a practice which is inherently misleading and error prone It works right now, because virtually all sip communication is E.164's, if the userpart is digits at all (and long enough, and following certain patterns). In fact, I'd argue it works *better* than not doing it, for that reason. Most of the time, maybe virtually ALL of the time, when there is no user=phone param, it's because a device screwed up not putting it there. So you've got the incumbent/deployed boxes doing something that works. If it ain't broke, no one is going to fix it. Especially if fixing it breaks something already deployed. (BTW, I'm talking about provider side - I don't know if this holds true in Enterprise SIP at all, given their funky dial plans, but my guess is for them it's a pattern match or external dial prefix match) > b) it is a practice we can not sensibly design for / around. I'm not sure we need to. I didn't catch what the "problem" with this is with regard to E.164 assertions? I mean let's pretend all of them have user=phone, and look just like a TEL username should or whatever. What does that solve in terms of e164 identity? > c) It is not the working group's problem to repair security flaws > introduced by such behavior. It is the vendor's problem. And what exactly is the security flaw introduced? You're not telling me that a user=phone parameter is somehow a security mechanism? Is it like the evil bit or something? ;) -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 20:12:31 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523283A6DDC; Mon, 18 Feb 2008 20:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbCDa4KU31qM; Mon, 18 Feb 2008 20:12:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D253A690E; Mon, 18 Feb 2008 20:12:30 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CA83A690E for ; Mon, 18 Feb 2008 20:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gBaNi6-OaXz for ; Mon, 18 Feb 2008 20:12:28 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9F7963A6C9F for ; Mon, 18 Feb 2008 20:12:28 -0800 (PST) Received: from [10.0.1.192] (adsl-68-94-53-35.dsl.rcsntx.swbell.net [68.94.53.35]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1J4CNQS030779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2008 22:12:24 -0600 Message-Id: From: Dean Willis To: Richard Shockey In-Reply-To: <134b01c8727c$b2b90440$182b0cc0$@us> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 18 Feb 2008 22:12:22 -0600 References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> X-Mailer: Apple Mail (2.919.2) Cc: 'IETF SIP List' , 'Paul Kyzivat' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 18, 2008, at 4:22 PM, Richard Shockey wrote: > > The very idea that there is going to be some consensus on who "owns" > a phone > number, much less a deployable system considering the various > competing > interests here is a complete fantasy. > Counterargument: If I call phone number X, and the responding party can complete a media-path handshake against the published key for that number, then I'd claim they "own" it. Possession is, after all, 9/10ths of the law. In other words, to heck with the government -- who answers the phone? -- dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 20:12:42 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6DC728C3D5; Mon, 18 Feb 2008 20:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHpBIYEy8pAy; Mon, 18 Feb 2008 20:12:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A153D28C35E; Mon, 18 Feb 2008 20:12:41 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20B428C356 for ; Mon, 18 Feb 2008 20:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCsda2e+j72V for ; Mon, 18 Feb 2008 20:12:40 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D9D1B28C2E2 for ; Mon, 18 Feb 2008 20:12:38 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 23:12:23 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 18 Feb 2008 23:12:22 -0500 From: Hadriel Kaplan To: Richard Shockey , 'Jonathan Rosenberg' , 'Paul Kyzivat' Date: Mon, 18 Feb 2008 23:08:59 -0500 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyZq+yP2uwaP9yRieGSY9bY0JaGQAE707QAADoq/AAAeTgMAAJZAow Message-ID: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <148601c8728d$14002c50$3c0084f0$@us> In-Reply-To: <148601c8728d$14002c50$3c0084f0$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'IETF SIP List' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Monday, February 18, 2008 7:19 PM > To: Hadriel Kaplan; 'Jonathan Rosenberg'; 'Paul Kyzivat' > Cc: 'IETF SIP List' > Subject: RE: [Sip] New I-D on RFC4474 and phone numbers > > > > In your experience would there be a quorum of incumbent providers who > > would be willing to publish their numbers in an infrastructure enum, > > available only to other "club members"? Such a thing is essentially > > the logical conclusion of Peppermint, isn't it? Just in a distributed > > form. > > > > -hadriel > > Short answer NO but that is IMHO. Not in a global DNS tree, it's too > fraught > with real politics and I mean REAL politics. I agree with you there. I'm thinking something slightly less global, like local in fact. > PEPPERMINT is not about the provisioning of public, infrastructure > (carrier > of record) or private ENUM trees. It could easily encompass bilateral or > multilateral arrangements or PBX to SP data exchanges. That's not how I meant it. I meant, as it appears from the ESPP proposal, the idea is to exchange prefix and possibly unique number data reachability data. It is not clear if it would encompass ported numbers too, or not. Regardless, ESPP can't actually handle transit cases as written, but one possible outcome is that such data exchanged could let the providers learn the terminating provider domain, and thus if a call comes from it, what should have signed it. (sort of like uRPF in IP routing) Doesn't matter anyway for now, just fantasizing. :) > And yes you all are welcome to come to the 2nd PEPPERMINT BOF, alas beer > will not be served. I would think it should be schnapps... peppermint that is. If you guys can't come up with a better name. (please!) -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 20:32:30 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53ABF3A6C95; Mon, 18 Feb 2008 20:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-2.291, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E04DDUaDE4-A; Mon, 18 Feb 2008 20:32:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7A33A692C; Mon, 18 Feb 2008 20:32:29 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59FDF3A692C for ; Mon, 18 Feb 2008 20:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vbd4PwTsXBn for ; Mon, 18 Feb 2008 20:32:26 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4CDC93A67E6 for ; Mon, 18 Feb 2008 20:32:26 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2008 23:32:24 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1J4WN9a021388; Mon, 18 Feb 2008 23:32:23 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1J4WNWD015278; Tue, 19 Feb 2008 04:32:23 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 23:32:23 -0500 Received: from [10.86.240.164] ([10.86.240.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 23:32:22 -0500 Message-ID: <47BA5BE0.3070000@cisco.com> Date: Mon, 18 Feb 2008 23:32:32 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan References: <47B9125B.2060104@cisco.com> <47B9B294.7010700@joelhalpern.com> <47B9F385.4010804@cisco.com> <47BA495C.5000204@joelhalpern.com> In-Reply-To: X-OriginalArrivalTime: 19 Feb 2008 04:32:22.0795 (UTC) FILETIME=[6BC51DB0:01C872B0] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: IETF SIP List , "Joel M. Halpern" Subject: Re: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel, Hadriel Kaplan wrote: > What you say sound like the arguments against dealing with consumer NATs. :) > Inline... > > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, February 18, 2008 10:14 PM >> To: Hadriel Kaplan >> Cc: Paul Kyzivat; IETF SIP List >> Subject: Re: [Sip] SIP & E.164 assertions >> >> That, treating anything that smells like an E.164 like an E.164, may >> well be common practice. >> But it seems to me >> a) it is a practice which is inherently misleading and error prone > > It works right now, because virtually all sip communication is E.164's, if the userpart is digits at all (and long enough, and following certain patterns). In fact, I'd argue it works *better* than not doing it, for that reason. Most of the time, maybe virtually ALL of the time, when there is no user=phone param, it's because a device screwed up not putting it there. > So you've got the incumbent/deployed boxes doing something that works. If it ain't broke, no one is going to fix it. Especially if fixing it breaks something already deployed. > (BTW, I'm talking about provider side - I don't know if this holds true in Enterprise SIP at all, given their funky dial plans, but my guess is for them it's a pattern match or external dial prefix match) What you are describing is a "do what I mean" system rather than a "do what I say" system. With enough brute force you can make this work, by configuring everything to understand the conventions of all its neighbors. (And I know that is the typical deployment style used by my own employer's products.) It is better than nothing, but it is far from ideal. It of course then enhances the belief that peering arrangements must be bilateral, because you need to negotiate the mapping of dial strings. (And if your business is managing these boundaries then this may be a good thing.) But a system where everyone uses E.164 numbers, and where they *say* they are E.164 numbers, would simplify a lot of that. >> b) it is a practice we can not sensibly design for / around. > > I'm not sure we need to. I didn't catch what the "problem" with this is with regard to E.164 assertions? I mean let's pretend all of them have user=phone, and look just like a TEL username should or whatever. What does that solve in terms of e164 identity? I know of systems that assume a user part containing digits is a dial string. They don't quite "get it" that the dial string of one party may not be a vaid dial string for another party, or that even if it is it may denote a different destination. Is that a "problem"? I guess that depends. Is this an appropriate thing to do? IMO no. But in a world where everybody decides for themselves what the user part of somebody else's phone number means, who is to say it is wrong? Paul >> c) It is not the working group's problem to repair security flaws >> introduced by such behavior. It is the vendor's problem. > > And what exactly is the security flaw introduced? You're not telling me that a user=phone parameter is somehow a security mechanism? Is it like the evil bit or something? ;) > > -hadriel > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 21:42:47 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C0528C3AE; Mon, 18 Feb 2008 21:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.264 X-Spam-Level: X-Spam-Status: No, score=-0.264 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABCvVyCZ5gNg; Mon, 18 Feb 2008 21:42:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABD53A6985; Mon, 18 Feb 2008 21:42:46 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466743A6A1C for ; Mon, 18 Feb 2008 21:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0nc4S0nVEjE for ; Mon, 18 Feb 2008 21:42:43 -0800 (PST) Received: from tama555.ecl.ntt.co.jp (tama555.ecl.ntt.co.jp [129.60.39.106]) by core3.amsl.com (Postfix) with ESMTP id 41C2E3A6A1F for ; Mon, 18 Feb 2008 21:41:48 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama555.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m1J5fiki012991; Tue, 19 Feb 2008 14:41:44 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4EC0463EE; Tue, 19 Feb 2008 14:41:44 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4A6D363ED; Tue, 19 Feb 2008 14:41:44 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m1J5fgLp013289; Tue, 19 Feb 2008 14:41:42 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m1J5fevZ013255; Tue, 19 Feb 2008 14:41:40 +0900 (JST) Received: from [129.60.20.182] ([129.60.20.182]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m1J5felK000417; Tue, 19 Feb 2008 14:41:40 +0900 (JST) Message-ID: <47BA6CE4.8090004@lab.ntt.co.jp> Date: Tue, 19 Feb 2008 14:45:08 +0900 From: Mayumi Munakata User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sip@ietf.org Subject: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org All; I have just submitted a new version of ua-privacy draft. http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-01.txt Thanks to John Elwell for his comprehensive review, we managed to make a lot of editorial corrections and some technical. One profound open issue we have is on how to get an anonymous URI for a From header. While we can use a temp-gruu for a Contact header, there is no mechanism to obtain a functional anonymous URI for the From header or any other headers that houses URIs. RFC3323 recommends to use "anonymous@anonymous.invalid" for an anonymous URI in a From header. However, this impedes the use of SIP-Identity, as SIP-Identity mandates the domain portion of the "From" URI and that of "Identity-Info" to match. One of the expired draft written by Jonathan, attempted to use the GRUU to get this functional yet anonymous URI to address this issue. http://ietfreport.isoc.org/idref/draft-rosenberg-sip-identity-privacy/ I can see few ways forward. 1. Suggest the use of anonymous@{user's domain name}, which verifier then can verify the signature's validity as domain portion of the URI and that of Identity-Info matches. >> If SIP-Identity is used, the domain is given away anyhow in the Identity-Info, so what is the point of hiding the domain in the From header? 2. Make a note that SIP-Identity will not function when anonymous@anonymous.invalid is used. >> Describe the caveat that verifier is likely to fail the request or suggest that Authentication Service does not add Identity-Info/signature. 3. Extend GRUU to support mechanism that Rosenberg suggested. Does anybody has any preferences or any other suggestions? Regards, Mayumi _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 23:23:19 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FCA3A6DD1; Mon, 18 Feb 2008 23:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-1.530, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddz24QaUR4Bn; Mon, 18 Feb 2008 23:23:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35093A6C83; Mon, 18 Feb 2008 23:23:17 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E001B3A69A6 for ; Mon, 18 Feb 2008 23:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHAWuI6TtpMq for ; Mon, 18 Feb 2008 23:23:16 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0631B3A6C83 for ; Mon, 18 Feb 2008 23:23:16 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2008 23:23:13 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1J7ND6o012490; Mon, 18 Feb 2008 23:23:13 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1J7N4Jg023037; Tue, 19 Feb 2008 07:23:13 GMT From: "Dan Wing" To: "'Dean Willis'" , References: <47B69D8C.8060605@softarmor.com> Date: Mon, 18 Feb 2008 23:23:04 -0800 Message-ID: <056301c872c8$49b03710$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47B69D8C.8060605@softarmor.com> Thread-Index: AchwdXQEf/8Sy8I3ScqBP7qlfqAPSwCUPJVg Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Sip] Headsup on Short Agenda for IETF 71 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Saturday, February 16, 2008 12:24 AM > To: sip@ietf.org > Subject: [Sip] Headsup on Short Agenda for IETF 71 > > It appears that we will get only 2 hours of working group > meeting time > in Philadelphia. > > That means we're going to have to be VERY efficient with our > use of time. > > What are the mosr important things? The things we REALLY need to talk > about? Inquiring minds want to know. > > Here are the things on our charter we're currently late on: > > 1) Outbound > 2) SIPS (which I think is pretty much done) > 3) Diagnostic Responses > 4) Example security flows > 5) Extensions to SIP UA Profile Delivery Change Notification Event > Package for XCAP > 6) Location Conveyance with SIP > 7) Connection reuse mechanism > 8) Session Policies > 9) Etags in conditional notification > 10) Using SAML for SIP > 11) New resource priority namespaces for DISA > 12) Requirements for media keying If the chairs could update everyone on the status -- we're waiting for requirements from 3GPP -- that should be enough to say about it in Philly. There is a discussion on the list regarding one requirement (R-REUSE), but so far only two of the co-authors of the document seem to be interested in discussing that requirement, so I guess it isn't much of a 'discussion'. We'll take it off-list and assume everyone agrees. > 13) X.509 Certificates for TLS use in SIP (done?) > 14) X.509 extended key usage for SIP (done?) > 15) Roadmap for SIP > 16) Delivering request-URI and parameters to UAS via proxy > 17) Establishment of secure media sessions using DTLS-SRT > 18) MIME body handling in SIP > 19) Identify requirements for test matrix to move SIP to > Draft Standard > > And the things we aren't late on yet: > > 1) Essential corrections to RFC 3261 (1st batch) > 2) Mechanisms for UA initiated privacy to WGLC > > > So c'mon, people. What do we need to talk about? And why aren't we > talking about it on the list already? There is the whole SIP Identity and E.164 problem which was brought to light during Jason Fischl's DTLS presentation in Vancouver. There are at least eight new drafts posted related to SIP Identity and E.164: draft-darilion-sip-e164-enum-00.txt draft-elwell-sip-e164-problem-statement-00.txt draft-fischer-sip-e2e-sec-media-00.txt draft-kaplan-sip-baiting-attack-01.txt draft-kaplan-sip-uris-change-00.txt draft-rosenberg-sip-rfc4474-concerns-00.txt draft-schwartz-sip-e164-ownership-00.txt draft-wing-sip-e164-rrc-01.txt So it seems there is interest in that topic, but a 10-20 minute slot isn't enough time to say anything intelligent. -d _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 23:24:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BAA63A6DD1; Mon, 18 Feb 2008 23:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kofvqvmRqmpr; Mon, 18 Feb 2008 23:24:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160783A6A4B; Mon, 18 Feb 2008 23:24:26 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208233A6A4B for ; Mon, 18 Feb 2008 23:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tFaaqPXdE8N for ; Mon, 18 Feb 2008 23:24:23 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 41C713A6781 for ; Mon, 18 Feb 2008 23:24:23 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2008 07:24:19 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp006) with SMTP; 19 Feb 2008 08:24:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18E/PtLnkgEXOxleRuP9oJn0FvwFfKm1BKSFonLzu rkormQdHulRdnK Message-ID: <47BA8421.9040209@gmx.net> Date: Tue, 19 Feb 2008 09:24:17 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Richard Shockey References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> <134a01c8727c$0d3530c0$279f9240$@us> In-Reply-To: <134a01c8727c$0d3530c0$279f9240$@us> X-Y-GMX-Trusted: 0 Cc: 'IETF SIP List' , 'Paul Kyzivat' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Richard I have thought about that. When I spoke to a couple of people about = requesting a slot in ENUM they told me that ENUM is not the right place = to discuss this. Feedback from the ENUM WG would certainly be helpful. ; Ciao Hannes Richard Shockey wrote: > So did you guys want a slot during the ENUM WG? > > = >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Monday, February 18, 2008 2:55 PM >> To: ext Jonathan Rosenberg; Paul Kyzivat >> Cc: IETF SIP List >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >> = >> Hi Jonathan, >> Hi Paul, >> = >> thanks for raising the aspect of E.164 and ENUM usage. There was an >> offline discussion between Dan Wing, Klaus Darilion, Kai Fischer, >> David Schwartz, Hadriel Kaplan, John Elwell, and myself about E.164 >> and SIP Identity. As part of the discussion Klaus and I polished a >> former document of Alexander Mayrhofer on the usage of ENUM for E.164 >> numbers (see draft-mayrhofer-enum-domainkeys-00). As we moved along >> with the work we obviously came across a couple of problems (as one >> can easily imagine) and the document triggered a long discussion among >> us. Dispite a couple of challenges, we published the document today >> (see http://www.ietf.org/internet-drafts/draft-darilion-sip-e164-enum- >> 00.txt). I learned a lot while working on that document. >> = >> In addition to publishing the document a few of us have also worked on >> a document that captures some of our discussion on E.164 number >> ownership. I will publish it very soon -- just a bit more proof- >> reading. >> = >> Ciao >> Hannes >> = >> > -----Urspr=FCngliche Nachricht----- >> > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im >> > Auftrag von ext Jonathan Rosenberg >> > Gesendet: Montag, 18. Februar 2008 21:36 >> > An: Paul Kyzivat >> > Cc: IETF SIP List >> > Betreff: Re: [Sip] New I-D on RFC4474 and phone numbers >> > >> > I agree that something along the lines of enum could solve >> > this problem, >> > and I believe there was a draft that proposed such a thing. This has >> > been discussed since the start of rfc4474. >> > >> > However, I fear that saying, 'use enum' is kind of like saying, >> we'll >> > just use an All-Knowing Oracle, so lets figure out the interface >> > protocol to the Oracle. The easy part is the interface (the enum >> > mechanism). The actual hard problem is how to get those entries >> > populated. The deployment of public enum has been - shall we >> > say - less >> > than spectacular. I'd hate for that to be our only solution. Not >> that >> > its obvious what else to do; though I do suggest in my draft >> > how domain >> > based authentication, when combined with whitelists and >> > blacklists, can >> > help. >> > >> > -Jonathan R. >> > >> > Paul Kyzivat wrote: >> > > Jonathan, >> > > >> > > I guess the time has come for this discussion, since John >> > Ewell has also >> > > submitted a draft on this subject. >> > > >> > > I thought the problem was already well known, but perhaps >> > not. IMO the >> > > main thing now is to figure out the *solution* to the problem! >> > > IMO a solution is to use a 4474-style approach, but where the >> > > certificate is tied to just the phone number, not to some >> arbitrary >> > > domain name. That of course would depend on a model where >> > the "owner" of >> > > the phone number is the one who may obtain the certificate >> > for that number. >> > > >> > > My thought is that we already have an algorithmic mapping >> > from an E.164 >> > > phone number to a domain name, defined by enum. If the >> > sender puts an >> > > E.164 number in From, and can sign it with a cert for the >> > enum mapped >> > > domain name corresponding to that number, then that ought >> > to be valid >> > > proof of the validity of the sender. >> > > >> > > In those places where public enum is in operation, I think there >> is >> > > already a legal mechanism in place to give the owner of record of >> a >> > > particular phone number control over the contents of the >> > corresponding >> > > DNS entry. That should also be sufficient to allow a certificate >> > > authority to assign a cert to that same owner. >> > > >> > > Combine all that and you have a complete e2e identity model >> > for phone >> > > numbers, based on public enum. And that can be true even if >> > public enum >> > > isn't used to *route* the calls to that number. So it could >> > be used for >> > > "unlisted" numbers. >> > > >> > > To use this approach the From header should contain either >> > a TEL URI, or >> > > a sip/sips URI containing the enum-mapped domain name >> > corresponding to >> > > the phone number. (I would rather see the TEL used for this >> > - it is more >> > > user friendly.) >> > > >> > > Thanks, >> > > Paul >> > > >> > > Jonathan Rosenberg wrote: >> > >> I just submitted: >> > >> >> > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc447 >> > 4-concerns-00.txt >> > >> >> > >> >> > >> This is basically a discussion on the security properties >> > of rfc4474 >> > >> with phone numbers, and a comparison to rfc3325 in this >> > case. Also a >> > >> discussion on what happens to dtls-srtp. >> > >> >> > >> Comments welcome. >> > >> >> > >> -Jonathan R. >> > > >> > >> > -- >> > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >> > Cisco Fellow Edison, NJ 08837 >> > Cisco, Voice Technology Group >> > jdrosen@cisco.com >> > http://www.jdrosen.net PHONE: (408) 902-3084 >> > http://www.cisco.com >> > _______________________________________________ >> > Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> = > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 23:24:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF6C3A69A6; Mon, 18 Feb 2008 23:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCfsGOAWR7Zh; Mon, 18 Feb 2008 23:24:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8913A6D90; Mon, 18 Feb 2008 23:24:36 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1753A69A6 for ; Mon, 18 Feb 2008 23:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5VZbxUgXKq4 for ; Mon, 18 Feb 2008 23:24:34 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4923D3A6D90 for ; Mon, 18 Feb 2008 23:24:34 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2008 07:24:31 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp057) with SMTP; 19 Feb 2008 08:24:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/peaogGiHpYfMtW/MZ1bAwsaJWlPBm3dYNV6Kly9 HF63L6TKCBKouE Message-ID: <47BA842D.3060600@gmx.net> Date: Tue, 19 Feb 2008 09:24:29 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Richard Shockey References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> In-Reply-To: <134b01c8727c$b2b90440$182b0cc0$@us> X-Y-GMX-Trusted: 0 Cc: 'IETF SIP List' , 'Paul Kyzivat' Subject: [Sip] Oracle -- New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Richard, Richard Shockey wrote: > In line > > >> I agree that something along the lines of enum could solve this >> problem, >> and I believe there was a draft that proposed such a thing. This has >> been discussed since the start of rfc4474. >> >> However, I fear that saying, 'use enum' is kind of like saying, we'll >> just use an All-Knowing Oracle, so lets figure out the interface >> protocol to the Oracle. >> > > Yea and lets end world hunger while we're at it ... > > > It sounds like a super big thing when someone talk about an "oracle". The DNS is in some sense such an oracle since it returns you an IP address when you give it the FQDN. Hence, we are talking about a distributed database in this case for providing E.164 ownership. It is, for sure, more complicated than other techniques (such as matching the content of certain fields in a certificate with fields in a protocol message) but if these simpler techniques don't work what are you supposed todo? Ciao Hannes _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 18 23:55:42 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A1D3A6DB2; Mon, 18 Feb 2008 23:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kZ0fO4D8AM1; Mon, 18 Feb 2008 23:55:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F269E3A69FE; Mon, 18 Feb 2008 23:55:41 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1503A69D1 for ; Mon, 18 Feb 2008 23:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JEjKT6K1SZK for ; Mon, 18 Feb 2008 23:55:40 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 974633A69FE for ; Mon, 18 Feb 2008 23:55:40 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Feb 2008 23:55:38 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1J7tckJ006579; Mon, 18 Feb 2008 23:55:38 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1J7tbJg016763; Tue, 19 Feb 2008 07:55:37 GMT From: "Dan Wing" To: "'Dean Willis'" , "'Richard Shockey'" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com><47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> Date: Mon, 18 Feb 2008 23:55:37 -0800 Message-ID: <057501c872cc$d0bea8f0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AchyrbdJEP+Na2/JQm2Zs8nxrbb8ngAHufIw Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'IETF SIP List' , 'Paul Kyzivat' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Monday, February 18, 2008 8:12 PM > To: Richard Shockey > Cc: 'IETF SIP List'; 'Paul Kyzivat' > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > > On Feb 18, 2008, at 4:22 PM, Richard Shockey wrote: > > > > The very idea that there is going to be some consensus on > who "owns" > > a phone > > number, much less a deployable system considering the various > > competing > > interests here is a complete fantasy. > > > > Counterargument: If I call phone number X, and the responding party > can complete a media-path handshake against the published key > for that > number, then I'd claim they "own" it. Possession is, after all, > 9/10ths of the law. > > In other words, to heck with the government -- who answers the phone? That is what draft-wing-sip-e164-rrc-01 does, except it does it over the signaling path. The same thing could be done over the media path (using TOTE, even, if we like), if doing RRC over the media path is deemed better/stronger/faster. -d > -- > dean > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 00:09:29 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A053A6DE8; Tue, 19 Feb 2008 00:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-1.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3aGaxi9NrKr; Tue, 19 Feb 2008 00:09:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E8E3A6DDD; Tue, 19 Feb 2008 00:09:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940EC3A690C for ; Tue, 19 Feb 2008 00:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLC6EnnnGojd for ; Tue, 19 Feb 2008 00:09:26 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D85043A6896 for ; Tue, 19 Feb 2008 00:09:26 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 19 Feb 2008 00:09:24 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1J89Ol3024839; Tue, 19 Feb 2008 00:09:24 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1J89NJg028985; Tue, 19 Feb 2008 08:09:23 GMT From: "Dan Wing" To: "'Frank W. Miller'" , "'Paul Kyzivat'" References: <47B9CE49.7080504@cisco.com> <20080218183757.E892C758072@smtpauth00.csee.onr.siteprotect.com> Date: Tue, 19 Feb 2008 00:09:23 -0800 Message-ID: <057901c872ce$bd4cb710$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080218183757.E892C758072@smtpauth00.csee.onr.siteprotect.com> Thread-Index: AchyXAqSwatk5ygPS3Sg1J8IqVO50gAAMYHgABxT5mA= Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'IETF SIP List' , 'Dean Willis' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > FM: Look, I'm sure this community is going to probably go off > and spend a > lot of time doing this. And there may ultimately be large, expensive > deployments of certs and signatures, etc. etc. Just don't > kid yourself that its going to stop phishing or spit cuz it won't Nothing will stop phishing or spit. Absolutely nothing. Similar attacks happen in the Real World with looks-like-real FedEx trucks and Border Patrol vans, http://abcnews.go.com/Blotter/popup?id=4154733&contentIndex=1&page=6 What strong identity will do is create ... strong identity. With that, we can build useful and reliable whitelists. We can build useful and reliable reputation systems. We can build a lot of things. Without strong identity, SIP will behave very much like everyone's inbox. Except, unlike email, you cannot filter SIP using content filtering (because there is no message) so popular and relatively effective tools like Bayesian filters and SpamAssassin will not work for SIP. So SIP needs effective and functional identity. Nobody believes identity, by itself, will stop spit or phishing. However, identity is necessary to build anything else of value. -d _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 00:20:52 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A633A6DD6; Tue, 19 Feb 2008 00:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-1.437, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK1apmLJXGWk; Tue, 19 Feb 2008 00:20:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A48E3A6DD8; Tue, 19 Feb 2008 00:20:51 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C213A6DD8 for ; Tue, 19 Feb 2008 00:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frYYObn+hCMC for ; Tue, 19 Feb 2008 00:20:49 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 334BB3A6DD6 for ; Tue, 19 Feb 2008 00:20:49 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 19 Feb 2008 00:20:46 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1J8KkD6010262; Tue, 19 Feb 2008 00:20:46 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1J8Kivn019289; Tue, 19 Feb 2008 08:20:44 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , "'SIP IETF'" References: <127f01c87277$c61615f0$524241d0$@us> <47BA0624.3060401@cisco.com> Date: Tue, 19 Feb 2008 00:20:44 -0800 Message-ID: <057a01c872d0$52ddf0e0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47BA0624.3060401@cisco.com> Thread-Index: AchyfiFJ+fYX/8gXRYyGdOCKIn8Y4wAUbmSw Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] [Enum] FW: I-DAction:draft-schwartz-sip-e164-ownership-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, February 18, 2008 2:27 PM > To: SIP IETF > Subject: Re: [Sip] [Enum] FW: > I-DAction:draft-schwartz-sip-e164-ownership-00.txt > > Nice draft. > > One thing this highlights is that even if we solve the > identity problem > for E.164 numbers in sip-sip cases, the identity problem will > remain for > the pstn-sip case. > > The solutions for the sip-sip case will presumably require > that somebody > actually *know* the sender is the owner of the number. The GW in a > pstn-sip call will in general not know that. In reality the > callerid in > pstn calls cannot be trusted, so a true assertion of it > cannot be done > with a pstn source. Yet from a practical perspective most > will consider > a pstn assertion of identity to be something they want to know about. > > That suggests to me that a weaker form of assertion is needed in that > case, and that for suitably smart phones different forms of callerid > presentation be used in those cases, reflecting the degree of > confidence > in the value being presented. The PSTN's assertion of identity using CLID (which is the PSTN's user-asserted identity) is as valuable as SIP's "From:" (which is SIP's user-asserted identity). The PSTN's assertion of identity using ANI (which is the PSTN's network-asserted identity) is as valuable as SIP's "P-Asserted-Identity:" (which is SIP's network-asserted identity). A PSTN->SIP gateway would not want to, and MUST NOT, attempt to provide a stronger assertion of identity because the PSTN itself has very a weak identity model (transitive trust). -d > Thanks, > Paul > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 00:26:11 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA17C28C4A1; Tue, 19 Feb 2008 00:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=-1.428, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvDbQsZB5B1A; Tue, 19 Feb 2008 00:26:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEC63A6DEF; Tue, 19 Feb 2008 00:26:10 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106283A6D9A for ; Tue, 19 Feb 2008 00:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEi5f6teb5WY for ; Tue, 19 Feb 2008 00:26:09 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A849128C3D5 for ; Tue, 19 Feb 2008 00:26:08 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Feb 2008 00:26:06 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1J8Q6T8017792; Tue, 19 Feb 2008 00:26:06 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1J8Puvn022835; Tue, 19 Feb 2008 08:26:05 GMT From: "Dan Wing" To: "'Richard Shockey'" , "'Paul Kyzivat'" , "'Frank W. Miller'" References: <20080218175250.43ED4E38024@smtpauth02.csee.onr.siteprotect.com><47B9CE49.7080504@cisco.com> <134c01c8727d$ad9ec0c0$08dc4240$@us> Date: Tue, 19 Feb 2008 00:25:56 -0800 Message-ID: <057b01c872d1$12663a80$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <134c01c8727d$ad9ec0c0$08dc4240$@us> Thread-Index: AchyW/W2m7qBAo9bRMq+7qFrB+uDZQAIQbYwABTaV7A= Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'IETF SIP List' , 'Dean Willis' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > Frank, > > > > So are you asserting that reliable callerid is not needed, > > or that it is not possible? > > > > If its not needed, then I guess sip identity was a waste > > of time, as > > is P-Asserted-ID. From should be good enough. > > > > The PSTN callerid is to a large extend based on transitive > > trust, and > > is> reliable if the providers are careful. It breaks when > > providers trust > > sources that they shouldn't. Apparently that is becoming an > > increasingly common case. > > Really ??? Transitive trust seems to have worked reasonable > well for the > time being .what examples have you found of sources that > providers thought > they could trust but found they shouldn't have? The first page of http://www.google.com/search?q=caller+id+spoofing shows 4 companies that appear to provide caller ID spoofing for a fee. Of course, providers don't care much about Caller ID spoofing as that only fools subscribers. So, to your question: providers do care about the ANI, which is used by their own systems. I will leave you to search the Internet to see if there are companies and products that proport to sell or provide ANI spoofing. I found 1 product and 3 service companies on the first page of my Google search. -d _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 02:30:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082673A6DE0; Tue, 19 Feb 2008 02:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.493 X-Spam-Level: * X-Spam-Status: No, score=1.493 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKzxOKlR8q47; Tue, 19 Feb 2008 02:30:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDEF3A6A59; Tue, 19 Feb 2008 02:30:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF44B3A6A5F for ; Tue, 19 Feb 2008 02:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6oRM8gPHURL for ; Tue, 19 Feb 2008 02:30:32 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by core3.amsl.com (Postfix) with ESMTP id 03C823A6A59 for ; Tue, 19 Feb 2008 02:30:31 -0800 (PST) Received: by wx-out-0506.google.com with SMTP id s8so1828955wxc.31 for ; Tue, 19 Feb 2008 02:30:29 -0800 (PST) Received: by 10.142.237.20 with SMTP id k20mr5107343wfh.227.1203417028581; Tue, 19 Feb 2008 02:30:28 -0800 (PST) Received: by 10.142.99.8 with HTTP; Tue, 19 Feb 2008 02:30:28 -0800 (PST) Message-ID: <52db68bc0802190230s1b565783p4df788cd28ffd345@mail.gmail.com> Date: Tue, 19 Feb 2008 16:00:28 +0530 From: "Sudhir Kumar Reddy" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] is supported and require is Mandatory in INVITE request X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0050422499==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0050422499== Content-Type: multipart/alternative; boundary="----=_Part_6460_22037421.1203417028562" ------=_Part_6460_22037421.1203417028562 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, Is supported and require methods are required for INVITE request (RFC 3262) or any of method(either Supported or require) will suffice for INVITE for Provisional ACK. Because I see in one of INVITE(from server) sending only require: 100Rel, but there is no Supported Header. Should we treat as complete or incomplete request? Any response is highly appreciated. Thanks in Advance Sudhir ------=_Part_6460_22037421.1203417028562 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

    Is supported and require methods are required for INVITE request (RFC 3262) or any of method(either Supported or require) will suffice for INVITE for Provisional ACK. Because I see in one of INVITE(from server) sending only require: 100Rel, but there is no Supported Header.

    Should we treat as complete or incomplete request?

    Any response is highly appreciated.

    Thanks in Advance
    Sudhir ------=_Part_6460_22037421.1203417028562-- --===============0050422499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0050422499==-- From sip-bounces@ietf.org Tue Feb 19 02:42:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A330928C530; Tue, 19 Feb 2008 02:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.123 X-Spam-Level: X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfYh1NksES5V; Tue, 19 Feb 2008 02:42:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBC93A6A56; Tue, 19 Feb 2008 02:42:46 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84CE73A68AB for ; Tue, 19 Feb 2008 02:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgAbzdRs1sKz for ; Tue, 19 Feb 2008 02:42:43 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EB76A28C49D for ; Tue, 19 Feb 2008 02:42:32 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 19 Feb 2008 05:42:16 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 19 Feb 2008 05:42:16 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Tue, 19 Feb 2008 05:42:16 -0500 Thread-Topic: [Sip] SIP & E.164 assertions Thread-Index: AchysGew2TTIUIPaQ1CAF9Z0aF4kYwAKgUCw Message-ID: References: <47B9125B.2060104@cisco.com> <47B9B294.7010700@joelhalpern.com> <47B9F385.4010804@cisco.com> <47BA495C.5000204@joelhalpern.com> <47BA5BE0.3070000@cisco.com> In-Reply-To: <47BA5BE0.3070000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List , "Joel M. Halpern" Subject: Re: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hey Paul, Inline... > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, February 18, 2008 11:33 PM > > What you are describing is a "do what I mean" system rather than a "do > what I say" system. Yes, but I should have been clearer - I'm not advocating we try to standardize it or some such. It just is the reality. So we can just continue assuming user=phone and such make it an e164, for the purpose of the identity mechanism for e614 (whatever the mechanism is). Those who treat other things as e164 will just apply the same rules to them. We may just need a "I signed this as e164" flag if the identity mechanism is different than for non-e164, or some such concept. > It of course then enhances the belief that peering arrangements must be > bilateral, because you need to negotiate the mapping of dial strings. > (And if your business is managing these boundaries then this may be a > good thing.) Actually, that is very much NOT in the best interest of those managing such things. Any configuration whatsoever slows down peering bring-up time, and that does not help sell more border boxes. It is in the best interest of border-box vendors to make it as plug-play/standard as possible. (and I don't think peering is bilateral because of dial-string formats, but that's getting off-topic) > But a system where everyone uses E.164 numbers, and where they *say* > they are E.164 numbers, would simplify a lot of that. Yeah, no disagreement there. -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 03:19:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA19528C552; Tue, 19 Feb 2008 03:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.617 X-Spam-Level: * X-Spam-Status: No, score=1.617 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HIMH36mUrTc; Tue, 19 Feb 2008 03:19:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE6428C505; Tue, 19 Feb 2008 03:19:35 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF4E28C4C6 for ; Tue, 19 Feb 2008 03:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUhbja6vkh+q for ; Tue, 19 Feb 2008 03:19:33 -0800 (PST) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by core3.amsl.com (Postfix) with ESMTP id 9991D28C50E for ; Tue, 19 Feb 2008 03:19:32 -0800 (PST) X-AuditID: cb5bdd58-abf2ebb000000747-c0-47babba0d99e Received: from blr-ec-bh02.wipro.com (unknown [10.201.50.92]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with ESMTP id C2036420002 for ; Tue, 19 Feb 2008 16:51:04 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Feb 2008 16:49:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 16:51:10 +0530 Message-ID: In-Reply-To: <52db68bc0802190230s1b565783p4df788cd28ffd345@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] is supported and require is Mandatory in INVITE request Thread-Index: Achy4n79x2PXHibzR1aECRmUPVUKpwABRT7A From: To: , X-OriginalArrivalTime: 19 Feb 2008 11:19:28.0106 (UTC) FILETIME=[4A63CCA0:01C872E9] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] is supported and require is Mandatory in INVITE request X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0928145109==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0928145109== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C872E9.4A30D491" This is a multi-part message in MIME format. ------_=_NextPart_001_01C872E9.4A30D491 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sudhir, "Supported" and "Require" are known as headers rather than methods. These two headers have the following significance as per RFC 3261 : =20 20.32 Require The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. =20 20.37 Supported The Supported header field enumerates all the extensions supported by the UAC or UAS. If INVITE contains just "Supported" header, the UAS "MAY" send the non-100 responses reliably as stated in RFC 3262 =20 If INVITE contains "Require" header, the UAS "MUST" send the non-100 responses reliably. If it does not support this extension, it should respond to the INVITE with "420 Bad Extension" response. =20 Its valid for a UAC to send INVITE with just "Require: 100 rel" header as well. Best Regards, Rekha (ESN : 6-877-5834) (PSTN : 81168) =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Sudhir Kumar Reddy Sent: Tuesday, February 19, 2008 4:00 PM To: sip@ietf.org Subject: [Sip] is supported and require is Mandatory in INVITE request Hi All, Is supported and require methods are required for INVITE request (RFC 3262) or any of method(either Supported or require) will suffice for INVITE for Provisional ACK. Because I see in one of INVITE(from server) sending only require: 100Rel, but there is no Supported Header. Should we treat as complete or incomplete request? Any response is highly appreciated.=20 Thanks in Advance Sudhir=20 ------_=_NextPart_001_01C872E9.4A30D491 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hi Sudhir,
      "Supported" and "Require" are known as = headers=20 rather than methods.
      These two headers have the = following=20 significance as per RFC 3261 :
      
    20.32 = Require
    The=20 Require header field is used by UACs to tell UASs about = options
      =20 that the UAC expects the UAS to support in order to process = the
      =20 request.
     
    20.37=20 Supported
       The Supported header field enumerates all the=20 extensions supported by
       the UAC or UAS.
      If INVITE contains just "Supported" header, the UAS = "MAY" send the=20 non-100 responses reliably as stated in RFC 3262
     
      If INVITE contains "Require" header, the UAS "MUST" send = the=20 non-100 responses reliably. If it does not support this extension, it = should=20 respond to the INVITE with "420 Bad Extension" = response.
     
      Its valid for a UAC to send INVITE with just "Require: = 100 rel"=20 header as well.
    Best=20 Regards,
    Rekha
    (ESN :=20 6-877-5834)
    (PSTN :=20 81168)
     

    From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Sudhir Kumar=20 Reddy
    Sent: Tuesday, February 19, 2008 4:00 PM
    To:=20 sip@ietf.org
    Subject: [Sip] is supported and require is = Mandatory in=20 INVITE request

    Hi All,

    Is supported and require methods are required = for=20 INVITE request (RFC 3262) or any of method(either Supported or require) = will=20 suffice for INVITE for Provisional ACK. Because I see in one of = INVITE(from=20 server) sending only require: 100Rel, but there is no Supported=20 Header.

    Should we treat as complete or incomplete = request?

    Any=20 response is highly appreciated.

    Thanks in Advance
    Sudhir=20 ------_=_NextPart_001_01C872E9.4A30D491-- --===============0928145109== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0928145109==-- From sip-bounces@ietf.org Tue Feb 19 07:03:20 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17973A6D46; Tue, 19 Feb 2008 07:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj3FRKpjJntq; Tue, 19 Feb 2008 07:03:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7960A3A6AAB; Tue, 19 Feb 2008 07:03:19 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E543A695E; Tue, 19 Feb 2008 07:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8G-mXFIIWmI; Tue, 19 Feb 2008 07:03:16 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 7AE873A6A9F; Tue, 19 Feb 2008 07:03:16 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1JF27MM016770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2008 07:02:09 -0800 From: "Richard Shockey" To: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> <134a01c8727c$0d3530c0$279f9240$@us> <47BA8421.9040209@gmx.net> In-Reply-To: <47BA8421.9040209@gmx.net> Date: Tue, 19 Feb 2008 10:00:52 -0500 Message-ID: <0af801c87308$3a672530$af356f90$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchyyF2iXQBrESw/QcejEIi4+p7SEgAPvGPw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'IETF SIP List' , enum@ietf.org, 'Paul Kyzivat' Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well ENUM is on a short leash in Philadelphia with only 1 hour, we are trying to slowly but deliberately wind things down. It might not be the best time, but we certainly have large body of expertise in dealing with E.164 numbers and the history of trying to deal with number mappings in globally distributed databases. :-) = It's certainly something worth discussing the ENUM WG list from time to time but the real issues are all layer 8 and above. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, February 19, 2008 2:24 AM > To: Richard Shockey > Cc: 'IETF SIP List'; 'Paul Kyzivat' > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > = > Hi Richard > = > I have thought about that. When I spoke to a couple of people about > requesting a slot in ENUM they told me that ENUM is not the right > place > to discuss this. > Feedback from the ENUM WG would certainly be helpful. ; > = > Ciao > Hannes > = > Richard Shockey wrote: > > So did you guys want a slot during the ENUM WG? > > > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf > Of > >> Tschofenig, Hannes (NSN - FI/Espoo) > >> Sent: Monday, February 18, 2008 2:55 PM > >> To: ext Jonathan Rosenberg; Paul Kyzivat > >> Cc: IETF SIP List > >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > >> > >> Hi Jonathan, > >> Hi Paul, > >> > >> thanks for raising the aspect of E.164 and ENUM usage. There was > an > >> offline discussion between Dan Wing, Klaus Darilion, Kai Fischer, > >> David Schwartz, Hadriel Kaplan, John Elwell, and myself about > E.164 > >> and SIP Identity. As part of the discussion Klaus and I polished a > >> former document of Alexander Mayrhofer on the usage of ENUM for > E.164 > >> numbers (see draft-mayrhofer-enum-domainkeys-00). As we moved > along > >> with the work we obviously came across a couple of problems (as > one > >> can easily imagine) and the document triggered a long discussion > among > >> us. Dispite a couple of challenges, we published the document > today > >> (see http://www.ietf.org/internet-drafts/draft-darilion-sip-e164- > enum- > >> 00.txt). I learned a lot while working on that document. > >> > >> In addition to publishing the document a few of us have also > worked on > >> a document that captures some of our discussion on E.164 number > >> ownership. I will publish it very soon -- just a bit more proof- > >> reading. > >> > >> Ciao > >> Hannes > >> > >> > -----Urspr=FCngliche Nachricht----- > >> > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im > >> > Auftrag von ext Jonathan Rosenberg > >> > Gesendet: Montag, 18. Februar 2008 21:36 > >> > An: Paul Kyzivat > >> > Cc: IETF SIP List > >> > Betreff: Re: [Sip] New I-D on RFC4474 and phone numbers > >> > > >> > I agree that something along the lines of enum could solve > >> > this problem, > >> > and I believe there was a draft that proposed such a thing. This > has > >> > been discussed since the start of rfc4474. > >> > > >> > However, I fear that saying, 'use enum' is kind of like saying, > >> we'll > >> > just use an All-Knowing Oracle, so lets figure out the interface > >> > protocol to the Oracle. The easy part is the interface (the enum > >> > mechanism). The actual hard problem is how to get those entries > >> > populated. The deployment of public enum has been - shall we > >> > say - less > >> > than spectacular. I'd hate for that to be our only solution. Not > >> that > >> > its obvious what else to do; though I do suggest in my draft > >> > how domain > >> > based authentication, when combined with whitelists and > >> > blacklists, can > >> > help. > >> > > >> > -Jonathan R. > >> > > >> > Paul Kyzivat wrote: > >> > > Jonathan, > >> > > > >> > > I guess the time has come for this discussion, since John > >> > Ewell has also > >> > > submitted a draft on this subject. > >> > > > >> > > I thought the problem was already well known, but perhaps > >> > not. IMO the > >> > > main thing now is to figure out the *solution* to the problem! > >> > > IMO a solution is to use a 4474-style approach, but where the > >> > > certificate is tied to just the phone number, not to some > >> arbitrary > >> > > domain name. That of course would depend on a model where > >> > the "owner" of > >> > > the phone number is the one who may obtain the certificate > >> > for that number. > >> > > > >> > > My thought is that we already have an algorithmic mapping > >> > from an E.164 > >> > > phone number to a domain name, defined by enum. If the > >> > sender puts an > >> > > E.164 number in From, and can sign it with a cert for the > >> > enum mapped > >> > > domain name corresponding to that number, then that ought > >> > to be valid > >> > > proof of the validity of the sender. > >> > > > >> > > In those places where public enum is in operation, I think > there > >> is > >> > > already a legal mechanism in place to give the owner of record > of > >> a > >> > > particular phone number control over the contents of the > >> > corresponding > >> > > DNS entry. That should also be sufficient to allow a > certificate > >> > > authority to assign a cert to that same owner. > >> > > > >> > > Combine all that and you have a complete e2e identity model > >> > for phone > >> > > numbers, based on public enum. And that can be true even if > >> > public enum > >> > > isn't used to *route* the calls to that number. So it could > >> > be used for > >> > > "unlisted" numbers. > >> > > > >> > > To use this approach the From header should contain either > >> > a TEL URI, or > >> > > a sip/sips URI containing the enum-mapped domain name > >> > corresponding to > >> > > the phone number. (I would rather see the TEL used for this > >> > - it is more > >> > > user friendly.) > >> > > > >> > > Thanks, > >> > > Paul > >> > > > >> > > Jonathan Rosenberg wrote: > >> > >> I just submitted: > >> > >> > >> > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc447 > >> > 4-concerns-00.txt > >> > >> > >> > >> > >> > >> This is basically a discussion on the security properties > >> > of rfc4474 > >> > >> with phone numbers, and a comparison to rfc3325 in this > >> > case. Also a > >> > >> discussion on what happens to dtls-srtp. > >> > >> > >> > >> Comments welcome. > >> > >> > >> > >> -Jonathan R. > >> > > > >> > > >> > -- > >> > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > >> > Cisco Fellow Edison, NJ 08837 > >> > Cisco, Voice Technology Group > >> > jdrosen@cisco.com > >> > http://www.jdrosen.net PHONE: (408) 902- > 3084 > >> > http://www.cisco.com > >> > _______________________________________________ > >> > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> > This list is for NEW development of the core SIP Protocol > >> > Use sip-implementors@cs.columbia.edu for questions on current > sip > >> > Use sipping@ietf.org for new developments on the application of > sip > >> > > >> _______________________________________________ > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of > sip > >> > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > = > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 07:37:26 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C28E3A6E38; Tue, 19 Feb 2008 07:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIy2iHKK2oNQ; Tue, 19 Feb 2008 07:37:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9568B3A68EB; Tue, 19 Feb 2008 07:37:22 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925993A680B for ; Tue, 19 Feb 2008 07:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoR1jYbyl-kg for ; Tue, 19 Feb 2008 07:37:19 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id E34843A695E for ; Tue, 19 Feb 2008 07:36:44 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1JFZmlC013935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2008 07:35:50 -0800 From: "Richard Shockey" To: , "'IETF SIP List'" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> In-Reply-To: <47BA842D.3060600@gmx.net> Date: Tue, 19 Feb 2008 10:34:33 -0500 Message-ID: <0b6a01c8730c$eea1c4c0$cbe54e40$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchyyHTh32FeBaGQTsWEZvLx+Xi4KAAQakRw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: paf@cisco.com Subject: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > > > Yea and lets end world hunger while we're at it ... > > > > > > > It sounds like a super big thing when someone talk about an "oracle". > The DNS is in some sense such an oracle since it returns you an IP > address when you give it the FQDN. Hence, we are talking about a > distributed database in this case for providing E.164 ownership. It > is, > for sure, more complicated than other techniques (such as matching the > content of certain fields in a certificate with fields in a protocol > message) but if these simpler techniques don't work what are you > supposed todo? I wish I knew. But I do know Patrik Faltstrom, I and the IAB-IESG have no stomach for sitting around the ITU in Geneva for the next 5-7 years trying to get them to buy into a solution involving another apex involving e164 numbers. We are still trying to resolve the issue regarding the concept of Infrastructure ENUM ( which could involve certs BTW) and the associated drafts we produced in the last couple of years. We have been told that the IAB is trying to finalize the liaison letter to ITU SG2 on that issue as we speak. You might recall Patrik and I sent a Memorandum on this very issue of Infrastructure ENUM and related issues involving e164 numbers to the IAB-IESG some time ago. http://www.ietf.org/mail-archive/web/enum/current/msg05529.html If there is going to be a solution to the SIP identity problem involving e164 numbers, it will not IMHO be solved in the IETF. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 07:38:02 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1193A6E2F; Tue, 19 Feb 2008 07:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-2.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQ6lEhi2W+nD; Tue, 19 Feb 2008 07:38:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE963A6E22; Tue, 19 Feb 2008 07:37:44 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B873A69D5 for ; Tue, 19 Feb 2008 07:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqgjkZkQeOAr for ; Tue, 19 Feb 2008 07:37:42 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2BBBB3A6E26 for ; Tue, 19 Feb 2008 07:37:31 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2008 10:37:29 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1JFbS8O020675; Tue, 19 Feb 2008 10:37:28 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1JFbRSC004704; Tue, 19 Feb 2008 15:37:28 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 10:37:27 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 10:37:27 -0500 Message-ID: <47BAF7C2.8000301@cisco.com> Date: Tue, 19 Feb 2008 10:37:38 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mayumi Munakata References: <47BA6CE4.8090004@lab.ntt.co.jp> In-Reply-To: <47BA6CE4.8090004@lab.ntt.co.jp> X-OriginalArrivalTime: 19 Feb 2008 15:37:27.0351 (UTC) FILETIME=[54BD2470:01C8730D] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Why would you want sip-identity for an anonymous From address? IMO it is perfectly fine to provide an address with no identity. Paul Mayumi Munakata wrote: > All; > > I have just submitted a new version of ua-privacy draft. > http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-01.txt > > Thanks to John Elwell for his comprehensive review, > we managed to make a lot of editorial corrections > and some technical. > > One profound open issue we have is on how to get an > anonymous URI for a From header. While we can use a > temp-gruu for a Contact header, there is no mechanism > to obtain a functional anonymous URI for the From > header or any other headers that houses URIs. > > RFC3323 recommends to use "anonymous@anonymous.invalid" > for an anonymous URI in a From header. However, this > impedes the use of SIP-Identity, as SIP-Identity > mandates the domain portion of the "From" URI and > that of "Identity-Info" to match. > > One of the expired draft written by Jonathan, attempted > to use the GRUU to get this functional yet anonymous URI > to address this issue. > http://ietfreport.isoc.org/idref/draft-rosenberg-sip-identity-privacy/ > > I can see few ways forward. > > 1. Suggest the use of anonymous@{user's domain name}, which > verifier then can verify the signature's validity as > domain portion of the URI and that of Identity-Info matches. > >> If SIP-Identity is used, the domain is given away anyhow > in the Identity-Info, so what is the point of hiding the > domain in the From header? > > 2. Make a note that SIP-Identity will not function when > anonymous@anonymous.invalid is used. > >> Describe the caveat that verifier is likely to fail the > request or suggest that Authentication Service does not > add Identity-Info/signature. > > 3. Extend GRUU to support mechanism that Rosenberg suggested. > > Does anybody has any preferences or any other suggestions? > > Regards, > Mayumi > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 07:49:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401713A6D62; Tue, 19 Feb 2008 07:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNhoDSnC0XHH; Tue, 19 Feb 2008 07:49:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47AFA28C2A9; Tue, 19 Feb 2008 07:49:27 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548123A6AD2 for ; Tue, 19 Feb 2008 07:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdlVO+MF5GS9 for ; Tue, 19 Feb 2008 07:49:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1CD693A689A for ; Tue, 19 Feb 2008 07:49:24 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2008 15:49:21 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp041) with SMTP; 19 Feb 2008 16:49:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18rg2c7FAErf4Eoa4awaHqjz83xUY3N3Wfz9yUyWP Vb9wdSqlO4Wjwx Message-ID: <47BAFA7E.6060006@gmx.net> Date: Tue, 19 Feb 2008 17:49:18 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Richard Shockey References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> In-Reply-To: <0b6a01c8730c$eea1c4c0$cbe54e40$@us> X-Y-GMX-Trusted: 0 Cc: 'IETF SIP List' , paf@cisco.com Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > If there is going to be a solution to the SIP identity problem involving > e164 numbers, it will not IMHO be solved in the IETF. > > Interesting view. I obviously does not appear to be an easy thing; in the draft I called this "There is non-neglectable deployment incentive challenge." _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 07:56:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A153A6DD4; Tue, 19 Feb 2008 07:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQFHE+xE1bZj; Tue, 19 Feb 2008 07:56:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D1F3A6DF5; Tue, 19 Feb 2008 07:56:36 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6662A3A6DD4 for ; Tue, 19 Feb 2008 07:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QOWH5bXEGz5 for ; Tue, 19 Feb 2008 07:56:33 -0800 (PST) Received: from smtp.cnr.it (unknown [IPv6:2001:760:4000:60:202:55ff:fe9d:132f]) by core3.amsl.com (Postfix) with ESMTP id 0A0673A689A for ; Tue, 19 Feb 2008 07:56:33 -0800 (PST) Received: by smtp.cnr.it (Postfix, from userid 1000) id 4611FAC0BB; Tue, 19 Feb 2008 16:56:25 +0100 (CET) From: ".:: Francesco la Torre ::." To: Paul Kyzivat In-Reply-To: <47BAF7C2.8000301@cisco.com> References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> Date: Tue, 19 Feb 2008 16:56:25 +0100 Message-Id: <1203436585.5603.5.camel@frankernet-iit-cnr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Cc: Mayumi Munakata , sip@ietf.org Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org According some general privacy considerations, from an authentication service's point of view, an anonymous may be a known user in his domain that he has authenticated, but he's keeping its identity private. Nothing strange. Francesco la Torre IIT-National Council Research Security Session Pisa, Italy Il giorno mar, 19/02/2008 alle 10.37 -0500, Paul Kyzivat ha scritto: > Why would you want sip-identity for an anonymous From address? > > IMO it is perfectly fine to provide an address with no identity. > > Paul > > Mayumi Munakata wrote: > > All; > > > > I have just submitted a new version of ua-privacy draft. > > http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-01.txt > > > > Thanks to John Elwell for his comprehensive review, > > we managed to make a lot of editorial corrections > > and some technical. > > > > One profound open issue we have is on how to get an > > anonymous URI for a From header. While we can use a > > temp-gruu for a Contact header, there is no mechanism > > to obtain a functional anonymous URI for the From > > header or any other headers that houses URIs. > > > > RFC3323 recommends to use "anonymous@anonymous.invalid" > > for an anonymous URI in a From header. However, this > > impedes the use of SIP-Identity, as SIP-Identity > > mandates the domain portion of the "From" URI and > > that of "Identity-Info" to match. > > > > One of the expired draft written by Jonathan, attempted > > to use the GRUU to get this functional yet anonymous URI > > to address this issue. > > http://ietfreport.isoc.org/idref/draft-rosenberg-sip-identity-privacy/ > > > > I can see few ways forward. > > > > 1. Suggest the use of anonymous@{user's domain name}, which > > verifier then can verify the signature's validity as > > domain portion of the URI and that of Identity-Info matches. > > >> If SIP-Identity is used, the domain is given away anyhow > > in the Identity-Info, so what is the point of hiding the > > domain in the From header? > > > > 2. Make a note that SIP-Identity will not function when > > anonymous@anonymous.invalid is used. > > >> Describe the caveat that verifier is likely to fail the > > request or suggest that Authentication Service does not > > add Identity-Info/signature. > > > > 3. Extend GRUU to support mechanism that Rosenberg suggested. > > > > Does anybody has any preferences or any other suggestions? > > > > Regards, > > Mayumi > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 08:04:46 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF83828C679; Tue, 19 Feb 2008 08:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-2.273, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJKQ9-UwTaLm; Tue, 19 Feb 2008 08:04:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EE128C671; Tue, 19 Feb 2008 08:04:45 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3D828C5E6 for ; Tue, 19 Feb 2008 08:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyKbc1k8kAxi for ; Tue, 19 Feb 2008 08:04:43 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 30D3A28C600 for ; Tue, 19 Feb 2008 08:04:43 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2008 11:04:40 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1JG4eTn005637; Tue, 19 Feb 2008 11:04:40 -0500 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 m1JG4SSo016906; Tue, 19 Feb 2008 16:04:40 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 11:04:38 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 11:04:38 -0500 Message-ID: <47BAFE21.3010207@cisco.com> Date: Tue, 19 Feb 2008 11:04:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ".:: Francesco la Torre ::." References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> In-Reply-To: <1203436585.5603.5.camel@frankernet-iit-cnr> X-OriginalArrivalTime: 19 Feb 2008 16:04:38.0085 (UTC) FILETIME=[20BB6750:01C87311] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Mayumi Munakata , sip@ietf.org Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org .:: Francesco la Torre ::. wrote: > According some general privacy considerations, from an authentication > service's point of view, an anonymous may be a known user in his domain > that he has authenticated, but he's keeping its identity private. > Nothing strange. Fine. But what value does that bring to the recipient, compared to no authenticated identity at all? Paul > Francesco la Torre > > IIT-National Council Research > Security Session > Pisa, Italy > > Il giorno mar, 19/02/2008 alle 10.37 -0500, Paul Kyzivat ha scritto: >> Why would you want sip-identity for an anonymous From address? >> >> IMO it is perfectly fine to provide an address with no identity. >> >> Paul >> >> Mayumi Munakata wrote: >>> All; >>> >>> I have just submitted a new version of ua-privacy draft. >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-01.txt >>> >>> Thanks to John Elwell for his comprehensive review, >>> we managed to make a lot of editorial corrections >>> and some technical. >>> >>> One profound open issue we have is on how to get an >>> anonymous URI for a From header. While we can use a >>> temp-gruu for a Contact header, there is no mechanism >>> to obtain a functional anonymous URI for the From >>> header or any other headers that houses URIs. >>> >>> RFC3323 recommends to use "anonymous@anonymous.invalid" >>> for an anonymous URI in a From header. However, this >>> impedes the use of SIP-Identity, as SIP-Identity >>> mandates the domain portion of the "From" URI and >>> that of "Identity-Info" to match. >>> >>> One of the expired draft written by Jonathan, attempted >>> to use the GRUU to get this functional yet anonymous URI >>> to address this issue. >>> http://ietfreport.isoc.org/idref/draft-rosenberg-sip-identity-privacy/ >>> >>> I can see few ways forward. >>> >>> 1. Suggest the use of anonymous@{user's domain name}, which >>> verifier then can verify the signature's validity as >>> domain portion of the URI and that of Identity-Info matches. >>> >> If SIP-Identity is used, the domain is given away anyhow >>> in the Identity-Info, so what is the point of hiding the >>> domain in the From header? >>> >>> 2. Make a note that SIP-Identity will not function when >>> anonymous@anonymous.invalid is used. >>> >> Describe the caveat that verifier is likely to fail the >>> request or suggest that Authentication Service does not >>> add Identity-Info/signature. >>> >>> 3. Extend GRUU to support mechanism that Rosenberg suggested. >>> >>> Does anybody has any preferences or any other suggestions? >>> >>> Regards, >>> Mayumi >>> >>> _______________________________________________ >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 08:22:23 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B87E28C671; Tue, 19 Feb 2008 08:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDFKFYp4CI4V; Tue, 19 Feb 2008 08:22:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BECC28C5D9; Tue, 19 Feb 2008 08:22:22 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0E428C671 for ; Tue, 19 Feb 2008 08:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm42Pspb1QSl for ; Tue, 19 Feb 2008 08:22:18 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 363CD28C57F for ; Tue, 19 Feb 2008 08:22:18 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1JGLAs1018132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2008 08:21:14 -0800 From: "Richard Shockey" To: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> In-Reply-To: <47BAFA7E.6060006@gmx.net> Date: Tue, 19 Feb 2008 11:19:54 -0500 Message-ID: <0ccf01c87313$4613e160$d23ba420$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchzDud0ZmsZPdg0TyK7X2RLoduKpwAAmO/w Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'IETF SIP List' , paf@cisco.com Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is not to say that the IETF could play a useful and essential role. We can certainly develop and define the requirements, use cases etc. In addition the IETF can architect a solution but experience tells me that deployment and implementation issues surrounding e164 issues will need the cooperation of "other bodies" which is where the problem lies. It's not really the ITU, in fact the ITU is a much easier place to get things done these days. The complications arise with the ITU member states, who jealously guard their diplomatic and political prerogatives. This was the conclusion that we drew when the Infrastructure ENUM issues first arose. We essentially said ..."Here is this problem, this is what we (IETF) think, the solution is in your court. Have a nice day." > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, February 19, 2008 10:49 AM > To: Richard Shockey > Cc: 'IETF SIP List'; paf@cisco.com > Subject: Re: Infrastructure issues involving e164 numbers > > > > If there is going to be a solution to the SIP identity problem > involving > > e164 numbers, it will not IMHO be solved in the IETF. > > > > > Interesting view. I obviously does not appear to be an easy thing; > in the draft I called this "There is non-neglectable deployment > incentive challenge." _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 08:32:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E74628C6AC; Tue, 19 Feb 2008 08:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-2.212, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP2xkb0dIE4q; Tue, 19 Feb 2008 08:32:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3F83A6A8C; Tue, 19 Feb 2008 08:32:43 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A3F3A6DF5 for ; Tue, 19 Feb 2008 08:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaX7AWOBo3mY for ; Tue, 19 Feb 2008 08:32:41 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B538028C685 for ; Tue, 19 Feb 2008 08:31:50 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2008 11:31:48 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1JGVlrc023300; Tue, 19 Feb 2008 11:31:47 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1JGVjWH023708; Tue, 19 Feb 2008 16:31:47 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 11:31:39 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 11:31:38 -0500 Message-ID: <47BB0476.1030902@cisco.com> Date: Tue, 19 Feb 2008 11:31:50 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Richard Shockey References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> In-Reply-To: <0ccf01c87313$4613e160$d23ba420$@us> X-OriginalArrivalTime: 19 Feb 2008 16:31:38.0608 (UTC) FILETIME=[E6A39700:01C87314] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'IETF SIP List' , paf@cisco.com Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, maybe that is what is needed. If there is to be anything approaching reliable callerid then there needs to be *something* that is directly tied to the "ownership" of E.164 numbers. Paul Richard Shockey wrote: > This is not to say that the IETF could play a useful and essential role. We > can certainly develop and define the requirements, use cases etc. > > In addition the IETF can architect a solution but experience tells me that > deployment and implementation issues surrounding e164 issues will need the > cooperation of "other bodies" which is where the problem lies. It's not > really the ITU, in fact the ITU is a much easier place to get things done > these days. The complications arise with the ITU member states, who > jealously guard their diplomatic and political prerogatives. > > This was the conclusion that we drew when the Infrastructure ENUM issues > first arose. We essentially said ..."Here is this problem, this is what we > (IETF) think, the solution is in your court. Have a nice day." > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, February 19, 2008 10:49 AM >> To: Richard Shockey >> Cc: 'IETF SIP List'; paf@cisco.com >> Subject: Re: Infrastructure issues involving e164 numbers >> >> >> > If there is going to be a solution to the SIP identity problem >> involving >> > e164 numbers, it will not IMHO be solved in the IETF. >> > >> > >> Interesting view. I obviously does not appear to be an easy thing; >> in the draft I called this "There is non-neglectable deployment >> incentive challenge." > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 08:34:40 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA6728C690; Tue, 19 Feb 2008 08:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64V2KFmqFS5b; Tue, 19 Feb 2008 08:34:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869423A6A93; Tue, 19 Feb 2008 08:34:39 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44F73A6A93 for ; Tue, 19 Feb 2008 08:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNy-phYg8mIk for ; Tue, 19 Feb 2008 08:34:37 -0800 (PST) Received: from smtp.cnr.it (unknown [IPv6:2001:760:4000:60:202:55ff:fe9d:132f]) by core3.amsl.com (Postfix) with ESMTP id BB18A3A6821 for ; Tue, 19 Feb 2008 08:34:36 -0800 (PST) Received: by smtp.cnr.it (Postfix, from userid 1000) id F38BEAC0BB; Tue, 19 Feb 2008 17:34:22 +0100 (CET) From: ".:: Francesco la Torre ::." To: Paul Kyzivat In-Reply-To: <47BAFE21.3010207@cisco.com> References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> Date: Tue, 19 Feb 2008 17:34:22 +0100 Message-Id: <1203438862.5603.23.camel@frankernet-iit-cnr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Cc: Mayumi Munakata , sip@ietf.org Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org IMO authenticated but private is something more then not authenticated. In first case, you know that on the other end there is an authenticated user for that domain, in the second one there is a complete lack of identity ... this entails that there is no reasons why sip uri (e.g. anonimous@pippo.org) cannot be signed by authentication service. This uri may be used for special scenarios generating the value you are looking for. Francesco la Torre IIT-National Research Counsil Security Session Pisa, Italy Il giorno mar, 19/02/2008 alle 11.04 -0500, Paul Kyzivat ha scritto: > > .:: Francesco la Torre ::. wrote: > > According some general privacy considerations, from an authentication > > service's point of view, an anonymous may be a known user in his domain > > that he has authenticated, but he's keeping its identity private. > > Nothing strange. > > Fine. But what value does that bring to the recipient, compared to no > authenticated identity at all? > > Paul > > > Francesco la Torre > > > > IIT-National Council Research > > Security Session > > Pisa, Italy > > > > Il giorno mar, 19/02/2008 alle 10.37 -0500, Paul Kyzivat ha scritto: > >> Why would you want sip-identity for an anonymous From address? > >> > >> IMO it is perfectly fine to provide an address with no identity. > >> > >> Paul > >> > >> Mayumi Munakata wrote: > >>> All; > >>> > >>> I have just submitted a new version of ua-privacy draft. > >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-01.txt > >>> > >>> Thanks to John Elwell for his comprehensive review, > >>> we managed to make a lot of editorial corrections > >>> and some technical. > >>> > >>> One profound open issue we have is on how to get an > >>> anonymous URI for a From header. While we can use a > >>> temp-gruu for a Contact header, there is no mechanism > >>> to obtain a functional anonymous URI for the From > >>> header or any other headers that houses URIs. > >>> > >>> RFC3323 recommends to use "anonymous@anonymous.invalid" > >>> for an anonymous URI in a From header. However, this > >>> impedes the use of SIP-Identity, as SIP-Identity > >>> mandates the domain portion of the "From" URI and > >>> that of "Identity-Info" to match. > >>> > >>> One of the expired draft written by Jonathan, attempted > >>> to use the GRUU to get this functional yet anonymous URI > >>> to address this issue. > >>> http://ietfreport.isoc.org/idref/draft-rosenberg-sip-identity-privacy/ > >>> > >>> I can see few ways forward. > >>> > >>> 1. Suggest the use of anonymous@{user's domain name}, which > >>> verifier then can verify the signature's validity as > >>> domain portion of the URI and that of Identity-Info matches. > >>> >> If SIP-Identity is used, the domain is given away anyhow > >>> in the Identity-Info, so what is the point of hiding the > >>> domain in the From header? > >>> > >>> 2. Make a note that SIP-Identity will not function when > >>> anonymous@anonymous.invalid is used. > >>> >> Describe the caveat that verifier is likely to fail the > >>> request or suggest that Authentication Service does not > >>> add Identity-Info/signature. > >>> > >>> 3. Extend GRUU to support mechanism that Rosenberg suggested. > >>> > >>> Does anybody has any preferences or any other suggestions? > >>> > >>> Regards, > >>> Mayumi > >>> > >>> _______________________________________________ > >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the application of sip > >>> > >> _______________________________________________ > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 10:04:19 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CCE28C680; Tue, 19 Feb 2008 10:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hojkak0jukc; Tue, 19 Feb 2008 10:04:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD4C3A6AF3; Tue, 19 Feb 2008 10:04:18 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7951328C519 for ; Tue, 19 Feb 2008 10:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQIB74AnWT-X for ; Tue, 19 Feb 2008 10:04:16 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8AE2A3A689A for ; Tue, 19 Feb 2008 10:04:16 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2008 10:04:14 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1JI4DHC030512; Tue, 19 Feb 2008 10:04:13 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1JI4CJg016209; Tue, 19 Feb 2008 18:04:13 GMT From: "Dan Wing" To: "'Richard Shockey'" , , "'IETF SIP List'" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us><47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> Date: Tue, 19 Feb 2008 10:04:12 -0800 Message-ID: <072801c87321$d5c8f0d0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <0b6a01c8730c$eea1c4c0$cbe54e40$@us> Thread-Index: AchyyHTh32FeBaGQTsWEZvLx+Xi4KAAQakRwAAXTKPA= Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: paf@cisco.com Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Richard Shockey wrote: > If there is going to be a solution to the SIP identity > problem involving e164 numbers, it will not IMHO be > solved in the IETF. Please do not assume that the only path to E.164 enlightenment is ENUM. I have one proposal on the table, draft-wing-sip-e164-rrc, which does not use ENUM. My proposal may not be perfect, but it does not use ENUM. -d _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 10:14:49 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32A228C646; Tue, 19 Feb 2008 10:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-1.542, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIRojsQiU3G3; Tue, 19 Feb 2008 10:14:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D7928C5AD; Tue, 19 Feb 2008 10:14:48 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082E43A6B0B for ; Tue, 19 Feb 2008 10:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6TdgI2SRBBe for ; Tue, 19 Feb 2008 10:14:46 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B186F3A692B for ; Tue, 19 Feb 2008 10:14:45 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2008 13:14:43 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1JIEh7H019041; Tue, 19 Feb 2008 13:14:43 -0500 Received: from dhcp-161-44-173-134.cisco.com (dhcp-161-44-173-134.cisco.com [161.44.173.134]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1JIEgSC011471; Tue, 19 Feb 2008 18:14:42 GMT Message-Id: <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> From: David R Oran To: ".:: Francesco la Torre ::." In-Reply-To: <1203438862.5603.23.camel@frankernet-iit-cnr> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 19 Feb 2008 13:14:42 -0500 References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> X-Mailer: Apple Mail (2.919.2) Authentication-Results: rtp-dkim-2; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Mayumi Munakata , sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 19, 2008, at 11:34 AM, .:: Francesco la Torre ::. wrote: > IMO authenticated but private is something more then not > authenticated. > In first case, you know that on the other end there is an > authenticated > user for that domain, in the second one there is a complete lack of > identity ... this entails that there is no reasons why sip uri (e.g. > anonimous@pippo.org) cannot be signed by authentication service. > Of what value to a recipient is an authenticated From:anonymous@chaos-computer-club.org ? Or a phished anonymous@bank0fAmerica.com? In the absence of a reputation service and separate authentication of the source domain I don't see any at all. What are your assumed preconditions for this authentication to have value? These need explicit statement. > This uri may be used for special scenarios generating the value you > are > looking for. > > Francesco la Torre > > IIT-National Research Counsil > Security Session > Pisa, Italy > > Il giorno mar, 19/02/2008 alle 11.04 -0500, Paul Kyzivat ha scritto: >> >> .:: Francesco la Torre ::. wrote: >>> According some general privacy considerations, from an >>> authentication >>> service's point of view, an anonymous may be a known user in his >>> domain >>> that he has authenticated, but he's keeping its identity private. >>> Nothing strange. >> >> Fine. But what value does that bring to the recipient, compared to no >> authenticated identity at all? >> >> Paul >> >>> Francesco la Torre >>> >>> IIT-National Council Research >>> Security Session >>> Pisa, Italy >>> >>> Il giorno mar, 19/02/2008 alle 10.37 -0500, Paul Kyzivat ha scritto: >>>> Why would you want sip-identity for an anonymous From address? >>>> >>>> IMO it is perfectly fine to provide an address with no identity. >>>> >>>> Paul >>>> >>>> Mayumi Munakata wrote: >>>>> All; >>>>> >>>>> I have just submitted a new version of ua-privacy draft. >>>>> http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-01.txt >>>>> >>>>> Thanks to John Elwell for his comprehensive review, >>>>> we managed to make a lot of editorial corrections >>>>> and some technical. >>>>> >>>>> One profound open issue we have is on how to get an >>>>> anonymous URI for a From header. While we can use a >>>>> temp-gruu for a Contact header, there is no mechanism >>>>> to obtain a functional anonymous URI for the From >>>>> header or any other headers that houses URIs. >>>>> >>>>> RFC3323 recommends to use "anonymous@anonymous.invalid" >>>>> for an anonymous URI in a From header. However, this >>>>> impedes the use of SIP-Identity, as SIP-Identity >>>>> mandates the domain portion of the "From" URI and >>>>> that of "Identity-Info" to match. >>>>> >>>>> One of the expired draft written by Jonathan, attempted >>>>> to use the GRUU to get this functional yet anonymous URI >>>>> to address this issue. >>>>> http://ietfreport.isoc.org/idref/draft-rosenberg-sip-identity-privacy/ >>>>> >>>>> I can see few ways forward. >>>>> >>>>> 1. Suggest the use of anonymous@{user's domain name}, which >>>>> verifier then can verify the signature's validity as >>>>> domain portion of the URI and that of Identity-Info matches. >>>>>>> If SIP-Identity is used, the domain is given away anyhow >>>>> in the Identity-Info, so what is the point of hiding the >>>>> domain in the From header? >>>>> >>>>> 2. Make a note that SIP-Identity will not function when >>>>> anonymous@anonymous.invalid is used. >>>>>>> Describe the caveat that verifier is likely to fail the >>>>> request or suggest that Authentication Service does not >>>>> add Identity-Info/signature. >>>>> >>>>> 3. Extend GRUU to support mechanism that Rosenberg suggested. >>>>> >>>>> Does anybody has any preferences or any other suggestions? >>>>> >>>>> Regards, >>>>> Mayumi >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the application of >>>>> sip >>>>> >>>> _______________________________________________ >>>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 10:19:12 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9524128C682; Tue, 19 Feb 2008 10:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXE6U0yLLyK6; Tue, 19 Feb 2008 10:19:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA973A689A; Tue, 19 Feb 2008 10:19:11 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EAD428C3C4 for ; Tue, 19 Feb 2008 10:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RkfPAXOWAVh for ; Tue, 19 Feb 2008 10:19:09 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EBD9A3A692B for ; Tue, 19 Feb 2008 10:19:08 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2008 18:19:05 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp038) with SMTP; 19 Feb 2008 19:19:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/B72AwDHHBu7edJgwfQv/gRJcV0ZxtB02Ivv/RFJ Ps9YQLc2ecQUiM Message-ID: <47BB1D98.2010804@gmx.net> Date: Tue, 19 Feb 2008 20:19:04 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dan Wing References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us><47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <072801c87321$d5c8f0d0$c4f0200a@cisco.com> In-Reply-To: <072801c87321$d5c8f0d0$c4f0200a@cisco.com> X-Y-GMX-Trusted: 0 Cc: 'IETF SIP List' , paf@cisco.com, 'Richard Shockey' Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org True. There are other solution approaches that have a different ownership criteria. draft-wing-sip-e164-rrc, for example, performs a return routability test. Dan Wing wrote: > > > Richard Shockey wrote: > > >> If there is going to be a solution to the SIP identity >> problem involving e164 numbers, it will not IMHO be >> solved in the IETF. >> > > Please do not assume that the only path to E.164 enlightenment is > ENUM. > > I have one proposal on the table, draft-wing-sip-e164-rrc, which > does not use ENUM. My proposal may not be perfect, but it does > not use ENUM. > > -d > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 10:50:39 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2947728C6A4; Tue, 19 Feb 2008 10:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=-1.319, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juELzmoz9KDz; Tue, 19 Feb 2008 10:50:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC4928C5F4; Tue, 19 Feb 2008 10:50:38 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FD928C602 for ; Tue, 19 Feb 2008 10:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUGs1u6wjsj8 for ; Tue, 19 Feb 2008 10:50:36 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 044F828C653 for ; Tue, 19 Feb 2008 10:50:35 -0800 (PST) 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 m1JIoOf13771; Tue, 19 Feb 2008 18:50:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 12:50:10 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> In-Reply-To: <47B9DE39.60608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyZuxYK8QRbUyDQt6PIDy0tZI7rgAwFqCQ References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , "Paul Kyzivat" Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Another "solution" is to not do it. By that I mean, use RFC 4474 for domain-based security, and if you = insist on using phone numbers, then it's not "secured that way". Before the flaming start: by definition, if something is addressed by a pho= ne number, it is something that is likely to be reacheable through the PSTN. The way security works in the PSTN is completely different. The media is al= most never encrypted for one. So in the context of SIP, it means there is a gate= way = somewhere destroying the end-to-end nature of the encryption. Even for the Identity, it's different. For one thing, the Identity assertion is not end-to-end =E0-la-RFC 4474. So, I'm proposing that if you are using phone numbers as your identity, then it is not a design requirement of this group to re-invent a "better" identi= ty security system for the PSTN. It's not because something is a problem that it necessarily needs to be sol= ved. My 2 cents. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = > Behalf Of Jonathan Rosenberg > Sent: Monday, February 18, 2008 11:36 > To: Paul Kyzivat > Cc: IETF SIP List > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > = > I agree that something along the lines of enum could solve = > this problem, and I believe there was a draft that proposed = > such a thing. This has been discussed since the start of rfc4474. > = > However, I fear that saying, 'use enum' is kind of like = > saying, we'll just use an All-Knowing Oracle, so lets figure = > out the interface protocol to the Oracle. The easy part is = > the interface (the enum mechanism). The actual hard problem = > is how to get those entries populated. The deployment of = > public enum has been - shall we say - less than spectacular. = > I'd hate for that to be our only solution. Not that its = > obvious what else to do; though I do suggest in my draft how = > domain based authentication, when combined with whitelists = > and blacklists, can help. > = > -Jonathan R. > = > Paul Kyzivat wrote: > > Jonathan, > > = > > I guess the time has come for this discussion, since John Ewell has = > > also submitted a draft on this subject. > > = > > I thought the problem was already well known, but perhaps = > not. IMO the = > > main thing now is to figure out the *solution* to the problem! > > IMO a solution is to use a 4474-style approach, but where the = > > certificate is tied to just the phone number, not to some arbitrary = > > domain name. That of course would depend on a model where = > the "owner" = > > of the phone number is the one who may obtain the = > certificate for that number. > > = > > My thought is that we already have an algorithmic mapping from an = > > E.164 phone number to a domain name, defined by enum. If the sender = > > puts an > > E.164 number in From, and can sign it with a cert for the = > enum mapped = > > domain name corresponding to that number, then that ought = > to be valid = > > proof of the validity of the sender. > > = > > In those places where public enum is in operation, I think there is = > > already a legal mechanism in place to give the owner of record of a = > > particular phone number control over the contents of the = > corresponding = > > DNS entry. That should also be sufficient to allow a certificate = > > authority to assign a cert to that same owner. > > = > > Combine all that and you have a complete e2e identity model = > for phone = > > numbers, based on public enum. And that can be true even if public = > > enum isn't used to *route* the calls to that number. So it could be = > > used for "unlisted" numbers. > > = > > To use this approach the From header should contain either = > a TEL URI, = > > or a sip/sips URI containing the enum-mapped domain name = > corresponding = > > to the phone number. (I would rather see the TEL used for = > this - it is = > > more user friendly.) > > = > > Thanks, > > Paul > > = > > Jonathan Rosenberg wrote: > >> I just submitted: > >> = > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-conce > >> rns-00.txt > >> > >> > >> This is basically a discussion on the security properties = > of rfc4474 = > >> with phone numbers, and a comparison to rfc3325 in this = > case. Also a = > >> discussion on what happens to dtls-srtp. > >> > >> Comments welcome. > >> > >> -Jonathan R. > > = > = > -- = > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip = > Use sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 11:12:59 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BEC28C6BD; Tue, 19 Feb 2008 11:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z2grkiYIBKZ; Tue, 19 Feb 2008 11:12:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0A73A6A58; Tue, 19 Feb 2008 11:12:55 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA9C3A6A58 for ; Tue, 19 Feb 2008 11:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxI0JwnLLbZD for ; Tue, 19 Feb 2008 11:12:52 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 6FE213A692B for ; Tue, 19 Feb 2008 11:12:52 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1JJBc1r012809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2008 11:11:40 -0800 From: "Richard Shockey" To: "'Dan Wing'" , , "'IETF SIP List'" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us><47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <072801c87321$d5c8f0d0$c4f0200a@cisco.com> In-Reply-To: <072801c87321$d5c8f0d0$c4f0200a@cisco.com> Date: Tue, 19 Feb 2008 14:10:22 -0500 Message-ID: <0fe501c8732b$14e2e060$3ea8a120$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchyyHTh32FeBaGQTsWEZvLx+Xi4KAAQakRwAAXTKPAAAlm3MA== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: paf@cisco.com Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Oh of course, but you would not get an argument from me if you asserted that sure the path to damnation is through ENUM. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, February 19, 2008 1:04 PM > To: 'Richard Shockey'; Hannes.Tschofenig@gmx.net; 'IETF SIP List' > Cc: paf@cisco.com > Subject: RE: [Sip] Infrastructure issues involving e164 numbers > > > > Richard Shockey wrote: > > > If there is going to be a solution to the SIP identity > > problem involving e164 numbers, it will not IMHO be > > solved in the IETF. > > Please do not assume that the only path to E.164 enlightenment is > ENUM. > > I have one proposal on the table, draft-wing-sip-e164-rrc, which > does not use ENUM. My proposal may not be perfect, but it does > not use ENUM. > > -d _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 11:18:56 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23973A6B6A; Tue, 19 Feb 2008 11:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA3hi3MpiKQx; Tue, 19 Feb 2008 11:18:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED3A3A6A58; Tue, 19 Feb 2008 11:18:55 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C5D3A6B20 for ; Tue, 19 Feb 2008 11:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S3o7hR-QTW9 for ; Tue, 19 Feb 2008 11:18:52 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4721E3A679C for ; Tue, 19 Feb 2008 11:18:52 -0800 (PST) Received: from 71-81-78-129.dhcp.stls.mo.charter.com ([71.81.78.129] helo=alan-johnstons-powerbook-g4-17.local) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JRXzL-000HUh-Gc; Tue, 19 Feb 2008 19:18:47 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.81.78.129 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+n9sqoZFKgcOzUM7s0spgJtt6ageytIRk= Message-ID: <47BB2B96.2020205@sipstation.com> Date: Tue, 19 Feb 2008 13:18:46 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Francois Audet References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> Cc: IETF SIP List , Paul Kyzivat Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Couldn't have put it better myself. +1 Thanks, Alan Francois Audet wrote: > Another "solution" is to not do it. > > By that I mean, use RFC 4474 for domain-based security, and if you = > insist on using phone numbers, then it's not "secured that way". > > Before the flaming start: by definition, if something is addressed by a p= hone > number, it is something that is likely to be reacheable through the PSTN. > > The way security works in the PSTN is completely different. The media is = almost > never encrypted for one. So in the context of SIP, it means there is a ga= teway = > somewhere destroying the end-to-end nature of the encryption. > > Even for the Identity, it's different. For one thing, the Identity assert= ion > is not end-to-end =E0-la-RFC 4474. > > So, I'm proposing that if you are using phone numbers as your identity, t= hen > it is not a design requirement of this group to re-invent a "better" iden= tity > security system for the PSTN. > > It's not because something is a problem that it necessarily needs to be s= olved. > > My 2 cents. > > = >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = >> Behalf Of Jonathan Rosenberg >> Sent: Monday, February 18, 2008 11:36 >> To: Paul Kyzivat >> Cc: IETF SIP List >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >> >> I agree that something along the lines of enum could solve = >> this problem, and I believe there was a draft that proposed = >> such a thing. This has been discussed since the start of rfc4474. >> >> However, I fear that saying, 'use enum' is kind of like = >> saying, we'll just use an All-Knowing Oracle, so lets figure = >> out the interface protocol to the Oracle. The easy part is = >> the interface (the enum mechanism). The actual hard problem = >> is how to get those entries populated. The deployment of = >> public enum has been - shall we say - less than spectacular. = >> I'd hate for that to be our only solution. Not that its = >> obvious what else to do; though I do suggest in my draft how = >> domain based authentication, when combined with whitelists = >> and blacklists, can help. >> >> -Jonathan R. >> >> Paul Kyzivat wrote: >> = >>> Jonathan, >>> >>> I guess the time has come for this discussion, since John Ewell has = >>> also submitted a draft on this subject. >>> >>> I thought the problem was already well known, but perhaps = >>> = >> not. IMO the = >> = >>> main thing now is to figure out the *solution* to the problem! >>> IMO a solution is to use a 4474-style approach, but where the = >>> certificate is tied to just the phone number, not to some arbitrary = >>> domain name. That of course would depend on a model where = >>> = >> the "owner" = >> = >>> of the phone number is the one who may obtain the = >>> = >> certificate for that number. >> = >>> My thought is that we already have an algorithmic mapping from an = >>> E.164 phone number to a domain name, defined by enum. If the sender = >>> puts an >>> E.164 number in From, and can sign it with a cert for the = >>> = >> enum mapped = >> = >>> domain name corresponding to that number, then that ought = >>> = >> to be valid = >> = >>> proof of the validity of the sender. >>> >>> In those places where public enum is in operation, I think there is = >>> already a legal mechanism in place to give the owner of record of a = >>> particular phone number control over the contents of the = >>> = >> corresponding = >> = >>> DNS entry. That should also be sufficient to allow a certificate = >>> authority to assign a cert to that same owner. >>> >>> Combine all that and you have a complete e2e identity model = >>> = >> for phone = >> = >>> numbers, based on public enum. And that can be true even if public = >>> enum isn't used to *route* the calls to that number. So it could be = >>> used for "unlisted" numbers. >>> >>> To use this approach the From header should contain either = >>> = >> a TEL URI, = >> = >>> or a sip/sips URI containing the enum-mapped domain name = >>> = >> corresponding = >> = >>> to the phone number. (I would rather see the TEL used for = >>> = >> this - it is = >> = >>> more user friendly.) >>> >>> Thanks, >>> Paul >>> >>> Jonathan Rosenberg wrote: >>> = >>>> I just submitted: >>>> >>>> = >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-conce >> = >>>> rns-00.txt >>>> >>>> >>>> This is basically a discussion on the security properties = >>>> = >> of rfc4474 = >> = >>>> with phone numbers, and a comparison to rfc3325 in this = >>>> = >> case. Also a = >> = >>>> discussion on what happens to dtls-srtp. >>>> >>>> Comments welcome. >>>> >>>> -Jonathan R. >>>> = >> -- = >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >> Cisco Fellow Edison, NJ 08837 >> Cisco, Voice Technology Group >> jdrosen@cisco.com >> http://www.jdrosen.net PHONE: (408) 902-3084 >> http://www.cisco.com >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip = >> Use sipping@ietf.org for new developments on the application of sip >> >> = > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > = _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 11:24:40 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52AD3A6E0B; Tue, 19 Feb 2008 11:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-2.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQLT3orTqnuX; Tue, 19 Feb 2008 11:24:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505353A6B6B; Tue, 19 Feb 2008 11:24:39 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7F43A6B22 for ; Tue, 19 Feb 2008 11:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KjR0OGrkYvr for ; Tue, 19 Feb 2008 11:24:36 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3C2DC3A6B6B for ; Tue, 19 Feb 2008 11:24:36 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2008 14:24:33 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1JJOX7M021312; Tue, 19 Feb 2008 14:24:33 -0500 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 m1JJOSSI012208; Tue, 19 Feb 2008 19:24:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 14:24:28 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 14:24:27 -0500 Message-ID: <47BB2CF7.3090407@cisco.com> Date: Tue, 19 Feb 2008 14:24:39 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Francois Audet References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 19 Feb 2008 19:24:27.0928 (UTC) FILETIME=[0B3C4180:01C8732D] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think we don't need something *better* than the PSTN, though that = would be nice. What I think we need is something that is *not worse* = than the PSTN. The problem is defining what that means. I think that means at least: - when you connect via sip you get a callerid for at least those pstn callers where you would have gotten one if you had a pstn phone *and* that callerid was "correct". - callerid is available to callees from sip callers with E.164 AORs when it hasn't been intentionally blocked and the caller is the legitimate "owner" of the number. - the frequency with which "incorrect" (spoofed) callerid is delivered to callees is no worse, on average, than with pure pstn calls. I realize this are a bit vague and hard to measure. But I think this is = subjectively what will be required for sip to be widely accepted as a = substitute for pstn phone service. Paul Francois Audet wrote: > Another "solution" is to not do it. > = > By that I mean, use RFC 4474 for domain-based security, and if you = > insist on using phone numbers, then it's not "secured that way". > = > Before the flaming start: by definition, if something is addressed by a p= hone > number, it is something that is likely to be reacheable through the PSTN. > = > The way security works in the PSTN is completely different. The media is = almost > never encrypted for one. So in the context of SIP, it means there is a ga= teway = > somewhere destroying the end-to-end nature of the encryption. > = > Even for the Identity, it's different. For one thing, the Identity assert= ion > is not end-to-end =E0-la-RFC 4474. > = > So, I'm proposing that if you are using phone numbers as your identity, t= hen > it is not a design requirement of this group to re-invent a "better" iden= tity > security system for the PSTN. > = > It's not because something is a problem that it necessarily needs to be s= olved. > = > My 2 cents. > = >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = >> Behalf Of Jonathan Rosenberg >> Sent: Monday, February 18, 2008 11:36 >> To: Paul Kyzivat >> Cc: IETF SIP List >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >> >> I agree that something along the lines of enum could solve = >> this problem, and I believe there was a draft that proposed = >> such a thing. This has been discussed since the start of rfc4474. >> >> However, I fear that saying, 'use enum' is kind of like = >> saying, we'll just use an All-Knowing Oracle, so lets figure = >> out the interface protocol to the Oracle. The easy part is = >> the interface (the enum mechanism). The actual hard problem = >> is how to get those entries populated. The deployment of = >> public enum has been - shall we say - less than spectacular. = >> I'd hate for that to be our only solution. Not that its = >> obvious what else to do; though I do suggest in my draft how = >> domain based authentication, when combined with whitelists = >> and blacklists, can help. >> >> -Jonathan R. >> >> Paul Kyzivat wrote: >>> Jonathan, >>> >>> I guess the time has come for this discussion, since John Ewell has = >>> also submitted a draft on this subject. >>> >>> I thought the problem was already well known, but perhaps = >> not. IMO the = >>> main thing now is to figure out the *solution* to the problem! >>> IMO a solution is to use a 4474-style approach, but where the = >>> certificate is tied to just the phone number, not to some arbitrary = >>> domain name. That of course would depend on a model where = >> the "owner" = >>> of the phone number is the one who may obtain the = >> certificate for that number. >>> My thought is that we already have an algorithmic mapping from an = >>> E.164 phone number to a domain name, defined by enum. If the sender = >>> puts an >>> E.164 number in From, and can sign it with a cert for the = >> enum mapped = >>> domain name corresponding to that number, then that ought = >> to be valid = >>> proof of the validity of the sender. >>> >>> In those places where public enum is in operation, I think there is = >>> already a legal mechanism in place to give the owner of record of a = >>> particular phone number control over the contents of the = >> corresponding = >>> DNS entry. That should also be sufficient to allow a certificate = >>> authority to assign a cert to that same owner. >>> >>> Combine all that and you have a complete e2e identity model = >> for phone = >>> numbers, based on public enum. And that can be true even if public = >>> enum isn't used to *route* the calls to that number. So it could be = >>> used for "unlisted" numbers. >>> >>> To use this approach the From header should contain either = >> a TEL URI, = >>> or a sip/sips URI containing the enum-mapped domain name = >> corresponding = >>> to the phone number. (I would rather see the TEL used for = >> this - it is = >>> more user friendly.) >>> >>> Thanks, >>> Paul >>> >>> Jonathan Rosenberg wrote: >>>> I just submitted: >>>> >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-conce >>>> rns-00.txt >>>> >>>> >>>> This is basically a discussion on the security properties = >> of rfc4474 = >>>> with phone numbers, and a comparison to rfc3325 in this = >> case. Also a = >>>> discussion on what happens to dtls-srtp. >>>> >>>> Comments welcome. >>>> >>>> -Jonathan R. >> -- = >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >> Cisco Fellow Edison, NJ 08837 >> Cisco, Voice Technology Group >> jdrosen@cisco.com >> http://www.jdrosen.net PHONE: (408) 902-3084 >> http://www.cisco.com >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use = >> sip-implementors@cs.columbia.edu for questions on current sip = >> Use sipping@ietf.org for new developments on the application of sip >> > = _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 11:43:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8993A6B40; Tue, 19 Feb 2008 11:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh7yEndVtgbf; Tue, 19 Feb 2008 11:43:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D02D3A6A8C; Tue, 19 Feb 2008 11:43:52 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6FD3A6887 for ; Tue, 19 Feb 2008 11:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MnMosXQ5hNa for ; Tue, 19 Feb 2008 11:43:50 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id AE6853A6AD8 for ; Tue, 19 Feb 2008 11:43:49 -0800 (PST) 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 m1JJhgf22171; Tue, 19 Feb 2008 19:43:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 13:43:41 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> In-Reply-To: <47BB2CF7.3090407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchzLRUYuzuveP7HRqeVwI+y3YEwtAAAnbVQ References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm not sure I agree with that. I think we want something that is better than the PSTN. I just don't think = it's the right question to ask. And specifically, I don't think "identity" for PSTN numbers should be our m= andate. = > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] = > Sent: Tuesday, February 19, 2008 11:25 > To: Audet, Francois (SC100:3055) > Cc: Jonathan Rosenberg; IETF SIP List > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > = > I think we don't need something *better* than the PSTN, = > though that would be nice. What I think we need is something = > that is *not worse* than the PSTN. The problem is defining = > what that means. > = > I think that means at least: > = > - when you connect via sip you get a callerid for at least those > pstn callers where you would have gotten one if you had a = > pstn phone > *and* that callerid was "correct". > = > - callerid is available to callees from sip callers with E.164 AORs > when it hasn't been intentionally blocked and the caller is the > legitimate "owner" of the number. > = > - the frequency with which "incorrect" (spoofed) callerid is delivered > to callees is no worse, on average, than with pure pstn calls. > = > I realize this are a bit vague and hard to measure. But I = > think this is subjectively what will be required for sip to = > be widely accepted as a substitute for pstn phone service. > = > Paul > = > Francois Audet wrote: > > Another "solution" is to not do it. > > = > > By that I mean, use RFC 4474 for domain-based security, and if you = > > insist on using phone numbers, then it's not "secured that way". > > = > > Before the flaming start: by definition, if something is = > addressed by = > > a phone number, it is something that is likely to be = > reacheable through the PSTN. > > = > > The way security works in the PSTN is completely different. = > The media = > > is almost never encrypted for one. So in the context of = > SIP, it means = > > there is a gateway somewhere destroying the end-to-end = > nature of the encryption. > > = > > Even for the Identity, it's different. For one thing, the Identity = > > assertion is not end-to-end =E0-la-RFC 4474. > > = > > So, I'm proposing that if you are using phone numbers as your = > > identity, then it is not a design requirement of this group to = > > re-invent a "better" identity security system for the PSTN. > > = > > It's not because something is a problem that it necessarily = > needs to be solved. > > = > > My 2 cents. > > = > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = > On Behalf Of = > >> Jonathan Rosenberg > >> Sent: Monday, February 18, 2008 11:36 > >> To: Paul Kyzivat > >> Cc: IETF SIP List > >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > >> > >> I agree that something along the lines of enum could solve this = > >> problem, and I believe there was a draft that proposed = > such a thing. = > >> This has been discussed since the start of rfc4474. > >> > >> However, I fear that saying, 'use enum' is kind of like = > saying, we'll = > >> just use an All-Knowing Oracle, so lets figure out the interface = > >> protocol to the Oracle. The easy part is the interface (the enum = > >> mechanism). The actual hard problem is how to get those entries = > >> populated. The deployment of public enum has been - shall we say - = > >> less than spectacular. > >> I'd hate for that to be our only solution. Not that its = > obvious what = > >> else to do; though I do suggest in my draft how domain based = > >> authentication, when combined with whitelists and blacklists, can = > >> help. > >> > >> -Jonathan R. > >> > >> Paul Kyzivat wrote: > >>> Jonathan, > >>> > >>> I guess the time has come for this discussion, since John = > Ewell has = > >>> also submitted a draft on this subject. > >>> > >>> I thought the problem was already well known, but perhaps > >> not. IMO the > >>> main thing now is to figure out the *solution* to the problem! > >>> IMO a solution is to use a 4474-style approach, but where the = > >>> certificate is tied to just the phone number, not to some = > arbitrary = > >>> domain name. That of course would depend on a model where > >> the "owner" = > >>> of the phone number is the one who may obtain the > >> certificate for that number. > >>> My thought is that we already have an algorithmic mapping from an > >>> E.164 phone number to a domain name, defined by enum. If = > the sender = > >>> puts an > >>> E.164 number in From, and can sign it with a cert for the > >> enum mapped > >>> domain name corresponding to that number, then that ought > >> to be valid > >>> proof of the validity of the sender. > >>> > >>> In those places where public enum is in operation, I = > think there is = > >>> already a legal mechanism in place to give the owner of = > record of a = > >>> particular phone number control over the contents of the > >> corresponding > >>> DNS entry. That should also be sufficient to allow a certificate = > >>> authority to assign a cert to that same owner. > >>> > >>> Combine all that and you have a complete e2e identity model > >> for phone > >>> numbers, based on public enum. And that can be true even = > if public = > >>> enum isn't used to *route* the calls to that number. So = > it could be = > >>> used for "unlisted" numbers. > >>> > >>> To use this approach the From header should contain either > >> a TEL URI, > >>> or a sip/sips URI containing the enum-mapped domain name > >> corresponding > >>> to the phone number. (I would rather see the TEL used for > >> this - it is > >>> more user friendly.) > >>> > >>> Thanks, > >>> Paul > >>> > >>> Jonathan Rosenberg wrote: > >>>> I just submitted: > >>>> > >> = > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-conce > >>>> rns-00.txt > >>>> > >>>> > >>>> This is basically a discussion on the security properties > >> of rfc4474 > >>>> with phone numbers, and a comparison to rfc3325 in this > >> case. Also a > >>>> discussion on what happens to dtls-srtp. > >>>> > >>>> Comments welcome. > >>>> > >>>> -Jonathan R. > >> -- = > >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > >> Cisco Fellow Edison, NJ 08837 > >> Cisco, Voice Technology Group > >> jdrosen@cisco.com > >> http://www.jdrosen.net PHONE: = > (408) 902-3084 > >> http://www.cisco.com > >> _______________________________________________ > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use = > >> sip-implementors@cs.columbia.edu for questions on current sip Use = > >> sipping@ietf.org for new developments on the application of sip > >> > > = > = _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 11:50:31 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1191E28C600; Tue, 19 Feb 2008 11:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7YaWVkL7DVK; Tue, 19 Feb 2008 11:50:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49633A6B6B; Tue, 19 Feb 2008 11:50:29 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC433A6B12 for ; Tue, 19 Feb 2008 11:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG8jG65MQF2J for ; Tue, 19 Feb 2008 11:50:27 -0800 (PST) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id 6BC753A6A8C for ; Tue, 19 Feb 2008 11:50:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 067B17DCA for ; Tue, 19 Feb 2008 11:50:25 -0800 (PST) Received: from [192.168.0.100] (pool-71-161-50-169.clppva.east.verizon.net [71.161.50.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 516707DC9 for ; Tue, 19 Feb 2008 11:50:23 -0800 (PST) Message-ID: <47BB32FA.7070307@joelhalpern.com> Date: Tue, 19 Feb 2008 14:50:18 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> X-Enigmail-Version: 0.95.6 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I am coming to the same conclusion from the discussion. Yours, Joel Francois Audet wrote: > I'm not sure I agree with that. > = > I think we want something that is better than the PSTN. I just don't thin= k it's the > right question to ask. > = > And specifically, I don't think "identity" for PSTN numbers should be our= mandate. = > = >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] = >> Sent: Tuesday, February 19, 2008 11:25 >> To: Audet, Francois (SC100:3055) >> Cc: Jonathan Rosenberg; IETF SIP List >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >> >> I think we don't need something *better* than the PSTN, = >> though that would be nice. What I think we need is something = >> that is *not worse* than the PSTN. The problem is defining = >> what that means. >> >> I think that means at least: >> >> - when you connect via sip you get a callerid for at least those >> pstn callers where you would have gotten one if you had a = >> pstn phone >> *and* that callerid was "correct". >> >> - callerid is available to callees from sip callers with E.164 AORs >> when it hasn't been intentionally blocked and the caller is the >> legitimate "owner" of the number. >> >> - the frequency with which "incorrect" (spoofed) callerid is delivered >> to callees is no worse, on average, than with pure pstn calls. >> >> I realize this are a bit vague and hard to measure. But I = >> think this is subjectively what will be required for sip to = >> be widely accepted as a substitute for pstn phone service. >> >> Paul >> >> Francois Audet wrote: >>> Another "solution" is to not do it. >>> >>> By that I mean, use RFC 4474 for domain-based security, and if you = >>> insist on using phone numbers, then it's not "secured that way". >>> >>> Before the flaming start: by definition, if something is = >> addressed by = >>> a phone number, it is something that is likely to be = >> reacheable through the PSTN. >>> The way security works in the PSTN is completely different. = >> The media = >>> is almost never encrypted for one. So in the context of = >> SIP, it means = >>> there is a gateway somewhere destroying the end-to-end = >> nature of the encryption. >>> Even for the Identity, it's different. For one thing, the Identity = >>> assertion is not end-to-end =E0-la-RFC 4474. >>> >>> So, I'm proposing that if you are using phone numbers as your = >>> identity, then it is not a design requirement of this group to = >>> re-invent a "better" identity security system for the PSTN. >>> >>> It's not because something is a problem that it necessarily = >> needs to be solved. >>> My 2 cents. >>> >>>> -----Original Message----- >>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = >> On Behalf Of = >>>> Jonathan Rosenberg >>>> Sent: Monday, February 18, 2008 11:36 >>>> To: Paul Kyzivat >>>> Cc: IETF SIP List >>>> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >>>> >>>> I agree that something along the lines of enum could solve this = >>>> problem, and I believe there was a draft that proposed = >> such a thing. = >>>> This has been discussed since the start of rfc4474. >>>> >>>> However, I fear that saying, 'use enum' is kind of like = >> saying, we'll = >>>> just use an All-Knowing Oracle, so lets figure out the interface = >>>> protocol to the Oracle. The easy part is the interface (the enum = >>>> mechanism). The actual hard problem is how to get those entries = >>>> populated. The deployment of public enum has been - shall we say - = >>>> less than spectacular. >>>> I'd hate for that to be our only solution. Not that its = >> obvious what = >>>> else to do; though I do suggest in my draft how domain based = >>>> authentication, when combined with whitelists and blacklists, can = >>>> help. >>>> >>>> -Jonathan R. >>>> >>>> Paul Kyzivat wrote: >>>>> Jonathan, >>>>> >>>>> I guess the time has come for this discussion, since John = >> Ewell has = >>>>> also submitted a draft on this subject. >>>>> >>>>> I thought the problem was already well known, but perhaps >>>> not. IMO the >>>>> main thing now is to figure out the *solution* to the problem! >>>>> IMO a solution is to use a 4474-style approach, but where the = >>>>> certificate is tied to just the phone number, not to some = >> arbitrary = >>>>> domain name. That of course would depend on a model where >>>> the "owner" = >>>>> of the phone number is the one who may obtain the >>>> certificate for that number. >>>>> My thought is that we already have an algorithmic mapping from an >>>>> E.164 phone number to a domain name, defined by enum. If = >> the sender = >>>>> puts an >>>>> E.164 number in From, and can sign it with a cert for the >>>> enum mapped >>>>> domain name corresponding to that number, then that ought >>>> to be valid >>>>> proof of the validity of the sender. >>>>> >>>>> In those places where public enum is in operation, I = >> think there is = >>>>> already a legal mechanism in place to give the owner of = >> record of a = >>>>> particular phone number control over the contents of the >>>> corresponding >>>>> DNS entry. That should also be sufficient to allow a certificate = >>>>> authority to assign a cert to that same owner. >>>>> >>>>> Combine all that and you have a complete e2e identity model >>>> for phone >>>>> numbers, based on public enum. And that can be true even = >> if public = >>>>> enum isn't used to *route* the calls to that number. So = >> it could be = >>>>> used for "unlisted" numbers. >>>>> >>>>> To use this approach the From header should contain either >>>> a TEL URI, >>>>> or a sip/sips URI containing the enum-mapped domain name >>>> corresponding >>>>> to the phone number. (I would rather see the TEL used for >>>> this - it is >>>>> more user friendly.) >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Jonathan Rosenberg wrote: >>>>>> I just submitted: >>>>>> >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-conce >>>>>> rns-00.txt >>>>>> >>>>>> >>>>>> This is basically a discussion on the security properties >>>> of rfc4474 >>>>>> with phone numbers, and a comparison to rfc3325 in this >>>> case. Also a >>>>>> discussion on what happens to dtls-srtp. >>>>>> >>>>>> Comments welcome. >>>>>> >>>>>> -Jonathan R. >>>> -- = >>>> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >>>> Cisco Fellow Edison, NJ 08837 >>>> Cisco, Voice Technology Group >>>> jdrosen@cisco.com >>>> http://www.jdrosen.net PHONE: = >> (408) 902-3084 >>>> http://www.cisco.com >>>> _______________________________________________ >>>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use = >>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>> sipping@ietf.org for new developments on the application of sip >>>> > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 11:56:29 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B0328C653; Tue, 19 Feb 2008 11:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wckdpz-B1Jj; Tue, 19 Feb 2008 11:56:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F3A3A6B6B; Tue, 19 Feb 2008 11:56:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83773A6B80 for ; Tue, 19 Feb 2008 11:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYI+iUpfgi+e for ; Tue, 19 Feb 2008 11:56:26 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CEE343A6996 for ; Tue, 19 Feb 2008 11:56:25 -0800 (PST) Received: from [192.168.2.108] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1JJuI8V005487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Feb 2008 13:56:20 -0600 Message-ID: <47BB346A.2050005@softarmor.com> Date: Tue, 19 Feb 2008 13:56:26 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: David R Oran References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> In-Reply-To: <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> Cc: Mayumi Munakata , sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org David R Oran wrote: > On Feb 19, 2008, at 11:34 AM, .:: Francesco la Torre ::. wrote: > > >> IMO authenticated but private is something more then not >> authenticated. >> In first case, you know that on the other end there is an >> authenticated >> user for that domain, in the second one there is a complete lack of >> identity ... this entails that there is no reasons why sip uri (e.g. >> anonimous@pippo.org) cannot be signed by authentication service. >> >> > Of what value to a recipient is an authenticated From:anonymous@chaos-computer-club.org > ? Or a phished anonymous@bank0fAmerica.com? > > In the absence of a reputation service and separate authentication of > the source domain I don't see any at all. What are your assumed > preconditions for this authentication to have value? > > There is a distinct difference between a caller who is unknown to me but known to someone who is known to me and a caller who is truly anonymous. In the first case, if the caller proves to be "a problem", I have some recourse through channels. In the second, I do not. So let us take the typical public network scenario. If all caller's identities are known to the operator, an anonymized identifier asserted by that operator could be used to trace a nuisance call back to the source. That's useful: It could drive "black listing" operations, "white listing" operations, and support legal investigation into harassment calls, etc. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 11:57:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38E6D28C684; Tue, 19 Feb 2008 11:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-2.178, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t470tZAnhhMM; Tue, 19 Feb 2008 11:57:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61823A6B74; Tue, 19 Feb 2008 11:57:51 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5666C3A6B61 for ; Tue, 19 Feb 2008 11:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gmapV0cK8hI for ; Tue, 19 Feb 2008 11:57:50 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AC8433A6B74 for ; Tue, 19 Feb 2008 11:57:49 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Feb 2008 11:57:46 -0800 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 m1JJvkSr015835; Tue, 19 Feb 2008 11:57:46 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1JJvSwF012613; Tue, 19 Feb 2008 19:57:45 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 14:57:44 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 14:57:43 -0500 Message-ID: <47BB34C2.1060309@cisco.com> Date: Tue, 19 Feb 2008 14:57:54 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Francois Audet References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 19 Feb 2008 19:57:43.0606 (UTC) FILETIME=[B0C08D60:01C87331] Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet wrote: > I'm not sure I agree with that. > = > I think we want something that is better than the PSTN. I just don't thin= k it's the > right question to ask. I certainly *want* something better than PSTN. But perhaps we don't = *need* that. I think we do *need* something "as good as" the PSTN. But perhaps the first order of business is to come to agreement on what = we need. Paul > And specifically, I don't think "identity" for PSTN numbers should be our= mandate. = > = >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] = >> Sent: Tuesday, February 19, 2008 11:25 >> To: Audet, Francois (SC100:3055) >> Cc: Jonathan Rosenberg; IETF SIP List >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >> >> I think we don't need something *better* than the PSTN, = >> though that would be nice. What I think we need is something = >> that is *not worse* than the PSTN. The problem is defining = >> what that means. >> >> I think that means at least: >> >> - when you connect via sip you get a callerid for at least those >> pstn callers where you would have gotten one if you had a = >> pstn phone >> *and* that callerid was "correct". >> >> - callerid is available to callees from sip callers with E.164 AORs >> when it hasn't been intentionally blocked and the caller is the >> legitimate "owner" of the number. >> >> - the frequency with which "incorrect" (spoofed) callerid is delivered >> to callees is no worse, on average, than with pure pstn calls. >> >> I realize this are a bit vague and hard to measure. But I = >> think this is subjectively what will be required for sip to = >> be widely accepted as a substitute for pstn phone service. >> >> Paul >> >> Francois Audet wrote: >>> Another "solution" is to not do it. >>> >>> By that I mean, use RFC 4474 for domain-based security, and if you = >>> insist on using phone numbers, then it's not "secured that way". >>> >>> Before the flaming start: by definition, if something is = >> addressed by = >>> a phone number, it is something that is likely to be = >> reacheable through the PSTN. >>> The way security works in the PSTN is completely different. = >> The media = >>> is almost never encrypted for one. So in the context of = >> SIP, it means = >>> there is a gateway somewhere destroying the end-to-end = >> nature of the encryption. >>> Even for the Identity, it's different. For one thing, the Identity = >>> assertion is not end-to-end =E0-la-RFC 4474. >>> >>> So, I'm proposing that if you are using phone numbers as your = >>> identity, then it is not a design requirement of this group to = >>> re-invent a "better" identity security system for the PSTN. >>> >>> It's not because something is a problem that it necessarily = >> needs to be solved. >>> My 2 cents. >>> >>>> -----Original Message----- >>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = >> On Behalf Of = >>>> Jonathan Rosenberg >>>> Sent: Monday, February 18, 2008 11:36 >>>> To: Paul Kyzivat >>>> Cc: IETF SIP List >>>> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >>>> >>>> I agree that something along the lines of enum could solve this = >>>> problem, and I believe there was a draft that proposed = >> such a thing. = >>>> This has been discussed since the start of rfc4474. >>>> >>>> However, I fear that saying, 'use enum' is kind of like = >> saying, we'll = >>>> just use an All-Knowing Oracle, so lets figure out the interface = >>>> protocol to the Oracle. The easy part is the interface (the enum = >>>> mechanism). The actual hard problem is how to get those entries = >>>> populated. The deployment of public enum has been - shall we say - = >>>> less than spectacular. >>>> I'd hate for that to be our only solution. Not that its = >> obvious what = >>>> else to do; though I do suggest in my draft how domain based = >>>> authentication, when combined with whitelists and blacklists, can = >>>> help. >>>> >>>> -Jonathan R. >>>> >>>> Paul Kyzivat wrote: >>>>> Jonathan, >>>>> >>>>> I guess the time has come for this discussion, since John = >> Ewell has = >>>>> also submitted a draft on this subject. >>>>> >>>>> I thought the problem was already well known, but perhaps >>>> not. IMO the >>>>> main thing now is to figure out the *solution* to the problem! >>>>> IMO a solution is to use a 4474-style approach, but where the = >>>>> certificate is tied to just the phone number, not to some = >> arbitrary = >>>>> domain name. That of course would depend on a model where >>>> the "owner" = >>>>> of the phone number is the one who may obtain the >>>> certificate for that number. >>>>> My thought is that we already have an algorithmic mapping from an >>>>> E.164 phone number to a domain name, defined by enum. If = >> the sender = >>>>> puts an >>>>> E.164 number in From, and can sign it with a cert for the >>>> enum mapped >>>>> domain name corresponding to that number, then that ought >>>> to be valid >>>>> proof of the validity of the sender. >>>>> >>>>> In those places where public enum is in operation, I = >> think there is = >>>>> already a legal mechanism in place to give the owner of = >> record of a = >>>>> particular phone number control over the contents of the >>>> corresponding >>>>> DNS entry. That should also be sufficient to allow a certificate = >>>>> authority to assign a cert to that same owner. >>>>> >>>>> Combine all that and you have a complete e2e identity model >>>> for phone >>>>> numbers, based on public enum. And that can be true even = >> if public = >>>>> enum isn't used to *route* the calls to that number. So = >> it could be = >>>>> used for "unlisted" numbers. >>>>> >>>>> To use this approach the From header should contain either >>>> a TEL URI, >>>>> or a sip/sips URI containing the enum-mapped domain name >>>> corresponding >>>>> to the phone number. (I would rather see the TEL used for >>>> this - it is >>>>> more user friendly.) >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Jonathan Rosenberg wrote: >>>>>> I just submitted: >>>>>> >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-conce >>>>>> rns-00.txt >>>>>> >>>>>> >>>>>> This is basically a discussion on the security properties >>>> of rfc4474 >>>>>> with phone numbers, and a comparison to rfc3325 in this >>>> case. Also a >>>>>> discussion on what happens to dtls-srtp. >>>>>> >>>>>> Comments welcome. >>>>>> >>>>>> -Jonathan R. >>>> -- = >>>> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >>>> Cisco Fellow Edison, NJ 08837 >>>> Cisco, Voice Technology Group >>>> jdrosen@cisco.com >>>> http://www.jdrosen.net PHONE: = >> (408) 902-3084 >>>> http://www.cisco.com >>>> _______________________________________________ >>>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use = >>>> sip-implementors@cs.columbia.edu for questions on current sip Use = >>>> sipping@ietf.org for new developments on the application of sip >>>> > = _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 12:01:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6FA28C782; Tue, 19 Feb 2008 12:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=-1.139, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2Hwq3Fx-9o4; Tue, 19 Feb 2008 12:01:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D326428C751; Tue, 19 Feb 2008 12:00:55 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF61928C7E2 for ; Tue, 19 Feb 2008 12:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrls6Q1lfM6K for ; Tue, 19 Feb 2008 12:00:52 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 179E328C78C for ; Tue, 19 Feb 2008 12:00:20 -0800 (PST) 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 m1JK00f25774; Tue, 19 Feb 2008 20:00:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 13:59:47 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> In-Reply-To: <47BB34C2.1060309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchzMbte2KtmmfeFR0eNRpz01z1oNgAABHbA References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> <47BB34C2.1060309@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think we might be talking about two different aspects. For "phone numbers", I agree with you that parity is ok. For "email-looking addresses", I believe the bar is higher (and we have it already with 4474). > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 19, 2008 11:58 > To: Audet, Francois (SC100:3055) > Cc: Jonathan Rosenberg; IETF SIP List > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > > > Francois Audet wrote: > > I'm not sure I agree with that. > > > > I think we want something that is better than the PSTN. I > just don't > > think it's the right question to ask. > > I certainly *want* something better than PSTN. But perhaps we don't > *need* that. I think we do *need* something "as good as" the PSTN. > > But perhaps the first order of business is to come to > agreement on what we need. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 13:12:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBB128C603; Tue, 19 Feb 2008 13:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hiedhq4GXpUF; Tue, 19 Feb 2008 13:12:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E8828C127; Tue, 19 Feb 2008 13:12:47 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF5028C127 for ; Tue, 19 Feb 2008 13:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4soolu8XiI0i for ; Tue, 19 Feb 2008 13:12:44 -0800 (PST) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by core3.amsl.com (Postfix) with ESMTP id B5DD728C5D4 for ; Tue, 19 Feb 2008 13:12:30 -0800 (PST) Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Feb 2008 16:12:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 16:12:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc3262: validity and meaning of PRACK 488 Thread-Index: AchzPCIAZpRF90dZQl2wQIvUo27/UQ== From: "Brett Tate" To: "IETF SIP List" X-OriginalArrivalTime: 19 Feb 2008 21:12:28.0075 (UTC) FILETIME=[21B437B0:01C8733C] Cc: pkyzivat@cisco.com, christer.holmberg@ericsson.com, hgs@cs.columbia.edu Subject: [Sip] rfc3262: validity and meaning of PRACK 488 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Greetings, While discussing draft-ietf-sipping-sip-offeranswer-05, several questions surfaced. Christer has requested time to discuss it at the IETF; however I thought that I'd seek earlier resolution. Many agree that offers within PRACK should be deprecated. However since they are discussed within draft-ietf-sipping-sip-offeranswer and these questions are not limited to PRACK offer, please consider the questions anyway. Is rejecting PRACK by a UAS generically allowed by rfc3262? And if so, is the 18x 100rel considered acknowledged from UAS perspective always, never, or sometimes? And if sometimes, when? Per rfc3262, is the UAS allowed to reject the PRACK body with responses such as 488? And if so, is the 18x 100rel considered acknowledged from UAS perspective? If UAC receives a PRACK 488 (or similarly body response), should it resend PRACK with higher cseq and appropriate SDP/body modifications/removal if desiring to provide satisfactory acknowledgement of INVITE 18x? Recent "sipping-sip-offeranswer-05: comments and questions" discussions can be found within the sipping email archive; first post was 1/31/2008. I didn't provide links to the relevant postings since I'm currently unable to access the IETF email archives. Thanks, Brett _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 13:20:18 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1133128C78A; Tue, 19 Feb 2008 13:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=-2.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpRmmTh32w+F; Tue, 19 Feb 2008 13:20:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD70B28C3F7; Tue, 19 Feb 2008 13:19:40 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EF83A6BA8 for ; Tue, 19 Feb 2008 13:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9AuNJ-J8qBm for ; Tue, 19 Feb 2008 13:19:39 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 47D2828C3F7 for ; Tue, 19 Feb 2008 13:17:31 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2008 16:17:27 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1JLHQMa018855; Tue, 19 Feb 2008 16:17:26 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1JLHHWJ024558; Tue, 19 Feb 2008 21:17:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 16:17:13 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 16:17:12 -0500 Message-ID: <47BB4763.1020804@cisco.com> Date: Tue, 19 Feb 2008 16:17:23 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> In-Reply-To: <47BB346A.2050005@softarmor.com> X-OriginalArrivalTime: 19 Feb 2008 21:17:12.0816 (UTC) FILETIME=[CB6C3F00:01C8733C] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Mayumi Munakata , sip@ietf.org, David R Oran Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In this case there is no expectation that the anonymized address will be willing or able to report to anyone what the identity of its client was. In the absence of any such assurance, having sip identity is of no use. Paul Dean Willis wrote: > David R Oran wrote: >> On Feb 19, 2008, at 11:34 AM, .:: Francesco la Torre ::. wrote: >> >> >>> IMO authenticated but private is something more then not authenticated. >>> In first case, you know that on the other end there is an authenticated >>> user for that domain, in the second one there is a complete lack of >>> identity ... this entails that there is no reasons why sip uri (e.g. >>> anonimous@pippo.org) cannot be signed by authentication service. >>> >>> >> Of what value to a recipient is an authenticated >> From:anonymous@chaos-computer-club.org ? Or a phished >> anonymous@bank0fAmerica.com? >> >> In the absence of a reputation service and separate authentication of >> the source domain I don't see any at all. What are your assumed >> preconditions for this authentication to have value? >> >> > There is a distinct difference between a caller who is unknown to me but > known to someone who is known to me and a caller who is truly anonymous. > In the first case, if the caller proves to be "a problem", I have some > recourse through channels. In the second, I do not. > > So let us take the typical public network scenario. If all caller's > identities are known to the operator, an anonymized identifier asserted > by that operator could be used to trace a nuisance call back to the > source. That's useful: It could drive "black listing" operations, "white > listing" operations, and support legal investigation into harassment > calls, etc. > > -- > Dean > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 13:23:46 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B8E28C742; Tue, 19 Feb 2008 13:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=-2.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAUGl6VdjaJ6; Tue, 19 Feb 2008 13:23:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B353A6A75; Tue, 19 Feb 2008 13:23:31 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E0328C67F for ; Tue, 19 Feb 2008 13:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xHl5TwaVXbb for ; Tue, 19 Feb 2008 13:23:30 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 73B4E28C75A for ; Tue, 19 Feb 2008 13:22:20 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2008 16:22:17 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1JLMHET021513; Tue, 19 Feb 2008 16:22:17 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1JLMDSG029514; Tue, 19 Feb 2008 21:22:17 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 16:22:14 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 16:22:13 -0500 Message-ID: <47BB4890.6050007@cisco.com> Date: Tue, 19 Feb 2008 16:22:24 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Francois Audet References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> <47BB34C2.1060309@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 19 Feb 2008 21:22:13.0741 (UTC) FILETIME=[7EC9C1D0:01C8733D] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet wrote: > I think we might be talking about two different aspects. > > For "phone numbers", I agree with you that parity is ok. > > For "email-looking addresses", I believe the bar is higher (and we > have it already with 4474). OK. THen we aren't far apart. I agree we want and have something better for email-style addresses where the domain is significant. It is the "phone number" addresses I am concerned with here. I think we must have parity, and ideally better when the PSTN isn't involved. Paul >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, February 19, 2008 11:58 >> To: Audet, Francois (SC100:3055) >> Cc: Jonathan Rosenberg; IETF SIP List >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >> >> >> >> Francois Audet wrote: >>> I'm not sure I agree with that. >>> >>> I think we want something that is better than the PSTN. I >> just don't >>> think it's the right question to ask. >> I certainly *want* something better than PSTN. But perhaps we don't >> *need* that. I think we do *need* something "as good as" the PSTN. >> >> But perhaps the first order of business is to come to >> agreement on what we need. > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 13:47:59 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351E428C6D5; Tue, 19 Feb 2008 13:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He0zLYK0BDuk; Tue, 19 Feb 2008 13:47:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F14828C1B6; Tue, 19 Feb 2008 13:47:58 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46FA28C1B6 for ; Tue, 19 Feb 2008 13:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suYbrhnFTcGW for ; Tue, 19 Feb 2008 13:47:55 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 95A113A6ADD for ; Tue, 19 Feb 2008 13:47:55 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9E3AB2053A; Tue, 19 Feb 2008 22:47:51 +0100 (CET) X-AuditID: c1b4fb3e-a99fdbb000000b15-6a-47bb4e87ec21 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8F73B20525; Tue, 19 Feb 2008 22:47:51 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 22:47:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 22:45:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc3262: validity and meaning of PRACK 488 thread-index: AchzPCIAZpRF90dZQl2wQIvUo27/UQABKckb References: From: "Christer Holmberg" To: "Brett Tate" , "IETF SIP List" X-OriginalArrivalTime: 19 Feb 2008 21:47:42.0620 (UTC) FILETIME=[0E122DC0:01C87341] X-Brightmail-Tracker: AAAAAA== Cc: pkyzivat@cisco.com, hgs@cs.columbia.edu Subject: Re: [Sip] rfc3262: validity and meaning of PRACK 488 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Brett, Thanks for putting this e-mail together. A small correction, though: I have not requested time for this at the meeting. I told Dean that it was an issue missing from his list, which could be a candidate for discussion. Regards, Christer ________________________________ From: Brett Tate [mailto:brett@broadsoft.com] Sent: Tue 19/02/2008 22:12 To: IETF SIP List Cc: jdrosen@cisco.com; hgs@cs.columbia.edu; Christer Holmberg; pkyzivat@cisco.com Subject: rfc3262: validity and meaning of PRACK 488 Greetings, While discussing draft-ietf-sipping-sip-offeranswer-05, several questions surfaced. Christer has requested time to discuss it at the IETF; however I thought that I'd seek earlier resolution. Many agree that offers within PRACK should be deprecated. However since they are discussed within draft-ietf-sipping-sip-offeranswer and these questions are not limited to PRACK offer, please consider the questions anyway. Is rejecting PRACK by a UAS generically allowed by rfc3262? And if so, is the 18x 100rel considered acknowledged from UAS perspective always, never, or sometimes? And if sometimes, when? Per rfc3262, is the UAS allowed to reject the PRACK body with responses such as 488? And if so, is the 18x 100rel considered acknowledged from UAS perspective? If UAC receives a PRACK 488 (or similarly body response), should it resend PRACK with higher cseq and appropriate SDP/body modifications/removal if desiring to provide satisfactory acknowledgement of INVITE 18x? Recent "sipping-sip-offeranswer-05: comments and questions" discussions can be found within the sipping email archive; first post was 1/31/2008. I didn't provide links to the relevant postings since I'm currently unable to access the IETF email archives. Thanks, Brett _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 14:09:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0921B28C5F9; Tue, 19 Feb 2008 14:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.286 X-Spam-Level: X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUs1XeOruCuy; Tue, 19 Feb 2008 14:09:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB273A6B2B; Tue, 19 Feb 2008 14:09:38 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87BBA3A68C4 for ; Tue, 19 Feb 2008 14:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALFOYiYiL4R9 for ; Tue, 19 Feb 2008 14:09:36 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 701033A6C73 for ; Tue, 19 Feb 2008 14:09:36 -0800 (PST) Received: from [172.16.3.233] ([172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.1/8.14.1) with ESMTP id m1JM9Uv6085502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2008 16:09:31 -0600 (CST) (envelope-from bcampen@estacado.net) Mime-Version: 1.0 (Apple Message framework v753) To: SIP IETF Message-Id: <15806D18-8A95-43E8-8AE3-C0B41C73D7FC@estacado.net> From: Byron Campen Date: Tue, 19 Feb 2008 16:09:26 -0600 X-Mailer: Apple Mail (2.753) Subject: [Sip] draft-ietf-sip-xcapevent-00: notifier behavior when Accept header is missing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1383292325==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1383292325== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-16--334013160; protocol="application/pkcs7-signature" --Apple-Mail-16--334013160 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I can't find any text in the draft detailing notifier behavior when the Accept header is missing in a SUBSCRIBE (RFC 3265 sec 3.1.3 requires that event packages define the behavior in this case). I imagine the easy thing to do is assume that the subscriber can handle application/xcap-diff+xml? Best regards, Byron Campen --Apple-Mail-16--334013160 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEFwXRVCLqQP3qi3PRrH6AlAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkyNzE2NDM1MFoXDTA4MDkyNjE2NDM1 MFowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrUCWJxs76 dJ2iUD0fdJN7Xp1gjw1zWQD8Cb4ilcy9eMRlHr8XxhcyV7my1Clbhdo9ARTvFVF2kh5pMFC4piO5 I5JrwY7tx5cpfeQiSmEU6nVGcyWrjgBFsD2tPtTvroxne7wXYgSwlh/VX9haPI1qOkfqY6rP4Ojt CUpQpcseg5RA3aTyLiKHZj1/UkR5qk+B1WGscDq6pyG6a8UGRU6AHbN8nThMZ6Mql2nFP45TaFzL iqs1k1LbrKVQZ1ejUbDj4VHO85sX0nPHvb68MYN8gfq7YyiG3nkMzZfbvTgWRx4QQWAFVHymd3nT bo2nQmNO7GMvHprR+7Ju2trAzuUnAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAqPdc4XlMKZoLLn5UCvGVW0R2 pL6kGuoDyFJNS1Ad/Aq5y06OEA+j1pudVOlbe/Z27AqT3dGX0mFdHBsiyTzXNqa9UkhIDFoaWfpV M9U6SXcQY9cDFeAEUWWT6zf8CbaLXwVJKygY6/PFlgusb+fn7JYQTieqg+DbMszrP55WFh8wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFwXRVCLqQP3qi3PRrH6AlAwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMjE5 MjIwOTI2WjAjBgkqhkiG9w0BCQQxFgQUoqIMyeI5g0H1g21xlwb3v2IMAsQwgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBcF0VQi6kD 96otz0ax+gJQMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhBcF0VQi6kD96otz0ax+gJQMA0GCSqGSIb3DQEBAQUABIIBAIKkzJMO j55/MR64Qtlp/TMW7MRsw/CWrD4pSgZVnpG4dXsa3HJjOdIrWyHOr0wETEaZeeU6h66XAfc4vERI +66nTwW5PskaAPHYbB4yeGwcgNREksNJhO6AFD8wTGHU2z3AldzbGdda9OS7c58e0qWsbaIMqXJ4 PAxOOTTjcgNcmFi5I6L5nw/bvp0v0+kitnZF29su71ZXOjMJvf6AqE3dF2uahfPuPuTrYMxittd4 Qcl27QwV6dsmK6hfe3ZH+oA6eYtDSUa8jHRKN3YexjTW6EOq6uL5WPtf+/RG8YLtnCZTwORSF9bN hdPsP6TFS6epPu13PvN1/W3Vv3e3MnkAAAAAAAA= --Apple-Mail-16--334013160-- --===============1383292325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1383292325==-- From sip-bounces@ietf.org Tue Feb 19 14:29:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EF23A6CC3; Tue, 19 Feb 2008 14:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0iPp5dQaLNW; Tue, 19 Feb 2008 14:29:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC6F3A6ABC; Tue, 19 Feb 2008 14:29:50 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937EB3A6876 for ; Tue, 19 Feb 2008 14:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTfvEfudk5s7 for ; Tue, 19 Feb 2008 14:29:47 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E6AC73A6AD9 for ; Tue, 19 Feb 2008 14:29:46 -0800 (PST) X-IronPort-AV: E=McAfee;i="5200,2160,5233"; a="800002" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2008 14:29:44 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1JMThP8009220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Feb 2008 14:29:43 -0800 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1JMTgJE021035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Feb 2008 14:29:43 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <47B6345B.4030807@cisco.com> References: <47B6345B.4030807@cisco.com> Date: Tue, 19 Feb 2008 14:29:41 -0800 To: Jonathan Rosenberg , IETF SIP List From: Ted Hardie Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Howdy, So I read this, then re-read this after having some more coffee, and I seriously considered re-reading it again after something alcoholic, just so I could see whether it seemed like a good idea in any of those states. Since my workplace declines to provide a wet bar, I didn't manage the last, so there is some chance I'm way off base here. First, some comments on the mechanics. Having a "purpose" that is not tied to the top level type of the mime type you're transporting opens you up to a lot of silly states. If I send you a purpose claiming something is a pic, but provide text/plain, is it ascii art? If I claim it is a pic, but provide application/octet-stream, will the data get fed to a renderer? That is, does the MIME type or the purpose handle disposition? The "Semantics" session seems to indicate it is purpose that governs this: Semantics: Each purpose MUST clearly define what its used for. T he definition must be sufficiently clear to allow an implementation to decide whether to render the object, what kind of UI to apply, how and where to store the object, how to process it, and so on. That's going to break how a lot of other things handle MIME object transport, and incidentally call into question a very basic mechanism for minting new application protocols currently in favor (that is, using specialty MIME types to trigger the handling). I'm not saying it's not a valid design choice, but it does run counter to the current set of trends. I also am concerned that in using the purpose, the design opens things up to crafted payload attacks. Second, none of the examples seem to show parameters being included with the MIME types; dealing with those provides a serious set of problems for interoperability (think of the charset parameters for an easy example). Supported MIME types may not be enough to determine whether you and your intended recipient actually do share enough for an interoperable transfer. This is also true with bucket MIME types (like message/cpim) which can contain other MIME types. I found your description of the session model and the answerer behavior somewhat unclear, and I'd like some additional clarification. In the answerer section, you say: An agent receiving an offer with an m=message line including the protocol "TOTE" or "TOTES" is being offered the opportunity to set up a TOTE session for one or more purposes. If the agent is capable of receiving objects using at least one of the purpose tokens associated with the tote session, the agent SHOULD accept the session. If it can receive none of them, it MUST reject the session (by setting the port to zero). The TOTE session described here looks like it is multiplexed for all the original purposes. For a receiver to remove one or more purposes from the original set, do I understand correctly that it needs to tear down the TOTE session and set up another? (On a side note, the TOTE vs. TOTES issue looks to have exactly the same ratholes we've seen before). Your draft says: An actual TOTE message can span several RFC4571 frames; this is analagous in general to reads off of a TCP connection - the amount of data read at a time has no bearing on the length of the actual message. As a consequence of this, even though RFC4571 has a limit of 64k, there is no constraint on the length of a TOTE message. I assume that this means that a TOTE implementation should not try to split its messages using any existing MIME facilities for that. Why not re-use the mechanism of things like message/partial? It would also be good to describe whether a MIME type like multipart/alternative SHOULD be split and each alternative listed in the SDP offer, or whether the multipart/alternative should be listed. If the former, the semantics of how to restore the default choice semantics of multipart/alternative should be described. If the latter, how does the receiver know anything about the interal parts' mime types? In other issues, I found the IANA consideration section very underspecified. This seriously needs to indicate when a purpose like "whiteboard" is general and when it is specific to an application. Having something that indicates what potential MIME types would be for this (and a way of updating the registration) would be much better than the "Description" field you have, and having both would be better still. The IANA considerations section also needs to re-mention the possibility of vendor specific purposes, and indicate whether they should conform to things like the SHOULD limit of 20 characters. (To put this another way, your IANA considerations only handle one of the two namespaces, and should mention the other and describe it as well). You have several examples (name, pic, bizcard, whiteboard) in the draft, but you do not register them. Why not? The Security Considerations don't begin to describe the issues here, and I assume that would change if this progressed. I look forward to hearing how the deep-packet inspection industry enjoys a bi-directional TLS-protected generic MIME tranport that gets through NATs and Firewalls using relays everyone thought they were deploying for VoIP. On the big picture, I think this is in the muddy middle in too many ways. Having an application linked to a specific transport is pretty well understood. Having a transfer protocol linked to very limited application semantics (e.g. FTP) is also pretty well understood. Having a generic rendezvous mechanism that multiplexes MIME objects intended for consumption by multiple different applications seems to run across some pretty rathole-infested ground (head of line blocking for my camera-control object when I'm sending media to a different application; MIME disposition ambiguity; interoperability problems when every vendor chooses their own specific purpose strings). If this is the cure, the disease was much, much worse than I thought. I look forward to my post-work re-read, Ted _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 17:19:10 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3DEA28C38A; Tue, 19 Feb 2008 17:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.128 X-Spam-Level: **** X-Spam-Status: No, score=4.128 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=1, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, RDNS_NONE=0.1, ROUND_THE_WORLD_LOCAL=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oiLMmAl+iEA; Tue, 19 Feb 2008 17:19:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD44628C1D8; Tue, 19 Feb 2008 17:19:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1F03A688F for ; Tue, 19 Feb 2008 17:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AHLZhSSbXKa for ; Tue, 19 Feb 2008 17:19:07 -0800 (PST) Received: from mail.alcatel-sbell.com.cn (cnrelay03.alcatel-sbell.com.cn [211.144.215.19]) by core3.amsl.com (Postfix) with ESMTP id ED2FB3A68D1 for ; Tue, 19 Feb 2008 17:19:06 -0800 (PST) Received: from cnshgsbhs02.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id m1K1IUmC014156; Wed, 20 Feb 2008 09:18:35 +0800 Received: from CNSHGSMBS04.ad4.ad.alcatel.com ([172.24.146.173]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 20 Feb 2008 09:18:57 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Feb 2008 09:18:18 +0800 Message-ID: <198A33EB1E9E344EBC566802C7761D6B3F4ED4@CNSHGSMBS04.ad4.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] is supported and require is Mandatory in INVITE request Thread-Index: Achy4n79x2PXHibzR1aECRmUPVUKpwABRT7AAB2gcjA= From: "ZHANG Rocky F" To: , , X-OriginalArrivalTime: 20 Feb 2008 01:18:57.0158 (UTC) FILETIME=[90AF3260:01C8735E] X-imss-version: 2.049 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.1500 0.1500) Subject: Re: [Sip] is supported and require is Mandatory in INVITE request X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0055497429==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0055497429== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8735E.907E6401" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8735E.907E6401 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Yes. =20 According to RFC 3261, Supported and Require are optional. But if they are needed, they must be present. These two header fields are all for standard SIP extensions. =20 =20 =20 Best Regards, =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fanwen zhang FS5000 CPE IOT, Alcatel-Lucent Qingdao, R&D Tel: +86-532-88615493 Email:fanwenz@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of sreerekha.shenoy@wipro.com Sent: Tuesday, February 19, 2008 7:21 PM To: t.sudhirkumar@gmail.com; sip@ietf.org Subject: Re: [Sip] is supported and require is Mandatory in INVITE request Hi Sudhir, "Supported" and "Require" are known as headers rather than methods. These two headers have the following significance as per RFC 3261 : =20 20.32 Require The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. =20 20.37 Supported The Supported header field enumerates all the extensions supported by the UAC or UAS. If INVITE contains just "Supported" header, the UAS "MAY" send the non-100 responses reliably as stated in RFC 3262 =20 If INVITE contains "Require" header, the UAS "MUST" send the non-100 responses reliably. If it does not support this extension, it should respond to the INVITE with "420 Bad Extension" response. =20 Its valid for a UAC to send INVITE with just "Require: 100 rel" header as well. Best Regards, Rekha (ESN : 6-877-5834) (PSTN : 81168) =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Sudhir Kumar Reddy Sent: Tuesday, February 19, 2008 4:00 PM To: sip@ietf.org Subject: [Sip] is supported and require is Mandatory in INVITE request Hi All, Is supported and require methods are required for INVITE request (RFC 3262) or any of method(either Supported or require) will suffice for INVITE for Provisional ACK. Because I see in one of INVITE(from server) sending only require: 100Rel, but there is no Supported Header. Should we treat as complete or incomplete request? Any response is highly appreciated.=20 Thanks in Advance Sudhir=20 ------_=_NextPart_001_01C8735E.907E6401 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Yes.
     
    According to RFC 3261, Supported and Require = are optional.=20 But if they are needed, they must be present.
    These two header fields are all for standard = SIP=20 extensions.
     
     
     
    Best Regards,
     
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Fanwen zhang
    FS5000 CPE IOT, Alcatel-Lucent = Qingdao,=20 R&D
    Tel:=20 +86-532-88615493
    Email:fanwenz@alcatel-lucent.com
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     

    From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of=20 sreerekha.shenoy@wipro.com
    Sent: Tuesday, February 19, = 2008 7:21=20 PM
    To: t.sudhirkumar@gmail.com; = sip@ietf.org
    Subject: Re:=20 [Sip] is supported and require is Mandatory in INVITE=20 request

    Hi Sudhir,
      "Supported" and "Require" are known as = headers=20 rather than methods.
      These two headers have the = following=20 significance as per RFC 3261 :
      
    20.32 = Require
    The=20 Require header field is used by UACs to tell UASs about = options
      =20 that the UAC expects the UAS to support in order to process = the
      =20 request.
     
    20.37=20 Supported
       The Supported header field enumerates all the=20 extensions supported by
       the UAC or UAS.
      If INVITE contains just "Supported" header, the UAS = "MAY" send the=20 non-100 responses reliably as stated in RFC 3262
     
      If INVITE contains "Require" header, the UAS "MUST" send = the=20 non-100 responses reliably. If it does not support this extension, it = should=20 respond to the INVITE with "420 Bad Extension" = response.
     
      Its valid for a UAC to send INVITE with just "Require: = 100 rel"=20 header as well.
    Best=20 Regards,
    Rekha
    (ESN :=20 6-877-5834)
    (PSTN :=20 81168)
     

    From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Sudhir Kumar=20 Reddy
    Sent: Tuesday, February 19, 2008 4:00 PM
    To:=20 sip@ietf.org
    Subject: [Sip] is supported and require is = Mandatory in=20 INVITE request

    Hi All,

    Is supported and require methods are required = for=20 INVITE request (RFC 3262) or any of method(either Supported or require) = will=20 suffice for INVITE for Provisional ACK. Because I see in one of = INVITE(from=20 server) sending only require: 100Rel, but there is no Supported=20 Header.

    Should we treat as complete or incomplete = request?

    Any=20 response is highly appreciated.

    Thanks in Advance
    Sudhir=20 ------_=_NextPart_001_01C8735E.907E6401-- --===============0055497429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0055497429==-- From sip-bounces@ietf.org Tue Feb 19 18:43:12 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2142C28C69D; Tue, 19 Feb 2008 18:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcf5Yb+ihCnL; Tue, 19 Feb 2008 18:43:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2292F3A6B4C; Tue, 19 Feb 2008 18:43:11 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B19F28C3EB for ; Tue, 19 Feb 2008 18:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBkyKH3OKocH for ; Tue, 19 Feb 2008 18:43:09 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by core3.amsl.com (Postfix) with ESMTP id 2E21F3A6BD4 for ; Tue, 19 Feb 2008 18:43:07 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP; Tue, 19 Feb 2008 18:43:03 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m1K2eQin027684; Tue, 19 Feb 2008 18:40:27 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id m1K2gZFt010058; Tue, 19 Feb 2008 18:43:01 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 18:42:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 18:42:46 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> In-Reply-To: <0ccf01c87313$4613e160$d23ba420$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-Index: AchzDud0ZmsZPdg0TyK7X2RLoduKpwAAmO/wABXxYCA= References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us><47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us><47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> From: "Henry Sinnreich" To: "Richard Shockey" , X-OriginalArrivalTime: 20 Feb 2008 02:42:58.0592 (UTC) FILETIME=[4D9CFA00:01C8736A] Cc: IETF SIP List , paf@cisco.com Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >"Here is this problem, this is what we >(IETF) think, the solution is in your court. Have a nice day." I believe this puts it in nutshell. The telecom specific uses of ENUM technology are more appropriately handled in the telecom standards organizations, such as the ITU-T, and ETSI. Let's move on and work with Internet and web addressing that I believe have the real potential for the Internet standards development and where IETF resources are better placed. Thanks, Henry -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, February 19, 2008 10:20 AM To: Hannes.Tschofenig@gmx.net Cc: 'IETF SIP List'; paf@cisco.com Subject: Re: [Sip] Infrastructure issues involving e164 numbers This is not to say that the IETF could play a useful and essential role. We can certainly develop and define the requirements, use cases etc. In addition the IETF can architect a solution but experience tells me that deployment and implementation issues surrounding e164 issues will need the cooperation of "other bodies" which is where the problem lies. It's not really the ITU, in fact the ITU is a much easier place to get things done these days. The complications arise with the ITU member states, who jealously guard their diplomatic and political prerogatives. This was the conclusion that we drew when the Infrastructure ENUM issues first arose. We essentially said ..."Here is this problem, this is what we (IETF) think, the solution is in your court. Have a nice day." > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, February 19, 2008 10:49 AM > To: Richard Shockey > Cc: 'IETF SIP List'; paf@cisco.com > Subject: Re: Infrastructure issues involving e164 numbers > > > > If there is going to be a solution to the SIP identity problem > involving > > e164 numbers, it will not IMHO be solved in the IETF. > > > > > Interesting view. I obviously does not appear to be an easy thing; > in the draft I called this "There is non-neglectable deployment > incentive challenge." _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 18:44:30 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A4B3A694A; Tue, 19 Feb 2008 18:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61Jvc1l6VWKE; Tue, 19 Feb 2008 18:44:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E520528C10D; Tue, 19 Feb 2008 18:44:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA503A6B4C for ; Tue, 19 Feb 2008 18:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7krffPxyNqRf for ; Tue, 19 Feb 2008 18:44:27 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 78A7B3A6AE8 for ; Tue, 19 Feb 2008 18:44:27 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 19 Feb 2008 18:44:24 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1K2iO5c032747; Tue, 19 Feb 2008 18:44:24 -0800 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 m1K2iMJm005144; Wed, 20 Feb 2008 02:44:23 GMT 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.1830); Tue, 19 Feb 2008 18:44:15 -0800 Received: from [128.107.103.186] ([128.107.103.186]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 18:44:15 -0800 Message-ID: <47BB93F3.6060907@cisco.com> Date: Tue, 19 Feb 2008 21:44:03 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Paul Kyzivat References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> <47BB34C2.1060309@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> <47BB4890.6050007@cisco.com> In-Reply-To: <47BB4890.6050007@cisco.com> X-OriginalArrivalTime: 20 Feb 2008 02:44:15.0453 (UTC) FILETIME=[7B6D08D0:01C8736A] Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: IETF SIP List , Francois Audet Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Actually what I am hoping to do is to just clearly document the applicability of RFC4474 to numbers and be much crisper with guidance on when to use it, when to not, what it buys you with numbers (since it does help a little even then - receivers can know the domain that asserts that number and use blacklists/whitelists to judge trustability). I also want to make sure we are not basing SRTP security on integrity properties delivered with RFC4474, when said properties aren't really delivered so well with phone numbers. -Jonathan R. Paul Kyzivat wrote: > > > Francois Audet wrote: >> I think we might be talking about two different aspects. >> >> For "phone numbers", I agree with you that parity is ok. >> >> For "email-looking addresses", I believe the bar is higher (and we >> have it already with 4474). > > OK. THen we aren't far apart. I agree we want and have something better > for email-style addresses where the domain is significant. It is the > "phone number" addresses I am concerned with here. I think we must have > parity, and ideally better when the PSTN isn't involved. > > Paul > >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, >>> February 19, 2008 11:58 >>> To: Audet, Francois (SC100:3055) >>> Cc: Jonathan Rosenberg; IETF SIP List >>> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >>> >>> >>> >>> Francois Audet wrote: >>>> I'm not sure I agree with that. >>>> >>>> I think we want something that is better than the PSTN. I >>> just don't >>>> think it's the right question to ask. >>> I certainly *want* something better than PSTN. But perhaps we don't >>> *need* that. I think we do *need* something "as good as" the PSTN. >>> >>> But perhaps the first order of business is to come to agreement on >>> what we need. >> > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 18:51:04 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0741F28C722; Tue, 19 Feb 2008 18:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPxagODIjP0G; Tue, 19 Feb 2008 18:51:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1613E3A6BD4; Tue, 19 Feb 2008 18:51:03 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6055E3A6BD8 for ; Tue, 19 Feb 2008 18:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD3-UFuVX+DD for ; Tue, 19 Feb 2008 18:51:00 -0800 (PST) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id B34923A694C for ; Tue, 19 Feb 2008 18:51:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 1792E7DE7 for ; Tue, 19 Feb 2008 18:50:58 -0800 (PST) Received: from [192.168.0.100] (pool-71-161-50-169.clppva.east.verizon.net [71.161.50.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 1F2397DA4 for ; Tue, 19 Feb 2008 18:50:56 -0800 (PST) Message-ID: <47BB958A.3070206@joelhalpern.com> Date: Tue, 19 Feb 2008 21:50:50 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> <47BB34C2.1060309@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> <47BB4890.6050007@cisco.com> <47BB93F3.6060907@cisco.com> In-Reply-To: <47BB93F3.6060907@cisco.com> X-Enigmail-Version: 0.95.6 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, it is a little hard to be crisp and clear about the usage of 4474 with "numbers" when we don't know what a "number" is, nor do we know when we have one. So I am not sure that your stated goal is achievable without first solving some other problems. Yours, Joel M. Halpern Jonathan Rosenberg wrote: > Actually what I am hoping to do is to just clearly document the > applicability of RFC4474 to numbers and be much crisper with guidance on > when to use it, when to not, what it buys you with numbers (since it > does help a little even then - receivers can know the domain that > asserts that number and use blacklists/whitelists to judge trustability). > > I also want to make sure we are not basing SRTP security on integrity > properties delivered with RFC4474, when said properties aren't really > delivered so well with phone numbers. > > -Jonathan R. > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 19:11:10 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4AAC28C5F8; Tue, 19 Feb 2008 19:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfWWHbbJ89xc; Tue, 19 Feb 2008 19:11:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F276428C421; Tue, 19 Feb 2008 19:11:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABF228C34A for ; Tue, 19 Feb 2008 19:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT+wOFfvnJSF for ; Tue, 19 Feb 2008 19:11:07 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9A5F728C10D for ; Tue, 19 Feb 2008 19:11:07 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1K3Auf6008768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Feb 2008 21:10:57 -0600 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <47BB4763.1020804@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 19 Feb 2008 21:10:50 -0600 References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> <47BB4763.1020804@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Mayumi Munakata , sip@ietf.org, David R Oran Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 19, 2008, at 3:17 PM, Paul Kyzivat wrote: > In this case there is no expectation that the anonymized address > will be willing or able to report to anyone what the identity of its > client was. In the absence of any such assurance, having sip > identity is of no use. I disagree. The presence of an Identity header declares that the asserter of the anonymized identity of the address, will if suitably encouraged (as in a court order), reveal the identity of the client. If they aren't willing to take the responsibility of having made an assertion of identity on behalf of that client, then they shouldn't put an Identity header in. I might be more willing to accept a call from an anonymous party if I knew that, should said anonymous party be making a threat, my lawyer can subpoena somebody and find the culprit. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 19:22:46 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DA428C63B; Tue, 19 Feb 2008 19:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFkAs8nhxc9c; Tue, 19 Feb 2008 19:22:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CC328C6E3; Tue, 19 Feb 2008 19:22:44 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA083A684B for ; Tue, 19 Feb 2008 19:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnzwIabh87fQ for ; Tue, 19 Feb 2008 19:22:42 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7DE803A6BB8 for ; Tue, 19 Feb 2008 19:21:42 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1K3LY8T008856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Feb 2008 21:21:36 -0600 Message-Id: <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> From: Dean Willis To: Ted Hardie In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 19 Feb 2008 21:21:29 -0600 References: <47B6345B.4030807@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 19, 2008, at 4:29 PM, Ted Hardie wrote: > Howdy, > So I read this, then re-read this after having some more coffee, > and I seriously considered re-reading it again after something > alcoholic, > just so I could see whether it seemed like a good idea in any of > those states. > Since my workplace declines to provide a wet bar, I didn't manage the > last, so there is some chance I'm way off base here. > First, some comments on the mechanics. Having a "purpose" > that is not tied to the top level type of the mime type you're > transporting > opens you up to a lot of silly states. If I send you a purpose > claiming > something is a pic, but provide text/plain, is it ascii art? If I > claim it is > a pic, but provide application/octet-stream, will the data get fed to > a renderer? That is, does the MIME type or the purpose handle > disposition? > The "Semantics" session seems to indicate it is purpose that governs > this: > > Semantics: Each purpose MUST clearly define what its used for. > T he > definition must be sufficiently clear to allow an implementation > to decide whether to render the object, what kind of UI to apply, > how and where to store the object, how to process it, and so on. Well then, none of the way we use MIME in any of the "considered good" uses in SIP must make any sense. For example, with NOTIFY, the body is some sort of MIME object that may well have many different possible uses. It's the event type that tells us what that specific mime type means in the context of this NOTIFY. Otherwise said, an event package that defines a NOTIFY contain an application/octet-stream has to explain what to do with the octet- stream. What does it mean if we get a NOTIFY containing an image/jpeg? Should we display it? File it? Turn it into an mjpeg movie? Run a fingerprint recognizer on it? Apply steganogarphic analysis to extract the watermark? Here, the handling is driven by the event type, not the MIME type. That's the same as a "purpose" in TOTE. Each TOTE purpose would need to be documented, and that documentation would need to explain what MIME types can be sent for that purpose, and what it means to receive such a type in the context of a given purpose. > > > That's going to break how a lot of other things handle MIME object > transport, and incidentally call into question a very basic mechanism > for minting new application protocols currently in favor (that is, > using specialty > MIME types to trigger the handling). I'm not saying it's not a > valid design choice, > but it does run counter to the current set of trends. I also am > concerned that in using > the purpose, the design opens things up to crafted payload attacks. The whole argument against INFO is that the MIME type itself is inadequate to trigger the handling. If it were adequate, we wouldn't have had this big fight about INFO for the last n-many years. Or are you now saying INFO is good and sip-events are BAD? > Did I just wake up in a different quantum universe again? Dang it, that always confuses me. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 20:07:16 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13473A6A61; Tue, 19 Feb 2008 20:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNNdifZysGJv; Tue, 19 Feb 2008 20:07:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95043A6A9C; Tue, 19 Feb 2008 20:07:15 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631BA3A6A47 for ; Tue, 19 Feb 2008 20:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tslENqxcGH7 for ; Tue, 19 Feb 2008 20:07:12 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id F1D5E28C34A for ; Tue, 19 Feb 2008 20:06:51 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with comcast id rfnh1Y0010mv7h05A02200; Wed, 20 Feb 2008 04:06:23 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA11.westchester.pa.mail.comcast.net with comcast id rg6n1Y0020umElk3X00000; Wed, 20 Feb 2008 04:06:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=bwMbDb7QmMlOwJ6DgCEA:9 a=4_FqedBE9KVby6fZ3fkA:7 a=znur1fTe7HvM3WddoYwTuIYzi38A:4 a=mnQxEUBslVAA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m1K46kMj009475 for ; Tue, 19 Feb 2008 23:06:46 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m1K46kZc009471; Tue, 19 Feb 2008 23:06:46 -0500 Date: Tue, 19 Feb 2008 23:06:46 -0500 Message-Id: <200802200406.m1K46kZc009471@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (dean.willis@softarmor.com) References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Dean Willis Counterargument: If I call phone number X, and the responding party can complete a media-path handshake against the published key for that number, then I'd claim they "own" it. Possession is, after all, 9/10ths of the law. Whoever publishes the keys ipso facto defines who owns the numbers. And there's no reason that there would be only one publisher. Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 20:21:11 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E583028C56C; Tue, 19 Feb 2008 20:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lvk3hR-Yizq; Tue, 19 Feb 2008 20:21:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B653A6A0C; Tue, 19 Feb 2008 20:21:11 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9664D28C196 for ; Tue, 19 Feb 2008 20:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5p-SPldF2EL for ; Tue, 19 Feb 2008 20:21:09 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 884AF3A68C9 for ; Tue, 19 Feb 2008 20:21:09 -0800 (PST) Received: (qmail 81372 invoked by alias); 20 Feb 2008 04:21:04 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 20 Feb 2008 04:21:04 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id m1K4L3Yl028994 for ; Wed, 20 Feb 2008 13:21:03 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id m1K4L3t3096983 for ; Wed, 20 Feb 2008 13:21:03 +0900 (JST) (envelope-from munakata.mayumi@lab.ntt.co.jp) Received: from [192.168.23.217] (center5217.cnh.ntt-at.co.jp [192.168.23.217]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id 97CCC20843A for ; Wed, 20 Feb 2008 13:21:03 +0900 (JST) Message-ID: <47BBAA9F.7060604@lab.ntt.co.jp> Date: Wed, 20 Feb 2008 13:20:47 +0900 From: Mayumi Munakata User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: munakata.mayumi@lab.ntt.co.jp List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org See inline. David R Oran wrote: > In the absence of a reputation service and separate authentication of > the source domain I don't see any at all. What are your assumed > preconditions for this authentication to have value? I agree that it requires a separate identity service. It's my understanding that the SIP-Identity mechanism [RFC4474] makes use of separate authentication services to verify identities. Dean Willis wrote: > There is a distinct difference between a caller who is unknown to me but > known to someone who is known to me and a caller who is truly anonymous. > In the first case, if the caller proves to be "a problem", I have some > recourse through channels. In the second, I do not. > > So let us take the typical public network scenario. If all caller's > identities are known to the operator, an anonymized identifier asserted > by that operator could be used to trace a nuisance call back to the > source. That's useful: It could drive "black listing" operations, "white > listing" operations, and support legal investigation into harassment > calls, etc. Thank you for clarifying the use cases of authenticated anonymous address. I would like to include such use cases in the next version of the draft if those will be accepted as useful. Regards, Mayumi _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 20:57:38 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2665928C5FA; Tue, 19 Feb 2008 20:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9plou5lQiArn; Tue, 19 Feb 2008 20:57:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A5A3A6A63; Tue, 19 Feb 2008 20:57:37 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D02528C296 for ; Tue, 19 Feb 2008 20:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlO-TF6Ee5o8 for ; Tue, 19 Feb 2008 20:57:34 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 7FD553A6A63 for ; Tue, 19 Feb 2008 20:57:34 -0800 (PST) Received: (qmail 89295 invoked by alias); 20 Feb 2008 04:57:30 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 20 Feb 2008 04:57:30 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id m1K4vTYl003602; Wed, 20 Feb 2008 13:57:29 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id m1K4vSDZ002992; Wed, 20 Feb 2008 13:57:28 +0900 (JST) (envelope-from munakata.mayumi@lab.ntt.co.jp) Received: from [192.168.23.217] (center5217.cnh.ntt-at.co.jp [192.168.23.217]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id B99DA208439; Wed, 20 Feb 2008 13:57:28 +0900 (JST) Message-ID: <47BBB326.70702@lab.ntt.co.jp> Date: Wed, 20 Feb 2008 13:57:10 +0900 From: Mayumi Munakata User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> <47BB4763.1020804@cisco.com> In-Reply-To: Cc: sip@ietf.org, Paul Kyzivat , David R Oran Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Even if the asserter is not going to reveal identity of the client, you can at least tell whether the call is authenticated by identity service or not. On the basis of that, I might want to receive authenticated anonymous calls but reject simple anonymous calls. Mayumi Dean Willis wrote: > On Feb 19, 2008, at 3:17 PM, Paul Kyzivat wrote: > >> In this case there is no expectation that the anonymized address >> will be willing or able to report to anyone what the identity of its >> client was. In the absence of any such assurance, having sip >> identity is of no use. > > > I disagree. > > The presence of an Identity header declares that the asserter of the > anonymized identity of the address, will if suitably encouraged (as > in a court order), reveal the identity of the client. If they aren't > willing to take the responsibility of having made an assertion of > identity on behalf of that client, then they shouldn't put an Identity > header in. > > I might be more willing to accept a call from an anonymous party if I > knew that, should said anonymous party be making a threat, my lawyer > can subpoena somebody and find the culprit. > > -- > Dean > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 21:08:03 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0124828C566; Tue, 19 Feb 2008 21:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFaMaw2EAUuY; Tue, 19 Feb 2008 21:08:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2736F3A694A; Tue, 19 Feb 2008 21:08:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420C03A694A for ; Tue, 19 Feb 2008 21:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcz98Kz6mu80 for ; Tue, 19 Feb 2008 21:08:00 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 73B1A3A6909 for ; Tue, 19 Feb 2008 21:08:00 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 20 Feb 2008 00:07:43 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 20 Feb 2008 00:07:40 -0500 From: Hadriel Kaplan To: Francois Audet , Paul Kyzivat Date: Wed, 20 Feb 2008 00:09:11 -0500 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchzMbte2KtmmfeFR0eNRpz01z1oNgAABHbAABJuUpA= Message-ID: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> <47BB34C2.1060309@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Francois Audet > Sent: Tuesday, February 19, 2008 3:00 PM > > For "email-looking addresses", I believe the bar is higher (and we > have it already with 4474). Isn't that like saying we have created the best saddle for unicorns one could possible make? (and I should note that the saddle isn't even made for all humans to sit in, and isn't even very sturdy) Ok, maybe unicorn isn't quite right... maybe a Lipizzaner horse. :) -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 22:28:29 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748A83A6E18; Tue, 19 Feb 2008 22:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYHcZcYixPhr; Tue, 19 Feb 2008 22:28:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCBE3A67AC; Tue, 19 Feb 2008 22:28:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD2F3A67AC for ; Tue, 19 Feb 2008 22:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcdZo5GQqtkp for ; Tue, 19 Feb 2008 22:28:24 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id C9E193A67A9 for ; Tue, 19 Feb 2008 22:28:24 -0800 (PST) X-IronPort-AV: E=McAfee;i="5200,2160,5233"; a="808588" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2008 22:28:21 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1K6SKXx000359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Feb 2008 22:28:21 -0800 Received: from [24.4.239.115] (vpn-10-50-0-112.qualcomm.com [10.50.0.112]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1K6S5QG001375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Feb 2008 22:28:11 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> References: <47B6345B.4030807@cisco.com> <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> Date: Tue, 19 Feb 2008 22:28:03 -0800 To: Dean Willis From: Ted Hardie Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > Semantics: Each purpose MUST clearly define what its used for. >> T he >> definition must be sufficiently clear to allow an implementation >> to decide whether to render the object, what kind of UI to apply, >> how and where to store the object, how to process it, and so on. > >Well then, none of the way we use MIME in any of the "considered good" >uses in SIP must make any sense. > >For example, with NOTIFY, the body is some sort of MIME object that >may well have many different possible uses. It's the event type that >tells us what that specific mime type means in the context of this >NOTIFY. > >Otherwise said, an event package that defines a NOTIFY contain an >application/octet-stream has to explain what to do with the octet- >stream. But event packages are fairly fully specified, compared to what this draft seems to propose. If you have an extremely generic statement like "pic" and expect to extract semantics beyond that of the top level image/ mime type, I think you're going to get pretty disappointed. Now that I am re-reading after having gotten "home" (wink-wink), maybe I did miss the idea. If the idea is that the specification of "pic" or "name" is at the level of the specification of an event package, then we are dealing with something else entirely and the draft can be re-written to express that. But I would expect, in that case, for each of the registered purposes to be very carefully specified as to what the acting application would do with them. And I suspect pretty much everything like "name" would have to go. >What does it mean if we get a NOTIFY containing an image/jpeg? Should >we display it? File it? Turn it into an mjpeg movie? Run a fingerprint >recognizer on it? Apply steganogarphic analysis to extract the >watermark? Here, the handling is driven by the event type, not the >MIME type. > >That's the same as a "purpose" in TOTE. Each TOTE purpose would need >to be documented, and that documentation would need to explain what >MIME types can be sent for that purpose, and what it means to receive >such a type in the context of a given purpose. Again, if the level of specification that is expected is equivalent to event packages, this has some hope of working. Look at the IANA considerations section again, though, and I think you'll see that does not appear to be required by the current draft. > > >> >> That's going to break how a lot of other things handle MIME object >> transport, and incidentally call into question a very basic mechanism >> for minting new application protocols currently in favor (that is, >> using specialty >> MIME types to trigger the handling). I'm not saying it's not a >> valid design choice, >> but it does run counter to the current set of trends. I also am >> concerned that in using >> the purpose, the design opens things up to crafted payload attacks. > >The whole argument against INFO is that the MIME type itself is >inadequate to trigger the handling. If it were adequate, we wouldn't >have had this big fight about INFO for the last n-many years. > >Or are you now saying INFO is good and sip-events are BAD? I'm saying that what the draft appears to be replacing INFO with is as bad as INFO, as the "purpose" looks to be a mighty low-quality signal for disposition. There are some existing, common MIME types which are bad, no question. "pic", however, doesn't seem to tell you any better than image/jpeg whether to display, it file, transform it, examine it for watermarks, or print out the coupon it contains for a free helicopter ride to CityWest. Neither image/jpeg or "pic" is likely to do as you as much good as one of the application-protocol specific MIME types created with a disposition in mind, like application/atom+xml . > > > >Did I just wake up in a different quantum universe again? Dang it, >that always confuses me. Permit me to suggest a dram or two of a well-tempered liquid, preferably after it has been aged in a wood barrel of some kind. It might not result in clarity, but that won't bother you nearly as much. Ted _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 19 23:59:58 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7025528C625; Tue, 19 Feb 2008 23:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIDFT9s3mIe8; Tue, 19 Feb 2008 23:59:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475C928C45B; Tue, 19 Feb 2008 23:59:57 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FBD28C396 for ; Tue, 19 Feb 2008 23:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih1vYcX9pdA8 for ; Tue, 19 Feb 2008 23:59:54 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5228D28C45B for ; Tue, 19 Feb 2008 23:59:53 -0800 (PST) Received: (qmail invoked by alias); 20 Feb 2008 07:59:50 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp034) with SMTP; 20 Feb 2008 08:59:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/2ciQuzb72tn3IPO6rKhsjS0JPoYiJagFHXQgsZB Wlg2dXg2oH2Zpr Message-ID: <47BBDDEC.1080502@gmx.net> Date: Wed, 20 Feb 2008 09:59:40 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Henry Sinnreich References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us><47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us><47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> X-Y-GMX-Trusted: 0 Cc: IETF SIP List , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Henry, there are two aspects to the story: * Do you believe there is a problem for security when interworking between the PSTN and SIP? (e.g., in the way how SIP Identity deals with E.164 numbers) * If yes, do you think that someone should be investigating what todo about it? Don't get hung-up in the details of a specific strawman proposal that, I believe, shows quite well some of the challenges around the aspect of E.164 number ownership. Ciao Hannes Henry Sinnreich wrote: >> "Here is this problem, this is what we >> (IETF) think, the solution is in your court. Have a nice day." >> > > I believe this puts it in nutshell. > > The telecom specific uses of ENUM technology are more appropriately > handled in the telecom standards organizations, such as the ITU-T, and > ETSI. > > Let's move on and work with Internet and web addressing that I believe > have the real potential for the Internet standards development and where > IETF resources are better placed. > > Thanks, Henry > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Richard Shockey > Sent: Tuesday, February 19, 2008 10:20 AM > To: Hannes.Tschofenig@gmx.net > Cc: 'IETF SIP List'; paf@cisco.com > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > This is not to say that the IETF could play a useful and essential role. > We > can certainly develop and define the requirements, use cases etc. > > In addition the IETF can architect a solution but experience tells me > that > deployment and implementation issues surrounding e164 issues will need > the > cooperation of "other bodies" which is where the problem lies. It's not > really the ITU, in fact the ITU is a much easier place to get things > done > these days. The complications arise with the ITU member states, who > jealously guard their diplomatic and political prerogatives. > > This was the conclusion that we drew when the Infrastructure ENUM issues > first arose. We essentially said ..."Here is this problem, this is what > we > (IETF) think, the solution is in your court. Have a nice day." > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, February 19, 2008 10:49 AM >> To: Richard Shockey >> Cc: 'IETF SIP List'; paf@cisco.com >> Subject: Re: Infrastructure issues involving e164 numbers >> >> >> > If there is going to be a solution to the SIP identity problem >> involving >> > e164 numbers, it will not IMHO be solved in the IETF. >> > >> > >> Interesting view. I obviously does not appear to be an easy thing; >> in the draft I called this "There is non-neglectable deployment >> incentive challenge." >> > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 01:24:33 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C1928C6C1; Wed, 20 Feb 2008 01:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl5fofyalRuw; Wed, 20 Feb 2008 01:24:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA91D28C20D; Wed, 20 Feb 2008 01:24:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D780128C181 for ; Wed, 20 Feb 2008 01:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-rRx-hD1Ypd for ; Wed, 20 Feb 2008 01:24:29 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B4C4B28C137 for ; Wed, 20 Feb 2008 01:24:29 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWJ00MC264P8A@siemenscomms.co.uk> for sip@ietf.org; Wed, 20 Feb 2008 09:24:26 +0000 (GMT) Date: Wed, 20 Feb 2008 09:24:18 +0000 From: "Elwell, John" In-reply-to: <47B9125B.2060104@cisco.com> To: Jonathan Rosenberg , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D069860F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: Achx7G+E4aUToVTYRZqr9za1269QWwBRNjNg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, I agree with a lot of what this says. A few comments: 1. "Unfortunately, this problem is a FUNDAMENTAL PROPERTY OF PHONE NUMBERS. No specifications or efforts on the part of IETF can fix this problem. Phone numbers are fundamentally NOT scoped to a domain, and attempts to represent them in any other form are ultimately futile from an identification perspective." But on the other hand, you can at least see what domain the request came from, and if you trust that domain, this might be of value. The particular value of the user part of the SIP URI may not be some important, in some scenarios, as the domain part. This seems to be acknowledged later when it talks about the "second model". 2. "However, in the second model, intermediate domains do not resign requests. Furthermore, UA's utilize white lists and black lists of domains that are known to be trustworthy (or not). Today, such lists do exist and are provided for email spam. One can imagine a UA contacting such a service periodically, or upon an incoming call, to verify the signing domain against the list." Or maybe the user is expecting a call from a particular domain (e.g., his bank) or answers the call and the caller announces that he/she is from the bank. Of maybe the user has called his bank and uses connected-identity to ensure that he really is connected to his bank. These all seems to be situations akin to the second model with some practical benefit. 3. "Thus, DTLS-SRTP still provides better security than Sdescriptions. However, when used with phone numbers, it is by no means ideal. Most importantly, it does NOT provide guarantees that intermediaries have not been able to intercept and decrypt the media." Not true. If you use DTLS-SRTP with RFC 4474 and an E.164 number in the SIP URI, it DOES provide a guarantee that intermediaries between the domain in the SIP URI and the UAS are unable to intercept and decrypt media. This seems to be of value in some situations. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: 18 February 2008 05:07 > To: IETF SIP List > Subject: [Sip] New I-D on RFC4474 and phone numbers > > I just submitted: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc447 > 4-concerns-00.txt > > This is basically a discussion on the security properties of rfc4474 > with phone numbers, and a comparison to rfc3325 in this case. Also a > discussion on what happens to dtls-srtp. > > Comments welcome. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 01:36:04 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA85128C766; Wed, 20 Feb 2008 01:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4rtRW8yBba9; Wed, 20 Feb 2008 01:36:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F7028C713; Wed, 20 Feb 2008 01:36:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C1C3A691E for ; Wed, 20 Feb 2008 01:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHAp-cP2P4xB for ; Wed, 20 Feb 2008 01:36:00 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id A428F3A67F2 for ; Wed, 20 Feb 2008 01:36:00 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWJ000066NXAI@siemenscomms.co.uk> for sip@ietf.org; Wed, 20 Feb 2008 09:35:57 +0000 (GMT) Date: Wed, 20 Feb 2008 09:35:55 +0000 From: "Elwell, John" In-reply-to: <47BB93F3.6060907@cisco.com> To: Jonathan Rosenberg , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D069861C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: Achza4HbOtKD0u31Tvqf5npId8ytNQANvKfA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> <47BB34C2.1060309@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> <47BB4890.6050007@cisco.com> <47BB93F3.6060907@cisco.com> Cc: IETF SIP List , Francois Audet Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes, I think this is the right direction. I would not want to prevent investigations on how to do it better, e.g., based on the ENUM tree in some way. But what you propose is a practical step that gives some value in the short term, both in terms of anti-spam and DTLS-SRTP. Perhaps we also need to do even more to promote email-style SIP URIs, alongside Tel URIs for use when interworking with PSTN. This does not necessarily prevent the use of numeric values in the user part of email-style URIs (without user=phone), thereby making it easier to correlate the a SIP URI with the telephone number that would need to be used to contact the user from the PSTN. Perhaps it would be beneficial to provide both an email-style SIP URI and a Tel URI in From, so that the Tel URI can be used if the call breaks out to PSTN (where end-to-end security is not achievable) and the SIP URI can be used in other cases. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: 20 February 2008 02:44 > To: Paul Kyzivat > Cc: IETF SIP List; Francois Audet > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > Actually what I am hoping to do is to just clearly document the > applicability of RFC4474 to numbers and be much crisper with > guidance on > when to use it, when to not, what it buys you with numbers (since it > does help a little even then - receivers can know the domain that > asserts that number and use blacklists/whitelists to judge > trustability). > > I also want to make sure we are not basing SRTP security on integrity > properties delivered with RFC4474, when said properties aren't really > delivered so well with phone numbers. > > -Jonathan R. > > Paul Kyzivat wrote: > > > > > > Francois Audet wrote: > >> I think we might be talking about two different aspects. > >> > >> For "phone numbers", I agree with you that parity is ok. > >> > >> For "email-looking addresses", I believe the bar is higher (and we > >> have it already with 4474). > > > > OK. THen we aren't far apart. I agree we want and have > something better > > for email-style addresses where the domain is significant. > It is the > > "phone number" addresses I am concerned with here. I think > we must have > > parity, and ideally better when the PSTN isn't involved. > > > > Paul > > > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, > >>> February 19, 2008 11:58 > >>> To: Audet, Francois (SC100:3055) > >>> Cc: Jonathan Rosenberg; IETF SIP List > >>> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > >>> > >>> > >>> > >>> Francois Audet wrote: > >>>> I'm not sure I agree with that. > >>>> > >>>> I think we want something that is better than the PSTN. I > >>> just don't > >>>> think it's the right question to ask. > >>> I certainly *want* something better than PSTN. But > perhaps we don't > >>> *need* that. I think we do *need* something "as good as" the PSTN. > >>> > >>> But perhaps the first order of business is to come to > agreement on > >>> what we need. > >> > > > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 02:13:29 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D375B28C351; Wed, 20 Feb 2008 02:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMcNwTTktMhz; Wed, 20 Feb 2008 02:13:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1ED28C0FD; Wed, 20 Feb 2008 02:13:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA43728C0E1 for ; Wed, 20 Feb 2008 02:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evTT8dqfTJQA for ; Wed, 20 Feb 2008 02:13:25 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 924A628C0FD for ; Wed, 20 Feb 2008 02:13:25 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWJ002978E84J@siemenscomms.co.uk> for sip@ietf.org; Wed, 20 Feb 2008 10:13:20 +0000 (GMT) Date: Wed, 20 Feb 2008 10:13:26 +0000 From: "Elwell, John" In-reply-to: <47BBDDEC.1080502@gmx.net> To: Hannes.Tschofenig@gmx.net, Henry Sinnreich Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-Index: Achzlwp2hiuVC2vHTGuMgdsvnfv5vQAEHvDg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> Cc: IETF SIP List , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hannes, I know the questions were directed at Henry. However, if I may intervene: > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: 20 February 2008 08:00 > To: Henry Sinnreich > Cc: IETF SIP List; paf@cisco.com; Richard Shockey > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > Hi Henry, > > there are two aspects to the story: > > * Do you believe there is a problem for security when interworking > between the PSTN and SIP? > (e.g., in the way how SIP Identity deals with E.164 numbers) [JRE] There are actually two separate situations: use of E.164 numbers for communication within the SIP world; and use of E.164 numbers when interworking between SIP and PSTN. Did you intentionally limit your question to the second of these? Assuming that was the intention, I would point out that we can never achieve end-to-end security when interworking with PSTN. The best we can do is achieve security across the local SIP part as far as the PSTN gateway. There are different opinions as to whether the PSTN itself is secure - I won't express an opinion on that aspect. However, what happens beyond the PSTN? Another SIP hop? An H.323 hop? There is no way of knowing whether that is secured or not. Some guarantee of security as far as the gateway is the best we can achieve, and, importantly, the user should be made aware of this - do not raise his expectations concerning the end-to-end security of the call. Let's concentrate on the end-to-end SIP case and provide a good security solution for that. One possibility might be to use email-style URIs for that. John > > * If yes, do you think that someone should be investigating what todo > about it? > > Don't get hung-up in the details of a specific strawman > proposal that, I > believe, shows quite well some of the challenges around the aspect of > E.164 number ownership. > > Ciao > Hannes > > > Henry Sinnreich wrote: > >> "Here is this problem, this is what we > >> (IETF) think, the solution is in your court. Have a nice day." > >> > > > > I believe this puts it in nutshell. > > > > The telecom specific uses of ENUM technology are more appropriately > > handled in the telecom standards organizations, such as the > ITU-T, and > > ETSI. > > > > Let's move on and work with Internet and web addressing > that I believe > > have the real potential for the Internet standards > development and where > > IETF resources are better placed. > > > > Thanks, Henry > > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Richard Shockey > > Sent: Tuesday, February 19, 2008 10:20 AM > > To: Hannes.Tschofenig@gmx.net > > Cc: 'IETF SIP List'; paf@cisco.com > > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > > > This is not to say that the IETF could play a useful and > essential role. > > We > > can certainly develop and define the requirements, use cases etc. > > > > In addition the IETF can architect a solution but > experience tells me > > that > > deployment and implementation issues surrounding e164 > issues will need > > the > > cooperation of "other bodies" which is where the problem > lies. It's not > > really the ITU, in fact the ITU is a much easier place to get things > > done > > these days. The complications arise with the ITU member states, who > > jealously guard their diplomatic and political prerogatives. > > > > This was the conclusion that we drew when the > Infrastructure ENUM issues > > first arose. We essentially said ..."Here is this problem, > this is what > > we > > (IETF) think, the solution is in your court. Have a nice day." > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Tuesday, February 19, 2008 10:49 AM > >> To: Richard Shockey > >> Cc: 'IETF SIP List'; paf@cisco.com > >> Subject: Re: Infrastructure issues involving e164 numbers > >> > >> > >> > If there is going to be a solution to the SIP identity problem > >> involving > >> > e164 numbers, it will not IMHO be solved in the IETF. > >> > > >> > > >> Interesting view. I obviously does not appear to be an easy thing; > >> in the draft I called this "There is non-neglectable deployment > >> incentive challenge." > >> > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 02:53:38 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A630F28C20A; Wed, 20 Feb 2008 02:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM9EsFBtkv2y; Wed, 20 Feb 2008 02:53:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9085D3A693E; Wed, 20 Feb 2008 02:53:37 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4331A3A693E for ; Wed, 20 Feb 2008 02:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIxWsZ833DTQ for ; Wed, 20 Feb 2008 02:53:35 -0800 (PST) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 47AA13A67B3 for ; Wed, 20 Feb 2008 02:53:35 -0800 (PST) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m1KArHuc030701; Wed, 20 Feb 2008 11:53:18 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m1KArH39008236; Wed, 20 Feb 2008 11:53:17 +0100 Received: from atnets15pa.ww300.siemens.net ([158.226.250.54]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 11:53:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 11:53:20 +0100 Message-ID: <5AB8CA778E49D149B6EAEC3B864C7A8C0184136C@atnets15pa.ww300.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-Index: Achzlwp2hiuVC2vHTGuMgdsvnfv5vQAEHvDgAAFy9IA= References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com><47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us><47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us><47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us><24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com><47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> From: "Horvath, Ernst" To: "Elwell, John" , , "Henry Sinnreich" X-OriginalArrivalTime: 20 Feb 2008 10:53:16.0122 (UTC) FILETIME=[CBD3D3A0:01C873AE] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080220115317-0B21FBB0-63EBC038/0-0/0-15 X-purgate-size: 934/0 Cc: IETF SIP List , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John, > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, February 20, 2008 11:13 AM > To: Hannes.Tschofenig@gmx.net; Henry Sinnreich > Cc: IETF SIP List; paf@cisco.com; Richard Shockey > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > Hannes, > > I know the questions were directed at Henry. However, if I may > intervene: > >[...] > > Let's concentrate on the end-to-end SIP case and provide a > good security > solution for that. One possibility might be to use > email-style URIs for > that. Unfortunately email-style URIs make identity portability harder. Number portability is a regulatory requirement in many countries and solved for E.164 numbers. I can imagine that regulators might require an equivalent feature from SIP providers. Ernst > > John > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 03:40:01 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0AB28C773; Wed, 20 Feb 2008 03:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.763 X-Spam-Level: X-Spam-Status: No, score=-0.763 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63YAraOq2gYD; Wed, 20 Feb 2008 03:40:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF90128C129; Wed, 20 Feb 2008 03:40:00 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E6128C129 for ; Wed, 20 Feb 2008 03:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmxmF42pUsPB for ; Wed, 20 Feb 2008 03:39:58 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 9100428C114 for ; Wed, 20 Feb 2008 03:39:58 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWJ00739CCXJJ@siemenscomms.co.uk> for sip@ietf.org; Wed, 20 Feb 2008 11:39:51 +0000 (GMT) Date: Wed, 20 Feb 2008 11:39:23 +0000 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D069870C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] New I-D on why From/To-URIs are changed at provider borders Thread-Index: AchyZulElgl5PP+qQYG8DvAYAxoq4AAABmmgAACz7qAAUnRVYA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> Subject: Re: [Sip] New I-D on why From/To-URIs are changed at provider borders X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel, Thanks for this draft. One comments: When talking about changing the host part of SIP URIs, are you referring just to SIP URIs containing an E.164 number in telephone-subscriber format (e.g.: +123456789@example.com;user=phone)? Or are you also talking about other forms of URI that look like E.164 number (e.g., +123456789@example.com)? Presumably you are not talking about email style URIs. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: 18 February 2008 20:20 > To: IETF SIP List > Subject: [Sip] New I-D on why From/To-URIs are changed at > provider borders > > As part of an off-line discussion regarding Kai Fischer's > draft on e2e-security-media and whether his From-URI copying > tactic would succeed or not at a policy level, if rfc4474 > fails to do so, I gave my 2 cents on what some providers had > been telling me. Dan asked me to write up a draft on it, in > case people are interested. This is the draft: > http://www.ietf.org/internet-drafts/draft-kaplan-sip-uris-chan > ge-00.txt > > -hadriel > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 03:48:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3CF28C100; Wed, 20 Feb 2008 03:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVlHEXv7GuVz; Wed, 20 Feb 2008 03:48:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FCB28C116; Wed, 20 Feb 2008 03:48:52 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A843A6991 for ; Wed, 20 Feb 2008 03:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCDdB92tBxxL for ; Wed, 20 Feb 2008 03:48:49 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B7A433A697E for ; Wed, 20 Feb 2008 03:48:49 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWJ00780CT8U8@siemenscomms.co.uk> for sip@ietf.org; Wed, 20 Feb 2008 11:48:44 +0000 (GMT) Date: Wed, 20 Feb 2008 11:48:37 +0000 From: "Elwell, John" In-reply-to: <5AB8CA778E49D149B6EAEC3B864C7A8C0184136C@atnets15pa.ww300.siemens.net> To: "Horvath, Ernst" , Hannes.Tschofenig@gmx.net, Henry Sinnreich Message-id: <0D5F89FAC29E2C41B98A6A762007F5D069871B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-Index: Achzlwp2hiuVC2vHTGuMgdsvnfv5vQAEHvDgAAFy9IAAAhin0A== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <5AB8CA778E49D149B6EAEC3B864C7A8C0184136C@atnets15pa.ww300.siemens.net> Cc: IETF SIP List , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ernst, In a separate message on this list earlier today I suggested email-style along with TEL URIs. The latter would be used when interworking with PSTN and would allow number portability to be achieved. Also, for enterprises email-style still gives number portability - an enterprise would keep its domain name even when changing the SIP carrier. Admittedly that model doesn't work for an individual user that relies on the carrier's domain. John > -----Original Message----- > From: Horvath, Ernst > Sent: 20 February 2008 10:53 > To: Elwell, John; Hannes.Tschofenig@gmx.net; Henry Sinnreich > Cc: IETF SIP List; paf@cisco.com; Richard Shockey > Subject: RE: [Sip] Infrastructure issues involving e164 numbers > > John, > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Wednesday, February 20, 2008 11:13 AM > > To: Hannes.Tschofenig@gmx.net; Henry Sinnreich > > Cc: IETF SIP List; paf@cisco.com; Richard Shockey > > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > > > Hannes, > > > > I know the questions were directed at Henry. However, if I may > > intervene: > > > >[...] > > > > Let's concentrate on the end-to-end SIP case and provide a > > good security > > solution for that. One possibility might be to use > > email-style URIs for > > that. > > Unfortunately email-style URIs make identity portability > harder. Number portability is a regulatory requirement in > many countries and solved for E.164 numbers. I can imagine > that regulators might require an equivalent feature from SIP > providers. > > Ernst > > > > > John > > > > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 03:56:23 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC7D28C7AD; Wed, 20 Feb 2008 03:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8lDWHyBNQOX; Wed, 20 Feb 2008 03:56:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1144D28C155; Wed, 20 Feb 2008 03:56:21 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB203A6803 for ; Mon, 18 Feb 2008 18:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmDhz0YfwrDr for ; Mon, 18 Feb 2008 18:36:33 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by core3.amsl.com (Postfix) with ESMTP id 10F3E3A6955 for ; Mon, 18 Feb 2008 18:36:32 -0800 (PST) Received: from mailhub3.watson.ibm.com (mailhub3.watson.ibm.com [129.34.20.45]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2007-12-27 igw) with ESMTP id m1J2cW9q028158 for ; Mon, 18 Feb 2008 21:38:32 -0500 Received: from mailhub3.watson.ibm.com (localhost.localdomain [127.0.0.1]) by mailhub3.watson.ibm.com (8.13.1/8.13.1/8.13.1-01-23-2007-Delivery) with ESMTP id m1J2aUs5015484 for ; Mon, 18 Feb 2008 21:36:30 -0500 Received: from barcelona.watson.ibm.com (barcelona.watson.ibm.com [9.2.14.135]) by mailhub3.watson.ibm.com (8.13.1/8.13.1/8.13.1-01-23-2007-IMSS) with ESMTP id m1J2aTqu015478 for ; Mon, 18 Feb 2008 21:36:29 -0500 Received: from barcelona.watson.ibm.com (localhost.localdomain [127.0.0.1]) by barcelona.watson.ibm.com (8.12.11.20060308/8.12.8) with ESMTP id m1J2aTeR029656 for ; Mon, 18 Feb 2008 21:36:29 -0500 Received: (from nahum@localhost) by barcelona.watson.ibm.com (8.12.11.20060308/8.12.11/Submit) id m1J2aTUO029654 for sip@ietf.org; Mon, 18 Feb 2008 21:36:29 -0500 Date: Mon, 18 Feb 2008 21:36:29 -0500 From: Erich Nahum To: sip@ietf.org Message-ID: <20080219023629.GB29627@barcelona.watson.ibm.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 20 Feb 2008 03:56:19 -0800 Subject: [Sip] SPEC SIP benchmarking effort X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Erich Nahum List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I wanted to make people on this list aware of an effort at SPEC to develop an industry-standard SIP benchmark. SPEC is a non-profit corporation formed to establish, maintain and endorse a standardized set of relevant benchmarks that can be applied to the newest generation of high-performance computers. SPEC develops benchmark suites and also reviews and publishes submitted results from our member organizations and other benchmark licensees. The SPEC SIP SubCommittee was established in March of 2007 and has been chartered with designing, developing, and releasing a benchmark. The benchmark design document is completed, and development of the benchmark is under way with an expected release date of 2Q 2008. The design document is available for review at http://www.spec.org/specsip The design document is a result of a collaborative, consensus effort with participation from AMD, BEA, Columbia University, Communigate Systems, HP, Intel, IBM, and Sun Microsystems. There is also a design FAQ to answer common questions. I'm making this announcement for two reasons: - To solicit feedback about the design document. Most of our members are on the server side rather than ISP or NEP side, and getting additional perspective would of course help. - To encourage participation in the SPEC SIP SubCommittee. There's still plenty of opportunity to influence the benchmark and help in the development, testing, and documentation. While participating in SPEC does cost money, we can allow temporary participation on a trial basis in the SubCommittee so that people can test it out and see if they want to pursue it. We have weekly calls on Thursdays at 10:00 AM Pacific. We could also schedule an extra call if there is enough demand. You can find out more about SPEC membership at http://www.spec.org/spec/membership.html Please contact me if interested. I'll also try to respond to any comments about the design document posted on the mailing list. Thanks, -Erich -- Erich M. Nahum IBM T.J. Watson Research Center Research Staff Member P.O. Box 704 nahum@watson.ibm.com Yorktown Heights NY 10598 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 03:58:11 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1634028C803; Wed, 20 Feb 2008 03:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.717 X-Spam-Level: X-Spam-Status: No, score=-100.717 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVCIb-0tiVqA; Wed, 20 Feb 2008 03:58:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47C328C7AD; Wed, 20 Feb 2008 03:56:43 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09EBD3A6ABF; Tue, 19 Feb 2008 07:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhyVS2eF3YX5; Tue, 19 Feb 2008 07:43:39 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 46B063A6A47; Tue, 19 Feb 2008 07:43:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1203435813!24826826!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23505 invoked from network); 19 Feb 2008 15:43:33 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 19 Feb 2008 15:43:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m1JFhXJ8007999; Tue, 19 Feb 2008 10:43:33 -0500 Received: from ACCLUST02EVS1.ugd.att.com (acst03.ugd.att.com [135.37.16.8]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m1JFhTF5007981; Tue, 19 Feb 2008 10:43:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 10:43:29 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A11EFFB31@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <0af801c87308$3a672530$af356f90$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchyyF2iXQBrESw/QcejEIi4+p7SEgAPvGPwAAGwwEA= References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> <134a01c8727c$0d3530c0$279f9240$@us><47BA8421.9040209@gmx.net> <0af801c87308$3a672530$af356f90$@us> From: "PFAUTZ, PENN L, ATTCORP" To: "Richard Shockey" , X-Mailman-Approved-At: Wed, 20 Feb 2008 03:56:43 -0800 Cc: IETF SIP List , enum@ietf.org Subject: Re: [Sip] [Enum] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org = Section 3.2 suggests there is no definition for Infrastructure ENUM. At lea= st reference RFC 5067! Section 3.3 wallet garden model? I like that :-) = Is there a reason why a carrier can't use infrastructure ENUM to certify a = given populated caller ID using a general rather than a specific key? (If t= hey were willing to) Penn Pfautz AT&T National Access Management +1-732-420-4962 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Ric= hard Shockey Sent: Tuesday, February 19, 2008 10:01 AM To: Hannes.Tschofenig@gmx.net Cc: 'IETF SIP List'; enum@ietf.org; 'Paul Kyzivat' Subject: Re: [Enum] [Sip] New I-D on RFC4474 and phone numbers Well ENUM is on a short leash in Philadelphia with only 1 hour, we are trying to slowly but deliberately wind things down. It might not be the best time, but we certainly have large body of expertise in dealing with E.164 numbers and the history of trying to deal with number mappings in globally distributed databases. :-) = It's certainly something worth discussing the ENUM WG list from time to time but the real issues are all layer 8 and above. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, February 19, 2008 2:24 AM > To: Richard Shockey > Cc: 'IETF SIP List'; 'Paul Kyzivat' > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > = > Hi Richard > = > I have thought about that. When I spoke to a couple of people about > requesting a slot in ENUM they told me that ENUM is not the right > place > to discuss this. > Feedback from the ENUM WG would certainly be helpful. ; > = > Ciao > Hannes > = > Richard Shockey wrote: > > So did you guys want a slot during the ENUM WG? > > > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf > Of > >> Tschofenig, Hannes (NSN - FI/Espoo) > >> Sent: Monday, February 18, 2008 2:55 PM > >> To: ext Jonathan Rosenberg; Paul Kyzivat > >> Cc: IETF SIP List > >> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > >> > >> Hi Jonathan, > >> Hi Paul, > >> > >> thanks for raising the aspect of E.164 and ENUM usage. There was > an > >> offline discussion between Dan Wing, Klaus Darilion, Kai Fischer, > >> David Schwartz, Hadriel Kaplan, John Elwell, and myself about > E.164 > >> and SIP Identity. As part of the discussion Klaus and I polished a > >> former document of Alexander Mayrhofer on the usage of ENUM for > E.164 > >> numbers (see draft-mayrhofer-enum-domainkeys-00). As we moved > along > >> with the work we obviously came across a couple of problems (as > one > >> can easily imagine) and the document triggered a long discussion > among > >> us. Dispite a couple of challenges, we published the document > today > >> (see http://www.ietf.org/internet-drafts/draft-darilion-sip-e164- > enum- > >> 00.txt). I learned a lot while working on that document. > >> > >> In addition to publishing the document a few of us have also > worked on > >> a document that captures some of our discussion on E.164 number > >> ownership. I will publish it very soon -- just a bit more proof- > >> reading. > >> > >> Ciao > >> Hannes > >> > >> > -----Urspr=FCngliche Nachricht----- > >> > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im > >> > Auftrag von ext Jonathan Rosenberg > >> > Gesendet: Montag, 18. Februar 2008 21:36 > >> > An: Paul Kyzivat > >> > Cc: IETF SIP List > >> > Betreff: Re: [Sip] New I-D on RFC4474 and phone numbers > >> > > >> > I agree that something along the lines of enum could solve > >> > this problem, > >> > and I believe there was a draft that proposed such a thing. This > has > >> > been discussed since the start of rfc4474. > >> > > >> > However, I fear that saying, 'use enum' is kind of like saying, > >> we'll > >> > just use an All-Knowing Oracle, so lets figure out the interface > >> > protocol to the Oracle. The easy part is the interface (the enum > >> > mechanism). The actual hard problem is how to get those entries > >> > populated. The deployment of public enum has been - shall we > >> > say - less > >> > than spectacular. I'd hate for that to be our only solution. Not > >> that > >> > its obvious what else to do; though I do suggest in my draft > >> > how domain > >> > based authentication, when combined with whitelists and > >> > blacklists, can > >> > help. > >> > > >> > -Jonathan R. > >> > > >> > Paul Kyzivat wrote: > >> > > Jonathan, > >> > > > >> > > I guess the time has come for this discussion, since John > >> > Ewell has also > >> > > submitted a draft on this subject. > >> > > > >> > > I thought the problem was already well known, but perhaps > >> > not. IMO the > >> > > main thing now is to figure out the *solution* to the problem! > >> > > IMO a solution is to use a 4474-style approach, but where the > >> > > certificate is tied to just the phone number, not to some > >> arbitrary > >> > > domain name. That of course would depend on a model where > >> > the "owner" of > >> > > the phone number is the one who may obtain the certificate > >> > for that number. > >> > > > >> > > My thought is that we already have an algorithmic mapping > >> > from an E.164 > >> > > phone number to a domain name, defined by enum. If the > >> > sender puts an > >> > > E.164 number in From, and can sign it with a cert for the > >> > enum mapped > >> > > domain name corresponding to that number, then that ought > >> > to be valid > >> > > proof of the validity of the sender. > >> > > > >> > > In those places where public enum is in operation, I think > there > >> is > >> > > already a legal mechanism in place to give the owner of record > of > >> a > >> > > particular phone number control over the contents of the > >> > corresponding > >> > > DNS entry. That should also be sufficient to allow a > certificate > >> > > authority to assign a cert to that same owner. > >> > > > >> > > Combine all that and you have a complete e2e identity model > >> > for phone > >> > > numbers, based on public enum. And that can be true even if > >> > public enum > >> > > isn't used to *route* the calls to that number. So it could > >> > be used for > >> > > "unlisted" numbers. > >> > > > >> > > To use this approach the From header should contain either > >> > a TEL URI, or > >> > > a sip/sips URI containing the enum-mapped domain name > >> > corresponding to > >> > > the phone number. (I would rather see the TEL used for this > >> > - it is more > >> > > user friendly.) > >> > > > >> > > Thanks, > >> > > Paul > >> > > > >> > > Jonathan Rosenberg wrote: > >> > >> I just submitted: > >> > >> > >> > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc447 > >> > 4-concerns-00.txt > >> > >> > >> > >> > >> > >> This is basically a discussion on the security properties > >> > of rfc4474 > >> > >> with phone numbers, and a comparison to rfc3325 in this > >> > case. Also a > >> > >> discussion on what happens to dtls-srtp. > >> > >> > >> > >> Comments welcome. > >> > >> > >> > >> -Jonathan R. > >> > > > >> > > >> > -- > >> > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > >> > Cisco Fellow Edison, NJ 08837 > >> > Cisco, Voice Technology Group > >> > jdrosen@cisco.com > >> > http://www.jdrosen.net PHONE: (408) 902- > 3084 > >> > http://www.cisco.com > >> > _______________________________________________ > >> > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> > This list is for NEW development of the core SIP Protocol > >> > Use sip-implementors@cs.columbia.edu for questions on current > sip > >> > Use sipping@ietf.org for new developments on the application of > sip > >> > > >> _______________________________________________ > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of > sip > >> > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > = > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 04:06:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5D328C741; Wed, 20 Feb 2008 04:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLCSaNZFgACE; Wed, 20 Feb 2008 04:06:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35FF93A6991; Wed, 20 Feb 2008 04:06:26 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3198C28C12A for ; Wed, 20 Feb 2008 04:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVcHWQcVJTa3 for ; Wed, 20 Feb 2008 04:06:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 01A933A6991 for ; Wed, 20 Feb 2008 04:06:23 -0800 (PST) Received: (qmail invoked by alias); 20 Feb 2008 12:06:19 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp044) with SMTP; 20 Feb 2008 13:06:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+9ejJ/FkO9lgqCplSlbzGkvAx8siGNtBAvelDXdO sQAFDBoEu60DYY Message-ID: <47BC17B2.4030807@gmx.net> Date: Wed, 20 Feb 2008 14:06:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Elwell, John" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <5AB8CA778E49D149B6EAEC3B864C7A8C0184136C@atnets15pa.ww300.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D069871B@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D069871B@GBNTHT12009MSX.gb002.siemens.net> X-Y-GMX-Trusted: 0 Cc: "Horvath, Ernst" , IETF SIP List , Henry Sinnreich , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi John, you are essentially suggesting to use an identifier like +123456789@example.com;user=phone whereby example.com corresponds to the domain that operates the authentication service? Ciao Hannes Elwell, John wrote: > Ernst, > > In a separate message on this list earlier today I suggested email-style > along with TEL URIs. The latter would be used when interworking with > PSTN and would allow number portability to be achieved. > > Also, for enterprises email-style still gives number portability - an > enterprise would keep its domain name even when changing the SIP > carrier. Admittedly that model doesn't work for an individual user that > relies on the carrier's domain. > > John > > >> -----Original Message----- >> From: Horvath, Ernst >> Sent: 20 February 2008 10:53 >> To: Elwell, John; Hannes.Tschofenig@gmx.net; Henry Sinnreich >> Cc: IETF SIP List; paf@cisco.com; Richard Shockey >> Subject: RE: [Sip] Infrastructure issues involving e164 numbers >> >> John, >> >> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>> Behalf Of Elwell, John >>> Sent: Wednesday, February 20, 2008 11:13 AM >>> To: Hannes.Tschofenig@gmx.net; Henry Sinnreich >>> Cc: IETF SIP List; paf@cisco.com; Richard Shockey >>> Subject: Re: [Sip] Infrastructure issues involving e164 numbers >>> >>> Hannes, >>> >>> I know the questions were directed at Henry. However, if I may >>> intervene: >>> >>> [...] >>> >>> Let's concentrate on the end-to-end SIP case and provide a >>> good security >>> solution for that. One possibility might be to use >>> email-style URIs for >>> that. >>> >> Unfortunately email-style URIs make identity portability >> harder. Number portability is a regulatory requirement in >> many countries and solved for E.164 numbers. I can imagine >> that regulators might require an equivalent feature from SIP >> providers. >> >> Ernst >> >> >>> John >>> >>> _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 04:30:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE5F28C159; Wed, 20 Feb 2008 04:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Va0htQsgXLx; Wed, 20 Feb 2008 04:30:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE93728C102; Wed, 20 Feb 2008 04:30:31 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE103A6A0E for ; Wed, 20 Feb 2008 04:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8KDCEJTPrjI for ; Wed, 20 Feb 2008 04:22:50 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E96283A6A00 for ; Wed, 20 Feb 2008 04:22:49 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Feb 2008 13:22:44 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1KCMiXI015332; Wed, 20 Feb 2008 13:22:44 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1KCMZp6019334; Wed, 20 Feb 2008 12:22:35 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 13:22:37 +0100 Received: from junior.frobbit.se ([10.61.82.223]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 13:22:37 +0100 Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey In-Reply-To: <0fe501c8732b$14e2e060$3ea8a120$@us> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 07:15:58 +0100 References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us><47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <072801c87321$d5c8f0d0$c4f0200a@cisco.com> <0fe501c8732b$14e2e060$3ea8a120$@us> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 20 Feb 2008 12:22:37.0585 (UTC) FILETIME=[47822810:01C873BB] Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Mailman-Approved-At: Wed, 20 Feb 2008 04:30:30 -0800 Cc: 'IETF SIP List' , 'Dan Wing' Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0925534303==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0925534303== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-40--304824127" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-40--304824127 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit This should not be a surprise to anyone... Due to the complex management of of E.164 numbers, which includes management, routing to, billing models and everything else, I have personally all the time thought sip-email-like addresses "win". That will be the format used for routing of "calls" in the future. Full stop. What ENUM solves is something that can be viewed as an intermediary problem on mapping from the (old) E.164 addressing to the (new) domain name based. Sure, E.164 numbers will be around for a Very Long Time, but domain based address is what the Internet use, and what people will use in the future. And btw, even more quickly grows the use of VCard like mechanisms (electronic business cards) which imply the end user have absolutely no idea what identifier is used to set up the call. The application select the fragment of the VCard that it can understand, and routing mechanisms (on application layer) must be smart enough to ensure the call setup actually works. Because of this, of course E.164 based mechanisms MUST work also on the Internet, but it MUST at the same time be remembered that it is an old technology that will not grow anymore. Because of this I urge people to NOT base any service/application solutions on the function, working and deployment of E.164 numbers. Please use Domain Name based addressing instead. Patrik --Apple-Mail-40--304824127 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFHu8WfvHlR2X0luNwRAvo2AJsFMDjgUF4YiCZpAy5cGSP/FEE0LACfdCKx HvBf/4WehsP6s1cfnqG4Nb0= =9RKd -----END PGP SIGNATURE----- --Apple-Mail-40--304824127-- --===============0925534303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0925534303==-- From sip-bounces@ietf.org Wed Feb 20 04:35:13 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDFA28C2FC; Wed, 20 Feb 2008 04:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-1.578, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYL0eavAQ+vG; Wed, 20 Feb 2008 04:35:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284D228C12A; Wed, 20 Feb 2008 04:35:12 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0C728C12A for ; Wed, 20 Feb 2008 04:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3KOAjFPgark for ; Wed, 20 Feb 2008 04:35:10 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B2C5328C118 for ; Wed, 20 Feb 2008 04:35:10 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Feb 2008 07:35:06 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1KCZ51u023496; Wed, 20 Feb 2008 07:35:05 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1KCYaWJ019539; Wed, 20 Feb 2008 12:35:00 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 07:34:59 -0500 Received: from [10.86.241.39] ([10.86.241.39]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 07:34:59 -0500 Message-ID: <47BC1E7E.5070303@cisco.com> Date: Wed, 20 Feb 2008 07:35:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> <47BB4763.1020804@cisco.com> In-Reply-To: X-OriginalArrivalTime: 20 Feb 2008 12:34:59.0709 (UTC) FILETIME=[01D94AD0:01C873BD] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Mayumi Munakata , sip@ietf.org, David R Oran Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, I don't think I agree. In the non-anonymous case, the asserter will attest that the source is entitled to claim the address. AFAIK nothing else is implied. But assume it will provide more - for instance the name, address, and SS# of the person entitled to the address. Now assume that the address is an "anonymous" address. The asserter will then be providing information about the anonymizer, not the entity that is being anonymized. Its entirely possible (likely) that the anonymizer won't maintain records that would give it the capability of reporting on the address being anonymized. Paul Dean Willis wrote: > On Feb 19, 2008, at 3:17 PM, Paul Kyzivat wrote: > >> In this case there is no expectation that the anonymized address will >> be willing or able to report to anyone what the identity of its client >> was. In the absence of any such assurance, having sip identity is of >> no use. > > > I disagree. > > The presence of an Identity header declares that the asserter of the > anonymized identity of the address, will if suitably encouraged (as in > a court order), reveal the identity of the client. If they aren't > willing to take the responsibility of having made an assertion of > identity on behalf of that client, then they shouldn't put an Identity > header in. > > I might be more willing to accept a call from an anonymous party if I > knew that, should said anonymous party be making a threat, my lawyer > can subpoena somebody and find the culprit. > > -- > Dean > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 04:44:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931D428C7BD; Wed, 20 Feb 2008 04:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SFgoQHRqIPD; Wed, 20 Feb 2008 04:44:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAE328C14B; Wed, 20 Feb 2008 04:44:06 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA8C28C14B for ; Wed, 20 Feb 2008 04:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2XnMR+Xx5DA for ; Wed, 20 Feb 2008 04:44:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6F99728C0ED for ; Wed, 20 Feb 2008 04:44:04 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2008 07:44:01 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1KCi1qT025812; Wed, 20 Feb 2008 07:44:01 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1KCi0WD022096; Wed, 20 Feb 2008 12:44:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 07:44:00 -0500 Received: from [10.86.241.39] ([10.86.241.39]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 07:44:00 -0500 Message-ID: <47BC209A.2080902@cisco.com> Date: Wed, 20 Feb 2008 07:44:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mayumi Munakata References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> <47BB4763.1020804@cisco.com> <47BBB326.70702@lab.ntt.co.jp> In-Reply-To: <47BBB326.70702@lab.ntt.co.jp> X-OriginalArrivalTime: 20 Feb 2008 12:44:00.0420 (UTC) FILETIME=[44233E40:01C873BE] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, David R Oran , Dean Willis Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If some UAS prefers an anonymous address that has been authenticated, then I have no objection, though I consider it irrational. But I don't see this as a necessary condition for a privacy mechanism. Paul Mayumi Munakata wrote: > Even if the asserter is not going to reveal identity of the client, > you can at least tell whether the call is authenticated by identity > service or not. On the basis of that, I might want to receive > authenticated anonymous calls but reject simple anonymous calls. > > Mayumi > > > Dean Willis wrote: >> On Feb 19, 2008, at 3:17 PM, Paul Kyzivat wrote: >> >>> In this case there is no expectation that the anonymized address >>> will be willing or able to report to anyone what the identity of its >>> client was. In the absence of any such assurance, having sip >>> identity is of no use. >> >> >> I disagree. >> >> The presence of an Identity header declares that the asserter of the >> anonymized identity of the address, will if suitably encouraged (as >> in a court order), reveal the identity of the client. If they aren't >> willing to take the responsibility of having made an assertion of >> identity on behalf of that client, then they shouldn't put an >> Identity header in. >> >> I might be more willing to accept a call from an anonymous party if I >> knew that, should said anonymous party be making a threat, my lawyer >> can subpoena somebody and find the culprit. >> >> -- >> Dean >> > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 06:25:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B173528C741; Wed, 20 Feb 2008 06:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=-1.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mr1Ns1b9drNA; Wed, 20 Feb 2008 06:25:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A607B28C1B8; Wed, 20 Feb 2008 06:25:47 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA0928C1B8 for ; Wed, 20 Feb 2008 06:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKoe+jAXRV52 for ; Wed, 20 Feb 2008 06:25:46 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0DF2028C16F for ; Wed, 20 Feb 2008 06:25:46 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2008 06:25:43 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1KEPh6W008969; Wed, 20 Feb 2008 06:25:43 -0800 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 m1KEPguL005742; Wed, 20 Feb 2008 14:25:42 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 06:25:42 -0800 Received: from [128.107.103.186] ([128.107.103.186]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 06:25:41 -0800 Message-ID: <47BC385A.40702@cisco.com> Date: Wed, 20 Feb 2008 09:25:30 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Elwell, John" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> <47BB34C2.1060309@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> <47BB4890.6050007@cisco.com> <47BB93F3.6060907@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069861C@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D069861C@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 20 Feb 2008 14:25:41.0828 (UTC) FILETIME=[78DC3840:01C873CC] Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: IETF SIP List , Paul Kyzivat , Francois Audet Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Yes, I think this is the right direction. I would not want to prevent > investigations on how to do it better, e.g., based on the ENUM tree in > some way. But what you propose is a practical step that gives some value > in the short term, both in terms of anti-spam and DTLS-SRTP. > > Perhaps we also need to do even more to promote email-style SIP URIs, well, having tried to do that for something like ten years now, and having STILL seen the industry primarily doing pstn replacement which requires phone numbers, I am somewhat skeptical that there is anything IETF can do here. > alongside Tel URIs for use when interworking with PSTN. This does not > necessarily prevent the use of numeric values in the user part of > email-style URIs (without user=phone), thereby making it easier to > correlate the a SIP URI with the telephone number that would need to be > used to contact the user from the PSTN. Perhaps it would be beneficial > to provide both an email-style SIP URI and a Tel URI in From, so that > the Tel URI can be used if the call breaks out to PSTN (where end-to-end > security is not achievable) and the SIP URI can be used in other cases. Now that is a topic worth discussing. From can only have a single URI. Interestingly PAI does allow more; you can assert both a tel and a SIP URI. What would be really nice is to be able to assert both the phone number and the username in the From and have the domain covered by the 4474 signature. As my draft points out, there is some small value in the 4474 signature there. One way to do this for example would be something horrible like this: From: sip:jdrosen*+14089023084@cisco.com;user=composite where "composite" means that the user part is a series of names within the domain, each one separated by "*". Unfortunately that would work much better in theory than in practice since I think most implementations ignore the user attribute of the URI and would not know that they shouldn't render this weird looking user part. Probably the better solution is some hybrid where PAI is used for the phone numbers and 4474 for the user@domain identifier. Thats another thing useful we could do, is to try and clarify how PAI and 4474 work in concert. Right now that is clear as mud. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 06:47:54 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7CDA28C747; Wed, 20 Feb 2008 06:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.573 X-Spam-Level: X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx7YRWYps+zo; Wed, 20 Feb 2008 06:47:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373423A6965; Wed, 20 Feb 2008 06:47:53 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4501F28C1EB for ; Wed, 20 Feb 2008 06:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZI8EXgSu1ub for ; Wed, 20 Feb 2008 06:47:46 -0800 (PST) Received: from mail.strom.cz (mail.strom.cz [89.111.70.111]) by core3.amsl.com (Postfix) with ESMTP id B0ECE28C82C for ; Wed, 20 Feb 2008 06:47:38 -0800 (PST) Received: from exalfa.stromtelecom.cz ([172.16.16.10]) by mail.strom.cz with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 15:47:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 15:46:54 +0100 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE2918001BB7CE2@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-06 Thread-Index: Acg5CAVYvVaurdFmT0G+mU6ExOtR0AqbKTcwBBZ+9/A= References: <5D1A7985295922448D5550C94DE29180019F7594@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE2918001BB7CE2@DEEXC1U01.de.lucent.com> From: "Kolomaznik Jan" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 20 Feb 2008 14:47:33.0366 (UTC) FILETIME=[86990960:01C873CF] Cc: slawrence@bluesocket.com, alan.ietf@polyphase.ca Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I am sorry for my late answer. After long time I have found time for the draft-ietf-sip-fork-loop-fix-06 reading. I have following notices: 1) Section 3 contains small typo in paragraph under the figure 2. There is written "If the endpoint and two proxies involved follow RFC 3260 recommendations, the tree ..." - There should be RFC 3261. 2) Section 4.1: The 2nd and 4th paragraph uses different words in the same meaning - "destination" and "location". My opinion is that it could be a little misleading. I thing the word "location" is according to RFC 3261 terminology. 3) The draft-ietf-sip-fork-loop-fix-06 shows and describes in detail two horrible examples when a proxy follows only RFC 3261 recommendations. Why this document doesn't also show result of recommendations described by this document? I thing something like following text is very motivating for implementation of shown recommendations. When proxies follow recommendation of RFC XXXX, the number of stimulated messages is reduced to 14 and message tree looks like depicted on Figure X. In case of simplified attack using twice the same uri with two different uri parameters, the number of stimulated messages is reduced to 10. | a@P1 / \ / \ / \ / \ a@P2 b@P2 / \ / \ / \ / \ / \ / \ a@P1 b@P1 a@P1 b@P1 / \ / \ a@P2 b@P2 a@P2 b@P2 /\ /\ / \ / \ a@P1 b@P1 a@P1 b@P1 Figure X: Attack request propagation when RFC XXXX recommendations applied Jan Kolomaznik -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Wednesday, January 30, 2008 8:19 PM To: DRAGE, Keith (Keith); sip@ietf.org Cc: slawrence@bluesocket.com; alan.ietf@polyphase.ca Subject: RE: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-06 (As WG chair) There were no comments in response to this WGLC, so I propose to submit a publish request for it shortly. If it is still on your pending list to look at, then immediately would be a good time to get round to it. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Friday, December 07, 2007 7:33 PM > To: sip@ietf.org > Cc: alan.ietf@polyphase.ca; slawrence@bluesocket.com > Subject: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-06 > > (As WG chair) > > This document has a somewhat complicated history, in that we > completed it once in the WG and sent it to the IESG, but it > came back from them because of concerns over security issues. > > The editor's have now followed the instructions from the > previous meeting, i.e. to: > > Integrated Max-Breadth based on working group discussion of the > secdir review > > Added a paragraph pointing out that removing or modifying other > node's branch parameters defeats their ability to loop detect > > Moved the total number of messages from O(2^70) to O(2^71) based > on an observation by Jan Kolomaznik. To see this, note that the > total number of requests is the sum from i=0 to Max-Forwards of > 2^i which is 2^(Max-Forwards+1) - 1. The point of the text > doesn't change - (the point being that the number is _big_). > > Made the new 4xx concrete (choosing 440) > > Added a sentence reinforcing that if you forward to only one > branch, you still potentially have a constant multiplier of > messages in the network as Max-Forwards runs out (based on > feedback from Thomas Cross.) > > These changes are significant enough to justify a revised > WGLC, and I would therefore like the working group to review > the document and provide comments to the SIP list and authors by > > Friday 21st December 2007. > > It would be appropriate to concentrate on the text with the > changes identified about. > > The document may be found at: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-f > ix-06.txt > > And the wdiff document may be found at: > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://to > ols.ietf.o > rg/id/draft-ietf-sip-fork-loop-fix-06.txt > > [Note that unfortunately this identifies a significant > portion of text as new text, when it fact it merely moved.] > > Regards > > Keith > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 07:18:20 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F3828C0F6; Wed, 20 Feb 2008 07:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCTYafob5zJN; Wed, 20 Feb 2008 07:18:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0506628C101; Wed, 20 Feb 2008 07:18:19 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812D728C0F6 for ; Wed, 20 Feb 2008 07:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkY6x5KpT0kg for ; Wed, 20 Feb 2008 07:18:17 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A8B5828C101 for ; Wed, 20 Feb 2008 07:18:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,381,1199692800"; d="scan'208";a="13739642" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2008 07:18:14 -0800 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.145.37]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m1KF5AvY003101; Wed, 20 Feb 2008 07:05:10 -0800 Message-ID: <47BC44BE.2060007@cisco.com> Date: Wed, 20 Feb 2008 07:18:22 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Jonathan Rosenberg References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> <47BB34C2.1060309@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> <47BB4890.6050007@cisco.com> <47BB93F3.6060907@cisco.com> In-Reply-To: <47BB93F3.6060907@cisco.com> Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: IETF SIP List , Paul Kyzivat , Francois Audet Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Actually what I am hoping to do is to just clearly document the > applicability of RFC4474 to numbers and be much crisper with guidance on > when to use it, when to not, what it buys you with numbers (since it > does help a little even then - receivers can know the domain that > asserts that number and use blacklists/whitelists to judge trustability). > > I also want to make sure we are not basing SRTP security on integrity > properties delivered with RFC4474, when said properties aren't really > delivered so well with phone numbers. > I'd say that the sooner that we stop worrying about what happens when the signaling and media streams cease to be transported by IP, the sooner our sanity will seek us out again. Or even less than that. We can't possibly even enumerate all of the potential hazards even within the IP realm like, oh say, media->email/MIME attachments re-posted to Usenet. Mike > -Jonathan R. > > Paul Kyzivat wrote: > >> Francois Audet wrote: >> >>> I think we might be talking about two different aspects. >>> >>> For "phone numbers", I agree with you that parity is ok. >>> >>> For "email-looking addresses", I believe the bar is higher (and we >>> have it already with 4474). >>> >> OK. THen we aren't far apart. I agree we want and have something better >> for email-style addresses where the domain is significant. It is the >> "phone number" addresses I am concerned with here. I think we must have >> parity, and ideally better when the PSTN isn't involved. >> >> Paul >> >> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, >>>> February 19, 2008 11:58 >>>> To: Audet, Francois (SC100:3055) >>>> Cc: Jonathan Rosenberg; IETF SIP List >>>> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers >>>> >>>> >>>> >>>> Francois Audet wrote: >>>> >>>>> I'm not sure I agree with that. >>>>> >>>>> I think we want something that is better than the PSTN. I >>>>> >>>> just don't >>>> >>>>> think it's the right question to ask. >>>>> >>>> I certainly *want* something better than PSTN. But perhaps we don't >>>> *need* that. I think we do *need* something "as good as" the PSTN. >>>> >>>> But perhaps the first order of business is to come to agreement on >>>> what we need. >>>> > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 07:18:33 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE3028C833; Wed, 20 Feb 2008 07:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=-1.959, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL-IVeOdx1RN; Wed, 20 Feb 2008 07:18:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DECC28C81C; Wed, 20 Feb 2008 07:18:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2609228C81C for ; Wed, 20 Feb 2008 07:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-AohdbW-hOF for ; Wed, 20 Feb 2008 07:18:29 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D40CA28C18D for ; Wed, 20 Feb 2008 07:18:28 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2008 07:18:25 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1KFIOsU023526; Wed, 20 Feb 2008 07:18:24 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1KFI6w7014684; Wed, 20 Feb 2008 15:18:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 10:18:13 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 10:18:12 -0500 Message-ID: <47BC44C0.6050801@cisco.com> Date: Wed, 20 Feb 2008 10:18:24 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Elwell, John" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 20 Feb 2008 15:18:13.0014 (UTC) FILETIME=[CF1D0B60:01C873D3] Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: IETF SIP List , Henry Sinnreich , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It seems that we have two parallel worlds: one using email-style addresses and another using phone numbers. While there are some devices that can play in both worlds, the majority of devices can only play in one of the worlds, or at least are strongly biased towards one so that usability with the other form is compromised. It seems essential that sip find a way to be successful in the phone number world - at least to the extent that a sip device in not perceived as being functionally worse than a comparable device using PSTN protocols. No amount of arguing that things would be better if you just used an email-style address will win the day there. The alternative is to accept that sip is worse than native PSTN equipment for phone numbers, and hope that the parallel communications world based on email-style addresses will eventually win out. But that is like waiting for IPv4 to be replaced by IPv6. Paul Elwell, John wrote: > Hannes, > > I know the questions were directed at Henry. However, if I may > intervene: > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Hannes Tschofenig >> Sent: 20 February 2008 08:00 >> To: Henry Sinnreich >> Cc: IETF SIP List; paf@cisco.com; Richard Shockey >> Subject: Re: [Sip] Infrastructure issues involving e164 numbers >> >> Hi Henry, >> >> there are two aspects to the story: >> >> * Do you believe there is a problem for security when interworking >> between the PSTN and SIP? >> (e.g., in the way how SIP Identity deals with E.164 numbers) > [JRE] There are actually two separate situations: use of E.164 numbers > for communication within the SIP world; and use of E.164 numbers when > interworking between SIP and PSTN. Did you intentionally limit your > question to the second of these? > Assuming that was the intention, I would point out that we can never > achieve end-to-end security when interworking with PSTN. The best we can > do is achieve security across the local SIP part as far as the PSTN > gateway. There are different opinions as to whether the PSTN itself is > secure - I won't express an opinion on that aspect. However, what > happens beyond the PSTN? Another SIP hop? An H.323 hop? There is no way > of knowing whether that is secured or not. Some guarantee of security as > far as the gateway is the best we can achieve, and, importantly, the > user should be made aware of this - do not raise his expectations > concerning the end-to-end security of the call. > > Let's concentrate on the end-to-end SIP case and provide a good security > solution for that. One possibility might be to use email-style URIs for > that. > > John > >> * If yes, do you think that someone should be investigating what todo >> about it? >> >> Don't get hung-up in the details of a specific strawman >> proposal that, I >> believe, shows quite well some of the challenges around the aspect of >> E.164 number ownership. >> >> Ciao >> Hannes >> >> >> Henry Sinnreich wrote: >>>> "Here is this problem, this is what we >>>> (IETF) think, the solution is in your court. Have a nice day." >>>> >>> I believe this puts it in nutshell. >>> >>> The telecom specific uses of ENUM technology are more appropriately >>> handled in the telecom standards organizations, such as the >> ITU-T, and >>> ETSI. >>> >>> Let's move on and work with Internet and web addressing >> that I believe >>> have the real potential for the Internet standards >> development and where >>> IETF resources are better placed. >>> >>> Thanks, Henry >>> >>> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of >>> Richard Shockey >>> Sent: Tuesday, February 19, 2008 10:20 AM >>> To: Hannes.Tschofenig@gmx.net >>> Cc: 'IETF SIP List'; paf@cisco.com >>> Subject: Re: [Sip] Infrastructure issues involving e164 numbers >>> >>> This is not to say that the IETF could play a useful and >> essential role. >>> We >>> can certainly develop and define the requirements, use cases etc. >>> >>> In addition the IETF can architect a solution but >> experience tells me >>> that >>> deployment and implementation issues surrounding e164 >> issues will need >>> the >>> cooperation of "other bodies" which is where the problem >> lies. It's not >>> really the ITU, in fact the ITU is a much easier place to get things >>> done >>> these days. The complications arise with the ITU member states, who >>> jealously guard their diplomatic and political prerogatives. >>> >>> This was the conclusion that we drew when the >> Infrastructure ENUM issues >>> first arose. We essentially said ..."Here is this problem, >> this is what >>> we >>> (IETF) think, the solution is in your court. Have a nice day." >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Tuesday, February 19, 2008 10:49 AM >>>> To: Richard Shockey >>>> Cc: 'IETF SIP List'; paf@cisco.com >>>> Subject: Re: Infrastructure issues involving e164 numbers >>>> >>>> >>>> > If there is going to be a solution to the SIP identity problem >>>> involving >>>> > e164 numbers, it will not IMHO be solved in the IETF. >>>> > >>>> > >>>> Interesting view. I obviously does not appear to be an easy thing; >>>> in the draft I called this "There is non-neglectable deployment >>>> incentive challenge." >>>> >>> >>> _______________________________________________ >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 08:06:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C3D3A6E89; Wed, 20 Feb 2008 08:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcPydei-EsFO; Wed, 20 Feb 2008 08:06:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313253A6E7C; Wed, 20 Feb 2008 08:06:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37703A6E69 for ; Wed, 20 Feb 2008 08:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC7BNqLWU6lB for ; Wed, 20 Feb 2008 08:06:29 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 7C3C23A6E70 for ; Wed, 20 Feb 2008 08:06:27 -0800 (PST) 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 m1KG6FB08548; Wed, 20 Feb 2008 16:06:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 10:05:43 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF14F815AE@zrc2hxm0.corp.nortel.com> In-Reply-To: <47BB93F3.6060907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers Thread-Index: AchzaoSZI3ud10e2SSixLFWWRtb/mQAb+hhw References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A573@zrc2hxm0.corp.nortel.com> <47BB2CF7.3090407@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A73F@zrc2hxm0.corp.nortel.com> <47BB34C2.1060309@cisco.com> <1ECE0EB50388174790F9694F77522CCF14F3A7D5@zrc2hxm0.corp.nortel.com> <47BB4890.6050007@cisco.com> <47BB93F3.6060907@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , "Paul Kyzivat" Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sounds reasonable to me. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, February 19, 2008 18:44 > To: Paul Kyzivat > Cc: Audet, Francois (SC100:3055); IETF SIP List > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > Actually what I am hoping to do is to just clearly document > the applicability of RFC4474 to numbers and be much crisper > with guidance on when to use it, when to not, what it buys > you with numbers (since it does help a little even then - > receivers can know the domain that asserts that number and > use blacklists/whitelists to judge trustability). > > I also want to make sure we are not basing SRTP security on > integrity properties delivered with RFC4474, when said > properties aren't really delivered so well with phone numbers. > > -Jonathan R. > > Paul Kyzivat wrote: > > > > > > Francois Audet wrote: > >> I think we might be talking about two different aspects. > >> > >> For "phone numbers", I agree with you that parity is ok. > >> > >> For "email-looking addresses", I believe the bar is higher (and we > >> have it already with 4474). > > > > OK. THen we aren't far apart. I agree we want and have something > > better for email-style addresses where the domain is > significant. It > > is the "phone number" addresses I am concerned with here. I > think we > > must have parity, and ideally better when the PSTN isn't involved. > > > > Paul > > > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, > >>> February 19, 2008 11:58 > >>> To: Audet, Francois (SC100:3055) > >>> Cc: Jonathan Rosenberg; IETF SIP List > >>> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > >>> > >>> > >>> > >>> Francois Audet wrote: > >>>> I'm not sure I agree with that. > >>>> > >>>> I think we want something that is better than the PSTN. I > >>> just don't > >>>> think it's the right question to ask. > >>> I certainly *want* something better than PSTN. But > perhaps we don't > >>> *need* that. I think we do *need* something "as good as" the PSTN. > >>> > >>> But perhaps the first order of business is to come to > agreement on > >>> what we need. > >> > > > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 10:05:56 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF00D3A6A90; Wed, 20 Feb 2008 10:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=-1.506, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_111=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sziotw4-P08v; Wed, 20 Feb 2008 10:05:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852D128C98C; Wed, 20 Feb 2008 10:05:48 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CE628C988 for ; Wed, 20 Feb 2008 10:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7+34QXYdUrr for ; Wed, 20 Feb 2008 10:05:46 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BD07B28C99D for ; Wed, 20 Feb 2008 10:05:15 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2008 10:05:12 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1KI5Cx2026640; Wed, 20 Feb 2008 10:05:12 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1KI5AuL012028; Wed, 20 Feb 2008 18:05:10 GMT From: "Dan Wing" To: "'Elwell, John'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" References: <47B9125B.2060104@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069860F@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 20 Feb 2008 10:05:13 -0800 Message-ID: <102901c873eb$24842d10$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D069860F@GBNTHT12009MSX.gb002.siemens.net> Thread-Index: Achx7G+E4aUToVTYRZqr9za1269QWwBRNjNgAC5WoiA= Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > 3. "Thus, DTLS-SRTP still provides better security than Sdescriptions. > However, when used with phone numbers, it is by no means > ideal. Most > importantly, it does NOT provide guarantees that > intermediaries have > not been able to intercept and decrypt the media." > > Not true. If you use DTLS-SRTP with RFC 4474 and an E.164 > number in the > SIP URI, it DOES provide a guarantee that intermediaries between the > domain in the SIP URI and the UAS are unable to intercept and decrypt > media. This seems to be of value in some situations. If the intermediary created the RFC4474 signature itself -- which is necessary if the intermediary changed the SDP -- the intermediary could have also changed the a=fingerprint. Changing the a=fingerprint allows the intermediary to perform the DTLS-SRTP handshake itself and thus decrypt the SRTP packets to/from both callers. draft-kaplan-sip-uris-change-00.txt describes reasons why an intermediary might want or need to change the SDP and the From URI. Most intermediaries are service providers. Most service providers operate SBCs. All SBCs change the SDP (otherwise, they would merely be B2BUAs). -d _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 10:31:03 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301423A6ADF; Wed, 20 Feb 2008 10:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcf+vOQaCasd; Wed, 20 Feb 2008 10:31:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1256928C1CD; Wed, 20 Feb 2008 10:31:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B023A68C9 for ; Wed, 20 Feb 2008 10:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ1P2EQnQs4g for ; Wed, 20 Feb 2008 10:30:59 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9B8403A69A2 for ; Wed, 20 Feb 2008 10:30:59 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1KIUsq4017408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2008 12:30:55 -0600 Message-Id: From: Dean Willis To: Ted Hardie In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 12:30:48 -0600 References: <47B6345B.4030807@cisco.com> <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 20, 2008, at 12:28 AM, Ted Hardie wrote: > > . If the idea is that the specification of > "pic" or "name" is at the level of the specification of an event > package, > then we are dealing with something else entirely and the draft can > be re-written to express that. But I would expect, in that case, > for each > of the registered purposes to be very carefully specified as to what > the > acting application would do with them. And I suspect pretty much > everything like "name" would have to go. Ok, I think I agree with you here. Each "purpose" would need to be very clearly specified, at roughly the same level of detail as is required for an event package or would be required for an INFO package if we were to go that way. And yes, the draft is a bit short on this right now. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 10:41:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61AD028C82A; Wed, 20 Feb 2008 10:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR5giUT96NaH; Wed, 20 Feb 2008 10:41:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C55928C1F7; Wed, 20 Feb 2008 10:41:36 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476983A6E46 for ; Wed, 20 Feb 2008 10:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9i-rg6uVrdb for ; Wed, 20 Feb 2008 10:41:33 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7E5423A6ADA for ; Wed, 20 Feb 2008 10:41:33 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1KIfPEP017528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2008 12:41:27 -0600 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <47BC1E7E.5070303@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 12:41:20 -0600 References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> <47BB4763.1020804@cisco.com> <47BC1E7E.5070303@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Mayumi Munakata , sip@ietf.org, David R Oran Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 20, 2008, at 6:35 AM, Paul Kyzivat wrote: > Dean, > > I don't think I agree. > > In the non-anonymous case, the asserter will attest that the source > is entitled to claim the address. AFAIK nothing else is implied. But > assume it will provide more - for instance the name, address, and > SS# of the person entitled to the address. > > Now assume that the address is an "anonymous" address. The asserter > will then be providing information about the anonymizer, not the > entity that is being anonymized. Its entirely possible (likely) that > the anonymizer won't maintain records that would give it the > capability of reporting on the address being anonymized. Well then in most jurisdictions it can go to jail for contempt of court when it can't respond to the court order. Seriously, you really shouldn't be acting as an identity service if you have no way to validate the identity being asserted against. It's like notarizing a signature on a document without checking the signer's ID. In other words, the anonymizer and the identity service MUST be integrated. The identity service needs to perform an identity verification check on the user BEFORE anonymizing, if it's going to act as an identity service for that user. Slapping an identity record on something that's been anonymized elsewhere is worse than useless. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 11:00:20 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2046328CA28; Wed, 20 Feb 2008 11:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=-1.888, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySY3uskBlTpo; Wed, 20 Feb 2008 11:00:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EEE228C82C; Wed, 20 Feb 2008 11:00:11 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CF328C9FA for ; Wed, 20 Feb 2008 11:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsus6ewy2+pO for ; Wed, 20 Feb 2008 11:00:09 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 77D7D28C9FB for ; Wed, 20 Feb 2008 11:00:08 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Feb 2008 14:00:05 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1KJ05Cn017538; Wed, 20 Feb 2008 14:00:05 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1KJ00SC002735; Wed, 20 Feb 2008 19:00:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 14:00:00 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 13:59:59 -0500 Message-ID: <47BC78BB.5070708@cisco.com> Date: Wed, 20 Feb 2008 14:00:11 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> <47BB4763.1020804@cisco.com> <47BC1E7E.5070303@cisco.com> In-Reply-To: X-OriginalArrivalTime: 20 Feb 2008 18:59:59.0804 (UTC) FILETIME=[CA940FC0:01C873F2] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Mayumi Munakata , sip@ietf.org, David R Oran Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Feb 20, 2008, at 6:35 AM, Paul Kyzivat wrote: > >> Dean, >> >> I don't think I agree. >> >> In the non-anonymous case, the asserter will attest that the source is >> entitled to claim the address. AFAIK nothing else is implied. But >> assume it will provide more - for instance the name, address, and SS# >> of the person entitled to the address. >> >> Now assume that the address is an "anonymous" address. The asserter >> will then be providing information about the anonymizer, not the >> entity that is being anonymized. Its entirely possible (likely) that >> the anonymizer won't maintain records that would give it the >> capability of reporting on the address being anonymized. > > Well then in most jurisdictions it can go to jail for contempt of court > when it can't respond to the court order. Seriously, you really > shouldn't be acting as an identity service if you have no way to > validate the identity being asserted against. It's like notarizing a > signature on a document without checking the signer's ID. > > In other words, the anonymizer and the identity service MUST be > integrated. The identity service needs to perform an identity > verification check on the user BEFORE anonymizing, if it's going to act > as an identity service for that user. Slapping an identity record on > something that's been anonymized elsewhere is worse than useless. We are entering the realm of legal opinion, where I am not qualified to operate. But I will still render an opinion. I could potentially operate an anonymization service simply by getting two PSTN phones. If you want my service, you call me on one of my lines and tell me who you want to call. I call that number with my other line, and just hold the receivers together to couple the media. The recipient will get the callerid of my 2nd line. You can serve me with a court order to provide the actual identity of the caller, but it won't do any good because I don't know who that was. Further, I am not identity provider. My telco provider is the identity provider for the line. A court order to them also will serve no purpose. I don't *think* anybody is violating any laws here. I see a sip anonymization service as being logically equivalent to the above. Paul _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 12:44:47 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6FA28C9AE; Wed, 20 Feb 2008 12:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.067 X-Spam-Level: *** X-Spam-Status: No, score=3.067 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4xR8ZjtDAt6; Wed, 20 Feb 2008 12:44:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FF128C399; Wed, 20 Feb 2008 12:44:40 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C671A28C399 for ; Wed, 20 Feb 2008 12:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puBfaHqKfWVA for ; Wed, 20 Feb 2008 12:44:35 -0800 (PST) Received: from cuda6.sorenson.com (cuda6.sorenson.com [209.169.244.134]) by core3.amsl.com (Postfix) with ESMTP id D2B2328C2EE for ; Wed, 20 Feb 2008 12:44:35 -0800 (PST) X-ASG-Debug-ID: 1203540462-683f01360000-Gp2Nu1 X-Barracuda-URL: http://209.169.244.134:8000/cgi-bin/mark.cgi Received: from sorenson.com (unknown [10.20.35.101]) by cuda6.sorenson.com (Spam Firewall) with ESMTP id 04925B2452 for ; Wed, 20 Feb 2008 13:47:43 -0700 (MST) Received: from sorenson.com ([10.20.35.101]) by cuda6.sorenson.com with ESMTP id hcM8V8yqedQdmcxJ for ; Wed, 20 Feb 2008 13:47:43 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Signaling Video Details Date: Wed, 20 Feb 2008 13:44:32 -0700 Message-ID: <17996BB6EF2E744CBB57DE193073AA71330553@SC-EMAIL01.SorensonComm.Sorenson.Com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signaling Video Details Thread-Index: Ach0AWV9dIUZI575QHuY7JfT70WdDg== From: "Eugene Christensen" To: X-Barracuda-Connect: UNKNOWN[10.20.35.101] X-Barracuda-Start-Time: 1203540463 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at sorenson.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Subject: [Sip] Signaling Video Details X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0784533223==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0784533223== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87401.6556EAF6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87401.6556EAF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I would like to be able to signal a video channel using SIP. I have seen in SDP how to signal the codec, the bandwidth and the rtpmap but I don't see how to signal frame rates, frame sizes, and other negotiable capabilities of a video codec. Can you point me to how this is done? I see that in SDP, I can use the "a" for attributes but are there some standard identifiers that are being used by the industry or described in some rfc for how to do this? =20 =20 Thank You, =20 Eugene Christensen Sorenson Communications =20 ------_=_NextPart_001_01C87401.6556EAF6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello,

     

    I would like to be able to signal a video channel = using SIP.  I have seen in SDP how to signal the codec, the bandwidth and = the rtpmap but I don’t see how to signal frame rates, frame sizes, and = other negotiable capabilities of a video codec.  Can you point me to how = this is done?  I see that in SDP, I can use the “a” for = attributes but are there some standard identifiers that are being used by the industry = or described in some rfc for how to do this?

     

     

    Thank You,

     

    Eugene Christensen

    Sorenson Communications

     

    ------_=_NextPart_001_01C87401.6556EAF6-- --===============0784533223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0784533223==-- From sip-bounces@ietf.org Wed Feb 20 12:48:42 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE8C3A6E19; Wed, 20 Feb 2008 12:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u+CX82wfEHg; Wed, 20 Feb 2008 12:48:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7253A6B21; Wed, 20 Feb 2008 12:48:41 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB96C3A690B for ; Wed, 20 Feb 2008 12:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml9+u2+jietS for ; Wed, 20 Feb 2008 12:48:38 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B372728C0D9 for ; Wed, 20 Feb 2008 12:48:38 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1KKmPkX018638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2008 14:48:26 -0600 Message-Id: <5818401F-47F8-410E-8A5E-1F914F9BEBF7@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <47BC78BB.5070708@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 14:48:19 -0600 References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> <47BB4763.1020804@cisco.com> <47BC1E7E.5070303@cisco.com> <47BC78BB.5070708@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Mayumi Munakata , sip@ietf.org, David R Oran Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 20, 2008, at 1:00 PM, Paul Kyzivat wrote: > > > I could potentially operate an anonymization service simply by > getting two PSTN phones. If you want my service, you call me on one > of my lines and tell me who you want to call. I call that number > with my other line, and just hold the receivers together to couple > the media. > > The recipient will get the callerid of my 2nd line. You can serve me > with a court order to provide the actual identity of the caller, but > it won't do any good because I don't know who that was. > > Further, I am not identity provider. My telco provider is the > identity provider for the line. A court order to them also will > serve no purpose. Some would argue that you could be held culpable due to aiding and abetting. What happens if someone uses the open access point at your house to send threatening messages to the white house? What happened to the folks who ran the anonymous remailer service in Finland a while back? (see http://en.wikipedia.org/wiki/Penet_remailer) > I don't *think* anybody is violating any laws here. Laws vary. But we're I thought we were talking about another situation, see below. > > > I see a sip anonymization service as being logically equivalent to > the above. > I didn't say you couldn't have a SIP anonymization service. I'm saying that if you're running an identity service that inserting an identity header asserting that you know who the message is from when you don't actually know who the message is from is a bad idea. Conversely, there is a legitimate role for a service that is both an anonymizer and an asserter of identity. The assertion here is "I know who this person is, but I'm not telling you without proper cause". As an end user, I'd be inclined to grant this a higher level of trust than I would a message that claims nothing about who it might be from. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 13:29:06 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D336628C642; Wed, 20 Feb 2008 13:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=-1.326, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2sDJ5kwk64I; Wed, 20 Feb 2008 13:29:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B7128C1C7; Wed, 20 Feb 2008 13:29:04 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080653A6B05 for ; Wed, 20 Feb 2008 13:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQc8RMj4G-n6 for ; Wed, 20 Feb 2008 13:29:02 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 791953A6A41 for ; Wed, 20 Feb 2008 13:29:02 -0800 (PST) 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 m1KLSsB28088; Wed, 20 Feb 2008 21:28:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 15:28:28 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> In-Reply-To: <47BC44C0.6050801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-Index: Achz1BycDA1pMO0bSE2u7o+mDcgWDgAMptFg References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Elwell, John" Cc: IETF SIP List , Henry Sinnreich , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think it's time for a reality check... In the PSTN, if you are an enterprise and have a trunk to a service provider, you can pretty much put whatever you want in the Calling Party Number (you can't do that from home with an individual line as the CO puts the Calling Party Number for you). The network will pass it for you to the other end. So, not only is the identity in PSTN "hop-by-hop" and not end-to-end, anybody with suitable trunk interface can spoof anybody else. So again, I don't see why WE need to worry about phone number identity. I agree with Jonathan that we should just document the limitations. And personally, I don't mind if we restrict the usefulness end-to-end identity (4474) to addresses where the domain name actually matters and is not ignored (as is the case with user=phone type numbers). > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Wednesday, February 20, 2008 07:18 > To: Elwell, John > Cc: IETF SIP List; Henry Sinnreich; paf@cisco.com; Richard Shockey > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > It seems that we have two parallel worlds: one using > email-style addresses and another using phone numbers. While > there are some devices that can play in both worlds, the > majority of devices can only play in one of the worlds, or at > least are strongly biased towards one so that usability with > the other form is compromised. > > It seems essential that sip find a way to be successful in > the phone number world - at least to the extent that a sip > device in not perceived as being functionally worse than a > comparable device using PSTN protocols. No amount of arguing > that things would be better if you just used an email-style > address will win the day there. > > The alternative is to accept that sip is worse than native > PSTN equipment for phone numbers, and hope that the parallel > communications world based on email-style addresses will > eventually win out. But that is like waiting for IPv4 to be > replaced by IPv6. > > Paul > > Elwell, John wrote: > > Hannes, > > > > I know the questions were directed at Henry. However, if I may > > intervene: > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] > On Behalf Of > >> Hannes Tschofenig > >> Sent: 20 February 2008 08:00 > >> To: Henry Sinnreich > >> Cc: IETF SIP List; paf@cisco.com; Richard Shockey > >> Subject: Re: [Sip] Infrastructure issues involving e164 numbers > >> > >> Hi Henry, > >> > >> there are two aspects to the story: > >> > >> * Do you believe there is a problem for security when interworking > >> between the PSTN and SIP? > >> (e.g., in the way how SIP Identity deals with E.164 numbers) > > [JRE] There are actually two separate situations: use of > E.164 numbers > > for communication within the SIP world; and use of E.164 > numbers when > > interworking between SIP and PSTN. Did you intentionally limit your > > question to the second of these? > > Assuming that was the intention, I would point out that we > can never > > achieve end-to-end security when interworking with PSTN. > The best we > > can do is achieve security across the local SIP part as far as the > > PSTN gateway. There are different opinions as to whether the PSTN > > itself is secure - I won't express an opinion on that > aspect. However, > > what happens beyond the PSTN? Another SIP hop? An H.323 > hop? There is > > no way of knowing whether that is secured or not. Some guarantee of > > security as far as the gateway is the best we can achieve, and, > > importantly, the user should be made aware of this - do not > raise his > > expectations concerning the end-to-end security of the call. > > > > Let's concentrate on the end-to-end SIP case and provide a good > > security solution for that. One possibility might be to use > > email-style URIs for that. > > > > John > > > >> * If yes, do you think that someone should be > investigating what todo > >> about it? > >> > >> Don't get hung-up in the details of a specific strawman proposal > >> that, I believe, shows quite well some of the challenges > around the > >> aspect of > >> E.164 number ownership. > >> > >> Ciao > >> Hannes > >> > >> > >> Henry Sinnreich wrote: > >>>> "Here is this problem, this is what we > >>>> (IETF) think, the solution is in your court. Have a nice day." > >>>> > >>> I believe this puts it in nutshell. > >>> > >>> The telecom specific uses of ENUM technology are more > appropriately > >>> handled in the telecom standards organizations, such as the > >> ITU-T, and > >>> ETSI. > >>> > >>> Let's move on and work with Internet and web addressing > >> that I believe > >>> have the real potential for the Internet standards > >> development and where > >>> IETF resources are better placed. > >>> > >>> Thanks, Henry > >>> > >>> > >>> -----Original Message----- > >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >> Behalf Of > >>> Richard Shockey > >>> Sent: Tuesday, February 19, 2008 10:20 AM > >>> To: Hannes.Tschofenig@gmx.net > >>> Cc: 'IETF SIP List'; paf@cisco.com > >>> Subject: Re: [Sip] Infrastructure issues involving e164 numbers > >>> > >>> This is not to say that the IETF could play a useful and > >> essential role. > >>> We > >>> can certainly develop and define the requirements, use cases etc. > >>> > >>> In addition the IETF can architect a solution but > >> experience tells me > >>> that > >>> deployment and implementation issues surrounding e164 > >> issues will need > >>> the > >>> cooperation of "other bodies" which is where the problem > >> lies. It's not > >>> really the ITU, in fact the ITU is a much easier place to > get things > >>> done these days. The complications arise with the ITU > member states, > >>> who jealously guard their diplomatic and political prerogatives. > >>> > >>> This was the conclusion that we drew when the > >> Infrastructure ENUM issues > >>> first arose. We essentially said ..."Here is this problem, > >> this is what > >>> we > >>> (IETF) think, the solution is in your court. Have a nice day." > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>> Sent: Tuesday, February 19, 2008 10:49 AM > >>>> To: Richard Shockey > >>>> Cc: 'IETF SIP List'; paf@cisco.com > >>>> Subject: Re: Infrastructure issues involving e164 numbers > >>>> > >>>> > >>>> > If there is going to be a solution to the SIP > identity problem > >>>> involving > e164 numbers, it will not IMHO be solved in > the IETF. > >>>> > > >>>> > > >>>> Interesting view. I obviously does not appear to be an > easy thing; > >>>> in the draft I called this "There is non-neglectable deployment > >>>> incentive challenge." > >>>> > >>> > >>> _______________________________________________ > >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use > >>> sip-implementors@cs.columbia.edu for questions on current sip Use > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> _______________________________________________ > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu for questions on current sip Use > >> sipping@ietf.org for new developments on the application of sip > >> > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 13:40:06 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A80C28C9B9; Wed, 20 Feb 2008 13:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQqx6FJRtncQ; Wed, 20 Feb 2008 13:40:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8F928C8CA; Wed, 20 Feb 2008 13:40:05 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59A428C965 for ; Wed, 20 Feb 2008 13:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLsrhSwxP45z for ; Wed, 20 Feb 2008 13:40:02 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B10D028C7F4 for ; Wed, 20 Feb 2008 13:40:02 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 20 Feb 2008 16:39:45 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 20 Feb 2008 16:39:45 -0500 From: Hadriel Kaplan To: "Elwell, John" , IETF SIP List Date: Wed, 20 Feb 2008 16:39:44 -0500 Thread-Topic: [Sip] New I-D on why From/To-URIs are changed at provider borders Thread-Index: AchyZulElgl5PP+qQYG8DvAYAxoq4AAABmmgAACz7qAAUnRVYAAJ6Aaw Message-ID: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D069870C@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D069870C@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] New I-D on why From/To-URIs are changed at provider borders X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org As far as I know, both true E.164 and those that "look like" E.164 are being changed, as well as NANP/local-exchange format, emergency code, and some cellular-specific number formats, etc. To be honest I really believe a lot of these truly are E.164 or non-local-scope numbers in nature/meaning, and just aren't using the exact format one would want. In other words it's as Paul says "do what I mean, not what I say". Really some of the rules are pretty simplistic, including even just change it regardless of username format. But I would consider those just bad and need to be corrected, and will if email-style URI's start showing up. Really though I don't think there's much/any email-style URIs crossing provider borders. (inside Enterprises or within a provider may be, but that doesn't need rfc4474) Or maybe it's just my particular customers, or my kind of customers. I dunno. I find everyone on the IETF list has a different view of SIP, because they represent different users/markets. -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, February 20, 2008 6:39 AM > To: Hadriel Kaplan; IETF SIP List > Subject: RE: [Sip] New I-D on why From/To-URIs are changed at provider > borders > > Hadriel, > > Thanks for this draft. One comments: > > When talking about changing the host part of SIP URIs, are you referring > just to SIP URIs containing an E.164 number in telephone-subscriber > format (e.g.: +123456789@example.com;user=phone)? Or are you also > talking about other forms of URI that look like E.164 number (e.g., > +123456789@example.com)? Presumably you are not talking about email > style URIs. > > John > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Hadriel Kaplan > > Sent: 18 February 2008 20:20 > > To: IETF SIP List > > Subject: [Sip] New I-D on why From/To-URIs are changed at > > provider borders > > > > As part of an off-line discussion regarding Kai Fischer's > > draft on e2e-security-media and whether his From-URI copying > > tactic would succeed or not at a policy level, if rfc4474 > > fails to do so, I gave my 2 cents on what some providers had > > been telling me. Dan asked me to write up a draft on it, in > > case people are interested. This is the draft: > > http://www.ietf.org/internet-drafts/draft-kaplan-sip-uris-chan > > ge-00.txt > > > > -hadriel > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 13:40:09 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC3D28CA83; Wed, 20 Feb 2008 13:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8F77pI+26-6; Wed, 20 Feb 2008 13:40:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2BA28C2E6; Wed, 20 Feb 2008 13:40:07 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C138828C998 for ; Wed, 20 Feb 2008 13:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f51uiIoWlNeS for ; Wed, 20 Feb 2008 13:40:04 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 44AB928C7F4 for ; Wed, 20 Feb 2008 13:40:04 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E272D21CAC; Wed, 20 Feb 2008 22:39:59 +0100 (CET) X-AuditID: c1b4fb3e-a99fdbb000000b15-75-47bc9e2f7b98 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CA3AB201C2; Wed, 20 Feb 2008 22:39:59 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 22:39:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 22:38:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signaling Video Details thread-index: Ach0AWV9dIUZI575QHuY7JfT70WdDgAB5O+0 References: <17996BB6EF2E744CBB57DE193073AA71330553@SC-EMAIL01.SorensonComm.Sorenson.Com> From: "Christer Holmberg" To: "Eugene Christensen" , X-OriginalArrivalTime: 20 Feb 2008 21:39:59.0667 (UTC) FILETIME=[248AE830:01C87409] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Signaling Video Details X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, You should check out the AVT WG. They specify these kind of SDP attributes for different codecs. Regards, Christer ________________________________ From: sip-bounces@ietf.org on behalf of Eugene Christensen Sent: Wed 20/02/2008 21:44 To: sip@ietf.org Subject: [Sip] Signaling Video Details Hello, I would like to be able to signal a video channel using SIP. I have seen in SDP how to signal the codec, the bandwidth and the rtpmap but I don't see how to signal frame rates, frame sizes, and other negotiable capabilities of a video codec. Can you point me to how this is done? I see that in SDP, I can use the "a" for attributes but are there some standard identifiers that are being used by the industry or described in some rfc for how to do this? Thank You, Eugene Christensen Sorenson Communications _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 13:44:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34D528C9BA; Wed, 20 Feb 2008 13:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfb7Z6FjNyFF; Wed, 20 Feb 2008 13:44:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17F028C8FB; Wed, 20 Feb 2008 13:44:33 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43EA928C8CA for ; Wed, 20 Feb 2008 13:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXaFvStto6pi for ; Wed, 20 Feb 2008 13:44:22 -0800 (PST) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 98BE328C473 for ; Wed, 20 Feb 2008 13:44:22 -0800 (PST) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id rojZ1Y0070x6nqcAA0WH00; Wed, 20 Feb 2008 21:43:33 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id rxk51Y00F0umElk8Y00000; Wed, 20 Feb 2008 21:44:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=oLHs5Kn5MywA:10 a=iv0-ODH01Rv8_8RZ9PUA:9 a=D-4XSc3ErUP9SlJfE3FaUIdkaFkA:4 a=mnQxEUBslVAA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m1KLi5Mj024165 for ; Wed, 20 Feb 2008 16:44:05 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m1KLi5WJ024161; Wed, 20 Feb 2008 16:44:05 -0500 Date: Wed, 20 Feb 2008 16:44:05 -0500 Message-Id: <200802202144.m1KLi5WJ024161@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (dean.willis@softarmor.com) References: <47B6345B.4030807@cisco.com> <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Dean Willis Ok, I think I agree with you here. Each "purpose" would need to be very clearly specified, at roughly the same level of detail as is required for an event package or would be required for an INFO package if we were to go that way. IMHO the purposes need to be specified in *more* detail than an event package. The reason is that an event package is "pull" information, the meaning of the information is defined by the event-name, but the requestor is presumed to know *why* it wants the information, that is, what it intends to do based on that information. A TOTE object, like an INFO, is "push" information, and the attached meta-data must specify not only what the information means, but how the recipient is expected to act on it. Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 13:45:31 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF5E28CADA; Wed, 20 Feb 2008 13:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pmBP5lCWgfX; Wed, 20 Feb 2008 13:45:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B3428C998; Wed, 20 Feb 2008 13:45:29 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7923328C8CA for ; Wed, 20 Feb 2008 13:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOkG5nGNpWmX for ; Wed, 20 Feb 2008 13:45:25 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1E12828CADA for ; Wed, 20 Feb 2008 13:45:22 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWK00K214FFZ7@siemenscomms.co.uk> for sip@ietf.org; Wed, 20 Feb 2008 21:45:15 +0000 (GMT) Date: Wed, 20 Feb 2008 21:45:14 +0000 From: "Elwell, John" In-reply-to: <47BC44C0.6050801@cisco.com> To: Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Infrastructure issues involving e164 numbers thread-index: Achz1A+cw4J5tHIVSIm7S0D0a585FwANL4tg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> Cc: IETF SIP List , Henry Sinnreich , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, That is not quite what I meant. I meant that for PSTN interworking there is no point in trying to do anything more secure on the SIP hop than the security provided by the PSTN hop and anything beyond the PSTN. Security is only as good as the weakest link. So let's try to be as good, but not better. In the SIP world we can try to be better. Most devices today either don't support SRTP or support it using Sdescriptions. As devices evolve to support DTLS-SRTP, they too must evolve to exploit email-style URIs, because little benefit seems to be achieved by using of DTLS-SRTP with E.164 numbers, especially if devices display the number part and don't display, or don't give prominence to, the domain part. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 20 February 2008 15:18 > To: Elwell, John > Cc: Hannes.Tschofenig@gmx.net; Henry Sinnreich; IETF SIP > List; paf@cisco.com; Richard Shockey > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > It seems that we have two parallel worlds: one using email-style > addresses and another using phone numbers. While there are > some devices > that can play in both worlds, the majority of devices can > only play in > one of the worlds, or at least are strongly biased towards > one so that > usability with the other form is compromised. > > It seems essential that sip find a way to be successful in the phone > number world - at least to the extent that a sip device in > not perceived > as being functionally worse than a comparable device using PSTN > protocols. No amount of arguing that things would be better > if you just > used an email-style address will win the day there. > > The alternative is to accept that sip is worse than native PSTN > equipment for phone numbers, and hope that the parallel > communications > world based on email-style addresses will eventually win out. > But that > is like waiting for IPv4 to be replaced by IPv6. > > Paul > > Elwell, John wrote: > > Hannes, > > > > I know the questions were directed at Henry. However, if I may > > intervene: > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >> Behalf Of Hannes Tschofenig > >> Sent: 20 February 2008 08:00 > >> To: Henry Sinnreich > >> Cc: IETF SIP List; paf@cisco.com; Richard Shockey > >> Subject: Re: [Sip] Infrastructure issues involving e164 numbers > >> > >> Hi Henry, > >> > >> there are two aspects to the story: > >> > >> * Do you believe there is a problem for security when interworking > >> between the PSTN and SIP? > >> (e.g., in the way how SIP Identity deals with E.164 numbers) > > [JRE] There are actually two separate situations: use of > E.164 numbers > > for communication within the SIP world; and use of E.164 > numbers when > > interworking between SIP and PSTN. Did you intentionally limit your > > question to the second of these? > > Assuming that was the intention, I would point out that we can never > > achieve end-to-end security when interworking with PSTN. > The best we can > > do is achieve security across the local SIP part as far as the PSTN > > gateway. There are different opinions as to whether the > PSTN itself is > > secure - I won't express an opinion on that aspect. However, what > > happens beyond the PSTN? Another SIP hop? An H.323 hop? > There is no way > > of knowing whether that is secured or not. Some guarantee > of security as > > far as the gateway is the best we can achieve, and, importantly, the > > user should be made aware of this - do not raise his expectations > > concerning the end-to-end security of the call. > > > > Let's concentrate on the end-to-end SIP case and provide a > good security > > solution for that. One possibility might be to use > email-style URIs for > > that. > > > > John > > > >> * If yes, do you think that someone should be > investigating what todo > >> about it? > >> > >> Don't get hung-up in the details of a specific strawman > >> proposal that, I > >> believe, shows quite well some of the challenges around > the aspect of > >> E.164 number ownership. > >> > >> Ciao > >> Hannes > >> > >> > >> Henry Sinnreich wrote: > >>>> "Here is this problem, this is what we > >>>> (IETF) think, the solution is in your court. Have a nice day." > >>>> > >>> I believe this puts it in nutshell. > >>> > >>> The telecom specific uses of ENUM technology are more > appropriately > >>> handled in the telecom standards organizations, such as the > >> ITU-T, and > >>> ETSI. > >>> > >>> Let's move on and work with Internet and web addressing > >> that I believe > >>> have the real potential for the Internet standards > >> development and where > >>> IETF resources are better placed. > >>> > >>> Thanks, Henry > >>> > >>> > >>> -----Original Message----- > >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >> Behalf Of > >>> Richard Shockey > >>> Sent: Tuesday, February 19, 2008 10:20 AM > >>> To: Hannes.Tschofenig@gmx.net > >>> Cc: 'IETF SIP List'; paf@cisco.com > >>> Subject: Re: [Sip] Infrastructure issues involving e164 numbers > >>> > >>> This is not to say that the IETF could play a useful and > >> essential role. > >>> We > >>> can certainly develop and define the requirements, use cases etc. > >>> > >>> In addition the IETF can architect a solution but > >> experience tells me > >>> that > >>> deployment and implementation issues surrounding e164 > >> issues will need > >>> the > >>> cooperation of "other bodies" which is where the problem > >> lies. It's not > >>> really the ITU, in fact the ITU is a much easier place to > get things > >>> done > >>> these days. The complications arise with the ITU member > states, who > >>> jealously guard their diplomatic and political prerogatives. > >>> > >>> This was the conclusion that we drew when the > >> Infrastructure ENUM issues > >>> first arose. We essentially said ..."Here is this problem, > >> this is what > >>> we > >>> (IETF) think, the solution is in your court. Have a nice day." > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>> Sent: Tuesday, February 19, 2008 10:49 AM > >>>> To: Richard Shockey > >>>> Cc: 'IETF SIP List'; paf@cisco.com > >>>> Subject: Re: Infrastructure issues involving e164 numbers > >>>> > >>>> > >>>> > If there is going to be a solution to the SIP identity problem > >>>> involving > >>>> > e164 numbers, it will not IMHO be solved in the IETF. > >>>> > > >>>> > > >>>> Interesting view. I obviously does not appear to be an > easy thing; > >>>> in the draft I called this "There is non-neglectable deployment > >>>> incentive challenge." > >>>> > >>> > >>> _______________________________________________ > >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the > application of sip > >>> > >> _______________________________________________ > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 13:49:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DECF28CAD9; Wed, 20 Feb 2008 13:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-1.882, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r1i3-qOSZcX; Wed, 20 Feb 2008 13:49:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CFEE28CA02; Wed, 20 Feb 2008 13:49:06 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B842F28C993 for ; Wed, 20 Feb 2008 13:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42zWjKd5NQVM for ; Wed, 20 Feb 2008 13:49:03 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3704628CB13 for ; Wed, 20 Feb 2008 13:47:47 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2008 16:47:40 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1KLldKX007337; Wed, 20 Feb 2008 16:47:39 -0500 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 m1KLlUSG012388; Wed, 20 Feb 2008 21:47:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 16:47:33 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 16:47:32 -0500 Message-ID: <47BCA001.10307@cisco.com> Date: Wed, 20 Feb 2008 16:47:45 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> <47BB4763.1020804@cisco.com> <47BC1E7E.5070303@cisco.com> <47BC78BB.5070708@cisco.com> <5818401F-47F8-410E-8A5E-1F914F9BEBF7@softarmor.com> In-Reply-To: <5818401F-47F8-410E-8A5E-1F914F9BEBF7@softarmor.com> X-OriginalArrivalTime: 20 Feb 2008 21:47:32.0944 (UTC) FILETIME=[32B77D00:01C8740A] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Mayumi Munakata , sip@ietf.org, David R Oran Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > On Feb 20, 2008, at 1:00 PM, Paul Kyzivat wrote: >> >> I could potentially operate an anonymization service simply by >> getting two PSTN phones. If you want my service, you call me on one >> of my lines and tell me who you want to call. I call that number >> with my other line, and just hold the receivers together to couple >> the media. >> >> The recipient will get the callerid of my 2nd line. You can serve me >> with a court order to provide the actual identity of the caller, but >> it won't do any good because I don't know who that was. >> >> Further, I am not identity provider. My telco provider is the >> identity provider for the line. A court order to them also will >> serve no purpose. > > Some would argue that you could be held culpable due to aiding and > abetting. What happens if someone uses the open access point at your > house to send threatening messages to the white house? What happened > to the folks who ran the anonymous remailer service in Finland a while > back? (see http://en.wikipedia.org/wiki/Penet_remailer) > >> I don't *think* anybody is violating any laws here. > > Laws vary. But we're I thought we were talking about another > situation, see below. > >> >> I see a sip anonymization service as being logically equivalent to >> the above. >> > > I didn't say you couldn't have a SIP anonymization service. I'm > saying that if you're running an identity service that inserting an > identity header asserting that you know who the message is from when > you don't actually know who the message is from is a bad idea. *ANY* anonymization service will have this problem. It can know who *it* is getting the message from, but it cannot know if that source is acting as a relay point. If it can't provide identity without knowing that then it can never provide identity. > Conversely, there is a legitimate role for a service that is both an > anonymizer and an asserter of identity. The assertion here is "I know > who this person is, but I'm not telling you without proper cause". As > an end user, I'd be inclined to grant this a higher level of trust > than I would a message that claims nothing about who it might be from. Yes, I guess there could be some value in such a thing. But it will only be valuable if the recipient of the identity can determine it has this property. If I get a call from an address I don't recognize (which is typically be the way I will see it if there is an anonymizer involved) then how am I to know: - this is an anonymizer (as opposed to a direct call from somebody I don't know) - that this anonymizer will be willing and able to disclose the identity under certain circumstances - what those circumstances are Paul > -- > Dean > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 13:56:16 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197A53A6ABA; Wed, 20 Feb 2008 13:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.422 X-Spam-Level: X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_111=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+8OFBKKetbW; Wed, 20 Feb 2008 13:56:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8D728C1B9; Wed, 20 Feb 2008 13:56:15 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B5F3A692B for ; Wed, 20 Feb 2008 13:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi-S9CBRdDEA for ; Wed, 20 Feb 2008 13:56:12 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 835B428C1B9 for ; Wed, 20 Feb 2008 13:56:12 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWK00LB14XK00@siemenscomms.co.uk> for sip@ietf.org; Wed, 20 Feb 2008 21:56:09 +0000 (GMT) Date: Wed, 20 Feb 2008 21:56:08 +0000 From: "Elwell, John" In-reply-to: <102901c873eb$24842d10$c4f0200a@cisco.com> To: Dan Wing , Jonathan Rosenberg , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0698955@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] New I-D on RFC4474 and phone numbers thread-index: Achx7G+E4aUToVTYRZqr9za1269QWwBRNjNgAC5WoiAACAZRAA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069860F@GBNTHT12009MSX.gb002.siemens.net> <102901c873eb$24842d10$c4f0200a@cisco.com> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dan, Well, yes, if the intermediary changes the From URI and resigns, at least you know that you have security only as far as that intermediary. If the originating URI is carried elsewhere in the header, intermediaries might be less likely to change it, but if they do the same consideration applies. Unfortunately, as noted on another thread, there is the difficulty of bringing this fact (that security is only as far as the intermediary) to the attention of the user. John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 20 February 2008 18:05 > To: Elwell, John; 'Jonathan Rosenberg'; 'IETF SIP List' > Subject: RE: [Sip] New I-D on RFC4474 and phone numbers > > > > 3. "Thus, DTLS-SRTP still provides better security than > Sdescriptions. > > However, when used with phone numbers, it is by no means > > ideal. Most > > importantly, it does NOT provide guarantees that > > intermediaries have > > not been able to intercept and decrypt the media." > > > > Not true. If you use DTLS-SRTP with RFC 4474 and an E.164 > > number in the > > SIP URI, it DOES provide a guarantee that intermediaries between the > > domain in the SIP URI and the UAS are unable to intercept > and decrypt > > media. This seems to be of value in some situations. > > If the intermediary created the RFC4474 signature itself -- which > is necessary if the intermediary changed the SDP -- the intermediary > could have also changed the a=fingerprint. Changing the a=fingerprint > allows the intermediary to perform the DTLS-SRTP handshake itself and > thus decrypt the SRTP packets to/from both callers. > > draft-kaplan-sip-uris-change-00.txt describes reasons why an > intermediary might want or need to change the SDP and the From URI. > > Most intermediaries are service providers. Most service providers > operate SBCs. All SBCs change the SDP (otherwise, they would merely > be B2BUAs). > > -d > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:01:17 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0B428C948; Wed, 20 Feb 2008 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=-2.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe4UqmFCv7Ir; Wed, 20 Feb 2008 14:01:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C6228CAB1; Wed, 20 Feb 2008 14:01:04 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B1428CAB1 for ; Wed, 20 Feb 2008 14:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbKY+S3f0r51 for ; Wed, 20 Feb 2008 14:01:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3DC5328CB08 for ; Wed, 20 Feb 2008 14:00:58 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2008 17:00:55 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1KM0sAf015388; Wed, 20 Feb 2008 17:00:54 -0500 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 m1KM0WSc018064; Wed, 20 Feb 2008 22:00:52 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:00:41 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:00:40 -0500 Message-ID: <47BCA315.8010908@cisco.com> Date: Wed, 20 Feb 2008 17:00:53 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Francois Audet References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 20 Feb 2008 22:00:40.0916 (UTC) FILETIME=[08627940:01C8740C] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: IETF SIP List , paf@cisco.com, Henry Sinnreich , "Elwell, John" , Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet wrote: > I think it's time for a reality check... > > In the PSTN, if you are an enterprise and have a trunk to a service provider, > you can pretty much put whatever you want in the Calling Party Number (you > can't do that from home with an individual line as the CO puts the Calling > Party Number for you). The network will pass it for you to the other end. Why hasn't somebody sued a SP for providing false identity??? The SP *should* be restricting what the enterprise can put based on the numbers that the SP knows belong to the enterprise. (The SP doesn't need to care if the number is the precise one originating this call.) But I knew this. In principle the reliability of the pstn callerid is nonexistent. But because it is somewhat difficult for most users to spoof, *on average* callerid is reasonably reliable. Enough so that many can/do make use of it. (Admittedly the ease of spoofing is increasing, and so the average reliablility of callerid is probably going down.) > So, not only is the identity in PSTN "hop-by-hop" and not end-to-end, anybody > with suitable trunk interface can spoof anybody else. > > So again, I don't see why WE need to worry about phone number identity. > > I agree with Jonathan that we should just document the limitations. The problem is that with sip phones if there is no form of authenticated identity in use, the ease of spoofing is much easier. So if we use nothing on sip phones then end user perceived reliability of callerid will be degraded. So the question is: how can we get the *perceived* reliability of callerid with sip and phone numbers up to the perceived level of the pstn? Perhaps the solution *is* to wait for the perceived reliability on the pstn to go down. (When people stop believing callerid altogether they will be ready to by sip phone service.) > And personally, I don't mind if we restrict the usefulness end-to-end > identity (4474) to addresses where the domain name actually matters and is > not ignored (as is the case with user=phone type numbers). I certainly don't mind if we have separate mechanisms for email-style addresses and phone number addresses, or that the guarantee is better for the email-style. Paul >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Wednesday, February 20, 2008 07:18 >> To: Elwell, John >> Cc: IETF SIP List; Henry Sinnreich; paf@cisco.com; Richard Shockey >> Subject: Re: [Sip] Infrastructure issues involving e164 numbers >> >> It seems that we have two parallel worlds: one using >> email-style addresses and another using phone numbers. While >> there are some devices that can play in both worlds, the >> majority of devices can only play in one of the worlds, or at >> least are strongly biased towards one so that usability with >> the other form is compromised. >> >> It seems essential that sip find a way to be successful in >> the phone number world - at least to the extent that a sip >> device in not perceived as being functionally worse than a >> comparable device using PSTN protocols. No amount of arguing >> that things would be better if you just used an email-style >> address will win the day there. >> >> The alternative is to accept that sip is worse than native >> PSTN equipment for phone numbers, and hope that the parallel >> communications world based on email-style addresses will >> eventually win out. But that is like waiting for IPv4 to be >> replaced by IPv6. >> >> Paul >> >> Elwell, John wrote: >>> Hannes, >>> >>> I know the questions were directed at Henry. However, if I may >>> intervene: >>> >>>> -----Original Message----- >>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] >> On Behalf Of >>>> Hannes Tschofenig >>>> Sent: 20 February 2008 08:00 >>>> To: Henry Sinnreich >>>> Cc: IETF SIP List; paf@cisco.com; Richard Shockey >>>> Subject: Re: [Sip] Infrastructure issues involving e164 numbers >>>> >>>> Hi Henry, >>>> >>>> there are two aspects to the story: >>>> >>>> * Do you believe there is a problem for security when interworking >>>> between the PSTN and SIP? >>>> (e.g., in the way how SIP Identity deals with E.164 numbers) >>> [JRE] There are actually two separate situations: use of >> E.164 numbers >>> for communication within the SIP world; and use of E.164 >> numbers when >>> interworking between SIP and PSTN. Did you intentionally limit your >>> question to the second of these? >>> Assuming that was the intention, I would point out that we >> can never >>> achieve end-to-end security when interworking with PSTN. >> The best we >>> can do is achieve security across the local SIP part as far as the >>> PSTN gateway. There are different opinions as to whether the PSTN >>> itself is secure - I won't express an opinion on that >> aspect. However, >>> what happens beyond the PSTN? Another SIP hop? An H.323 >> hop? There is >>> no way of knowing whether that is secured or not. Some guarantee of >>> security as far as the gateway is the best we can achieve, and, >>> importantly, the user should be made aware of this - do not >> raise his >>> expectations concerning the end-to-end security of the call. >>> >>> Let's concentrate on the end-to-end SIP case and provide a good >>> security solution for that. One possibility might be to use >>> email-style URIs for that. >>> >>> John >>> >>>> * If yes, do you think that someone should be >> investigating what todo >>>> about it? >>>> >>>> Don't get hung-up in the details of a specific strawman proposal >>>> that, I believe, shows quite well some of the challenges >> around the >>>> aspect of >>>> E.164 number ownership. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> Henry Sinnreich wrote: >>>>>> "Here is this problem, this is what we >>>>>> (IETF) think, the solution is in your court. Have a nice day." >>>>>> >>>>> I believe this puts it in nutshell. >>>>> >>>>> The telecom specific uses of ENUM technology are more >> appropriately >>>>> handled in the telecom standards organizations, such as the >>>> ITU-T, and >>>>> ETSI. >>>>> >>>>> Let's move on and work with Internet and web addressing >>>> that I believe >>>>> have the real potential for the Internet standards >>>> development and where >>>>> IETF resources are better placed. >>>>> >>>>> Thanks, Henry >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>>> Behalf Of >>>>> Richard Shockey >>>>> Sent: Tuesday, February 19, 2008 10:20 AM >>>>> To: Hannes.Tschofenig@gmx.net >>>>> Cc: 'IETF SIP List'; paf@cisco.com >>>>> Subject: Re: [Sip] Infrastructure issues involving e164 numbers >>>>> >>>>> This is not to say that the IETF could play a useful and >>>> essential role. >>>>> We >>>>> can certainly develop and define the requirements, use cases etc. >>>>> >>>>> In addition the IETF can architect a solution but >>>> experience tells me >>>>> that >>>>> deployment and implementation issues surrounding e164 >>>> issues will need >>>>> the >>>>> cooperation of "other bodies" which is where the problem >>>> lies. It's not >>>>> really the ITU, in fact the ITU is a much easier place to >> get things >>>>> done these days. The complications arise with the ITU >> member states, >>>>> who jealously guard their diplomatic and political prerogatives. >>>>> >>>>> This was the conclusion that we drew when the >>>> Infrastructure ENUM issues >>>>> first arose. We essentially said ..."Here is this problem, >>>> this is what >>>>> we >>>>> (IETF) think, the solution is in your court. Have a nice day." >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Tuesday, February 19, 2008 10:49 AM >>>>>> To: Richard Shockey >>>>>> Cc: 'IETF SIP List'; paf@cisco.com >>>>>> Subject: Re: Infrastructure issues involving e164 numbers >>>>>> >>>>>> >>>>>> > If there is going to be a solution to the SIP >> identity problem >>>>>> involving > e164 numbers, it will not IMHO be solved in >> the IETF. >>>>>> > >>>>>> > >>>>>> Interesting view. I obviously does not appear to be an >> easy thing; >>>>>> in the draft I called this "There is non-neglectable deployment >>>>>> incentive challenge." >>>>>> >>>>> _______________________________________________ >>>>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>> _______________________________________________ >>>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> _______________________________________________ >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:07:24 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E4E28C9A2; Wed, 20 Feb 2008 14:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f10zGwzsRku; Wed, 20 Feb 2008 14:07:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BFD28CA42; Wed, 20 Feb 2008 14:05:10 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D063028CA7D for ; Wed, 20 Feb 2008 14:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szCJd5z1YQTt for ; Wed, 20 Feb 2008 14:05:09 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4AC5828C273 for ; Wed, 20 Feb 2008 14:01:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,382,1199692800"; d="scan'208";a="13790743" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2008 14:01:49 -0800 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.77.106]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m1KLmhaJ019562; Wed, 20 Feb 2008 13:48:44 -0800 Message-ID: <47BCA355.2050208@cisco.com> Date: Wed, 20 Feb 2008 14:01:57 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Elwell, John" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: IETF SIP List , Paul Kyzivat , paf@cisco.com, Henry Sinnreich , Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Paul, > > That is not quite what I meant. I meant that for PSTN interworking there > is no point in trying to do anything more secure on the SIP hop than the > security provided by the PSTN hop and anything beyond the PSTN. Security > is only as good as the weakest link. So let's try to be as good, but not > better. In the SIP world we can try to be better. > Hold on a second. Doesn't SIP have the concept of redirection? That is, even if I use a tel: URL I might get redirected to another device which doesn't ever touch the PSTN? It sure seems to me that the prudent thing to do is *always* use the best security you can instead of trying to divine whether it's going to end up being on a less secure path. Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:11:03 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BEB528CBC4; Wed, 20 Feb 2008 14:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-1.818, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+1zzHlr7D6Q; Wed, 20 Feb 2008 14:11:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C3628CA90; Wed, 20 Feb 2008 14:05:57 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B069028CAA4 for ; Wed, 20 Feb 2008 14:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIh39EWGRkaF for ; Wed, 20 Feb 2008 14:05:54 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6406828C6F8 for ; Wed, 20 Feb 2008 14:04:33 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2008 17:04:30 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1KM4UPZ017573; Wed, 20 Feb 2008 17:04:30 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1KM3wWR022883; Wed, 20 Feb 2008 22:04:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:04:10 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:04:10 -0500 Message-ID: <47BCA3E6.5040404@cisco.com> Date: Wed, 20 Feb 2008 17:04:22 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D069870C@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: X-OriginalArrivalTime: 20 Feb 2008 22:04:10.0277 (UTC) FILETIME=[852C6D50:01C8740C] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: IETF SIP List , "Elwell, John" Subject: Re: [Sip] New I-D on why From/To-URIs are changed at provider borders X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > As far as I know, both true E.164 and those that "look like" E.164 are being changed, as well as NANP/local-exchange format, emergency code, and some cellular-specific number formats, etc. To be honest I really believe a lot of these truly are E.164 or non-local-scope numbers in nature/meaning, and just aren't using the exact format one would want. In other words it's as Paul says "do what I mean, not what I say". > > Really some of the rules are pretty simplistic, including even just change it regardless of username format. But I would consider those just bad and need to be corrected, and will if email-style URI's start showing up. > > Really though I don't think there's much/any email-style URIs crossing provider borders. (inside Enterprises or within a provider may be, but that doesn't need rfc4474) Or maybe it's just my particular customers, or my kind of customers. I dunno. I find everyone on the IETF list has a different view of SIP, because they represent different users/markets. I expect you might get a different story from Microsoft. (But then they probably aren't a customer of yours.) That is what I meant about it being two different worlds. Each world has its own set of SPs. And they aren't very good at peering with one another. Paul > -hadriel > > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Wednesday, February 20, 2008 6:39 AM >> To: Hadriel Kaplan; IETF SIP List >> Subject: RE: [Sip] New I-D on why From/To-URIs are changed at provider >> borders >> >> Hadriel, >> >> Thanks for this draft. One comments: >> >> When talking about changing the host part of SIP URIs, are you referring >> just to SIP URIs containing an E.164 number in telephone-subscriber >> format (e.g.: +123456789@example.com;user=phone)? Or are you also >> talking about other forms of URI that look like E.164 number (e.g., >> +123456789@example.com)? Presumably you are not talking about email >> style URIs. >> >> John >> >> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>> Behalf Of Hadriel Kaplan >>> Sent: 18 February 2008 20:20 >>> To: IETF SIP List >>> Subject: [Sip] New I-D on why From/To-URIs are changed at >>> provider borders >>> >>> As part of an off-line discussion regarding Kai Fischer's >>> draft on e2e-security-media and whether his From-URI copying >>> tactic would succeed or not at a policy level, if rfc4474 >>> fails to do so, I gave my 2 cents on what some providers had >>> been telling me. Dan asked me to write up a draft on it, in >>> case people are interested. This is the draft: >>> http://www.ietf.org/internet-drafts/draft-kaplan-sip-uris-chan >>> ge-00.txt >>> >>> -hadriel >>> >>> _______________________________________________ >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:13:49 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FD328CB09; Wed, 20 Feb 2008 14:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-1.440, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_111=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSDFxKv1AmxD; Wed, 20 Feb 2008 14:13:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9695228C2B1; Wed, 20 Feb 2008 14:11:43 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05DDD28C1B9 for ; Wed, 20 Feb 2008 14:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWqZbI5Ta0Bz for ; Wed, 20 Feb 2008 14:11:42 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 404B928CA54 for ; Wed, 20 Feb 2008 14:07:26 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2008 14:07:23 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1KM7Nu3020617; Wed, 20 Feb 2008 14:07:23 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1KM7KJg007246; Wed, 20 Feb 2008 22:07:20 GMT From: "Dan Wing" To: "'Elwell, John'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" References: <47B9125B.2060104@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D069860F@GBNTHT12009MSX.gb002.siemens.net><102901c873eb$24842d10$c4f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0698955@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 20 Feb 2008 14:07:20 -0800 Message-ID: <14f301c8740c$f6b3d7b0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0698955@GBNTHT12009MSX.gb002.siemens.net> Thread-Index: Achx7G+E4aUToVTYRZqr9za1269QWwBRNjNgAC5WoiAACAZRAAAAjh9g Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] New I-D on RFC4474 and phone numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Agreed. -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, February 20, 2008 1:56 PM > To: Dan Wing; Jonathan Rosenberg; IETF SIP List > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > Dan, > > Well, yes, if the intermediary changes the From URI and resigns, at > least you know that you have security only as far as that > intermediary. > If the originating URI is carried elsewhere in the header, > intermediaries might be less likely to change it, but if they do the > same consideration applies. Unfortunately, as noted on another thread, > there is the difficulty of bringing this fact (that security > is only as > far as the intermediary) to the attention of the user. > > John > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: 20 February 2008 18:05 > > To: Elwell, John; 'Jonathan Rosenberg'; 'IETF SIP List' > > Subject: RE: [Sip] New I-D on RFC4474 and phone numbers > > > > > > > 3. "Thus, DTLS-SRTP still provides better security than > > Sdescriptions. > > > However, when used with phone numbers, it is by no means > > > ideal. Most > > > importantly, it does NOT provide guarantees that > > > intermediaries have > > > not been able to intercept and decrypt the media." > > > > > > Not true. If you use DTLS-SRTP with RFC 4474 and an E.164 > > > number in the > > > SIP URI, it DOES provide a guarantee that intermediaries > between the > > > domain in the SIP URI and the UAS are unable to intercept > > and decrypt > > > media. This seems to be of value in some situations. > > > > If the intermediary created the RFC4474 signature itself -- which > > is necessary if the intermediary changed the SDP -- the intermediary > > could have also changed the a=fingerprint. Changing the > a=fingerprint > > allows the intermediary to perform the DTLS-SRTP handshake > itself and > > thus decrypt the SRTP packets to/from both callers. > > > > draft-kaplan-sip-uris-change-00.txt describes reasons why an > > intermediary might want or need to change the SDP and the From URI. > > > > Most intermediaries are service providers. Most service providers > > operate SBCs. All SBCs change the SDP (otherwise, they would merely > > be B2BUAs). > > > > -d > > > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:14:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B274328C948; Wed, 20 Feb 2008 14:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=-1.817, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qbwro9uLT4Wy; Wed, 20 Feb 2008 14:14:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FCE228C21F; Wed, 20 Feb 2008 14:13:55 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D3628C758 for ; Wed, 20 Feb 2008 14:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSFuLG9II2-G for ; Wed, 20 Feb 2008 14:13:52 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E5B9728C1A6 for ; Wed, 20 Feb 2008 14:11:52 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Feb 2008 17:11:50 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1KMBnKv030171; Wed, 20 Feb 2008 17:11:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1KMBaWX025566; Wed, 20 Feb 2008 22:11:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:11:46 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:11:45 -0500 Message-ID: <47BCA5AE.8090708@cisco.com> Date: Wed, 20 Feb 2008 17:11:58 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Michael Thomas References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> In-Reply-To: <47BCA355.2050208@cisco.com> X-OriginalArrivalTime: 20 Feb 2008 22:11:45.0707 (UTC) FILETIME=[94A187B0:01C8740D] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: IETF SIP List , paf@cisco.com, Henry Sinnreich , "Elwell, John" , Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree with Mike here. People are clearly tolerating a less than ideal situation in the pstn. Many know that the mechanisms for securing the callerid (and the media) are not 100%, but they think they are also more than 0% and are willing to tolerate the level they get. We ought to be pulling the percentages up, rather than down. E.g. being able to assert that the information is accurate back to the nearest PSTN gw is better than not. Paul Michael Thomas wrote: > Elwell, John wrote: >> Paul, >> >> That is not quite what I meant. I meant that for PSTN interworking there >> is no point in trying to do anything more secure on the SIP hop than the >> security provided by the PSTN hop and anything beyond the PSTN. Security >> is only as good as the weakest link. So let's try to be as good, but not >> better. In the SIP world we can try to be better. >> > > Hold on a second. Doesn't SIP have the concept of redirection? That is, > even if I use a tel: URL I might get redirected to another device which > doesn't ever touch the PSTN? > > It sure seems to me that the prudent thing to do is *always* use the > best security you can instead of trying to divine whether it's going > to end up being on a less secure path. > > Mike > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:14:43 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4584A28C9C2; Wed, 20 Feb 2008 14:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ4eW7-qsf+E; Wed, 20 Feb 2008 14:14:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BCA28C12D; Wed, 20 Feb 2008 14:13:59 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF7928C6AB for ; Wed, 20 Feb 2008 14:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2dqDGN7+6FL for ; Wed, 20 Feb 2008 14:13:56 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 596B128CA1E for ; Wed, 20 Feb 2008 14:12:45 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1KMCd4J019247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2008 16:12:40 -0600 Message-Id: <1A3B971B-CBBA-434E-8747-360B0DAD9469@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <47BCA001.10307@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 16:12:34 -0600 References: <47BA6CE4.8090004@lab.ntt.co.jp> <47BAF7C2.8000301@cisco.com> <1203436585.5603.5.camel@frankernet-iit-cnr> <47BAFE21.3010207@cisco.com> <1203438862.5603.23.camel@frankernet-iit-cnr> <53C7623A-29F3-4A7E-B321-8912ACE4240A@cisco.com> <47BB346A.2050005@softarmor.com> <47BB4763.1020804@cisco.com> <47BC1E7E.5070303@cisco.com> <47BC78BB.5070708@cisco.com> <5818401F-47F8-410E-8A5E-1F914F9BEBF7@softarmor.com> <47BCA001.10307@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Mayumi Munakata , sip@ietf.org, David R Oran Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 20, 2008, at 3:47 PM, Paul Kyzivat wrote: >> . > > *ANY* anonymization service will have this problem. It can know who > *it* is getting the message from, but it cannot know if that source > is acting as a relay point. If it can't provide identity without > knowing that then it can never provide identity. We have traditionally presumed that if the party requesting anonymity/ identity can pass a digest authentication or equivalent test that some level of assertion about the identity of that party is warranted. > > >> Conversely, there is a legitimate role for a service that is both >> an anonymizer and an asserter of identity. The assertion here is >> "I know who this person is, but I'm not telling you without proper >> cause". As an end user, I'd be inclined to grant this a higher >> level of trust than I would a message that claims nothing about >> who it might be from. > > Yes, I guess there could be some value in such a thing. But it will > only be valuable if the recipient of the identity can determine it > has this property. > > If I get a call from an address I don't recognize (which is > typically be the way I will see it if there is an anonymizer > involved) then how am I to know: > - this is an anonymizer (as opposed to a direct call from somebody > I don't know) the anonymizing identity service has an included an Identity header signed by the identity service. That's different from NOT having one. Consider the difference between a SIP request with a "From:" of "agent@fbi.gov " and the same request carrying an RFC 4474 Identity body that is signed with the FBI.GOV cert (which validates back to a trusted root). Or consider the difference between this message, and a similar one signed by the self-signed cert for "john smith". As in all certificate work, you have to have knowledge of the policy and role of a signer in order to decide what sort of trust you wish to extend to it. > > - that this anonymizer will be willing and able to disclose the > identity under certain circumstances > - what those circumstances are I see this is more a function of "identity" than "anonymity". If you act as an identity service, whether anonymizing or not, then you probably need a policy statement about your identity service just as every CA needs a policy statement about its credential service. But mosly, it comes down to a trusted relationship. A signature from an anonymizing identity service that you don't trust obviously adds no value. Let's talk about the context of eBay. Buyers and sellers occasionally communicate outside of the offer-bid cycle. This has raised the opportunity for all sorts of fraudulent activity, such as forged "2nd- chance" offers. Ebay found it necessary to put in its own messaging infrastructure which provides for authenticated transmission. If you get a message in that channel claiming to be from the seller of an item on which you are bidding, there is a much higher probability that this is true than if you get such a message from a 3rd parry email server. Here, eBay is acting as an identity service -- somebody presumably had to be able to log into eBay as the seller in order to be able to send the message. The seller is still more-or-less anonymous -- we don't know who they are -- but eBay has vouched for their role, and we know that if things go bad, they'll attempt to apply their published policy in resolving the situation. Extending to the SIP anonymous/pseudonymous/identity discussion, I might get an INVITE from "Anonymous" that carries an Identity header verifiably from eBay. From this, I'd know that the party contacting me has a verified relationship with eBay, and I'd be able to make some decision about that message that might be a different decision than if the Identity header were not present. And yes, there's all sorts of room for SAML-like things added to Identity headers. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:19:18 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1CA28C948; Wed, 20 Feb 2008 14:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RU+TipTgrq1; Wed, 20 Feb 2008 14:19:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE4E28CA0A; Wed, 20 Feb 2008 14:18:52 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C6828C2B4 for ; Wed, 20 Feb 2008 14:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q182wrBcN9S for ; Wed, 20 Feb 2008 14:18:50 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9D31B28CAEC for ; Wed, 20 Feb 2008 14:18:08 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1KMGaNk019294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2008 16:16:37 -0600 Message-Id: <469EDDD3-1091-4BA4-8763-054468058834@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <47BCA315.8010908@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 16:16:30 -0600 References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> <47BCA315.8010908@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List , Francois Audet , Richard Shockey , Henry Sinnreich , "Elwell, John" , paf@cisco.com Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 20, 2008, at 4:00 PM, Paul Kyzivat wrote: > > > Francois Audet wrote: >> I think it's time for a reality check... >> >> In the PSTN, if you are an enterprise and have a trunk to a service >> provider, >> you can pretty much put whatever you want in the Calling Party >> Number (you >> can't do that from home with an individual line as the CO puts the >> Calling >> Party Number for you). The network will pass it for you to the >> other end. > > Why hasn't somebody sued a SP for providing false identity??? > > The SP *should* be restricting what the enterprise can put based on > the > numbers that the SP knows belong to the enterprise. (The SP doesn't > need > to care if the number is the precise one originating this call.) > > But I knew this. In principle the reliability of the pstn callerid is > nonexistent. But because it is somewhat difficult for most users to > spoof, *on average* callerid is reasonably reliable. Enough so that > many > can/do make use of it. > > (Admittedly the ease of spoofing is increasing, and so the average > reliablility of callerid is probably going down.) It's also because the telephony service provider has additional logging records that can be used to back-trace the call if it turns out to have been fraudulently identified. Try this experiment: Take your home ISDN BRI line. Add your own terminal adapter with POTS interface (if you don't have one, I'll be happy to sell you one of mine -- I have several that need to be eBayed). Dummy up your CPID field to whatever you want (this works, at least here on Verizon lines). Now place a crank call to somebody very important, and see how long it takes for the authorities to show up . . . -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:20:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D47128C6F8; Wed, 20 Feb 2008 14:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.116 X-Spam-Level: * X-Spam-Status: No, score=1.116 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIM2fyx3C3FO; Wed, 20 Feb 2008 14:20:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5447728C28B; Wed, 20 Feb 2008 14:20:44 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD2328C225 for ; Wed, 20 Feb 2008 14:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPBpEmW5frex for ; Wed, 20 Feb 2008 14:20:39 -0800 (PST) Received: from isrexch01.israel.polycom.com (fw.polycom.co.il [212.179.41.2]) by core3.amsl.com (Postfix) with ESMTP id 027FF28C28B for ; Wed, 20 Feb 2008 14:20:38 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 00:17:14 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C730D82@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signaling Video Details Thread-Index: Ach0AWV9dIUZI575QHuY7JfT70WdDgADPL/a References: <17996BB6EF2E744CBB57DE193073AA71330553@SC-EMAIL01.SorensonComm.Sorenson.Com> From: "Even, Roni" To: "Eugene Christensen" , Subject: Re: [Sip] Signaling Video Details X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1284149127==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1284149127== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8740E.ECBB7F20" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8740E.ECBB7F20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, These parameters are codec specific and appear in the payload = specification. Look for example at the H.263 RFC4629 or H.261 in RFC4587 = or H.264 in RFC 3984 Roni Even ________________________________ From: sip-bounces@ietf.org on behalf of Eugene Christensen Sent: Wed 2/20/2008 10:44 PM To: sip@ietf.org Subject: [Sip] Signaling Video Details Hello, =20 I would like to be able to signal a video channel using SIP. I have = seen in SDP how to signal the codec, the bandwidth and the rtpmap but I = don't see how to signal frame rates, frame sizes, and other negotiable = capabilities of a video codec. Can you point me to how this is done? I = see that in SDP, I can use the "a" for attributes but are there some = standard identifiers that are being used by the industry or described in = some rfc for how to do this? =20 =20 Thank You, =20 Eugene Christensen Sorenson Communications =20 ------_=_NextPart_001_01C8740E.ECBB7F20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
    =0A=
    Hi,
    =0A=
    These parameters are codec = specific and appear in the payload specification. Look for example at = the H.263 RFC4629 or H.261 in RFC4587 or H.264 in RFC 3984
    =0A=
    Roni Even
    =0A=

    =0A=
    =0A= From: sip-bounces@ietf.org on behalf = of Eugene Christensen
    Sent: Wed 2/20/2008 10:44 = PM
    To: sip@ietf.org
    Subject: [Sip] Signaling Video = Details

    =0A=
    =0A=
    =0A=

    Hello,

    =0A=

     

    =0A=

    I would like to be able to = signal a video channel using SIP.  I have seen in SDP how to signal = the codec, the bandwidth and the rtpmap but I don’t see how to = signal frame rates, frame sizes, and other negotiable capabilities of a = video codec.  Can you point me to how this is done?  I see = that in SDP, I can use the “a” for attributes but are there = some standard identifiers that are being used by the industry or = described in some rfc for how to do this?

    =0A=

     

    =0A=

     

    =0A=

    Thank = You,

    =0A=

     

    =0A=

    Eugene = Christensen

    =0A=

    Sorenson = Communications

    =0A=

     

    ------_=_NextPart_001_01C8740E.ECBB7F20-- --===============1284149127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1284149127==-- From sip-bounces@ietf.org Wed Feb 20 14:24:04 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1293328C8F9; Wed, 20 Feb 2008 14:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrjXa22IM6NI; Wed, 20 Feb 2008 14:24:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286F628C321; Wed, 20 Feb 2008 14:24:03 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5E128C735 for ; Wed, 20 Feb 2008 14:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQqNi8ZNSYBc for ; Wed, 20 Feb 2008 14:23:58 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id BEC5228C321 for ; Wed, 20 Feb 2008 14:23:57 -0800 (PST) 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 m1KMNos26650; Wed, 20 Feb 2008 22:23:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 16:23:02 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF14FDA008@zrc2hxm0.corp.nortel.com> In-Reply-To: <469EDDD3-1091-4BA4-8763-054468058834@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-Index: Ach0DnlFoKlEJtLPTfya5DFEytDqYwAAJqvA References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> <47BCA315.8010908@cisco.com> <469EDDD3-1091-4BA4-8763-054468058834@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Paul Kyzivat" Cc: IETF SIP List , "Elwell, John" , Henry Sinnreich , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Now, repeat this experience at work. Big difference. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, February 20, 2008 14:17 > To: Paul Kyzivat > Cc: Audet, Francois (SC100:3055); IETF SIP List; > paf@cisco.com; Henry Sinnreich; Elwell, John; Richard Shockey > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > > On Feb 20, 2008, at 4:00 PM, Paul Kyzivat wrote: > > > > > > > Francois Audet wrote: > >> I think it's time for a reality check... > >> > >> In the PSTN, if you are an enterprise and have a trunk to > a service > >> provider, you can pretty much put whatever you want in the Calling > >> Party Number (you can't do that from home with an > individual line as > >> the CO puts the Calling Party Number for you). The network > will pass > >> it for you to the other end. > > > > Why hasn't somebody sued a SP for providing false identity??? > > > > The SP *should* be restricting what the enterprise can put based on > > the numbers that the SP knows belong to the enterprise. (The SP > > doesn't need to care if the number is the precise one > originating this > > call.) > > > > But I knew this. In principle the reliability of the pstn > callerid is > > nonexistent. But because it is somewhat difficult for most users to > > spoof, *on average* callerid is reasonably reliable. Enough so that > > many can/do make use of it. > > > > (Admittedly the ease of spoofing is increasing, and so the average > > reliablility of callerid is probably going down.) > > It's also because the telephony service provider has > additional logging records that can be used to back-trace the > call if it turns out to have been fraudulently identified. > > Try this experiment: Take your home ISDN BRI line. Add your > own terminal adapter with POTS interface (if you don't have > one, I'll be happy to sell you one of mine -- I have several > that need to be eBayed). Dummy up your CPID field to whatever > you want (this works, at least here on Verizon lines). Now > place a crank call to somebody very important, and see how > long it takes for the authorities to show up . . . > > -- > Dean > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:33:33 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B7428C322; Wed, 20 Feb 2008 14:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs9vxNHqCh9o; Wed, 20 Feb 2008 14:33:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9DAB28C157; Wed, 20 Feb 2008 14:33:31 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316B73A6888 for ; Wed, 20 Feb 2008 14:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39nkUL+zbhdh for ; Wed, 20 Feb 2008 14:33:29 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4A23728C157 for ; Wed, 20 Feb 2008 14:33:29 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1KMXKa3019446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2008 16:33:21 -0600 Message-Id: From: Dean Willis To: Michael Thomas In-Reply-To: <47BCA355.2050208@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 16:33:15 -0600 References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List , Paul Kyzivat , Richard Shockey , Henry Sinnreich , paf@cisco.com, "Elwell, John" Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 20, 2008, at 4:01 PM, Michael Thomas wrote: > Elwell, John wrote: >> Paul, >> >> That is not quite what I meant. I meant that for PSTN interworking >> there >> is no point in trying to do anything more secure on the SIP hop >> than the >> security provided by the PSTN hop and anything beyond the PSTN. >> Security >> is only as good as the weakest link. So let's try to be as good, >> but not >> better. In the SIP world we can try to be better. >> > > Hold on a second. Doesn't SIP have the concept of redirection? That > is, > even if I use a tel: URL I might get redirected to another device > which > doesn't ever touch the PSTN? > > It sure seems to me that the prudent thing to do is *always* use the > best security you can instead of trying to divine whether it's going > to end up being on a less secure path. > Security can be reduced by such a sequence, but it can never be increased beyond that of the weakest link. So if a call is coming from the PSTN, the trust anchor is the identity assertion of the PSTN, which is weak. Putting really cleaver crypto on it makes it no stronger. However, it can mask the weakness of an assertion by making it look stronger, which could be its own sort of bad thing. To paraphrase Postel's maxim: Be appropriately secure in what you send, and suspicious of what you receive. Good advice also comes from Shakepeare, who gave us the wise words of Polonious to Hamlet that might be phrased applicably as: Neither gild nor dross a message's integrity; For faux increase doth thy recipients faith offend; And false discard dulls the edge of security. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 14:44:50 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B73B28C316; Wed, 20 Feb 2008 14:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVJfs5mjYwWs; Wed, 20 Feb 2008 14:44:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE7928C27F; Wed, 20 Feb 2008 14:44:49 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CDB28C29B for ; Wed, 20 Feb 2008 14:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPG7j6TcV69j for ; Wed, 20 Feb 2008 14:44:46 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DB77F28C150 for ; Wed, 20 Feb 2008 14:44:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,382,1199692800"; d="scan'208";a="13790760" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2008 14:44:43 -0800 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.77.106]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m1KMVcqH021340; Wed, 20 Feb 2008 14:31:38 -0800 Message-ID: <47BCAD63.7060502@cisco.com> Date: Wed, 20 Feb 2008 14:44:51 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dean Willis References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> In-Reply-To: Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: IETF SIP List , Paul Kyzivat , Richard Shockey , Henry Sinnreich , paf@cisco.com, "Elwell, John" Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Feb 20, 2008, at 4:01 PM, Michael Thomas wrote: > >> Elwell, John wrote: >>> Paul, >>> >>> That is not quite what I meant. I meant that for PSTN interworking >>> there >>> is no point in trying to do anything more secure on the SIP hop than >>> the >>> security provided by the PSTN hop and anything beyond the PSTN. >>> Security >>> is only as good as the weakest link. So let's try to be as good, but >>> not >>> better. In the SIP world we can try to be better. >>> >> >> Hold on a second. Doesn't SIP have the concept of redirection? That is, >> even if I use a tel: URL I might get redirected to another device which >> doesn't ever touch the PSTN? >> >> It sure seems to me that the prudent thing to do is *always* use the >> best security you can instead of trying to divine whether it's going >> to end up being on a less secure path. >> > > Security can be reduced by such a sequence, but it can never be > increased beyond that of the weakest link. I'm sorry, but I don't get this. If I send to a tel: URL in the clear because I think it's going to hit an "insecure" link, I'm better off even if it turns out that the tel: URL never made it to the PSTN? How does that make any sense? In fact, I'd expect that as VoIP becomes more prevalent, this sort of situation will become more and more common since e.164 will be more and more vestigial. This idea of trying to divine what happens outside of the scope of SIP to affect SIP signaling is the path to insanity. But let's put it another way: who on earth would want to maintain the crufty hacks and pretzel logic to implement this in 5 years time? Mike > > So if a call is coming from the PSTN, the trust anchor is the identity > assertion of the PSTN, which is weak. Putting really cleaver crypto > on it makes it no stronger. However, it can mask the weakness of an > assertion by making it look stronger, which could be its own sort of > bad thing. > > To paraphrase Postel's maxim: > > Be appropriately secure in what you send, and suspicious of what you > receive. > > Good advice also comes from Shakepeare, who gave us the wise words of > Polonious to Hamlet that might be phrased applicably as: > > Neither gild nor dross a message's integrity; > For faux increase doth thy recipients faith offend; > And false discard dulls the edge of security. > > -- > Dean > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 18:26:43 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3D1828C8AE; Wed, 20 Feb 2008 18:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.668 X-Spam-Level: X-Spam-Status: No, score=-0.668 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zidZHvNDekc2; Wed, 20 Feb 2008 18:26:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7F628C81B; Wed, 20 Feb 2008 18:26:42 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0B228C745 for ; Wed, 20 Feb 2008 18:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x3A1DgR25Br for ; Wed, 20 Feb 2008 18:26:40 -0800 (PST) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id A26D128C81B for ; Wed, 20 Feb 2008 18:26:40 -0800 (PST) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id rrDi1Y00Z16AWCUA30Zn00; Thu, 21 Feb 2008 02:25:58 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id s2Sb1Y00D0umElk8S00000; Thu, 21 Feb 2008 02:26:37 +0000 X-Authority-Analysis: v=1.0 c=1 a=TAktf3U8W7HrIZRfOc8A:9 a=xaySMK06E2WRZxFoK4kA:7 a=NdXoKGfHWRNzFtUxDskLpeJOIZ0A:4 a=chC_agHSu74A:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m1L2QZMj012518 for ; Wed, 20 Feb 2008 21:26:35 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m1L2QZ2V012514; Wed, 20 Feb 2008 21:26:35 -0500 Date: Wed, 20 Feb 2008 21:26:35 -0500 Message-Id: <200802210226.m1L2QZ2V012514@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <47BA495C.5000204@joelhalpern.com> (jmh@joelhalpern.com) References: <47B9125B.2060104@cisco.com> <47B9B294.7010700@joelhalpern.com> <47B9F385.4010804@cisco.com> <47BA495C.5000204@joelhalpern.com> Subject: Re: [Sip] SIP & E.164 assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Joel M. Halpern" That, treating anything that smells like an E.164 like an E.164, may well be common practice. But it seems to me a) it is a practice which is inherently misleading and error prone b) it is a practice we can not sensibly design for / around. c) It is not the working group's problem to repair security flaws introduced by such behavior. It is the vendor's problem. I agree with you strongly. If one wants to specify an E.164 number, one should use a tel: URI (with the right qualifiers). In a Sip: URI, one can only map an E.164-like user-part into an E.164 number if one knows that the policy of the specified domain is to do so. It does sound like many systems make broader assumptions. We may want to introduce the concept of using tel: URIs in SIP systems, by which the UA delegates the proxy to choose the "best way" to get to the specified E.164 destination. Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 19:48:58 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253F628C8E1; Wed, 20 Feb 2008 19:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibg1+5gVSqsP; Wed, 20 Feb 2008 19:48:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0350E28C3C8; Wed, 20 Feb 2008 19:48:57 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3A428C2D5 for ; Wed, 20 Feb 2008 19:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95wE-cTefiqt for ; Wed, 20 Feb 2008 19:48:54 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DAC4028C2E3 for ; Wed, 20 Feb 2008 19:48:53 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1L3lxdM021461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2008 21:48:01 -0600 Message-Id: <75BEF7A7-147C-4BC2-8ABC-854869A7EAC9@softarmor.com> From: Dean Willis To: Michael Thomas In-Reply-To: <47BCAD63.7060502@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 21:47:54 -0600 References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> <47BCAD63.7060502@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List , Paul Kyzivat , Richard Shockey , Henry Sinnreich , "Elwell, John" , paf@cisco.com Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 20, 2008, at 4:44 PM, Michael Thomas wrote: >> >> Security can be reduced by such a sequence, but it can never be >> increased beyond that of the weakest link. > > I'm sorry, but I don't get this. If I send to a tel: URL in the clear > because > I think it's going to hit an "insecure" link, I'm better off even if > it > turns > out that the tel: URL never made it to the PSTN? How does that make > any sense? > It makes perfect sense to strongly assert an identity than one has high confidence in, and if we're lucky enough to have an end-to-end path that preserves the integrity of the assertion, then we're good. What happens if we aren't so lucky? I'm more concerned about the "other direction" -- that is, an identity assertion that came from the PSTN is never going to be stronger than the PSTN, no matter how we package it. And by packaging it wrongly, we can give a false impression as to its validity. A link that transitions "downward" on the axes of integrity protection doesn't need to inform the next hop of this downgrade; the next hop can assume that the integrity protection is no stronger than that provided by the immediately preceding link. It's when links try to upgrade the protections that errors are introduced. It is entirely possible that our "security" mechanisms might be deployed in such a way that the eventual recipient is blinded to the weakness of such an assertion and therefore makes a mistake in trusting it. If the cryptographic envelope is "upgraded", we need some way to preserve the provenance of the assertion in order to keep this form happening. The simplest approach is to always consider a "tel:" assertion to be at the PSTN level of strength, even if it came from an IP source. This would imply "use domain-level source addressing when you can; if coming from PSTN, use telephone addressing, and never convert back". -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 20:18:24 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D5628C1D2; Wed, 20 Feb 2008 20:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8x-Uu-8sh7C; Wed, 20 Feb 2008 20:18:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1D928C74D; Wed, 20 Feb 2008 20:18:22 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6610B3A6A66 for ; Wed, 20 Feb 2008 20:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukGStN5rJJxR for ; Wed, 20 Feb 2008 20:18:18 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 95B6D28C8F8 for ; Wed, 20 Feb 2008 20:18:04 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 20 Feb 2008 23:17:46 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 20 Feb 2008 23:17:41 -0500 From: Hadriel Kaplan To: Francois Audet , Paul Kyzivat , "Elwell, John" Date: Wed, 20 Feb 2008 23:17:37 -0500 Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-Index: Achz1BycDA1pMO0bSE2u7o+mDcgWDgAMptFgAAxeEUA= Message-ID: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List , Henry Sinnreich , "paf@cisco.com" , Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think it depends on what you think the future looks like. Yes a PBX PRI can spoof a CLID, though I would argue it's much harder to fake an ANI (because of who sets it). But anyway, I think such a thing is more limited in scope on the PSTN simply because there is less benefit to doing it. If you do it from a PRI, there is a physical link and switch records can be used to track back, and so your gain is limited - unless it's targeted at specific individuals (which makes that very insidious). Add to that that it still costs money to make the calls usually, and the benefit goes down further. But if you think in the future (a) call cost approaches zero or becomes bulk in nature, at least for voip-voip calls, and (b) voip peering grows and/or open providers are included, then the benefit of CLID spoofing grows to potentially make SPIT profitable or Phishing attacks untraceable. It's not a near-term problem, and may never be a problem. It's just that email has such a problem and so there's concern that SIP could too someday. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Francois Audet > Sent: Wednesday, February 20, 2008 4:28 PM > To: Paul Kyzivat; Elwell, John > Cc: IETF SIP List; Henry Sinnreich; paf@cisco.com; Richard Shockey > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > I think it's time for a reality check... > > In the PSTN, if you are an enterprise and have a trunk to a service > provider, > you can pretty much put whatever you want in the Calling Party Number (you > can't do that from home with an individual line as the CO puts the Calling > Party Number for you). The network will pass it for you to the other end. > > So, not only is the identity in PSTN "hop-by-hop" and not end-to-end, > anybody > with suitable trunk interface can spoof anybody else. > > So again, I don't see why WE need to worry about phone number identity. > > I agree with Jonathan that we should just document the limitations. > > And personally, I don't mind if we restrict the usefulness end-to-end > identity (4474) to addresses where the domain name actually matters and is > not ignored (as is the case with user=phone type numbers). > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Wednesday, February 20, 2008 07:18 > > To: Elwell, John > > Cc: IETF SIP List; Henry Sinnreich; paf@cisco.com; Richard Shockey > > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > > > It seems that we have two parallel worlds: one using > > email-style addresses and another using phone numbers. While > > there are some devices that can play in both worlds, the > > majority of devices can only play in one of the worlds, or at > > least are strongly biased towards one so that usability with > > the other form is compromised. > > > > It seems essential that sip find a way to be successful in > > the phone number world - at least to the extent that a sip > > device in not perceived as being functionally worse than a > > comparable device using PSTN protocols. No amount of arguing > > that things would be better if you just used an email-style > > address will win the day there. > > > > The alternative is to accept that sip is worse than native > > PSTN equipment for phone numbers, and hope that the parallel > > communications world based on email-style addresses will > > eventually win out. But that is like waiting for IPv4 to be > > replaced by IPv6. > > > > Paul > > > > Elwell, John wrote: > > > Hannes, > > > > > > I know the questions were directed at Henry. However, if I may > > > intervene: > > > > > >> -----Original Message----- > > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] > > On Behalf Of > > >> Hannes Tschofenig > > >> Sent: 20 February 2008 08:00 > > >> To: Henry Sinnreich > > >> Cc: IETF SIP List; paf@cisco.com; Richard Shockey > > >> Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > >> > > >> Hi Henry, > > >> > > >> there are two aspects to the story: > > >> > > >> * Do you believe there is a problem for security when interworking > > >> between the PSTN and SIP? > > >> (e.g., in the way how SIP Identity deals with E.164 numbers) > > > [JRE] There are actually two separate situations: use of > > E.164 numbers > > > for communication within the SIP world; and use of E.164 > > numbers when > > > interworking between SIP and PSTN. Did you intentionally limit your > > > question to the second of these? > > > Assuming that was the intention, I would point out that we > > can never > > > achieve end-to-end security when interworking with PSTN. > > The best we > > > can do is achieve security across the local SIP part as far as the > > > PSTN gateway. There are different opinions as to whether the PSTN > > > itself is secure - I won't express an opinion on that > > aspect. However, > > > what happens beyond the PSTN? Another SIP hop? An H.323 > > hop? There is > > > no way of knowing whether that is secured or not. Some guarantee of > > > security as far as the gateway is the best we can achieve, and, > > > importantly, the user should be made aware of this - do not > > raise his > > > expectations concerning the end-to-end security of the call. > > > > > > Let's concentrate on the end-to-end SIP case and provide a good > > > security solution for that. One possibility might be to use > > > email-style URIs for that. > > > > > > John > > > > > >> * If yes, do you think that someone should be > > investigating what todo > > >> about it? > > >> > > >> Don't get hung-up in the details of a specific strawman proposal > > >> that, I believe, shows quite well some of the challenges > > around the > > >> aspect of > > >> E.164 number ownership. > > >> > > >> Ciao > > >> Hannes > > >> > > >> > > >> Henry Sinnreich wrote: > > >>>> "Here is this problem, this is what we > > >>>> (IETF) think, the solution is in your court. Have a nice day." > > >>>> > > >>> I believe this puts it in nutshell. > > >>> > > >>> The telecom specific uses of ENUM technology are more > > appropriately > > >>> handled in the telecom standards organizations, such as the > > >> ITU-T, and > > >>> ETSI. > > >>> > > >>> Let's move on and work with Internet and web addressing > > >> that I believe > > >>> have the real potential for the Internet standards > > >> development and where > > >>> IETF resources are better placed. > > >>> > > >>> Thanks, Henry > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > >> Behalf Of > > >>> Richard Shockey > > >>> Sent: Tuesday, February 19, 2008 10:20 AM > > >>> To: Hannes.Tschofenig@gmx.net > > >>> Cc: 'IETF SIP List'; paf@cisco.com > > >>> Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > >>> > > >>> This is not to say that the IETF could play a useful and > > >> essential role. > > >>> We > > >>> can certainly develop and define the requirements, use cases etc. > > >>> > > >>> In addition the IETF can architect a solution but > > >> experience tells me > > >>> that > > >>> deployment and implementation issues surrounding e164 > > >> issues will need > > >>> the > > >>> cooperation of "other bodies" which is where the problem > > >> lies. It's not > > >>> really the ITU, in fact the ITU is a much easier place to > > get things > > >>> done these days. The complications arise with the ITU > > member states, > > >>> who jealously guard their diplomatic and political prerogatives. > > >>> > > >>> This was the conclusion that we drew when the > > >> Infrastructure ENUM issues > > >>> first arose. We essentially said ..."Here is this problem, > > >> this is what > > >>> we > > >>> (IETF) think, the solution is in your court. Have a nice day." > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >>>> Sent: Tuesday, February 19, 2008 10:49 AM > > >>>> To: Richard Shockey > > >>>> Cc: 'IETF SIP List'; paf@cisco.com > > >>>> Subject: Re: Infrastructure issues involving e164 numbers > > >>>> > > >>>> > > >>>> > If there is going to be a solution to the SIP > > identity problem > > >>>> involving > e164 numbers, it will not IMHO be solved in > > the IETF. > > >>>> > > > >>>> > > > >>>> Interesting view. I obviously does not appear to be an > > easy thing; > > >>>> in the draft I called this "There is non-neglectable deployment > > >>>> incentive challenge." > > >>>> > > >>> > > >>> _______________________________________________ > > >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > >>> This list is for NEW development of the core SIP Protocol Use > > >>> sip-implementors@cs.columbia.edu for questions on current sip Use > > >>> sipping@ietf.org for new developments on the application of sip > > >>> > > >> _______________________________________________ > > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol Use > > >> sip-implementors@cs.columbia.edu for questions on current sip Use > > >> sipping@ietf.org for new developments on the application of sip > > >> > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 21:25:05 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B9628C8E1; Wed, 20 Feb 2008 21:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.074 X-Spam-Level: X-Spam-Status: No, score=-0.074 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkRPOEIBv3qz; Wed, 20 Feb 2008 21:25:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE0D28C83D; Wed, 20 Feb 2008 21:25:04 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E092228C6EA for ; Wed, 20 Feb 2008 21:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju2ObBOJOyyO for ; Wed, 20 Feb 2008 21:25:02 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EE70B28C80A for ; Wed, 20 Feb 2008 21:25:01 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 21 Feb 2008 00:24:44 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 21 Feb 2008 00:24:44 -0500 From: Hadriel Kaplan To: Dean Willis Date: Thu, 21 Feb 2008 00:24:43 -0500 Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-Index: Ach0PK1PWzBj1z8iTg6QVIBZzTKTNgABi+sw Message-ID: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> <47BCAD63.7060502@cisco.com> <75BEF7A7-147C-4BC2-8ABC-854869A7EAC9@softarmor.com> In-Reply-To: <75BEF7A7-147C-4BC2-8ABC-854869A7EAC9@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org But since there's no way to stop the signer from simply converting to a sip-URI, or decide/not to sign things, what you're saying is the verifier/UAS must not believe the ID of any signed request if the From is an E.164, regardless of sip|sips|tel, right? And since the signer could just remove the user=phone param before signing, you're saying the UAS can't believe it if the username even looks like an E.164? -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Wednesday, February 20, 2008 10:48 PM > To: Michael Thomas > Cc: IETF SIP List; Paul Kyzivat; Richard Shockey; Henry Sinnreich; Elwell, > John; paf@cisco.com > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > It makes perfect sense to strongly assert an identity than one has > high confidence in, and if we're lucky enough to have an end-to-end > path that preserves the integrity of the assertion, then we're good. > What happens if we aren't so lucky? > > I'm more concerned about the "other direction" -- that is, an identity > assertion that came from the PSTN is never going to be stronger than > the PSTN, no matter how we package it. And by packaging it wrongly, we > can give a false impression as to its validity. > > A link that transitions "downward" on the axes of integrity protection > doesn't need to inform the next hop of this downgrade; the next hop > can assume that the integrity protection is no stronger than that > provided by the immediately preceding link. It's when links try to > upgrade the protections that errors are introduced. > > It is entirely possible that our "security" mechanisms might be > deployed in such a way that the eventual recipient is blinded to the > weakness of such an assertion and therefore makes a mistake in > trusting it. If the cryptographic envelope is "upgraded", we need some > way to preserve the provenance of the assertion in order to keep this > form happening. > > The simplest approach is to always consider a "tel:" assertion to be > at the PSTN level of strength, even if it came from an IP source. > > This would imply "use domain-level source addressing when you can; if > coming from PSTN, use telephone addressing, and never convert back". > > -- > Dean > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 23:46:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1639428C997; Wed, 20 Feb 2008 23:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCZGxoZGTV12; Wed, 20 Feb 2008 23:46:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBEA28C8AE; Wed, 20 Feb 2008 23:46:44 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ACB728C8AE for ; Wed, 20 Feb 2008 23:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpjdCsqgSExy for ; Wed, 20 Feb 2008 23:46:41 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 8D95828C7A2 for ; Wed, 20 Feb 2008 23:46:41 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWK0098GW9PPJ@siemenscomms.co.uk> for sip@ietf.org; Thu, 21 Feb 2008 07:46:37 +0000 (GMT) Date: Thu, 21 Feb 2008 07:46:36 +0000 From: "Elwell, John" In-reply-to: <47BCA315.8010908@cisco.com> To: Paul Kyzivat , Francois Audet Message-id: <0D5F89FAC29E2C41B98A6A762007F5D069898F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Infrastructure issues involving e164 numbers thread-index: Ach0DI1uD34MvPc/SFq58hMMKKZv8gAUN1mg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> <47BCA315.8010908@cisco.com> Cc: IETF SIP List , Henry Sinnreich , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, You wrote: > The SP *should* be restricting what the enterprise can put > based on the > numbers that the SP knows belong to the enterprise. (The SP > doesn't need > to care if the number is the precise one originating this call.) [JRE] The problem is a call that comes from a different part of a large enterprise, with a number that is not within the range of numbers reachable from that particular SP. Or a call that comes from outside the enterprise and then is forwarded to the PSTN (say to the enterprise user's home or mobile phone). This "unscreened" number can advantageously be passed to the callee. John _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 20 23:49:09 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E04128C996; Wed, 20 Feb 2008 23:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEmaClKFVkgT; Wed, 20 Feb 2008 23:49:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DD928C9AA; Wed, 20 Feb 2008 23:49:01 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B05728C9CC for ; Wed, 20 Feb 2008 23:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSP1PNN1dbNj for ; Wed, 20 Feb 2008 23:48:59 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id A81D228C9DB for ; Wed, 20 Feb 2008 23:48:49 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWK009AVWD9PJ@siemenscomms.co.uk> for sip@ietf.org; Thu, 21 Feb 2008 07:48:45 +0000 (GMT) Date: Thu, 21 Feb 2008 07:48:45 +0000 From: "Elwell, John" In-reply-to: <47BCA355.2050208@cisco.com> To: Michael Thomas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0698991@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Infrastructure issues involving e164 numbers thread-index: Ach0DI8ZcNvOw7dHQVW77h6riuw4LQAUWs+g Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> Cc: IETF SIP List , Paul Kyzivat , paf@cisco.com, Henry Sinnreich , Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 20 February 2008 22:02 > To: Elwell, John > Cc: Paul Kyzivat; IETF SIP List; Henry Sinnreich; > paf@cisco.com; Richard Shockey > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > Elwell, John wrote: > > Paul, > > > > That is not quite what I meant. I meant that for PSTN > interworking there > > is no point in trying to do anything more secure on the SIP > hop than the > > security provided by the PSTN hop and anything beyond the > PSTN. Security > > is only as good as the weakest link. So let's try to be as > good, but not > > better. In the SIP world we can try to be better. > > > > Hold on a second. Doesn't SIP have the concept of > redirection? That is, > even if I use a tel: URL I might get redirected to another > device which > doesn't ever touch the PSTN? > > It sure seems to me that the prudent thing to do is *always* use the > best security you can instead of trying to divine whether it's going > to end up being on a less secure path. [JRE] I agree, but when a PSTN gateway is encountered we may have to downgrade to the level of security appropriate to a mixed SIP-PSTN call. John _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 00:39:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F068028C9C2; Thu, 21 Feb 2008 00:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.672 X-Spam-Level: X-Spam-Status: No, score=-0.672 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBb2Kte-Dgfi; Thu, 21 Feb 2008 00:39:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B7028C9C5; Thu, 21 Feb 2008 00:39:06 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22C228C2B2 for ; Thu, 21 Feb 2008 00:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIv4ehvvjM97 for ; Thu, 21 Feb 2008 00:39:03 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 06C4628C988 for ; Thu, 21 Feb 2008 00:39:03 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWK00D9DYOX07@siemenscomms.co.uk> for sip@ietf.org; Thu, 21 Feb 2008 08:38:57 +0000 (GMT) Date: Thu, 21 Feb 2008 08:38:55 +0000 From: "Elwell, John" In-reply-to: <47BCA5AE.8090708@cisco.com> To: Paul Kyzivat , Michael Thomas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D06989AF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Infrastructure issues involving e164 numbers thread-index: Ach0DpXIHf3CO56ZSjmb83H4yfwUnAAT6qLA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> <47BCA5AE.8090708@cisco.com> Cc: IETF SIP List , Henry Sinnreich , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 20 February 2008 22:12 > To: Michael Thomas > Cc: Elwell, John; IETF SIP List; Henry Sinnreich; > paf@cisco.com; Richard Shockey > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > I agree with Mike here. > > People are clearly tolerating a less than ideal situation in > the pstn. > Many know that the mechanisms for securing the callerid (and > the media) > are not 100%, but they think they are also more than 0% and > are willing > to tolerate the level they get. > > We ought to be pulling the percentages up, rather than down. > E.g. being > able to assert that the information is accurate back to the > nearest PSTN > gw is better than not. [JRE] Agreed. But this is still a downgraded security, because the fact that I have a secure connection to a PSTN gateway doesn't tell me anything about the end-to-end security. John _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 01:18:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9158328CA20; Thu, 21 Feb 2008 01:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvEuBF4MvWq3; Thu, 21 Feb 2008 01:18:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724FD28C9EB; Thu, 21 Feb 2008 01:18:44 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0144328C9E3 for ; Thu, 21 Feb 2008 01:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCrhkFc02uem for ; Thu, 21 Feb 2008 01:18:41 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id BA62028C9E4 for ; Thu, 21 Feb 2008 01:18:41 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWL00F7B0J2N7@siemenscomms.co.uk> for sip@ietf.org; Thu, 21 Feb 2008 09:18:38 +0000 (GMT) Date: Thu, 21 Feb 2008 09:18:36 +0000 From: "Elwell, John" In-reply-to: <47BA6CE4.8090004@lab.ntt.co.jp> To: Mayumi Munakata , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0698A03@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Anonymous URI for From header in ua-privacy-01 thread-index: AchyvG8qWjxHbJyDQi+3K972fdo/SQBrXg7A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47BA6CE4.8090004@lab.ntt.co.jp> Subject: Re: [Sip] Anonymous URI for From header in ua-privacy-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Mayumi, I would note that RFC 4474 already allows option 1. I see various emails discussing the usefulness of this. I can see it as beneficial where a domain wishes to assert that the request originated in that domain, but does not wish to disclose the particular user ID, e.g., in call centres. Given that this is already allowed in RFC 4474, I would prefer that the ua-privacy draft does nothing to deprecate that. Of course, we also need to allow the use of option 2. I don't see a need for option 3, and I haven't heard anyone else speaking in its favour. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Mayumi Munakata > Sent: 19 February 2008 05:45 > To: sip@ietf.org > Subject: [Sip] Anonymous URI for From header in ua-privacy-01 > > All; > > I have just submitted a new version of ua-privacy draft. > http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-01.txt > > Thanks to John Elwell for his comprehensive review, > we managed to make a lot of editorial corrections > and some technical. > > One profound open issue we have is on how to get an > anonymous URI for a From header. While we can use a > temp-gruu for a Contact header, there is no mechanism > to obtain a functional anonymous URI for the From > header or any other headers that houses URIs. > > RFC3323 recommends to use "anonymous@anonymous.invalid" > for an anonymous URI in a From header. However, this > impedes the use of SIP-Identity, as SIP-Identity > mandates the domain portion of the "From" URI and > that of "Identity-Info" to match. > > One of the expired draft written by Jonathan, attempted > to use the GRUU to get this functional yet anonymous URI > to address this issue. > http://ietfreport.isoc.org/idref/draft-rosenberg-sip-identity-privacy/ > > I can see few ways forward. > > 1. Suggest the use of anonymous@{user's domain name}, which > verifier then can verify the signature's validity as > domain portion of the URI and that of Identity-Info matches. > >> If SIP-Identity is used, the domain is given away anyhow > in the Identity-Info, so what is the point of hiding the > domain in the From header? > > 2. Make a note that SIP-Identity will not function when > anonymous@anonymous.invalid is used. > >> Describe the caveat that verifier is likely to fail the > request or suggest that Authentication Service does not > add Identity-Info/signature. > > 3. Extend GRUU to support mechanism that Rosenberg suggested. > > Does anybody has any preferences or any other suggestions? > > Regards, > Mayumi > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 03:55:05 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B852228C632; Thu, 21 Feb 2008 03:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7r15u0cAGVl; Thu, 21 Feb 2008 03:55:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7AC28C460; Thu, 21 Feb 2008 03:55:04 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E54C28C460 for ; Thu, 21 Feb 2008 03:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brxjaZKsM-bd for ; Thu, 21 Feb 2008 03:54:58 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 7327F28C3D4 for ; Thu, 21 Feb 2008 03:54:57 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m1LBsX1C007442; Thu, 21 Feb 2008 05:54:48 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 05:54:43 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 12:54:41 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 12:54:39 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001C68879@DEEXC1U01.de.lucent.com> In-Reply-To: <469EDDD3-1091-4BA4-8763-054468058834@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-index: Ach0DrbF1s8sq6f2TSyDWza7O26oRAAb6oPQ References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com><1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com><47BCA315.8010908@cisco.com> <469EDDD3-1091-4BA4-8763-054468058834@softarmor.com> From: "DRAGE, Keith \(Keith\)" To: "Dean Willis" X-OriginalArrivalTime: 21 Feb 2008 11:54:41.0293 (UTC) FILETIME=[8AC60BD0:01C87480] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: IETF SIP List Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Just to put some background to what is happening here with caller id in the PSTN. If the calling terminal provides a caller id, then the public network has two options: - it screens it (is this line entitled to use this number) and puts it in the ISUP calling party number field - it does not screen it and puts it in the generic number parameter. The calling party number has some sort of default number for the access. Which of these it does depends on a special arrangement. US providers appear to give that special arrangement to everyone. European operators will either give that special arrangement only to PBX customers (i.e. they trust the PBX operator to configure the equipment to deliver numbers to some level of trust), or they do not provide it at all (no trust). The reason for this is based on history. At the terminating side calling line identity is provided using the content on the generic number if present, and then on the calling party number (in ISDN both are delivered by the second may well be discarded). Malicious call identification (the network recording call details) is based primarily on the contents of the calling party number, and only optionally records other identities. Therefore if the police do bother to turn up, they will turn up to the address associated with the default number for that line if the special arrangement exists. And none of this is capable of being mimicked completely by RFC 3325 or RFC 4474 so that provides yet another set of rules. Regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Wednesday, February 20, 2008 10:17 PM > To: Paul Kyzivat > Cc: IETF SIP List; Francois Audet; Richard Shockey; Henry > Sinnreich; Elwell,John; paf@cisco.com > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > > On Feb 20, 2008, at 4:00 PM, Paul Kyzivat wrote: > > > > > > > Francois Audet wrote: > >> I think it's time for a reality check... > >> > >> In the PSTN, if you are an enterprise and have a trunk to > a service > >> provider, you can pretty much put whatever you want in the Calling > >> Party Number (you can't do that from home with an > individual line as > >> the CO puts the Calling Party Number for you). The network > will pass > >> it for you to the other end. > > > > Why hasn't somebody sued a SP for providing false identity??? > > > > The SP *should* be restricting what the enterprise can put based on > > the numbers that the SP knows belong to the enterprise. (The SP > > doesn't need to care if the number is the precise one > originating this > > call.) > > > > But I knew this. In principle the reliability of the pstn > callerid is > > nonexistent. But because it is somewhat difficult for most users to > > spoof, *on average* callerid is reasonably reliable. Enough so that > > many can/do make use of it. > > > > (Admittedly the ease of spoofing is increasing, and so the average > > reliablility of callerid is probably going down.) > > It's also because the telephony service provider has > additional logging records that can be used to back-trace the > call if it turns out to have been fraudulently identified. > > Try this experiment: Take your home ISDN BRI line. Add your > own terminal adapter with POTS interface (if you don't have > one, I'll be happy to sell you one of mine -- I have several > that need to be eBayed). Dummy up your CPID field to whatever > you want (this works, at least here on Verizon lines). Now > place a crank call to somebody very important, and see how > long it takes for the authorities to show up . . . > > -- > Dean > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 07:00:38 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286A428C9FB; Thu, 21 Feb 2008 07:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-1.736, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oymce5lhdP6r; Thu, 21 Feb 2008 07:00:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094AF28C946; Thu, 21 Feb 2008 07:00:37 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF3A28C65C for ; Thu, 21 Feb 2008 07:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+9+Ko2k89jo for ; Thu, 21 Feb 2008 07:00:34 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8638528C518 for ; Thu, 21 Feb 2008 07:00:34 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Feb 2008 10:00:31 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1LF0UUj009722; Thu, 21 Feb 2008 10:00:30 -0500 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 m1LExtV4017362; Thu, 21 Feb 2008 15:00:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 10:00:15 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 10:00:14 -0500 Message-ID: <47BD920A.6000005@cisco.com> Date: Thu, 21 Feb 2008 10:00:26 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Elwell, John" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> <47BCA315.8010908@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069898F@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D069898F@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 21 Feb 2008 15:00:14.0880 (UTC) FILETIME=[76E89A00:01C8749A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1678; t=1203606030; x=1204470030; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Infrastructure=20issues=20invol ving=20e164=20numbers |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=DTxF/v1Oi2S1Jeh6ZzQZZyU6HQXsi4k4VL21KinrQ3k=; b=TqXkLVxHJq59ObHG8uG3ZIqZy/rs2Cyidn5aJzvEKftCpcfh4Gww9Pkuwb VTx7LPaIy/op8ysGQ4dBUy+LOILjHgdGwF2u41suT5X6BdgsxCojOXrfatRm rbzAc0pCF5; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: IETF SIP List , Francois Audet , paf@cisco.com, Henry Sinnreich , Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Paul, > > You wrote: >> The SP *should* be restricting what the enterprise can put >> based on the >> numbers that the SP knows belong to the enterprise. (The SP >> doesn't need >> to care if the number is the precise one originating this call.) > [JRE] The problem is a call that comes from a different part of a large > enterprise, with a number that is not within the range of numbers > reachable from that particular SP. You are saying that the enterprise has numbers assigned/managed by multiple SPs, and the call is entering the PSTN from the enterprise via a GW attached to SP1 while the asserted number is managed by SP2? In that case the enterprise in effect acting as a transit network. Either the SP must really *trust* the enterprise, or else it should have a list of all the numbers assigned to the enterprise, or else it should treat this as invalid or block the identity. The enterprise can solve this by entering the PSTN through the SP that can verify the ID. > Or a call that comes from outside the > enterprise and then is forwarded to the PSTN (say to the enterprise > user's home or mobile phone). This "unscreened" number can > advantageously be passed to the callee. Only an issue if the call is hairpinned through the enterprise. If it is, then again it is acting as a transit network, and trust is required. Of course trust is a dangerous thing, especially in the last case. How did the enterprise verify this identity before reasserting it? But I see your point. The SPs may have caved to demands from their customers to trade off accuracy vs functionality. Paul _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 07:03:31 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC6328C777; Thu, 21 Feb 2008 07:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-1.704, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnGszXO8HaK2; Thu, 21 Feb 2008 07:03:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4788728C518; Thu, 21 Feb 2008 07:03:30 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0119D28C2A3 for ; Thu, 21 Feb 2008 07:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB339VAvAVIo for ; Thu, 21 Feb 2008 07:03:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 771C028C9FB for ; Thu, 21 Feb 2008 07:02:51 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2008 10:02:48 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1LF2lBx011718; Thu, 21 Feb 2008 10:02:47 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1LF2aJj009204; Thu, 21 Feb 2008 15:02:47 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 10:02:44 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 10:02:43 -0500 Message-ID: <47BD929F.6060501@cisco.com> Date: Thu, 21 Feb 2008 10:02:55 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Elwell, John" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> <47BCA5AE.8090708@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D06989AF@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D06989AF@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 21 Feb 2008 15:02:43.0898 (UTC) FILETIME=[CFBAF1A0:01C8749A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1604; t=1203606167; x=1204470167; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Infrastructure=20issues=20invol ving=20e164=20numbers |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=Vi3ZD3XhhS28JGDIGGXg0vEDBsA1whT55wnkbkMiMq4=; b=kvFfDXZTmetiji2aoCQongSu3SNRi9Wnq0pwBUoZS4QSafaLDnnox+SJvN SLtTkwKdsKDGOCRTO5fWCtG9unSmqtUTbOP7QMAgBfIaYJ9RlwHrwNz9l87H g/pfTjxadV; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: IETF SIP List , Henry Sinnreich , Michael Thomas , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John, I agree. Taking the number learned from the PSTN and asserting it with something akin to sip identity would be asserting more than is known. It seems that some weaker form of assertion is needed. (PSTN-grade security.) Paul Elwell, John wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 20 February 2008 22:12 >> To: Michael Thomas >> Cc: Elwell, John; IETF SIP List; Henry Sinnreich; >> paf@cisco.com; Richard Shockey >> Subject: Re: [Sip] Infrastructure issues involving e164 numbers >> >> I agree with Mike here. >> >> People are clearly tolerating a less than ideal situation in >> the pstn. >> Many know that the mechanisms for securing the callerid (and >> the media) >> are not 100%, but they think they are also more than 0% and >> are willing >> to tolerate the level they get. >> >> We ought to be pulling the percentages up, rather than down. >> E.g. being >> able to assert that the information is accurate back to the >> nearest PSTN >> gw is better than not. > [JRE] Agreed. But this is still a downgraded security, because the fact > that I have a secure connection to a PSTN gateway doesn't tell me > anything about the end-to-end security. > > John > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 08:36:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FD628C2A3; Thu, 21 Feb 2008 08:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-1.226, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TAJoCeeBKdi; Thu, 21 Feb 2008 08:36:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BF628CB15; Thu, 21 Feb 2008 08:36:15 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE30828CB11 for ; Thu, 21 Feb 2008 08:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdFbyEkhK4Dt for ; Thu, 21 Feb 2008 08:36:09 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C36E728CB15 for ; Thu, 21 Feb 2008 08:34:50 -0800 (PST) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 21 Feb 2008 08:34:47 -0800 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.67.143]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m1LGLdGF031971; Thu, 21 Feb 2008 08:21:39 -0800 Message-ID: <47BDA82F.5080600@cisco.com> Date: Thu, 21 Feb 2008 08:34:55 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Elwell, John" References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> <47BCA5AE.8090708@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D06989AF@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D06989AF@GBNTHT12009MSX.gb002.siemens.net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1679; t=1203610899; x=1204474899; 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:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20Infrastructure=20issues=20invol ving=20e164=20numbers |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=Z0PhqQXaPrySEtJI9rczQJPCrDUDQvvBhAw+pFENE4Q=; b=OIFqP4V6uhT9iZ79+XY3/GUBndjJet6p4llzbZX7QyXLkC8Wwmkwyxbnmm PWV2pJqU04oYxc8v3mjMF79kjcDxNmXnG9PwhMliVfeEJtyhmQH3GmwgtJmc kR+HHumj3M; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: IETF SIP List , Paul Kyzivat , paf@cisco.com, Henry Sinnreich , Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 20 February 2008 22:12 >> To: Michael Thomas >> Cc: Elwell, John; IETF SIP List; Henry Sinnreich; >> paf@cisco.com; Richard Shockey >> Subject: Re: [Sip] Infrastructure issues involving e164 numbers >> >> I agree with Mike here. >> >> People are clearly tolerating a less than ideal situation in >> the pstn. >> Many know that the mechanisms for securing the callerid (and >> the media) >> are not 100%, but they think they are also more than 0% and >> are willing >> to tolerate the level they get. >> >> We ought to be pulling the percentages up, rather than down. >> E.g. being >> able to assert that the information is accurate back to the >> nearest PSTN >> gw is better than not. >> > [JRE] Agreed. But this is still a downgraded security, because the fact > that I have a secure connection to a PSTN gateway doesn't tell me > anything about the end-to-end security. > I think it might be worthwhile to keep in mind that there's more to overall security than absolute guarantees that can be made to individuals. Security is also about populations, and overall risk management. Mainly what we're trying to do is get the bad guys to find somebody else to annoy rather than hoping you can survive a full frontal attack. Defending the SIP side of the house regardless of any weaker links is just inviting the bad guys to go find something else to do with their time which most likely has nothing to do with telephony at all since the pstn side of this is already pretty well understood. Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 08:42:58 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2348728C293; Thu, 21 Feb 2008 08:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh-455ez1xvj; Thu, 21 Feb 2008 08:42:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A024A3A6EA3; Thu, 21 Feb 2008 08:42:52 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1223A6E9E for ; Thu, 21 Feb 2008 08:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ-B5XZqBFwx for ; Thu, 21 Feb 2008 08:42:50 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4A7C73A6E9A for ; Thu, 21 Feb 2008 08:42:50 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1LGghMt027861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Feb 2008 10:42:44 -0600 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 10:42:37 -0600 References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> <47BCAD63.7060502@cisco.com> <75BEF7A7-147C-4BC2-8ABC-854869A7EAC9@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 20, 2008, at 11:24 PM, Hadriel Kaplan wrote: > > But since there's no way to stop the signer from simply converting > to a sip-URI, or decide/not to sign things, what you're saying is > the verifier/UAS must not believe the ID of any signed request if > the From is an E.164, regardless of sip|sips|tel, right? And since > the signer could just remove the user=phone param before signing, > you're saying the UAS can't believe it if the username even looks > like an E.164? > That would be one way to handle it "by convention". There may be better solutions. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 09:03:52 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0ED428CC2A; Thu, 21 Feb 2008 09:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-1.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIEPIQWjFj96; Thu, 21 Feb 2008 09:03:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D1528CC12; Thu, 21 Feb 2008 09:01:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A084B28CABB for ; Thu, 21 Feb 2008 09:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZRgegWbh0HU for ; Thu, 21 Feb 2008 09:00:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5AB2628CB74 for ; Thu, 21 Feb 2008 08:59:52 -0800 (PST) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 21 Feb 2008 08:59:49 -0800 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.67.143]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m1LGkeNt000518; Thu, 21 Feb 2008 08:46:40 -0800 Message-ID: <47BDAE0C.1050902@cisco.com> Date: Thu, 21 Feb 2008 08:59:56 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Paul Kyzivat References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069894D@GBNTHT12009MSX.gb002.siemens.net> <47BCA355.2050208@cisco.com> <47BCA5AE.8090708@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D06989AF@GBNTHT12009MSX.gb002.siemens.net> <47BD929F.6060501@cisco.com> In-Reply-To: <47BD929F.6060501@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2468; t=1203612401; x=1204476401; 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:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20Infrastructure=20issues=20invol ving=20e164=20numbers |Sender:=20 |To:=20Paul=20Kyzivat=20; bh=puNiTGE6YYW1wC0us6lQRiSTcOwCgJpNdoPstEenRmA=; b=bS2J20EqifOVAlvSZtFYePhXdfKAFyVTQ1KnrAXonUJzmGR/YNvHwwV1iR 9hZvsDfwDH23NvvdVEvt3rgi3TI6Zb/nn0cAJ6ePXnhEIRRX36S6NW3GwxBk AqUK7eiErd; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: IETF SIP List , paf@cisco.com, Henry Sinnreich , "Elwell, John" , Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > John, > > I agree. Taking the number learned from the PSTN and asserting it with > something akin to sip identity would be asserting more than is known. > > It seems that some weaker form of assertion is needed. (PSTN-grade > security.) With email and DKIM, there are really two kinds of assertions that can be made: 1) this message came from me 2) this message passed through me I actively don't want to sign messages that purport to come from me from sources I don't trust (like, say, the internet). The second is more of a statement of fact, essentially being a digitally signed received: (via) header. I think that both are interesting assertions for filters, and it seems to me that the same situation exists with SIP. For example, I may want to whitelist anything coming through ietf.org even though I can't _really_ count on the validity of the From: address. That's because experience tells me that the likelihood of ietf.org being an attack vector is extremely low. Mike, hoping to get ietf.org dkim signing soon > > Paul > > Elwell, John wrote: >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 20 February >>> 2008 22:12 >>> To: Michael Thomas >>> Cc: Elwell, John; IETF SIP List; Henry Sinnreich; paf@cisco.com; >>> Richard Shockey >>> Subject: Re: [Sip] Infrastructure issues involving e164 numbers >>> >>> I agree with Mike here. >>> >>> People are clearly tolerating a less than ideal situation in the >>> pstn. Many know that the mechanisms for securing the callerid (and >>> the media) are not 100%, but they think they are also more than 0% >>> and are willing to tolerate the level they get. >>> >>> We ought to be pulling the percentages up, rather than down. E.g. >>> being able to assert that the information is accurate back to the >>> nearest PSTN gw is better than not. >> [JRE] Agreed. But this is still a downgraded security, because the fact >> that I have a secure connection to a PSTN gateway doesn't tell me >> anything about the end-to-end security. >> >> John >> >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 09:04:17 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C8628CCAF; Thu, 21 Feb 2008 09:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuuErn4bu2i5; Thu, 21 Feb 2008 09:04:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9147728CCD5; Thu, 21 Feb 2008 09:01:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88CD28CB91 for ; Thu, 21 Feb 2008 09:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh4vPx5WEnGP for ; Thu, 21 Feb 2008 09:01:23 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2DF3528CB99 for ; Thu, 21 Feb 2008 09:00:28 -0800 (PST) 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 m1LGuCc29101; Thu, 21 Feb 2008 16:56:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 11:00:10 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF150224B5@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D069898F@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Infrastructure issues involving e164 numbers Thread-Index: Ach0DI1uD34MvPc/SFq58hMMKKZv8gAUN1mgABM18WA= References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <134b01c8727c$b2b90440$182b0cc0$@us> <47BA842D.3060600@gmx.net> <0b6a01c8730c$eea1c4c0$cbe54e40$@us> <47BAFA7E.6060006@gmx.net> <0ccf01c87313$4613e160$d23ba420$@us> <24CCCC428EFEA2469BF046DB3C7A8D22019E0773@namail5.corp.adobe.com> <47BBDDEC.1080502@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0698662@GBNTHT12009MSX.gb002.siemens.net> <47BC44C0.6050801@cisco.com> <1ECE0EB50388174790F9694F77522CCF14FD9E28@zrc2hxm0.corp.nortel.com> <47BCA315.8010908@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D069898F@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Paul Kyzivat" Cc: IETF SIP List , Henry Sinnreich , paf@cisco.com, Richard Shockey Subject: Re: [Sip] Infrastructure issues involving e164 numbers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Exactly. For example, me sitting in California can make a SIP call to somebody in Texas. Internally, it will be routed through our internal network until it reaches a PSTN gateway in Texas (least-cost routing). That gateway will insert my california CLID in the ISDN message. And yes, this is totally prone to abuse. But the benefits have been judged by the industry to outweight the cost. So, trying to fix the "phone number" assertion problem seems (a) out of scope of what IETF's mandate is and (b) unlikely to be solveable. That is why my thinking is that we should focus on things were we can actually make a difference. "Email-looking addresses" or "Addresses where the domain matters" fall in that category. Putting a warning that if the system routes on the "user part" instead of the "domain" (like is often the case with phone numbers), it breaks domain-based identity assertion is a good start. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, February 20, 2008 23:47 > To: Paul Kyzivat; Audet, Francois (SC100:3055) > Cc: IETF SIP List; Henry Sinnreich; paf@cisco.com; Richard Shockey > Subject: RE: [Sip] Infrastructure issues involving e164 numbers > > Paul, > > You wrote: > > The SP *should* be restricting what the enterprise can put based on > > the numbers that the SP knows belong to the enterprise. (The SP > > doesn't need to care if the number is the precise one > originating this > > call.) > [JRE] The problem is a call that comes from a different part > of a large enterprise, with a number that is not within the > range of numbers reachable from that particular SP. Or a call > that comes from outside the enterprise and then is forwarded > to the PSTN (say to the enterprise user's home or mobile > phone). This "unscreened" number can advantageously be passed > to the callee. > > John > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 21 23:22:55 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297C83A6C65; Thu, 21 Feb 2008 23:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eVsnrKr6gt0; Thu, 21 Feb 2008 23:22:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988BB3A6A0D; Thu, 21 Feb 2008 23:22:53 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244953A685E for ; Thu, 21 Feb 2008 23:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE45lsZ-gHHF for ; Thu, 21 Feb 2008 23:22:50 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6CBDA3A6C09 for ; Thu, 21 Feb 2008 23:21:51 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m1M7LceU024357; Fri, 22 Feb 2008 01:21:38 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 01:21:38 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 08:21:35 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 08:21:36 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001C68A17@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on domain-certs and eku Thread-index: Ach1I47x4nFLQ/r9Sf6PE1fK5hI8NA== From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 22 Feb 2008 07:21:35.0522 (UTC) FILETIME=[8E819020:01C87523] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Jeffrey, Alan S A \(Alan\)" , slawrence@bluesocket.com Subject: [Sip] WGLC on domain-certs and eku X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (As WG chair) This is to announce a WG last call on BOTH http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt and http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-01.txt Comments should be submitted to both the list, and to the authors, by Friday 7th March 2008. This will give the opportunity for discussion of major issues at the SIP WG meeting in Philadelphia. Please clearly identify the position of any issue in the internet draft, and if possible identify what you would like to see as a correction. Please also indicate the nature or severity of the error or correction, e.g. Major technical, minor technical, NIT, so that we can quickly judge the extent of problems with the document. Note that both these documents are used by: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-09.txt This particular document is finished and ready for the publication request, but if you feel your comment also addresses the usage by this document, please clearly indicate and get the comment in. Regards Keith _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 22 06:15:09 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F0928CB43; Fri, 22 Feb 2008 06:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnzZGvQwEvCS; Fri, 22 Feb 2008 06:15:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661C728C391; Fri, 22 Feb 2008 06:15:05 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B42F028C224; Fri, 22 Feb 2008 06:15:02 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080222141502.B42F028C224@core3.amsl.com> Date: Fri, 22 Feb 2008 06:15:02 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-record-route-fix-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Addressing Record-Route issues in the Session Initiation Protocol (SIP) Author(s) : T. Froment, C. Lebel Filename : draft-ietf-sip-record-route-fix-02.txt Pages : 26 Date : 2008-02-22 A typical function of a Session Initiation Protocol (SIP) Proxy is to set a Record-Route header on initial requests in order to make subsequent requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain sip or sips schemes, IPV4 or IPV6 addresses, and URI parameters that could influence the routing like different transport parameters (UDP, TCP, SCTP...), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, sip to sips or IPV4 to IPV6 scenarios...), the question arises on what should be put in Record- Route header(s). It is just not possible to make one header having the characteristics of both sides at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which describes only a Record-Route rewriting solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-record-route-fix-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-record-route-fix-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-22060445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-record-route-fix-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-record-route-fix-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-22060445.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Feb 22 09:31:10 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C04128C38C; Fri, 22 Feb 2008 09:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjM6S-GRYKXG; Fri, 22 Feb 2008 09:31:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16C53A6CC1; Fri, 22 Feb 2008 09:31:08 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97E13A6CBD for ; Fri, 22 Feb 2008 09:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIff3NKmGTE8 for ; Fri, 22 Feb 2008 09:31:05 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CBE1D28C2B6 for ; Fri, 22 Feb 2008 09:31:04 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 22 Feb 2008 12:30:46 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 22 Feb 2008 12:30:46 -0500 From: Hadriel Kaplan To: IETF SIP List Date: Fri, 22 Feb 2008 12:31:00 -0500 Thread-Topic: ID updated: draft-kaplan-sip-baiting-attack-02.txt Thread-Index: Ach1eLC7qg4PteusQY6RHwjdjmacMQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Dan Wing Subject: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org FYI, the draft on the Baiting attack with RFC4474 has been updated: http://www.ietf.org/internet-drafts/draft-kaplan-sip-baiting-attack-02.txt I changed section 12.1 possible solution to the problem of the request being delivered to unintended recipients. This new solution only works for true SIP ends, vs. to a PSTN-gateway, but based on the mailing list discussion so far that appears to be a behavior the WG may want in the end. (Personally I feel one might as well then only make RFC4474 work for SIPS URIs with S/MIME bodies, but that's just personal opinion) -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 22 09:42:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A9928C190; Fri, 22 Feb 2008 09:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHcyw5fwypwa; Fri, 22 Feb 2008 09:42:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820153A6A21; Fri, 22 Feb 2008 09:42:51 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A343A69D7 for ; Fri, 22 Feb 2008 09:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxuEyLFZEb-1 for ; Fri, 22 Feb 2008 09:42:49 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 212E23A6BF0 for ; Fri, 22 Feb 2008 09:42:30 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWN00H30IDA95@siemenscomms.co.uk> for sip@ietf.org; Fri, 22 Feb 2008 17:39:10 +0000 (GMT) Date: Fri, 22 Feb 2008 17:39:00 +0000 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D06CF981@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt thread-index: Ach1eLC7qg4PteusQY6RHwjdjmacMQAANfRQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: Dan Wing Subject: Re: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel, You wrote: > (Personally I feel one might as well then only make RFC4474 > work for SIPS URIs with S/MIME bodies, but that's just > personal opinion) [JRE] The purpose of RFC 4474 was to provide authentication without requiring a certificate at the UA - S/MIME requires a certificate! John _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 22 09:44:49 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD6B3A68CA; Fri, 22 Feb 2008 09:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvjZibs37PBl; Fri, 22 Feb 2008 09:44:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718E53A68DB; Fri, 22 Feb 2008 09:44:47 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B653A68CA for ; Fri, 22 Feb 2008 09:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC2K5v1n7zR9 for ; Fri, 22 Feb 2008 09:44:46 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 361153A68DB for ; Fri, 22 Feb 2008 09:44:46 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 22 Feb 2008 12:44:28 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 22 Feb 2008 12:44:28 -0500 From: Hadriel Kaplan To: "Elwell, John" , IETF SIP List Date: Fri, 22 Feb 2008 12:44:41 -0500 Thread-Topic: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt Thread-Index: Ach1eLC7qg4PteusQY6RHwjdjmacMQAANfRQAAA8NvA= Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D06CF981@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D06CF981@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Dan Wing Subject: Re: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I know. It was a joke/wise-a$$ comment on the usefulness of this thing. :) -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Friday, February 22, 2008 12:39 PM > To: Hadriel Kaplan; IETF SIP List > Cc: Dan Wing > Subject: RE: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt > > Hadriel, > > You wrote: > > (Personally I feel one might as well then only make RFC4474 > > work for SIPS URIs with S/MIME bodies, but that's just > > personal opinion) > [JRE] The purpose of RFC 4474 was to provide authentication without > requiring a certificate at the UA - S/MIME requires a certificate! > > John _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 22 09:56:14 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4554A28C306; Fri, 22 Feb 2008 09:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxCJEcUzglOW; Fri, 22 Feb 2008 09:56:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A86C28C20F; Fri, 22 Feb 2008 09:56:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77FC628C17D for ; Fri, 22 Feb 2008 09:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iea9grgvvo8d for ; Fri, 22 Feb 2008 09:56:06 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B69D028C166 for ; Fri, 22 Feb 2008 09:56:06 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 22 Feb 2008 09:56:02 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1MHu20n023108; Fri, 22 Feb 2008 09:56:02 -0800 Received: from dwingwxp01 (dhcp-128-107-163-49.cisco.com [128.107.163.49]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m1MHtwJ9000643; Fri, 22 Feb 2008 17:56:02 GMT From: "Dan Wing" To: "'Elwell, John'" , "'Hadriel Kaplan'" , "'IETF SIP List'" References: <0D5F89FAC29E2C41B98A6A762007F5D06CF981@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 22 Feb 2008 09:55:57 -0800 Message-ID: <011601c8757c$2ff837d0$31a36b80@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D06CF981@GBNTHT12009MSX.gb002.siemens.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Ach1eLC7qg4PteusQY6RHwjdjmacMQAANfRQAABwLCA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1521; t=1203702962; x=1204566962; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20ID=20updated=3A=20draft-kaplan- sip-baiting-attack-02.txt |Sender:=20; bh=OV9OzJuRic/8zxiyUUkhSsY4eiRC9L95JrWH6bN0/8E=; b=Z1JX5vrJxFMtgGsUexIYp+K9/y4QpvClB7ICHNC+A9c+P2A74qXjjRYma8 fYr6jQq8Y8QZuLwXWcYHoaycK61ANcZfX5AD5nGY5xFJn1yAfxixxYiNjNqK khdT36yd4i; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > You wrote: > > (Personally I feel one might as well then only make RFC4474 > > work for SIPS URIs with S/MIME bodies, but that's just > > personal opinion) > > [JRE] The purpose of RFC 4474 was to provide authentication without > requiring a certificate at the UA - S/MIME requires a certificate! S/MIME requires a separate body part, too. But SIP neglected to clearly require support for multipart MIME and many implmentations neglect to include support for multipart MIME. Robert Sparks collected information on multipart MIME support a SIPit or two ago, : " This is how the endpoints answered how they supported multipart/mime: 7% I break if someone sends me multipart/mime 30% I pretend multipart mime doesn't exist if someone sends it to me 20% I ignore multipart/mime, but will proxy it or hand it to my application if it shows up 17% I try to do something useful with multipart/mime I receive, but I never send it 3% I ignore multipart/mime I receive, but I try to send it to do something useful 20% I try to do something useful with multipart/mime I send and receive " I expect any SIP functionality that relied on multipart MIME would have disappointing results in the field unless these numbers vastly improve. But without multipart MIME messages, implementors have little reason to code or test it. -d _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 22 09:58:23 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3DB928C482; Fri, 22 Feb 2008 09:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USz+nc+Nl5OD; Fri, 22 Feb 2008 09:58:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0673E28C171; Fri, 22 Feb 2008 09:56:49 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C3128C0E9 for ; Fri, 22 Feb 2008 09:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuQ2jWWPf4Qb for ; Fri, 22 Feb 2008 09:56:43 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BFAB13A6CD7 for ; Fri, 22 Feb 2008 09:56:43 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 22 Feb 2008 09:56:39 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1MHud9U009974; Fri, 22 Feb 2008 09:56:39 -0800 Received: from dwingwxp01 (dhcp-128-107-163-49.cisco.com [128.107.163.49]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m1MHudJ9000904; Fri, 22 Feb 2008 17:56:39 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Elwell, John'" , "'IETF SIP List'" References: <0D5F89FAC29E2C41B98A6A762007F5D06CF981@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 22 Feb 2008 09:56:39 -0800 Message-ID: <011701c8757c$4611df30$31a36b80@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Ach1eLC7qg4PteusQY6RHwjdjmacMQAANfRQAAA8NvAAAG70IA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=822; t=1203702999; x=1204566999; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20ID=20updated=3A=20draft-kaplan- sip-baiting-attack-02.txt |Sender:=20; bh=4iJh7Gvmxx5+U8+RX2b8tmk0cDEzmRJqznkBqm9dDHk=; b=zPnEp3NoLJ2Owz6d7dzn4K43Kl6nUaGsTwFlnzuhM1KJZMMp34LGTCY4Iu QSpUDTbkUTMVO7p/KJ/N/5TLV4ONfLjSGG2nU4AlK4JjgtoIi6OAjGbs5rfs Ua/X9vL6Ji; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > I know. It was a joke/wise-a$$ comment on the usefulness of > this thing. :) Sorry for my followup, then; the joke was lost in the translation to pixels. :-) -d > -hadriel > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Friday, February 22, 2008 12:39 PM > > To: Hadriel Kaplan; IETF SIP List > > Cc: Dan Wing > > Subject: RE: [Sip] ID updated: > draft-kaplan-sip-baiting-attack-02.txt > > > > Hadriel, > > > > You wrote: > > > (Personally I feel one might as well then only make RFC4474 > > > work for SIPS URIs with S/MIME bodies, but that's just > > > personal opinion) > > [JRE] The purpose of RFC 4474 was to provide authentication without > > requiring a certificate at the UA - S/MIME requires a certificate! > > > > John _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 22 12:11:49 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F4028CC60; Fri, 22 Feb 2008 12:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4jRjqT51VdG; Fri, 22 Feb 2008 12:11:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA093A6D29; Fri, 22 Feb 2008 12:07:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7AC528CB8C for ; Fri, 22 Feb 2008 12:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JflJ2969S5Oc for ; Fri, 22 Feb 2008 12:07:27 -0800 (PST) Received: from mailhost2.aepona.com (mailhost1.aepona.com [194.46.24.5]) by core3.amsl.com (Postfix) with ESMTP id 7F3AD28CC7C for ; Fri, 22 Feb 2008 12:04:55 -0800 (PST) Received: from exim by mailhost2.aepona.com with local (Exim 4.52) id 1JSe8Y-0005n2-EQ for sip@ietf.org; Fri, 22 Feb 2008 20:04:50 +0000 From: David.Monahan@aepona.com To: sip@ietf.org In-Reply-To: Auto-Submitted: auto-replied Message-Id: Date: Fri, 22 Feb 2008 20:04:50 +0000 Subject: [Sip] Out-of-office-reply: Sip Digest, Vol 46, Issue 30 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I will be out of the office until 3 March 2008. I will read your email on my return. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 22 16:07:00 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FBC28C0FB; Fri, 22 Feb 2008 16:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVDqL4rRhqED; Fri, 22 Feb 2008 16:07:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABAE928C309; Fri, 22 Feb 2008 16:05:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ACA33A6DF2 for ; Fri, 22 Feb 2008 16:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjIptsi2+Leu for ; Fri, 22 Feb 2008 16:05:30 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8357528C9C5 for ; Fri, 22 Feb 2008 16:02:00 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Feb 2008 19:01:56 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1N01uEv022621; Fri, 22 Feb 2008 19:01:56 -0500 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 m1N01gV6010077; Sat, 23 Feb 2008 00:01:56 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 19:01:12 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 19:01:11 -0500 Message-ID: <47BF623C.8020105@cisco.com> Date: Fri, 22 Feb 2008 19:01:00 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <47B6345B.4030807@cisco.com> <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> <200802202144.m1KLi5WJ024161@dragon.ariadne.com> In-Reply-To: <200802202144.m1KLi5WJ024161@dragon.ariadne.com> X-OriginalArrivalTime: 23 Feb 2008 00:01:11.0578 (UTC) FILETIME=[33056FA0:01C875AF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4432; t=1203724916; x=1204588916; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20New=20I-D=20-=20TOTE=20-=20=22I NFO=22=20on=20the=20media=20path |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=+vpySHKHPaqfuv+E0tItHVgmKW5dWTX5gQhJ5LBrwhE=; b=LWyQ6OadLrHXkuz2XRETEPQ65u93Y+tCPjXcgddfQAwcZqLccYdiRmQy5W gc1vCX9GGeMpldppNrTBhTv1Y1rveDdfeBwMIJ7qAKWsUekOyo0ZohtoU9tG KvUwYTnf7k; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It only gets pushed to the client if the client indicates support for it. Thus, the typical flow is: A->B : "hey, you can send me pic if you want" B->A : "ok I will" and I think this is very much like: A->B : "please send be pic" B->A : "ok I will" which is what SIP events is about. In terms of the need to understand the semantics of the data, they are identical. Now, the intended model in TOTE is that there would be two types of purpose parameters. Global ones which are standardized, and a vendor tree. The global ones require a specification, though it doesnt at the moment require standards track. But it does need an RFC. I am happy to debate standards track vs. ietf action. That said, depending on the purpose, I don't think there is that much needed in such a spec. For example, for pic, something along the lines of "this purpose is meant for picture sharing between users. For example, in cases where a user with a cell phone snaps a picture during a call and wishes to send it to the other person, or wishes to send an existing file on disk. The received picture is normally rendered, possibly with user permission, and possibly saved by the recipient. All implementations MUST support image/jpg." I'm not sure that much more is required; we could debate whether max-size needs to be dealt with, and that could be done any number of ways. The TOTE model would argue that you would do this by having a message from recipient to sender, over this TOTE connection, with the max size. Indeed, you could also have a message from sender to recipient first that indicates an interest in sending a picture right now, including picture metadata. This would imply that "pic" is really a three way handshake, two of which are some new messages we'd need to define (and presumably would be defined by the tote usage). We could alternatively send those params through SDP, but that constrains us to the O/A 2-way handshake; and as we have seen with things like SRTP, having the flexibility of building the protocol without the constraints of O/A is highly beneficial. It also means you can add new stuff without extending SIP itself. What TOTE does is it avoids the need for this particular application to define how to get connections set up through sip, how to secure them, how to do nat traversal for them, how to signal what they are used for, how to negotiate them, and so on. It also gives us the ability to share connections across applications when it makes sense; this also allows us to have very rich multi-app communications in one session without this large number of connections. And so in my mind, it lowers the bar for new applications by providing a framework for adding new ones without needing to change SIP, and to have the flexibility of engineering the application ideally for its particular needs. -Jonathan R. Dale.Worley@comcast.net wrote: > From: Dean Willis > > Ok, I think I agree with you here. Each "purpose" would need to be > very clearly specified, at roughly the same level of detail as is > required for an event package or would be required for an INFO package > if we were to go that way. > > IMHO the purposes need to be specified in *more* detail than an event > package. The reason is that an event package is "pull" information, > the meaning of the information is defined by the event-name, but the > requestor is presumed to know *why* it wants the information, that is, > what it intends to do based on that information. A TOTE object, like > an INFO, is "push" information, and the attached meta-data must > specify not only what the information means, but how the recipient is > expected to act on it. > > Dale > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 23 11:30:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF0328C502; Sat, 23 Feb 2008 11:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.045 X-Spam-Level: X-Spam-Status: No, score=-1.045 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0alCLrGR1lLe; Sat, 23 Feb 2008 11:30:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD76F28C4DB; Sat, 23 Feb 2008 11:30:51 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6DF28C412 for ; Sat, 23 Feb 2008 11:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JW0UY4YfgcT for ; Sat, 23 Feb 2008 11:30:49 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 372C328C316 for ; Sat, 23 Feb 2008 11:30:49 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2008 14:30:44 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1NJUir1015117 for ; Sat, 23 Feb 2008 14:30:44 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1NJUiJR012921 for ; Sat, 23 Feb 2008 19:30:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 14:30:44 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 14:30:43 -0500 Message-ID: <47C07458.7080503@cisco.com> Date: Sat, 23 Feb 2008 14:30:32 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List X-OriginalArrivalTime: 23 Feb 2008 19:30:43.0800 (UTC) FILETIME=[94ECC580:01C87652] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=750; t=1203795044; x=1204659044; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20I-D=20on=20ICE=20diagnostic=20error=20code |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=E6ZThmJvRvV7WTrvTAyeGuN01yUypan3s8cAoUpx7sw=; b=El5XsgACmFzQ7DBkDD0hyf+iNb00yYM63ascBgqRFmwDKrqj1rguLdUJDX o1EzF3+7DuZRt9GB4zHgsq7nLM0qSanZkT/U2+GiRcWPEbu8qmJd7dY5/GrI b6ESNvs2RN; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Sip] I-D on ICE diagnostic error code X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I just submitted: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ice-error-code-01.txt This is nearly identical to a draft I submitted before Vancouver, but we never discussed. The basic idea here is to define a new SIP response code for the case when all ICE connectivity checks fail. THe main benefit is that proxies can log this and collect statistics on successful and failed ICE cases from the SIP messaging. Comments welcome. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 23 13:00:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E557F28C40B; Sat, 23 Feb 2008 13:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUTPJzhe-dc2; Sat, 23 Feb 2008 13:00:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63103A6B6D; Sat, 23 Feb 2008 13:00:05 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4ECF83A6B13; Sat, 23 Feb 2008 13:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080223210002.4ECF83A6B13@core3.amsl.com> Date: Sat, 23 Feb 2008 13:00:02 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-sips-08.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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 : The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) Author(s) : F. Audet Filename : draft-ietf-sip-sips-08.txt Pages : 57 Date : 2008-02-23 This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. This document also provides a discussion of possible future steps in specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-08.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-sips-08.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-sips-08.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: <2008-02-23125222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sips-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sips-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-23125222.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Sat Feb 23 21:45:08 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10AD63A6B9F; Sat, 23 Feb 2008 21:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bg4-5o-fYFN; Sat, 23 Feb 2008 21:45:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23BA3A6ACA; Sat, 23 Feb 2008 21:45:03 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 90B6A3A6A07; Sat, 23 Feb 2008 21:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080224054501.90B6A3A6A07@core3.amsl.com> Date: Sat, 23 Feb 2008 21:45:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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 : IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces Author(s) : J. Polk Filename : draft-ietf-sip-rph-new-namespaces-02.txt Pages : 7 Date : 2008-02-23 This document creates additional Session Initiation Protocol Resource-Priority namespaces, and places these namespaces in the IANA register. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-rph-new-namespaces-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rph-new-namespaces-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-23213006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rph-new-namespaces-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rph-new-namespaces-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-23213006.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Sun Feb 24 08:45:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3BA28C14B; Sun, 24 Feb 2008 08:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cINOwQFtL8q4; Sun, 24 Feb 2008 08:45:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A407F3A6BDB; Sun, 24 Feb 2008 08:45:03 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A223B3A6A08; Sun, 24 Feb 2008 08:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080224164501.A223B3A6A08@core3.amsl.com> Date: Sun, 24 Feb 2008 08:45:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-media-security-requirements-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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 : Requirements and Analysis of Media Security Management Protocols Author(s) : D. Wing, et al. Filename : draft-ietf-sip-media-security-requirements-03.txt Pages : 48 Date : 2008-02-24 This document describes requirements for a protocol to negotiate a security context for SIP-signaled SRTP media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-media-security-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-media-security-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-24083936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-media-security-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-media-security-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24083936.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Sun Feb 24 08:51:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F1428C149; Sun, 24 Feb 2008 08:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXs+SKl0sMrh; Sun, 24 Feb 2008 08:51:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E4C28C1F5; Sun, 24 Feb 2008 08:51:06 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1D53A6827 for ; Sun, 24 Feb 2008 08:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25GZR8u-RfCD for ; Sun, 24 Feb 2008 08:51:03 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 77AB628C12C for ; Sun, 24 Feb 2008 08:50:47 -0800 (PST) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-1.cisco.com with ESMTP; 24 Feb 2008 08:50:42 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id m1OGogWR030645; Sun, 24 Feb 2008 08:50:42 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1OGoahn008283; Sun, 24 Feb 2008 16:50:41 GMT From: "Dan Wing" To: "'IETF SIP List'" Date: Sun, 24 Feb 2008 08:50:36 -0800 Message-ID: <0a9f01c87705$6471f1b0$31a36b80@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Ach3BWDG+fmMpf/DQ+aHnHflsKs/4g== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2261; t=1203871842; x=1204735842; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20sip-media-security-requirements-03 |Sender:=20; bh=kgUE8kOnfP/LtBXSWxDpBZdGa7rDMfLu9xdTSnGymNA=; b=SYxwVX8ApwmHD8wmBAc+wDYKCgrVoULWsE25zwWaiwyoz+lE6lYlKWpyKs N0kZhQqnGyefPOxCiNd9F0togXB3pYajeSfElxonIKBVF4W7ljXgY71iG7AQ aSt+mg8Myx; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); Cc: 'Francois Audet' , "'Fries, Steffen'" Subject: [Sip] sip-media-security-requirements-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I just submitted a version -03 of media-security-requirements, http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements -03.txt The major changes to the document include: * After the discussion on the mailing list about R-REUSE, I have returned that requirement to a MAY. * Offline, Peter Schneider sent a detailed review of draft-ietf-sip-media-security requirements. Many of his comments were resolved with new text or editorial changes, but a few of his comments resulted in new or adjusted requirements. He also had comments about R-REUSE and suggested it should not be a MUST-level requirement. * I added a new requirement, R-HERFP; there was existing discussion text around handling HERFP correctly, but this creates a specific requirement: R-HERFP: The media security key management protocol MUST function securely even in the presence of HERFP behavior. * To the discussion of the R-PSTN requirement, (which is unchanged and says "The media security key management protocol MUST support termination of media security in a PSTN gateway."), I added: It is desirable, even when one leg of a call is on the PSTN, that the IP leg of the call be protected with SRTP. This comment has some relationship with the active discussion (and I-D's) we are have with RFC4474 and E.164 numbers, so this may need revision. What I'm trying to do is ensure we have SRTP on the IP leg, even if we know (or suspect) the call is going across the PSTN. There is no need to force RTP over the IP leg of a call just because the call is going over the PSTN later. * As mentioned above, R-REUSE has been returned to a MAY (it was only a MUST in version -02 of the document): R-REUSE: The media security key management protocol MAY support the re- use of a previously established security context. Note: re-use of the security context does not imply re-use of RTP parameters (e.g., payload type or SSRC). * The R-AVOID-CLIPPING requirement now references Security Preconditions rather than simply PRACK. * Other changes can be seen by running rfcdiff, http://www.tools.ietf.org/rfcdiff -d _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 24 11:05:47 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C0628C10E; Sun, 24 Feb 2008 11:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8mLHWhRfs9H; Sun, 24 Feb 2008 11:05:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521813A6A57; Sun, 24 Feb 2008 11:05:42 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E803A6A08 for ; Sun, 24 Feb 2008 11:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMDCNeT992J1 for ; Sun, 24 Feb 2008 11:05:38 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 52E763A6935 for ; Sun, 24 Feb 2008 11:05:38 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2008 14:05:33 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1OJ5XNF007099; Sun, 24 Feb 2008 14:05:33 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1OJ5SJR006039; Sun, 24 Feb 2008 19:05:28 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 14:05:28 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 14:05:28 -0500 Message-ID: <47C1BFED.70002@cisco.com> Date: Sun, 24 Feb 2008 14:05:17 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D04D8890@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D04D8890@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 24 Feb 2008 19:05:28.0304 (UTC) FILETIME=[38082F00:01C87718] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=913; t=1203879933; x=1204743933; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Comments=20on=20hitchhikers-guide-04 |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=8pxyOyBC6gPrjs2mDrTnEfozS8hchzDc1T5x7It/O9I=; b=hLjdNcsu43M8spJcG9ZA2AeLr3XIw5X892pvGfmozGKNHsBQO5VMK0xYBl glt9CGSUv3U1aBJmrubnjS4YGs8CUmmC8svDfTkYHMMh2hh+pgrugwfXv6DS ycXzOYkRHA; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Comments on hitchhikers-guide-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Good catch, John. Fixed. -Jonathan R. Elwell, John wrote: > Jonathan, > > Thanks for taking care of most of my review comments. The following is > outstanding: > > "As such, this document formally defines a > "SIP specification" as: > > o Any specification that defines an extension to RFC 3261, where an > extension is a mechanism that changes or updates in some way a > behavior specified there." > This means RFC 3261 is not a SIP specification! Suggest: > "The basic SIP specification, RFC 3261 [RFC3261], or any specification > that defines an extension to RFC 3261..." > > John > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 24 11:20:42 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587AD3A67B2; Sun, 24 Feb 2008 11:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1EZ+RskdCfa; Sun, 24 Feb 2008 11:20:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7313A687E; Sun, 24 Feb 2008 11:20:40 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB21A3A687E; Sun, 24 Feb 2008 11:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZn1Lb+vxy5h; Sun, 24 Feb 2008 11:20:36 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9EA1B3A67B2; Sun, 24 Feb 2008 11:20:36 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Feb 2008 11:20:31 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1OJKVMc027123; Sun, 24 Feb 2008 11:20:31 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m1OJKUJB013421; Sun, 24 Feb 2008 19:20:31 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 14:20:30 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 14:20:30 -0500 Message-ID: <47C1C373.4050106@cisco.com> Date: Sun, 24 Feb 2008 14:20:19 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Avshalom Houri References: <473B7ECA.1080504@cisco.com> In-Reply-To: X-OriginalArrivalTime: 24 Feb 2008 19:20:30.0212 (UTC) FILETIME=[519C6C40:01C8771A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14144; t=1203880831; x=1204744831; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[RAI]=20Re=3A=20RAI=20review=20of=20dra ft-ietf-sip-hitchhikers-guide-03 |Sender:=20; bh=M5SLDYZDquIise8nPkLHpfEmti+pEXpbVbIXKqFniZE=; b=nw99b+yKBD36q+8yjMO4W1MJqnMPmoLgMMGgcNwN0O9NFjblUo819ZQPYz WgnSyKP0aeclxEJAKm0rC80plOVeWt0el3u1NXK/gpkc2IOf+MQ7DAkhGlli BPmWdOwczm; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, rai@ietf.org Subject: Re: [Sip] [RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Text updated to say: These extensions are general purpose enhancements to SIP, SDP and MIME that can serve a wide variety of uses. However, they are not used for every session or registration, as the core specifications are. which matches the criteria defined in the document for core. -Jonathan R. Avshalom Houri wrote: > > Jonathan, > > Agree with your all replies. > > One comment only: > > First paragraph in section 5: > > These extensions are general purpose enhancements to SIP, SDP and > MIME that can serve a wide variety of uses. However, they are not as > widely used or as essential as the core specifications. > > Maybe should be changed to put more emphasize that these RFCs are not > core specs and less on the wide deployment of them. > Current wording seems to say (at least to me) that wide deployment was > the main > criteria. > > --Avshalom > > > > > > > > *Jonathan Rosenberg * > > 15/11/2007 01:03 > > > To > Avshalom Houri/Haifa/IBM@IBMIL > cc > sip@ietf.org, rai@ietf.org > Subject > [RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03 > > > > > > > > > Thanks for the comments, Avshalom. Responses below: > > Avshalom Houri wrote: > > > > I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03 > > from the perspective of presence and the SIMPLE group but ended up in > > commenting on the whole document at the end. > > > > For background on RAI-ART, please see the FAQ at > > _http://www.softarmor.com/rai/art/rai-art-FAQ.html_ > > > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > In my opinion this draft is basically ready for publication, but has > > nits that should be fixed before publication. > > > > Citations from the draft are marked by <<< text from draft >>> > > > > General comments > > ---------------- > > > > By its nature there are a lot of reference to drafts in the document. > > It will take a lot of time for these documents to become and RFC. > > So how we are going to publish this as an RFC? Since when the > > referenced drafts will become an RFC, this draft would have to be > > updated with new drafts, will it be held in the > > RFC ED queue for ever? > > We had a whole thread on this, so I won't address this again here, but > rather focus on your other comments. > > > > > How do we gauge the usage of an RFC or a draft? There are many places > > here that it is said that this or that RFC/draft got widely implemented > > or not. > > How it is measured? The wide implementation test is used to decide > > whether an RFC or draft are core or not and therefore there should be > > some text explaining how the wide implementation was determined. > > No. Wide usage is not used to determine core or not. There is a litmus > test defined for inclusion as a core spec: > > > > 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 > > > > > this definition is based entirely on the functionality of the spec and > not judgement on its deployment. > > The comments on deployment in the document are based on my own > observation and awareness. Please feel free to suggest changes, that > part of the description can only be improved with data from additional > folks. > > > > > Better change RFC XXXX (before the reference number in []) to the name > > of the draft (with no version number), it will make the ride smoother. > > OK. Changing to symrefs helps a lot. > > > > > An introduction that details the various grouping should be added. It > > should include additional text on the group and what was the criteria > > for putting an RFC/draft in the group. > > OK, I added a list in the introduction along with brief classification > description. > > > > > 2. Scope of this Document > > -------------------------- > > > > <<< > > o Any specification that defines an extension to SIP itself, where > > an extension is a mechanism that changes or updates in some way a > > behavior specified in RFC 3261 > > >>> > > > > "to SIP itself" sounds vague. It will be better to say:"to RFC 3261" > > instead. > > Maybe there should be an earlier definition of RFC 3261 as the SIP > nucleus > > (or the president of the galaxy) and that RFCs/drafts mentioned in this > > document are based on their relation to it. > > changed this sentence to: > > Any specification that defines an extension to RFC 3261, > where an extension is a mechanism that changes or updates in > some way a behavior specified there. > > > > > > > <<< > > Excluded from this list are requirements, architectures, registry > > definitions, non-normative frameworks, and processes. Best Current > > Practices are included when they normatively define mechanisms for > > accomplishing a task. > > >>> > > > > "normatively define" not sure what is meant by normative with > > respect to BCP. Seems like a contradiction in terms. > > Actually BCPs can contain normative text and are, in many ways, very > much like a PS. > > > > > 3. Core SIP Specifications > > --------------------------- > > > > If we think on presence as eventually replacing registration, since it > > carries much more information about the availability of the user, > > should we consider also presence as a towel? > > > > <<< > > RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the > > core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9]. > > It is the president of the galaxy [42] as far as the suite of SIP > > specifications is concerned. > > >>> > > > > RFC 3261 is a very big document. Should it be treated as one or it can > > be divided into parts in this document e.g. proxy, client etc.? I am not > > sure what would be better. > > The purpose here is to just enumerate the specs and describe each. I > don't think the aim is to break it up here. > > > > > 4. Public Switched Telephone Network (PSTN) Interworking > > --------------------------------------------------------- > > > > Regarding RFC 3578 > > Ugly in one corner of the galaxy may be beautiful on the other of it :-) > > > > 7. Minor Extensions > > -------------------- > > > > <<< > > RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44] > > allows a UA sending a REFER to ask the recipient of the REFER to > > generate multiple SIP requests, not just one. This is useful for > > conferencing, where a client would like to ask a conference server > > to eject multiple users. > > >>> > > > > Should not this be referred to in the conferencing section also? > > ok > > > > > <<< > > RFC 4483, A Mechanism for Content Indirection in Session Initiation > > Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for > > content indirection. Instead of carrying an object within a SIP > > body, a URL reference is carried instead, and the recipient > > dereferences the URL to obtain the object. The specification has > > potential applicability for sending large instant messages, but > > has yet to find much actual use. > > >>> > > > > The specification has also potential for sending large presence > > documents via a URL. > > sure, but I don't think it would really be classified as a > presence-related spec. > > > > > <<< > > RFC 4583, Session Description Protocol (SDP) Format for Binary Floor > > Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a > > mechanism in SDP to signal floor control streams that use BFCP. > > It is used for Push-To-Talk and conference floor control. > > >>> > > > > Should not this be referred to in the conferencing section also? > > ok > > > > > <<< > > RFC XXXX, Connectivity Preconditions for Session Description Protocol > > Media Streams (S): RFC XXXX [93] defines a usage of the precondition > > framework [59]. The connectivity precondition makes sure that the > > session doesn't get established until actual packet connectivity > > is checked. > > >>> > > > > Should not this be referred to in the QoS section also? > > Well, the line is fine, but connectivity preconditions is not about QoS > as most folks think of it (i.e., bandwidth reservation). > > > > > 8. Conferencing > > ---------------- > > > > The Conferencing section should be before or after "Instant Messaging, > > Presence and Multimedia" as it is also an application. See the comment > > on whether presence is an application or not later. > > moved. > > > > > 10. Event Framework and Packages > > ---------------------------------- > > > > Suggest to divide this section to event framework section and to > > packages section. The event framework should include 3265, 3903, 4662 > > and subnot-etags which define the event framework itself. > > The other section will the packages sections that will list the > > packages. > > OK. > > > > > Alternatively, many of the packages are mentioned in their proper > > section so it may be that all the event packages can be fit into > > their relevant section and there is not a need for packages section. > > I think its useful to list them. > > > > > 11. Quality of Service > > ----------------------- > > > > <<< > > RFC 3313, Private SIP Extensions for Media Authorization (I): RFC > > 3313 [61] defines a P-header that provides a mechanism for passing > > an authorization token between SIP and a network QoS reservation > > protocol like RSVP. Its purpose is to make sure network QoS is > > only granted if a client has made a SIP call through the same > > providers network. This specification is sometimes referred to as > > the SIP walled garden specification by the truly paranoid androids > > in the SIP community. This is because it requires coupling of > > signaling and the underlying IP network. > > >>> > > > > Understand that being a "truly paranoid" is a virtue? :-) > > > > 15. Security Mechanisms > > ------------------------ > > > > Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474 > > (Identity) be mentioned here also? > > Hmm, well Brian had suggested that RFC 3325 has nothing to do with > 'secure caller ID' so that one is definitely debatable. > > 4474 definitely fits here. 3323 is kind of fuzzy, but I'll include. > > > > > 16. Instant Messaging, Presence and Multimedia > > ----------------------------------------------- > > > > Maybe create an applications section and put also conferencing as a type > > of an application. > > Applications is really broad. The service URI stuff could be considered > an app too. I think its valuable to have finer granularity than that. > > > > > Including presence here with IM and multimedia seems that presence is > > regarded as an additional type of media. I am not sure that I agree with > > this. Presence is an enabler for many other applications and it deserves > > a section of its own. > > Certainly its valuable, sufficiently so that simple-simple addresses it > more completely and obviously separates IM from presence. But its not > the emphasis of this document. If I split off presence there is only two > docs in there (winfo and presence package), and only one in IM (3428) so > this seems to argue for keeping them together. I did add a reference to > simple-simple in the intro to let people know there is a more complete > source of presence specs elsewhere. > > > > > It is very tempting to include the simple-simple content here > > (as an appendix?). If simple-simple is not to be included here, there > > should be at least a reference to simple-simple as for presence > > there are so many documents that are essential for doing presence and > > are not mentioned here (e.g. watcher format, RPID, presence rules, > > partial notify and publish and many many more). > > done. > > > Roughly counting, there > > are about 20-25 RFCs/drafts that are very relevant to presence that are > > mentioned in simple-simple in addition to the ones that are mentioned > here. > > right, since they are not sip extensions. > > > > > The MSRP drafts seem to be forgotten? > > Not a sip extension. RTP isn't listed here either. > > -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 > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www1.ietf.org/mailman/listinfo/rai > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 24 13:50:39 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A0828C182; Sun, 24 Feb 2008 13:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbH-t7wjASdH; Sun, 24 Feb 2008 13:50:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC803A69DC; Sun, 24 Feb 2008 13:50:37 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3889E3A69DC for ; Sun, 24 Feb 2008 13:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlAhm-6jid1z for ; Sun, 24 Feb 2008 13:50:35 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C85D73A6875 for ; Sun, 24 Feb 2008 13:50:34 -0800 (PST) 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 m1OLkGW24412 for ; Sun, 24 Feb 2008 21:46:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8772F.436B374B" Date: Sun, 24 Feb 2008 15:50:26 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF150BA1E2@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-sip-sips-08.txt Thread-Index: Ach2XynyrnHKqudjQ0mR0YH5UicV5AA0AzLQ From: "Francois Audet" To: "IETF SIP List" Subject: [Sip] FW: I-D Action:draft-ietf-sip-sips-08.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8772F.436B374B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI, Integrated all comments from WGLC. -----Original Message----- From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = Internet-Drafts@ietf.org Sent: Saturday, February 23, 2008 13:00 To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: I-D Action:draft-ietf-sip-sips-08.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 : The use of the SIPS URI Scheme in the Session = Initiation Protocol (SIP) Author(s) : F. Audet Filename : draft-ietf-sip-sips-08.txt Pages : 57 Date : 2008-02-23 This document provides clarifications and guidelines concerning the use = of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. This document also provides a = discussion of possible future steps in specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-08.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-sips-08.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-sips-08.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_001_01C8772F.436B374B Content-Type: application/octet-stream; name="ATT4275666.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT4275666.TXT Content-Disposition: attachment; filename="ATT4275666.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6IDwyMDA4LTAyLTIzMTI1MjIyLkktREBpZXRmLm9yZz4NCg0K RU5DT0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lwLXNpcHMt MDgudHh0DQo= ------_=_NextPart_001_01C8772F.436B374B Content-Type: application/octet-stream; name="draft-ietf-sip-sips-08.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-sip-sips-08.URL Content-Disposition: attachment; filename="draft-ietf-sip-sips-08.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXNpcC1zaXBzLTA4LnR4dA0K ------_=_NextPart_001_01C8772F.436B374B Content-Type: text/plain; name="ATT4275667.txt" Content-Transfer-Encoding: base64 Content-Description: ATT4275667.txt Content-Disposition: attachment; filename="ATT4275667.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0K ------_=_NextPart_001_01C8772F.436B374B Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C8772F.436B374B-- From sip-bounces@ietf.org Sun Feb 24 14:15:08 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC05728C496; Sun, 24 Feb 2008 14:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8Z5YmhTVsyi; Sun, 24 Feb 2008 14:15:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFD428C44E; Sun, 24 Feb 2008 14:15:05 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6417428C15A; Sun, 24 Feb 2008 14:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080224221501.6417428C15A@core3.amsl.com> Date: Sun, 24 Feb 2008 14:15:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Hitchhiker's Guide to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-hitchhikers-guide-05.txt Pages : 42 Date : 2008-02-24 The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-hitchhikers-guide-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-24141341.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-hitchhikers-guide-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24141341.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Sun Feb 24 14:20:24 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3AA28C2A7; Sun, 24 Feb 2008 14:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHnR0s9ygD-D; Sun, 24 Feb 2008 14:20:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E888728C420; Sun, 24 Feb 2008 14:19:04 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56F628C3E0 for ; Sun, 24 Feb 2008 14:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7Uw1Spcl804 for ; Sun, 24 Feb 2008 14:19:02 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CE7C028C420 for ; Sun, 24 Feb 2008 14:16:58 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2008 17:16:53 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1OMGrR0003225 for ; Sun, 24 Feb 2008 17:16:53 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1OMGpJR029697 for ; Sun, 24 Feb 2008 22:16:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 17:16:51 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 17:16:51 -0500 Message-ID: <47C1ECC8.50305@cisco.com> Date: Sun, 24 Feb 2008 17:16:40 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List X-OriginalArrivalTime: 24 Feb 2008 22:16:51.0095 (UTC) FILETIME=[F44F0A70:01C87732] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2577; t=1203891413; x=1204755413; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Updated=20hitchhikers=20guide |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=12eoMoDpHzIy4x9k9mCFRR1dH55rhyR9kWj6h6NJi+Y=; b=M4eilXZRHxqGLyK4/ZHSEan/Sj4QKZxYf8FQIk1OMHTNeOM3uUwzC6SeZG 4oReKHgRnsKMb+gPMRUQMeYEqppnBFdc4mAMYJH/YkkmooMMUJWexEBQAyrZ MweDcjgZ4T; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Sip] Updated hitchhikers guide X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I just submitted an update to the hitchhikers guide: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-05.txt This update reflects Keith's review after WGLC, addition of the last comments from WGLC, and addition of the normative call flows documents, which was an open issue from the previous draft. Here is a table I put together that indicates the number of references in each version of this document: Version References ind-00 85 sip-00 100 sip-01 104 sip-02 109 sip-03 112 sip-04 122 sip-05 140 Quite an increase over time. Changes from -04: * added draft-ietf-sipping-v6-transition to Minor Extensions added * RFC4497 (QSIG to SIP) in PSTN interworking. ISUP to SIP was already there. * draft-ietf-sipping-gruu-reg-event added to event packages * draft-ietf-sipping-uri-services added to URI Services section. Updated the descriptions of the URI list services specs to point to this. * draft-ietf-sipping-consent-format added to security section. It comes in as a MIME object for SIP. * added draft-ietf-mmusic-qos-identification to the QoS section * added draft-ietf-sip-location-conveyance to the emergency services section * added draft-ietf-sip-connect-reuse to minor extensions * added draft-ietf-sipping-session-policy-framework * added connected-identity (RFC4916) to security (was previously just in core). RFC4474 was in core and security, so it makes sense for 4916 to mirror that * added SIPS to security (was previously just in core) * added draft-ietf-mmusic-sdp-dtls to security * security preconditions -> RFC 5027 * acr-code -> RFC 5079 * added draft-ietf-sip-body-handling to general infrastructure specs * added draft-ietf-sip-domain-certs to security * added draft-ietf-sip-ua-privacy to security * added ipv6-abnf-fix to the list of essential corrections * added draft-ietf-sipping-pai-update as part of the description of rfc3325 * broadened slightly the scope of documents to include, so that BCPs which significantly clarify other normative specs are included. This adds: RFC3665: Basic call flow examples [core sip] RFC3666: PSTN call flows [PSTN interworking] RFC4579: CC conferencing [conferencing] -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 24 20:04:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF5128C4F2; Sun, 24 Feb 2008 20:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cy+dJL+CRTmh; Sun, 24 Feb 2008 20:04:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008E13A6B3F; Sun, 24 Feb 2008 20:04:50 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B1928C430 for ; Sun, 24 Feb 2008 20:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xV9idr50bz+P for ; Sun, 24 Feb 2008 20:04:48 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 2A3E828C20A for ; Sun, 24 Feb 2008 20:04:48 -0800 (PST) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id tQWA1Y0051GXsucA90p900; Mon, 25 Feb 2008 04:04:05 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id tg4g1Y00D0umElk8T00000; Mon, 25 Feb 2008 04:04:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=VlRPawm5cPVZARccvA0A:9 a=ix_7ccM0jfCm7JdDJnj_wmvxNpEA:4 a=JqJj0Mv_YbgA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m1P44eMj023630 for ; Sun, 24 Feb 2008 23:04:40 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m1P44eZm023626; Sun, 24 Feb 2008 23:04:40 -0500 Date: Sun, 24 Feb 2008 23:04:40 -0500 Message-Id: <200802250404.m1P44eZm023626@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <20080224054501.90B6A3A6A07@core3.amsl.com> (Internet-Drafts@ietf.org) References: <20080224054501.90B6A3A6A07@core3.amsl.com> Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Title : IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces Author(s) : J. Polk Filename : draft-ietf-sip-rph-new-namespaces-02.txt Pages : 7 Date : 2008-02-23 Abstract: This document creates additional Session Initiation Protocol Resource-Priority namespaces, and places these namespaces in the IANA register. As an editorial matter, can the abstract be made less vague? Such as mentioning that it creates a set of namespaces for the use of the US Defense Information Systems Agency... Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 24 21:57:59 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B26028C1D2; Sun, 24 Feb 2008 21:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9Re8RdAg+Ok; Sun, 24 Feb 2008 21:57:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1B93A67F4; Sun, 24 Feb 2008 21:57:58 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DB33A67F4 for ; Sun, 24 Feb 2008 21:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHm124LoLWpj for ; Sun, 24 Feb 2008 21:57:53 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 559BA3A67A2 for ; Sun, 24 Feb 2008 21:57:53 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 24 Feb 2008 21:57:48 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1P5vl8Z012309; Sun, 24 Feb 2008 21:57:47 -0800 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 m1P5v5iB004324; Mon, 25 Feb 2008 05:57:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 21:57:27 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.78.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 21:57:27 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Feb 2008 23:57:26 -0600 To: Dale.Worley@comcast.net, sip@ietf.org From: "James M. Polk" In-Reply-To: <200802250404.m1P44eZm023626@dragon.ariadne.com> References: <20080224054501.90B6A3A6A07@core3.amsl.com> <200802250404.m1P44eZm023626@dragon.ariadne.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 25 Feb 2008 05:57:27.0344 (UTC) FILETIME=[4CCBFB00:01C87773] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1207; t=1203919067; x=1204783067; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20I-D=20Action=3Adraft-ietf-sip-r ph-new-namespaces-02.txt |Sender:=20; bh=7Z5W072T90LLpQ/C65xdAKGC7Hbfagbkmq7kiwQjDgU=; b=gxpw8IobCn8G4L4VYDieFy/Xk/tziA8a2mgNUQSUPYHVEZB7N/im8538mO 6HSoEHdJHStmlWkXZfLzINGxmqQ78ICLplFh76ebLC3C5j30fVcteplNJEmS NY2T2xSJk+; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 10:04 PM 2/24/2008, Dale.Worley@comcast.net wrote: > Title : IANA Registration of New Session > Initiation Protocol (SIP) > Resource-Priority Namespaces > Author(s) : J. Polk > Filename : draft-ietf-sip-rph-new-namespaces-02.txt > Pages : 7 > Date : 2008-02-23 > > Abstract: > > This document creates additional Session Initiation Protocol > Resource-Priority namespaces, and places these namespaces in the > IANA register. > >As an editorial matter, can the abstract be made less vague? Such as >mentioning that it creates a set of namespaces for the use of the US >Defense Information Systems Agency... well, at least I didn't overstate things... ;-) I can change this if you want me to >Dale >_______________________________________________ >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 24 22:30:10 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F0E28C568; Sun, 24 Feb 2008 22:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s835173V88tV; Sun, 24 Feb 2008 22:30:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E14E28C52F; Sun, 24 Feb 2008 22:30:07 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C110428C20A; Sun, 24 Feb 2008 22:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225063001.C110428C20A@core3.amsl.com> Date: Sun, 24 Feb 2008 22:30:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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 : Framework for Establishing an SRTP Security Context using DTLS Author(s) : J. Fischl, et al. Filename : draft-ietf-sip-dtls-srtp-framework-01.txt Pages : 29 Date : 2008-02-24 This document specifies how to use the Session Initiation Protocol (SIP) to establish an Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. It relies on the SIP identity mechanism to ensure the integrity of the fingerprint attribute. The key exchange travels along the media path as opposed to the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-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-dtls-srtp-framework-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-dtls-srtp-framework-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: <2008-02-24222709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-dtls-srtp-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-dtls-srtp-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24222709.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Sun Feb 24 22:30:11 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E2D28C571; Sun, 24 Feb 2008 22:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyCX6aK4hAPs; Sun, 24 Feb 2008 22:30:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D962428C535; Sun, 24 Feb 2008 22:30:07 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C5F0D28C233; Sun, 24 Feb 2008 22:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225063001.C5F0D28C233@core3.amsl.com> Date: Sun, 24 Feb 2008 22:30:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-xcapevent-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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 : An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package Author(s) : J. Urpalainen Filename : draft-ietf-sip-xcapevent-01.txt Pages : 14 Date : 2008-02-24 This document describes an "xcap-diff" SIP event package, with the aid of which clients can receive notifications of the partial changes of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization and document updates are based on using the XCAP-Diff format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-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-xcapevent-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-xcapevent-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: <2008-02-24222810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-xcapevent-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-xcapevent-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24222810.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Sun Feb 24 23:36:22 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1440A28C2A7; Sun, 24 Feb 2008 23:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZfePhFoddMd; Sun, 24 Feb 2008 23:36:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1804328C1B8; Sun, 24 Feb 2008 23:36:20 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A7128C1EC for ; Sun, 24 Feb 2008 23:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msK0Ljo6L0ZU for ; Sun, 24 Feb 2008 23:36:13 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C0ECF28C1B8 for ; Sun, 24 Feb 2008 23:36:13 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Feb 2008 23:36:01 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1P7a19Y000382; Sun, 24 Feb 2008 23:36:01 -0800 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 m1P7Z5iH028405; Mon, 25 Feb 2008 07:35:56 GMT 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.1830); Sun, 24 Feb 2008 23:35:44 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.78.249]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 23:35:44 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Feb 2008 01:35:43 -0600 To: Adam Roach From: "James M. Polk" In-Reply-To: <4752BED8.7050404@nostrum.com> References: <474C84F0.7000309@nostrum.com> <4752BED8.7050404@nostrum.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 25 Feb 2008 07:35:44.0103 (UTC) FILETIME=[0789FF70:01C87781] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1339; t=1203924961; x=1204788961; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20NITS=3A=20draft-ietf-sip-location-conve yance-09.txt |Sender:=20; bh=uqKXyhTTkwdvOgJKoCOfg46v94UC4wH29H+WZIahT+8=; b=ELmOcVTsuCrIRl5HoOvl7e+RuWnC3pv7DP7BLt/KAQ34vD+b1HwOcF61F8 R/8sU5ZXTu6RLM5CTxL8hlAr7FEVyGpNz2NeVNlt04XqwhwwNlKpK2B+DEF5 T1bL8S4RvQ; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] NITS: draft-ietf-sip-location-conveyance-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 08:19 AM 12/2/2007, Adam Roach wrote: >James M. Polk wrote: >> >>>[T]his document appears to have removed a couple of important >>>header field parameters from the IANA section. Section 5.2 explains: >>> >>> There are 3 Geolocation header parameters, >>> >>> o "inserted-by=" >>> o "used-for-routing" >> >>the two above were taken out, as they do not have parameter-values >>(which I thought one night was the barrier to be included on this >>list). I can add them in easily. > >I've become more confused just now. The headers on the table in the >IANA section of this document don't appear to match any of the >tables in the sip-parameters registry >. If you could point >to the table in question, I could probably find you a specific >example of parameters being registered without predefined parameter >values in the specific table in question. (The specific registry >that I think you're aiming for is "Header Field Parameters and >Parameter Values", which has a column to indicate whether the >parameter has predefined values -- and most of them don't). for the record, -10 of this ID will mimic what's at the location you suggest above The ID will be submitted in 1-2 hours. I'll send a note to the SIP list about it. >/a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 24 23:43:47 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B3528C12D; Sun, 24 Feb 2008 23:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZXxM9TjkL00; Sun, 24 Feb 2008 23:43:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1473A6B58; Sun, 24 Feb 2008 23:43:45 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FA73A68F9 for ; Sun, 24 Feb 2008 23:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPhUveiHrxTL for ; Sun, 24 Feb 2008 23:43:41 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7EED93A67F4 for ; Sun, 24 Feb 2008 23:43:41 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1E9512147A; Mon, 25 Feb 2008 08:43:35 +0100 (CET) X-AuditID: c1b4fb3e-aa1febb000000b15-29-47c271a7157f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 013BB21339; Mon, 25 Feb 2008 08:43:35 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 08:43:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 08:43:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D on ICE diagnostic error code thread-index: Ach2Uz/5UIFbNdyvRJe6IROahBGsPAA3+W52 References: <47C07458.7080503@cisco.com> From: "Christer Holmberg" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 25 Feb 2008 07:43:34.0569 (UTC) FILETIME=[1FF56990:01C87782] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] I-D on ICE diagnostic error code X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1098415592==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1098415592== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87782.1F9BDA92" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87782.1F9BDA92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, =20 The response code is ICE specific. But, couldn't it be useful at least also for RFC4145, if one fails to establish a TCP connection? =20 So, instead of "Connectivity Checks Failed" the text would be more generic and say "Connectivity Failure", or something like that... =20 Regards, =20 Christer =20 ________________________________ From: sip-bounces@ietf.org on behalf of Jonathan Rosenberg Sent: Sat 23/02/2008 20:30 To: IETF SIP List Subject: [Sip] I-D on ICE diagnostic error code I just submitted: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ice-error-code-0 1.txt This is nearly identical to a draft I submitted before Vancouver, but we never discussed. The basic idea here is to define a new SIP response code for the case when all ICE connectivity checks fail. THe main benefit is that proxies can log this and collect statistics on successful and failed ICE cases from the SIP messaging. Comments welcome. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com =20 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C87782.1F9BDA92 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Sip] I-D on ICE diagnostic error = code
    Hi = Jonathan,
     
    The response code is ICE = specific. But,=20 couldn't it be useful at least also for RFC4145, if one fails to = establish a TCP=20 connection?
     
    So, instead of "Connectivity = Checks Failed"=20 the text would be more generic and say "Connectivity Failure", or = something like=20 that...
     
    Regards,
     
    Christer
     

    From: sip-bounces@ietf.org on behalf = of Jonathan=20 Rosenberg
    Sent: Sat 23/02/2008 20:30
    To: IETF SIP=20 List
    Subject: [Sip] I-D on ICE diagnostic error=20 code

    I just submitted:
    http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ice= -error-code-01.txt

    This=20 is nearly identical to a draft I submitted before Vancouver, but = we
    never=20 discussed. The basic idea here is to define a new SIP response
    code = for the=20 case when all ICE connectivity checks fail. THe main
    benefit is that = proxies=20 can log this and collect statistics on
    successful and failed ICE = cases from=20 the SIP messaging.

    Comments welcome.

    -Jonathan=20 R.
    --
    Jonathan D. Rosenberg,=20 Ph.D.           &n= bsp;      =20 499 Thornall St.
    Cisco=20 Fellow           &= nbsp;           &n= bsp;          =20 Edison, NJ 08837
    Cisco, Voice Technology = Group
    jdrosen@cisco.com
    http://www.jdrosen.net  &n= bsp;           &nb= sp;         =20 PHONE: (408) 902-3084
    http://www.cisco.com
    ______________= _________________________________
    Sip=20 mailing list  http://www.ietf.org/mai= lman/listinfo/sip
    This=20 list is for NEW development of the core SIP Protocol
    Use=20 sip-implementors@cs.columbia.edu for questions on current sip
    Use=20 sipping@ietf.org for new developments on the application of=20 sip

    ------_=_NextPart_001_01C87782.1F9BDA92-- --===============1098415592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1098415592==-- From sip-bounces@ietf.org Mon Feb 25 02:56:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF07A28C1CA; Mon, 25 Feb 2008 02:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKmw++Gzjz9t; Mon, 25 Feb 2008 02:56:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D242B3A6C0B; Mon, 25 Feb 2008 02:56:33 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963BA3A6BE9 for ; Mon, 25 Feb 2008 02:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzrSYo8DD02C for ; Mon, 25 Feb 2008 02:56:31 -0800 (PST) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 83E1A3A685D for ; Mon, 25 Feb 2008 02:56:31 -0800 (PST) Received: from rly11b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly11b.srv.mailcontrol.com (MailControl) with ESMTP id m1PAtqHB013895 for ; Mon, 25 Feb 2008 10:56:23 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly11b.srv.mailcontrol.com (MailControl) id m1PAtaod012674 for sip@ietf.org; Mon, 25 Feb 2008 10:55:36 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly11b-eth0.srv.mailcontrol.com (envelope-sender cboulton@avaya.com) (MIMEDefang) with ESMTP id m1PAtTes012136; Mon, 25 Feb 2008 10:55:36 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6619.12 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 10:51:50 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D - TOTE - "INFO" on the media path Thread-Index: Achz70OBX+stLb6OTUmvxIECQEdZxgDrLc3w References: <47B6345B.4030807@cisco.com><8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> From: "Chris Boulton" To: "Dean Willis" , "Ted Hardie" X-Scanned-By: MailControl A-08-00-04 (www.mailcontrol.com) on 10.66.1.121 Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 20, 2008, at 12:28 AM, Ted Hardie wrote: > > . If the idea is that the specification of > "pic" or "name" is at the level of the specification of an event > package, > then we are dealing with something else entirely and the draft can > be re-written to express that. But I would expect, in that case, > for each > of the registered purposes to be very carefully specified as to what > the > acting application would do with them. And I suspect pretty much > everything like "name" would have to go. Ok, I think I agree with you here. Each "purpose" would need to be very clearly specified, at roughly the same level of detail as is required for an event package or would be required for an INFO package if we were to go that way. And yes, the draft is a bit short on this right now. [Chris Boulton] BUT then we are just recreating the Control Framework (http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-sip-control-fr amework-01.txt) from the MediaCtrl work group - just called a different name. I'm not sure why we can't just use that. Chris. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 06:56:19 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D8228C458; Mon, 25 Feb 2008 06:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chaoGgKqoeEM; Mon, 25 Feb 2008 06:56:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C20B3A6C9D; Mon, 25 Feb 2008 06:56:18 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3DE3A694B for ; Mon, 25 Feb 2008 06:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wVFPPLu9c-P for ; Mon, 25 Feb 2008 06:56:15 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E835B3A6B07 for ; Mon, 25 Feb 2008 06:56:14 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 25 Feb 2008 09:55:53 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 25 Feb 2008 09:55:53 -0500 From: Hadriel Kaplan To: Jonathan Rosenberg , IETF SIP List Date: Mon, 25 Feb 2008 09:55:53 -0500 Thread-Topic: [Sip] New I-D - TOTE - "INFO" on the media path Thread-Index: AchwNq9itf+NfMzmRjewszRp4tRyrQHhwOKQ Message-ID: References: <47B6345B.4030807@cisco.com> In-Reply-To: <47B6345B.4030807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sweet draft. I would actually define the session-based IM usage for this first. It would fix a lot of the NAT traversal issues we can't currently get around with MSRP. (the basic lesson being: don't put IP Addresses/ports in application layer messages when you don't need to) -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Friday, February 15, 2008 7:55 PM > To: IETF SIP List > Subject: [Sip] New I-D - TOTE - "INFO" on the media path > > I just submitted a new I-D, which proposes a protocol called TOTE: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt > > Basically, TOTE provides the ability to exchange MIME objects of any > type and "purpose" over a tcp/tls connection established e2e through SDP > O/A procedures and ICE-tcp. This ties into the INFO disussion; it > provides the media-plane equivalent of the INFO-events framework. > > This draft should arguably go in mmusic but since the INFO debate is > happening here I submitted it as a -sip. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 07:08:12 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776533A6D1B; Mon, 25 Feb 2008 07:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGviNByp-ozk; Mon, 25 Feb 2008 07:08:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762973A6CBF; Mon, 25 Feb 2008 07:08:11 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C293A6CFC for ; Mon, 25 Feb 2008 07:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL3G3LNrzhB5 for ; Mon, 25 Feb 2008 07:08:09 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8BAD23A6CF6 for ; Mon, 25 Feb 2008 07:08:08 -0800 (PST) Received: (qmail invoked by alias); 25 Feb 2008 15:08:02 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp020) with SMTP; 25 Feb 2008 16:08:02 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19IzwJsWWFI16QViXLV0ReU7EDX+R+KDuORkAzZQV OIh9hdifetXJp6 Message-ID: <47C2D9CD.6020306@gmx.net> Date: Mon, 25 Feb 2008 17:07:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <47B6345B.4030807@cisco.com> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel, would you box block it since it travels along the media path? Hadriel Kaplan wrote: > Sweet draft. > > I would actually define the session-based IM usage for this first. It would fix a lot of the NAT traversal issues we can't currently get around with MSRP. (the basic lesson being: don't put IP Addresses/ports in application layer messages when you don't need to) > > -hadriel > > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Jonathan Rosenberg >> Sent: Friday, February 15, 2008 7:55 PM >> To: IETF SIP List >> Subject: [Sip] New I-D - TOTE - "INFO" on the media path >> >> I just submitted a new I-D, which proposes a protocol called TOTE: >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt >> >> Basically, TOTE provides the ability to exchange MIME objects of any >> type and "purpose" over a tcp/tls connection established e2e through SDP >> O/A procedures and ICE-tcp. This ties into the INFO disussion; it >> provides the media-plane equivalent of the INFO-events framework. >> >> This draft should arguably go in mmusic but since the INFO debate is >> happening here I submitted it as a -sip. >> >> Thanks, >> Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >> Cisco Fellow Edison, NJ 08837 >> Cisco, Voice Technology Group >> jdrosen@cisco.com >> http://www.jdrosen.net PHONE: (408) 902-3084 >> http://www.cisco.com >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 07:13:44 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B409928C44D; Mon, 25 Feb 2008 07:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HoHQb2Bn37m; Mon, 25 Feb 2008 07:13:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4BE28C341; Mon, 25 Feb 2008 07:13:35 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8ADB28C211 for ; Mon, 25 Feb 2008 07:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya1WIx2NP6tx for ; Mon, 25 Feb 2008 07:13:32 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 88BDD28C24C for ; Mon, 25 Feb 2008 07:12:09 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 25 Feb 2008 10:11:48 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 25 Feb 2008 10:11:49 -0500 From: Hadriel Kaplan To: Chris Boulton , Dean Willis , Ted Hardie Date: Mon, 25 Feb 2008 10:11:48 -0500 Thread-Topic: [Sip] New I-D - TOTE - "INFO" on the media path Thread-Index: Achz70OBX+stLb6OTUmvxIECQEdZxgDrLc3wAAkHf6A= Message-ID: References: <47B6345B.4030807@cisco.com><8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, looking at draft-ietf-mediactrl-sip-control-framework-01.txt for the first time, I would say one reason is that the TOTE mechanism has a better chance of success in more environments. At least across SBCs, if that matters to you. (it matters to me, obviously, but not everyone) Also, TOTE is a lot lighter weight, although I'm sure after a few rounds of drafts with lots of people's inputs it will probably grow to be not far off. :) -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Chris Boulton > Sent: Monday, February 25, 2008 5:52 AM > To: Dean Willis; Ted Hardie > Cc: IETF SIP List > Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path > > On Feb 20, 2008, at 12:28 AM, Ted Hardie wrote: > > > > . If the idea is that the specification of > > "pic" or "name" is at the level of the specification of an event > > package, > > then we are dealing with something else entirely and the draft can > > be re-written to express that. But I would expect, in that case, > > for each > > of the registered purposes to be very carefully specified as to what > > the > > acting application would do with them. And I suspect pretty much > > everything like "name" would have to go. > > Ok, I think I agree with you here. Each "purpose" would need to be > very clearly specified, at roughly the same level of detail as is > required for an event package or would be required for an INFO package > if we were to go that way. And yes, the draft is a bit short on this > right now. > > [Chris Boulton] BUT then we are just recreating the Control Framework > (http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-sip-control-fr > amework-01.txt) from the MediaCtrl work group - just called a different > name. I'm not sure why we can't just use that. > > Chris. > > > -- > Dean > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 07:41:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B0428C1CF; Mon, 25 Feb 2008 07:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyJP4sdU6HkG; Mon, 25 Feb 2008 07:41:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441E43A6D3D; Mon, 25 Feb 2008 07:36:08 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5A83A6C11 for ; Mon, 25 Feb 2008 07:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isU2RbhqZwiU for ; Mon, 25 Feb 2008 07:36:02 -0800 (PST) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 93CD73A6D2C for ; Mon, 25 Feb 2008 07:32:36 -0800 (PST) Received: from rly11b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly11b.srv.mailcontrol.com (MailControl) with ESMTP id m1PFWKOW017278 for ; Mon, 25 Feb 2008 15:32:29 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly11b.srv.mailcontrol.com (MailControl) id m1PFWJ1x017129 for sip@ietf.org; Mon, 25 Feb 2008 15:32:19 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly11b-eth0.srv.mailcontrol.com (envelope-sender cboulton@avaya.com) (MIMEDefang) with ESMTP id m1PFW5Mq015188; Mon, 25 Feb 2008 15:32:19 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6619.12 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 15:32:03 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D - TOTE - "INFO" on the media path Thread-Index: Achz70OBX+stLb6OTUmvxIECQEdZxgDrLc3wAAkHf6AAAHcHoA== References: <47B6345B.4030807@cisco.com><8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> From: "Chris Boulton" To: "Hadriel Kaplan" , "Dean Willis" , "Ted Hardie" X-Scanned-By: MailControl A-08-00-04 (www.mailcontrol.com) on 10.66.1.121 Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, looking at draft-ietf-mediactrl-sip-control-framework-01.txt for the first time, I would say one reason is that the TOTE mechanism has a better chance of success in more environments. At least across SBCs, if that matters to you. (it matters to me, obviously, but not everyone) [Chris Boulton] Which is exactly why the Control Framework needs valuable input from RAI experts for the next revision (which is already planned). This is certainly an area that 'we'(mediactrl) have flagged to look at for the next version of the Framework. I certainly wouldn't want to see yet another 'parallel fork' (that one is for Dean) in IETF technology - especially as the Control Framework is the rarest of beasts in the IETF in that it ACTUALLY has several 'running code' implementations. Also, TOTE is a lot lighter weight, although I'm sure after a few rounds of drafts with lots of people's inputs it will probably grow to be not far off. :) [Chris Boulton] hehehe - that made me smile. Next you will be telling me that SIP is a light weight protocol :-). -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Chris Boulton > Sent: Monday, February 25, 2008 5:52 AM > To: Dean Willis; Ted Hardie > Cc: IETF SIP List > Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path > > On Feb 20, 2008, at 12:28 AM, Ted Hardie wrote: > > > > . If the idea is that the specification of > > "pic" or "name" is at the level of the specification of an event > > package, > > then we are dealing with something else entirely and the draft can > > be re-written to express that. But I would expect, in that case, > > for each > > of the registered purposes to be very carefully specified as to what > > the > > acting application would do with them. And I suspect pretty much > > everything like "name" would have to go. > > Ok, I think I agree with you here. Each "purpose" would need to be > very clearly specified, at roughly the same level of detail as is > required for an event package or would be required for an INFO package > if we were to go that way. And yes, the draft is a bit short on this > right now. > > [Chris Boulton] BUT then we are just recreating the Control Framework > (http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-sip-control-fr > amework-01.txt) from the MediaCtrl work group - just called a different > name. I'm not sure why we can't just use that. > > Chris. > > > -- > Dean > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 08:12:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF883A6DEE; Mon, 25 Feb 2008 08:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtoEsJXJmV63; Mon, 25 Feb 2008 08:12:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3D328C4D5; Mon, 25 Feb 2008 08:07:12 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5303A6CD1 for ; Mon, 25 Feb 2008 08:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq0x0PwDLtps for ; Mon, 25 Feb 2008 08:07:09 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 97BCE28C636 for ; Mon, 25 Feb 2008 08:05:49 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2008 11:05:43 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1PG5f91014637; Mon, 25 Feb 2008 11:05:41 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1PAKgV0007390; Mon, 25 Feb 2008 10:20:47 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:05:40 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:05:40 -0500 Message-ID: <47C2E749.2090000@cisco.com> Date: Mon, 25 Feb 2008 11:05:29 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Chris Boulton References: <47B6345B.4030807@cisco.com><8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> In-Reply-To: X-OriginalArrivalTime: 25 Feb 2008 16:05:40.0110 (UTC) FILETIME=[442E2AE0:01C877C8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4357; t=1203955541; x=1204819541; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20New=20I-D=20-=20TOTE=20-=20=22I NFO=22=20on=20the=20media=20path |Sender:=20 |To:=20Chris=20Boulton=20; bh=AFcjEvOYPciW3SoUjrZQYV4YPF9mDmzx7pDDK5+hWgc=; b=QH7/unksuf0alJ1Zx2e7gqFBXU+aCeW4ZSU9bdwccljgXvTOxxvV28EiEP WSox8V1372S7S66uVeRbCY7JNZb1GqAe9H+pSvSj2ka2CVWIAKi0kvauysW7 18FFUpOHa/; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: IETF SIP List , Dean Willis Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Chris, Thanks for pointing this out - I hadn't looked at the mediactrl-framework before and there is definitely overlap and a relationship between it and TOTE. Here is my analysis on the similarities and differences: Both of them are about establishing connections between agents through an O/A exchange. Mediactrl uses comedia, whereas TOTE uses ICE-tcp. ICE-tcp will fall back to comedia when both sides are unnatted. TOTE, however, provides a layer of demux within the SDP signaling, allowing for negotiation of what runs over the channel as part of the O/A negotiation. In mediactrl, this is done within the control channel itself, by doing a supported kind of exchange over the mediactrl protocol. TOTE and media-ctrl framework both define a simple message protocol that runs over the connection. This is lighter weight in TOTE; its just for framing and purpose demux. mediactrl defines specific messages - control, report, synch, etc., transactions, response codes. Mediactrl solves the problem of binding a connection to a dialog by defining a SYNC message. TOTE solves this problem by using ICE, which provides this correlation as part of its normal operations. Mediactrl solves the problem of keepalives using its own keepalive message; TOTE uses the ICE keepalive mechanism. Since TOTE is a bit lower-layer than mediactrl, one model is to think of running mediactrl over TOTE. Mediactrl would then be a specific "purpose" parameter. When you do this, a bunch of features would get removed from mediactrl - all of the SDP stuff, connection establishment, synch mechanism. Mediactrl would continue to define the notion of control packages, control package negotiation, REPORT, CONTROl, response codes, transaction rules, etc. I think thats a good story - instead of each and every protocol (like mediactrl) needing to worry about this lower-layer connection management and connectivity stuff, we solve it once, and provide a framework for reusing connections across different protocols and applications. So that one tcp connection between me and my media server could be used for mediactrl messages, streaming commands, picture transmission, etc. -Jonathan R. Chris Boulton wrote: > On Feb 20, 2008, at 12:28 AM, Ted Hardie wrote: >> . If the idea is that the specification of >> "pic" or "name" is at the level of the specification of an event >> package, >> then we are dealing with something else entirely and the draft can >> be re-written to express that. But I would expect, in that case, >> for each >> of the registered purposes to be very carefully specified as to what >> the >> acting application would do with them. And I suspect pretty much >> everything like "name" would have to go. > > Ok, I think I agree with you here. Each "purpose" would need to be > very clearly specified, at roughly the same level of detail as is > required for an event package or would be required for an INFO package > if we were to go that way. And yes, the draft is a bit short on this > right now. > > [Chris Boulton] BUT then we are just recreating the Control Framework > (http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-sip-control-fr > amework-01.txt) from the MediaCtrl work group - just called a different > name. I'm not sure why we can't just use that. > > Chris. > > > -- > Dean > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 08:12:17 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E53D3A6E16; Mon, 25 Feb 2008 08:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gdNTl+FJ7Nk; Mon, 25 Feb 2008 08:12:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4DD3A6D74; Mon, 25 Feb 2008 08:08:13 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8164B3A6D6F for ; Mon, 25 Feb 2008 08:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQj+GBL2waFS for ; Mon, 25 Feb 2008 08:08:07 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 53F1028C37C for ; Mon, 25 Feb 2008 08:06:44 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 25 Feb 2008 11:06:23 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 25 Feb 2008 11:06:23 -0500 From: Hadriel Kaplan To: "Hannes.Tschofenig@gmx.net" Date: Mon, 25 Feb 2008 11:06:21 -0500 Thread-Topic: [Sip] New I-D - TOTE - "INFO" on the media path Thread-Index: Ach3wC+X+qFVAXMjQySjspna80Vs6AAAJnCw Message-ID: References: <47B6345B.4030807@cisco.com> <47C2D9CD.6020306@gmx.net> In-Reply-To: <47C2D9CD.6020306@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Nope. As I tried to explain a bit in the To/from uri changes draft, it's not that SBCs want to block such things, it's up to the owner of the SBC to decide whether to allow it or not. -hadriel > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, February 25, 2008 10:08 AM > To: Hadriel Kaplan > Cc: Jonathan Rosenberg; IETF SIP List > Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path > > Hadriel, > > would you box block it since it travels along the media path? > > > Hadriel Kaplan wrote: > > Sweet draft. > > > > I would actually define the session-based IM usage for this first. It > would fix a lot of the NAT traversal issues we can't currently get around > with MSRP. (the basic lesson being: don't put IP Addresses/ports in > application layer messages when you don't need to) > > > > -hadriel > > > > > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > >> Jonathan Rosenberg > >> Sent: Friday, February 15, 2008 7:55 PM > >> To: IETF SIP List > >> Subject: [Sip] New I-D - TOTE - "INFO" on the media path > >> > >> I just submitted a new I-D, which proposes a protocol called TOTE: > >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt > >> > >> Basically, TOTE provides the ability to exchange MIME objects of any > >> type and "purpose" over a tcp/tls connection established e2e through > SDP > >> O/A procedures and ICE-tcp. This ties into the INFO disussion; it > >> provides the media-plane equivalent of the INFO-events framework. > >> > >> This draft should arguably go in mmusic but since the INFO debate is > >> happening here I submitted it as a -sip. > >> > >> Thanks, > >> Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > >> Cisco Fellow Edison, NJ 08837 > >> Cisco, Voice Technology Group > >> jdrosen@cisco.com > >> http://www.jdrosen.net PHONE: (408) 902-3084 > >> http://www.cisco.com > >> _______________________________________________ > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 08:21:06 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC8428C6C1; Mon, 25 Feb 2008 08:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOK4eCAEvXDU; Mon, 25 Feb 2008 08:21:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D557E3A6D20; Mon, 25 Feb 2008 08:16:33 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9A128C24C for ; Mon, 25 Feb 2008 08:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0nJHEyPvu2h for ; Mon, 25 Feb 2008 08:16:31 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2C49F3A6BC0 for ; Mon, 25 Feb 2008 08:16:03 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2008 11:15:57 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1PGFuUM029812; Mon, 25 Feb 2008 11:15:56 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1PEG4Jd003762; Mon, 25 Feb 2008 14:16:10 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:14:37 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:14:37 -0500 Message-ID: <47C2E962.40606@cisco.com> Date: Mon, 25 Feb 2008 11:14:26 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan References: <47B6345B.4030807@cisco.com> In-Reply-To: X-OriginalArrivalTime: 25 Feb 2008 16:14:37.0213 (UTC) FILETIME=[845194D0:01C877C9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1820; t=1203956157; x=1204820157; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20New=20I-D=20-=20TOTE=20-=20=22I NFO=22=20on=20the=20media=20path |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=YmSoAv7xf1bwfSLsioyx3FlULg+uRAS6fnWmJnji+0I=; b=fAFe0ieryK/0uzEO3K3vHocz33xsMB1s5U2N2QNHFiyiAPMoDOPMCgmAXW cDvWEqDGA9tKPEuPe8LEc/1EdRSosNjzJaApdZE+4SEXBunjKH8E0xFiKItr GUFHE1O3Wt; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > Sweet draft. Thanks! > > I would actually define the session-based IM usage for this first. > It would fix a lot of the NAT traversal issues we can't currently get > around with MSRP. (the basic lesson being: don't put IP > Addresses/ports in application layer messages when you don't need to) I thought about that a bunch; I had planned a separate draft on how MSRP is different than session-mode IM over TOTE. The million dollar question is, what MSRP features would be lost and would we still need them. I've convinced myself that the key architectural difference - the use of turn for relays rather than an IM-specific relay, causes a very different inter-server connection model and has a huge impact on the functionality required in the protocol. That said, I do think TOTE has a really good overall nat/sbc story. Its usage of ice-tcp will allow it to work reasonably well (with some amount of relaying...) with existing fw/nat. Whether it would work through existing SBCs depends a lot on what they do; whether they have the ability to pass unknown m-lines or not. However, more importantly, once an SBC does support TOTE, it would only need to support it once, and then from then on, all tote-based applications would work through the resulting connection (of course I have no doubt that SBCs would want to do per-purpose blocking/allowing but this becomes an issue of configuration and NOT software update; that is what I want to avoid). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 09:36:56 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2243A6DCC; Mon, 25 Feb 2008 09:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1bQdI6FhKGz; Mon, 25 Feb 2008 09:36:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2A63A6E1E; Mon, 25 Feb 2008 09:34:51 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED463A6E18 for ; Mon, 25 Feb 2008 09:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtdaMzDtfkXB for ; Mon, 25 Feb 2008 09:34:49 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D5CE43A6D32 for ; Mon, 25 Feb 2008 09:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1203960815; x=1235496815; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=Mime-Version:=201.0|Message-Id:=20|In-Reply-To:=20<47BF623C.8020105@cisco. com>|References:=20<47B6345B.4030807@cisco.com>=0D=0A=20< p06240601c3e0e71e3fef@[129.46.226.27]>=0D=0A=20<8F90CB13- F83A-4D95-82E4-63794937E8A9@softarmor.com>=0D=0A=20=0D=0A=20=0D=0A=20<20080220214 4.m1KLi5WJ024161@dragon.ariadne.com>=0D=0A=20<47BF623C.80 20105@cisco.com>|Date:=20Mon,=2025=20Feb=202008=2009:33:3 3=20-0800|To:=20Jonathan=20Rosenberg=20,=0D=0A=20=20=20=20=20=20=20=20"Dale.Worley@comcast.net" =20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Sip]=20New=20I-D=20- =20TOTE=20-=20"INFO"=20on=20the=20media=20path|Cc:=20"sip @ietf.org"=20|Content-Type:=20text/plain=3B =20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi =3D"5200,2160,5237"=3B=20a=3D"796277"; bh=uNuu7wmP7B67AQIMEHKkhxBpONr37cGtwzZAOlHS8Sc=; b=uUoe9iyGMiha9hQ2wzhhP53j64F48Lr34/x1vDSyEajywr1xntWgAwTo bmuC0e4llDZESRcspUByDKFF/OfXtQKPl838LthM2qYKgbNGhwg3xiakw Neb06si5oJd/lRYgDatdAr00H8XwGheLV49sU4WKAzSKoILl4hkIjeJb0 c=; X-IronPort-AV: E=McAfee;i="5200,2160,5237"; a="796277" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2008 09:33:34 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1PHXZ17005720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Feb 2008 09:33:35 -0800 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1PHXYhf004406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2008 09:33:34 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <47BF623C.8020105@cisco.com> References: <47B6345B.4030807@cisco.com> <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> <200802202144.m1KLi5WJ024161@dragon.ariadne.com> <47BF623C.8020105@cisco.com> Date: Mon, 25 Feb 2008 09:33:33 -0800 To: Jonathan Rosenberg , "Dale.Worley@comcast.net" From: Ted Hardie Cc: "sip@ietf.org" Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, Did you see my messages in this thread? I raised several issues with the approach you appear to be outlining again here, and I'm wondering if you saw them. To recapitulate just slightly: The negotiation model appears inadequate to deal with MIME types with significant parameters, with multipart MIME types, or with MIME types that have "bucket" semantics (like message/cpim, the container video types, or the 3ggp bucket mime types). Having a dispatch based on purpose without detailed specifications or reference to specific applications seems to hit a middle ground that's kind of nobody's sweet spot. A specific application already has detailed semantics that go beyond this purpose to actual decisions of whether to render or store, user permissions needed, sizes accepted, etc; generalized MIME transfer protocols like SMTP or HTTP already use a different system for deciding which applications to invoke when faced with a MIME object, and this forces systems with that logic to have a parallel track. The muxing seems liable to head of line blocking unless BEEP-like channels are introduced. This seems to re-purpose the deployed TURN servers in ways that transform them into a generic NAT/Firewall avoidance mechanism for any MIME type. You're listing that as a feature. Isn't there a risk that security folks will see it as a bug? regards, Ted At 4:01 PM -0800 2/22/08, Jonathan Rosenberg wrote: >It only gets pushed to the client if the client indicates support for >it. Thus, the typical flow is: > >A->B : "hey, you can send me pic if you want" >B->A : "ok I will" > >and I think this is very much like: > >A->B : "please send be pic" >B->A : "ok I will" > >which is what SIP events is about. In terms of the need to understand >the semantics of the data, they are identical. >Now, the intended model in TOTE is that there would be two types of >purpose parameters. Global ones which are standardized, and a vendor >tree. The global ones require a specification, though it doesnt at the >moment require standards track. But it does need an RFC. I am happy to >debate standards track vs. ietf action. > >That said, depending on the purpose, I don't think there is that much >needed in such a spec. For example, for pic, something along the lines >of "this purpose is meant for picture sharing between users. For >example, in cases where a user with a cell phone snaps a picture during >a call and wishes to send it to the other person, or wishes to send an >existing file on disk. The received picture is normally rendered, >possibly with user permission, and possibly saved by the recipient. All >implementations MUST support image/jpg." >I'm not sure that much more is required; we could debate whether >max-size needs to be dealt with, and that could be done any number of >ways. The TOTE model would argue that you would do this by having a >message from recipient to sender, over this TOTE connection, with the >max size. Indeed, you could also have a message from sender to recipient >first that indicates an interest in sending a picture right now, >including picture metadata. This would imply that "pic" is really a >three way handshake, two of which are some new messages we'd need to >define (and presumably would be defined by the tote usage). We could >alternatively send those params through SDP, but that constrains us to >the O/A 2-way handshake; and as we have seen with things like SRTP, >having the flexibility of building the protocol without the constraints >of O/A is highly beneficial. It also means you can add new stuff without >extending SIP itself. > >What TOTE does is it avoids the need for this particular application to >define how to get connections set up through sip, how to secure them, >how to do nat traversal for them, how to signal what they are used for, >how to negotiate them, and so on. It also gives us the ability to share >connections across applications when it makes sense; this also allows us >to have very rich multi-app communications in one session without this >large number of connections. > >And so in my mind, it lowers the bar for new applications by providing a >framework for adding new ones without needing to change SIP, and to have >the flexibility of engineering the application ideally for its >particular needs. > >-Jonathan R. > >Dale.Worley@comcast.net wrote: >> From: Dean Willis >> >> Ok, I think I agree with you here. Each "purpose" would need to be >> very clearly specified, at roughly the same level of detail as is >> required for an event package or would be required for an INFO package >> if we were to go that way. >> >> IMHO the purposes need to be specified in *more* detail than an event >> package. The reason is that an event package is "pull" information, >> the meaning of the information is defined by the event-name, but the >> requestor is presumed to know *why* it wants the information, that is, >> what it intends to do based on that information. A TOTE object, like >> an INFO, is "push" information, and the attached meta-data must >> specify not only what the information means, but how the recipient is >> expected to act on it. >> >> Dale >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > >-- >Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >Cisco Fellow Edison, NJ 08837 >Cisco, Voice Technology Group >jdrosen@cisco.com >http://www.jdrosen.net PHONE: (408) 902-3084 >http://www.cisco.com >_______________________________________________ >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 10:42:06 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402AD28C336; Mon, 25 Feb 2008 10:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nbm5ueBBvWk1; Mon, 25 Feb 2008 10:42:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C812A28C24F; Mon, 25 Feb 2008 10:39:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753463A6D14 for ; Mon, 25 Feb 2008 10:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmPTP0q3G0nJ for ; Mon, 25 Feb 2008 10:39:30 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CEABE28C743 for ; Mon, 25 Feb 2008 10:37:11 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2008 13:37:05 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1PIb5ss014119; Mon, 25 Feb 2008 13:37:05 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1PIacVA007255; Mon, 25 Feb 2008 18:37:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 13:37:02 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 13:37:02 -0500 Message-ID: <47C30AC3.4090407@cisco.com> Date: Mon, 25 Feb 2008 13:36:51 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Hardie References: <47B6345B.4030807@cisco.com> <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> <200802202144.m1KLi5WJ024161@dragon.ariadne.com> <47BF623C.8020105@cisco.com> In-Reply-To: X-OriginalArrivalTime: 25 Feb 2008 18:37:02.0615 (UTC) FILETIME=[69C67270:01C877DD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3573; t=1203964626; x=1204828626; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20New=20I-D=20-=20TOTE=20-=20=22I NFO=22=20on=20the=20media=20path |Sender:=20 |To:=20Ted=20Hardie=20; bh=BbVoUYuX/MKrLcj7wtqcWECho+7ujO3yqJVyiLFoXj0=; b=lDj7nYTENd6dRicPiw9hszt8cy3C1W2BLX9scP0FfvvisrCPzutF4etkM3 pdU05J1v2x+tlyu1foBUJ864352BW86XCkqgbuyyg6ZKBGQEHZJNKnihzp3z bQWSXc0120; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "sip@ietf.org" Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ted, I did see your note. Dean had responded, and your response to him, I thought, indicated that you were satisfied that having purposes specified (which was the intent of the draft) addressed your concerns. Sorry for having misunderstood. Some responses below: Ted Hardie wrote: > Jonathan, > Did you see my messages in this thread? I raised several > issues with the approach you appear to be outlining again here, and I'm > wondering if you saw them. To recapitulate just slightly: > > The negotiation model appears inadequate to deal with MIME types > with significant parameters, with multipart MIME types, or with > MIME types that have "bucket" semantics (like message/cpim, the > container video types, or the 3ggp bucket mime types). OK; this was just a -00. There are two ways to deal with that: 1. add the additional negotiation needed for this as new SDP parameters, or 2. don't bother at all with MIME negotiation as part of SDP for TOTE; rather, each purpose would have a protocol to doing the negotiations needed to make its functionality work. This avoids needing to do a general purpose MIME thing. FOr example, in the case of "pic", we'd actually define a little protocol that negotiates pictures sizes and supported types. In that applications, buckets and multiparts aren't an issue. I'm inclined towards #2 actually. But note that, I put into TOTE exactly the same level of MIME negotiation that SIP itself provides. SO if it is grossly inadequate here, so it is there. > > Having a dispatch based on purpose without detailed specifications or > reference to specific applications seems to hit a middle ground that's > kind of nobody's sweet spot. That was never the intent. The IANA considerations section states that these require specification. > A specific application already has detailed > semantics that go beyond this purpose to actual decisions of whether > to render or store, user permissions needed, sizes accepted, etc; > generalized MIME transfer protocols like SMTP or HTTP already > use a different system for deciding which applications to invoke > when faced with a MIME object, and this forces systems with that > logic to have a parallel track. That would seem to argue for pulling the MIME aspects out of TOTE. > > The muxing seems liable to head of line blocking unless BEEP-like > channels are introduced. This is discussed; if the purpose requires significant content, set it up as a separate session/tcp connection. > > This seems to re-purpose the deployed TURN servers in ways that > transform them into a generic NAT/Firewall avoidance mechanism > for any MIME type. You're listing that as a feature. Isn't there > a risk that security folks will see it as a bug? I think you are getting wrapped up in the MIME parts of this, which is not the main point. The main point is that there are lots of cases where we need UA to UA communications - see: http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-use-cases-00.txt I was trying to provide a common mechanism for addressing those cases where we don't want to send all this garbage over SIP - we want it over the media plane. Are you objecting to that? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 11:28:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224CD28CB2B; Mon, 25 Feb 2008 11:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXQTDhF99WGI; Mon, 25 Feb 2008 11:28:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C25028CB4E; Mon, 25 Feb 2008 11:20:57 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27ECA28CB4C; Mon, 25 Feb 2008 11:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7o2EmP7ikM9; Mon, 25 Feb 2008 11:20:55 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 483153A6DE1; Mon, 25 Feb 2008 11:12:13 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 1E7D65081A; Mon, 25 Feb 2008 11:13:58 -0800 (PST) Date: Mon, 25 Feb 2008 11:13:57 -0800 From: Eric Rescorla To: sip@ietf.org, avt@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080225191358.1E7D65081A@romeo.rtfm.com> Subject: [Sip] New DTLS-SRTP Drafts Submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We just submitted revised versions of the DTLS-SRTP documents: - draft-ietf-sip-dtls-srtp-framework - draft-ietf-avt-dtls-srtp These include the following revisions: - Harmonized our requirements evaluation with the current requirements doc. - Added a requirement to generate a pilot STUN transaction to address the SBC latching issue - Clarified the anonymity issue as discussed in YVR - Required that the SDP offerer do actpass to deal with symmetry breaking issues - Merged the material from draft-fischl-mmusic-* into these drafts Note that draft-fischl-mmusic-sdp-dtls is redundant and has been incorporated entirely into the other two drafts. - Added a section on interactions with ICE - Removed the use of the connection line from SDP - A bunch of cleanups suggested by Flemming Andreasen -Ekr _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 12:08:15 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF00D28CDDB; Mon, 25 Feb 2008 12:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjqWJCmUzc1I; Mon, 25 Feb 2008 12:08:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79BA228C949; Mon, 25 Feb 2008 11:45:32 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9886D28C89D; Mon, 25 Feb 2008 11:45:04 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225194505.9886D28C89D@core3.amsl.com> Date: Mon, 25 Feb 2008 11:45:04 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-subnot-etags-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org 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 : An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author(s) : A. Niemi Filename : draft-ietf-sip-subnot-etags-02.txt Pages : 24 Date : 2008-02-25 The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-subnot-etags-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-subnot-etags-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-subnot-etags-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25113948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-subnot-etags-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-subnot-etags-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25113948.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Feb 25 13:46:06 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF223A6EBB; Mon, 25 Feb 2008 13:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=-0.957, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgQUiYHkvF28; Mon, 25 Feb 2008 13:46:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E103A6F81; Mon, 25 Feb 2008 13:14:50 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55B73A6D02 for ; Mon, 25 Feb 2008 13:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKOsLEcglDPT for ; Mon, 25 Feb 2008 13:14:47 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C128A28C94B for ; Mon, 25 Feb 2008 13:06:53 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1PL7WXd028692; Mon, 25 Feb 2008 15:08:21 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 23:06:41 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 23:06:40 +0200 Received: from [10.162.253.189] (essapo-nirac253189.europe.nokia.com [10.162.253.189]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1PL6cYs014042; Mon, 25 Feb 2008 23:06:39 +0200 From: Aki Niemi To: ext Avshalom Houri In-Reply-To: References: Organization: Nokia Devices R&D Date: Mon, 25 Feb 2008 23:06:38 +0200 Message-Id: <1203973598.6192.46.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 25 Feb 2008 21:06:40.0705 (UTC) FILETIME=[51224310:01C877F2] X-Nokia-AV: Clean Cc: sip@ietf.org, draft-ietf-sip-subnot-etags@tools.ietf.org Subject: Re: [Sip] Review of draft-ietf-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On ma, 2007-10-08 at 17:02 +0200, ext Avshalom Houri wrote: > > Several comments: > > ------------- > A possible security issue with the following scenario: > a) Subscriber subscribes with Suppress-Body-If-Match header with > etag of e1. > b) The document has changed but what was changed is suppressed from > that subscriber due to privacy. > c) The subscriber will get notify with new tag but with the same > document. > > If the subscriber wants to it can compare to the previous value and > understand that something is being suppressed from it. I think this is an implementation issue. But really, the notifier shouldn't be generating a new entity-tag, if the entity hasn't changed. I think the model already talks about this. A resource can have several *different* representations, each of which also has its own private pool of entity-tags. > ------------- > Section 5.2 - second paragraph > "the first notification after the SUBSCRIBE" sounds as the first new > notification due to state change after the SUBSCRIBE. Maybe it is > better > to write "the immediate notification following the SUBSCRIBE". > Note that there are other occurrences of the usage of "first" if you > decide to change. This is fixed in -02. Now, the condition applies to all subsequent notifications. > ------------- > Section 5.2 - Last paragraph before the examples > typo - "simply copies" should be "simply copied" No I really meant copies. I guess this could be said differently, but I like my way better. ;) > ------------- > Section 5.2 - last example > > Maybe there should be some explanation of why * is needed earlier > in the document. Liveliness use case is described below but maybe > better to explain earlier in the doc The wildcard is better motivated now, I think. > ------------- > Figure 4 > ... poll interval elapses > > Should probably be "... poll interval elapses immediately" > Since it is zero initially. No, it's not zero; the expires is zero because it's a "fetch". The poll interval is the time between successive fetches. That can be anything the subscriber wants. > Section 5.6 > Should not this be the first use case described? From bandwidth pov > it is the most important. Well, these are not in priority order. > ------------- > Section 6.1 > > " > ...The notifier MUST remember the entity-tag of an entity as long > as the version of the entity is current. The notifier MAY > remember > the entity-tag longer than this, e.g., for implementing journaled > state differentials (Section 6.4). > " > > I understood from the text that the etag can be deleted by the > notifier > when there is no current value to the entity. Consider the case when > a subscriber subscribed and got entity e1. Meanwhile the resource has > become > stale (all previous publishes expired). This would cause the entity to change, no? > After e.g. two days the subscriber tries to subscribe with e1 for > the suppressing condition. What will the notifier selecting e1 as the > current entity tag again? If it does so the subscriber will not get > a notify (or body of notify) while it should have gotten one. > I hope that this is only my misunderstanding. It should get a new NOTIFY that reports the latest state. > ------------- > Comment from Ofira Tal (IBM) > > Should we consider the change of the entity tag as a reason to > send a notify with the entity tag only even though there is no > need to send an actual notify to the subscriber since the change > affects filtered information due to privacy or just filtering. > This will enable avoiding redundant NOTIFY in subsequent > subscribes since the latest entity tag will be used. The model tries to take privacy filtering into account with the concept of representations. In effect, each possible variation of the resource state due to privacy filters being applied and whatnot, is a unique representation that has it's own entity-tag pool. Notifications are only generated for this representation, when actual reportable changes trickle through the filters. At this point, a new entity-tag would be generated as well. If the model isn't clear on this, I'm open to suggestions. Thanks for the review! Cheers, Aki > --Avshalom > > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 13:55:14 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B773328D16A; Mon, 25 Feb 2008 13:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOEchhVJKfOQ; Mon, 25 Feb 2008 13:55:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7963A6E24; Mon, 25 Feb 2008 13:16:35 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DAA3A6E21 for ; Mon, 25 Feb 2008 13:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Ekq2-8uCou for ; Mon, 25 Feb 2008 13:16:33 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7095F3A6E6D for ; Mon, 25 Feb 2008 13:10:25 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1PLAAHS030568; Mon, 25 Feb 2008 23:10:16 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 23:09:01 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 23:09:01 +0200 Received: from [10.162.253.189] (essapo-nirac253189.europe.nokia.com [10.162.253.189]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1PL8sCR012314; Mon, 25 Feb 2008 23:08:59 +0200 From: Aki Niemi To: "ext Asveren, Tolga" In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E71882E7@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E71882E7@sonusmail04.sonusnet.com> Organization: Nokia Devices R&D Date: Mon, 25 Feb 2008 23:08:53 +0200 Message-Id: <1203973733.6192.49.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 25 Feb 2008 21:09:01.0308 (UTC) FILETIME=[A4F093C0:01C877F2] X-Nokia-AV: Clean Cc: sip@ietf.org Subject: Re: [Sip] Review of draft-ietf-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On ti, 2007-10-02 at 10:53 -0400, ext Asveren, Tolga wrote: > Draft: draft-ietf-sip-subnot-etags-01 > Reviewer: Tolga Asveren [tasveren@sonusnet.com] > Review Date: 2 October 2007 > Review Deadline: > Status: post-WGLC > > Summary: This draft is on the right track for publication and requires a > few additions/clarifications before publication > > Detailed Comments: > > * 1.2 Terminology , definition of representation > The definition of "representation" does not provide a definition. There > are just some statements about "representation". I am not sure whether > such a definition is necessary either. I would suggest deleting > "representation" from this section. Done. > * 3. Overview of Operations, remembering entity-tags for all versions > Why is it necessary for the notifier to remember all versions of an > entity? To check entity-tags in SUBSCRIBEs to determine whether an > update has happened, it just needs to know the entity-tag for the last > version. Yes, but if the same entity-tag was given to a subscriber in the past, how would the notifier know which one the subscriber is using? > To generate unique entity-tags, it can just use a counter with > some extra information to deal with restart situations, e.g. some > information extracted from current time. Right, generating unique entity-tags doesn't require much more than this. The extra information can be a timestamp and the resource URI for instance. That would already fulfill the uniqueness property. > * 5.2 Generating SUBSCRIBE requests, presence of multiple conditional > headers > I assume simultaneous presence of both "Suppress-Body-If-Match" and > "Suppress-Notify-If-Match" is allowed. This could be useful for > polling/resuming a previous subscription scenarios, where the subscriber > isn't sure about the capabilities of the notifier. Mentioning about this > possibility could be useful IMHO: > "It should be noted that subscribers MAY include both > Suppress-Body-If-Match and Suppress-Notify-If-Match conditional header > fields together in a SUBSCRIBE request. This type of usage could be > utilized for the cases where the subscriber is not sure about the > suppressing capabilities of the notifier." > I guess, we would also need to define what a notifier should do upon > receipt of both headers: > "If a notifier receives both Suppress-Notify-If-Match and > Suppress-Body-If-Match headers, it SHOULD suppress the notification if > the condition evaluates to true if it has this capability. Otherwise it > SHOULD suppress the body of the notification if it has this capability. > If the notifier can't do either of these, it simply SHOULD ignore these > headers." You're correct. The new draft version does exactly this but in another way, i.e., there is now only one header field that does all that the previous two did separately. > * 5.4 Polling or Fetching Resource State, meta-information query > What is a real life use case for meta-information query? What value > would learning current entity-tag value provide from subscriber > perspective? This was probably a little too sci-fi. I've removed the text. > * 6.1 Generating Entity-tags > "For example, one possible method is to implement the entity-tag as a > simple counter, incrementing it by one for each generated notification > per resource" > I have a few questions regarding this sentence: > i- Multiple notifications to different subscribers could be generated > for the same state. I don't think all these should cause a new e-tag > value. AFAICS, the rule for a new entity-tag is as follows: > "If a notification is generated for the current state and if the state > changes, a new entity-tag MUST be assigned". I believe the draft says exactly this. Can you point to specific text that needs fixing? > ii- What about notifier restarts? It may be helpful to indicate about > some differentiator between cycles, e.g. some information based on > current time. I guess the crucial point is to make sure that the same > entity-tag is not reused for two different versions because that may > suppress necessary state notifications. A timestamp is a good idea in any case, given the uniqueness requirement for an etag. I'm reluctant to specifying any fixed (normative or otherwise) specification of the entity-tag, but to leave it as an implementation detail. Implementors don't need help here, and are likely to come up with a better one that suits them better anyway. > It is still tolerable if the > notifier -for whatever reason- uses two different entity-tags for the > same version at two distinct times. Maybe a sentence could be added > about this : "Subscribers MUST not assume that a notifier will always > use the same entity-tag for a specific version. Especially after > notifier restarts, this MAY not be the case." The way this needs to work for the subscriber is that a new NOTIFY always resets the entity. I added a sentence on this based on Brian's comments. Still, if you think this needs to be more explicit, I'm open to suggestions. > * Forking > RFC3265 4.4.9 has the following: > " If such behavior is not allowed, the first potential > dialog-establishing message will create a dialog. All subsequent NOTIFY > messages which correspond to the SUBSCRIBE message (i.e., match "To", > "From", "From" header "tag" parameter, "Call-ID", "CSeq", "Event", and > "Event" header "id" parameter) but which do not match the dialog would > be rejected with a 481 response. Note that the 200-class response to > the SUBSCRIBE can arrive after a matching NOTIFY has been received; such > responses might not correlate to the same dialog established by the > NOTIFY. Except as required to complete the SUBSCRIBE transaction, such > non-matching 200-class responses are ignored. " > It could make sense to amend this behavior. Consider the case, where the > SUBSCRIBE forks and the first 200/NOTIFY arrives from a notifier which > does not support suppressing and after a short while subscriber receives > the NOTIFY from another notifier with an entity-tag. It could be > preferable for the subscriber to terminate the first dialog and continue > the second one. Possible in theory, but in reality, how likely is it that this will be a problem? I just find it an incredibly bad idea to build a system that behaves this way. > * Implicit Subscriptions, REFER > I think this mechanism is applicable for implicit subscriptions as well. > It could be an idea to mention this somewhere (maybe in 2.3. > Requirements) > To say a sentence or two about REFER initiated subscriptions could be > useful as well. I guess it doesn't make much sense to use suppressing > capability in this case: "Although technically it is possible to use > notification/body suppressing capability for REFER initiated > subscriptions, this is not seen as desirable considering the REFER use > case." Hmm... Good point. AFAICS, this should work as-is with REFER subscriptions as well. I added this to section 4: The conditional notification mechanism is independent of the way in which subscriptions are installed. In other words, the mechanism supports implicit subscriptions, such as those associated with the REFER method. > > Nits: > * 3. Overview of Operation, middle of the second paragraph > ", and attaches includes it in a SIP-ETag" > Just use either "attaches" or "includes" Fixed. Thanks for the review! Cheers, Aki _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 14:31:39 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CC628CF97; Mon, 25 Feb 2008 14:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn-0ukD5Kwk4; Mon, 25 Feb 2008 14:31:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99B728C5F6; Mon, 25 Feb 2008 13:59:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C07928C5B6 for ; Mon, 25 Feb 2008 13:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF9hLj3bLbzv for ; Mon, 25 Feb 2008 13:59:30 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D7F1E28C75B for ; Mon, 25 Feb 2008 13:53:31 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1PLrLRx032391; Mon, 25 Feb 2008 23:53:22 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 23:53:14 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 23:53:14 +0200 Received: from [10.162.253.189] (essapo-nirac253189.europe.nokia.com [10.162.253.189]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1PLrCVS018062; Mon, 25 Feb 2008 23:53:12 +0200 From: Aki Niemi To: "ext worley@dworley.hsd1.ma.comcast.net" In-Reply-To: <200709181506.l8IF6Bmp007748@dragon.ariadne.com> References: <5D1A7985295922448D5550C94DE2918001636AF1@DEEXC1U01.de.lucent.com> <200709181506.l8IF6Bmp007748@dragon.ariadne.com> Organization: Nokia Devices R&D Date: Mon, 25 Feb 2008 23:53:12 +0200 Message-Id: <1203976392.6192.88.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 25 Feb 2008 21:53:14.0417 (UTC) FILETIME=[D250E210:01C877F8] X-Nokia-AV: Clean Cc: sip@ietf.org Subject: Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On ti, 2007-09-18 at 11:06 -0400, ext worley@dworley.hsd1.ma.comcast.net wrote: > I have one technical issue (which is probably insoluble and can only > be documented) and a number of nits. > > * Section 4 specifies that a resource is identified by one or more > URIs. It seems to be implicit that one URI always identifies the same > resource. Without that, it would be difficult to use ETags > effectively, since ETags are only unique for a single resource. Yes. > In the general case, the mapping from URIs to resources involves the > full complexity of SIP routing. This means that without additional > information, the subscriber does not know that request-URI that it > uses always maps into the same resource URI, and so has no absolute > guarantee that the space of ETags it is working with does not change > over time. The subscriber really need not know. It is the notifier's responsibility to keep the entity-tags unique across all of the insanely difficult SIP routing that it may deploy in front of it. > One assumes that all SUBSCRIBEs within a subscription are routed to > the same destination URI because the refresh SUBSCRIBEs are sent using > the route-set and contact. But a "resumed" subscription does not have > this protection. Correct. > It is not clear that there is any solution to these problems, and we > may only be able to document that the subscriber is responsible for > assuring that successive subscription requests are delivered to the > same resource. This isn't the subscriber's problem. Moreover, I really doubt that it is even feasible to build a system where a new subscription sent to the same AoR will randomly reach a different notifier instance that is in no way synchronized (as in state, entity-tag values, etc) with the other instances. > * Section 3 contains the line: > > notification, and attaches includes it in a SIP-ETag header field of > > The words "attaches includes" seem to be incorrect. Perhaps only > "includes" was intended? Fixed in -02. > * In section 3, it is emphasized that ETags are only unique "for a > resource and event package". Checking RFC 3265, "event-package" > explicitly excludes any parameters attached to the event package name > in the "Event" header. Section 4 defines the entity to include the Event header field, which includes all of the parameters. > * Section 3 and other sections contain examples of SUBSCRIBE requests > which receive a 202 response. It may be worth mentioning that 200 > responses are also possible (if the notifier can determine without > delay that the request is authorized). Fixed in -02. It now says 202 (or 200). > * Section 5.2 contains the statement: > > Unlike the condition introduced for the SIP PUBLISH [1] method, these > conditions do not apply to the SUBSCRIBE request itself, but to the > resulting NOTIFY request. > > This is not strictly true, as success of the Suppress-Notify-If-Match > condition causes the SUBSCRIBE to receive a 204 response. Yes it is. A PUBLISH request will succeed (with a 2xx) or fail (412) based on the condition; whereas a SUBSCRIBE will always succeed (with a 2xx) regardless of whether the "suppress" condition is true or not. This is because the condition only affects the NOTIFYs that follow. > * Section 5.3 states: > > When a subscriber receives a NOTIFY request that contains a SIP-ETag > header field, it MUST store the entity-tag. > > This seems to be an awkward description. The subscriber only needs to > store the entity-tag if it wishes to avail itself of the subnot-etags > mechanism later. I think it would be clearer to say something like: > > In order for a subscriber to use this mechanism, when it receives a > NOTIFY request that contains a SIP-ETag header field, it must store > the entity-tag for later use. Fixed in -02. > * Section 5.7 shows a subscription being terminated: > > Subscriber Notifier > ---------- -------- > > (1) SUBSCRIBE --------> > Suppress-Notify-If-Match: ega23 > Expires: 0 > > But it seems to me that most subscribers will only terminate a > subscription when they are no longer interested in the state of the > resource, and so it would be more straightforward to use "*" to ensure > that they do not receive a NOTIFY that they are not interested in: > > (1) SUBSCRIBE --------> > Suppress-Notify-If-Match: * > Expires: 0 Yes, this is also an option. > * In sections 7.2 and 7.3, "it's" is used where "its" should be used. > (That is one of the irregularities of English -- "it's" is reserved as > the contraction of "it is".) > > This header field is allowed to appear in any request, but [its] > behavior is only defined for the SUBSCRIBE request. Fixed in -02. Thanks for the review! Cheers, Aki > Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 15:09:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07AD928D845; Mon, 25 Feb 2008 15:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLpULIBglwRh; Mon, 25 Feb 2008 15:09:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D1228D443; Mon, 25 Feb 2008 14:15:12 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D028B28D303; Mon, 25 Feb 2008 14:15:01 -0800 (PST) Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225221501.D028B28D303@core3.amsl.com> Date: Mon, 25 Feb 2008 14:15:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-10.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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 : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-10.txt Pages : 44 Date : 2008-2-25 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where proxy servers make routing decisions based on the location of the SIP user agents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-location-conveyance-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 16:48:44 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3923128C97F; Mon, 25 Feb 2008 16:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1y-pm3vegum; Mon, 25 Feb 2008 16:48:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D9D3A6DFF; Mon, 25 Feb 2008 15:15:04 -0800 (PST) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 078743A6DF4; Mon, 25 Feb 2008 15:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225231502.078743A6DF4@core3.amsl.com> Date: Mon, 25 Feb 2008 15:15:02 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-outbound-12.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-12.txt Pages : 50 Date : 2008-02-25 The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its Registrar. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-outbound-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-outbound-12.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: <2008-02-25150816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25150816.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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Feb 25 16:48:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8227C28CB9F; Mon, 25 Feb 2008 16:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqjd6-tp2Txt; Mon, 25 Feb 2008 16:48:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E3C28CFC7; Mon, 25 Feb 2008 15:19:04 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B2728CFC3 for ; Mon, 25 Feb 2008 15:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjfeScAJ42-U for ; Mon, 25 Feb 2008 15:19:02 -0800 (PST) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 9F2CE3A6D58 for ; Mon, 25 Feb 2008 15:12:07 -0800 (PST) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id trDy1Y01D1HpZEsA60FC00; Mon, 25 Feb 2008 23:11:35 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id tzBz1Y00S0umElk8a00000; Mon, 25 Feb 2008 23:12:01 +0000 X-Authority-Analysis: v=1.0 c=1 a=YR97AyKs833mcfULtLcA:9 a=59he5cdgjcZn3-JWFyEq9q8awEMA:4 a=JfD0Fch1gWkA:10 a=si9q_4b84H0A:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m1PNBxMj007880 for ; Mon, 25 Feb 2008 18:11:59 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m1PNBxuu007876; Mon, 25 Feb 2008 18:11:59 -0500 Date: Mon, 25 Feb 2008 18:11:59 -0500 Message-Id: <200802252311.m1PNBxuu007876@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (jmpolk@cisco.com) References: <20080224054501.90B6A3A6A07@core3.amsl.com> <200802250404.m1P44eZm023626@dragon.ariadne.com> Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "James M. Polk" At 10:04 PM 2/24/2008, Dale.Worley@comcast.net wrote: > Title : IANA Registration of New Session > Initiation Protocol (SIP) > Resource-Priority Namespaces > Author(s) : J. Polk > Filename : draft-ietf-sip-rph-new-namespaces-02.txt > Pages : 7 > Date : 2008-02-23 > > Abstract: > > This document creates additional Session Initiation Protocol > Resource-Priority namespaces, and places these namespaces in the > IANA register. > >As an editorial matter, can the abstract be made less vague? Such as >mentioning that it creates a set of namespaces for the use of the US >Defense Information Systems Agency... well, at least I didn't overstate things... ;-) I can change this if you want me to I've been sick and perhaps my message was a little short. But when I read the abstract, I realized that if I didn't already know what the I-D was about, the abstract really wouldn't tell me. It would be even clearer to say something like "This document creates 40 additional SIP ... for the use of DISA." But that might sound snarky, as people have wondered what so many namespaces are needed for. Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 18:10:54 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC76728C9B9; Mon, 25 Feb 2008 18:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-1.448, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uASMPjHeKlxw; Mon, 25 Feb 2008 18:10:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F4783A6B89; Mon, 25 Feb 2008 17:53:05 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32633A6B50 for ; Mon, 25 Feb 2008 17:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY-7967vqBpF for ; Mon, 25 Feb 2008 17:53:03 -0800 (PST) Received: from mtagate2.de.ibm.com (mtagate2.de.ibm.com [195.212.29.151]) by core3.amsl.com (Postfix) with ESMTP id 3815128C153 for ; Mon, 25 Feb 2008 17:48:22 -0800 (PST) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id m1Q1mEGZ034180 for ; Tue, 26 Feb 2008 01:48:14 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1Q1mEaV2220148 for ; Tue, 26 Feb 2008 02:48:14 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1Q1mETK030405 for ; Tue, 26 Feb 2008 01:48:14 GMT Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1Q1mDGZ030402; Tue, 26 Feb 2008 01:48:13 GMT In-Reply-To: <20080225063001.C5F0D28C233@core3.amsl.com> References: <20080225063001.C5F0D28C233@core3.amsl.com> To: sip List , jari.urpalainen@nokia.com MIME-Version: 1.0 X-KeepSent: 23EF5900:A16A2106-C22573FB:000973B3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0NP August 02, 2007 From: Avshalom Houri Message-ID: Date: Tue, 26 Feb 2008 03:48:13 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0|August 02, 2007) at 26/02/2008 03:48:13, Serialize complete at 26/02/2008 03:48:13 Subject: Re: [Sip] I-D Action:draft-ietf-sip-xcapevent-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1698906625==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1698906625== Content-Type: multipart/alternative; boundary="=_alternative 0009E4B0C22573FB_=" This is a multipart message in MIME format. --=_alternative 0009E4B0C22573FB_= Content-Type: text/plain; charset="US-ASCII" Few questions/clarifications: Should there be a "content-disposition: recipient-list" header included in the SUBSCRIBE? When a SUBSCRIBE is refreshed, should the body sent again? Is there a way to change the subscription if different body will be sent in subsequent SUBSCRIBE? Thanks --Avshalom Internet-Drafts@ietf.org Sent by: sip-bounces@ietf.org 25/02/2008 08:40 To i-d-announce@ietf.org cc sip@ietf.org Subject [Sip] I-D Action:draft-ietf-sip-xcapevent-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package Author(s) : J. Urpalainen Filename : draft-ietf-sip-xcapevent-01.txt Pages : 14 Date : 2008-02-24 This document describes an "xcap-diff" SIP event package, with the aid of which clients can receive notifications of the partial changes of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization and document updates are based on using the XCAP-Diff format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-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-xcapevent-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-xcapevent-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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-01.txt _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 0009E4B0C22573FB_= Content-Type: text/html; charset="US-ASCII"
    Few questions/clarifications:

    Should there be a "content-disposition: recipient-list" header
    included in the SUBSCRIBE?

    When a SUBSCRIBE is refreshed, should the body sent again?

    Is there a way to change the subscription if different body will be sent
    in subsequent SUBSCRIBE?

    Thanks
    --Avshalom


    Internet-Drafts@ietf.org
    Sent by: sip-bounces@ietf.org

    25/02/2008 08:40

    To
    		i-d-announce@ietf.org
    cc
    		sip@ietf.org
    Subject
    		[Sip] I-D Action:draft-ietf-sip-xcapevent-01.txt





    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Session Initiation Protocol Working Group of the IETF.


                    Title           : An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package
                    Author(s)       : J. Urpalainen
                    Filename        : draft-ietf-sip-xcapevent-01.txt
                    Pages           : 14
                    Date            : 2008-02-24

    This document describes an "xcap-diff" SIP event package, with the
    aid of which clients can receive notifications of the partial changes
    of Extensible Markup Language (XML) Configuration Access Protocol
    (XCAP) resources.  The initial synchronization and document updates
    are based on using the XCAP-Diff format.

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-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-xcapevent-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-xcapevent-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.
    ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-01.txt_______________________________________________
    Sip mailing list      http://www.ietf.org/mailman/listinfo/sip
    This list is for NEW development of the core SIP Protocol
    Use sip-implementors@cs.columbia.edu for questions on current sip
    Use sipping@ietf.org for new developments on the application of sip
    --=_alternative 0009E4B0C22573FB_=-- --===============1698906625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1698906625==-- From sip-bounces@ietf.org Mon Feb 25 18:27:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F042B28C683; Mon, 25 Feb 2008 18:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmkuPXtrQFDx; Mon, 25 Feb 2008 18:27:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332CA28C681; Mon, 25 Feb 2008 18:20:52 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBEA28C47F for ; Mon, 25 Feb 2008 18:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CE6q-zy45lC for ; Mon, 25 Feb 2008 18:20:49 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 532893A6E8E for ; Mon, 25 Feb 2008 18:17:00 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Feb 2008 18:16:54 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1Q2GsTf019264; Mon, 25 Feb 2008 18:16:54 -0800 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 m1Q2Gohp010333; Tue, 26 Feb 2008 02:16:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 18:16:50 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 18:16:49 -0800 Message-ID: <47C37686.8000602@cisco.com> Date: Mon, 25 Feb 2008 21:16:38 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> In-Reply-To: X-OriginalArrivalTime: 26 Feb 2008 02:16:49.0884 (UTC) FILETIME=[A511A1C0:01C8781D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1709; t=1203992214; x=1204856214; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20New=20I-D=20on=20why=20From/To- URIs=20are=20changed=20at=20provider=20borders |Sender:=20; bh=+uhQ4MUteFdq7bEN9E0UbkoxBIclvbEwMAzaY9If5Z8=; b=EPiAm5OJShJfH3Xuts1LcDNXAwI+vKQaXC56+Su8zbW9C8EvJP5raarRF7 uYM/mLbvnuID+ZkxvnDX6IdpgpsVjGDyvudVTA4Ralrk78CD+gC32UZx0TlS wtBkDYJ2YY; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New I-D on why From/To-URIs are changed at provider borders X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for putting this together. I'll add another to your list. This is more of an enterprise thing, but oftentimes the From URI is changed because the caller identity needs to be set to the attendant number before going to another domain. For example, if anyone within example.com makes a call, and that call remains within example.com, the caller ID is unchanged. But if the request exits the domain, the display name is often changed (Example Org.) and the number is changed to the direct number for example.com. I personally think this practice is an artifact of days long gone but it remains common. -Jonathan R. Hadriel Kaplan wrote: > As part of an off-line discussion regarding Kai Fischer's draft on e2e-security-media and whether his From-URI copying tactic would succeed or not at a policy level, if rfc4474 fails to do so, I gave my 2 cents on what some providers had been telling me. Dan asked me to write up a draft on it, in case people are interested. This is the draft: > http://www.ietf.org/internet-drafts/draft-kaplan-sip-uris-change-00.txt > > -hadriel > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 18:43:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7383A69A4; Mon, 25 Feb 2008 18:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpbPj2Mwh7p8; Mon, 25 Feb 2008 18:43:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B773A67D4; Mon, 25 Feb 2008 18:43:27 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6913A69A9 for ; Mon, 25 Feb 2008 18:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4paCOvSEaNz for ; Mon, 25 Feb 2008 18:43:22 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DD0FA3A6825 for ; Mon, 25 Feb 2008 18:43:21 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 25 Feb 2008 21:43:00 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 25 Feb 2008 21:43:00 -0500 From: Hadriel Kaplan To: IETF SIP List Date: Mon, 25 Feb 2008 21:41:19 -0500 Thread-Topic: I-D ACTION:draft-kaplan-sip-info-use-cases-01.txt Thread-Index: Ach4IRDV/JZNaXt+TeuHEmVNFDz22w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Sip] I-D ACTION:draft-kaplan-sip-info-use-cases-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org For posterity, I have updated the info-use-cases draft to fix some errors and include MSML. I don't expect this draft to go anywhere, since it has served its purpose, but wanted to get it right for Google's memory banks. (for when it becomes self-aware in 2029) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-use-cases-01.txt -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 18:53:02 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9333A6D07; Mon, 25 Feb 2008 18:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDExAYgLlsrz; Mon, 25 Feb 2008 18:53:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FE73A6D08; Mon, 25 Feb 2008 18:53:00 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A913A69B6 for ; Mon, 25 Feb 2008 18:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8YKIyvHZnDs for ; Mon, 25 Feb 2008 18:52:53 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EC74228C3D4 for ; Mon, 25 Feb 2008 18:52:40 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 25 Feb 2008 21:52:19 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 25 Feb 2008 21:52:17 -0500 From: Hadriel Kaplan To: IETF SIP List Date: Mon, 25 Feb 2008 21:50:36 -0500 Thread-Topic: I-D ACTION:draft-kaplan-sip-info-events-01.txt Thread-Index: Ach4IlzI2tkqHKiKRtGjhonCx20Mrw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Christer Holmberg Subject: [Sip] I-D ACTION:draft-kaplan-sip-info-events-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Howdy, The info-events draft has been updated with the following major changes (mostly based on Adam's comments): Incorporated RFC 2976 and changed the draft to replace it. (lots of changes there) Changed terminology to be "Info Packages" and changed header names. Added section on applicability, based on Eric's info draft. Added section on legacy use. Added section on requirements for defining a new Info Package. Changed BNF, but it's still not right yet. Other minor changes/edits based on mailing list comments. Known issues brought up on mailing list still open for SIP-WG discussion/decision: Whether to include Info-Packages in OPTIONS and REGISTER. Whether to have delayed package negotiation, for 3PCC cases. Whether to have re-Invite/Update re-negotiate packages. How to deal with overlapping or out-of-order INFO requests, if at all. What the response code should be for not-understood INFO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-events-01.txt -hadriel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 19:02:56 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C7428C36C; Mon, 25 Feb 2008 19:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGdnetVAjbs1; Mon, 25 Feb 2008 19:02:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841CE3A6C12; Mon, 25 Feb 2008 19:02:54 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86BEE3A682A for ; Mon, 25 Feb 2008 19:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDP13TJSmrW8 for ; Mon, 25 Feb 2008 19:02:51 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 23FC93A6ACE for ; Mon, 25 Feb 2008 19:02:18 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 25 Feb 2008 22:01:57 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 25 Feb 2008 22:01:55 -0500 From: Hadriel Kaplan To: Jonathan Rosenberg Date: Mon, 25 Feb 2008 22:00:14 -0500 Thread-Topic: [Sip] New I-D on why From/To-URIs are changed at provider borders Thread-Index: Ach4HaAa/qqNFFbfScmpfVeyIkDTNgABcPJw Message-ID: References: <47B9125B.2060104@cisco.com> <47B99B39.6040105@cisco.com> <47B9DE39.60608@cisco.com> <5FB585F183235B42A9E70095055136FB79857A@DEMUEXC012.nsn-intra.net> <47C37686.8000602@cisco.com> In-Reply-To: <47C37686.8000602@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] New I-D on why From/To-URIs are changed at provider borders X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yeah good point - it is what I would include under number translation I guess. Providers do it too in a way, when they remove internal routing prefix codes or "*" codes, fwiw. -hadriel > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Monday, February 25, 2008 9:17 PM > To: Hadriel Kaplan > Cc: IETF SIP List > Subject: Re: [Sip] New I-D on why From/To-URIs are changed at provider > borders > > Thanks for putting this together. > > I'll add another to your list. This is more of an enterprise thing, but > oftentimes the From URI is changed because the caller identity needs to > be set to the attendant number before going to another domain. For > example, if anyone within example.com makes a call, and that call > remains within example.com, the caller ID is unchanged. But if the > request exits the domain, the display name is often changed (Example > Org.) and the number is changed to the direct number for example.com. I > personally think this practice is an artifact of days long gone but it > remains common. > > -Jonathan R. > > Hadriel Kaplan wrote: > > As part of an off-line discussion regarding Kai Fischer's draft on e2e- > security-media and whether his From-URI copying tactic would succeed or > not at a policy level, if rfc4474 fails to do so, I gave my 2 cents on > what some providers had been telling me. Dan asked me to write up a draft > on it, in case people are interested. This is the draft: > > http://www.ietf.org/internet-drafts/draft-kaplan-sip-uris-change-00.txt > > > > -hadriel > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 25 23:53:08 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4933A6B2C; Mon, 25 Feb 2008 23:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql8UnxeSld0k; Mon, 25 Feb 2008 23:53:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207D33A6862; Mon, 25 Feb 2008 23:53:07 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D25D3A6862 for ; Mon, 25 Feb 2008 23:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8Kvq6WnoXcV for ; Mon, 25 Feb 2008 23:53:05 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 3E6A63A67D6 for ; Mon, 25 Feb 2008 23:53:04 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1Q7s1Mm016958; Tue, 26 Feb 2008 01:54:33 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 09:52:24 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 09:52:24 +0200 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 09:52:24 +0200 Message-ID: <47C3C53C.9010903@nokia.com> Date: Tue, 26 Feb 2008 09:52:28 +0200 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: ext Avshalom Houri References: <20080225063001.C5F0D28C233@core3.amsl.com> In-Reply-To: X-OriginalArrivalTime: 26 Feb 2008 07:52:24.0340 (UTC) FILETIME=[8623CD40:01C8784C] X-Nokia-AV: Clean Cc: sip List Subject: Re: [Sip] I-D Action:draft-ietf-sip-xcapevent-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ext Avshalom Houri wrote: > > Few questions/clarifications: > > Should there be a "content-disposition: recipient-list" header > included in the SUBSCRIBE? well, no. This is about sending a flat uri-list about "interesting" xcap-resources to a single server (closely coupled with the xcap-server). And also of course about syncing with this single server. > > When a SUBSCRIBE is refreshed, should the body sent again? > right, even with conditional re-subscriptions where the server returns a full response if there's no match in "etag" values. > Is there a way to change the subscription if different body will be sent > in subsequent SUBSCRIBE? > > Thanks > --Avshalom > you may change the subscription body with any re-subscribe, so that the client stamps all previous state as stale. Having body always is imo simpler and more consistent with conditional re-subscriptions, no ? And also body-content is presumably anyways pretty small. br, jari ps. there were minor changes from 00 version, some missing Accept-header and some text about Aki's subnotetags. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 00:26:21 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D463A6CCD; Tue, 26 Feb 2008 00:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WWofNsc-GQQ; Tue, 26 Feb 2008 00:26:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8A13A6C33; Tue, 26 Feb 2008 00:26:20 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61ACE3A6BCA for ; Tue, 26 Feb 2008 00:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztTCI1szBovu for ; Tue, 26 Feb 2008 00:26:17 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4AEFF3A6BFA for ; Tue, 26 Feb 2008 00:26:17 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1Q8Pxbi003431 for ; Tue, 26 Feb 2008 10:26:09 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 10:26:06 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 10:26:06 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 10:26:06 +0200 Received: from [172.21.40.116] (esdhcp040116.research.nokia.com [172.21.40.116]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1Q8Q3lr021242 for ; Tue, 26 Feb 2008 10:26:05 +0200 From: Aki Niemi To: sip@ietf.org Organization: Nokia Devices R&D Date: Tue, 26 Feb 2008 10:25:59 +0200 Message-Id: <1204014359.9517.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 26 Feb 2008 08:26:06.0930 (UTC) FILETIME=[3BB28B20:01C87851] X-Nokia-AV: Clean Subject: [Sip] New version of draft-ietf-sip-subnot-etags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I have submitted a new version of draft-ietf-sip-subnot-etags. I've sat on my hands for months on this, and I apologize for that. This version clears the backlog of the WGLC comments from late last year. I've sent replies to those comments separately. The biggest change is that the draft now joins together the two previously separate header fields (Suppress-Notify-If-Match and Suppress-Body-If-Match) and behaviors into a single header field (Suppress-If-Match) and behavior, as was suggested by Jonathan Rosenberg. I think this draft is about ready for publication, but as the diff to the previous version is non-trivial, perhaps another WGLC is in order. But I let the chairs speak on that. Cheers, Aki _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 03:52:30 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E2B28C253; Tue, 26 Feb 2008 03:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMzSLsB1-eJ4; Tue, 26 Feb 2008 03:52:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF933A6CBC; Tue, 26 Feb 2008 03:52:29 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F943A6CD9 for ; Tue, 26 Feb 2008 03:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4HUstnrD37U for ; Tue, 26 Feb 2008 03:52:26 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 754DB3A6CB3 for ; Tue, 26 Feb 2008 03:52:26 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m1QBpxam025773 for ; Tue, 26 Feb 2008 05:52:19 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 05:52:01 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 12:51:58 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8786D.FDB5CC98" Date: Tue, 26 Feb 2008 12:51:56 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001C69224@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-subnot-etags-02.txt Thread-index: Ach37Id6u148lWiSQfWH3dbefA3+/wAgSJ6w From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 26 Feb 2008 11:51:58.0515 (UTC) FILETIME=[FDD0D830:01C8786D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [Sip] FW: I-D Action:draft-ietf-sip-subnot-etags-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8786D.FDB5CC98 Content-Type: text/plain; name="warning1.txt" Content-Disposition: inline; filename="warning1.txt" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) WARNING: This e-mail has been altered by some SMTP protection software. Following this paragraph are indications of the actual changes made. For more information, contact . An attachment named draft-ietf-sip-subnot-etags-02.URL was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. ------_=_NextPart_001_01C8786D.FDB5CC98 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (As SIP WG cochair) This should represent the completion of the WG last call comments from some time back... Can you please check that if you made comments during WGLC, those comments have been addressed to your satisfaction. This is also the opportunity for all of you to do your last scan through this document and address any comments as I work through the publication request. Regards Keith -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, February 25, 2008 7:45 PM To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-subnot-etags-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author(s) : A. Niemi Filename : draft-ietf-sip-subnot-etags-02.txt Pages : 24 Date : 2008-02-25 The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-subnot-etags-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-subnot-etags-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-subnot-etags-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C8786D.FDB5CC98 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C8786D.FDB5CC98-- From sip-bounces@ietf.org Tue Feb 26 10:46:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218E83A6D81; Tue, 26 Feb 2008 10:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVClaC7IY1iJ; Tue, 26 Feb 2008 10:46:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF41C28C27F; Tue, 26 Feb 2008 10:46:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9756A28C2A8 for ; Tue, 26 Feb 2008 10:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxQSf1se2S+h for ; Tue, 26 Feb 2008 10:46:32 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C953D28C1FC for ; Tue, 26 Feb 2008 10:46:32 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Feb 2008 10:46:27 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1QIkQYR014906; Tue, 26 Feb 2008 10:46:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1QIk7RW018422; Tue, 26 Feb 2008 18:46:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 10:46:21 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 10:46:20 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Feb 2008 12:46:18 -0600 To: Dale.Worley@comcast.net, sip@ietf.org From: "James M. Polk" In-Reply-To: <200802252311.m1PNBxuu007876@dragon.ariadne.com> References: <20080224054501.90B6A3A6A07@core3.amsl.com> <200802250404.m1P44eZm023626@dragon.ariadne.com> <200802252311.m1PNBxuu007876@dragon.ariadne.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 26 Feb 2008 18:46:20.0645 (UTC) FILETIME=[E0CCD150:01C878A7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2062; t=1204051586; x=1204915586; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20I-D=20Action=3Adraft-ietf-sip-r ph-new-namespaces-02.txt |Sender:=20; bh=jm1RHv5jZzvyxXRPRkBCXaqSNik+jPJoNkQooicxB+4=; b=qCexFw4Ttp39KM1K6KSN+Ayv4OM/vpTvqamo+Nj53FO+/UvwUgHWNkcHJi 5Sqw+ZLC91YfPgaQZJNbPLt1NEGbtasxeYTKe0QGRGQZup3agCFu4G77C6yH hU9+1dB3aL; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 05:11 PM 2/25/2008, Dale.Worley@comcast.net wrote: > From: "James M. Polk" > > At 10:04 PM 2/24/2008, Dale.Worley@comcast.net wrote: > > Title : IANA Registration of New Session > > Initiation Protocol (SIP) > > Resource-Priority Namespaces > > Author(s) : J. Polk > > Filename : draft-ietf-sip-rph-new-namespaces-02.txt > > Pages : 7 > > Date : 2008-02-23 > > > > Abstract: > > > > This document creates additional Session Initiation Protocol > > Resource-Priority namespaces, and places these namespaces in the > > IANA register. > > > >As an editorial matter, can the abstract be made less vague? Such as > >mentioning that it creates a set of namespaces for the use of the US > >Defense Information Systems Agency... > > well, at least I didn't overstate things... ;-) > > I can change this if you want me to > >I've been sick and perhaps my message was a little short. But when I >read the abstract, I realized that if I didn't already know what the >I-D was about, the abstract really wouldn't tell me. It would be even >clearer to say something like "This document creates 40 additional SIP >... for the use of DISA." But that might sound snarky, as people have >wondered what so many namespaces are needed for. Well... I can easily put the purpose of the namespaces in, to differentiated it from future IANA registrations of RP namespaces. I'll submit this in two weeks, when we're out of the blackout period. This is easy. James >Dale >_______________________________________________ >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 13:01:03 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243BD28C7C1; Tue, 26 Feb 2008 13:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1pf6Tb3XNLf; Tue, 26 Feb 2008 13:01:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1FF28C6D9; Tue, 26 Feb 2008 13:01:01 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A72828C5A2 for ; Tue, 26 Feb 2008 13:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp5P354XQtJj for ; Tue, 26 Feb 2008 13:00:59 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EF41F28C56D for ; Tue, 26 Feb 2008 13:00:58 -0800 (PST) Received: from [192.168.1.3] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1QL0oZg015867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 Feb 2008 15:00:51 -0600 Message-Id: <77EA4502-7DE1-40F8-9051-8D7F965FEE56@softarmor.com> From: Dean Willis To: IETF SIP List Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 26 Feb 2008 15:00:44 -0600 X-Mailer: Apple Mail (2.919.2) Subject: [Sip] Draft SIP agenda for IETF 71 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0801481671==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0801481671== Content-Type: multipart/alternative; boundary=Apple-Mail-5-266661825 --Apple-Mail-5-266661825 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit A draft agenda follows. This is a VERY draft agenda, since it's about 5 hours long and we currently have only 2 hour of meeting time. Note that this has a new format: it includes markup as to whether each item is chartered (I was getting questioned on this) and a status column. Please review carefully and let me know if you'd like to volunteer to give up a time slot, or if other changes are needed. Agenda also posted on Softarmor and IETF sites. HTML follows: Agenda for SIP at IETF 71 Charter? Topic Discussion Lead Drafts Status Time Y Example Security Flows Robert Sparks draft-ietf-sip-sec-flows-01 Revising 0 Y Corrections to SIPS Francois Audet draft-ietf-sip-sips-08 Ready for pub 0 Y Diagnostic Responses Scott Lawrence draft-ietf-sip-hop-limit- diagnostics-03 Expired 0 Y Change Notification Event Package for XCAP Jari Urpalainenen draft- ietf-sip-xcapevent-01 Ready WGLC 0 Y Roadmap for SIP Jonathan Rosenberg draft-ietf-sip-hitchhikers- guide-05 Discuss 0 Y Requirements for test matrix to move SIP to Draft Standard Robert Sparks TBD Working 0 Y Using SAML for SIP Hannes Tschofenig Jeff Hodges draft-ietf-sip-saml-03 Revising 0 Y etags in conditional notification Aki Niemi draft-ietf-sip-subnot- etags-02 Revising 0 Y Outbound Francois Audet draft-ietf-sip-outbound-12 Overdue 15 Y Location Conveyance James Polk draft-ietf-sip-location-conveyance-10 Overdue 15 Y Connection Reuse Vijay Gurbani draft-ietf-sip-connect-reuse-09 WGLC Done? 15 Y Session Policies Volker Hilt draft-ietf-sip-session-policy- framework-02 Overdue 15 Y Requirements for Media Keying Dan Wing draft-ietf-sip-media-security- requirements-03 Discuss 15 Y Essential corrections to RFC 3261 Robert Sparks draft-drage-sip- essential-correction-02 Discuss 15 Y MIME body handling in SIP Gonzalo Camarillo draft-ietf-sip-body- handling-01 Discuss 15 Y UA initiated privacy Mayumi Munakata [1] Discuss 15 Y X.509 Certificates for TLS Vijay Gurbani Scott Lawrence draft-ietf-sip-domain-certs-00 In WGLC 15 Y X.509 Extended Key Usage Vijay Gurbani Scott Lawrence draft-ietf-sip-eku-01 in WGLC 15 Y Resource Priority Namespaces for DISA James Polk draft-ietf-sip-rph- new-namespaces-02 Discuss 15 Y Establishment of secure media sessions using DTLS-SRTP Jason Fischl draft-ietf-sip-dtls-srtp-framework-01 Discuss 15 Y Delivering request-URI and parameters to UAS via proxy Christer Holmberg draft-holmberg-sip-target-uri-delivery-01 draft-rosenberg-sip-ua-loose-route-02 draft-rosenberg-sipping-siptrunk-00 ? 30 N INFO Events Hadriel Kaplan Christer Holmberg draft-kaplan-sip-info-events-00 draft-kaplan-sip-info-use-cases-00 Discuss 15 N INFO Litmus Test Jonathan Rosenberg draft-rosenberg-sip-info- litmus-00 Discuss 15 N TOTE/ Media Path INFO Jonathan Rosenberg draft-rosenberg-sip-tote-00 Discuss 15 N Phish Baiting with Identity Hadriel Kaplan draft-kaplan-sip-baiting- attack-01 Discuss 15 N Identity-Based Authentication in SIP Harsh Kupwade Patil draft- kupwade-sip-iba-00 Discuss 15 N The Phone Number/Identity Dichotomoy Most of the Working Group draft- rosenberg-sip-rfc4474-concerns-00 Discuss 30 N Proxy-Authenticate-Info Sumanth Channabasappa tbd Discuss 5 N ICE Error Code Jonathan Rosenberg draft-rosenberg-sip-ice-error- code-01 Discuss 5 --Apple-Mail-5-266661825 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A draft agenda follows. This is = a VERY draft agenda, since it's about 5 hours long and we currently have = only 2 hour of meeting time.

    Note that this has a new = format: it includes markup as to whether each item is chartered (I was = getting questioned on this) and a status column.

    Please review carefully = and let me know if you'd like to volunteer to give up a time slot, or if = other changes are needed.

    Agenda also posted on = Softarmor and IETF sites.

    HTML = follows:

    Agenda for SIP at = IETF = 71Charter?TopicDiscussion = LeadDraftsStatusTimeYExample Security FlowsRobert SparksRFC 3261Robert = SparksChrister = Holmberg
    X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B733A6C6D; Tue, 26 Feb 2008 13:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9LjAKII7W9p; Tue, 26 Feb 2008 13:13:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0BB428C130; Tue, 26 Feb 2008 13:13:51 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21203A68BD for ; Tue, 26 Feb 2008 13:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFb3c2vXaNMq for ; Tue, 26 Feb 2008 13:13:50 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8A6493A6808 for ; Tue, 26 Feb 2008 13:13:49 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 21:13:42 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.5]) [91.154.103.163] by mail.gmx.net (mp031) with SMTP; 26 Feb 2008 22:13:42 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+he+tpHcmhs1bKvs9T2l+TtMkD/IRCSdY+RiWyUX g7YmUrpGYzrVSJ Message-ID: <47C480FB.8070608@gmx.net> Date: Tue, 26 Feb 2008 23:13:31 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <77EA4502-7DE1-40F8-9051-8D7F965FEE56@softarmor.com> In-Reply-To: <77EA4502-7DE1-40F8-9051-8D7F965FEE56@softarmor.com> X-Y-GMX-Trusted: 0 Cc: IETF SIP List Subject: Re: [Sip] Draft SIP agenda for IETF 71 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org How are you going to cover all the identity related documents? I see only a few documents on the agenda Dean Willis wrote: > A draft agenda follows. This is a VERY draft agenda, since it's about > 5 hours long and we currently have only 2 hour of meeting time. > > Note that this has a new format: it includes markup as to whether each > item is chartered (I was getting questioned on this) and a status column. > > Please review carefully and let me know if you'd like to volunteer to > give up a time slot, or if other changes are needed. > > Agenda also posted on Softarmor and IETF sites. > > HTML follows: > > Agenda for SIP at IETF 71 > Charter? Topic Discussion Lead Drafts Status Time > Y Example Security Flows Robert Sparks > draft-ietf-sip-sec-flows-01 Revising 0 > Y Corrections to SIPS Francois Audet > draft-ietf-sip-sips-08 Ready for pub 0 > Y Diagnostic Responses Scott Lawrence > draft-ietf-sip-hop-limit-diagnostics-03 Expired 0 > Y Change Notification Event Package for XCAP Jari > Urpalainenen draft-ietf-sip-xcapevent-01 Ready WGLC 0 > Y Roadmap for SIP Jonathan Rosenberg > draft-ietf-sip-hitchhikers-guide-05 Discuss 0 > Y Requirements for test matrix to move SIP to Draft Standard > Robert Sparks TBD Working 0 > Y Using SAML for SIP Hannes Tschofenig > Jeff Hodges draft-ietf-sip-saml-03 Revising 0 > Y etags in conditional notification Aki Niemi > draft-ietf-sip-subnot-etags-02 Revising 0 > Y Outbound Francois Audet draft-ietf-sip-outbound-12 > Overdue 15 > Y Location Conveyance James Polk > draft-ietf-sip-location-conveyance-10 Overdue 15 > Y Connection Reuse Vijay Gurbani > draft-ietf-sip-connect-reuse-09 WGLC Done? 15 > Y Session Policies Volker Hilt > draft-ietf-sip-session-policy-framework-02 Overdue 15 > Y Requirements for Media Keying Dan Wing > draft-ietf-sip-media-security-requirements-03 Discuss 15 > Y Essential corrections to RFC 3261 Robert Sparks > draft-drage-sip-essential-correction-02 Discuss 15 > Y MIME body handling in SIP Gonzalo Camarillo > draft-ietf-sip-body-handling-01 Discuss 15 > Y UA initiated privacy Mayumi Munakata [1] Discuss 15 > Y X.509 Certificates for TLS Vijay Gurbani > Scott Lawrence draft-ietf-sip-domain-certs-00 In WGLC 15 > Y X.509 Extended Key Usage Vijay Gurbani > Scott Lawrence draft-ietf-sip-eku-01 in WGLC 15 > Y Resource Priority Namespaces for DISA James Polk > draft-ietf-sip-rph-new-namespaces-02 Discuss 15 > Y Establishment of secure media sessions using DTLS-SRTP Jason > Fischl draft-ietf-sip-dtls-srtp-framework-01 Discuss 15 > Y Delivering request-URI and parameters to UAS via proxy > Christer Holmberg draft-holmberg-sip-target-uri-delivery-01 > draft-rosenberg-sip-ua-loose-route-02 > draft-rosenberg-sipping-siptrunk-00 > ? 30 > N INFO Events Hadriel Kaplan > Christer Holmberg > draft-kaplan-sip-info-events-00 > draft-kaplan-sip-info-use-cases-00 > Discuss 15 > N INFO Litmus Test Jonathan Rosenberg > draft-rosenberg-sip-info-litmus-00 Discuss 15 > N TOTE/ Media Path INFO Jonathan Rosenberg > draft-rosenberg-sip-tote-00 Discuss 15 > N Phish Baiting with Identity Hadriel Kaplan > draft-kaplan-sip-baiting-attack-01 Discuss 15 > N Identity-Based Authentication in SIP Harsh Kupwade Patil > draft-kupwade-sip-iba-00 Discuss 15 > N The Phone Number/Identity Dichotomoy Most of the Working > Group draft-rosenberg-sip-rfc4474-concerns-00 Discuss 30 > N Proxy-Authenticate-Info Sumanth Channabasappa tbd > Discuss 5 > N ICE Error Code Jonathan Rosenberg > draft-rosenberg-sip-ice-error-code-01 Discuss 5 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 13:31:26 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FA23A6DAC; Tue, 26 Feb 2008 13:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23F2PdUNALXB; Tue, 26 Feb 2008 13:31:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F0C3A6D69; Tue, 26 Feb 2008 13:31:20 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D464E3A6D1D for ; Tue, 26 Feb 2008 13:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQtx0SlNEoc3 for ; Tue, 26 Feb 2008 13:31:18 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 111723A6D6B for ; Tue, 26 Feb 2008 13:31:15 -0800 (PST) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id uEvf1Y00M0EPchoA50ZP00; Tue, 26 Feb 2008 21:30:23 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id uMX71Y00N0umElk8M00000; Tue, 26 Feb 2008 21:31:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=jBN9FSJavanR17sMwmQA:9 a=31pBORbvePUO2xJdf20A:7 a=fFxyS0LMJWkRYGzhMBUJY5HAe0QA:4 a=r9vth0PIv-oA:10 a=e1i35A98MB8A:10 a=1pxjJC3EenQA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m1QLV7Mj008480 for ; Tue, 26 Feb 2008 16:31:07 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m1QLV7Rm008476; Tue, 26 Feb 2008 16:31:07 -0500 Date: Tue, 26 Feb 2008 16:31:07 -0500 Message-Id: <200802262131.m1QLV7Rm008476@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1203976392.6192.88.camel@localhost> (aki.niemi@nokia.com) References: <5D1A7985295922448D5550C94DE2918001636AF1@DEEXC1U01.de.lucent.com> <200709181506.l8IF6Bmp007748@dragon.ariadne.com> <1203976392.6192.88.camel@localhost> Subject: Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Aki Niemi On ti, 2007-09-18 at 11:06 -0400, ext worley@dworley.hsd1.ma.comcast.net wrote: > I have one technical issue (which is probably insoluble and can only > be documented) and a number of nits. > > * Section 4 specifies that a resource is identified by one or more > URIs. It seems to be implicit that one URI always identifies the same > resource. Without that, it would be difficult to use ETags > effectively, since ETags are only unique for a single resource. Yes. > In the general case, the mapping from URIs to resources involves the > full complexity of SIP routing. This means that without additional > information, the subscriber does not know that request-URI that it > uses always maps into the same resource URI, and so has no absolute > guarantee that the space of ETags it is working with does not change > over time. The subscriber really need not know. It is the notifier's responsibility to keep the entity-tags unique across all of the insanely difficult SIP routing that it may deploy in front of it. The notifier cannot know what routing is in front of it, because it cannot know what URIs might route to it. > One assumes that all SUBSCRIBEs within a subscription are routed to > the same destination URI because the refresh SUBSCRIBEs are sent using > the route-set and contact. But a "resumed" subscription does not have > this protection. Correct. > It is not clear that there is any solution to these problems, and we > may only be able to document that the subscriber is responsible for > assuring that successive subscription requests are delivered to the > same resource. This isn't the subscriber's problem. Moreover, I really doubt that it is even feasible to build a system where a new subscription sent to the same AoR will randomly reach a different notifier instance that is in no way synchronized (as in state, entity-tag values, etc) with the other instances. There is no requirement that the SUBSCRIBE was sent to an "AoR" (even if that term was well-defined). It is trivial to build a system where a new subscription could go to a place that is much different than a previous subscription: sip:a.example.com forwards to sip:b.example.com - I think of this as "my call center". What I don't know is: sip:b.example.com uses time-of-day-based routing to forward to either sip:c1.example.com or sip:c2.example.com - My company has outsourced the call center to two different companies in in two different places, one for the day shift and one for the night shift. sip:c1.example.com parallel-forks to sip:d1a.example.com and sip:d1b.example.com - The day-shift call center workers are in several locations. sip:c2.example.com parallel-forks to sip:d2a.example.com and sip:d2b.example.com - And so are the night-shift call center workers. OK, now I send "SUBSCRIBE sip:a.example.com". Unless I know the details of the above routing, there's no way for me to know that the routing changes with time. Similarly, there's no way for the notifiers at d1a.example.com, d1b.example.com, d2a.example.com, and d2a.example.com to even know what notifiers they *might* have to synchronize with. Dale _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 13:41:21 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A955E3A6C13; Tue, 26 Feb 2008 13:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FltDdeeWQvA; Tue, 26 Feb 2008 13:41:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED5428C230; Tue, 26 Feb 2008 13:41:20 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBC528C230 for ; Tue, 26 Feb 2008 13:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6ROQbeoC-ZD for ; Tue, 26 Feb 2008 13:41:18 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CFCED3A6C13 for ; Tue, 26 Feb 2008 13:41:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,409,1199692800"; d="scan'208";a="7216503" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2008 13:41:11 -0800 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 m1QLfBdN022486 for ; Tue, 26 Feb 2008 13:41:11 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1QLfBR6000447 for ; Tue, 26 Feb 2008 21:41:11 GMT 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.1830); Tue, 26 Feb 2008 13:41:04 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 13:41:04 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Feb 2008 15:41:06 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 26 Feb 2008 21:41:04.0111 (UTC) FILETIME=[496EC7F0:01C878C0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3453; t=1204062071; x=1204926071; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Location=20Conveyance=20-10=20is=20out |Sender:=20; bh=A/vW38Cqd11IacadKL+hYhBgWT7l+dd+Ra7D9hI7fhA=; b=Km545gGOETwC+It8FATEfUsbgk1SHVvYi95AX++zO+QTmnFGfsCv+2pNd2 29VX2cTr5OcR3m/3b4cu+rYefvf3eiRduUIH99wq7M0e6pUZeemKLf0SWpc2 FyUhOL4F+t; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Sip] Location Conveyance -10 is out X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-10.txt This is a list of changes to Conveyance -10 that might not be so obvious, since a fair amount of the text was streamlined or just changed (meaning any diff won't point at these changes only): - moved Conventions and (the new) terminology section in front of the Introduction section -- so that readers know the terms and acronyms before the Intro. - removed the ability to provide granular CAtype indications in the locationErrorValue (to several people's relief!) - modified all mentioning of "Location-by-Reference" and "by-reference" to "LbyR" throughout the doc, for consistency - modified all mentioning of "Location-by-Value" and "by-Value" to "LbyV" throughout the doc, for consistency - created a brand new errors section. All (17 previous) errors were distilled down to 5 actionable responses by a location error recipient essentially meaning: - General error - similar to SIP 400 response - retry later, with same data - no retry-after indicator though - retry later, once device has refreshed data - no retry-after indicator though - user permission to reveal location necessary to succeed - Denial error (active denial of location supplied in request) - similar to 6XX in SIP - each are defined and actions articulated, as well as non-actions and misunderstandings are articulated - created the ability for each action to have a range of error codes, such as 1XX, 2XX, 3XX, 4XX, and 5XX ranges - but that is left for future efforts - consequence of fewer errors is the inability to indicate URI scheme not supported (specifically, sips: and pres:) - greatly shortened section 3 (Conveyance Overview) to not have 2119 language. Moved remaining text to section 4. - clarified Geolocation-Error header can be in any non-100 response - clarified role of 424 (Bad Location Information) - removed all references to "recipient=" parameter within the Geolocation header - created new IANA registry for Location Reference URI (schemes), and register 3 schemes with this doc (sip:, sips:, and pres:) - corrected the IANA registration of "Header Field Parameters and Parameter Values" for both the Geolocation and Geolocation-Error headers (thanks Adam Roach!) - fixed the Geolocation-Error ABNF (thanks Paul Kyzivat!) - changed all usage of "per " to "as defined in " >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 : Location Conveyance for the Session > Initiation Protocol > Author(s) : J. Polk, B. Rosen > Filename : draft-ietf-sip-location-conveyance-10.txt > Pages : 44 > Date : 2008-2-25 > >This document defines an extension to the Session Initiation > Protocol (SIP) to convey geographic location information from one > SIP entity to another SIP entity. The extension covers end to end > conveyance as well as location-based routing, where proxy servers > make routing decisions based on the location of the SIP user agents. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 14:31:17 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6908728C592; Tue, 26 Feb 2008 14:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GguRchddwkOG; Tue, 26 Feb 2008 14:31:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA0928C515; Tue, 26 Feb 2008 14:31:16 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF52B28C4AB for ; Tue, 26 Feb 2008 14:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbN0F3WvKEGX for ; Tue, 26 Feb 2008 14:31:14 -0800 (PST) Received: from isr-jlm-mail.Kayote.com (isr-jlm-mail.kayote.com [212.25.94.44]) by core3.amsl.com (Postfix) with ESMTP id 984A128C4EB for ; Tue, 26 Feb 2008 14:31:13 -0800 (PST) MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 27 Feb 2008 00:31:04 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A6065504FCB700@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: nit in draft-wing-sip-e164-rrc-01 Thread-Index: Ach4x0TCNh6QwqPNQeO7TMN1gaeTRA== From: "David Schwartz" To: Cc: sip@ietf.org Subject: [Sip] nit in draft-wing-sip-e164-rrc-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0028975315==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0028975315== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C878C7.45AC82EF" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C878C7.45AC82EF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dan a quick comment on this draft... There is no discussion of what happens when there is a validation = failure. While obvious, you should probably reference 4474 processing = upon validation failure (i.e. respond with 438 'Invalid Identity = Header'). And while on the topic in your second example where the cert = comparison test fails your diagram still shows the call proceeding to = its destination (hence the earlier comment). D. ------_=_NextPart_001_01C878C7.45AC82EF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable nit in draft-wing-sip-e164-rrc-01

    Hi Dan

    a quick comment on this draft...

    There is no discussion of what happens when there is a validation = failure. While obvious, you should probably reference 4474 processing = upon validation failure (i.e. respond with 438 'Invalid Identity = Header'). And while on the topic in your second example where the cert = comparison test fails your diagram still shows the call proceeding to = its destination (hence the earlier comment).
    D.

    ------_=_NextPart_001_01C878C7.45AC82EF-- --===============0028975315== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0028975315==-- From sip-bounces@ietf.org Tue Feb 26 16:35:10 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16A928C2EA; Tue, 26 Feb 2008 16:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcvTstY7i1yD; Tue, 26 Feb 2008 16:35:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798E43A697B; Tue, 26 Feb 2008 16:35:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5823A68D3 for ; Tue, 26 Feb 2008 16:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ornsj24SmexO for ; Tue, 26 Feb 2008 16:35:06 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id CCC1F3A689E for ; Tue, 26 Feb 2008 16:35:06 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 265505081A; Tue, 26 Feb 2008 16:36:51 -0800 (PST) Date: Tue, 26 Feb 2008 16:36:51 -0800 From: Eric Rescorla To: sip@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227003651.265505081A@romeo.rtfm.com> Cc: draft-kupwade-sip-iba@tools.ietf.org Subject: [Sip] Review of draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org $Id: draft-kupwade-sip-iba-00-rev.txt,v 1.1 2008/02/27 00:16:00 ekr Exp $ SIP has seen several attempts to use cryptographic signatures to provide data origin authentication for SIP messages: - RFC 3261 provided for S/MIME digital signatures by the end-user. - RFC 4474 provided for "Identity" signatures by an authentication proxy. The RFC 3261 S/MIME scheme has seen almost no deployment. This was generally attributed to the difficulty of users obtaining certificates. RFC 4474 was explicitly designed to avoid end-user certs and is comparatively new so we don't know what kind of deployment it will see. This document describes an alternate mechanism using "Identity Based Signatures". This is a little complicated to explain, but here's the basic overview: In a conventional asymmetric (public key) scheme, you generate your own key pair, consisting of a public key and a private key. Then when someone wants to encrypt to you, they encrypt under your public key and you decrypt with the private key. But how do people get your public key, and how do they know it's yours? That's what certificates are for. A certificate, of course, is a credential that binds your name to your public key. But this is all kind of inconvenient if you want to encrypt to someone who you've never talked to before, because you need to get their certificate, which brings up directory issues. Identity-Based Encryption is a scheme that does without the certificates. The idea is that you have two algorithms: - P(string) which converts any string into a public key - p(string, K) which converts any string into its corresponding private key. K, of course, is a secret master parameter. So, instead of having a certificate authority you have a key generator (KG) which knows K. KG's policy is only to issue private key p(, K) to the owner of (this is the same policy as the CA would have, of course). So, when you want to encrypt to "alice@example.com" you encrypt to P("alice@example.com") secure in the knowledge that only Alice could have gotten the private key. The nice thing about this is that there is no need to have a certificate directory because the public key is directly computable from the SIP URI. Where this seems useful is in settings where you want to encrypt to people you have had no prior contact with, like e-mail. (more on this at http://www.rtfm.com/movabletype/archives/2003_07.html#000315). Unsurprisingly, IBE has a signature variant. In a conventional public key system, when you want to sign a message you send along [Message, Signature, Certificate]. The recipient extracts your public key from the certificate and then verifies the signature. In Identity Based Signatures (IBS), you can do without the cert: the sender just send [Message, Signature, Identity] since the receiver can compute the public key directly from the Identity. It shouldn't be hard to see that this is a lot less interesting than IBE, since pretty much by definition the verifier is reading a message from the signer and so the signer can include a copy of (or a reference to) his certificate. So, all this really does is provide a bit of message compression. With all that in mind, this document describes how to use a variant of Identity Based Signatures with SIP Identity. Now, I've oversimplified a little bit, because there are two other features it uses (neither of which are actually that desirable). - "Signcryption". When Alice sends a message to Bob, she can structure her signature so that only Bob can verify it. This pretty clearly interacts badly with retargeting. - Hierarchical IBS. The system I described has only one key generator, but it's possible to use crypto to delegate authority so that there is a central KG which delegates "example.com" to one sub-KG and "example.org" to another. This doesn't make a lot of sense in an RFC4474 environment since there's only one key for any domain anyway. The only thing that this document really does is allow you to avoid having to have the trivial Web site RFC 4474 requires you to have (or contract for) to stick your certificate on. However, when you weigh that against the fact that the number of CAs issuing identity-based signature keys currently stands at 0, that seems to be a pretty marginal advantage. -Ekr _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 18:18:29 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C95328C3C5; Tue, 26 Feb 2008 18:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHSmNma3js1n; Tue, 26 Feb 2008 18:18:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19B828C2EA; Tue, 26 Feb 2008 18:18:27 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88793A69CD for ; Tue, 26 Feb 2008 18:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IftlvyfJ+8N2 for ; Tue, 26 Feb 2008 18:18:24 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id ABE513A6CAB for ; Tue, 26 Feb 2008 18:18:24 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Feb 2008 18:18:17 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1R2IIcK026677 for ; Tue, 26 Feb 2008 18:18:18 -0800 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 m1R2IICH023771 for ; Wed, 27 Feb 2008 02:18:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 18:18:18 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 18:18:18 -0800 Message-ID: <47C4C85F.4050000@cisco.com> Date: Tue, 26 Feb 2008 21:18:07 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List X-OriginalArrivalTime: 27 Feb 2008 02:18:18.0135 (UTC) FILETIME=[04156A70:01C878E7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2159; t=1204078698; x=1204942698; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-kupwade-sip-iba-00 |Sender:=20; bh=b5t9939LKmuQBnAMTT9eZXtM+qT2knmgyeCSwGTaGFU=; b=nTgNf8D4m2/S+k7By3xC087A+JIhFD05AiTKtpb0nMUdoNqcOlq2fiLOpr D3R0ceS4kUp6nUai2m9AkeaQVZnp59IyiP1Z6BTo6vPmMBAI0GefG1mzwaMw s28GIbyM3K; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Harsh, Dean, Thanks much for this document. Its great to see folks trying to tackle new areas of work, especially tough ones like identity. The concept of identity based security is a new one to me; how mature is this stuff? Are there any commercial uses yet? What about intellectual property issues? Has it been well-studied by experts to assess its robustness? i.e., have folks been trying to crack it, and so far its held up? The document talks about encrypting the signature for the target but I don't see what security benefit this brings. Indeed, encrypting content in the signaling for an intended target has proven very problematic. Besides the (so-far) hugely hard cert problem, there is also the issue of retargeting. Also you have cases of multiple receiving devices - forking for example. Maybe Dean is just hoping it goes away, but how would this solution work there? Then there are things like shared lines, contact centers, etc... I agree with Ekr that the primary advantage from a pure signature perspective is the ability to eliminate the fetching of the certificate. I think this is more beneficial than just 'compression'. Identity-Info presents the certificate by reference. The increasing numbers of NAT and firewalls and SBCs are making me increasingly worried that the ability to reach across the network, back to the originator, and fetch ANYTHING over http, will be really hard in SIP deployments. So there is value in eliminating this IMHO. I must say I didn't understand how revocation works. From the description of the algorithm it seemed untenable. The verifier never needs to obtain a cert and the public key is generated statically from the identity. Once they have the private key, the sender can always sign with it, so I don't see how revocation is possible. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 21:39:29 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C050C28C333; Tue, 26 Feb 2008 21:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrmH98-TSUPP; Tue, 26 Feb 2008 21:39:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190E53A68F4; Tue, 26 Feb 2008 21:39:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEF13A68F4 for ; Tue, 26 Feb 2008 21:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8-wis4-wdGF for ; Tue, 26 Feb 2008 21:39:21 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 5A6A93A686E for ; Tue, 26 Feb 2008 21:39:21 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8A9DE5081A; Tue, 26 Feb 2008 21:41:05 -0800 (PST) Date: Tue, 26 Feb 2008 21:41:05 -0800 From: Eric Rescorla To: Jonathan Rosenberg In-Reply-To: <47C4C85F.4050000@cisco.com> References: <47C4C85F.4050000@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227054105.8A9DE5081A@romeo.rtfm.com> Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Tue, 26 Feb 2008 21:18:07 -0500, Jonathan Rosenberg wrote: > > Harsh, Dean, > > Thanks much for this document. Its great to see folks trying to tackle > new areas of work, especially tough ones like identity. > > The concept of identity based security is a new one to me; how mature is > this stuff? Well, my pairing based cryptography expert friends tell me that the algorithms in this draft are pretty far off the current state of the art, which would be something from the Boneh-Boyen family. BB is pretty well regarded. > Are there any commercial uses yet? Yes: www.voltage.com www.identum.com (full disclosure: I'm on Voltage's TAB). > What about intellectual > property issues? Yes, there are a number of patents in the field. I don't know about these specific algorithms, but given that they post-date the original Boneh-Franklin IBE patent, it wouldn't be surprising if they were covered by patents. Dean? > Has it been well-studied by experts to assess its > robustness? i.e., have folks been trying to crack it, and so far its > held up? Yes, at least for the Boneh-Franklin and Boneh-Boyen stuff. As with all modern algorithms, there are security reductions to some assumed hard problem. HArd to know how much that should comfort you. > > I agree with Ekr that the primary advantage from a pure signature > perspective is the ability to eliminate the fetching of the certificate. > I think this is more beneficial than just 'compression'. Identity-Info > presents the certificate by reference. The increasing numbers of NAT and > firewalls and SBCs are making me increasingly worried that the ability > to reach across the network, back to the originator, and fetch ANYTHING > over http, will be really hard in SIP deployments. So there is value in > eliminating this IMHO. Sure, but we could just shove the certificate into the message in a new header or in the body, at which point we are talking about compression. Moreover, there's no requirement that the certificate be on the UAC's machine. If people care about this, then it seems pretty likely that the CA can operate a site which hosts your certificate for you. This is especially true when we're talking about one certificate per domain as assumed by RFC 4474. > I must say I didn't understand how revocation works. From the > description of the algorithm it seemed untenable. The verifier never > needs to obtain a cert and the public key is generated statically from > the identity. Once they have the private key, the sender can always sign > with it, so I don't see how revocation is possible. The way this is done is with what's effectively short-lived identities (you could do the same thing with short-lived certificates) you treat the time as part of the identity. E.g., you might be "jdrosen@cisco.com:March-April, 2008". So, the user needs to periodically refresh his private key to match the new identity. If the key has been revoked you don't issue new keys. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 21:43:10 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8203A6DC9; Tue, 26 Feb 2008 21:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZfQsO8UJShM; Tue, 26 Feb 2008 21:43:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B1B3A6DA5; Tue, 26 Feb 2008 21:43:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4640F3A6DBC for ; Tue, 26 Feb 2008 21:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaWY0Ryc+c98 for ; Tue, 26 Feb 2008 21:43:03 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5B6C63A6DCA for ; Tue, 26 Feb 2008 21:42:50 -0800 (PST) Received: from [192.168.1.3] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1R5gdmm019641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2008 23:42:41 -0600 Message-Id: From: Dean Willis To: Hannes.Tschofenig@gmx.net In-Reply-To: <47C480FB.8070608@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 26 Feb 2008 23:42:34 -0600 References: <77EA4502-7DE1-40F8-9051-8D7F965FEE56@softarmor.com> <47C480FB.8070608@gmx.net> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List Subject: Re: [Sip] Draft SIP agenda for IETF 71 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 26, 2008, at 3:13 PM, Hannes Tschofenig wrote: > How are you going to cover all the identity related documents? I see > only a few documents on the agenda Badly, most probably. I've suggested a breakout on e.164 identity to AD Cullen, and he is pushing back on the idea, as it has the potential to be full of sound and fury but signify nothing. It's not chartered, and it might not be productive to just get into a bunch of shouting matches. Perhaps you folks have some suggestions on how these things could be covered effectively in a meeting? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 21:56:05 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35293A6D9A; Tue, 26 Feb 2008 21:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.794 X-Spam-Level: X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqXeAZrASe6f; Tue, 26 Feb 2008 21:55:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C3F3A6D28; Tue, 26 Feb 2008 21:55:59 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075533A6D28 for ; Tue, 26 Feb 2008 21:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeK9Lt47lsnB for ; Tue, 26 Feb 2008 21:55:57 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 04A9B3A6989 for ; Tue, 26 Feb 2008 21:55:56 -0800 (PST) Received: from [192.168.1.3] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1R5tR8F019704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2008 23:55:29 -0600 Message-Id: <04F07E6B-8714-4D60-B936-A9B6D339A977@softarmor.com> From: Dean Willis To: Eric Rescorla In-Reply-To: <20080227054105.8A9DE5081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 26 Feb 2008 23:55:22 -0600 References: <47C4C85F.4050000@cisco.com> <20080227054105.8A9DE5081A@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 26, 2008, at 11:41 PM, Eric Rescorla wrote: > >> What about intellectual >> property issues? > > Yes, there are a number of patents in the field. I don't know about > these specific algorithms, but given that they post-date the > original Boneh-Franklin IBE patent, it wouldn't be surprising > if they were covered by patents. Dean? We expect to have IPR on some related material, but I don't believe it is required for the subject discussed in the draft. There are rumors that Boneh's folks have a lot of IPR in the area. ... >> I agree with Ekr that the primary advantage from a pure signature >> perspective is the ability to eliminate the fetching of the >> certificate. >> I think this is more beneficial than just 'compression'. Identity- >> Info >> presents the certificate by reference. The increasing numbers of >> NAT and >> firewalls and SBCs are making me increasingly worried that the >> ability >> to reach across the network, back to the originator, and fetch >> ANYTHING >> over http, will be really hard in SIP deployments. So there is >> value in >> eliminating this IMHO. > > Sure, but we could just shove the certificate into the message > in a new header or in the body, at which point we are talking > about compression. Moreover, there's no requirement that the > certificate be on the UAC's machine. If people care about this, > then it seems pretty likely that the CA can operate a site > which hosts your certificate for you. This is especially true > when we're talking about one certificate per domain as assumed > by RFC 4474. The real benefit is not just the elimination of cert-fetching, but the reduction of effort for cert validation. The entire validation tree is essentially encoded in the mathematics. If it works at all, the key was "good" (which doesn't say anything about whether it has been compromised and/or revoked). There's also some benefit to using time-limited identities to reduce the massive problem of CRL management. Here's a novel thing: Let's say I know your identity is sip:ekr@networkresonance.com, and that your relationship with the PKG allows you to retrieve keys for parameterized versions of that identity. I can construct a new cryptographic identity for you, perhaps "sip:ekr@networkresonance.com;ID=2009121222 " and use that to sign a message to you. You've never seen this identity before and don't yet even have the private key for it. You then go to your PKG and retrieve said key and use it to verify the message. I didn't need to check a CRL (or worry about known-text attacks, etc.) for your cert, because I in effect forced the creation of a new one. >> I must say I didn't understand how revocation works. From the >> description of the algorithm it seemed untenable. The verifier never >> needs to obtain a cert and the public key is generated statically >> from >> the identity. Once they have the private key, the sender can always >> sign >> with it, so I don't see how revocation is possible. > > The way this is done is with what's effectively short-lived > identities (you could do the same thing with short-lived > certificates) you treat the time as part of the identity. > E.g., you might be "jdrosen@cisco.com:March-April, 2008". So, > the user needs to periodically refresh his private key to match > the new identity. If the key has been revoked you don't issue > new keys. Right, that's a variation of the technique I outlined above. If one has a convention for encoding the duration into the identity, then it can be made to work very smoothly. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 22:07:05 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128A128C2EA; Tue, 26 Feb 2008 22:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuWEqD0UxXjK; Tue, 26 Feb 2008 22:07:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9B13A68F4; Tue, 26 Feb 2008 22:07:03 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226043A698F for ; Tue, 26 Feb 2008 22:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK7tumLCIi3E for ; Tue, 26 Feb 2008 22:07:02 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 2DFF33A68F4 for ; Tue, 26 Feb 2008 22:07:02 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DE8A85081A; Tue, 26 Feb 2008 22:08:46 -0800 (PST) Date: Tue, 26 Feb 2008 22:08:46 -0800 From: Eric Rescorla To: Dean Willis In-Reply-To: <04F07E6B-8714-4D60-B936-A9B6D339A977@softarmor.com> References: <47C4C85F.4050000@cisco.com> <20080227054105.8A9DE5081A@romeo.rtfm.com> <04F07E6B-8714-4D60-B936-A9B6D339A977@softarmor.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227060846.DE8A85081A@romeo.rtfm.com> Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Tue, 26 Feb 2008 23:55:22 -0600, Dean Willis wrote: > On Feb 26, 2008, at 11:41 PM, Eric Rescorla wrote: > >> I agree with Ekr that the primary advantage from a pure signature > >> perspective is the ability to eliminate the fetching of the > >> certificate. > >> I think this is more beneficial than just 'compression'. Identity- > >> Info > >> presents the certificate by reference. The increasing numbers of > >> NAT and > >> firewalls and SBCs are making me increasingly worried that the > >> ability > >> to reach across the network, back to the originator, and fetch > >> ANYTHING > >> over http, will be really hard in SIP deployments. So there is > >> value in > >> eliminating this IMHO. > > > > Sure, but we could just shove the certificate into the message > > in a new header or in the body, at which point we are talking > > about compression. Moreover, there's no requirement that the > > certificate be on the UAC's machine. If people care about this, > > then it seems pretty likely that the CA can operate a site > > which hosts your certificate for you. This is especially true > > when we're talking about one certificate per domain as assumed > > by RFC 4474. > > The real benefit is not just the elimination of cert-fetching, but the > reduction of effort for cert validation. The entire validation tree is > essentially encoded in the mathematics. If it works at all, the key > was "good" (which doesn't say anything about whether it has been > compromised and/or revoked). I'm sorry, but this is just not convincing. 1. The computational cost to do the certificate validation is trivial. 2. You have to have the code in your system to do TLS anyway. 3. The "one big KG in the sky" scheme that you describe is not one that anyone I know in the IBE world thinks is plausible. In fact, if you look at Voltage's system (see draft-ietf-smime-ibearch), they use a system where each domain has their own KG and certificates are used to authenticate the KG (full disclosure: US Patent 7017181) > There's also some benefit to using time-limited identities to reduce > the massive problem of CRL management. Which is equally possible with certificates. > Here's a novel thing: > > Let's say I know your identity is sip:ekr@networkresonance.com, and > that your relationship with the PKG allows you to retrieve keys for > parameterized versions of that identity. > > I can construct a new cryptographic identity for you, perhaps "sip:ekr@networkresonance.com;ID=2009121222 > " and use that to sign a message to you. You've never seen this > identity before and don't yet even have the private key for it. You > then go to your PKG and retrieve said key and use it to verify the > message. Yes, this is a commonly discussed in the IBE world, but it doesn't work as well with store-and-forward signature systems because the relying party has no opportunity to insist that you provide an identity of his choice. > I didn't need to check a CRL (or worry about known-text attacks, etc.) known-text attacks? What are you talking about? > for your cert, because I in effect forced the creation of a new one. And of course, this is equally compatible with cert-based systems. The reason people don't do it is it's an enormous pain. > >> I must say I didn't understand how revocation works. From the > >> description of the algorithm it seemed untenable. The verifier never > >> needs to obtain a cert and the public key is generated statically > >> from > >> the identity. Once they have the private key, the sender can always > >> sign > >> with it, so I don't see how revocation is possible. > > > > The way this is done is with what's effectively short-lived > > identities (you could do the same thing with short-lived > > certificates) you treat the time as part of the identity. > > E.g., you might be "jdrosen@cisco.com:March-April, 2008". So, > > the user needs to periodically refresh his private key to match > > the new identity. If the key has been revoked you don't issue > > new keys. > > Right, that's a variation of the technique I outlined above. > > If one has a convention for encoding the duration into the identity, > then it can be made to work very smoothly. > > -- > Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 22:11:00 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89FB28C392; Tue, 26 Feb 2008 22:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y9WOATst0LH; Tue, 26 Feb 2008 22:11:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045BB3A6963; Tue, 26 Feb 2008 22:11:00 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1AE93A6892 for ; Tue, 26 Feb 2008 22:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLnZuQmNx6FX for ; Tue, 26 Feb 2008 22:10:52 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 8BBAE3A6963 for ; Tue, 26 Feb 2008 22:10:52 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 439905081A; Tue, 26 Feb 2008 22:12:37 -0800 (PST) Date: Tue, 26 Feb 2008 22:12:36 -0800 From: Eric Rescorla To: Dean Willis In-Reply-To: <20080227060846.DE8A85081A@romeo.rtfm.com> References: <47C4C85F.4050000@cisco.com> <20080227054105.8A9DE5081A@romeo.rtfm.com> <04F07E6B-8714-4D60-B936-A9B6D339A977@softarmor.com> <20080227060846.DE8A85081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227061237.439905081A@romeo.rtfm.com> Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Tue, 26 Feb 2008 22:08:46 -0800, Eric Rescorla wrote: > > At Tue, 26 Feb 2008 23:55:22 -0600, > Dean Willis wrote: > > Here's a novel thing: > > > > Let's say I know your identity is sip:ekr@networkresonance.com, and > > that your relationship with the PKG allows you to retrieve keys for > > parameterized versions of that identity. > > > > I can construct a new cryptographic identity for you, perhaps "sip:ekr@networkresonance.com;ID=2009121222 > > " and use that to sign a message to you. You've never seen this > > identity before and don't yet even have the private key for it. You > > then go to your PKG and retrieve said key and use it to verify the > > message. > > Yes, this is a commonly discussed in the IBE world, but it doesn't > work as well with store-and-forward signature systems because the > relying party has no opportunity to insist that you provide an > identity of his choice. Oh, I should mention: what's the value of needing a new key to *verify* the message? What does that do for the sender? The relying party can simply assume the signature is valid. If the sender wants to force the recipient to have a new key, they need to encipher the whole message or require a signed receipt from the recipient. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 26 22:18:14 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC35528C3B3; Tue, 26 Feb 2008 22:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC-x+gYFY2nP; Tue, 26 Feb 2008 22:18:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E6828C318; Tue, 26 Feb 2008 22:18:13 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F2F3A6CE8 for ; Tue, 26 Feb 2008 22:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0u7Ojhktlu4V for ; Tue, 26 Feb 2008 22:18:07 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 769DC28C392 for ; Tue, 26 Feb 2008 22:18:05 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 25so1951435wfa.31 for ; Tue, 26 Feb 2008 22:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=82N/LVRsUNCxSYzVHiPTxRkinkkJ4aFqtqW5nJXkh5A=; b=uOrqKdpICB17zQvkRIn/Z9Kpv2DckZUXrkC8ksoVedtee/A7VNHBQCbu52KW6G0JitRUB346PoRgJaINfb+Kbgy9OCw+jWOtT4zvmkacYL0Qz2pbto+rUQXz5v+Z2afSKfumNFhdsXXxGOv3dFTaYtIvjG0x0K8ngxJ2OebO6G8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=GX9+R+2lQw2quKywZTpJGnjOTd6+d/io0B0n/Ryj5EGLIpdy9qJ0dMy8REj+FNRvH8rlgoAO5HcKPpSbubGi0+5VAR77dUgC5UiLkgV5682ACfPTi5LrVSnSq1Tk+FDr5QRVMpX0vBZfqOwlwgyvH74LCvok66djDH98A7O8J7Q= Received: by 10.142.215.5 with SMTP id n5mr4781874wfg.177.1204093078629; Tue, 26 Feb 2008 22:17:58 -0800 (PST) Received: by 10.143.33.20 with HTTP; Tue, 26 Feb 2008 22:17:58 -0800 (PST) Message-ID: <52db68bc0802262217m237213cdqcfcb3ecaa11ca645@mail.gmail.com> Date: Wed, 27 Feb 2008 11:47:58 +0530 From: "Sudhir Kumar Reddy" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] Query about Supported and require header in Invite X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1461591207==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1461591207== Content-Type: multipart/alternative; boundary="----=_Part_9960_15724766.1204093078657" ------=_Part_9960_15724766.1204093078657 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, Can supported header contains like timer or any other option tag without (RFC3262Tag)100rel and can require header contain rfc3262tag(100rel)? Is that mandatory INVITE request should contain supported and require header with 100rel option tag? Eg: Supported: Timer Require: 100rel The above example is ok to be in INVITE request Any response is highly appreciated. Thanks, Sudhir ------=_Part_9960_15724766.1204093078657 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

    Can supported header contains like timer or any other option tag without (RFC3262Tag)100rel and can require header contain rfc3262tag(100rel)?

    Is that mandatory INVITE request should contain supported and require header with 100rel option tag?

    Eg: Supported: Timer
        Require: 100rel
    The above example is ok to be in INVITE request

    Any response is highly appreciated.

    Thanks,
    Sudhir
    ------=_Part_9960_15724766.1204093078657-- --===============1461591207== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1461591207==-- From sip-bounces@ietf.org Tue Feb 26 22:49:41 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5B028C526; Tue, 26 Feb 2008 22:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC3KtNg0qjf4; Tue, 26 Feb 2008 22:49:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEFF28C471; Tue, 26 Feb 2008 22:49:36 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E2928C437 for ; Tue, 26 Feb 2008 22:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh1-q0+yTASm for ; Tue, 26 Feb 2008 22:49:28 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D040928C421 for ; Tue, 26 Feb 2008 22:49:27 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 27 Feb 2008 01:49:05 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 27 Feb 2008 01:49:03 -0500 From: Hadriel Kaplan To: Eric Rescorla , "sip@ietf.org" Date: Wed, 27 Feb 2008 01:47:23 -0500 Thread-Topic: [Sip] Review of draft-kupwade-sip-iba-00 Thread-Index: Ach42JyGP7MVVjB3TiScFbtmqRpFigAM4NUw Message-ID: References: <20080227003651.265505081A@romeo.rtfm.com> In-Reply-To: <20080227003651.265505081A@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "draft-kupwade-sip-iba@tools.ietf.org" Subject: Re: [Sip] Review of draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cool. So if I understand this right (and I probably don't), ignoring rfc4474 identity and IBS for a moment and instead thinking about SRTP and IBE: I could use IBE to encrypt the security-descriptions attribute value using the intended target's SIP URI as a key, and only someone owning that URI (and sharing the same KG) or the KG itself could decrypt it to learn the sec-desc cleartext to use? -hadriel p.s. the KG would actually be a problem for IBE, wouldn't it? I mean the KG can always decrypt it. (at which point they would be the Key Generator Backdoor - aka, the KGB ;) > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eric > Rescorla > Sent: Tuesday, February 26, 2008 7:37 PM > To: sip@ietf.org > Cc: draft-kupwade-sip-iba@tools.ietf.org > Subject: [Sip] Review of draft-kupwade-sip-iba-00 > > $Id: draft-kupwade-sip-iba-00-rev.txt,v 1.1 2008/02/27 00:16:00 ekr Exp $ > > SIP has seen several attempts to use cryptographic signatures > to provide data origin authentication for SIP messages: > > - RFC 3261 provided for S/MIME digital signatures by the > end-user. > - RFC 4474 provided for "Identity" signatures by an > authentication proxy. > > The RFC 3261 S/MIME scheme has seen almost no deployment. This was > generally attributed to the difficulty of users obtaining > certificates. RFC 4474 was explicitly designed to avoid end-user > certs and is comparatively new so we don't know what kind > of deployment it will see. > > This document describes an alternate mechanism using "Identity Based > Signatures". This is a little complicated to explain, but here's > the basic overview: > > In a conventional asymmetric (public key) scheme, you > generate your own key pair, consisting of a public key and > a private key. Then when someone wants to encrypt to you, > they encrypt under your public key and you decrypt with > the private key. But how do people get your public key, > and how do they know it's yours? That's what certificates > are for. A certificate, of course, is a credential that > binds your name to your public key. But this is all kind of > inconvenient if you want to encrypt to someone who you've > never talked to before, because you need to get their certificate, > which brings up directory issues. > > Identity-Based Encryption is a scheme that does without > the certificates. The idea is that you have two algorithms: > > - P(string) which converts any string into a public key > - p(string, K) which converts any string into its corresponding > private key. > > K, of course, is a secret master parameter. So, instead of > having a certificate authority you have a key generator (KG) > which knows K. KG's policy is only to issue private key > p(, K) to the owner of (this is the same > policy as the CA would have, of course). > > So, when you want to encrypt to "alice@example.com" you encrypt > to P("alice@example.com") secure in the knowledge that only > Alice could have gotten the private key. The nice thing about > this is that there is no need to have a certificate directory > because the public key is directly computable from the > SIP URI. Where this seems useful is in settings where you > want to encrypt to people you have had no prior contact > with, like e-mail. > (more on this at > http://www.rtfm.com/movabletype/archives/2003_07.html#000315). > > Unsurprisingly, IBE has a signature variant. In a conventional > public key system, when you want to sign a message you send > along [Message, Signature, Certificate]. The recipient extracts > your public key from the certificate and then verifies the > signature. In Identity Based Signatures (IBS), you can > do without the cert: the sender just send > [Message, Signature, Identity] since the receiver can compute > the public key directly from the Identity. > > It shouldn't be hard to see that this is a lot less interesting > than IBE, since pretty much by definition the verifier is > reading a message from the signer and so the signer can > include a copy of (or a reference to) his certificate. > So, all this really does is provide a bit of message compression. > > With all that in mind, this document describes how to use a > variant of Identity Based Signatures with SIP Identity. > Now, I've oversimplified a little bit, because there are > two other features it uses (neither of which are actually > that desirable). > > - "Signcryption". When Alice sends a message to Bob, she > can structure her signature so that only Bob can verify > it. This pretty clearly interacts badly with retargeting. > - Hierarchical IBS. The system I described has only one > key generator, but it's possible to use crypto to delegate > authority so that there is a central KG which delegates > "example.com" to one sub-KG and "example.org" to another. > This doesn't make a lot of sense in an RFC4474 environment > since there's only one key for any domain anyway. > > The only thing that this document really does is allow you > to avoid having to have the trivial Web site RFC 4474 requires > you to have (or contract for) to stick your certificate on. > However, when you weigh that against the fact that the number > of CAs issuing identity-based signature keys currently stands > at 0, that seems to be a pretty marginal advantage. > > -Ekr > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 00:09:24 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB4928C56F; Wed, 27 Feb 2008 00:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoTrpk-Ni6-K; Wed, 27 Feb 2008 00:09:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC1F3A6DCD; Wed, 27 Feb 2008 00:09:23 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF843A6954; Wed, 27 Feb 2008 00:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snVf3VutlUNh; Wed, 27 Feb 2008 00:09:20 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 3CAFD28C4B9; Wed, 27 Feb 2008 00:09:19 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1R88wUe013087; Wed, 27 Feb 2008 10:09:10 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 10:09:04 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 10:09:03 +0200 Received: from [172.21.40.116] (esdhcp040116.research.nokia.com [172.21.40.116]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1R892DT004050; Wed, 27 Feb 2008 10:09:02 +0200 From: Aki Niemi To: "ext sip-bounces@ietf.org" Cc: sip@ietf.org In-Reply-To: <200802262131.m1QLV7Rm008476@dragon.ariadne.com> References: <5D1A7985295922448D5550C94DE2918001636AF1@DEEXC1U01.de.lucent.com> <200709181506.l8IF6Bmp007748@dragon.ariadne.com> <1203976392.6192.88.camel@localhost> <200802262131.m1QLV7Rm008476@dragon.ariadne.com> Organization: Nokia Devices R&D Date: Wed, 27 Feb 2008 10:08:58 +0200 Message-Id: <1204099738.16881.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 27 Feb 2008 08:09:04.0013 (UTC) FILETIME=[04678BD0:01C87918] X-Nokia-AV: Clean Subject: Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On ti, 2008-02-26 at 16:31 -0500, ext sip-bounces@ietf.org wrote: > The subscriber really need not know. It is the notifier's responsibility > to keep the entity-tags unique across all of the insanely difficult SIP > routing that it may deploy in front of it. > > The notifier cannot know what routing is in front of it, because it > cannot know what URIs might route to it. Then that's bad. How does the notifier then know which PIDF to pick in presence subscriptions? > > It is not clear that there is any solution to these problems, and we > > may only be able to document that the subscriber is responsible for > > assuring that successive subscription requests are delivered to the > > same resource. > > This isn't the subscriber's problem. Moreover, I really doubt that it is > even feasible to build a system where a new subscription sent to the > same AoR will randomly reach a different notifier instance that is in no > way synchronized (as in state, entity-tag values, etc) with the other > instances. > > There is no requirement that the SUBSCRIBE was sent to an "AoR" (even > if that term was well-defined). > > It is trivial to build a system where a new subscription could go to a > place that is much different than a previous subscription: > > sip:a.example.com forwards to sip:b.example.com - I think of this as > "my call center". What I don't know is: > > sip:b.example.com uses time-of-day-based routing to forward to either > sip:c1.example.com or sip:c2.example.com - My company has outsourced > the call center to two different companies in in two different places, > one for the day shift and one for the night shift. > > sip:c1.example.com parallel-forks to sip:d1a.example.com and > sip:d1b.example.com - The day-shift call center workers are in several > locations. > > sip:c2.example.com parallel-forks to sip:d2a.example.com and > sip:d2b.example.com - And so are the night-shift call center workers. > > OK, now I send "SUBSCRIBE sip:a.example.com". Unless I know the > details of the above routing, there's no way for me to know that the > routing changes with time. Similarly, there's no way for the > notifiers at d1a.example.com, d1b.example.com, d2a.example.com, and > d2a.example.com to even know what notifiers they *might* have to > synchronize with. I agree this kind of setup presents a problem. But I also think that what we're dealing with here is not that different from the web world. There are a lot of load balancing schemes that can be used with HTTP, which result in a GET ending up in different data centers in different parts of the world at different times. What's important to note there is that if the service that is accessed via this GET needs sessions and gives out cookies, then the backend system needs to be synchronized. Otherwise, the servers will be unaware of each others cookies, and the service won't work correctly. Similarly, the backend to the SIP notifiers needs a synchronized backend, otherwise, subnot-etags won't work. Naturally, the etags just like cookies can be constructed in such a way that they contain the necessary state. Cheers, Aki _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 02:03:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54563A69E5; Wed, 27 Feb 2008 02:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpFFD9310vaf; Wed, 27 Feb 2008 02:03:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519C63A6993; Wed, 27 Feb 2008 02:03:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B2F3A695A for ; Wed, 27 Feb 2008 02:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYgJT3A1SgZW for ; Wed, 27 Feb 2008 02:03:26 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id 260A83A69E3 for ; Wed, 27 Feb 2008 02:03:24 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id i7so2941101tid.25 for ; Wed, 27 Feb 2008 02:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=swplkSgPiyN5sajIVCyQ+NtEGz0cqd4ivIlVRPWrin8=; b=kpqhS5FPY6hzxboiZ7YPh7nNV/S4D6nRrgKHpe/ycfhUuk2Sayxcfi5kVQ5bwbZJPsOluBsLzCGzV9b/tKmQejhkEEIJCp4wRBGWya0NoSsNETCnV/dVOc1o0qzUXGnjvhVhJF288CuEijC8Jz4eRbEX5k8z9mb/WR6MjBJiLDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Ope7AxQ1584y+7U1KwJhWpKmrdIIiIA4ek4o19nrlILpyYhzgM1S1tPqEAOihQHjXNmUmAUZmmPaVaUQnnBkzEevPC9akbeWqXYPPHHMG+vdbmRDHXnAixOLxYIebMJdV8v0M4xhXbc8vHgsiYl3MRP8FHuKh+syCVdlUrTw0vY= Received: by 10.150.123.16 with SMTP id v16mr2167450ybc.156.1204106595679; Wed, 27 Feb 2008 02:03:15 -0800 (PST) Received: by 10.150.143.1 with HTTP; Wed, 27 Feb 2008 02:03:15 -0800 (PST) Message-ID: <22f508c20802270203h53edb4f7ib33553d745887080@mail.gmail.com> Date: Wed, 27 Feb 2008 15:33:15 +0530 From: "PAVAN KUMAR O" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] SIPS over NAT and Firewalls X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0327456084==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0327456084== Content-Type: multipart/alternative; boundary="----=_Part_11167_28316468.1204106595661" ------=_Part_11167_28316468.1204106595661 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I am Pavan.I am working on implementing security features for SIP on a Voip enabled phone.\ 1) I am bit confused with the implementation of "sips" scheme and the necessary changes to be made in the sip headers to make them comply with sips scheme. 2) How to transport sip/sips messages over NAT or Firewall?? Any help in this regard will be greatly appreciated. Thanks & Regards Pavan Kumar O M.E Embedded Systems BITS Pilani India ------=_Part_11167_28316468.1204106595661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
    Hi all,
     
           I am Pavan.I am working on implementing security features for SIP on a Voip enabled phone.\
    1) I am bit confused with the implementation of "sips" scheme and the necessary changes to be made in the sip headers to make them comply with sips scheme.
    2) How to transport sip/sips messages over NAT or Firewall??
     
    Any help in this regard will be greatly appreciated.
     
    Thanks & Regards
    Pavan Kumar O
    M.E Embedded Systems
    BITS Pilani
    India
    ------=_Part_11167_28316468.1204106595661-- --===============0327456084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0327456084==-- From sip-bounces@ietf.org Wed Feb 27 03:20:06 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A413A6E11; Wed, 27 Feb 2008 03:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Y4nvfQq6kBq; Wed, 27 Feb 2008 03:20:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA803A69C5; Wed, 27 Feb 2008 03:20:00 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3BB3A69C5 for ; Wed, 27 Feb 2008 03:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVC6xK7j79wU for ; Wed, 27 Feb 2008 03:19:58 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 787D43A6870 for ; Wed, 27 Feb 2008 03:19:58 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1RBKREY028866; Wed, 27 Feb 2008 05:21:24 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 13:19:13 +0200 Received: from [10.144.23.25] ([10.144.23.25]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 13:19:12 +0200 Message-ID: <47C54730.5030501@nsn.com> Date: Wed, 27 Feb 2008 13:19:12 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg X-OriginalArrivalTime: 27 Feb 2008 11:19:12.0720 (UTC) FILETIME=[94861500:01C87932] X-Nokia-AV: Clean Cc: IETF SIP List Subject: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Here are some comments to the TOTE draft: 1. In the Introduction the draft mentions three general purpose mechanisms that allow a pair of agents to communicate data during a session. However it fails to name the most relevant work for this draft, which is the file transfer mechanism, an MMUSIC WG item: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-06.txt 2. Then, I believe most of what the draft proposes can be done with the above draft. For good or for bad, the file transfer mechanism does not really define a new file transfer protocol as TOTE does, but reuses the existing MSRP. 3. I don't think I have seen the requirements for this draft. So, I cannot really evaluate why the file transfer mechanism is able to meet these requirements, and I cannot evaluate if MSRP is able to meet these requirements. The requirements corresponding to the file transfer mechanism were posted way back in this draft: http://tools.ietf.org/draft/draft-isomaki-sipping-file-transfer/draft-isomaki-sipping-file-transfer-01.txt 4. Assuming that there is a need for a new protocol for transferring files between to endpoints, I would encourage to re-use existing work. In particular, the file transfer mechanism says: In principle it is possible to use the SDP extensions defined here and replace MSRP with any other similar protocol that can carry MIME objects. This kind of specification can be written as a separate document if the need arises. Essentially, such protocol should be able to be negotiated on an SDP offer/answer exchange (RFC 3264 [RFC3264]), be able to carry MIME objects between two endpoints, and use a reliable transport protocol (e.g., TCP). For what I read, TOTE will qualify for such alternative protocol, but again, we need to understand the requirements that makes the need for yet another file transfer protocol. 5. On a slightly different topic. The draft also mentions Shared Browsing. I have recently put a draft that describes how to do collaboration between endpoints, and one of the topics is Shared Browsing. The draft is this one: http://www.ietf.org/internet-drafts/draft-garcia-mmusic-sdp-collaboration-00.txt Section 4.2 discusses the topic, and proposes to use the file transfer mechanism for sending those URL objects between endpoints. 6. I've been told that in German language TOTE means DEATH, so, perhaps that name should be changed. So, all in all, I think we need more discussion on the requirements with respect existing work, and try to identify the delta that makes the need for this draft. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 03:54:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ACF428C4B7; Wed, 27 Feb 2008 03:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtt72abX-+TW; Wed, 27 Feb 2008 03:54:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33A028C2CB; Wed, 27 Feb 2008 03:54:25 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EB33A67E6 for ; Wed, 27 Feb 2008 03:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlrX-cLdDmam for ; Wed, 27 Feb 2008 03:54:23 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id B044C28C10A for ; Wed, 27 Feb 2008 03:54:22 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so1865126fgg.41 for ; Wed, 27 Feb 2008 03:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=eQw/XLYF3ByQogfcDVIs6j7M2CeGHK3Cbt3vsRFmH7E=; b=RzkscTHqz7f+FKWb3cx76R0FJTsWTQ5iY7qwTr3zkLk7hHrskeWmrFKIqozW42oP47jkEW+/clSm7VU1zEt2i03lVHrjcJSXMgKvlY3BtI5w9Y+AiPCcH9wwygU317A4A3VCnj5ZQE13vki8klFJaEODlsimvVD1IXqLhuZNmb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=sI3IJIFqzvfaNZGuDH1vZvx8WQddbVEpQ1r+SedYgEVLS1/xXTCSkC+ha3Swqd8cR1nRuvVtcxz5ed2NYMu0XhhT6s30lMKPq7OmnOl8emlu/Ija5Dk6iHq+7GT+eNd7jdUxfDMZU6hxUcLzl3jtdU17HjgmcZ2knEeihsunuxk= Received: by 10.86.31.18 with SMTP id e18mr5934822fge.68.1204113255518; Wed, 27 Feb 2008 03:54:15 -0800 (PST) Received: by 10.86.83.15 with HTTP; Wed, 27 Feb 2008 03:54:15 -0800 (PST) Message-ID: <14b80930802270354p7298eb9fl48d234db539293b3@mail.gmail.com> Date: Wed, 27 Feb 2008 17:24:15 +0530 From: "Hulbut hulbut" To: "PAVAN KUMAR O" In-Reply-To: <22f508c20802270203h53edb4f7ib33553d745887080@mail.gmail.com> MIME-Version: 1.0 References: <22f508c20802270203h53edb4f7ib33553d745887080@mail.gmail.com> Cc: sip@ietf.org Subject: Re: [Sip] SIPS over NAT and Firewalls X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1377791045==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1377791045== Content-Type: multipart/alternative; boundary="----=_Part_20508_28663699.1204113255498" ------=_Part_20508_28663699.1204113255498 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Pavan, Not sure abt the 1st part of ur questions...but regarding point 2 I have some suggestions: 1) Not sure what you mean by how to transport ??....but here I assume that u r concerned about how the packets will be seen in the REAL world. There are several options a) Clients can have STUN support, which will make clients transparent of any NAT traversal b) Proxies can be sip-outbound-draft compliant...this will take care of routing based on actuall src IP:Port overriding 3261 based approach (routing request based on Contact/Route hdr etc ..). c) Your network can have a ALG , just outside NAT box.....this ALG needs to be SIP aware and should do all the header re-writings. Unfortunately no standard exists as such ..but some googling may help rgds Hul On Wed, Feb 27, 2008 at 3:33 PM, PAVAN KUMAR O wrote: > Hi all, > > I am Pavan.I am working on implementing security features for SIP > on a Voip enabled phone.\ > 1) I am bit confused with the implementation of "sips" scheme and the > necessary changes to be made in the sip headers to make them comply with > sips scheme. > 2) How to transport sip/sips messages over NAT or Firewall?? > > Any help in this regard will be greatly appreciated. > > Thanks & Regards > Pavan Kumar O > M.E Embedded Systems > BITS Pilani > India > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_20508_28663699.1204113255498 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Pavan,

    Not sure abt the 1st part of ur questions...but regarding point 2 I have some suggestions:
    1) Not sure what you mean by how to transport ??....but here I assume that u r concerned about how the packets will be seen in the REAL world. There are several options
    a) Clients can have STUN support, which will make clients transparent of any NAT traversal
    b) Proxies can be sip-outbound-draft compliant...this will take care of routing based on actuall src IP:Port overriding 3261 based approach (routing request based on Contact/Route hdr etc ..).
    c) Your network can have a ALG , just outside NAT box.....this ALG needs to be SIP aware and should do all the header re-writings. Unfortunately no standard exists as such ..but some googling may help

    rgds
      Hul

    On Wed, Feb 27, 2008 at 3:33 PM, PAVAN KUMAR O <acdcpavan@gmail.com> wrote:
    Hi all,
     
           I am Pavan.I am working on implementing security features for SIP on a Voip enabled phone.\
    1) I am bit confused with the implementation of "sips" scheme and the necessary changes to be made in the sip headers to make them comply with sips scheme.
    2) How to transport sip/sips messages over NAT or Firewall??
     
    Any help in this regard will be greatly appreciated.
     
    Thanks & Regards
    Pavan Kumar O
    M.E Embedded Systems
    BITS Pilani
    India

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

    ------=_Part_20508_28663699.1204113255498-- --===============1377791045== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1377791045==-- From sip-bounces@ietf.org Wed Feb 27 04:04:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06FB28C7B2; Wed, 27 Feb 2008 04:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRI2Ych6Nf2U; Wed, 27 Feb 2008 04:04:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3B528C4B9; Wed, 27 Feb 2008 04:04:39 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A72328C4C6 for ; Wed, 27 Feb 2008 04:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csUZfkRBugLq for ; Wed, 27 Feb 2008 04:04:37 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 3FE0328C5D1 for ; Wed, 27 Feb 2008 04:04:37 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1204113869!50633691!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 12574 invoked from network); 27 Feb 2008 12:04:29 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-119.messagelabs.com with SMTP; 27 Feb 2008 12:04:29 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m1RC4TM8018482 for ; Wed, 27 Feb 2008 05:04:29 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m1RC4SF3000686 for ; Wed, 27 Feb 2008 06:04:28 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m1RC4QSw000657 for ; Wed, 27 Feb 2008 06:04:27 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 20:04:24 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0544FF5A@ZMY16EXM66.ds.mot.com> In-Reply-To: <22f508c20802270203h53edb4f7ib33553d745887080@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIPS over NAT and Firewalls Thread-Index: Ach5KBOJXFs/0P1bSxGZR9H5AmxRZwAEMnag From: "Avasarala Ranjit-A20990" To: "PAVAN KUMAR O" , X-CFilter-Loop: Reflected Subject: Re: [Sip] SIPS over NAT and Firewalls X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1952976877==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1952976877== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87938.E546349E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87938.E546349E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi Pavan =20 For question 1) implementing sips means implementing TLS. So the SIP stack would use SIP over TLS/TCP or DTLS over UDP. Then the URI would be sips: Refer to RFC 3261 for more details about which flags / headers need to changed. I think transportation of either sip or sips messages over NAT/Firewall remains almost same. For more details on SIP over NAT refer to RFC 3489 which explains STUN (Simple Traversal of Udp over NAT). =20 Regards=20 Ranjit=20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of PAVAN KUMAR O Sent: Wednesday, February 27, 2008 3:33 PM To: sip@ietf.org Subject: [Sip] SIPS over NAT and Firewalls Hi all, =20 I am Pavan.I am working on implementing security features for SIP on a Voip enabled phone.\ 1) I am bit confused with the implementation of "sips" scheme and the necessary changes to be made in the sip headers to make them comply with sips scheme. 2) How to transport sip/sips messages over NAT or Firewall?? =20 Any help in this regard will be greatly appreciated. =20 Thanks & Regards Pavan Kumar O M.E Embedded Systems BITS Pilani India ------_=_NextPart_001_01C87938.E546349E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hi Pavan
     
    For question 1) implementing sips means = implementing TLS.=20 So the SIP stack would use SIP over TLS/TCP or DTLS over UDP. Then the = URI would=20 be sips: Refer to RFC 3261 for more details about which flags / headers = need to=20 changed.
    I think transportation of either sip or sips = messages over=20 NAT/Firewall remains almost same. For more details on SIP over NAT refer = to RFC=20 3489 which explains STUN (Simple Traversal of Udp over = NAT).
     

    Regards=20
    Ranjit=20

     

    From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of PAVAN KUMAR = O
    Sent:=20 Wednesday, February 27, 2008 3:33 PM
    To:=20 sip@ietf.org
    Subject: [Sip] SIPS over NAT and=20 Firewalls

    Hi all,
     
           I am Pavan.I am working on=20 implementing security features for SIP on a Voip enabled phone.\
    1) I am bit confused with the implementation of "sips" scheme and = the=20 necessary changes to be made in the sip headers to make them comply with = sips=20 scheme.
    2) How to transport sip/sips messages over NAT or Firewall??
     
    Any help in this regard will be greatly appreciated.
     
    Thanks & Regards
    Pavan Kumar O
    M.E Embedded Systems
    BITS Pilani
    India
    ------_=_NextPart_001_01C87938.E546349E-- --===============1952976877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1952976877==-- From sip-bounces@ietf.org Wed Feb 27 05:41:47 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31AB28C740; Wed, 27 Feb 2008 05:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.328 X-Spam-Level: X-Spam-Status: No, score=0.328 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv6SNpsASdcp; Wed, 27 Feb 2008 05:41:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F282A28C2A0; Wed, 27 Feb 2008 05:41:41 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8ED93A6A1A for ; Wed, 27 Feb 2008 05:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzXMhwRD7A8H for ; Wed, 27 Feb 2008 05:41:39 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id E17753A692F for ; Wed, 27 Feb 2008 05:41:38 -0800 (PST) Received: from [24.73.151.85] (account dyork HELO [150.168.1.121]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28244348; Wed, 27 Feb 2008 13:41:28 +0000 In-Reply-To: <47C1ECC8.50305@cisco.com> References: <47C1ECC8.50305@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <208BA572-92AF-4392-A926-5FCF68742A5A@voxeo.com> From: Dan York Date: Wed, 27 Feb 2008 08:40:57 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) Cc: IETF SIP List Subject: Re: [Sip] Updated hitchhikers guide X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1077758667==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1077758667== Content-Type: multipart/alternative; boundary=Apple-Mail-323-326675043 --Apple-Mail-323-326675043 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Jonathan, On Feb 24, 2008, at 5:16 PM, Jonathan Rosenberg wrote: > I just submitted an update to the hitchhikers guide: > http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers- > guide-05.txt DY> Thanks for continuing to maintain this document. I know it has been very useful for a number of people just starting to learn about SIP (they have indicated this to me some time after I referred them to it). > Here is a table I put together that indicates the number of references > in each version of this document: > > Version References > ind-00 85 > sip-00 100 > sip-01 104 > sip-02 109 > sip-03 112 > sip-04 122 > sip-05 140 > > > Quite an increase over time. DY> Quite a number! And it's no wonder that it's so hard to answer the question "how do I implement SIP?" when someone asks that. It would be fun if your table also had the dates of those various drafts to see the growth as a function of time. DY> One other suggestion - I realize it's not a *specification*, but RFC 5039 by you and Cullen about the issues around the potential of spam for SIP is one that I would add to the "security" section. While it doesn't go into detail on specific solutions, it does make people aware of the issues they need to be thinking about when implementing SIP solutions. I would suggest that RFC 5039 could be added now and then replaced later as RFCs emerge with actual solutions (or steps toward solutions). Just a thought. Thanks for your work on this, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-323-326675043 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Jonathan,

    On Feb 24, 2008, at 5:16 PM, Jonathan = Rosenberg wrote:

    I just submitted an update to = the hitchhikers guide:

    DY> Thanks for continuing to = maintain this document. =A0I know it has been very useful for a number = of people just starting to learn about SIP (they have indicated this to = me some time after I referred them to it).

    in each version of this = document:

    Version References
    ind-00 85
    = 100
    sip-01 = 104
    sip-02 = 109
    sip-03 = 112
    sip-04 = 122
    sip-05 = 140


    Quite an = increase over time.

    DY> Quite a number! =A0And = it's no wonder that it's so hard to answer the question "how do I = implement SIP?" when someone asks that. =A0It would be fun if your table = also had the dates of those various drafts to see the growth as a = function of time.

    DY> One other = suggestion - I realize it's not a *specification*, but RFC 5039 by you = and Cullen about the issues around the potential of spam for SIP is one = that I would add to the "security" section. =A0While it doesn't go into = detail on specific solutions, it does make people aware of the issues = they need to be thinking about when implementing SIP solutions. =A0I = would suggest that RFC 5039 could be added now and then replaced later = as RFCs emerge with actual solutions (or steps toward solutions). =A0Just = a thought.

    Thanks for your work on = this,
    Dan

    --=A0
    Dan York, = CISSP, Director of Emerging Communication Technology
    Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
    Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

    Bring your web applications to the phone.



    =

    = --Apple-Mail-323-326675043-- --===============1077758667== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1077758667==-- From sip-bounces@ietf.org Wed Feb 27 06:13:20 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CCE13A69D6; Wed, 27 Feb 2008 06:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOv7xGVg16kb; Wed, 27 Feb 2008 06:13:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235F63A6D84; Wed, 27 Feb 2008 06:13:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9167D28C31E for ; Wed, 27 Feb 2008 06:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ps+YsvMtzUr for ; Wed, 27 Feb 2008 06:13:02 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id EF91F3A6D84 for ; Wed, 27 Feb 2008 06:12:46 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2C3025081A; Wed, 27 Feb 2008 06:14:31 -0800 (PST) Date: Wed, 27 Feb 2008 06:14:31 -0800 From: Eric Rescorla To: Hadriel Kaplan In-Reply-To: References: <20080227003651.265505081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227141431.2C3025081A@romeo.rtfm.com> Cc: "sip@ietf.org" , "draft-kupwade-sip-iba@tools.ietf.org" Subject: Re: [Sip] Review of draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Wed, 27 Feb 2008 01:47:23 -0500, Hadriel Kaplan wrote: > > Cool. So if I understand this right (and I probably don't), > ignoring rfc4474 identity and IBS for a moment and instead thinking > about SRTP and IBE: I could use IBE to encrypt the > security-descriptions attribute value using the intended target's > SIP URI as a key, and only someone owning that URI (and sharing the > same KG) or the KG itself could decrypt it to learn the sec-desc > cleartext to use? Yeah. This is how Voltage's email system works. (Seriously, read the blog post I pointed at, whcih explains all this). But of course this doesn't work correctly with a bunch of retargeting scenarios. This is basically orthogonal to MIKEY RSA mdoe, except that instead of doing certificate retrieval you need to do parameter retrieval, and only once for the domain. Another sort-of-weird feature here is that you can encrypt to someone who hasn't registered with the system, and then they can register *afterward*. That works with email but of course is too slow for VoIP. > -hadriel p.s. the KG would actually be a problem for IBE, wouldn't > it? I mean the KG can always decrypt it. (at which point they would > be the Key Generator Backdoor - aka, the KGB ;) Yeah. This feature is generally referred to as "escrow" and is one of the reasons why people don't want to have a single global KG. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 07:43:30 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AE428C739; Wed, 27 Feb 2008 07:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.383 X-Spam-Level: X-Spam-Status: No, score=0.383 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 590wZlsdY-hU; Wed, 27 Feb 2008 07:43:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A1228C31F; Wed, 27 Feb 2008 07:43:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624133A6E18 for ; Wed, 27 Feb 2008 07:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRQwoy5Xa2PA for ; Wed, 27 Feb 2008 07:43:17 -0800 (PST) Received: from web65516.mail.ac4.yahoo.com (web65516.mail.ac4.yahoo.com [76.13.9.60]) by core3.amsl.com (Postfix) with SMTP id AB4A928C5F7 for ; Wed, 27 Feb 2008 07:43:15 -0800 (PST) Received: (qmail 38647 invoked by uid 60001); 27 Feb 2008 15:43:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=o1Vbh9+uwAvwcILMugu64FOov06Jan9GvyF0sCNXApEciR3Q/+AlQ2QxfqEXETvOKD+nirQLOLPCoZwX2XT7SU+6YBounEtcD5wMppeobM33RcwwTHlwjdqai0UtFWh/Uxs5xTOTWZR6JAjWxv1phhct/NblcXxPh6UU2IWO2Kk=; X-YMail-OSG: Rjc6Y4YVM1l5vdCJV2hpIB4Igs_8Di4NpYNYnd5iOIQiifiz8POBsHbTd1fp868.K9L1NoW1o3hxJ7bV.aHOonjhDpp_OtGenMprhwdT7ElD61bBykSqTw8D80i_BA-- Received: from [70.250.198.218] by web65516.mail.ac4.yahoo.com via HTTP; Wed, 27 Feb 2008 07:43:08 PST Date: Wed, 27 Feb 2008 07:43:08 -0800 (PST) From: Harsh Kupwade To: sip@ietf.org In-Reply-To: <20080227141431.2C3025081A@romeo.rtfm.com> MIME-Version: 1.0 Message-ID: <729836.33399.qm@web65516.mail.ac4.yahoo.com> Subject: Re: [Sip] Review of draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1728271089==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1728271089== Content-Type: multipart/alternative; boundary="0-990955665-1204126988=:33399" Content-Transfer-Encoding: 8bit --0-990955665-1204126988=:33399 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Key escrow problem has been tackled using B. Lee et. al’s algorithm. They propose a single Private key generator who would perform the identity check and multiple KPAs (Key Privacy Authorities) who would distribute the partial private key. Lee, B., Boyd, C., Dawson, E., Kim, K., Yang, J. and Yoo, S., "Secure Key Issuing in ID-based Cryptography," in Conferences in Research and Practice in Information Technology, 2004, vol. 32, pp. 69-74. Eric Rescorla wrote: At Wed, 27 Feb 2008 01:47:23 -0500, Hadriel Kaplan wrote: > > Cool. So if I understand this right (and I probably don't), > ignoring rfc4474 identity and IBS for a moment and instead thinking > about SRTP and IBE: I could use IBE to encrypt the > security-descriptions attribute value using the intended target's > SIP URI as a key, and only someone owning that URI (and sharing the > same KG) or the KG itself could decrypt it to learn the sec-desc > cleartext to use? Yeah. This is how Voltage's email system works. (Seriously, read the blog post I pointed at, whcih explains all this). But of course this doesn't work correctly with a bunch of retargeting scenarios. This is basically orthogonal to MIKEY RSA mdoe, except that instead of doing certificate retrieval you need to do parameter retrieval, and only once for the domain. Another sort-of-weird feature here is that you can encrypt to someone who hasn't registered with the system, and then they can register *afterward*. That works with email but of course is too slow for VoIP. > -hadriel p.s. the KG would actually be a problem for IBE, wouldn't > it? I mean the KG can always decrypt it. (at which point they would > be the Key Generator Backdoor - aka, the KGB ;) Yeah. This feature is generally referred to as "escrow" and is one of the reasons why people don't want to have a single global KG. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. --0-990955665-1204126988=:33399 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    Key escrow problem has been tackled using B. Lee et. al’s algorithm.  They propose a single Private key generator who would perform the identity check and multiple KPAs (Key Privacy Authorities) who would distribute the partial private key.
    Lee, B., Boyd, C., Dawson, E., Kim, K., Yang, J. and Yoo, S.,   "Secure Key Issuing in ID-based Cryptography," in Conferences in   Research and Practice in Information Technology, 2004, vol. 32, pp. 69-74.


    Eric Rescorla <ekr@networkresonance.com> wrote:
    At Wed, 27 Feb 2008 01:47:23 -0500,
    Hadriel Kaplan wrote:
    >
    > Cool. So if I understand this right (and I probably don't),
    > ignoring rfc4474 identity and IBS for a moment and instead thinking
    > about SRTP and IBE: I could use IBE to encrypt the
    > security-descriptions attribute value using the intended target's
    > SIP URI as a key, and only someone owning that URI (and sharing the
    > same KG) or the KG itself could decrypt it to learn the sec-desc
    > cleartext to use?

    Yeah. This is how Voltage's email system works. (Seriously,
    read the blog post I pointed at, whcih explains all this).
    But of course this doesn't work correctly with a bunch of
    retargeting scenarios. This is basically orthogonal to
    MIKEY RSA mdoe, except that instead of doing certificate
    retrieval you need to do parameter retrieval, and only
    once for the domain.

    Another sort-of-weird feature here is that you can encrypt to
    someone who hasn't registered with the system, and then
    they can register *afterward*. That works with email but
    of course is too slow for VoIP.


    > -hadriel p.s. the KG would actually be a problem for IBE, wouldn't
    > it? I mean the KG can always decrypt it. (at which point they would
    > be the Key Generator Backdoor - aka, the KGB ;)

    Yeah. This feature is generally referred to as "escrow" and is
    one of the reasons why people don't want to have a single
    global KG.

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

    Looking for last minute shopping deals? Find them fast with Yahoo! Search. --0-990955665-1204126988=:33399-- --===============1728271089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1728271089==-- From sip-bounces@ietf.org Wed Feb 27 08:03:57 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7266028C777; Wed, 27 Feb 2008 08:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK72NyQqealO; Wed, 27 Feb 2008 08:03:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B5E3A6C52; Wed, 27 Feb 2008 08:03:48 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C06128C3DB for ; Wed, 27 Feb 2008 08:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXVcGavPGyrg for ; Wed, 27 Feb 2008 08:03:42 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C363A28C3DD for ; Wed, 27 Feb 2008 08:02:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,413,1199692800"; d="scan'208";a="14992860" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 27 Feb 2008 08:02:22 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1RG2MAT010475; Wed, 27 Feb 2008 08:02:22 -0800 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 m1RG2MDN000324; Wed, 27 Feb 2008 16:02:22 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 08:02:22 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.92.108]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 08:02:21 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 10:02:21 -0600 To: Eric Rescorla , Jonathan Rosenberg From: "James M. Polk" In-Reply-To: <20080227054105.8A9DE5081A@romeo.rtfm.com> References: <47C4C85F.4050000@cisco.com> <20080227054105.8A9DE5081A@romeo.rtfm.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 27 Feb 2008 16:02:21.0772 (UTC) FILETIME=[22C9B0C0:01C8795A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1076; t=1204128142; x=1204992142; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-kupwade-s ip-iba-00 |Sender:=20; bh=sy2Gkh46CV6cP4jgp10hiclirajvL2Xd6Izf70JLnr4=; b=In2ap6WIvnkADmO2o0co5Gf5qjxO+opUBhWGeiebYE5ieUU/Jm7qj0vxlx wDHI/M2cVrIu53fYdjrp26F7s8d5wQB7DEYGQ26pjQTWl4NfQ1Tp3kalgTsP zMgKUS6cz4V/I1XfuFHjAdYB/JXcUPGUEL0xC4Xmq96Sul+J2wPR0=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 11:41 PM 2/26/2008, Eric Rescorla wrote: > > I must say I didn't understand how revocation works. From the > > description of the algorithm it seemed untenable. The verifier never > > needs to obtain a cert and the public key is generated statically from > > the identity. Once they have the private key, the sender can always sign > > with it, so I don't see how revocation is possible. > >The way this is done is with what's effectively short-lived >identities (you could do the same thing with short-lived >certificates) you treat the time as part of the identity. >E.g., you might be "jdrosen@cisco.com:March-April, 2008". So, >the user needs to periodically refresh his private key to match >the new identity. If the key has been revoked you don't issue >new keys. naive question what burden does this put on a peer (or all peers) to (conceivably) have to constantly discover JDR's public key, for example (because they don't know how long the private key is good for)? Or is this problem known/expected or solved easily already? >-Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 08:04:46 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB8328C1DA; Wed, 27 Feb 2008 08:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7PFQrnKsrEo; Wed, 27 Feb 2008 08:04:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE00B28C742; Wed, 27 Feb 2008 08:04:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5C03A69D6 for ; Wed, 27 Feb 2008 08:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWc+h3myQaYf for ; Wed, 27 Feb 2008 08:04:18 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 577A528C7BA for ; Wed, 27 Feb 2008 08:04:09 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 1EFA95081A; Wed, 27 Feb 2008 08:05:54 -0800 (PST) Date: Wed, 27 Feb 2008 08:05:54 -0800 From: Eric Rescorla To: Harsh Kupwade In-Reply-To: <729836.33399.qm@web65516.mail.ac4.yahoo.com> References: <20080227141431.2C3025081A@romeo.rtfm.com> <729836.33399.qm@web65516.mail.ac4.yahoo.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227160554.1EFA95081A@romeo.rtfm.com> Cc: sip@ietf.org Subject: Re: [Sip] Review of draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Wed, 27 Feb 2008 07:43:08 -0800 (PST), Harsh Kupwade wrote: > = > [1 ] > Key escrow problem has been tackled using B. Lee et. al=92s > algorithm. They propose a single Private key generator who would > perform the identity check and multiple KPAs (Key Privacy > Authorities) who would distribute the partial private key. Lee, B., > Boyd, C., Dawson, E., Kim, K., Yang, J. and Yoo, S., "Secure Key > Issuing in ID-based Cryptography," in Conferences in Research and > Practice in Information Technology, 2004, vol. 32, pp. 69-74. I don't see how this really solves the problem. Obviously, at a large cost you can have multiple KGs such that all of them need to cheat in order to recover the message content, but that doesn't really solve the problem. As the paper you cite indicates, lawful intercept can be performed by subpoenaing all the KGs. Now, I'm not saying that escrow is necessarily bad, but that just that this doesn't remove it. -Ekr > Eric Rescorla wrote: At Wed, 27 Feb 2008 01:4= 7:23 -0500, > Hadriel Kaplan wrote: > > = > > Cool. So if I understand this right (and I probably don't), > > ignoring rfc4474 identity and IBS for a moment and instead thinking > > about SRTP and IBE: I could use IBE to encrypt the > > security-descriptions attribute value using the intended target's > > SIP URI as a key, and only someone owning that URI (and sharing the > > same KG) or the KG itself could decrypt it to learn the sec-desc > > cleartext to use? > = > Yeah. This is how Voltage's email system works. (Seriously, > read the blog post I pointed at, whcih explains all this). > But of course this doesn't work correctly with a bunch of > retargeting scenarios. This is basically orthogonal to > MIKEY RSA mdoe, except that instead of doing certificate > retrieval you need to do parameter retrieval, and only > once for the domain. > = > Another sort-of-weird feature here is that you can encrypt to > someone who hasn't registered with the system, and then > they can register *afterward*. That works with email but > of course is too slow for VoIP. > = > = > > -hadriel p.s. the KG would actually be a problem for IBE, wouldn't > > it? I mean the KG can always decrypt it. (at which point they would > > be the Key Generator Backdoor - aka, the KGB ;) > = > Yeah. This feature is generally referred to as "escrow" and is > one of the reasons why people don't want to have a single = > global KG. > = > -Ekr > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > = > = > = > --------------------------------- > Looking for last minute shopping deals? Find them fast with Yahoo! Searc= h. > [2 ] > = _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 08:11:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD27028C814; Wed, 27 Feb 2008 08:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLo5dHC4GIhL; Wed, 27 Feb 2008 08:11:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A56328C862; Wed, 27 Feb 2008 08:10:54 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DBA3A6DE4 for ; Wed, 27 Feb 2008 08:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCtqsCb94V99 for ; Wed, 27 Feb 2008 08:10:44 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 35F8228C8CD for ; Wed, 27 Feb 2008 08:09:20 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DBE635081A; Wed, 27 Feb 2008 08:11:04 -0800 (PST) Date: Wed, 27 Feb 2008 08:11:04 -0800 From: Eric Rescorla To: "James M. Polk" In-Reply-To: References: <47C4C85F.4050000@cisco.com> <20080227054105.8A9DE5081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227161104.DBE635081A@romeo.rtfm.com> Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Wed, 27 Feb 2008 10:02:21 -0600, James M. Polk wrote: > > At 11:41 PM 2/26/2008, Eric Rescorla wrote: > > > I must say I didn't understand how revocation works. From the > > > description of the algorithm it seemed untenable. The verifier never > > > needs to obtain a cert and the public key is generated statically from > > > the identity. Once they have the private key, the sender can always sign > > > with it, so I don't see how revocation is possible. > > > >The way this is done is with what's effectively short-lived > >identities (you could do the same thing with short-lived > >certificates) you treat the time as part of the identity. > >E.g., you might be "jdrosen@cisco.com:March-April, 2008". So, > >the user needs to periodically refresh his private key to match > >the new identity. If the key has been revoked you don't issue > >new keys. > > naive question > > what burden does this put on a peer (or all peers) to (conceivably) > have to constantly discover JDR's public key, for example (because > they don't know how long the private key is good for)? > > Or is this problem known/expected or solved easily already? Well, the feature of IBE schemes is that once you have the public parameters for the KG, you can compute the public key without fetching further data from the CA/KG. This is a lot more interesting for encryption than it is for signature, since, as I said, you can force the signer to just send you a new certificate, so the retrieval cost is minimized. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 08:30:47 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305B328C84A; Wed, 27 Feb 2008 08:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.436 X-Spam-Level: X-Spam-Status: No, score=0.436 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XeLX8egKzeK; Wed, 27 Feb 2008 08:30:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B42D28C8C2; Wed, 27 Feb 2008 08:30:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CCB28C819 for ; Wed, 27 Feb 2008 08:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvOaczJfctsv for ; Wed, 27 Feb 2008 08:30:25 -0800 (PST) Received: from web65505.mail.ac4.yahoo.com (web65505.mail.ac4.yahoo.com [76.13.9.49]) by core3.amsl.com (Postfix) with SMTP id 039C528C8C2 for ; Wed, 27 Feb 2008 08:30:19 -0800 (PST) Received: (qmail 98816 invoked by uid 60001); 27 Feb 2008 16:30:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=iSOLyiR/Y7Bt8W713XcsfJ2NoLpXO//a72mwBc5nmNiTK6oXk1CxIMeOvII6soiPUAYnJzv1iJv/IU+pIhEbzgbF1g4wFkMx6XPfH46rW96uXzP2yCOeQZjB/kMxGm1k5zCuJNp7icldk+8mElqnJ4HAf1FiyAtv7WOAgJ8xKYE=; X-YMail-OSG: 7MYUyskVM1nFF_kO0M88rJWKSyKmvvybQbxZPguX Received: from [70.250.198.218] by web65505.mail.ac4.yahoo.com via HTTP; Wed, 27 Feb 2008 08:30:11 PST Date: Wed, 27 Feb 2008 08:30:11 -0800 (PST) From: Harsh Kupwade To: sip@ietf.org In-Reply-To: <20080227161104.DBE635081A@romeo.rtfm.com> MIME-Version: 1.0 Message-ID: <355583.98265.qm@web65505.mail.ac4.yahoo.com> Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0556007639==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0556007639== Content-Type: multipart/alternative; boundary="0-1270268829-1204129811=:98265" Content-Transfer-Encoding: 8bit --0-1270268829-1204129811=:98265 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Forcing a signer to send a certificate is fine, but if the signer’s root CA is not same as the receiver’s root CAs, then the receiver has to go through a complex path construction process which is not a trivial problem. Diana Berbecaru, Antonio Lioy and Marius Marian “On the Complexity of Public-Key Certificate Validation” http://www.springerlink.com/content/1c77by87fcm34pp9/ Eric Rescorla wrote: At Wed, 27 Feb 2008 10:02:21 -0600, James M. Polk wrote: > > At 11:41 PM 2/26/2008, Eric Rescorla wrote: > > > I must say I didn't understand how revocation works. From the > > > description of the algorithm it seemed untenable. The verifier never > > > needs to obtain a cert and the public key is generated statically from > > > the identity. Once they have the private key, the sender can always sign > > > with it, so I don't see how revocation is possible. > > > >The way this is done is with what's effectively short-lived > >identities (you could do the same thing with short-lived > >certificates) you treat the time as part of the identity. > >E.g., you might be "jdrosen@cisco.com:March-April, 2008". So, > >the user needs to periodically refresh his private key to match > >the new identity. If the key has been revoked you don't issue > >new keys. > > naive question > > what burden does this put on a peer (or all peers) to (conceivably) > have to constantly discover JDR's public key, for example (because > they don't know how long the private key is good for)? > > Or is this problem known/expected or solved easily already? Well, the feature of IBE schemes is that once you have the public parameters for the KG, you can compute the public key without fetching further data from the CA/KG. This is a lot more interesting for encryption than it is for signature, since, as I said, you can force the signer to just send you a new certificate, so the retrieval cost is minimized. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-1270268829-1204129811=:98265 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    Forcing a signer to send a certificate is fine, but if the signer’s root CA is not same as the receiver’s root CAs, then the receiver has to go through a complex path construction process which is not a trivial problem.
    Diana Berbecaru, Antonio Lioy and Marius Marian “On the Complexity of Public-Key Certificate Validation”
     
    http://www.springerlink.com/content/1c77by87fcm34pp9/


    Eric Rescorla <ekr@networkresonance.com> wrote:
    At Wed, 27 Feb 2008 10:02:21 -0600,
    James M. Polk wrote:
    >
    > At 11:41 PM 2/26/2008, Eric Rescorla wrote:
    > > > I must say I didn't understand how revocation works. From the
    > > > description of the algorithm it seemed untenable. The verifier never
    > > > needs to obtain a cert and the public key is generated statically from
    > > > the identity. Once they have the private key, the sender can always sign
    > > > with it, so I don't see how revocation is possible.
    > >
    > >The way this is done is with what's effectively short-lived
    > >identities (you could do the same thing with short-lived
    > >certificates) you treat the time as part of the identity.
    > >E.g., you might be "jdrosen@cisco.com:March-April, 2008". So,
    > >the user needs to periodically refresh his private key to match
    > >the new identity. If the key has been revoked you don't issue
    > >new keys.
    >
    > naive question
    >
    > what burden does this put on a peer (or all peers) to (conceivably)
    > have to constantly discover JDR's public key, for example (because
    > they don't know how long the private key is good for)?
    >
    > Or is this problem known/expected or solved easily already?

    Well, the feature of IBE schemes is that once you have the public
    parameters for the KG, you can compute the public key without
    fetching further data from the CA/KG. This is a lot more interesting
    for encryption than it is for signature, since, as I said, you
    can force the signer to just send you a new certificate, so the
    retrieval cost is minimized.

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

    Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-1270268829-1204129811=:98265-- --===============0556007639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0556007639==-- From sip-bounces@ietf.org Wed Feb 27 08:42:25 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888CC28C930; Wed, 27 Feb 2008 08:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ejDtOZZxfTX; Wed, 27 Feb 2008 08:42:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0694B28C904; Wed, 27 Feb 2008 08:38:48 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230F628C904 for ; Wed, 27 Feb 2008 08:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkigIAOLG5xb for ; Wed, 27 Feb 2008 08:38:42 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id DD6A728C865 for ; Wed, 27 Feb 2008 08:37:15 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8BD695081A; Wed, 27 Feb 2008 08:39:00 -0800 (PST) Date: Wed, 27 Feb 2008 08:39:00 -0800 From: Eric Rescorla To: Harsh Kupwade In-Reply-To: <355583.98265.qm@web65505.mail.ac4.yahoo.com> References: <20080227161104.DBE635081A@romeo.rtfm.com> <355583.98265.qm@web65505.mail.ac4.yahoo.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227163900.8BD695081A@romeo.rtfm.com> Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Wed, 27 Feb 2008 08:30:11 -0800 (PST), Harsh Kupwade wrote: > Forcing a signer to send a certificate is fine, but if the > signer=92s root CA is not same as the receiver=92s root CAs, then > the receiver has to go through a complex path construction process > which is not a trivial problem. Huh? The entire Web security system operates on the principle that you can verify certificates from random CAs. This has not turned out to be a serious problem in practice. Moreover, *exactly* the same problem exists wrt the KG in identity-based systems. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 09:03:01 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6C328C96D; Wed, 27 Feb 2008 09:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.409 X-Spam-Level: X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p4tC-QTbfe5; Wed, 27 Feb 2008 09:02:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EAB28C8D4; Wed, 27 Feb 2008 09:00:49 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CF128C8F3 for ; Wed, 27 Feb 2008 09:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osUJqZoLKDOd for ; Wed, 27 Feb 2008 09:00:46 -0800 (PST) Received: from web65510.mail.ac4.yahoo.com (web65510.mail.ac4.yahoo.com [76.13.9.54]) by core3.amsl.com (Postfix) with SMTP id A493C28C975 for ; Wed, 27 Feb 2008 08:59:18 -0800 (PST) Received: (qmail 80145 invoked by uid 60001); 27 Feb 2008 16:59:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nbpIrJ22nF4KqlU/5l9gubOGT9YSNweELDEJkogIF8xCvN8oNZat/6brMCKFYEJXk+UwxGUZ0mVcXN2BzU4WaQNTl+C/HKcQ/CcOKAI7yEgxqcfpzfsEkkwRTd4kCe5FGSCt17itJXLmjDVrZUV+m/7xoxANMFVoNNmuMWZy930=; X-YMail-OSG: AlBWgI0VM1l.H3913JqdONqASRK3eQm8IqcDcFdVgmx20SIUMETod8KhYW.pDkGidoWSfIZ1Hg742KErcaSCgSfKsw0UkEZRwMQT9rQAMV9KvdCaFvOe9hl2qt7QbA-- Received: from [70.250.198.218] by web65510.mail.ac4.yahoo.com via HTTP; Wed, 27 Feb 2008 08:59:10 PST Date: Wed, 27 Feb 2008 08:59:10 -0800 (PST) From: Harsh Kupwade To: sip@ietf.org In-Reply-To: <20080227163900.8BD695081A@romeo.rtfm.com> MIME-Version: 1.0 Message-ID: <159863.80038.qm@web65510.mail.ac4.yahoo.com> Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0484222821==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0484222821== Content-Type: multipart/alternative; boundary="0-188473342-1204131550=:80038" Content-Transfer-Encoding: 8bit --0-188473342-1204131550=:80038 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit How can we verify a certificate from a random CA? It will definitely be a serious threat in the near future. Self signed certificates are not very reliable either. A malicious KG is equivalent to a malicious CA. A malicious CA can also tag a public key to a different user and pose the same threat level. Eric Rescorla wrote: At Wed, 27 Feb 2008 08:30:11 -0800 (PST), Harsh Kupwade wrote: > Forcing a signer to send a certificate is fine, but if the > signer’s root CA is not same as the receiver’s root CAs, then > the receiver has to go through a complex path construction process > which is not a trivial problem. Huh? The entire Web security system operates on the principle that you can verify certificates from random CAs. This has not turned out to be a serious problem in practice. Moreover, *exactly* the same problem exists wrt the KG in identity-based systems. -Ekr --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-188473342-1204131550=:80038 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    How can we verify a certificate from a random CA? It will definitely be a serious threat in the near future.
     
    Self signed certificates are not very reliable either.
     
     A malicious KG is equivalent to a malicious CA. A malicious CA can also tag a public key to a different user and pose the same threat level.
     

    Eric Rescorla <ekr@networkresonance.com> wrote:
     
    At Wed, 27 Feb 2008 08:30:11 -0800 (PST),
    Harsh Kupwade wrote:
    > Forcing a signer to send a certificate is fine, but if the
    > signer’s root CA is not same as the receiver’s root CAs, then
    > the receiver has to go through a complex path construction process
    > which is not a trivial problem.

    Huh? The entire Web security system operates on the principle that you
    can verify certificates from random CAs. This has not turned out to be
    a serious problem in practice.
     


    Moreover, *exactly* the same problem exists wrt the KG in identity-based
    systems.

    -Ekr

    Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-188473342-1204131550=:80038-- --===============0484222821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0484222821==-- From sip-bounces@ietf.org Wed Feb 27 09:07:01 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E013A6E40; Wed, 27 Feb 2008 09:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9TcDCmGl+gv; Wed, 27 Feb 2008 09:06:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0EC3A6E46; Wed, 27 Feb 2008 09:06:18 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0EA3A6E46 for ; Wed, 27 Feb 2008 09:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T66TrqOQM2J for ; Wed, 27 Feb 2008 09:06:11 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 94FA73A6E4F for ; Wed, 27 Feb 2008 09:05:17 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 5A5C05081A; Wed, 27 Feb 2008 09:07:01 -0800 (PST) Date: Wed, 27 Feb 2008 09:07:01 -0800 From: Eric Rescorla To: Harsh Kupwade In-Reply-To: <159863.80038.qm@web65510.mail.ac4.yahoo.com> References: <20080227163900.8BD695081A@romeo.rtfm.com> <159863.80038.qm@web65510.mail.ac4.yahoo.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227170702.5A5C05081A@romeo.rtfm.com> Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Wed, 27 Feb 2008 08:59:10 -0800 (PST), Harsh Kupwade wrote: > > [1 ] > How can we verify a certificate from a random CA? It will definitely > be a serious threat in the near future. Uh, that the trust anchors are publicly known and compiled into your client. > A malicious KG is equivalent to a malicious CA. A malicious CA > can also tag a public key to a different user and pose the same > threat level. Yes, a malicious CA is bad. No, a malicious CA is not anywhere near as bad as a malicious KG. A malicious CA has to mount MITM attacks on all your traffic in order to decrypt. A malicious KG can passively decrypt. Again, some people view escrow as a feature, but its simply not true that the security properties of PKI-based systems are the same as those IBE-based systems. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 09:17:00 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DA828C885; Wed, 27 Feb 2008 09:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opZE3dH01vSB; Wed, 27 Feb 2008 09:16:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1017E28C7B0; Wed, 27 Feb 2008 09:16:29 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16E43A6E25 for ; Wed, 27 Feb 2008 09:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI2+GlsWt8cA for ; Wed, 27 Feb 2008 09:16:26 -0800 (PST) Received: from web65509.mail.ac4.yahoo.com (web65509.mail.ac4.yahoo.com [76.13.9.53]) by core3.amsl.com (Postfix) with SMTP id 88ADE28C4B2 for ; Wed, 27 Feb 2008 09:14:36 -0800 (PST) Received: (qmail 86731 invoked by uid 60001); 27 Feb 2008 17:14:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=qTRQX4N9kLHmow+EvXXosnNsUyTxkquHzRbAwGCmE+7yFaBOBi1XA3EVUui0QSaF+L7fpzBqb/iCEqWCVsJ0005S75wkbTkdxRmWQmyVN2uTd8APQZ7gPmGJ3E1btOTLeEkgcUpWxRpE05RZ5eJfYk9+U2NSEOGde7Slx48y5x0=; X-YMail-OSG: WYPl50AVM1kEJ97DljbB20BxoqWebxRsojQ.JIFT Received: from [70.250.198.218] by web65509.mail.ac4.yahoo.com via HTTP; Wed, 27 Feb 2008 09:14:26 PST Date: Wed, 27 Feb 2008 09:14:26 -0800 (PST) From: Harsh Kupwade To: Eric Rescorla In-Reply-To: <20080227170702.5A5C05081A@romeo.rtfm.com> MIME-Version: 1.0 Message-ID: <132324.81291.qm@web65509.mail.ac4.yahoo.com> Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500423586==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1500423586== Content-Type: multipart/alternative; boundary="0-207906687-1204132466=:81291" Content-Transfer-Encoding: 8bit --0-207906687-1204132466=:81291 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit What if the trust anchors are not complied into your client? Then verifying a digital signature is not a trivial problem. Cross certificate validation is a challenging issue? Eric Rescorla wrote: At Wed, 27 Feb 2008 08:59:10 -0800 (PST), Harsh Kupwade wrote: > > [1 ] > How can we verify a certificate from a random CA? It will definitely > be a serious threat in the near future. Uh, that the trust anchors are publicly known and compiled into your client. > A malicious KG is equivalent to a malicious CA. A malicious CA > can also tag a public key to a different user and pose the same > threat level. Yes, a malicious CA is bad. No, a malicious CA is not anywhere near as bad as a malicious KG. A malicious CA has to mount MITM attacks on all your traffic in order to decrypt. A malicious KG can passively decrypt. Again, some people view escrow as a feature, but its simply not true that the security properties of PKI-based systems are the same as those IBE-based systems. -Ekr --------------------------------- Never miss a thing. Make Yahoo your homepage. --0-207906687-1204132466=:81291 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    What if the trust anchors are not complied into your client? Then verifying a digital signature is not a trivial problem.
     
    Cross certificate validation is a challenging issue?


    Eric Rescorla <ekr@networkresonance.com> wrote:
    At Wed, 27 Feb 2008 08:59:10 -0800 (PST),
    Harsh Kupwade wrote:
    >
    > [1 ]
    > How can we verify a certificate from a random CA? It will definitely
    > be a serious threat in the near future.

    Uh, that the trust anchors are publicly known and compiled into
    your client.


    > A malicious KG is equivalent to a malicious CA. A malicious CA
    > can also tag a public key to a different user and pose the same
    > threat level.

    Yes, a malicious CA is bad.
    No, a malicious CA is not anywhere near as bad as a malicious KG.
    A malicious CA has to mount MITM attacks on all your traffic
    in order to decrypt. A malicious KG can passively decrypt.

    Again, some people view escrow as a feature, but its simply
    not true that the security properties of PKI-based systems
    are the same as those IBE-based systems.

    -Ekr

    Never miss a thing. Make Yahoo your homepage. --0-207906687-1204132466=:81291-- --===============1500423586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1500423586==-- From sip-bounces@ietf.org Wed Feb 27 09:23:47 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7AD28C9B4; Wed, 27 Feb 2008 09:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2hW7+AFX4Zo; Wed, 27 Feb 2008 09:23:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B930828C1F3; Wed, 27 Feb 2008 09:22:21 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C81D3A6C15 for ; Wed, 27 Feb 2008 09:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSk0XoGStCFH for ; Wed, 27 Feb 2008 09:22:15 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id CC2EE3A68A6 for ; Wed, 27 Feb 2008 09:17:16 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8EAE95081A; Wed, 27 Feb 2008 09:19:01 -0800 (PST) Date: Wed, 27 Feb 2008 09:19:01 -0800 From: Eric Rescorla To: Harsh Kupwade In-Reply-To: <132324.81291.qm@web65509.mail.ac4.yahoo.com> References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080227171901.8EAE95081A@romeo.rtfm.com> Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Wed, 27 Feb 2008 09:14:26 -0800 (PST), Harsh Kupwade wrote: > > [1 ] > What if the trust anchors are not complied into your client? Then > verifying a digital signature is not a trivial problem. > > Cross certificate validation is a challenging issue? Which is why nobody does it in practice in the private sector. In any case, I'm not sure why we're having this discusion since all the same trust issues apply to IBE schemes. The only respect in which they don't apply to IBE schemes is if you have a single global KG, but of course you could have a single global CA, too. It's just that nobody wants to do either. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 11:05:47 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9A228C92A; Wed, 27 Feb 2008 11:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl93iGBVw1o8; Wed, 27 Feb 2008 11:05:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23BB28C395; Wed, 27 Feb 2008 11:05:20 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470F428C32B for ; Wed, 27 Feb 2008 11:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzsfwFA7lk6E for ; Wed, 27 Feb 2008 11:05:18 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 5DD8D28C323 for ; Wed, 27 Feb 2008 11:02:20 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m1RJ1vFs025673; Wed, 27 Feb 2008 13:01:58 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 13:01:57 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 20:01:54 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 20:01:53 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001CB019C@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt Thread-index: Ach3c2lnw7o0pmZSQ6+083GFB/sVNAB/4bGQ References: <20080224054501.90B6A3A6A07@core3.amsl.com><200802250404.m1P44eZm023626@dragon.ariadne.com> From: "DRAGE, Keith \(Keith\)" To: "James M. Polk" , , X-OriginalArrivalTime: 27 Feb 2008 19:01:54.0936 (UTC) FILETIME=[38180F80:01C87973] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Rather than "for the use of" I would prefer "to meet the requirements of". The usage of any namespace is a private matter between the operator of the SIP entities, and the user. The fact that DISA requested such a set of namespaces does not reserve usage to that particular organisation. Rather it defines a particular set of priority and preemption schemes that anyone can use. Regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of James M. Polk > Sent: Monday, February 25, 2008 5:57 AM > To: Dale.Worley@comcast.net; sip@ietf.org > Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt > > At 10:04 PM 2/24/2008, Dale.Worley@comcast.net wrote: > > Title : IANA Registration of New Session > > Initiation Protocol (SIP) > > Resource-Priority Namespaces > > Author(s) : J. Polk > > Filename : > draft-ietf-sip-rph-new-namespaces-02.txt > > Pages : 7 > > Date : 2008-02-23 > > > > Abstract: > > > > This document creates additional Session Initiation Protocol > > Resource-Priority namespaces, and places these namespaces in the > > IANA register. > > > >As an editorial matter, can the abstract be made less vague? > Such as > >mentioning that it creates a set of namespaces for the use of the US > >Defense Information Systems Agency... > > well, at least I didn't overstate things... ;-) > > I can change this if you want me to > > > >Dale > >_______________________________________________ > >Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use > >sip-implementors@cs.columbia.edu for questions on current sip Use > >sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 11:16:57 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5D428C777; Wed, 27 Feb 2008 11:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61FOwBHeVDCJ; Wed, 27 Feb 2008 11:16:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4785E28C494; Wed, 27 Feb 2008 11:16:56 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572A53A6E5B for ; Wed, 27 Feb 2008 11:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp8R-j99nXQe for ; Wed, 27 Feb 2008 11:16:54 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 508293A6A81 for ; Wed, 27 Feb 2008 11:16:54 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Feb 2008 11:16:48 -0800 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 m1RJGmTG001140; Wed, 27 Feb 2008 11:16:48 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1RJGlDV018982; Wed, 27 Feb 2008 19:16:47 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:16:43 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:16:42 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 13:16:42 -0600 To: Harsh Kupwade , sip@ietf.org From: "James M. Polk" In-Reply-To: <355583.98265.qm@web65505.mail.ac4.yahoo.com> References: <20080227161104.DBE635081A@romeo.rtfm.com> <355583.98265.qm@web65505.mail.ac4.yahoo.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 27 Feb 2008 19:16:42.0746 (UTC) FILETIME=[49451DA0:01C87975] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3136; t=1204139808; x=1205003808; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-kupwade-s ip-iba-00 |Sender:=20; bh=MH9h+n+DNzoFUgekqpXVyv1MIYvYTSCHL96yFec62Co=; b=fidERTPs361YOD7gZ/qUPb4LwjxSWLissMYrQNV8eApKFgYKJRz9EWX/nX fx6snMo71M0d7nlsklVCIKkXRE3X7XsjznbC9v+QqMS8f4QIEcV76vfyS8AG durI5MXUjj; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 10:30 AM 2/27/2008, Harsh Kupwade wrote: >Forcing a signer to send a certificate is fine, but if the signer's >root CA is not same as the receiver's root CAs, then the receiver >has to go through a complex path construction process which is not a >trivial problem. I think this was what I was asking about... and it appears as if it might be a hindrance > >Diana Berbecaru, Antonio Lioy and Marius Marian "On the Complexity >of Public-Key Certificate Validation" > >http://www.springerlink.com/content/1c77by87fcm34pp9/ > > >Eric Rescorla wrote: >At Wed, 27 Feb 2008 10:02:21 -0600, >James M. Polk wrote: > > > > At 11:41 PM 2/26/2008, Eric Rescorla wrote: > > > > I must say I didn't understand how revocation works. From the > > > > description of the algorithm it seemed untenable. The verifier never > > > > needs to obtain a cert and the public key is generated statically from > > > > the identity. Once they have the private key, the sender can > always sign > > > > with it, so I don't see how revocation is possible. > > > > > >The way this is done is with what's effectively short-lived > > >identities (you could do the same thing with short-lived > > >certificates) you treat the time as part of the identity. > > >E.g., you might be "jdrosen@cisco.com:March-April, 2008". So, > > >the user needs to periodically refresh his private key to match > > >the new identity. If the key has been revoked you don't issue > > >new keys. > > > > naive question > > > > what burden does this put on a peer (or all peers) to (conceivably) > > have to constantly discover JDR's public key, for example (because > > they don't know how long the private key is good for)? > > > > Or is this problem known/expected or solved easily already? > >Well, the feature of IBE schemes is that once you have the public >parameters for the KG, you can compute the public key without >fetching further data from the CA/KG. This is a lot more interesting >for encryption than it is for signature, since, as I said, you >can force the signer to just send you a new certificate, so the >retrieval cost is minimized. > >-Ekr >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > >Be a better friend, newshound, and know-it-all with Yahoo! Mobile. >Try >it now. >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 11:19:59 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A8D28C7FE; Wed, 27 Feb 2008 11:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAGESU2L9fll; Wed, 27 Feb 2008 11:19:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2A23A6AB9; Wed, 27 Feb 2008 11:19:53 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A323A6AB9 for ; Wed, 27 Feb 2008 11:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjnahwsLee4G for ; Wed, 27 Feb 2008 11:19:50 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 10E333A6A2A for ; Wed, 27 Feb 2008 11:19:50 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Feb 2008 11:19:43 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1RJJfuw023569; Wed, 27 Feb 2008 11:19:41 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1RJJbCN001400; Wed, 27 Feb 2008 19:19:41 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:19:39 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:19:38 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 13:19:38 -0600 To: "DRAGE, Keith \(Keith\)" , , From: "James M. Polk" In-Reply-To: <5D1A7985295922448D5550C94DE2918001CB019C@DEEXC1U01.de.luce nt.com> References: <20080224054501.90B6A3A6A07@core3.amsl.com> <200802250404.m1P44eZm023626@dragon.ariadne.com> <5D1A7985295922448D5550C94DE2918001CB019C@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 27 Feb 2008 19:19:38.0558 (UTC) FILETIME=[B20FE5E0:01C87975] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2514; t=1204139982; x=1205003982; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20I-D=20Action=3Adraft-ietf-sip-r ph-new-namespaces-02.txt |Sender:=20; bh=8Wy/6YunRR8M6K0F3SQo7NW36T34M+UQoQ6tirw3KE0=; b=GYV+SfDAH+aNf+zBjEQDuruEYVQTEaFzFY2ncPwip4mRvM35HdarHCmHY2 y1jL3y+7kmciD7WefSig9q5nr8/j/6dlgrUT6yKaQxEVR2neJYonPa1+ye3c ymij7jLi4O; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 01:01 PM 2/27/2008, DRAGE, Keith \(Keith\) wrote: >Rather than "for the use of" I would prefer "to meet the requirements >of". ack >The usage of any namespace is a private matter between the operator of >the SIP entities, and the user. The fact that DISA requested such a set >of namespaces does not reserve usage to that particular organisation. >Rather it defines a particular set of priority and preemption schemes >that anyone can use. right, it doesn't prevent anyone from using the namespaces >Regards > >Keith > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of James M. Polk > > Sent: Monday, February 25, 2008 5:57 AM > > To: Dale.Worley@comcast.net; sip@ietf.org > > Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt > > > > At 10:04 PM 2/24/2008, Dale.Worley@comcast.net wrote: > > > Title : IANA Registration of New Session > > > Initiation Protocol (SIP) > > > Resource-Priority Namespaces > > > Author(s) : J. Polk > > > Filename : > > draft-ietf-sip-rph-new-namespaces-02.txt > > > Pages : 7 > > > Date : 2008-02-23 > > > > > > Abstract: > > > > > > This document creates additional Session Initiation Protocol > > > Resource-Priority namespaces, and places these namespaces in the > > > IANA register. > > > > > >As an editorial matter, can the abstract be made less vague? > > Such as > > >mentioning that it creates a set of namespaces for the use of the US > > >Defense Information Systems Agency... > > > > well, at least I didn't overstate things... ;-) > > > > I can change this if you want me to > > > > > > >Dale > > >_______________________________________________ > > >Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > >This list is for NEW development of the core SIP Protocol Use > > >sip-implementors@cs.columbia.edu for questions on current sip Use > > >sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 11:28:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C88128C84D; Wed, 27 Feb 2008 11:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.06 X-Spam-Level: X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkR9Y5uzRxsX; Wed, 27 Feb 2008 11:28:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B8A28C2CE; Wed, 27 Feb 2008 11:28:22 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B738A3A68AE for ; Wed, 27 Feb 2008 11:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLD83qfdTntW for ; Wed, 27 Feb 2008 11:28:16 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 24A1D28C1F3 for ; Wed, 27 Feb 2008 11:27:29 -0800 (PST) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1RJQLSS014185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2008 11:26:23 -0800 From: "Richard Shockey" To: "'Dean Willis'" , References: <77EA4502-7DE1-40F8-9051-8D7F965FEE56@softarmor.com> <47C480FB.8070608@gmx.net> In-Reply-To: Date: Wed, 27 Feb 2008 14:24:32 -0500 Message-ID: <05c801c87976$62a93fa0$27fbbee0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach5A509JP97snUuSECyEfxKiOA0ZwAceSNA Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'IETF SIP List' Subject: Re: [Sip] Draft SIP agenda for IETF 71 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean I agree with your underlying notion that at this point in time any discussion of the underlying problems in E164 and identity could be potentially counter productive. The RAI schedule in Philadelphia is already overbooked as it is ..It may take a separate hour or more BOF in Dublin to just scope out the problem. Its better to try and peal these issues off into some separate task group or something in order to let the rest of the SIP WG to proceed with its usual overcrowded work load. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Wednesday, February 27, 2008 12:43 AM > To: Hannes.Tschofenig@gmx.net > Cc: IETF SIP List > Subject: Re: [Sip] Draft SIP agenda for IETF 71 > > > On Feb 26, 2008, at 3:13 PM, Hannes Tschofenig wrote: > > > How are you going to cover all the identity related documents? I see > > only a few documents on the agenda > > Badly, most probably. I've suggested a breakout on e.164 identity to > AD Cullen, and he is pushing back on the idea, as it has the potential > to be full of sound and fury but signify nothing. It's not chartered, > and it might not be productive to just get into a bunch of shouting > matches. > > Perhaps you folks have some suggestions on how these things could be > covered effectively in a meeting? > > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 12:09:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C8C28C54C; Wed, 27 Feb 2008 12:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnpL5m0WfNOG; Wed, 27 Feb 2008 12:09:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D85C28C938; Wed, 27 Feb 2008 12:09:30 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA06728C8E0 for ; Wed, 27 Feb 2008 12:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc0r1WkPNQMP for ; Wed, 27 Feb 2008 12:09:27 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0C56428C85A for ; Wed, 27 Feb 2008 12:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1204142858; x=1235678858; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=Mime-Version:=201.0|Message-Id:=20|In-Reply-To:=20<47C30AC3.4090407@cisco. com>|References:=20<47B6345B.4030807@cisco.com>=0D=0A=20< p06240601c3e0e71e3fef@[129.46.226.27]>=0D=0A=20<8F90CB13- F83A-4D95-82E4-63794937E8A9@softarmor.com>=0D=0A=20=0D=0A=20=0D=0A=20<20080220214 4.m1KLi5WJ024161@dragon.ariadne.com>=0D=0A=20<47BF623C.80 20105@cisco.com>=20=0D=0A=20<47C30AC3.4090407@cisco.com>|Date:=20Wed,=2027 =20Feb=202008=2012:07:18=20-0800|To:=20Jonathan=20Rosenbe rg=20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Sip]=20New=20I-D=20-=20TOT E=20-=20"INFO"=20on=20the=20media=20path|Cc:=20"Dale.Worl ey@comcast.net"=20,=0D=0A=20=20 =20=20=20=20=20=20"sip@ietf.org"=09 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5239"=3B=20 a=3D"851264"; bh=I6vgbDkMJtQtoePVIvBnOMkYqbOIu6Nb6gZ38EbVts8=; b=Jv7i0riXX9GkK6CGEhNZDZCEC3R/ER2VYTkU4l2tYSblHg7xakqDT/3b q4/HgCR8DBtMI1Px/sOWERjewooGeoN0Nib1Oo19TL1xODf80DPMCJeMr D/LWImeX6SnvMUK1yR/UVyMvwkNzGPdJiADg+zlMBFaJExhd2onjhZoKG 0=; X-IronPort-AV: E=McAfee;i="5200,2160,5239"; a="851264" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Feb 2008 12:07:23 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1RK7KeR027387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Feb 2008 12:07:22 -0800 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1RK7Jw4006454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Feb 2008 12:07:20 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <47C30AC3.4090407@cisco.com> References: <47B6345B.4030807@cisco.com> <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> <200802202144.m1KLi5WJ024161@dragon.ariadne.com> <47BF623C.8020105@cisco.com> <47C30AC3.4090407@cisco.com> Date: Wed, 27 Feb 2008 12:07:18 -0800 To: Jonathan Rosenberg From: Ted Hardie Cc: "sip@ietf.org" Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 10:36 AM -0800 2/25/08, Jonathan Rosenberg wrote: >Ted, > >I did see your note. Dean had responded, and your response to him, I >thought, indicated that you were satisfied that having purposes >specified (which was the intent of the draft) addressed your concerns. >Sorry for having misunderstood. Some responses below: Sorry for the delay in replying. Some further questions below. >Ted Hardie wrote: >> Jonathan, >> Did you see my messages in this thread? I raised several >> issues with the approach you appear to be outlining again here, and I'm >> wondering if you saw them. To recapitulate just slightly: >> >> The negotiation model appears inadequate to deal with MIME types >> with significant parameters, with multipart MIME types, or with >> MIME types that have "bucket" semantics (like message/cpim, the >> container video types, or the 3ggp bucket mime types). > >OK; this was just a -00. There are two ways to deal with that: > >1. add the additional negotiation needed for this as new SDP parameters, or > >2. don't bother at all with MIME negotiation as part of SDP for TOTE; >rather, each purpose would have a protocol to doing the negotiations >needed to make its functionality work. This avoids needing to do a >general purpose MIME thing. FOr example, in the case of "pic", we'd >actually define a little protocol that negotiates pictures sizes and >supported types. In that applications, buckets and multiparts aren't an >issue. > >I'm inclined towards #2 actually. But note that, I put into TOTE exactly >the same level of MIME negotiation that SIP itself provides. SO if it is >grossly inadequate here, so it is there. I'd be interested in seeing more on how #2 works. One of my concerns with "pic", to take one example, is how a very generic purpose like trading images gets used by applications that want it. How does a system know when a pic being sent from one side of the TOTE exchange to the other is meant as a new user icon, an avatar for a MMORPG, or a stand-alone picture relevant to some ongoing exchange on a real time channel? If there is more interaction than just "purpose" and mime type, then re-use of this by applications that want the facility may work. Otherwise, it seems you are either going to head towards purposes like "vnd.WoW" that have no generality or you are going to get what amounts to a least-common-denominator application. The "I can send you my name" application is not really too compelling. > > >> Having a dispatch based on purpose without detailed specifications or >> reference to specific applications seems to hit a middle ground that's >> kind of nobody's sweet spot. > >That was never the intent. The IANA considerations section states that >these require specification. > >> A specific application already has detailed >> semantics that go beyond this purpose to actual decisions of whether >> to render or store, user permissions needed, sizes accepted, etc; >> generalized MIME transfer protocols like SMTP or HTTP already >> use a different system for deciding which applications to invoke >> when faced with a MIME object, and this forces systems with that >> logic to have a parallel track. > >That would seem to argue for pulling the MIME aspects out of TOTE. > >> >> The muxing seems liable to head of line blocking unless BEEP-like >> channels are introduced. > >This is discussed; if the purpose requires significant content, set it >up as a separate session/tcp connection. What you have there now is: However, if a purpose represents a significant amount of data, such that head-of-line blocking might occur between purposes, an agent SHOULD utilize a separate TOTE session for that purpose. I guess this still worries me. If an application wants to set up a TOTE connection with an existing peer, I'm guessing it will need to decide whether to re-use an exiting session or set up a new one. While it may have a sense of whether it will have large amounts of data to send, it doesn't have any idea of the sensitivity to head of line blocking from the other users of the connection. That pushes the decision into the agent which knows something about both. But that ends up requiring a lot of knowledge of the protocol usage characteristics of the using application which go beyond what TOTE will carry on the wire (some uses of "pic" with image/jpeg are really highly unlikely to cause head of line blocking; others might be a real clog). Defaulting to non-muxed connections eliminates that, of course, but removes one of the benefits you propose. > > >> This seems to re-purpose the deployed TURN servers in ways that >> transform them into a generic NAT/Firewall avoidance mechanism >> for any MIME type. You're listing that as a feature. Isn't there >> a risk that security folks will see it as a bug? > >I think you are getting wrapped up in the MIME parts of this, which is >not the main point. The main point is that there are lots of cases where >we need UA to UA communications - see: > >http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-use-cases-00.txt > >I was trying to provide a common mechanism for addressing those cases >where we don't want to send all this garbage over SIP - we want it over >the media plane. Are you objecting to that? A number of your purposes seem pretty far outside the info-use-cases draft, and the level of generality does raise issues. Maybe I am too concerned with the "generic MIME transport" aspects of this, but I think replacing INFO with a media plane solution that does not have at least the level of specificity of event packages is not helpful and may even be harmful. I'll try to corner you in Philadelphia to discuss this in person, especially on your "little protocol" proposal above. There may be an opportunity there. regards, Ted >-Jonathan R. > > >-- >Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >Cisco Fellow Edison, NJ 08837 >Cisco, Voice Technology Group >jdrosen@cisco.com >http://www.jdrosen.net PHONE: (408) 902-3084 >http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 13:25:41 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569FA3A6E40; Wed, 27 Feb 2008 13:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[AWL=-2.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_73=0.6, MANGLED_BACK=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wopJ-mmOPa2Z; Wed, 27 Feb 2008 13:25:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4723E3A6911; Wed, 27 Feb 2008 13:25:35 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02573A692F for ; Wed, 27 Feb 2008 13:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeysUQB8CfxB for ; Wed, 27 Feb 2008 13:25:27 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 541383A688B for ; Wed, 27 Feb 2008 13:25:27 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 27 Feb 2008 13:25:20 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1RLPKNR029569; Wed, 27 Feb 2008 13:25:20 -0800 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 m1RLPKCH029327; Wed, 27 Feb 2008 21:25:20 GMT 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.1830); Wed, 27 Feb 2008 13:25:19 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 13:25:18 -0800 Message-ID: <47C5D533.5090002@cisco.com> Date: Wed, 27 Feb 2008 16:25:07 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Hardie References: <47B6345B.4030807@cisco.com> <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> <200802202144.m1KLi5WJ024161@dragon.ariadne.com> <47BF623C.8020105@cisco.com> <47C30AC3.4090407@cisco.com> In-Reply-To: X-OriginalArrivalTime: 27 Feb 2008 21:25:18.0558 (UTC) FILETIME=[404097E0:01C87987] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6784; t=1204147520; x=1205011520; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20New=20I-D=20-=20TOTE=20-=20=22I NFO=22=20on=20the=20media=20path |Sender:=20; bh=77TqETgFhjTPvgbtLKxgXm619EBdnXTiwHpisHTkSAk=; b=UNHKxlHNcnm0qbK2SsWtF4MkBlE/8F844fWKEyTz3Dsy3LmJTQ3SAy8bk8 q7de/BJ3p3J82Mm1CD4jwgOIP+fyv0pohgrvjktUnKxbBkdau5zj/NyhpkPq sr8u9HGG++mCAtO2eKWBeZnJXNAakNCeg2Vmned1uHCg2Le7FEqxI=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "sip@ietf.org" Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline: Ted Hardie wrote: >> OK; this was just a -00. There are two ways to deal with that: >> >> 1. add the additional negotiation needed for this as new SDP parameters, or >> >> 2. don't bother at all with MIME negotiation as part of SDP for TOTE; >> rather, each purpose would have a protocol to doing the negotiations >> needed to make its functionality work. This avoids needing to do a >> general purpose MIME thing. FOr example, in the case of "pic", we'd >> actually define a little protocol that negotiates pictures sizes and >> supported types. In that applications, buckets and multiparts aren't an >> issue. >> >> I'm inclined towards #2 actually. But note that, I put into TOTE exactly >> the same level of MIME negotiation that SIP itself provides. SO if it is >> grossly inadequate here, so it is there. > > I'd be interested in seeing more on how #2 works. Well, I'm thinking on my feet here, but for picture sharing, something like this: A->B INVITE tote session, purpose=pic B->A 200 OK tote, purpose=pic A->B ACK A->B [TOTE] I support jpg, png. Screen resolution here is just 100x200, 8 bits color. B->A [TOTE] I support just jpg, but I have a huge screen so up to 1000x1000 is fine. 24 bits color. and then later: A->B [TOTE] Hey I'd like to send a picture, 200x200, jpg, 8 bits color. From the camera. OK? B (prompts user, "Joe would like to send you a photo. Accept?". user accepts) B->A [TOTE] yes proceed A->B [TOTE] sends image B->A [TOTE] file received Again, thinking on my feet here. One of my concerns > with "pic", to take one example, is how a very generic purpose like > trading images gets used by applications that want it. How does a > system know when a pic being sent from one side of the TOTE exchange > to the other is meant as a new user icon, an avatar for a MMORPG, or > a stand-alone picture relevant to some ongoing exchange on a > real time channel? I see your concern. I think the main criteria is that, this is used when the primary purpose is to render an image to the recipient, and allow them the option to save. Since a part of this is rendering you need to think about screen sizes, colors and so on to make sure the image is in a form that can be processed by the recipient for rendering. So anything that needs this - negotiation of picture sizes for immediate rendering - could use it. Primary application would presumably be cameras on mobile phones. If there is more interaction than just "purpose" > and mime type, then re-use of this by applications that want the facility > may work. > Otherwise, it seems you are either going to head towards > purposes like "vnd.WoW" that have no generality or you are going > to get what amounts to a least-common-denominator application. > The "I can send you my name" application is not really too compelling. Agreed. No dispute that each purpose needs to be well defined and broad enough to be useful and narrow enough to meet the needs of the specific use cases well. But thats always the case in engineering. > > >>> Having a dispatch based on purpose without detailed specifications or >>> reference to specific applications seems to hit a middle ground that's >>> kind of nobody's sweet spot. >> That was never the intent. The IANA considerations section states that >> these require specification. >> >>> A specific application already has detailed >>> semantics that go beyond this purpose to actual decisions of whether >>> to render or store, user permissions needed, sizes accepted, etc; >>> generalized MIME transfer protocols like SMTP or HTTP already >>> use a different system for deciding which applications to invoke >>> when faced with a MIME object, and this forces systems with that >>> logic to have a parallel track. >> That would seem to argue for pulling the MIME aspects out of TOTE. >> >>> The muxing seems liable to head of line blocking unless BEEP-like >>> channels are introduced. >> This is discussed; if the purpose requires significant content, set it >> up as a separate session/tcp connection. > > What you have there now is: > > However, if a purpose represents a > significant amount of data, such that head-of-line blocking might > occur between purposes, an agent SHOULD utilize a separate TOTE > session for that purpose. > > I guess this still worries me. If an application wants to set up a TOTE > connection with an existing peer, I'm guessing it will need to decide > whether to re-use an exiting session or set up a new one. Right. > While it > may have a sense of whether it will have large amounts of data to > send, it doesn't have any idea of the sensitivity to head of line > blocking from the other users of the connection. Well there is only one other user, the recipient. But I tend to think this is mostly a function of the 'purpose'. You'd put picture share by itself, but more control-style functions (i.e., camera control or conference controls) could be multiplexed. That pushes the > decision into the agent which knows something about both. > But that ends up requiring a lot of knowledge of the protocol > usage characteristics of the using application which go beyond > what TOTE will carry on the wire (some uses of "pic" with image/jpeg > are really highly unlikely to cause head of line blocking; others might be a > real clog). So I agree that this kind of dynamic decision is really complicated and a static decision based on purpose is much easier. >> I was trying to provide a common mechanism for addressing those cases >> where we don't want to send all this garbage over SIP - we want it over >> the media plane. Are you objecting to that? > > A number of your purposes seem pretty far outside the info-use-cases > draft, and the level of generality does raise issues. I think the level of generality in there is EXACTLY the same as the INFO-usages. Thats why the reactions here surprise me. Fair enough that I do point out some use cases that are not in the INFO cases draft, but it was the whole INFO discussion that got me thinking that we have a need for a media-plane equivalent of INFO-events. TOTE is a nearly direct translation of the mechanism in Hadriels draft into the media plane. Purpose = info package, and the MIME negotiation is already there in SIP via Accept. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 13:58:58 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF88228C3D7; Wed, 27 Feb 2008 13:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzZbpOV5XbqB; Wed, 27 Feb 2008 13:58:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E923A696E; Wed, 27 Feb 2008 13:58:56 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D38A3A6A2C for ; Wed, 27 Feb 2008 13:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWWRe9KBOZhk for ; Wed, 27 Feb 2008 13:58:48 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 23BE53A6A1F for ; Wed, 27 Feb 2008 13:57:17 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2008 13:57:10 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1RLv7S4016811; Wed, 27 Feb 2008 13:57:07 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m1RLv7kk019865; Wed, 27 Feb 2008 21:57:07 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 13:57:06 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 13:57:05 -0800 Message-ID: <47C5DCA6.9080302@cisco.com> Date: Wed, 27 Feb 2008 16:56:54 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Miguel Garcia References: <47C54730.5030501@nsn.com> In-Reply-To: <47C54730.5030501@nsn.com> X-OriginalArrivalTime: 27 Feb 2008 21:57:06.0066 (UTC) FILETIME=[B1373720:01C8798B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6848; t=1204149430; x=1205013430; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Comments=20to=20the=20TOTE=20draft |Sender:=20; bh=Y5KpAW/ceoo2Y09HFpT5PI/BpsrgMrS/d5YGv/E5KxU=; b=b8chVj9Y77nVc509HjHs0p5AXCRwZ6KbQMqD+RXN7N48IAsepIYTh94nPe FteVuj7t0V25t/AicRcLL18wImzOjqhfmwRbGqtTxes7M+1z36ONTj7RtRae 1oedBHxsHf0SE5z0kWFV3GU1NYwiCbnEtI8deF6EhzAiqw0kCPpKI=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: IETF SIP List Subject: Re: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for the comments, Miguel. Looks like this topic is a contentious one, for different reasons than I thought. Lots of folks didn't want info-events, but it looks like lots of folks think we already have solutions for the media-plane equivalent (file transfer and the media-ctrl framework). Responses below: Miguel Garcia wrote: > Here are some comments to the TOTE draft: > > 1. In the Introduction the draft mentions three general purpose > mechanisms that allow a pair of agents to communicate data during a > session. However it fails to name the most relevant work for this draft, > which is the file transfer mechanism, an MMUSIC WG item: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-06.txt Sure I am aware of that. I saw that as a specific type of data communications - file transfer. > > > 2. Then, I believe most of what the draft proposes can be done with the > above draft. For good or for bad, the file transfer mechanism does not > really define a new file transfer protocol as TOTE does, but reuses the > existing MSRP. I think its the MIME bit that has gotten lots of folks in a tizzy here. I think, you are thinking, "MIME object = file" and so this draft is basically doing file transfer. But really its about these "purposes", and a purpose can be a mini-protocol and not really a file transfer in any sense of the word. Would you use the file transfer draft above to exchange camera controls? I didnt think so. > > 3. I don't think I have seen the requirements for this draft. So, I > cannot really evaluate why the file transfer mechanism is able to meet > these requirements, and I cannot evaluate if MSRP is able to meet these > requirements. The requirements corresponding to the file transfer > mechanism were posted way back in this draft: > http://tools.ietf.org/draft/draft-isomaki-sipping-file-transfer/draft-isomaki-sipping-file-transfer-01.txt The requirements are the same ones driving info-events - the ability to communicate between agents for new applications without requiring standardization work. I am merely adding a media-path solution to that problem. > > > 4. Assuming that there is a need for a new protocol for transferring > files TOTE is not about file transfer. See above. > between to endpoints, I would encourage to re-use existing work. > In particular, the file transfer mechanism says: > > In principle it is possible to use the SDP extensions defined here > and replace MSRP with any other similar protocol that can carry > MIME objects. This kind of specification can be written as a > separate document if the need arises. Essentially, such protocol > should be able to be negotiated on an SDP offer/answer exchange > (RFC 3264 [RFC3264]), be able to carry MIME objects between two > endpoints, and use a reliable transport protocol (e.g., TCP). > > For what I read, TOTE will qualify for such alternative protocol, but > again, we need to understand the requirements that makes the need for > yet another file transfer protocol. Interesting. I had missed that bit of the document. So I think there are a few ways to see how these relate: 1. as you suggest, TOTE could be an alternative to MSRP and you could continue to use the SDP attributes defined in your draft, 2. the file transfer spec very much couples the negotiation of the file transfer itself (parameters of the file along with an indication of willingness) with O/A. We have been burned by this before, when we've tried to take negotiation things and couple them to the O/A exchange. Security key negotiation is an example. We found, in the end, by doing it in the media path we had more flexibility and were not limited to a two-way handshake. So another way to think of it, is this, would you benefit from separating the file transfer negotiation from O/A itself? Would you benefit from more round trips or more complex objects that are hard to place in SDP? I for one always thought file trnasfer is best done as a 4-way: A->B want to send file, here are characteristics B->A yes, please send A->B ok here is the file B->A got it basically the file transfer is doing the first two in O/A and the last two in MSRP, so it kind of works. But I wonder if you had more flexibility would we get a feature or capability that would be impossible otherwise. For example, the ability of the recipient to cancel mid-transaction, or to tell the sender to pause and resume. If we went this route, you'd basically take your existing SDP attributes, take them out into a standalone protocol message and send e2e over this connection instead. 3. file transfer is for file transfer and tote is for other things that don't include file transfer; i.e., these look similar but file transfer has some special needs and that is why we have a specific spec for it. And so both proceed independently. Architecturally, the interesting question I'm posing, is what is our model for extending SIP to accomodate new media-level things. To date, it has been about doing SDP extensions for each new thing. This draft suggests that we don't do that; that we make SIP/SDP minimal and just set up something else that can do the application-specific protocol procedures that are optimized for it. This means, you don't need to upgrade your SIP/SDP infrastructure (since with b2bua they are coupled) every time you want something new. This is the same aspect that has attracted people to INFO - I can send new stuff without a new sip extension. I'd like the same for the media plane. > > 5. On a slightly different topic. The draft also mentions Shared > Browsing. I have recently put a draft that describes how to do > collaboration between endpoints, and one of the topics is Shared > Browsing. The draft is this one: > > http://www.ietf.org/internet-drafts/draft-garcia-mmusic-sdp-collaboration-00.txt > > > Section 4.2 discusses the topic, and proposes to use the file transfer > mechanism for sending those URL objects between endpoints. Yes I did see this, and had a chance to skim. Looking forward to the discussion. > > 6. I've been told that in German language TOTE means DEATH, so, perhaps > that name should be changed. lol. Well TOTE worked really nice in English since it means, "to carry" and that is basically what this does. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 17:07:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF02728C78A; Wed, 27 Feb 2008 17:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.025 X-Spam-Level: X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI0qfvGMSI6N; Wed, 27 Feb 2008 17:07:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8353A6BA4; Wed, 27 Feb 2008 17:07:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624C13A6B95 for ; Wed, 27 Feb 2008 17:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB3aCz4ZKtCw for ; Wed, 27 Feb 2008 17:06:59 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9E6C13A6BA4 for ; Wed, 27 Feb 2008 17:06:59 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2008 17:06:53 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1S16rlm015216 for ; Wed, 27 Feb 2008 17:06:53 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1S16kS0004184 for ; Thu, 28 Feb 2008 01:06:51 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 17:06:50 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 17:06:50 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 19:06:54 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 28 Feb 2008 01:06:50.0652 (UTC) FILETIME=[32F52DC0:01C879A6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=823; t=1204160813; x=1205024813; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20draft-ietf-sip-rph-new-namespaces-02 |Sender:=20; bh=ayW7YXHC50Odin81NKeAZAM1TtT+DOscnrBMqeaiCrU=; b=POI7Z6IWxIX+WsbM5mzWOjGEJOpDO1AtEz+sSuRHSpcDmf/F2DzQoTpEbO 7UIVqeaiPhRU9d5s+mRtQ9VCHLDBMJ08UiOntHAjYD3nxPjpFxe6W4BI6ZoX vik22Vu3zW; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Sip] draft-ietf-sip-rph-new-namespaces-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I revved this ID here http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-02.txt I changed the list of namespaces from 50 down to 40, in what looks like 4 groups of 10 The namespaces are now dsn-000000 through dsn-000009. drsn-000000 through drsn-000009. rts-000000 through rts-000009. crts-000000 through crts-000009. All have the same 10 priority-values of "0" (lowest priority) through "9" (highest priority), and I cut several pages down in the document by showing one example, and saying all others are just like it. I changed a few other nits Keith pointed out. The list has had one new comment from Dave Worley about making a clearer Abstract, and I will (which is ease), perhaps before the WG meeting on Thursday. Additional comments are welcome James _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 17:21:51 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09DF628C8AB; Wed, 27 Feb 2008 17:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEpsjGrcgMUl; Wed, 27 Feb 2008 17:21:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757043A69F1; Wed, 27 Feb 2008 17:21:45 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E4528C288 for ; Wed, 27 Feb 2008 17:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U04USseqwcuz for ; Wed, 27 Feb 2008 17:21:44 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F3C033A6D93 for ; Wed, 27 Feb 2008 17:21:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,416,1199692800"; d="scan'208";a="15050128" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 27 Feb 2008 17:21:37 -0800 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 m1S1LbXm019665 for ; Wed, 27 Feb 2008 17:21:37 -0800 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 m1S1LbDN016327 for ; Thu, 28 Feb 2008 01:21:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 17:21:37 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 17:21:36 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 19:21:41 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 28 Feb 2008 01:21:36.0956 (UTC) FILETIME=[433C6FC0:01C879A8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1248; t=1204161697; x=1205025697; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20New=20rev=20of=20draft-polk-sip-rph-in-response s-01 |Sender:=20; bh=9wTYJyvpohJBS4lGjGCVvHtVtmErrcrt6IGUn+XEEPE=; b=sPygsSoPuA6QiwcmZBsHqna5MgTMFoeXHh9qGrSmuPfl1nmi89/0dh4LPC HWA+nOqNGaawNFBI2OihinouHeCC/sYgj/kWnyOIldMs503rhbIddX+sXa5s hMaVcaqi9N; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Sip] New rev of draft-polk-sip-rph-in-responses-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I revved this ID http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-responses-01.txt What's new in this version: I clarified that this document deals with "use-case#1" - which is for the scenario in which a stateless proxy is surrounded by stateful proxies (a stated requirement to use Resource-Priority header, per RFC4412), and the stateless proxy needs to be able to rely on the Resource-Priority header value in responses. I explicitly dismissed Janet Gunn's "use-case#2", described here http://tools.ietf.org/wg/sip/draft-gunn-sip-req-for-rph-in-responses-00.txt from consideration in the draft, as it appears that use-case will be solved by using Diameter for their authorization of Resource-Priority header value in requests and responses. I believe that is much better suited for what they were discussing in Vancouver. I think I've made the above pretty clear in the doc. I also rewrote some portions to make them clearer. Plus I fixed some nits. If folks are agreeable that this document clearly articulates it's only covering "use-case#1", and not "use-case#2", I think this doc is done - meaning I feel LC can happen right after this becomes a WG doc. Comments are welcome James _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 27 21:38:56 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE1128C584; Wed, 27 Feb 2008 21:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.345 X-Spam-Level: X-Spam-Status: No, score=0.345 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9teqoC9grUl6; Wed, 27 Feb 2008 21:38:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7024F3A6A0C; Wed, 27 Feb 2008 21:38:55 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFB33A6A0C for ; Wed, 27 Feb 2008 21:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azC6ZBPHCUyK for ; Wed, 27 Feb 2008 21:38:52 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 327923A6903 for ; Wed, 27 Feb 2008 21:38:51 -0800 (PST) Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 28 Feb 2008 11:08:44 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1S5chjt024751; Thu, 28 Feb 2008 13:38:43 +0800 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 m1S5cf3l006842; Thu, 28 Feb 2008 05:38:43 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 13:38:36 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 13:39:26 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Sip] Contact header in 1xx responses/updates remote target or not? Thread-Index: Ach5zEf2Jt3kF8o9S6GMo2FYPIBmaw== From: "Rockson Li (zhengyli)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 28 Feb 2008 05:38:36.0707 (UTC) FILETIME=[2A1FB730:01C879CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2290; t=1204177123; x=1205041123; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20Re=3A=20[Sip]=20Contact=20header=20in=201xx=20r esponses/updates=20remote=20target=20or=20not? |Sender:=20; bh=aD30v43P/1VATDC8SNky3llfJDVSJ2pZ3+Ah04bApHM=; b=g1qop5nJCONfPhRvVY4W5xBvU48JbSEl0mKKhq5qHKvMTrkw7v/Pd5ninC 8Xw8N5BB8Ykwsm+hKKG9G4YelXTmTqogebE3w6omE8fUdxNjRDq4GfyCuTX3 yiLQuluRcmcLExuYJ7EtEq7+UpdAI3v8EesJDCTNvw45O9Bfu/I7o=; Authentication-Results: hkg-dkim-2; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1411017619==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1411017619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C879CC.29E31AB0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C879CC.29E31AB0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Paul , Christer and all, =20 I am following the email thread as in subject above http://www.ietf.org/mail-archive/web/sip/current/msg19322.html =20 However, I do not find the definite answer to Christer's question, Do we have the answer now? =20 Thanks a lot Regards, Rockson Li=20 Cisco R&D Center, Shanghai, PRC =20 ------_=_NextPart_001_01C879CC.29E31AB0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
    Paul , Christer=20 and all,
     
    I am = following the=20 email thread as in subject above
    h= ttp://www.ietf.org/mail-archive/web/sip/current/msg19322.html<= /FONT>
     
    However, I do not=20 find the definite answer to Christer's question,
    Do we = have the=20 answer now?
     
    Thanks = a=20 lot

    Regards,
    Rockson Li

    Cisco R&D Center, = Shanghai,=20 PRC

     
    ------_=_NextPart_001_01C879CC.29E31AB0-- --===============1411017619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1411017619==-- From sip-bounces@ietf.org Thu Feb 28 01:02:08 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4628C28C255; Thu, 28 Feb 2008 01:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOr2QzZJrRhR; Thu, 28 Feb 2008 01:02:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C709F28C343; Thu, 28 Feb 2008 01:02:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DC828C30D for ; Thu, 28 Feb 2008 01:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZkDSt4ABTsh for ; Thu, 28 Feb 2008 01:01:56 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0717E3A6903 for ; Thu, 28 Feb 2008 01:01:55 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DAD1D210D2; Thu, 28 Feb 2008 09:47:06 +0100 (CET) X-AuditID: c1b4fb3c-b08c0bb000007e19-d8-47c6750a43c5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BD5C720E98; Thu, 28 Feb 2008 09:47:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 09:47:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 09:45:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Sip] Contact header in 1xx responses/updates remote target or not? thread-index: Ach5zEf2Jt3kF8o9S6GMo2FYPIBmawAGgQBk References: From: "Christer Holmberg" To: "Rockson Li (zhengyli)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 28 Feb 2008 08:47:06.0356 (UTC) FILETIME=[7F333340:01C879E6] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I don't think anything has happened since Paul said he agrees :) I guess this is one thing, similar to the PRACK 488 (see other thread), that we need to try to figure out how to document (and, of course, what to document). Regards, Christer ________________________________ From: Rockson Li (zhengyli) [mailto:zhengyli@cisco.com] Sent: Thu 28/02/2008 06:39 To: Paul Kyzivat (pkyzivat); Christer Holmberg Cc: sip@ietf.org Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not? Paul , Christer and all, I am following the email thread as in subject above http://www.ietf.org/mail-archive/web/sip/current/msg19322.html However, I do not find the definite answer to Christer's question, Do we have the answer now? Thanks a lot Regards, Rockson Li Cisco R&D Center, Shanghai, PRC _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 01:38:41 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F132328C6F1; Thu, 28 Feb 2008 01:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRcz1ksIwWvC; Thu, 28 Feb 2008 01:38:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E992A28C566; Thu, 28 Feb 2008 01:38:35 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A79E28C465 for ; Thu, 28 Feb 2008 01:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X3Do+jwvew9 for ; Thu, 28 Feb 2008 01:38:30 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D638E28C625 for ; Thu, 28 Feb 2008 01:38:08 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1S9bq5i022518; Thu, 28 Feb 2008 03:39:37 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 11:37:40 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 11:37:40 +0200 Received: from [10.144.23.25] ([10.144.23.25]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 11:37:39 +0200 Message-ID: <47C680E3.2030803@nsn.com> Date: Thu, 28 Feb 2008 11:37:39 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg References: <47C54730.5030501@nsn.com> <47C5DCA6.9080302@cisco.com> In-Reply-To: <47C5DCA6.9080302@cisco.com> X-OriginalArrivalTime: 28 Feb 2008 09:37:39.0959 (UTC) FILETIME=[8F5E4870:01C879ED] X-Nokia-AV: Clean Cc: IETF SIP List Subject: Re: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Inline discussion. Jonathan Rosenberg wrote: > Thanks for the comments, Miguel. Looks like this topic is a contentious > one, for different reasons than I thought. Lots of folks didn't want > info-events, but it looks like lots of folks think we already have > solutions for the media-plane equivalent (file transfer and the > media-ctrl framework). > > Responses below: > > Miguel Garcia wrote: >> Here are some comments to the TOTE draft: >> >> 1. In the Introduction the draft mentions three general purpose >> mechanisms that allow a pair of agents to communicate data during a >> session. However it fails to name the most relevant work for this >> draft, which is the file transfer mechanism, an MMUSIC WG item: >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-06.txt > > > Sure I am aware of that. I saw that as a specific type of data > communications - file transfer. That is correct, the draft is specific to file transfer. Now, I don't want to open a discussion about what is a file versus what is a MIME object. I think we should focus on the semantics, and what make the file transfer draft not feasible for the TOTE protocol. > >> >> >> 2. Then, I believe most of what the draft proposes can be done with >> the above draft. For good or for bad, the file transfer mechanism does >> not really define a new file transfer protocol as TOTE does, but >> reuses the existing MSRP. > > I think its the MIME bit that has gotten lots of folks in a tizzy here. > I think, you are thinking, "MIME object = file" and so this draft is > basically doing file transfer. But really its about these "purposes", > and a purpose can be a mini-protocol and not really a file transfer in > any sense of the word. Would you use the file transfer draft above to > exchange camera controls? I didnt think so. If it is about a single camera control then it is possible to do it. But if the camera control is some sort of continuous interaction, then I would probably not use the file transfer, but just vanilla MSRP with the appropriate content type. > >> >> 3. I don't think I have seen the requirements for this draft. So, I >> cannot really evaluate why the file transfer mechanism is able to meet >> these requirements, and I cannot evaluate if MSRP is able to meet >> these requirements. The requirements corresponding to the file >> transfer mechanism were posted way back in this draft: >> http://tools.ietf.org/draft/draft-isomaki-sipping-file-transfer/draft-isomaki-sipping-file-transfer-01.txt > > > The requirements are the same ones driving info-events - the ability to > communicate between agents for new applications without requiring > standardization work. I am merely adding a media-path solution to that > problem. > ok, understood. >> >> >> 4. Assuming that there is a need for a new protocol for transferring >> files > > TOTE is not about file transfer. See above. > >> between to endpoints, I would encourage to re-use existing work. In >> particular, the file transfer mechanism says: >> >> In principle it is possible to use the SDP extensions defined here >> and replace MSRP with any other similar protocol that can carry >> MIME objects. This kind of specification can be written as a >> separate document if the need arises. Essentially, such protocol >> should be able to be negotiated on an SDP offer/answer exchange >> (RFC 3264 [RFC3264]), be able to carry MIME objects between two >> endpoints, and use a reliable transport protocol (e.g., TCP). >> >> For what I read, TOTE will qualify for such alternative protocol, but >> again, we need to understand the requirements that makes the need for >> yet another file transfer protocol. > > > Interesting. I had missed that bit of the document. > > So I think there are a few ways to see how these relate: > > 1. as you suggest, TOTE could be an alternative to MSRP and you could > continue to use the SDP attributes defined in your draft, > > 2. the file transfer spec very much couples the negotiation of the file > transfer itself (parameters of the file along with an indication of > willingness) with O/A. We have been burned by this before, when we've > tried to take negotiation things and couple them to the O/A exchange. > Security key negotiation is an example. We found, in the end, by doing > it in the media path we had more flexibility and were not limited to a > two-way handshake. So another way to think of it, is this, would you > benefit from separating the file transfer negotiation from O/A itself? > Would you benefit from more round trips or more complex objects that are > hard to place in SDP? I for one always thought file trnasfer is best > done as a 4-way: > > A->B want to send file, here are characteristics > B->A yes, please send > A->B ok here is the file > B->A got it > > basically the file transfer is doing the first two in O/A and the last > two in MSRP, so it kind of works. But I wonder if you had more > flexibility would we get a feature or capability that would be > impossible otherwise. For example, the ability of the recipient to > cancel mid-transaction, or to tell the sender to pause and resume. If we > went this route, you'd basically take your existing SDP attributes, take > them out into a standalone protocol message and send e2e over this > connection instead. Yes, the background for the file transfer draft. It tries to emulate the file transfer feature that we have in many instant messaging systems. So, the coupling of the file description with the O/A works well in that case. Any of both ends can also abort the file transfer. Both ends can also pause and resume the file transfer. > > 3. file transfer is for file transfer and tote is for other things that > don't include file transfer; i.e., these look similar but file transfer > has some special needs and that is why we have a specific spec for it. > And so both proceed independently. > I think the OTE draft should reuse the file transfer draft as much as it could. Dealing with files or MIME objects is a subtle difference. Perhaps the biggest difference is that TOTE tries to create a media stream for transferring a MIME object, while the file transfer draft assume a given protocol (so far MSRP) and a given purpose (a file). But it should be possible for me to offer you a file with either MSRP or the simple TCP connection that TOTE uses without much changes to the SDP. > > > Architecturally, the interesting question I'm posing, is what is our > model for extending SIP to accomodate new media-level things. To date, > it has been about doing SDP extensions for each new thing. This draft > suggests that we don't do that; that we make SIP/SDP minimal and just > set up something else that can do the application-specific protocol > procedures that are optimized for it. This means, you don't need to > upgrade your SIP/SDP infrastructure (since with b2bua they are coupled) > every time you want something new. This is the same aspect that has > attracted people to INFO - I can send new stuff without a new sip > extension. I'd like the same for the media plane. > This is certainly the question. But even with the model that TOTE uses, you still need to at least register the MIME objects or the underlying protocol, right? I understand the SDP should not change for any of these usages that you envision, so you don't need to upgrade intermediaries, but at least some mnemonic that identifies the protocol should be > > -Jonathan R. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 06:43:16 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E73F28C4AE; Thu, 28 Feb 2008 06:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zv4vz-lSGVl; Thu, 28 Feb 2008 06:43:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039D328C102; Thu, 28 Feb 2008 06:43:15 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152713A6A0E for ; Thu, 28 Feb 2008 06:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvZvErtXr00F for ; Thu, 28 Feb 2008 06:43:08 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 409163A6B4E for ; Thu, 28 Feb 2008 06:42:29 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2008 06:42:22 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1SEgM6I018309; Thu, 28 Feb 2008 06:42:22 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1SEgKRs014351; Thu, 28 Feb 2008 14:42:20 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 06:42:20 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 06:42:19 -0800 Message-ID: <47C6C841.2010201@cisco.com> Date: Thu, 28 Feb 2008 09:42:09 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Miguel Garcia References: <47C54730.5030501@nsn.com> <47C5DCA6.9080302@cisco.com> <47C680E3.2030803@nsn.com> In-Reply-To: <47C680E3.2030803@nsn.com> X-OriginalArrivalTime: 28 Feb 2008 14:42:20.0051 (UTC) FILETIME=[1F26F630:01C87A18] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5205; t=1204209742; x=1205073742; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Comments=20to=20the=20TOTE=20draft |Sender:=20; bh=qcXbgOVv0ZfLU08eJiB5h2uMGkHzkGuPTvclsDV2BdE=; b=k74EjRmu1enG6ob+HD6TFr+R7MJGf4ZXcQwSIrv1M3td5KhN3ltEGMiXrU shESTTlqBmtotfCcNiMTRWLTvc9DHpi12G1JeD/ws2pVagxZ7V0B0YL/UH5z YKHM+9GaYN; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: IETF SIP List Subject: Re: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline: Miguel Garcia wrote: >> I think its the MIME bit that has gotten lots of folks in a tizzy >> here. I think, you are thinking, "MIME object = file" and so this >> draft is basically doing file transfer. But really its about these >> "purposes", and a purpose can be a mini-protocol and not really a file >> transfer in any sense of the word. Would you use the file transfer >> draft above to exchange camera controls? I didnt think so. > > If it is about a single camera control then it is possible to do it. But > if the camera control is some sort of continuous interaction, then I > would probably not use the file transfer, but just vanilla MSRP with the > appropriate content type. Ah, so there are two parts of this discussion: 1. whether MSRP is to be used as a general transport of stuff between agents, which is not strictly instant messaging (like camera controls) 2. regardless of MSRP vs. something else, when would one use the file transfer mechanism and when not Frankly I don't think you'd ever use the file transfer mechanism for camera controls, even a one-shot. Most of the file selector attributes don't make sense here - size, filename, hashes - these are useful primarily for transfering an existing stored file, not for carrying arbitrary protocols. So then the question is, is MSRP a general purpose UA to UA transport mechanism, or not. Frankly I think it is not. Its designed around instant messaging which is a particular application. ITs having extensions for things like nicknames and conferencing which are specific to IM. The reporting feature is also IMHO very much an IM-specific thing. File transfer is arguably very close to IM and can benefit from much of what MSRP provides; chunking and interruption all make sense because these are big objects. TOTE proposes a much more lightweight transfer mechanism for general UA to UA protocols/applications. > >> 2. the file transfer spec very much couples the negotiation of the >> file transfer itself (parameters of the file along with an indication >> of willingness) with O/A. We have been burned by this before, when >> we've tried to take negotiation things and couple them to the O/A >> exchange. Security key negotiation is an example. We found, in the >> end, by doing it in the media path we had more flexibility and were >> not limited to a two-way handshake. So another way to think of it, is >> this, would you benefit from separating the file transfer negotiation >> from O/A itself? Would you benefit from more round trips or more >> complex objects that are hard to place in SDP? I for one always >> thought file trnasfer is best done as a 4-way: >> >> A->B want to send file, here are characteristics >> B->A yes, please send >> A->B ok here is the file >> B->A got it >> >> basically the file transfer is doing the first two in O/A and the last >> two in MSRP, so it kind of works. But I wonder if you had more >> flexibility would we get a feature or capability that would be >> impossible otherwise. For example, the ability of the recipient to >> cancel mid-transaction, or to tell the sender to pause and resume. If >> we went this route, you'd basically take your existing SDP attributes, >> take them out into a standalone protocol message and send e2e over >> this connection instead. > > Yes, the background for the file transfer draft. It tries to emulate the > file transfer feature that we have in many instant messaging systems. > So, the coupling of the file description with the O/A works well in that > case. Any of both ends can also abort the file transfer. Both ends can > also pause and resume the file transfer. How do you do pause with MSRP? Specifically, how does the receiver tell the sender to pause? How does the receiver cancel? > >> >> 3. file transfer is for file transfer and tote is for other things >> that don't include file transfer; i.e., these look similar but file >> transfer has some special needs and that is why we have a specific >> spec for it. And so both proceed independently. >> > > I think the OTE draft should reuse the file transfer draft as much as it > could. Dealing with files or MIME objects is a subtle difference. > Perhaps the biggest difference is that TOTE tries to create a media > stream for transferring a MIME object, while the file transfer draft > assume a given protocol (so far MSRP) and a given purpose (a file). But > it should be possible for me to offer you a file with either MSRP or the > simple TCP connection that TOTE uses without much changes to the SDP. That last sentence I agree with. However What I don't agree with, is if I am not transferring a file, just doing a camera control or somethign, that I have to use the file transfer SDP attributes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 07:34:01 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB20128C545; Thu, 28 Feb 2008 07:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.517 X-Spam-Level: X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFfvDx8YbSLI; Thu, 28 Feb 2008 07:34:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6C428C13F; Thu, 28 Feb 2008 07:34:00 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F993A6BA2 for ; Thu, 28 Feb 2008 07:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRG7sudksp7N for ; Thu, 28 Feb 2008 07:33:53 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 03FE028C13F for ; Thu, 28 Feb 2008 07:33:52 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1SFYwZi022782; Thu, 28 Feb 2008 09:35:11 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 17:33:01 +0200 Received: from [10.144.23.25] ([10.144.23.25]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 17:33:01 +0200 Message-ID: <47C6D42D.8040506@nsn.com> Date: Thu, 28 Feb 2008 17:33:01 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg References: <47C54730.5030501@nsn.com> <47C5DCA6.9080302@cisco.com> <47C680E3.2030803@nsn.com> <47C6C841.2010201@cisco.com> In-Reply-To: <47C6C841.2010201@cisco.com> X-OriginalArrivalTime: 28 Feb 2008 15:33:01.0147 (UTC) FILETIME=[33C962B0:01C87A1F] X-Nokia-AV: Clean Cc: IETF SIP List Subject: Re: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Inline as well. Jonathan Rosenberg wrote: > Ah, so there are two parts of this discussion: > > 1. whether MSRP is to be used as a general transport of stuff between > agents, which is not strictly instant messaging (like camera controls) > > 2. regardless of MSRP vs. something else, when would one use the file > transfer mechanism and when not Right, that is correct. Besides, I think the general willingness of making implementor's life easy, so that if we end up having several orthogonal mechanisms that share some sort of commonality, all these mechanism should be able to coexist in an implementation. > > Frankly I don't think you'd ever use the file transfer mechanism for > camera controls, even a one-shot. Most of the file selector attributes > don't make sense here - size, filename, hashes - these are useful > primarily for transfering an existing stored file, not for carrying > arbitrary protocols. I think I concluded the same, but with different reasons. I think camera control is probably a stream of actions, so you move the camera up, pan, tilt, zoom, etc. Let's assume that you model each action in an XML document. I wouldn't use the O/A described in the file transfer draft, because you would need to re-INVITE prior to sending each action, get acceptance from the remote party (the camera), and then do the action. It will be annoying, with a tremendous overhead (re-INVITE), and far from real-time. However, you can easily create a regular MSRP channel where you transport those MIME objects. MSRP can carry any MIME object of any arbitrary length, so, it meets the needs. The discussion of MSRP/not MSRP is below. > > So then the question is, is MSRP a general purpose UA to UA transport > mechanism, or not. Frankly I think it is not. Its designed around > instant messaging which is a particular application. ITs having > extensions for things like nicknames and conferencing which are specific > to IM. The reporting feature is also IMHO very much an IM-specific thing. I disagree here. You said: - It is designed around instant messaging: I would say MSRP is designed around real-time transfer of objects. The MSRP draft provides examples and provisions for transferring, for example, large video files. - It's having extensions for things like nicknames and conferencing which are specific to conferencing: I don't see the point here. It is like if you tell me that SIP is not good for voice because there are extensions for presence, instant messaging and alike. MSRP is generic enough to carry objects between two points. Extensions try to improve the user experience for specific applications. > > File transfer is arguably very close to IM and can benefit from much of > what MSRP provides; chunking and interruption all make sense because > these are big objects. > Agreed. > TOTE proposes a much more lightweight transfer mechanism for general UA > to UA protocols/applications. And I don't object it. As I indicated earlier, the use case for the file transfer is: I have an instant messaging application that implements MSRP. Now you are probably saying: does it mean I need to implement MSRP for a trivial file sending. The answer is no, and I don't have any problem with the simple trivial protocol that the TOTE draft describes. >> >>> 2. the file transfer spec very much couples the negotiation of the >>> file transfer itself (parameters of the file along with an indication >>> of willingness) with O/A. We have been burned by this before, when >>> we've tried to take negotiation things and couple them to the O/A >>> exchange. Security key negotiation is an example. We found, in the >>> end, by doing it in the media path we had more flexibility and were >>> not limited to a two-way handshake. So another way to think of it, is >>> this, would you benefit from separating the file transfer negotiation >>> from O/A itself? Would you benefit from more round trips or more >>> complex objects that are hard to place in SDP? I for one always >>> thought file trnasfer is best done as a 4-way: >>> >>> A->B want to send file, here are characteristics >>> B->A yes, please send >>> A->B ok here is the file >>> B->A got it >>> >>> basically the file transfer is doing the first two in O/A and the >>> last two in MSRP, so it kind of works. But I wonder if you had more >>> flexibility would we get a feature or capability that would be >>> impossible otherwise. For example, the ability of the recipient to >>> cancel mid-transaction, or to tell the sender to pause and resume. If >>> we went this route, you'd basically take your existing SDP >>> attributes, take them out into a standalone protocol message and send >>> e2e over this connection instead. >> >> Yes, the background for the file transfer draft. It tries to emulate >> the file transfer feature that we have in many instant messaging >> systems. So, the coupling of the file description with the O/A works >> well in that case. Any of both ends can also abort the file transfer. >> Both ends can also pause and resume the file transfer. > > How do you do pause with MSRP? Specifically, how does the receiver tell > the sender to pause? How does the receiver cancel? Pause from receiver to sender: re-INVITE with SDP offer with the MSRP media stream set to inactive. Cancel from receiver: re-INVITE with SDP offer setting the MSRP media stream to port 0. > >> >>> >>> 3. file transfer is for file transfer and tote is for other things >>> that don't include file transfer; i.e., these look similar but file >>> transfer has some special needs and that is why we have a specific >>> spec for it. And so both proceed independently. >>> >> >> I think the OTE draft should reuse the file transfer draft as much as >> it could. Dealing with files or MIME objects is a subtle difference. >> Perhaps the biggest difference is that TOTE tries to create a media >> stream for transferring a MIME object, while the file transfer draft >> assume a given protocol (so far MSRP) and a given purpose (a file). >> But it should be possible for me to offer you a file with either MSRP >> or the simple TCP connection that TOTE uses without much changes to >> the SDP. > > That last sentence I agree with. However What I don't agree with, is if > I am not transferring a file, just doing a camera control or somethign, > that I have to use the file transfer SDP attributes. I said "as much as it could", meaning that re-using or adapting already defined SDP parameters. /Miguel > > > -Jonathan R. > > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 07:58:41 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFFD28C5FC; Thu, 28 Feb 2008 07:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.346 X-Spam-Level: X-Spam-Status: No, score=0.346 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeoLKVJzjZ6P; Thu, 28 Feb 2008 07:58:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94EF328C0DE; Thu, 28 Feb 2008 07:58:40 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4273A68E1 for ; Thu, 28 Feb 2008 07:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHvqPDKVNM5A for ; Thu, 28 Feb 2008 07:58:33 -0800 (PST) Received: from isrexch01.israel.polycom.com (fw.polycom.co.il [212.179.41.2]) by core3.amsl.com (Postfix) with ESMTP id BF0233A6960 for ; Thu, 28 Feb 2008 07:58:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 17:59:11 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C05677665@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TOTE and other end to end control Thread-Index: Ach6IrhLhWNhQsYtTDm7RFNXogKLPg== From: "Even, Roni" To: Subject: [Sip] TOTE and other end to end control X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1114603772==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1114603772== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87A22.DCD4D3C2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87A22.DCD4D3C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I read the draft and would like to mention that for camera control is = real-time since today the feedback is by looking at the received video = stream. There is RFC4573 describing far end camera control. =20 As for media path connection there is also the RTCP feedback in RFC4585 = and RFC5124 as well asdraft-ott-avt-rtcp-guidelines-00 that tries to = define what you can do in RTCP. =20 =20 Roni Even ------_=_NextPart_001_01C87A22.DCD4D3C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi,

    I read the draft and would like to mention that for = camera control is real-time since today the feedback is by looking at the = received video stream. There is RFC4573 describing far end camera = control.

     

    As for media path connection there is also the RTCP = feedback in RFC4585 and RFC5124 as well asdraft-ott-avt-rtcp-guidelines-00 that = tries to define what you can do in RTCP.

     

     

    Roni = Even

    ------_=_NextPart_001_01C87A22.DCD4D3C2-- --===============1114603772== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1114603772==-- From sip-bounces@ietf.org Thu Feb 28 08:10:52 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7694A28C8C9; Thu, 28 Feb 2008 08:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.159 X-Spam-Level: X-Spam-Status: No, score=-0.159 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCACbOvwdRZE; Thu, 28 Feb 2008 08:10:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FA528C803; Thu, 28 Feb 2008 08:10:46 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46A328C865 for ; Thu, 28 Feb 2008 08:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJVn3GAbz-Sd for ; Thu, 28 Feb 2008 08:10:45 -0800 (PST) Received: from isrexch01.israel.polycom.com (fw.polycom.co.il [212.179.41.2]) by core3.amsl.com (Postfix) with ESMTP id 8E31228C794 for ; Thu, 28 Feb 2008 08:10:43 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 18:11:25 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C0567766D@IsrExch01.israel.polycom.com> In-Reply-To: <47C2E749.2090000@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D - TOTE - "INFO" on the media path Thread-Index: Ach3yZjX7y1ccwcVQmyq2hKwPUg8lACWemGw From: "Even, Roni" To: "Jonathan Rosenberg" , "Chris Boulton" Cc: IETF SIP List , Dean Willis Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi About the analysis: "Mediactrl solves the problem of binding a connection to a dialog by defining a SYNC message. TOTE solves this problem by using ICE, which provides this correlation as part of its normal operations. Mediactrl solves the problem of keepalives using its own keepalive message; TOTE uses the ICE keepalive mechanism." I think that there is a difference there. Media control is using one dialog to the media server for opening the control channel. On this control channel the media server will get many controls that relate to different dialogs created separately (users connecting to the media server). The association is between a specific control command and a dialog and not between the control channel and a dialog. Roni Even. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 08:50:46 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4346428C8F2; Thu, 28 Feb 2008 08:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0--jNL0CUF0T; Thu, 28 Feb 2008 08:50:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2CA3A6C03; Thu, 28 Feb 2008 08:50:40 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750CC3A6CD4 for ; Thu, 28 Feb 2008 08:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4ehift1dZCR for ; Thu, 28 Feb 2008 08:50:33 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 602033A6C03 for ; Thu, 28 Feb 2008 08:50:33 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWY00K47K3VCB@siemenscomms.co.uk> for sip@ietf.org; Thu, 28 Feb 2008 16:50:23 +0000 (GMT) Date: Thu, 28 Feb 2008 16:50:03 +0000 From: "Elwell, John" In-reply-to: <5D1A7985295922448D5550C94DE2918001C68A17@DEEXC1U01.de.lucent.com> To: "DRAGE, Keith (Keith)" , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D070BC40@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] WGLC on domain-certs and eku - comments on domain-certs Thread-Index: Ach1I47x4nFLQ/r9Sf6PE1fK5hI8NAE/Lb2w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001C68A17@DEEXC1U01.de.lucent.com> Cc: "Jeffrey, Alan S A \(Alan\)" , slawrence@bluesocket.com Subject: Re: [Sip] WGLC on domain-certs and eku - comments on domain-certs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 1. "Existing SIP specifications do no sufficiently specify" Change "no" to "not". 2. "Section 5 looks at the reason why mutual inter-domain authentication is desired in SIP, and the lack of normative text and behavior in RFC3261 for doing so. Section 7 provides normative behavior on the SIP entities (user agent clients, user agent servers, registrars, redirect servers, and proxies) that need perform authentication based on X.509 certificates." Odd that there is no mention of section 6. If there really is a need to describe the document layout, then mention section 6 too. 3. "A domain name in an X.509 certificates" Change "an" to "a". 4. "6. Guidelines for a service provider When assigning certificates to proxy servers, registrars, and redirect servers, a service provider MUST ensure that the SIP AUS used to address the server is present as an identity in the subjectAltName field of the certificate." So section 6 is "guidelines" and contains a RFC 2119 language. Whereas section 7 is normative (according to an earlier statement) and also contains RFC 2119 language. If they are both normative (in the way normative is used in BCPs), then they should both be claimed as normative. "Guidelines" seems too soft. 5. "such usage is NOT RECOMMENDED for new certificates, which MUST contain the identity in the subjectAltName extension" I think we should either use a "MUST NOT" construct in the first half together with "MUST" in the second half, or use "NOT RECOMMENDED" in the first half and "SHOULD" in the second half. 6. "implementations must follow checks as prescribed therein." Should this be "MUST"? 7. "The use of the CN value is allowed for backward compatibility, but is NOT RECOMMENDED" This appears in the section on normative behaviour for a SIP entity, yet it appears to be a recommendation applicable to certification authorities. 8. "Alternatively, the server could have a list of all SIP domain names is allowed to accept connections from" Change "is" to "it is". 9. "the connect-reuse [10] draft discusses this aspect in more detail." I would suggest changing to "connect-reuse [10] discusses this aspect in more detail", to cover the case where [10] becomes an RFC in time. 10. "A proxy MUST use the procedures defined for a User Agent Server (UAS) in Section 7.4 when authenticating a connection from a client." and "A proxy MUST use the procedures defined for a User Agent Client (UAC) in Section 7.3 when requesting an authenticated connection to a UAS." But section 7.4 has the title "Server behavior" and not "UAS behavior", and likewise 7.3 has the title "Client behavior" and not "UAC behavior". When reading those sections I had assumed the referred to the TLS client and server. If we were to make it clear that this is the case, we would not require these statements in 7.5 for a proxy. 11. "A SIP registrar, acting as a server, follows the normative behavior of Section 7.4. When it accepts a TLS connection from the client, it present its certificate. Depending on the registrar policies, it may challenge the client with HTTP Digest." It think this section on registrar behavior is redundant. 12. "A SIP redirect server follows the normative behavior of Section 7.4. It may accept a TLS connection from the client, present its certificate, and then challenge the client with HTTP Digest." I think this section on redirect server behavior is redundant too. 13. "the subjectAltName MAY contain multiple identifiers for the Subject" It is not the function of this draft to make normative statements concerning what can be placed in a certificate. 14. "Since only one certificate is needed for multiple domains, the keying material management is straightforward, but such a certificate MUST be revoked if ANY identifier in the certificate is no longer associated with the holder of the private key for the certificate." This section (7) is concerned with behavior of SIP entities, yet this seems to place a normative requirement on a certification authority. 15. "The TLS extended client hello [7] allows a TLS client to provide to the TLS server the name of the server to which a connection is desired. Thus, the server can present the correct certificate to establish the TLS connection." This doesn't seem to fit too well with the preceding paragraphs in section 7.8, which seem to say that one certificate can have multiple identities, so why the need for different certificates? I think this section needs to be made clearer. 16 "Confidentiality: SIPS messages from alice@example.com to bob@example.edu can be read only by alice@example.com, bob@example.edu, and SIP proxies issued with domain certificates for example.com or example.edu." Any SIP messages (not just those targeted at SIPS URI) expect this property if transported over TLS. Similarly for the next statement on integrity. 17. "8.1. Connection authentication using Digest" I have a problem with this section. Digest authentication, in conjunction with TLS server authentication, is frequently used between certain classes of UA and their outbound proxy because it is impractical to provide those UAs with certificates. One of the functions of sip-outbound is to help make this work. Therefore to say unconditionally that digest is NOT RECOMMENDED is wrong. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: 22 February 2008 07:22 > To: IETF SIP List > Cc: Jeffrey, Alan S A (Alan); slawrence@bluesocket.com > Subject: [Sip] WGLC on domain-certs and eku > > (As WG chair) > > This is to announce a WG last call on BOTH > > http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt > > and > > http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-01.txt > > Comments should be submitted to both the list, and to the authors, by > Friday 7th March 2008. This will give the opportunity for > discussion of > major issues at the SIP WG meeting in Philadelphia. > > Please clearly identify the position of any issue in the > internet draft, > and if possible identify what you would like to see as a correction. > Please also indicate the nature or severity of the error or > correction, > e.g. Major technical, minor technical, NIT, so that we can > quickly judge > the extent of problems with the document. > > Note that both these documents are used by: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu se-09.txt > > This particular document is finished and ready for the publication > request, but if you feel your comment also addresses the usage by this > document, please clearly indicate and get the comment in. > > Regards > > Keith > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 08:54:16 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBDC28C972; Thu, 28 Feb 2008 08:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbG3HMLGmXg2; Thu, 28 Feb 2008 08:54:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F8428C925; Thu, 28 Feb 2008 08:54:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2802F28C858 for ; Thu, 28 Feb 2008 08:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7t6pwSQTRTn for ; Thu, 28 Feb 2008 08:53:54 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3697428C8CA for ; Thu, 28 Feb 2008 08:53:07 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWY00KB3K8ACB@siemenscomms.co.uk> for sip@ietf.org; Thu, 28 Feb 2008 16:53:00 +0000 (GMT) Date: Thu, 28 Feb 2008 16:52:41 +0000 From: "Elwell, John" In-reply-to: <5D1A7985295922448D5550C94DE2918001C68A17@DEEXC1U01.de.lucent.com> To: "DRAGE, Keith (Keith)" , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D070BC45@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] WGLC on domain-certs and eku - Comments on eku Thread-Index: Ach1I47x4nFLQ/r9Sf6PE1fK5hI8NAE+dr3A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001C68A17@DEEXC1U01.de.lucent.com> Cc: slawrence@bluesocket.com Subject: Re: [Sip] WGLC on domain-certs and eku - Comments on eku X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 1. "Certificates whose purpose is to bind a SIP domain identity without binding other non-SIP identities MUST include an id-kp-SIPdomain attribute." I have several comments on this statement. a) It seems premature to make this statement prior to the explanation that occurs in 3.1. b) Is "MUST" appropriate at this stage, or would it be more appropriate to include such normative language later in the document, e.g., in section 5? c) It looks like it might be in conflict with the later statement: "Whether or not to include this restriction is up to the certificate issuer" 2. "but if it is included, it MUST be marked as critical" Wouldn't this be more appropriate in section 5? 3. "3. If any EKU is present and contains both id-kp-anyExtendedKeyUsage and id-kp-sipDomain, accept the certificate." This may be my lack of expertise in this area, but isn't there another case where id-kp-sipDomain is present but id-kp-anyExtendedKeyUsage is not present? If so, how is this handled. Similarly in the normative text that precedes this descriptive flow. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: 22 February 2008 07:22 > To: IETF SIP List > Cc: Jeffrey, Alan S A (Alan); slawrence@bluesocket.com > Subject: [Sip] WGLC on domain-certs and eku > > (As WG chair) > > This is to announce a WG last call on BOTH > > http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt > > and > > http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-01.txt > > Comments should be submitted to both the list, and to the authors, by > Friday 7th March 2008. This will give the opportunity for > discussion of > major issues at the SIP WG meeting in Philadelphia. > > Please clearly identify the position of any issue in the > internet draft, > and if possible identify what you would like to see as a correction. > Please also indicate the nature or severity of the error or > correction, > e.g. Major technical, minor technical, NIT, so that we can > quickly judge > the extent of problems with the document. > > Note that both these documents are used by: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu > se-09.txt > > This particular document is finished and ready for the publication > request, but if you feel your comment also addresses the usage by this > document, please clearly indicate and get the comment in. > > Regards > > Keith > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 08:54:23 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F6C28C7F9; Thu, 28 Feb 2008 08:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey9+obNKNBwR; Thu, 28 Feb 2008 08:54:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B22728C862; Thu, 28 Feb 2008 08:54:06 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966B928C939 for ; Thu, 28 Feb 2008 08:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn9bx49MltRM for ; Thu, 28 Feb 2008 08:54:03 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B74043A6E77 for ; Thu, 28 Feb 2008 08:53:42 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Feb 2008 11:53:19 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 28 Feb 2008 11:53:19 -0500 From: Hadriel Kaplan To: Miguel Garcia , Jonathan Rosenberg Date: Thu, 28 Feb 2008 11:53:33 -0500 Thread-Topic: [Sip] Comments to the TOTE draft Thread-Index: Ach6H1tss1xdpgHxSHelfx5FbqXhtAACML9Q Message-ID: References: <47C54730.5030501@nsn.com> <47C5DCA6.9080302@cisco.com> <47C680E3.2030803@nsn.com> <47C6C841.2010201@cisco.com> <47C6D42D.8040506@nsn.com> In-Reply-To: <47C6D42D.8040506@nsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Miguel Garcia > > > > > So then the question is, is MSRP a general purpose UA to UA transport > > mechanism, or not. Frankly I think it is not. Its designed around > > instant messaging which is a particular application. ITs having > > extensions for things like nicknames and conferencing which are specific > > to IM. The reporting feature is also IMHO very much an IM-specific > thing. > > I disagree here. You said: > - It is designed around instant messaging: I would say MSRP is designed > around real-time transfer of objects. The MSRP draft provides examples > and provisions for transferring, for example, large video files. > - It's having extensions for things like nicknames and conferencing > which are specific to conferencing: I don't see the point here. It is > like if you tell me that SIP is not good for voice because there are > extensions for presence, instant messaging and alike. MSRP is generic > enough to carry objects between two points. Extensions try to improve > the user experience for specific applications. Not really. We *DO* say SIP is not appropriate for carrying the voice itself (vs. RTP), or not appropriate for carrying session-based IM (vs. MSRP). We say that because of SIP's properties compared to the needs/properties of voice or IM or whatever. I assume we all agree on that. MSRP also has properties. Some of them frankly aren't very good for bulk file transfer, IMHO. One of those "properties" is it doesn't seem to be getting deployed UA-UA. It's getting deployed UA-AS-AS-UA, where "AS" is an app server or SBC or both either acting as an MSRP-relay or MSRP-b2bua. (it shouldn't be a surprise this is happening - the MSRP protocol leaves no other choice) I don't think it's a good property that a bulk file transfer gets sent through a chain of app servers. I don't think it's a good property that camera controls get sent through a chain of app servers. My 2 cents anyway. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 09:29:36 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB47328C8F0; Thu, 28 Feb 2008 09:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bytfXz7yWdh4; Thu, 28 Feb 2008 09:29:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207DB28C986; Thu, 28 Feb 2008 09:29:17 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277E128C983 for ; Thu, 28 Feb 2008 09:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLMFIQ9jlQQl for ; Thu, 28 Feb 2008 09:29:10 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 76EEF28C9C1 for ; Thu, 28 Feb 2008 09:28:48 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 207415081A for ; Thu, 28 Feb 2008 09:30:33 -0800 (PST) Date: Thu, 28 Feb 2008 09:30:33 -0800 From: Eric Rescorla To: sip@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080228173033.207415081A@romeo.rtfm.com> Subject: [Sip] Review of draft-ietf-sip-media-security-requirements-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org $Id: draft-ietf-sip-media-security-requirements-03-rev.txt,v 1.1 2008/02/28 17:10:00 ekr Exp $ GENERAL COMMENTS I'm concerned about the apparent lack of stability of this draft. When this draft was originally published, it seemed to me to have two purposes: - To capture the BOF consensus on the important security properties for an RTPSEC protocol. - To be a survey for the properties of the various protocols compared to those requirements. The first purpose still seems useful to me, but is best served by having a draft that reflects that consensus published ASAP. The second purpose seems to me to have been sort of overtaken by events and I'm not sure it's still valuable. With the first purpose firmly in mind, it seems a little problematic that this draft has changed so much in the past 6-12 months. In particular: - The -02 version totally renamed all the requirements - I'm not convinced that all the requirements introduced in -00 have WG consensus. Since there are other documents which need to reference these requirements, this presents a problem for them. IMO we should try to quickly converge on the requirements we have consensus on, remove others, and publish this document as a historical statement. We should also consider whether the appendices with the survey of the protocols is really that useful in an archival document. DETAILED COMMENTS S 4.2. retargeting problem. While Connected Identity [RFC4916] allows positive identification of the called party, the primary difficulty still remains that the calling party does not know if a mismatched called party is legitimate (i.e., due to authorized retargeting) or illegitimate (i.e., due to unauthorized retargeting by an attacker above to modify SIP signaling). This is totally true, but it's not a media security issue. It's a SIP issue. S 4.3. though it does consume additional cryptographic context on the mixer for each participant and has the advantage of non-repudiation of the originator of the incoming stream. This isn't non-repudiation. It's data origin authentication. When you have a shared group key, anyone who has the key can impersonate anyone else. Pairwise keys remove this problem, but they don't stop me from forging data on our pairwise and claiming it's from you to a third party. That's non-repudiation. Also, this section needs discussion of the advantages and disadvantages of (d). R-ID-BINDING: This requirement doesn't really make sense as stated. What needs to be bound isn't an identifier, it's the media security keys. Imagine a scheme in which new raw DH shares were generated for each connection and the public share was Identity signed. That's not an identifier, but it's secure. R-RECORDING: I don't believe that there is WG consensus on this requirement. R-TRANSCODER: I don't think this requirement makes sense as stated. Any SRTP-using system can always allow transcoding by having one side share the keys with the transcoder. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 09:49:06 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EDE3A6ED4; Thu, 28 Feb 2008 09:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-1.562, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EGdRlw+NulH; Thu, 28 Feb 2008 09:49:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EEE83A6B59; Thu, 28 Feb 2008 09:48:56 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6A828C822 for ; Thu, 28 Feb 2008 09:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnnVyEXDfRMe for ; Thu, 28 Feb 2008 09:48:49 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 794293A6923 for ; Thu, 28 Feb 2008 09:47:18 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Feb 2008 09:47:11 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1SHl97C005923; Thu, 28 Feb 2008 09:47:09 -0800 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 m1SHkIBV010404; Thu, 28 Feb 2008 17:47:04 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 12:46:22 -0500 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 12:46:21 -0500 Message-ID: <47C6F37B.7010609@cisco.com> Date: Thu, 28 Feb 2008 12:46:35 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Rockson Li (zhengyli)" References: In-Reply-To: X-OriginalArrivalTime: 28 Feb 2008 17:46:21.0824 (UTC) FILETIME=[D48FD000:01C87A31] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2095; t=1204220829; x=1205084829; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Contact=20header=20in=201xx=20r esponses/updates=20remote=20target=20or=0A=20not? |Sender:=20; bh=vEuyQcujEUPm5ySsSS7z9Khfj/ayaRfzGQlv8XNHsGc=; b=e73xnZI5pjDkNdn843bB4Gk7LBqAIAiyQPQOI0dT2i3k/UWkZjVBafvspt FwxaVwUvv8plWFrGVHVkrrOmfoth0KVHs/otyFLKu9MDQxoGg/49C+Ts7ajY hL2HD1M6ic; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, christer.holmberg@ericsson.com Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org No, I don't think we have an answer, though I do have an opinion. :-) Are you asking about whether the contact may be omitted? Or if it may be changed? AFAIK there is nothing normative that *forbids* the contact from being changed in subsequent provisional responses. But doing so is *asking* for trouble, so you shouldn't do it. Perhaps you could get away with it in a *reliable* provisional, but then you would still have a bunch of messy cases. The likelihood of it working is slim. Doing it with *unreliable* provisionals is going to cause trouble because they can be lost. Even with reliable provisionals, you will have to be prepared to receive on both addresses for some period of time. It seems clear that a contact may be omitted in a 100, since it is hop by hop, and presumably must be omitted in the 100 responses from proxies. Some other 1xx responses may be returned by proxies (notably 181) and presumably they should also not contain a contact in those cases. A 1xx that establishes an early dialog must contain a contact or else you really don't have a dialog. I think it is ambiguous whether: - the first 1xx with a particular to-tag *does* establish an early dialog and so *must* contain a contact, - OR a 1xx with a new to-tag, but without a contact, simply doesn't establish a dialog, but is legal. I would split the difference and say that the UAS MUST include a contact in the first 1xx it returns with a particular to-tag, but a UAC should accept a 1xx with new to-tag and without a contact and simply treat it as not establishing an early dialog. (Don't establish the dialog until you get enough info to do so.) Paul Rockson Li (zhengyli) wrote: > Paul , Christer and all, > > I am following the email thread as in subject above > http://www.ietf.org/mail-archive/web/sip/current/msg19322.html > > However, I do not find the definite answer to Christer's question, > Do we have the answer now? > > Thanks a lot > > Regards, > Rockson Li > > Cisco R&D Center, Shanghai, PRC > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 10:08:33 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95593A6F03; Thu, 28 Feb 2008 10:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgQd3wZU+gXi; Thu, 28 Feb 2008 10:08:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5EC3A68E1; Thu, 28 Feb 2008 10:08:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A7A3A688D for ; Thu, 28 Feb 2008 10:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvscWAj9Icho for ; Thu, 28 Feb 2008 10:08:21 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C43013A69D9 for ; Thu, 28 Feb 2008 10:08:04 -0800 (PST) Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1SI7tWT015741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 28 Feb 2008 12:07:57 -0600 Message-ID: <47C6F876.4060809@softarmor.com> Date: Thu, 28 Feb 2008 12:07:50 -0600 From: Dean Willis User-Agent: Icedove 1.5.0.14pre (X11/20080208) MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.94.2.0 Subject: [Sip] Doc we need to have draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Is there any need for discussion of the DTLS framework (draft-ietf-sip-dtls-srtp-framework-01) during our meeting? The authors think that it is pretty much ready for WGLC and that all known issues have been resolved. The list has been fairly quiet on the topic. Anybody read the new version yet and have an opinion? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 10:09:41 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DFB3A6E7B; Thu, 28 Feb 2008 10:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=-1.552, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOca1jEn2zY9; Thu, 28 Feb 2008 10:09:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929FE3A6EDF; Thu, 28 Feb 2008 10:09:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08CB43A6BDB for ; Thu, 28 Feb 2008 10:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu5tLpta+YZm for ; Thu, 28 Feb 2008 10:09:25 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B100628C83B for ; Thu, 28 Feb 2008 10:09:20 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Feb 2008 10:09:13 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1SI9CKB000417; Thu, 28 Feb 2008 10:09:13 -0800 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 m1SI8vBn027670; Thu, 28 Feb 2008 18:09:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 13:09:00 -0500 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 13:08:59 -0500 Message-ID: <47C6F8CA.2080305@cisco.com> Date: Thu, 28 Feb 2008 13:09:14 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <47C54730.5030501@nsn.com> <47C5DCA6.9080302@cisco.com> <47C680E3.2030803@nsn.com> <47C6C841.2010201@cisco.com> <47C6D42D.8040506@nsn.com> In-Reply-To: X-OriginalArrivalTime: 28 Feb 2008 18:08:59.0848 (UTC) FILETIME=[FE01D480:01C87A34] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4185; t=1204222153; x=1205086153; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Comments=20to=20the=20TOTE=20dr aft |Sender:=20; bh=ZwwLJ30kAXSnis/OZBE2OCYakQhCTQXx8yu0sx+ms38=; b=s6S368qKOCLUmleJMB6aEI8loYeWtbzfObw+M2gfsMuAqELdYrj9h5uunD 26nmgN8GhFkl+CzIgWbGQ8ezHuVZDY1rlulZV9n2rZihbsDGgiy1ErNwgF/L v2m9jrhVyS; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: IETF SIP List , Miguel Garcia Subject: Re: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Just jumping in, not replying to anyone in particular... I don't see the relationship between TOTE-like functionality and File Transfer at all. But I do see MSRP as an alternative to TOTE for the kinds of things Jonathan is proposing TOTE for. Advantages of using MSRP are: - its already defined - it already has all the mime type negotiation defined - it has some mechanisms to mitigate the head of line blocking issue - whatever is done to get MSRP through firewalls and proxies could be reused for this application - the exchange of mime objects as envisioned for tote could share a connection with IM if IM happens to be in use Some disadvantages: - its heavier weight than what Jonathan is proposing - there may be issues with MSRP relays The heavier weight of MSRP is an issue for UAs that won't otherwise be implementing MSRP anyway. For those that do its probably not an issue. OTOH, more uses for the protocol may serve to encourage ubiquitous implementation. The use of relays vs using ICE to get though FWs and NATs has already been brought up for MSRP in general I think. Perhaps that needs to be considered. OTOH, the use of media intermediaries of one sort or another for MSRP is likely to be required in many cases, at least in enterprises, because they have a need to log the stuff for legal or other business reasons. It may well be that the same people would conclude that they need to log TOTE exchanges too, because it otherwise might be used to tunnel things. So it may be that e2e media connections won't be allowed in any case. Bottom line: I haven't yet decided if I like TOTE or would prefer to see MSRP used for that purpose. Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Miguel Garcia >> >>> So then the question is, is MSRP a general purpose UA to UA transport >>> mechanism, or not. Frankly I think it is not. Its designed around >>> instant messaging which is a particular application. ITs having >>> extensions for things like nicknames and conferencing which are specific >>> to IM. The reporting feature is also IMHO very much an IM-specific >> thing. >> >> I disagree here. You said: >> - It is designed around instant messaging: I would say MSRP is designed >> around real-time transfer of objects. The MSRP draft provides examples >> and provisions for transferring, for example, large video files. >> - It's having extensions for things like nicknames and conferencing >> which are specific to conferencing: I don't see the point here. It is >> like if you tell me that SIP is not good for voice because there are >> extensions for presence, instant messaging and alike. MSRP is generic >> enough to carry objects between two points. Extensions try to improve >> the user experience for specific applications. > > Not really. We *DO* say SIP is not appropriate for carrying the voice itself (vs. RTP), or not appropriate for carrying session-based IM (vs. MSRP). We say that because of SIP's properties compared to the needs/properties of voice or IM or whatever. I assume we all agree on that. > > MSRP also has properties. Some of them frankly aren't very good for bulk file transfer, IMHO. One of those "properties" is it doesn't seem to be getting deployed UA-UA. It's getting deployed UA-AS-AS-UA, where "AS" is an app server or SBC or both either acting as an MSRP-relay or MSRP-b2bua. (it shouldn't be a surprise this is happening - the MSRP protocol leaves no other choice) > > I don't think it's a good property that a bulk file transfer gets sent through a chain of app servers. I don't think it's a good property that camera controls get sent through a chain of app servers. My 2 cents anyway. > > -hadriel > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 10:23:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618023A6EE2; Thu, 28 Feb 2008 10:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-jKhKxr4+7v; Thu, 28 Feb 2008 10:23:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E36728C983; Thu, 28 Feb 2008 10:21:39 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC263A6A3A for ; Thu, 28 Feb 2008 10:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKPH9PU-M1xR for ; Thu, 28 Feb 2008 10:21:37 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 48DC228CA91 for ; Thu, 28 Feb 2008 10:20:34 -0800 (PST) Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1SIKLig015946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2008 12:20:23 -0600 Message-ID: <47C6FB5F.8090209@softarmor.com> Date: Thu, 28 Feb 2008 12:20:15 -0600 From: Dean Willis User-Agent: Icedove 1.5.0.14pre (X11/20080208) MIME-Version: 1.0 To: "James M. Polk" References: <20080224054501.90B6A3A6A07@core3.amsl.com> <200802250404.m1P44eZm023626@dragon.ariadne.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org James M. Polk wrote: > >> Abstract: >> >> This document creates additional Session Initiation Protocol >> Resource-Priority namespaces, and places these namespaces in the >> IANA register. >> >> As an editorial matter, can the abstract be made less vague? Such as >> mentioning that it creates a set of namespaces for the use of the US >> Defense Information Systems Agency... > > well, at least I didn't overstate things... ;-) > > I can change this if you want me to Since I personally only read the abstract of new drafts and extrapolate all further content (including any errors) by intuitive deduction, I'm sure that a more detailed abstract would be helpful. ;-) Seriously, a well-written abstract is a big help for people who haven't been reading along with the development. Many students I've talked to start with the abstract, and then use that to decide how the RFC fits into the mental framework they're building as they try to come to grips with the documentation-kraken that SIP has become. We should be careful to make our abstracts as useful for this sort of thing as we can. That means that the abstract needs to tell us what the draft is about well enough to fit it into a framework, but not tell us much about the implementation detail. Admittedly, it is a fine balancing act -- but I'm afraid the abstract for the draft in question hasn't even stepped up to the high-wire, much less maintained its balance. -- dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 10:33:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BFCB3A6EE8; Thu, 28 Feb 2008 10:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIPk-aHtTFaG; Thu, 28 Feb 2008 10:33:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5DA28C0E1; Thu, 28 Feb 2008 10:33:46 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66BD28C2CB for ; Thu, 28 Feb 2008 10:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+qxwZoLygkk for ; Thu, 28 Feb 2008 10:33:44 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CB26C3A6E69 for ; Thu, 28 Feb 2008 10:33:38 -0800 (PST) Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1SIXQ5A016108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2008 12:33:28 -0600 Message-ID: <47C6FE6D.1040504@softarmor.com> Date: Thu, 28 Feb 2008 12:33:17 -0600 From: Dean Willis User-Agent: Icedove 1.5.0.14pre (X11/20080208) MIME-Version: 1.0 To: Hadriel Kaplan References: <20080227003651.265505081A@romeo.rtfm.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Cc: "sip@ietf.org" , "draft-kupwade-sip-iba@tools.ietf.org" Subject: Re: [Sip] Review of draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > Cool. So if I understand this right (and I probably don't), ignoring > rfc4474 identity and IBS for a moment and instead thinking about SRTP > and IBE: I could use IBE to encrypt the security-descriptions > attribute value using the intended target's SIP URI as a key, and > only someone owning that URI (and sharing the same KG) or the KG > itself could decrypt it to learn the sec-desc cleartext to use? Actually, there are partial-key models where the KG couldn't decrypt it either. There are modes of operation that allow the full private key to be a product of a secret (retained by the user) and the output of the PKG. Hence you need to know both parts to decrypt or sign a message. > -hadriel p.s. the KG would actually be a problem for IBE, wouldn't > it? I mean the KG can always decrypt it. (at which point they would > be the Key Generator Backdoor - aka, the KGB ;) Yep. Early IB systems worked as you describe. But they don't HAVE to work that way. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 10:39:04 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D43728C960; Thu, 28 Feb 2008 10:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXIjOP2yU4+6; Thu, 28 Feb 2008 10:38:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9F43A6A7C; Thu, 28 Feb 2008 10:38:57 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A6F28C8B0 for ; Thu, 28 Feb 2008 10:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBulu-HnH7qY for ; Thu, 28 Feb 2008 10:38:51 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B47A428C900 for ; Thu, 28 Feb 2008 10:38:30 -0800 (PST) Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1SIcLWL016153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2008 12:38:23 -0600 Message-ID: <47C6FF98.8000707@softarmor.com> Date: Thu, 28 Feb 2008 12:38:16 -0600 From: Dean Willis User-Agent: Icedove 1.5.0.14pre (X11/20080208) MIME-Version: 1.0 To: Eric Rescorla References: <20080227163900.8BD695081A@romeo.rtfm.com> <159863.80038.qm@web65510.mail.ac4.yahoo.com> <20080227170702.5A5C05081A@romeo.rtfm.com> In-Reply-To: <20080227170702.5A5C05081A@romeo.rtfm.com> X-Enigmail-Version: 0.94.2.0 Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: > At Wed, 27 Feb 2008 08:59:10 -0800 (PST), > Harsh Kupwade wrote: >> [1 ] >> How can we verify a certificate from a random CA? It will definitely >> be a serious threat in the near future. > > Uh, that the trust anchors are publicly known and compiled into > your client. Ok, so check out https://www.softarmor.com and tell me how it works out. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 10:46:48 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1384328C990; Thu, 28 Feb 2008 10:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyjY-V7FgbTV; Thu, 28 Feb 2008 10:46:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CF728C87C; Thu, 28 Feb 2008 10:46:42 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93EF128C87C for ; Thu, 28 Feb 2008 10:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v10r0Mv7AYdl for ; Thu, 28 Feb 2008 10:46:36 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2324E3A6BC2 for ; Thu, 28 Feb 2008 10:46:36 -0800 (PST) Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1SIkRXw016262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2008 12:46:28 -0600 Message-ID: <47C7017D.5020301@softarmor.com> Date: Thu, 28 Feb 2008 12:46:21 -0600 From: Dean Willis User-Agent: Icedove 1.5.0.14pre (X11/20080208) MIME-Version: 1.0 To: Eric Rescorla References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> In-Reply-To: <20080227171901.8EAE95081A@romeo.rtfm.com> X-Enigmail-Version: 0.94.2.0 Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: > In any case, I'm not sure why we're having this discusion since > all the same trust issues apply to IBE schemes. The only respect > in which they don't apply to IBE schemes is if you have a single > global KG, but of course you could have a single global CA, > too. It's just that nobody wants to do either. A global or semi-global KG makes excellent sense in large domains, especially where there are significant resource constraints. Consider, for example, the 3GPP world of GSM phones. A KG hierarchy rooted at the GSMA with each operator then having a subordinate KG could make a lot of sense. We could get end-to-end security with significantly fewer bits being transmitted than if users had to send copies of their certificates along with every message. Similar characteristics apply in peer-to-peer cases. The enrollment process could include a KG interaction. The resulting identity could be used with IBS for node identification in the overlay as well as message source verification ("identity" in and RFC 4474 context). This helps prevent a number of the easy attacks on P2P infrastructure. And of course, IBE could provide for message privacy as well as integrity across the untrusted peers that will be serving as proxies. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 10:50:23 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B963A6ECE; Thu, 28 Feb 2008 10:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw1qZCtshm4A; Thu, 28 Feb 2008 10:50:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F5228C8E0; Thu, 28 Feb 2008 10:49:53 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E43328C919 for ; Thu, 28 Feb 2008 10:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQV3N-m52zZO for ; Thu, 28 Feb 2008 10:49:47 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id B982828C9E4 for ; Thu, 28 Feb 2008 10:47:39 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7174A5081A; Thu, 28 Feb 2008 10:49:24 -0800 (PST) Date: Thu, 28 Feb 2008 10:49:24 -0800 From: Eric Rescorla To: Dean Willis In-Reply-To: <47C6FE6D.1040504@softarmor.com> References: <20080227003651.265505081A@romeo.rtfm.com> <47C6FE6D.1040504@softarmor.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080228184924.7174A5081A@romeo.rtfm.com> Cc: "sip@ietf.org" , "draft-kupwade-sip-iba@tools.ietf.org" Subject: Re: [Sip] Review of draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Thu, 28 Feb 2008 12:33:17 -0600, Dean Willis wrote: > > Hadriel Kaplan wrote: > > Cool. So if I understand this right (and I probably don't), ignoring > > rfc4474 identity and IBS for a moment and instead thinking about SRTP > > and IBE: I could use IBE to encrypt the security-descriptions > > attribute value using the intended target's SIP URI as a key, and > > only someone owning that URI (and sharing the same KG) or the KG > > itself could decrypt it to learn the sec-desc cleartext to use? > > Actually, there are partial-key models where the KG couldn't decrypt it > either. > > There are modes of operation that allow the full private key to be a > product of a secret (retained by the user) and the output of the PKG. > Hence you need to know both parts to decrypt or sign a message. Not precisely. 1. There are schemes which have multiple KGs which all have to cooperate in order to recover the private key (that's what Harsh referred to the other day). 2. There are "forward secure" schemes (Gentry) in which the KG forgets your private key and the ability to regenerate it. However, both of these still have escrow as a sort of inherent property. It's pretty easy to see that any true IBE scheme has to have escrow: The fundamental IBE property is that any random person can encrypt to any identity I knowing only the public system parameters P_pub, and then for the KG to be able to provide the appropriate K_priv from P_priv and I. In order for this to work, you need to be able to compute: - K_pub = F1(P_pub, I) - K_priv = F2(P_priv, I) If the user provides some information X that's not known to the KG *and* X is required to decrypt, then it clearly must affect K_pub, i.e., - K_pub = F1(P_pub, I, X) But that violates the invariant that K_pub is deterministically generated from I and P_pub--and it's precisely this invariant that makes IBE interesting. This doesn't apply to IBS, of course, since there's no requirement that the verifier be able to independently compute K_pub. In fact, one could argue under one definition that a PKI scheme is an IBS scheme and that X is the user's public key and F1 is certificate verification. But it's precusely because this invariant isn't interesting in IBS that IBS doesn't add much value over PKI. > Yep. Early IB systems worked as you describe. But they don't HAVE to > work that way. Citations, please? -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 10:54:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78FEE3A6E92; Thu, 28 Feb 2008 10:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDzwMtnxanZq; Thu, 28 Feb 2008 10:54:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A2F3A6A7C; Thu, 28 Feb 2008 10:54:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D913A6BCC for ; Thu, 28 Feb 2008 10:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHZeTjYrV9GD for ; Thu, 28 Feb 2008 10:54:27 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 69D0C3A6A3A for ; Thu, 28 Feb 2008 10:54:27 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Feb 2008 13:54:04 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 28 Feb 2008 13:54:04 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Thu, 28 Feb 2008 13:54:17 -0500 Thread-Topic: [Sip] Comments to the TOTE draft Thread-Index: Ach6NQTMx5NAwmqbRu2uT5ltLfuQqQAARWdQ Message-ID: References: <47C54730.5030501@nsn.com> <47C5DCA6.9080302@cisco.com> <47C680E3.2030803@nsn.com> <47C6C841.2010201@cisco.com> <47C6D42D.8040506@nsn.com> <47C6F8CA.2080305@cisco.com> In-Reply-To: <47C6F8CA.2080305@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List , Miguel Garcia Subject: Re: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, February 28, 2008 1:09 PM > > Advantages of using MSRP are: > ... > - it has some mechanisms to mitigate the head of line blocking issue MSRP needs that because it creates the problem for itself (or rather allows it to happen), because it lets multiple logical use or user connections be aggregated into one TCP connection. I'm not saying that's good/bad, but for TOTE that wouldn't be an issue needing to be solved, afaict. > The heavier weight of MSRP is an issue for UAs that won't otherwise be > implementing MSRP anyway. For those that do its probably not an issue. > OTOH, more uses for the protocol may serve to encourage ubiquitous > implementation. If the idea is to provide a media-path-channel alternative for some of the more media-applicable uses of INFO in the wild, the hurdle of MSRP would be immense. Making vendors choose between either implementing SIP+INFO, or SIP+MSRP? That's not a hard choice to choose from, and they'll choose poorly. > OTOH, the use of media intermediaries of one sort or another for MSRP is > likely to be required in many cases, at least in enterprises, because > they have a need to log the stuff for legal or other business reasons. > It may well be that the same people would conclude that they need to log > TOTE exchanges too, because it otherwise might be used to tunnel things. > So it may be that e2e media connections won't be allowed in any case. I have no doubt that would be needed in some cases, maybe even most cases. There is, however, a HUGE difference between *monitoring* TCP stream data payload contents, and *modifying* TCP stream data payload contents. MSRP requires modifying, even just for NAT traversal (today). Some vendors have started to implement proprietary extensions, to avoid that. That's not a good thing. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 11:05:02 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0F43A6DF3; Thu, 28 Feb 2008 11:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCfRKH318fI4; Thu, 28 Feb 2008 11:04:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540263A6E1D; Thu, 28 Feb 2008 11:04:58 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8F23A6E89 for ; Thu, 28 Feb 2008 11:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB2npMRKLMkn for ; Thu, 28 Feb 2008 11:04:56 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id A67633A6E1D for ; Thu, 28 Feb 2008 11:04:56 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 6FADC5081A; Thu, 28 Feb 2008 11:06:41 -0800 (PST) Date: Thu, 28 Feb 2008 11:06:41 -0800 From: Eric Rescorla To: Dean Willis In-Reply-To: <47C6FF98.8000707@softarmor.com> References: <20080227163900.8BD695081A@romeo.rtfm.com> <159863.80038.qm@web65510.mail.ac4.yahoo.com> <20080227170702.5A5C05081A@romeo.rtfm.com> <47C6FF98.8000707@softarmor.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080228190641.6FADC5081A@romeo.rtfm.com> Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Thu, 28 Feb 2008 12:38:16 -0600, > Dean Willis wrote: > Eric Rescorla wrote: > > At Wed, 27 Feb 2008 08:59:10 -0800 (PST), > > Harsh Kupwade wrote: > >> [1 ] > >> How can we verify a certificate from a random CA? It will definitely > >> be a serious threat in the near future. > > > > Uh, that the trust anchors are publicly known and compiled into > > your client. > > Ok, so check out https://www.softarmor.com and tell me how it works out. What point are you trying to make? A certificate is a data format. Obviously, it's possible to have a certificate signed by a trust anchor that isn't commonly trusted. So what? For the Nth time, this is equally possible with an identity-based scheme. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 11:13:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111BB3A6F31; Thu, 28 Feb 2008 11:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRjhlvakjSoc; Thu, 28 Feb 2008 11:13:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9ED3A6E28; Thu, 28 Feb 2008 11:13:31 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71DBA3A67B3 for ; Thu, 28 Feb 2008 11:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EancSs-ueF9P for ; Thu, 28 Feb 2008 11:13:29 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 9667E3A6EEE for ; Thu, 28 Feb 2008 11:12:23 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 677435081A; Thu, 28 Feb 2008 11:14:08 -0800 (PST) Date: Thu, 28 Feb 2008 11:14:08 -0800 From: Eric Rescorla To: Dean Willis In-Reply-To: <47C7017D.5020301@softarmor.com> References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080228191408.677435081A@romeo.rtfm.com> Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Thu, 28 Feb 2008 12:46:21 -0600, Dean Willis wrote: > > Eric Rescorla wrote: > > > In any case, I'm not sure why we're having this discusion since > > all the same trust issues apply to IBE schemes. The only respect > > in which they don't apply to IBE schemes is if you have a single > > global KG, but of course you could have a single global CA, > > too. It's just that nobody wants to do either. > > A global or semi-global KG makes excellent sense in large domains, > especially where there are significant resource constraints. > > Consider, for example, the 3GPP world of GSM phones. A KG hierarchy > rooted at the GSMA with each operator then having a subordinate KG could > make a lot of sense. We could get end-to-end security with significantly > fewer bits being transmitted than if users had to send copies of their > certificates along with every message. > > Similar characteristics apply in peer-to-peer cases. The enrollment > process could include a KG interaction. The resulting identity could be > used with IBS for node identification in the overlay as well as message > source verification ("identity" in and RFC 4474 context). This helps > prevent a number of the easy attacks on P2P infrastructure. Yes, and this is all equally possible with PKI systems. As I said at the beginning, the only thing that IBS is bringing to the party here is a smaller credential. As far as I'm awre, the size of the cert is not the primary reason for lack of adoption of any of these schemes Again, what does IBS bring to the party except compression? [0]. > And of > course, IBE could provide for message privacy as well as integrity > across the untrusted peers that will be serving as proxies. And now we're talking about something totally different: IBE. I agree that IBE has significantly different characteristics from PKI. The problems with IBE in SIP are totally different: namely not knowing the actual identity of the recipietn of the message. This is the norm in both SIP (retargeting) and P2P (churn) systems. -Ekr [0] It's worth noting that the combination of using ECC and doing LZW on certificates would significantly shrink the size of the cert. I haven't done the math, but I suspect down to the point where it's not the dominant factor. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 11:19:11 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2718E28C73D; Thu, 28 Feb 2008 11:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4TyIpXSwSAL; Thu, 28 Feb 2008 11:19:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996153A6C5C; Thu, 28 Feb 2008 11:19:05 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DF33A6C5C for ; Thu, 28 Feb 2008 11:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8ZSI3AwYis1 for ; Thu, 28 Feb 2008 11:18:58 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 54CD73A6A47 for ; Thu, 28 Feb 2008 11:18:58 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2008 11:18:51 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1SJInE6014906; Thu, 28 Feb 2008 11:18:49 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1SJIQSS021511; Thu, 28 Feb 2008 19:18:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 11:18:42 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 11:18:41 -0800 Message-ID: <47C70906.8000802@cisco.com> Date: Thu, 28 Feb 2008 14:18:30 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <47C6F876.4060809@softarmor.com> In-Reply-To: <47C6F876.4060809@softarmor.com> X-OriginalArrivalTime: 28 Feb 2008 19:18:41.0825 (UTC) FILETIME=[BAA8E110:01C87A3E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=956; t=1204226329; x=1205090329; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Doc=20we=20need=20to=20have=20d raft-ietf-sip-dtls-srtp-framework-01=0A=20on=20the=20-71=20a genda? |Sender:=20; bh=mQ+8R1R46a7/a0Bfs3DSSasX0h+VHIq/ORPkRCOr/Js=; b=hgL3J+U29MuwzEEe2TJ9MmigQWm+rhNOhWWNggAYIux7eRs23D7aKPH154 xDuN+ZWGlwml5VpfNRM9wYjpGM/NSrNqYFj32D9ruUJBCWJ/9el7vibgq00G MYa+w7Rb8f; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Doc we need to have draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Is there any need for discussion of the DTLS framework > (draft-ietf-sip-dtls-srtp-framework-01) during our meeting? > > The authors think that it is pretty much ready for WGLC and that all > known issues have been resolved. I do not agree. One of the points I raise in my rfc4474-concerns draft is that dtls-srtp is basing integrity of the fingerprint on 4474, and that 4474 does not provide integrity against intermediary modifications of the number, and even for user@domain names this can happen. I think this needs to be called out in the draft. The security considerations section does not discuss this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 11:29:09 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AF23A6D21; Thu, 28 Feb 2008 11:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ9XdoodD4Xd; Thu, 28 Feb 2008 11:29:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8073C3A699E; Thu, 28 Feb 2008 11:29:08 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FECA3A67F2 for ; Thu, 28 Feb 2008 11:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNIbq1JJXeJz for ; Thu, 28 Feb 2008 11:29:01 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id E63A03A6942 for ; Thu, 28 Feb 2008 11:29:01 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 9E4EF5081A; Thu, 28 Feb 2008 11:30:46 -0800 (PST) Date: Thu, 28 Feb 2008 11:30:46 -0800 From: Eric Rescorla To: Jonathan Rosenberg In-Reply-To: <47C70906.8000802@cisco.com> References: <47C6F876.4060809@softarmor.com> <47C70906.8000802@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080228193046.9E4EF5081A@romeo.rtfm.com> Cc: sip@ietf.org, Dean Willis Subject: Re: [Sip] Doc we need to have draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Thu, 28 Feb 2008 14:18:30 -0500, Jonathan Rosenberg wrote: > > > > Dean Willis wrote: > > Is there any need for discussion of the DTLS framework > > (draft-ietf-sip-dtls-srtp-framework-01) during our meeting? > > > > The authors think that it is pretty much ready for WGLC and that all > > known issues have been resolved. > > I do not agree. > > One of the points I raise in my rfc4474-concerns draft is that dtls-srtp > is basing integrity of the fingerprint on 4474, and that 4474 does not > provide integrity against intermediary modifications of the number, and > even for user@domain names this can happen. > > I think this needs to be called out in the draft. The security > considerations section does not discuss this. Because it's not a DTLS-SRTP issue. It's a SIP/4474 issue. The fingerprint in the SIP messaging does *not* tie the DTLS-SRTP handshake to the phone number or to the domain name. Rather, it ties the media to the SIP signalling. Period. It allows whatever guarantees you are prepared to assert about the signalling to be extended to media. If those guarantees allow you to make assertions about the caller (or callee) identity, then great. If not, then DTLS-SRTP doesn't help, nor is it intended to. Look at it this way: When the phone rings (or your UA shows you that the other side has answered), it can show you some meta-information about who you're talking to. The objections you have to RFC 4474 (and I'm not saying I agree with them) already apply at this point, before a single RTP packet has traversed the wire. This is not a DTLS-SRTP issue. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 11:36:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6693A6F07; Thu, 28 Feb 2008 11:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed7sy39mo6cX; Thu, 28 Feb 2008 11:36:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832D03A6EFF; Thu, 28 Feb 2008 11:36:26 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48A53A6BDC for ; Thu, 28 Feb 2008 11:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILZYkp1mCEDt for ; Thu, 28 Feb 2008 11:36:19 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8D3503A6EF7 for ; Thu, 28 Feb 2008 11:36:19 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1SJZqIn016946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2008 13:35:53 -0600 Message-Id: From: Dean Willis To: IETF SIP List In-Reply-To: <1204099738.16881.21.camel@localhost> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 13:35:46 -0600 References: <5D1A7985295922448D5550C94DE2918001636AF1@DEEXC1U01.de.lucent.com> <200709181506.l8IF6Bmp007748@dragon.ariadne.com> <1203976392.6192.88.camel@localhost> <200802262131.m1QLV7Rm008476@dragon.ariadne.com> <1204099738.16881.21.camel@localhost> X-Mailer: Apple Mail (2.919.2) Cc: Aki Niemi Subject: Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I see that Dale and Aki are discussing this draft. Do we need agenda time in Philadelphia for further discussion, or are we really ready for publication? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 11:55:17 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506233A6F18; Thu, 28 Feb 2008 11:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxrytYTz3+b5; Thu, 28 Feb 2008 11:55:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EAAB3A6EC2; Thu, 28 Feb 2008 11:55:16 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F303A6ED3 for ; Thu, 28 Feb 2008 11:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD0vGWS6nTxC for ; Thu, 28 Feb 2008 11:55:09 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A81B13A6EEE for ; Thu, 28 Feb 2008 11:55:08 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A68BB2130C; Thu, 28 Feb 2008 20:49:14 +0100 (CET) X-AuditID: c1b4fb3e-a81fabb000000b15-50-47c7103add8c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8068D212FF; Thu, 28 Feb 2008 20:49:14 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 20:49:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 20:49:11 +0100 Message-ID: In-Reply-To: <47C6F37B.7010609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Contact header in 1xx responses/updates remote target or not? thread-index: Ach6MfQ+3S5Y7/eVSX+Xy2Vl3VsJiwAEE/nw References: <47C6F37B.7010609@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Rockson Li (zhengyli)" X-OriginalArrivalTime: 28 Feb 2008 19:49:13.0989 (UTC) FILETIME=[FEB6EB50:01C87A42] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I agree with Paul's conclusion. But, I still think that is somethin that we should somehow document and clarify. This is a common reason for interop problems, so just agree on a mailing list and leave it there is not a good thing to do. IF (To-tag && Contact) THEN dialog And, it IS allowed to update the Contact in subsequence provisional responses. But, as Paul said: it is asking for trouble, so it should not be done unless you have a really good reason for it. I also think that updating the Contact in a re-INVITE/UPDATE is asking for trouble. At least you also there need to be prepared to receive requests on both the new and old contact for a period of time. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 28. helmikuuta 2008 19:47 > To: Rockson Li (zhengyli) > Cc: Christer Holmberg; sip@ietf.org > Subject: Re: [Sip] Contact header in 1xx responses/updates > remote target or not? > > No, I don't think we have an answer, though I do have an opinion. :-) > > Are you asking about whether the contact may be omitted? Or > if it may be changed? > > AFAIK there is nothing normative that *forbids* the contact > from being changed in subsequent provisional responses. But > doing so is *asking* for trouble, so you shouldn't do it. > Perhaps you could get away with it in a *reliable* > provisional, but then you would still have a bunch of messy > cases. The likelihood of it working is slim. Doing it with > *unreliable* provisionals is going to cause trouble because > they can be lost. Even with reliable provisionals, you will > have to be prepared to receive on both addresses for some > period of time. > > It seems clear that a contact may be omitted in a 100, since > it is hop by hop, and presumably must be omitted in the 100 > responses from proxies. Some other 1xx responses may be > returned by proxies (notably > 181) and presumably they should also not contain a contact in > those cases. > > A 1xx that establishes an early dialog must contain a contact > or else you really don't have a dialog. I think it is > ambiguous whether: > - the first 1xx with a particular to-tag *does* establish an early > dialog and so *must* contain a contact, > > - OR a 1xx with a new to-tag, but without a contact, simply doesn't > establish a dialog, but is legal. > > I would split the difference and say that the UAS MUST > include a contact in the first 1xx it returns with a > particular to-tag, but a UAC should accept a 1xx with new > to-tag and without a contact and simply treat it as not > establishing an early dialog. (Don't establish the dialog > until you get enough info to do so.) > > Paul > > Rockson Li (zhengyli) wrote: > > Paul , Christer and all, > > > > I am following the email thread as in subject above > > http://www.ietf.org/mail-archive/web/sip/current/msg19322.html > > > > However, I do not find the definite answer to Christer's > question, Do > > we have the answer now? > > > > Thanks a lot > > > > Regards, > > Rockson Li > > > > Cisco R&D Center, Shanghai, PRC > > > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 12:14:20 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C507A28C9CC; Thu, 28 Feb 2008 12:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=-1.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NM1EE2XGHbl; Thu, 28 Feb 2008 12:14:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA3C3A6C2F; Thu, 28 Feb 2008 12:14:14 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C653A69D8 for ; Thu, 28 Feb 2008 12:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5i70-t9nH+O for ; Thu, 28 Feb 2008 12:14:08 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4F8843A68EE for ; Thu, 28 Feb 2008 12:14:08 -0800 (PST) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 28 Feb 2008 12:14:01 -0800 Received: from dhcp-171-71-97-210.cisco.com (dhcp-171-71-97-210.cisco.com [171.71.97.210]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m1SK0Qgk028682; Thu, 28 Feb 2008 12:00:27 -0800 Message-ID: <47C7160A.9030606@cisco.com> Date: Thu, 28 Feb 2008 12:14:02 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eric Rescorla References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <20080228191408.677435081A@romeo.rtfm.com> In-Reply-To: <20080228191408.677435081A@romeo.rtfm.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3016; t=1204228827; x=1205092827; 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:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-kupwade-s ip-iba-00 |Sender:=20 |To:=20Eric=20Rescorla=20; bh=QQ6ZAtLSnUSBFcAHt5F9QfvjJ12Jo+e4RXkzUiBj6lw=; b=nBkb/NdTagFoKR+IkjBR8X6fP9lbu9LHVB5+n8cPgQzWUqa5NRpGqQ37CD BBNaC3Hg1Zavv6RHKLs4O0uMj8x66eU7EBbNu90+EWlKccbCnjcqyjQSmIHb A0YN6I4J6p; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org, Dean Willis Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: > At Thu, 28 Feb 2008 12:46:21 -0600, > Dean Willis wrote: > >> >> A global or semi-global KG makes excellent sense in large domains, >> especially where there are significant resource constraints. >> Are we talking about a trust anchor that isn't DNS and isn't shipped in web browsers currently? >> Consider, for example, the 3GPP world of GSM phones. A KG hierarchy >> rooted at the GSMA with each operator then having a subordinate KG could >> make a lot of sense. We could get end-to-end security with significantly >> fewer bits being transmitted than if users had to send copies of their >> certificates along with every message. >> >> Similar characteristics apply in peer-to-peer cases. The enrollment >> process could include a KG interaction. The resulting identity could be >> used with IBS for node identification in the overlay as well as message >> source verification ("identity" in and RFC 4474 context). This helps >> prevent a number of the easy attacks on P2P infrastructure. >> > > Yes, and this is all equally possible with PKI systems. As I > said at the beginning, the only thing that IBS is bringing > to the party here is a smaller credential. As far as I'm > awre, the size of the cert is not the primary reason for lack > of adoption of any of these schemes > > Again, what does IBS bring to the party except compression? [0]. > I just read through this too and I saw that in the abstract, and also thought the size of credentials might be "a problem" but isn't "THE PROBLEM" with deployment. Reading (quickly) through draft, I didn't get a sense for what other problems this solves if any. I'll mention that in addition to compression you can also use other methods to make key/name bindings too which don't rely on krufty ASN.1 blobs to make the point. > >> And of >> course, IBE could provide for message privacy as well as integrity >> across the untrusted peers that will be serving as proxies. >> > > And now we're talking about something totally different: IBE. > I agree that IBE has significantly different characteristics from > PKI. The problems with IBE in SIP are totally different: namely > not knowing the actual identity of the recipietn of the message. > This is the norm in both SIP (retargeting) and P2P (churn) > systems. > So there's no majick here seemingly. Darn. Mike > -Ekr > > [0] It's worth noting that the combination of using ECC and > doing LZW on certificates would significantly shrink the > size of the cert. I haven't done the math, but I suspect down > to the point where it's not the dominant factor. > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 12:14:22 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C707D28C9DF; Thu, 28 Feb 2008 12:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwThFNpQuTHm; Thu, 28 Feb 2008 12:14:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F2E28C7D7; Thu, 28 Feb 2008 12:14:15 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961F53A69D8 for ; Thu, 28 Feb 2008 12:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzrbLLcnwAKw for ; Thu, 28 Feb 2008 12:14:10 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 91D153A6EFA for ; Thu, 28 Feb 2008 12:14:10 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWY00939TJEQK@siemenscomms.co.uk> for sip@ietf.org; Thu, 28 Feb 2008 20:14:02 +0000 (GMT) Date: Thu, 28 Feb 2008 20:14:00 +0000 From: "Elwell, John" In-reply-to: <20080228193046.9E4EF5081A@romeo.rtfm.com> To: Eric Rescorla , Jonathan Rosenberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D070BCBB@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Doc we need to have draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda? Thread-Index: Ach6Qd2zUll3EdAjQR2CNW3PNXlM/AAAufwQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47C6F876.4060809@softarmor.com> <47C70906.8000802@cisco.com> <20080228193046.9E4EF5081A@romeo.rtfm.com> Cc: sip@ietf.org, Dean Willis Subject: Re: [Sip] Doc we need to have draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Without a means of binding the secure media to the identity of the remote party, DTLS-SRTP is not a complete solution. I don't think we can say the framework is finished until we have that complete solution. In particular, the framework uses RFC 4474 as part of the mechanism - if the solution to the RFC 4474 problem turns out to be something different from RFC 4474, the framework would be wrong. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: 28 February 2008 19:31 > To: Jonathan Rosenberg > Cc: sip@ietf.org; Dean Willis > Subject: Re: [Sip] Doc we need to have > draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda? > > At Thu, 28 Feb 2008 14:18:30 -0500, > Jonathan Rosenberg wrote: > > > > > > > > Dean Willis wrote: > > > Is there any need for discussion of the DTLS framework > > > (draft-ietf-sip-dtls-srtp-framework-01) during our meeting? > > > > > > The authors think that it is pretty much ready for WGLC > and that all > > > known issues have been resolved. > > > > I do not agree. > > > > One of the points I raise in my rfc4474-concerns draft is > that dtls-srtp > > is basing integrity of the fingerprint on 4474, and that > 4474 does not > > provide integrity against intermediary modifications of the > number, and > > even for user@domain names this can happen. > > > > I think this needs to be called out in the draft. The security > > considerations section does not discuss this. > > Because it's not a DTLS-SRTP issue. It's a SIP/4474 issue. > > The fingerprint in the SIP messaging does *not* tie the DTLS-SRTP > handshake to the phone number or to the domain name. Rather, it ties > the media to the SIP signalling. Period. It allows whatever guarantees > you are prepared to assert about the signalling to be extended to > media. If those guarantees allow you to make assertions about the > caller (or callee) identity, then great. If not, then DTLS-SRTP > doesn't help, nor is it intended to. > > Look at it this way: > When the phone rings (or your UA shows you that the other side has > answered), it can show you some meta-information about who you're > talking to. The objections you have to RFC 4474 (and I'm not saying I > agree with them) already apply at this point, before a single RTP > packet has traversed the wire. This is not a DTLS-SRTP issue. > > -Ekr > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 12:17:22 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511D128C9C9; Thu, 28 Feb 2008 12:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8vSvySK6ppR; Thu, 28 Feb 2008 12:17:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD0528C9A2; Thu, 28 Feb 2008 12:16:50 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFC028C851 for ; Thu, 28 Feb 2008 12:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri-XgBGU2HQp for ; Thu, 28 Feb 2008 12:16:48 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6BEC728C9AA for ; Thu, 28 Feb 2008 12:16:31 -0800 (PST) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 28 Feb 2008 12:16:24 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m1SKGO9g005631; Thu, 28 Feb 2008 12:16:24 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m1SKGHko012511; Thu, 28 Feb 2008 20:16:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 12:16:17 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 12:16:16 -0800 Message-ID: <47C71685.7060206@cisco.com> Date: Thu, 28 Feb 2008 15:16:05 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan References: <47C54730.5030501@nsn.com> <47C5DCA6.9080302@cisco.com> <47C680E3.2030803@nsn.com> <47C6C841.2010201@cisco.com> <47C6D42D.8040506@nsn.com> <47C6F8CA.2080305@cisco.com> In-Reply-To: X-OriginalArrivalTime: 28 Feb 2008 20:16:16.0824 (UTC) FILETIME=[C5FFE380:01C87A46] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3023; t=1204229784; x=1205093784; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Comments=20to=20the=20TOTE=20dr aft |Sender:=20; bh=DiISFFmXpoxJlVdpA4LOtBzCu/+Bbvsqb+XgIxdIOpw=; b=HVXyMqbcDdDiWxFv0F1TmnXWj+OELDbSVqzIb2Mxt0bq8j39r08HEMeCiT S2IdBhc7EMAEYZsu/4NqSpQ6Tn1V6Y9cfbWsSLxC3AezzRFcwPCZgFQFVcjV zhFe+k/kL2; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: IETF SIP List , Paul Kyzivat , Miguel Garcia Subject: Re: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline: Hadriel Kaplan wrote: > >> -----Original Message----- From: Paul Kyzivat >> [mailto:pkyzivat@cisco.com] Sent: Thursday, February 28, 2008 1:09 >> PM >> >> Advantages of using MSRP are: ... - it has some mechanisms to >> mitigate the head of line blocking issue > > MSRP needs that because it creates the problem for itself (or rather > allows it to happen), because it lets multiple logical use or user > connections be aggregated into one TCP connection. I'm not saying > that's good/bad, but for TOTE that wouldn't be an issue needing to be > solved, afaict. Correct. There is no sharing of connections between users, so any HOL blocking is caused by a user's own problem. This is why the draft says to, based on purpose, use different params. So basically tote lets the transport layer solve all these problems. > > >> The heavier weight of MSRP is an issue for UAs that won't otherwise >> be implementing MSRP anyway. For those that do its probably not an >> issue. OTOH, more uses for the protocol may serve to encourage >> ubiquitous implementation. > > If the idea is to provide a media-path-channel alternative for some > of the more media-applicable uses of INFO in the wild, the hurdle of > MSRP would be immense. Making vendors choose between either > implementing SIP+INFO, or SIP+MSRP? That's not a hard choice to > choose from, and they'll choose poorly. Yup. Thats why I wanted that "T" in TOTE to be "Trivial". > > >> OTOH, the use of media intermediaries of one sort or another for >> MSRP is likely to be required in many cases, at least in >> enterprises, because they have a need to log the stuff for legal or >> other business reasons. It may well be that the same people would >> conclude that they need to log TOTE exchanges too, because it >> otherwise might be used to tunnel things. So it may be that e2e >> media connections won't be allowed in any case. > > I have no doubt that would be needed in some cases, maybe even most > cases. There is, however, a HUGE difference between *monitoring* TCP > stream data payload contents, and *modifying* TCP stream data payload > contents. MSRP requires modifying, even just for NAT traversal > (today). Some vendors have started to implement proprietary > extensions, to avoid that. That's not a good thing. TOTE would not; you could just insert in the middle of the tcp connection and shovel data back and forth without ever looking at the payload. Again the idea is to do this in a way that, we can easily add new applications in the future without infrastructure change. So having a way to do e2e, SBCs, etc. really easy, and just ONCE, was important. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 12:25:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D0928C8B5; Thu, 28 Feb 2008 12:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiXS-GNsdL2s; Thu, 28 Feb 2008 12:25:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3521F3A6A5E; Thu, 28 Feb 2008 12:25:33 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301A828C21A for ; Thu, 28 Feb 2008 12:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W9Pswhmj20t for ; Thu, 28 Feb 2008 12:25:27 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D5D053A6C2B for ; Thu, 28 Feb 2008 12:25:18 -0800 (PST) Received: from sparc108.santera.com (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m1SKP8iE078465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 14:25:09 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <47C718A8.5080404@nostrum.com> Date: Thu, 28 Feb 2008 14:25:12 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Miguel Garcia References: <47C54730.5030501@nsn.com> <47C5DCA6.9080302@cisco.com> <47C680E3.2030803@nsn.com> <47C6C841.2010201@cisco.com> <47C6D42D.8040506@nsn.com> In-Reply-To: <47C6D42D.8040506@nsn.com> Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92.1/6029/Thu Feb 28 12:20:09 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: IETF SIP List Subject: Re: [Sip] Comments to the TOTE draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On 2/28/08 9:33 AM, Miguel Garcia wrote: > Inline as well. > > Jonathan Rosenberg wrote: > >> >> How do you do pause with MSRP? Specifically, how does the receiver tell >> the sender to pause? How does the receiver cancel? >> > > Pause from receiver to sender: re-INVITE with SDP offer with the MSRP > media stream set to inactive. > > Cancel from receiver: re-INVITE with SDP offer setting the MSRP media > stream to port 0. > This is getting off-topic, but I'm a bit concerned about using sledgehammers where screwdrivers are warranted. For canceling a file transfer -- that is, a single MIME object -- you're better off using the approach described in section 10.5 of RFC 4975. Otherwise, you're running the risk of throwing out an ongoing IM session just because you don't want to complete a specific file transfer. In the pause case, I agree that putting the MSRP stream on hold is a valid way to convey the semantics of, "I want you to pause everything inside this MSRP session," including the file transfer, but by no means limited to it. For most IM-related use cases, it would seem that this is very unlikely to be what the user expects, wants, or is even willing to put up with. For example: imagine that we're in an IM session using a client designed as you propose above. You start sending me a 5 Mb file. A dialog box pops up on my screen that conveys the progress of this file; it contains two buttons: [Pause], and [Cancel]. I press the button marked "Pause," and the file stops arriving. And suddenly you stop responding to my instant messages. Perhaps I manage to guess that the IM session has frozen because I paused the file transfer. So, to fix this, I press [Cancel]. And the whole IM window just goes away. /a _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 12:53:49 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C0C3A6AE1; Thu, 28 Feb 2008 12:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.953 X-Spam-Level: X-Spam-Status: No, score=-0.953 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0-D0Ycp8yPR; Thu, 28 Feb 2008 12:53:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661FD28C7D7; Thu, 28 Feb 2008 12:53:27 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D4E28C15E for ; Thu, 28 Feb 2008 12:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhBU1ST509Hm for ; Thu, 28 Feb 2008 12:53:25 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 2C20D28C192 for ; Thu, 28 Feb 2008 12:52:24 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m1SKqD7O028607; Thu, 28 Feb 2008 14:52:13 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 14:52:13 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 21:52:10 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 21:52:09 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001CB053E@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-body-handling-01 Thread-index: Ach6S8j1oIKE5FUTRQuXX/4TrvVc/A== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 28 Feb 2008 20:52:10.0410 (UTC) FILETIME=[C9A308A0:01C87A4B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: Gonzalo Camarillo Subject: [Sip] draft-ietf-sip-body-handling-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (As SIP WG cochair) http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-01.txt There are a couple of things in this that need revision based on list discussion, but at the moment it looks like when Gonzalo does this, it is ready for WGLC. Now would be a good time to speak if you think that there are open issues that need to be addressed in this draft, as these are all meant to be closed before WGLC. Currently there is no intent to give this agenda time in Philadelphia so don't depend on that to give you time to rant rather write an email. Regards Keith _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 13:01:58 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D264328C475; Thu, 28 Feb 2008 13:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsLYEH7NcGHX; Thu, 28 Feb 2008 13:01:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B622828C192; Thu, 28 Feb 2008 13:01:57 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E8B28C15E for ; Thu, 28 Feb 2008 13:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmCUCID8TquX for ; Thu, 28 Feb 2008 13:01:52 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7111E3A6A99 for ; Thu, 28 Feb 2008 13:01:52 -0800 (PST) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 28 Feb 2008 13:01:45 -0800 Received: from dhcp-171-71-97-210.cisco.com (dhcp-171-71-97-210.cisco.com [171.71.97.210]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m1SKmACV030680; Thu, 28 Feb 2008 12:48:11 -0800 Message-ID: <47C7213A.5090000@cisco.com> Date: Thu, 28 Feb 2008 13:01:46 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dean Willis References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> In-Reply-To: <47C7017D.5020301@softarmor.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2425; t=1204231691; x=1205095691; 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:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-kupwade-s ip-iba-00 |Sender:=20 |To:=20Dean=20Willis=20; bh=NGZTqyKV7TcGV6wnI/ja1cJPO2vULJFDGvAWzNu5Wv4=; b=P/RmfJuLQfQJtHQZWUmS6jkArlaG0K3Sreze8VBFzO6VOGrmyyjHKh2oLs 0Zgcr6iF2jn7RqiEKhifLk80sPULFDrKpTV7nwGjyyUtR+1DyRvJTFiKLNVl HGzHvu45uV; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > [] The enrollment > process could include a KG interaction. This to my mind is the _actual_ problem hindering deployment. Does this scheme help that problem or just rearrange the deck chairs? Something that posits yet another trust anchor would strike me as the latter. From the conclusion: The advantages with the proposed methods are: 1. Key size: Elliptic-curve cryptography arguably provides equivalent security with smaller operands than the RSA technique typically used with [7 ]. This provides some advantage for resource-constrained environments such as mobile telephones. It also reduces the cryptographic load on large-scale devices doing frequent authentication checks. You can do this with PKI or key-centric schemes too. 2. Key discovery: Callers can generate the public key of the callee from the identity (SIP URI) of the callee and vice versa. This eliminates a requirement for a key discovery mechanism using external sources, making deployment significantly easier. Or you can ship the key or cert in the signaling too. 3. Certificate validation: As a result caller or callee need not go through the complex path construction process to retrieve the public keys of a chain of CAs from the public key depositories which are controlled by the respective CAs. This allows deployment in a peer-to-per modality without a need to route SIP messages through a centralized identity service or trust peer nodes to operate as identity services. What is the KG if not a centralized entity? I guess I don't understand this part. 4. Revocation: The ease of minting new identities and discovering keys allows short-lived identities, reducing the need for certificate revocation lists and the checking thereof. This offers very large operational advantages in resource constrained environments. I don't understand why this is "easy". Enrollment is "hard" unless there's something really new here. And if I wanted a short-lived identity, I could just gin up a new public key pair and use that as the identity too. But I thought that the real problem was dealing with long term identities like, oh say, mat@cisco.com. Mike _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 13:39:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B80328C192; Thu, 28 Feb 2008 13:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2WpvWA24ShQ; Thu, 28 Feb 2008 13:39:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49273A68EE; Thu, 28 Feb 2008 13:39:31 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871643A6A3E for ; Thu, 28 Feb 2008 13:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puDpYDOrpyRu for ; Thu, 28 Feb 2008 13:39:29 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 824723A6827 for ; Thu, 28 Feb 2008 13:39:29 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1SLdDIV018472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2008 15:39:14 -0600 Message-Id: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> From: Dean Willis To: IETF SIP List Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 15:39:07 -0600 X-Mailer: Apple Mail (2.919.2) Cc: Cullen Jennings Subject: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Keith and I just spent the past three hours revising the agenda for SIP at IETF 71. It's very full, and we are not going to have time to discuss everything we need to discuss -- we have only 2.5 hours this time. Please take a look at: http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_71 (no, I'm not trying to send the MHTML by cut-and-paste again given what happened last time). and see if you have any suggestions. Remember, we're supposed to concentrate on the chartered working items first (that's the purpose of having a charter). Depending on what we decide about discussing session policies, I can see adding that time slice to the INFO discussion. But since we've only got 10 minutes for INFO and I can't see resolving that furball in 25 minutes, it doesn't help much. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 14:00:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE863A6E9F; Thu, 28 Feb 2008 14:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-RNfVLQ9dlt; Thu, 28 Feb 2008 14:00:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737483A6DAE; Thu, 28 Feb 2008 14:00:52 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6223A6B64 for ; Thu, 28 Feb 2008 14:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6PPbhHozYml for ; Thu, 28 Feb 2008 14:00:50 -0800 (PST) Received: from web65505.mail.ac4.yahoo.com (web65505.mail.ac4.yahoo.com [76.13.9.49]) by core3.amsl.com (Postfix) with SMTP id 6776C3A6D9A for ; Thu, 28 Feb 2008 14:00:46 -0800 (PST) Received: (qmail 25473 invoked by uid 60001); 28 Feb 2008 22:00:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=prOKmVBEMQ0WvryHxVyc6vFiFUfrEq6wPUEkQCnaL3phfxX48lcwE5MHduX+Vpa+UsXebZy5MQ27ptLNK71XhMphrAZ7wnjmILXbl5C/kiX9yNT0FmI22yr8DEYUMBbuDLKAz8tzrpyya1A+sIPocXRls6H9tHiWAAuFHA5+xlU=; X-YMail-OSG: WKx5N4MVM1lhrKJc33IFDskjq5n1vw5a2CwBitSTUo8_57eGnlbZMR3WFBZ7y8h6HpegMnOp9yT5uxWIXZCrtZJJNONWtZ1J5.SY.LrPdYEJ6bDCnJE2fZgWi0rjOA-- Received: from [70.250.198.218] by web65505.mail.ac4.yahoo.com via HTTP; Thu, 28 Feb 2008 14:00:36 PST Date: Thu, 28 Feb 2008 14:00:36 -0800 (PST) From: Harsh Kupwade To: sip@ietf.org In-Reply-To: <20080228201720.18C455081A@romeo.rtfm.com> MIME-Version: 1.0 Message-ID: <996813.24317.qm@web65505.mail.ac4.yahoo.com> Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0371901375==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0371901375== Content-Type: multipart/alternative; boundary="0-1367464068-1204236036=:24317" Content-Transfer-Encoding: 8bit --0-1367464068-1204236036=:24317 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Eric Rescorla wrote: At Thu, 28 Feb 2008 15:04:21 -0500, Hadriel Kaplan wrote: > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eric > > Rescorla > > Sent: Thursday, February 28, 2008 2:14 PM > > To: Dean Willis > > Cc: sip@ietf.org > > Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 > > > > At Thu, 28 Feb 2008 12:46:21 -0600, > > Dean Willis wrote: > > > > Yes, and this is all equally possible with PKI systems. As I > > said at the beginning, the only thing that IBS is bringing > > to the party here is a smaller credential. As far as I'm > > awre, the size of the cert is not the primary reason for lack > > of adoption of any of these schemes > > > > Again, what does IBS bring to the party except compression? [0]. > > I agree with you in general about IBS (but I like IBE); but it's not > just compression that IBE brings. When you receive a PKI cert from > an individual, you have to do a verification step that their cert > was signed by the CA. Assuming you share the same CA and all, > you're still doing a signature validation operation of the > individual's cert before you can then go validate what it is they > signed, with that user cert. Right? If you share the same KG, you > skip that validation step. Although I guess you have to generate > the individual's public key, which is probably just as taxing an > operation. So maybe it's a wash. I can't tell what your concern is? Performance? There are a lot of different designs that trade off the speed of various operations. In general, at least one of the operations (encrypt, decrypt) requires a pairing operation, so IB* systems are in aggregate slower than comparable non-IB* systems. Elliptic Curve Pairing operation is faster than the usual RSA operation. The bench mark program in the paring based crypto-library developed by the Dan Boneh’s research group shows how Elliptic curve parings ( Tate pairings) are faster than the usual RSA decryption scheme. - Harsh -Ekr --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-1367464068-1204236036=:24317 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

    Eric Rescorla <ekr@networkresonance.com> wrote:
    At Thu, 28 Feb 2008 15:04:21 -0500,
    Hadriel Kaplan wrote:

    > > -----Original Message-----
    > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eric
    > > Rescorla
    > > Sent: Thursday, February 28, 2008 2:14 PM
    > > To: Dean Willis
    > > Cc: sip@ietf.org
    > > Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00
    > >
    > > At Thu, 28 Feb 2008 12:46:21 -0600,
    > > Dean Willis wrote:
    > >
    > > Yes, and this is all equally possible with PKI systems. As I
    > > said at the beginning, the only thing that IBS is bringing
    > > to the party here is a smaller credential. As far as I'm
    > > awre, the size of the cert is not the primary reason for lack
    > > of adoption of any of these schemes
    > >
    > > Again, what does IBS bring to the party except compression? [0].
    >
    > I agree with you in general about IBS (but I like IBE); but it's not
    > just compression that IBE brings. When you receive a PKI cert from
    > an individual, you have to do a verification step that their cert
    > was signed by the CA. Assuming you share the same CA and all,
    > you're still doing a signature validation operation of the
    > individual's cert before you can then go validate what it is they
    > signed, with that user cert. Right? If you share the same KG, you
    > skip that validation step. Although I guess you have to generate
    > the individual's public key, which is probably just as taxing an
    > operation. So maybe it's a wash.

    I can't tell what your concern is? Performance?

    There are a lot of different designs that trade off the
    speed of various operations. In general, at least one
    of the operations (encrypt, decrypt) requires a pairing
    operation, so IB* systems are in aggregate slower than
    comparable non-IB* systems.
     
    Elliptic Curve Pairing operation is faster than the usual RSA operation.
     
    The bench mark program in the paring based crypto-library developed by the Dan Boneh’s research group shows how Elliptic curve parings ( Tate pairings)  are faster than the usual RSA decryption scheme.
    - Harsh


    -Ekr





    Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-1367464068-1204236036=:24317-- --===============0371901375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0371901375==-- From sip-bounces@ietf.org Thu Feb 28 14:42:22 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE0628C741; Thu, 28 Feb 2008 14:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zyjq0i54R2Ub; Thu, 28 Feb 2008 14:42:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418D028C397; Thu, 28 Feb 2008 14:42:19 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A9F3A67B3 for ; Thu, 28 Feb 2008 14:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR4ATZgtq3YP for ; Thu, 28 Feb 2008 14:42:17 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id C2A1328C1D8 for ; Thu, 28 Feb 2008 14:42:17 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8DA8D5081A; Thu, 28 Feb 2008 14:44:02 -0800 (PST) Date: Thu, 28 Feb 2008 14:44:02 -0800 From: Eric Rescorla To: Harsh Kupwade In-Reply-To: <996813.24317.qm@web65505.mail.ac4.yahoo.com> References: <20080228201720.18C455081A@romeo.rtfm.com> <996813.24317.qm@web65505.mail.ac4.yahoo.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080228224402.8DA8D5081A@romeo.rtfm.com> Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Thu, 28 Feb 2008 14:00:36 -0800 (PST), Harsh Kupwade wrote: > Eric Rescorla wrote: At Thu, 28 Feb 2008 15= :04:21 -0500, > Hadriel Kaplan wrote: > = > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of= Eric > > > Rescorla > > > Sent: Thursday, February 28, 2008 2:14 PM > > > To: Dean Willis > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 > > > > > > At Thu, 28 Feb 2008 12:46:21 -0600, > > > Dean Willis wrote: > > > > > > Yes, and this is all equally possible with PKI systems. As I > > > said at the beginning, the only thing that IBS is bringing > > > to the party here is a smaller credential. As far as I'm > > > awre, the size of the cert is not the primary reason for lack > > > of adoption of any of these schemes > > > > > > Again, what does IBS bring to the party except compression? [0]. > > = > > I agree with you in general about IBS (but I like IBE); but it's not > > just compression that IBE brings. When you receive a PKI cert from > > an individual, you have to do a verification step that their cert > > was signed by the CA. Assuming you share the same CA and all, > > you're still doing a signature validation operation of the > > individual's cert before you can then go validate what it is they > > signed, with that user cert. Right? If you share the same KG, you > > skip that validation step. Although I guess you have to generate > > the individual's public key, which is probably just as taxing an > > operation. So maybe it's a wash. > = > I can't tell what your concern is? Performance? > = > There are a lot of different designs that trade off the > speed of various operations. In general, at least one > of the operations (encrypt, decrypt) requires a pairing > operation, so IB* systems are in aggregate slower than > comparable non-IB* systems. > = > Elliptic Curve Pairing operation is faster than the usual RSA operation= . = > = > The bench mark program in the paring based crypto-library > developed by the Dan Boneh=92s research group shows how Elliptic > curve parings ( Tate pairings) are faster than the usual RSA > decryption scheme. > - Harsh Uh, that's not really what's at issue, since (1) RSA isn't really that fast compared to good EC systems and (2) the RSA decrypt is the slowest part of RSA. I'm not aware of any IB* system that has superior aggregate performance to the state of the art EC systems. [0] Could you please identify the exact IBS system you're talking about and the performance you believe it has on some system compared to RSA and ECDH or ECDSA. -Ekr [0] I'm assuming you're looking at the upper left hand part of the table (type-a). This isn't the type of curve people would usually use for PBC. More like d159 or f, which, you'll note, are quite a bit slower than type-a. Note, however, that I've heard that Ben's numbers aren't the fastest going implementation of PBC, but that doesn't affect the main point. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 15:01:10 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5E228C1DC; Thu, 28 Feb 2008 15:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd81TLveDK7h; Thu, 28 Feb 2008 15:01:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E773A6B3E; Thu, 28 Feb 2008 15:01:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC11C3A69CF for ; Thu, 28 Feb 2008 15:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlI4dOw9B5BN for ; Thu, 28 Feb 2008 15:01:02 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6464A3A6A5E for ; Thu, 28 Feb 2008 15:01:02 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2008 15:00:55 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1SN0tY4013371; Thu, 28 Feb 2008 15:00:55 -0800 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 m1SN0oCN020806; Thu, 28 Feb 2008 23:00:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 15:00:50 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 15:00:50 -0800 Message-ID: <47C73D16.9080103@cisco.com> Date: Thu, 28 Feb 2008 18:00:38 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> In-Reply-To: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> X-OriginalArrivalTime: 28 Feb 2008 23:00:50.0147 (UTC) FILETIME=[C2F56B30:01C87A5D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1929; t=1204239655; x=1205103655; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Revised=20agenda=20for=20SIP=20 --=20needs=20more=20work=20yet |Sender:=20; bh=JA4Umaq21KRYvYlwO87+KcqkT87uMN9wx0fw/4G3TM0=; b=nv9sUb6MxjYG4f7EICF9hw7TOsYFfCWuIQtdOxbv0szuDfAadMwugAef1s n/ovz6+Slgsu+LldwMI3LU81MOOnhN+LS0dI8S9oYoqdHPb6IM8ncgpwGjHs wVmPu91w1s; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF SIP List , Cullen Jennings Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 10 minutes on the phone number dichotomy thing isn't going to be even close enough to cut it. It should be either zero or a more significant number. We have 30 minutes on media security. The only chartered item there is the requiremetns document which I thought was mostly done. Why is there so much time dedicated to this? I would rather move that to INFO or the identity mess. -Jonathan R. Dean Willis wrote: > Keith and I just spent the past three hours revising the agenda for > SIP at IETF 71. > > It's very full, and we are not going to have time to discuss > everything we need to discuss -- we have only 2.5 hours this time. > > Please take a look at: > > http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_71 > > (no, I'm not trying to send the MHTML by cut-and-paste again given > what happened last time). > > and see if you have any suggestions. Remember, we're supposed to > concentrate on the chartered working items first (that's the purpose > of having a charter). > > Depending on what we decide about discussing session policies, I can > see adding that time slice to the INFO discussion. But since we've > only got 10 minutes for INFO and I can't see resolving that furball in > 25 minutes, it doesn't help much. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 15:38:33 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA21928C8C6; Thu, 28 Feb 2008 15:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnJBMcVXULSW; Thu, 28 Feb 2008 15:38:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7AF728C869; Thu, 28 Feb 2008 15:38:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8940A28C870 for ; Thu, 28 Feb 2008 15:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx8N3JxmkTCv for ; Thu, 28 Feb 2008 15:38:26 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id DD42D28C924 for ; Thu, 28 Feb 2008 15:38:17 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8F3BC5081A; Thu, 28 Feb 2008 15:40:02 -0800 (PST) Date: Thu, 28 Feb 2008 15:40:02 -0800 From: Eric Rescorla To: Jonathan Rosenberg In-Reply-To: <47C73D16.9080103@cisco.com> References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> <47C73D16.9080103@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080228234002.8F3BC5081A@romeo.rtfm.com> Cc: IETF SIP List , Cullen Jennings , Dean Willis Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Thu, 28 Feb 2008 18:00:38 -0500, Jonathan Rosenberg wrote: > > 10 minutes on the phone number dichotomy thing isn't going to be even > close enough to cut it. It should be either zero or a more significant > number. > > We have 30 minutes on media security. The only chartered item there is > the requiremetns document which I thought was mostly done. Why is there > so much time dedicated to this? I would rather move that to INFO or the > identity mess. I agree with Jonathan here. The media-security requirements document is basically done (see my review earlier today). What it needs it to be WGLCed and sent to the IESG. My vote here is for taking this time and giving it to the TOTE/INFO/mediactrl discussion, which seems like it has a lot of important and complicated issues that need to be worked through. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 15:48:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B440A28C95D; Thu, 28 Feb 2008 15:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbWM1L-HxzZP; Thu, 28 Feb 2008 15:48:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876AA28C825; Thu, 28 Feb 2008 15:48:22 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4319728C2DC for ; Thu, 28 Feb 2008 15:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-YLBteUZE6q for ; Thu, 28 Feb 2008 15:48:19 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D9A913A68E8 for ; Thu, 28 Feb 2008 15:47:28 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Feb 2008 18:47:05 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 28 Feb 2008 18:47:05 -0500 From: Hadriel Kaplan To: Jonathan Rosenberg , Dean Willis Date: Thu, 28 Feb 2008 18:47:15 -0500 Thread-Topic: [Sip] Revised agenda for SIP -- needs more work yet Thread-Index: Ach6XdEWRv5YTrPuQNyH8v3oyGGJpAABaLJA Message-ID: References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> <47C73D16.9080103@cisco.com> In-Reply-To: <47C73D16.9080103@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IETF SIP List , Cullen Jennings Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org And I would think the two X.509-cert related drafts could be combined and take less than 30 minutes. I agree with Jonathan about the phone number/identity topic - considering the discussion-leader field says "Most of the Working Group", it will take the allotted 10 minutes just to pass the microphone around. ;) -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Thursday, February 28, 2008 6:01 PM > To: Dean Willis > Cc: IETF SIP List; Cullen Jennings > Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet > > 10 minutes on the phone number dichotomy thing isn't going to be even > close enough to cut it. It should be either zero or a more significant > number. > > We have 30 minutes on media security. The only chartered item there is > the requiremetns document which I thought was mostly done. Why is there > so much time dedicated to this? I would rather move that to INFO or the > identity mess. > > -Jonathan R. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 16:47:14 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5D428C20D; Thu, 28 Feb 2008 16:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ibn2gxIcz5+c; Thu, 28 Feb 2008 16:47:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07ED63A6BF6; Thu, 28 Feb 2008 16:47:13 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657CC28C54A for ; Thu, 28 Feb 2008 16:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkUwRgAwtT9L for ; Thu, 28 Feb 2008 16:47:05 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3F82128C3AF for ; Thu, 28 Feb 2008 16:46:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,423,1199692800"; d="scan'208";a="23956344" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2008 16:46:51 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1T0kppe026618; Thu, 28 Feb 2008 16:46:51 -0800 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 m1T0kpbb010202; Fri, 29 Feb 2008 00:46:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 16:46:51 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 16:46:50 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Feb 2008 18:46:55 -0600 To: Dean Willis , IETF SIP List From: "James M. Polk" In-Reply-To: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 29 Feb 2008 00:46:50.0694 (UTC) FILETIME=[9223DE60:01C87A6C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=886; t=1204246011; x=1205110011; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Revised=20agenda=20for=20SIP=20 --=20needs=20more=20work=20yet |Sender:=20; bh=7HpClqYIv88wAo4otve6hUHCGayRRvorn6xYFujYoyM=; b=fCpfKLrxLtnwVQRoZZ+Cafyh1FPXyIIWsOcZIeC7bv1teYTr0AJUIVkYLS uIDQGKOPqR5YzqdWGMKO72UPjT/iU6KbOIoghasveRkDdj7pePUb/k1yDLW2 Rv1Zs8d3WF; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Cullen Jennings Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 03:39 PM 2/28/2008, Dean Willis wrote: >Keith and I just spent the past three hours revising the agenda for >SIP at IETF 71. > >It's very full, and we are not going to have time to discuss >everything we need to discuss -- we have only 2.5 hours this time. > >Please take a look at: > >http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_71 I thought (and hoped) Resource-Priority in Responses http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-responses-01.txt was within the charter (but without a specific milestone) that we can make a WG item and WGLC about the same day? Keith (putting him on the spot) mentioned this in Chicago. Vancouver muddied the water with the introduction of "use-case#2" - which has now been explicitly removed from consideration by this version. What do the WG (and chairs) think about this? >-- >Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 16:51:53 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE9328C161; Thu, 28 Feb 2008 16:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I7Ps0twbXmw; Thu, 28 Feb 2008 16:51:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E690A3A6C2C; Thu, 28 Feb 2008 16:51:52 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23533A6C2C for ; Thu, 28 Feb 2008 16:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DshLerz56GKF for ; Thu, 28 Feb 2008 16:51:50 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E28613A6BF6 for ; Thu, 28 Feb 2008 16:51:50 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2008 16:51:44 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1T0phLG015761; Thu, 28 Feb 2008 16:51:43 -0800 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 m1T0phbd013728; Fri, 29 Feb 2008 00:51:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 16:51:41 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 16:51:41 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Feb 2008 18:51:50 -0600 To: Dean Willis From: "James M. Polk" In-Reply-To: <47C6FB5F.8090209@softarmor.com> References: <20080224054501.90B6A3A6A07@core3.amsl.com> <200802250404.m1P44eZm023626@dragon.ariadne.com> <47C6FB5F.8090209@softarmor.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 29 Feb 2008 00:51:41.0115 (UTC) FILETIME=[3F3E98B0:01C87A6D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1667; t=1204246303; x=1205110303; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20I-D=20Action=3Adraft-ietf-sip-r ph-new-namespaces-02.txt |Sender:=20; bh=+PETuQE5qaxQE/etmuILcoNnus0JM9lEMqR+cb5BpXY=; b=HJkSP/WjI+EYHu/xnAjni0kSeuB3uGLNXl6deUtjjIxE7rWj1cRvMPMYwF Ki9n7/rwd7egecQjvXHpmDwhlSswV95fh3bexJwarZUAjqlw3nW7SABjQ2vK Fc5LEydDli; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 12:20 PM 2/28/2008, Dean Willis wrote: >James M. Polk wrote: > > > >> Abstract: > >> > >> This document creates additional Session Initiation Protocol > >> Resource-Priority namespaces, and places these namespaces in the > >> IANA register. > >> > >> As an editorial matter, can the abstract be made less vague? Such as > >> mentioning that it creates a set of namespaces for the use of the US > >> Defense Information Systems Agency... > > > > well, at least I didn't overstate things... ;-) > > > > I can change this if you want me to > >Since I personally only read the abstract of new drafts and extrapolate >all further content (including any errors) by intuitive deduction, I'm >sure that a more detailed abstract would be helpful. ;-) no problem... the next version will be done and submitted the week of the meeting >Seriously, a well-written abstract is a big help for people who haven't >been reading along with the development. Many students I've talked to >start with the abstract, and then use that to decide how the RFC fits >into the mental framework they're building as they try to come to grips >with the documentation-kraken that SIP has become. > >We should be careful to make our abstracts as useful for this sort of >thing as we can. That means that the abstract needs to tell us what the >draft is about well enough to fit it into a framework, but not tell us >much about the implementation detail. Admittedly, it is a fine balancing >act -- but I'm afraid the abstract for the draft in question hasn't even >stepped up to the high-wire, much less maintained its balance. > >-- >dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 17:50:02 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627BD28C2B4; Thu, 28 Feb 2008 17:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.053 X-Spam-Level: X-Spam-Status: No, score=-101.053 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE6hzzS6AcoZ; Thu, 28 Feb 2008 17:49:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE8B28C513; Thu, 28 Feb 2008 17:49:56 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC38928C3AF for ; Thu, 28 Feb 2008 17:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BQyhBwhmG6b for ; Thu, 28 Feb 2008 17:49:50 -0800 (PST) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 4A49728C399 for ; Thu, 28 Feb 2008 17:49:50 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-6.tower-203.messagelabs.com!1204249779!5893927!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 2053 invoked from network); 29 Feb 2008 01:49:40 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 29 Feb 2008 01:49:40 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m1T1nf1R008944 for ; Thu, 28 Feb 2008 20:49:41 -0500 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m1T1na44008921 for ; Thu, 28 Feb 2008 20:49:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 19:49:36 -0600 Message-ID: <28F05913385EAC43AF019413F674A0171246EB64@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Revised agenda for SIP -- needs more work yet thread-index: Ach6bMcxi3Cgy3fUTXGhDvpccQ8IoAACH7EA References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> From: "DOLLY, MARTIN C, ATTLABS" To: "James M. Polk" , "Dean Willis" , "IETF SIP List" Cc: Cullen Jennings Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org James, I fully support your proposal. Cheers, Martin -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of James M. Polk Sent: Thursday, February 28, 2008 7:47 PM To: Dean Willis; IETF SIP List Cc: Cullen Jennings Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet At 03:39 PM 2/28/2008, Dean Willis wrote: >Keith and I just spent the past three hours revising the agenda for >SIP at IETF 71. > >It's very full, and we are not going to have time to discuss >everything we need to discuss -- we have only 2.5 hours this time. > >Please take a look at: > >http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_71 I thought (and hoped) Resource-Priority in Responses http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-responses-01.t xt was within the charter (but without a specific milestone) that we can make a WG item and WGLC about the same day? Keith (putting him on the spot) mentioned this in Chicago. Vancouver muddied the water with the introduction of "use-case#2" - which has now been explicitly removed from consideration by this version. What do the WG (and chairs) think about this? >-- >Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 17:54:26 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838D528C93B; Thu, 28 Feb 2008 17:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS4UONsVrlQY; Thu, 28 Feb 2008 17:54:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039B63A6A5D; Thu, 28 Feb 2008 17:54:21 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54E83A6A5D for ; Thu, 28 Feb 2008 17:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7cg9-NNi1JW for ; Thu, 28 Feb 2008 17:54:20 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 161E03A6A4F for ; Thu, 28 Feb 2008 17:54:20 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Feb 2008 17:54:13 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1T1sDZs008230; Thu, 28 Feb 2008 17:54:13 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m1T1s7bb027138; Fri, 29 Feb 2008 01:54:11 GMT From: Cullen Jennings To: Hadriel Kaplan In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> <47C73D16.9080103@cisco.com> Message-Id: <83BB6D42-1A7A-44CE-9ACD-0BC51D5A081A@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 17:53:56 -0800 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=581; t=1204250053; x=1205114053; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Revised=20agenda=20for=20SIP=20 --=20needs=20more=20work=20yet |Sender:=20; bh=fi+V3XHz+QflnD1jmbRf0cS4ZE7C9zMr8wt8lubL+4k=; b=lvvgwVQbgaYvj3njTn5/nyOYF6LG50rMKgBYhDQs4RXOo4CJ9D5W0K/6GQ moHB2lvVflhGcHeP40323Bq8ATqtGV6CL4wR3RRQO7kS3nKGCQLROrHbCGXU hY6GTsZV1B; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF SIP List , Dean Willis Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 28, 2008, at 3:47 PM, Hadriel Kaplan wrote: > And I would think the two X.509-cert related drafts could be > combined and take less than 30 minutes. I have not managed to send comments yet because I am just reading drafts still but, I have a lot of ink on my copies of these. Expect some emails. I'm not saying these need agenda time - I'll leave that up to the chairs - possible the comments will just be dealt with on list but I did want to flag that I suspect these might not be 100% done yet. Cullen _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 17:58:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B2C28C565; Thu, 28 Feb 2008 17:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-1.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyZWAd7FLS+9; Thu, 28 Feb 2008 17:58:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF1C28C291; Thu, 28 Feb 2008 17:58:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF3B3A69F8 for ; Thu, 28 Feb 2008 17:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldz8lto3Wgow for ; Thu, 28 Feb 2008 17:58:27 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4964D28C892 for ; Thu, 28 Feb 2008 17:58:13 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Feb 2008 17:58:06 -0800 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 m1T1w4tK012298; Thu, 28 Feb 2008 17:58:04 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id m1T1vwcD025106; Fri, 29 Feb 2008 01:57:59 GMT From: Cullen Jennings To: SIP In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> Message-Id: <86A5F31E-DEF9-4FF0-8A4C-2C27EA97296E@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 17:57:53 -0800 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3078; t=1204250284; x=1205114284; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20RAI=20Scheduling |Sender:=20; bh=uneo6AXwYsFTaj884uVHwfjOoSTvCg+5g2wA4JcamN4=; b=og5/pXW0Pz2R/a8WPb/JUSyLqlKTrwvNd8O2tQN4fWny7QaC8icRAJABf8 kHIqu54Dbeh61/Vxsuzb4qOJ+/tjbJCMh4Nxlfj3jE9Xusg6RuJT/MHWtW9G IAnXnq0j8f; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Keith Drage , Dean Willis Subject: [Sip] RAI Scheduling X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The problem here is, well, time. At other times we may have had constraints of not enough WGs, or not enough cycles from chairs, or not enough chairs, but the issues we are having right here is hours in the IETF agenda. Right now we have some conflicts in the scheduling with WG and we only have two BOFs. Most of the RAI WG has less time than they want but SIP is the most squeezed IMHO. If I had another hour of agenda time in RAI right now, SIP is the WG that I would try to give it to and i suspect Jon would be on the same page. The SIP chairs did request more time and did predict that there would be a lot of stuff we were trying to squeeze into this. I've asked around to chairs of some other RAI WGs and asked if they really think they will use up all their time but most are already feeling like it is a tight schedule. As we see the agendas for other WG's get finalized it might become apparent that we could move some time around but I view this as a fairly unlikely possibility. One observation would be if we could finish (or shoot) some WGs we would have more time. Similarly if we could finish a bunch of WG items, we would have more time for things. I have lost count of how many times the WG has taken a HUM on how the keep-alive timers in outbound will work. (I don't mind embarrassing the authors of outbound so it is more or less my case study on how not to do a draft but there are plenty of similar cases around). Any time people HUM yes to adopt a new WG milestone, they need to realize they are putting that work at a higher priority level than all the stuff that is not a WG milestone. Similarly when we form new WGs it reduces the time available for existing WGs. Keep in mind we are running a 2 hours RUCUS BOF which is largely related to SIP security so we already do have another 2 hours on SIP security. So what can we do? Two years ago we had an RAI meeting to talk about this subject and others. Some of the ideas that came out of that have been implemented - splitting the BLISS work out to separate WG and the formation of the RAI WG to helps chairs both came out this. Jon and I had talked about having another meeting on this topic at IETF 71 but when we saw the agenda we decided it was too full to fit this in. I would not be surprised if we tried to run this at the Dublin IETF. One thing we can do is encourage stuff to get finished instead of just being endlessly discussed. If something has been discussed at a meeting, and nothing that would change the discussion has changed since the previous discussion, it is surprising to me that we keep discussing it anyways. I spend a ton of time trying to get a workable schedule out on time for RAI. (And many thanks to all the RAI Chairs - they do a good job of jumping all the hoops to make this happen). I would love feedback on what we need to be spending less time on. I get plenty of feedback on what needs more. Cullen _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 18:03:16 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA1328C95A; Thu, 28 Feb 2008 18:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=-2.489, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFlGuTbFO+SS; Thu, 28 Feb 2008 18:03:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3CE3A6A5D; Thu, 28 Feb 2008 18:03:11 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3BE28C291; Thu, 28 Feb 2008 18:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ov6i1-+Rsvm; Thu, 28 Feb 2008 18:03:10 -0800 (PST) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by core3.amsl.com (Postfix) with ESMTP id DBA903A6A07; Thu, 28 Feb 2008 18:03:09 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-12.tower-87.messagelabs.com!1204250537!2856765!13 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 8736 invoked from network); 29 Feb 2008 02:02:56 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-12.tower-87.messagelabs.com with AES256-SHA encrypted SMTP; 29 Feb 2008 02:02:56 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id m1T258ax020699; Thu, 28 Feb 2008 21:05:48 -0500 In-Reply-To: <28F05913385EAC43AF019413F674A0171246EB64@OCCLUST04EVS1.ugd.att.com> To: "DOLLY, MARTIN C, ATTLABS" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 28 Feb 2008 21:02:32 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 02/28/2008 09:02:56 PM, Serialize complete at 02/28/2008 09:02:56 PM Cc: Cullen Jennings , IETF SIP List , "James M. Polk" , sip-bounces@ietf.org, Dean Willis Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1256780413==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1256780413== Content-Type: multipart/alternative; boundary="=_alternative 000B39AE852573FE_=" This is a multipart message in MIME format. --=_alternative 000B39AE852573FE_= Content-Type: text/plain; charset="US-ASCII" I concur. Janet sip-bounces@ietf.org wrote on 02/28/2008 08:49:36 PM: > James, > > I fully support your proposal. > > Cheers, > > Martin > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Thursday, February 28, 2008 7:47 PM > To: Dean Willis; IETF SIP List > Cc: Cullen Jennings > Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet > > At 03:39 PM 2/28/2008, Dean Willis wrote: > > >Keith and I just spent the past three hours revising the agenda for > >SIP at IETF 71. > > > >It's very full, and we are not going to have time to discuss > >everything we need to discuss -- we have only 2.5 hours this time. > > > >Please take a look at: > > > >http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_71 > > I thought (and hoped) Resource-Priority in Responses > http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-responses-01.t > xt > was within the charter (but without a specific milestone) that we can > make a WG item and WGLC about the same day? > > Keith (putting him on the spot) mentioned this in Chicago. Vancouver > muddied the water with the introduction of "use-case#2" - which has > now been explicitly removed from consideration by this version. > > What do the WG (and chairs) think about this? > > >-- > >Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --=_alternative 000B39AE852573FE_= Content-Type: text/html; charset="US-ASCII"
    I concur.

    Janet

    sip-bounces@ietf.org wrote on 02/28/2008 08:49:36 PM:

    > James,
    >
    > I fully support your proposal.
    >
    > Cheers,
    >
    > Martin
    >
    > -----Original Message-----
    > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
    > James M. Polk
    > Sent: Thursday, February 28, 2008 7:47 PM
    > To: Dean Willis; IETF SIP List
    > Cc: Cullen Jennings
    > Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet
    >
    > At 03:39 PM 2/28/2008, Dean Willis wrote:
    >
    > >Keith and I just spent the past three hours revising the agenda for
    > >SIP at IETF 71.
    > >
    > >It's very full, and we are not going to have time to discuss
    > >everything we need to discuss -- we have only 2.5 hours this time.
    > >
    > >Please take a look at:
    > >
    > >http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_71
    >
    > I thought (and hoped) Resource-Priority in Responses
    > http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-responses-01.t
    > xt
    > was within the charter (but without a specific milestone) that we can
    > make a WG item and WGLC about the same day?
    >
    > Keith (putting him on the spot) mentioned this in Chicago.  Vancouver
    > muddied the water with the introduction of "use-case#2" - which has
    > now been explicitly removed from consideration by this version.
    >
    > What do the WG (and chairs) think about this?
    >
    > >--
    > >Dean
    >
    > _______________________________________________
    > Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
    > This list is for NEW development of the core SIP Protocol
    > Use sip-implementors@cs.columbia.edu for questions on current sip
    > Use sipping@ietf.org for new developments on the application of sip
    > _______________________________________________
    > Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
    > This list is for NEW development of the core SIP Protocol
    > Use sip-implementors@cs.columbia.edu for questions on current sip
    > Use sipping@ietf.org for new developments on the application of sip
     --=_alternative 000B39AE852573FE_=-- --===============1256780413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1256780413==-- From sip-bounces@ietf.org Thu Feb 28 19:27:05 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E318B3A6EE2; Thu, 28 Feb 2008 19:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIy2uensCTqw; Thu, 28 Feb 2008 19:27:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F9B3A6E88; Thu, 28 Feb 2008 19:27:04 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10583A6E01 for ; Thu, 28 Feb 2008 19:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLonVN7EejhI for ; Thu, 28 Feb 2008 19:27:03 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 091983A6C2C for ; Thu, 28 Feb 2008 19:27:02 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Feb 2008 22:26:39 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 28 Feb 2008 22:26:39 -0500 From: Hadriel Kaplan To: Eric Rescorla , Dean Willis Date: Thu, 28 Feb 2008 22:26:13 -0500 Thread-Topic: [Sip] comments on draft-kupwade-sip-iba-00 Thread-Index: Ach6Pg0Uj2oPtqKrTCOl6qxgkS+bCQAP+KuA Message-ID: References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <20080228191408.677435081A@romeo.rtfm.com> In-Reply-To: <20080228191408.677435081A@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eric > Rescorla > Sent: Thursday, February 28, 2008 2:14 PM > > > And of > > course, IBE could provide for message privacy as well as integrity > > across the untrusted peers that will be serving as proxies. > > And now we're talking about something totally different: IBE. > I agree that IBE has significantly different characteristics from > PKI. The problems with IBE in SIP are totally different: namely > not knowing the actual identity of the recipietn of the message. > This is the norm in both SIP (retargeting) and P2P (churn) > systems. Not to belabor this topic, but I don't think retargeting is an issue for SIP use of IBE, if by that you mean Alice sent a request to Bob and it got retargeted to Charles and thus Charles could not decrypt it. It would be considered a feature to some folks. It would take a second request to fix it, but that's only if retargeting occurs, and then the caller gets to decide if they want to do it to Charles. The real killer for SIP usage of IBE is that Alice has no idea what KG group Bob is a member of a priori. For example if Alice is a member of a KG group called "CLINTON", and Bob is a member of KG group "OBAMA". Alice won't know ahead of time that Bob is a member of OBAMA. Even if Alice had the OBAMA keying info at hand to use, she wouldn't know Bob is a member of it until she tries reaching Bob. Since that would happen a lot, there's no serious advantage over conventional pub-key retrieval to encrypt, methinks. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 20:22:11 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E6E3A6A90; Thu, 28 Feb 2008 20:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.292 X-Spam-Level: X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDNIXB7Yf3zt; Thu, 28 Feb 2008 20:22:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E36D3A68A0; Thu, 28 Feb 2008 20:22:05 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6ED3A67A9 for ; Thu, 28 Feb 2008 20:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxbvqZqaVm6O for ; Thu, 28 Feb 2008 20:22:03 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D73663A6A07 for ; Thu, 28 Feb 2008 20:22:01 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1T4K6fQ022264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2008 22:20:08 -0600 Message-Id: <4A3E0A4C-46D1-4DAF-B2A0-1A6AF3370C1F@softarmor.com> From: Dean Willis To: Michael Thomas In-Reply-To: <47C7160A.9030606@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 22:20:01 -0600 References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <20080228191408.677435081A@romeo.rtfm.com> <47C7160A.9030606@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 28, 2008, at 2:14 PM, Michael Thomas wrote: > Eric Rescorla wrote: >> At Thu, 28 Feb 2008 12:46:21 -0600, >> Dean Willis wrote: >> >>> >>> A global or semi-global KG makes excellent sense in large domains, >>> especially where there are significant resource constraints. >>> > > Are we talking about a trust anchor that isn't DNS and isn't shipped > in > web browsers currently? Yes. It would be a trust anchor that would be bound on enrollment in the domain, such as when signing up to use a P2p service, or buying a mobile phone SIM. One could perhaps bootstrap it from DNS, perhaps using a conventional cert as a trust anchor for the process. Here's a possible sequence: browse to https://p2psip.example.com. Complete an enrollment form. Receive a SIP URI and a private key. Later on, launch your P2PSIP client and connect to the overlay. Sign the PUT request for your registration using your private key. The peer you;re talking to can check the signature and validate your identity without having to retrieve your public key > >>> Consider, for example, the 3GPP world of GSM phones. A KG hierarchy >>> rooted at the GSMA with each operator then having a subordinate KG >>> could >>> make a lot of sense. We could get end-to-end security with >>> significantly >>> fewer bits being transmitted than if users had to send copies of >>> their >>> certificates along with every message. >>> >>> Similar characteristics apply in peer-to-peer cases. The enrollment >>> process could include a KG interaction. The resulting identity >>> could be >>> used with IBS for node identification in the overlay as well as >>> message >>> source verification ("identity" in and RFC 4474 context). This helps >>> prevent a number of the easy attacks on P2P infrastructure. >>> >> >> Yes, and this is all equally possible with PKI systems. As I >> said at the beginning, the only thing that IBS is bringing >> to the party here is a smaller credential. As far as I'm >> awre, the size of the cert is not the primary reason for lack >> of adoption of any of these schemes >> Again, what does IBS bring to the party except compression? [0]. >> > > I just read through this too and I saw that in the abstract, and > also thought the size of credentials might be "a problem" but isn't > "THE PROBLEM" with deployment. > > Reading (quickly) through draft, I didn't get a sense for what > other problems this solves if any. I'll mention that in addition to > compression you can also use other methods to make key/name > bindings too which don't rely on krufty ASN.1 blobs to make > the point. True. There are a lot of other problems with "deployment" that crop up. Many are of "perfect is the enemy of good enough". Nobody really wants to "run a CA", what with all the dire warnings about the responsibility and all the key management issues, and questions about what those certs are going to be used for, and so on. But nobody seems to be all that averse to running a password database for authentication. We could easily envision a simple web-service API for PKG services that bootstraps off a secured HTML page and a password database, and use that to launch a production system that would be considered "very deployable" and easy to operate. We could probably also do the same sort of thing with a CA instead of a PKG. It SEEMS easy enough. But nobody does it. Why? > >> >>> And of >>> course, IBE could provide for message privacy as well as integrity >>> across the untrusted peers that will be serving as proxies. >>> >> >> And now we're talking about something totally different: IBE. >> I agree that IBE has significantly different characteristics from >> PKI. The problems with IBE in SIP are totally different: namely >> not knowing the actual identity of the recipietn of the message. >> This is the norm in both SIP (retargeting) and P2P (churn) >> systems. >> > > So there's no majick here seemingly. Darn. Actually, there's no reason you can't know the identity of the recipient of a message. You may not know it in advance of them actually receiving the message, but given that they have a key that's meaningful to you, they can sign a response to the message. They could potentially even sign a response to a message that they couldn't actually understand fully -- all they need to know is enough to get the response back to you, along with a copy of the message. We've considered "response identity" a hard problem in SIP. There are a couple of reasons: 1) We assume SIP UAs do not have keys that are meaningful to each other, due to the difficulty of solving "the CA problem", so end-user verification is not available. 2) We assume servers rely on HTTP digest authentication to establish an identity relationship. Since digest authentication applies only to requests and not responses, identity services only work on requests. Of course, draft-ietf-sip-outbound makes it feasible for an identity server to be colocated with the "outbound proxy", thereby giving it the option of a persistent TLS connection to the UA from which identity could reasonably be inserted in responses. But we haven't internalized this yet (and "outbound" remains hung up in the process). So John Elwell's draft relies on the authentication of messages in the opposing direction, giving us "connected identity" instead of "response identity". This only works in a subset of cases. 3) We have the unanticipated respondent problem. Somebody on the path can retarget requests to somebody with whom you have no prior relationship, making any authentication of the recipient a dicey proposition. Of course, in an IB-system, everybody has some prior relationship (via whatever top-level KG roots the hierarchy), so you can validate an identity assertion on any response from within that hierarchy. We still don't have a way to know whether such a response is reasonable or not (although IB does allow for some interesting possibilities towards solving this too). So yeah, if you're willing to accept the constrains of an IB model (namely, some variation on single-root), then there is majick. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 20:54:45 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3646028C964; Thu, 28 Feb 2008 20:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxAPn66bJy5g; Thu, 28 Feb 2008 20:54:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441C53A6A3F; Thu, 28 Feb 2008 20:54:39 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F216828C1B6 for ; Thu, 28 Feb 2008 20:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1mPZ7li9kGh for ; Thu, 28 Feb 2008 20:54:32 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 06AE63A6A3F for ; Thu, 28 Feb 2008 20:54:31 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1T4sMT6022520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2008 22:54:23 -0600 Message-Id: <57ED2BE6-1A90-4D15-A7E0-8366082BD6BA@softarmor.com> From: Dean Willis To: Michael Thomas In-Reply-To: <47C7213A.5090000@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 22:54:17 -0600 References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <47C7213A.5090000@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 28, 2008, at 3:01 PM, Michael Thomas wrote: > Dean Willis wrote: >> [] The enrollment >> process could include a KG interaction. > > This to my mind is the _actual_ problem hindering deployment. Does > this scheme help that problem or just rearrange the deck chairs? > Something > that posits yet another trust anchor would strike me as the latter. > > From the conclusion: > > The advantages with the proposed methods are: > > 1. Key size: Elliptic-curve cryptography arguably provides > equivalent security with smaller operands than the RSA technique > typically used with [7 >]. This provides some advantage for > resource-constrained environments such as mobile telephones. It > also reduces the cryptographic load on large-scale devices doing > frequent authentication checks. > > You can do this with PKI or key-centric schemes too. true. > > > 2. Key discovery: Callers can generate the public key of the callee > from the identity (SIP URI) of the callee and vice versa. This > eliminates a requirement for a key discovery mechanism using > external sources, making deployment significantly easier. > > Or you can ship the key or cert in the signaling too. yes, although those keys may be big (a problem for network resource constrained environments), AND you have to ship them before they can be used for encryption. For signing, I can send my cert along with a signed message. But if I'm going to encrypt the message to you, I need your public key BEFORE sending the message. Since the IB model generates public keys from SIP URIs, if I have enough info on you to send you the message, then I also have enough to encrypt it. > > > 3. Certificate validation: As a result caller or callee need not go > through the complex path construction process to retrieve the > public keys of a chain of CAs from the public key depositories > which are controlled by the respective CAs. This allows > deployment in a peer-to-per modality without a need to route SIP > messages through a centralized identity service or trust peer > nodes to operate as identity services. > > What is the KG if not a centralized entity? I guess I don't > understand this part. It's a centralized entity, but OUTSIDE of the signaling path. Interaction with it is independent of interaction within the signaling plane. Consider, for example, a P2PSIP deployment that may initially bootstrap in a connected environment. Everybody talks to their PKGs and gets keyed up. Then a disaster occurs, people jump in their response vehicles, and rush off to the impact zone where they form an ad-hoc network. Their keys still work without further access to the PKG. Contrast this to RFC 4474 identity servers, where each SIP request has to go through a server, where a cryptographic process occurs. This is a very load-sensitive centralized device without which the system cannot function. Sure, we could do something similar by having the "initial bootstrap" include a CA process wherein everbody gets a cert. But now we need a way of distributing the certs, either by broadcast or some sort of query protocol. Why bother when an identity-based-encryption model makes it so much easier? > > > 4. Revocation: The ease of minting new identities and discovering > keys allows short-lived identities, reducing the need for > certificate revocation lists and the checking thereof. This > offers very large operational advantages in resource constrained > environments. > > I don't understand why this is "easy". Enrollment is > "hard" unless there's something really new here. And > if I wanted a short-lived identity, I could just gin > up a new public key pair and use that as the identity > too. But I thought that the real problem was dealing with > long term identities like, oh say, mat@cisco.com. > Secondary enrollment, or at least minting a new identity, is relatively easy, While the server load for crypto is comparable to that of generating a cert, the amount of data on the wire is much smaller. What we have in effect is a two-tier model with "permanent" and "temporary" keysets or secrets. Initial enrollment gets you the "permanent" keyset. This is then used to generate "secondary" keysets on an as-needed basis. One can easily model a single-request API for generating the secondaries. Here, the "permanent" keyset is known only to the user and the PKG. The "secondaries" are the identities that are used by everybody else. So for example, take "sip:mat@cisco.com". You'd probably never be contacted using precisely this identity. Instead, we'd use some sort of well-known convention to parameterize this identity. For example, we might use a time-based convention to delimit the identity to the current month: "sip:mat@cisco.com;valid=200802". A monthly validity period is roughly equivalent to using certs that expire after 30 days -- but the important point is that your correspondents wouldn't need to get a new cert for you next month. Instead, knowing the convention, they'd just change the identity they use when sending you SIP messages. It's even possible to "stock up" on identities in advance -- for example, generate your 200802 keyset, your 200803 keyset, and so on in advance, then just use the right one when you need it. The important thing is that when somebody knows your base URL, the conventions of your domain, and the fixed identity-to-key transform algorithm (basically some kind of hash), they can generate your current working public key WITHOUT having to talk to some kind of centralized server. While expiry is not a general answer to certificate revocation, it does help by making the CRLs very short, and in some cases by completely eliminating a requirement for revocation. Let's talk about conventional certificate revocation. There are ways to make it better, but the basic model is that the CA builds a file of every certificate it has ever revoked. It keeps this file forever (theoretically, it could prune expired certs, but nobody does as they keep getting used past their expiry), and keeps adding stuff to it. Every time it adds something, it has to re-sign the file using the CA cert. This file is called a "certificate revocation list", or CRL. If a user of certs from that CA wants to see if a cert that has not expired is still valid, it does a GET of the CRL. This might be a very large file. Assuming, say, 1 million users, 100 bytes per cert (only a part of the cert needs to be in the CRL), and a revocation rate of just 10%, after a year the CRL is over a megabyte in size. Since stuff constantly gets added, every time a user needs to check a cert it has to download the whole thing (or it checks periodically, giving us windows during which revoked certs will continue to be used). Then the user software does a liner search through the CRL every time it wants to use a key. This sucks, so we have things like OSCP to add validity-verification protocols that add round-trip operations before every usage of a cert. Gee, that's very helpful if your network is resource constrained or partitioned. I happen to be following the IETF's "server migration" test list, and I'll note that two weeks after cutover, we're still reporting OSCP problems. It is non-trivial to get right. At the moment, one of our Most Notable Persons is reporting that the OSCP servers used by IETF aren't reachable from his digs in Australia, meaning all accesses to IETF's secured web sites fail authentication checks and pop up nasty errors after an unconscionable delay. This would NOT be helpful to first-responders in a disaster zone, I assure you. -- Dean Time-constrained _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 20:58:02 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7212428C430; Thu, 28 Feb 2008 20:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3bhDBI2G7yt; Thu, 28 Feb 2008 20:58:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794A43A6A5B; Thu, 28 Feb 2008 20:58:01 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C243A67A9 for ; Thu, 28 Feb 2008 20:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ccfMYtDjeWm for ; Thu, 28 Feb 2008 20:57:54 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A276C28C73F for ; Thu, 28 Feb 2008 20:57:42 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1T4vXLS022545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2008 22:57:34 -0600 Message-Id: From: Dean Willis To: Jonathan Rosenberg In-Reply-To: <47C73D16.9080103@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 22:57:27 -0600 References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> <47C73D16.9080103@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List , Cullen Jennings Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 28, 2008, at 5:00 PM, Jonathan Rosenberg wrote: > 10 minutes on the phone number dichotomy thing isn't going to be > even close enough to cut it. It should be either zero or a more > significant number. > > We have 30 minutes on media security. The only chartered item there > is the requiremetns document which I thought was mostly done. Why is > there so much time dedicated to this? I would rather move that to > INFO or the identity mess. Me too. But hey, the media security requirements document is CHARTERED. We have permission to work on it and a commitment to a deliverable, with a published milestone. We don't have that for INFO or the identity mess (even though I think media security is blocked on the identity mess -- our AD currently disagrees). -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 21:01:38 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD2C28C1ED; Thu, 28 Feb 2008 21:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFyt3eivVyKI; Thu, 28 Feb 2008 21:01:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6C23A6A5B; Thu, 28 Feb 2008 21:01:37 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A463A67A9 for ; Thu, 28 Feb 2008 21:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTmAkm8NqVdd for ; Thu, 28 Feb 2008 21:01:36 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 31E833A68A0 for ; Thu, 28 Feb 2008 21:01:32 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1T51KfL022614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2008 23:01:22 -0600 Message-Id: From: Dean Willis To: Cullen Jennings In-Reply-To: <83BB6D42-1A7A-44CE-9ACD-0BC51D5A081A@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 23:01:14 -0600 References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> <47C73D16.9080103@cisco.com> <83BB6D42-1A7A-44CE-9ACD-0BC51D5A081A@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: IETF SIP List Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 28, 2008, at 7:53 PM, Cullen Jennings wrote: > > On Feb 28, 2008, at 3:47 PM, Hadriel Kaplan wrote: > >> And I would think the two X.509-cert related drafts could be >> combined and take less than 30 minutes. > > I have not managed to send comments yet because I am just reading > drafts still but, I have a lot of ink on my copies of these. Expect > some emails. I'm not saying these need agenda time - I'll leave that > up to the chairs - possible the comments will just be dealt with on > list but I did want to flag that I suspect these might not be 100% > done yet. And as we know from experience, 15 minutes is the barest minimum for a topic on which there is discussion. I only felt these could get anything done in 30 minutes for two because there is some overlap. Now, if we could get this stuff discussed effectively on list BEFORE the meeting, I'd be delighted to dedicate more time to the topics that are keeping us all awake at night. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 21:09:13 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16C83A6AD5; Thu, 28 Feb 2008 21:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-BXqbYDAHgc; Thu, 28 Feb 2008 21:09:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5356E3A6A3F; Thu, 28 Feb 2008 21:09:07 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4EA3A694D for ; Thu, 28 Feb 2008 21:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtqcoN+xN6Uw for ; Thu, 28 Feb 2008 21:09:06 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E90883A6A3F for ; Thu, 28 Feb 2008 21:09:05 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1T58rGN022659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2008 23:08:55 -0600 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 23:08:48 -0600 References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <20080228191408.677435081A@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org" Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 28, 2008, at 9:26 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf >> Of Eric >> Rescorla >> Sent: Thursday, February 28, 2008 2:14 PM >> >>> And of >>> course, IBE could provide for message privacy as well as integrity >>> across the untrusted peers that will be serving as proxies. >> >> And now we're talking about something totally different: IBE. >> I agree that IBE has significantly different characteristics from >> PKI. The problems with IBE in SIP are totally different: namely >> not knowing the actual identity of the recipietn of the message. >> This is the norm in both SIP (retargeting) and P2P (churn) >> systems. > > Not to belabor this topic, but I don't think retargeting is an issue > for SIP use of IBE, if by that you mean Alice sent a request to Bob > and it got retargeted to Charles and thus Charles could not decrypt > it. It would be considered a feature to some folks. It would take > a second request to fix it, but that's only if retargeting occurs, > and then the caller gets to decide if they want to do it to Charles. > > The real killer for SIP usage of IBE is that Alice has no idea what > KG group Bob is a member of a priori. For example if Alice is a > member of a KG group called "CLINTON", and Bob is a member of KG > group "OBAMA". Alice won't know ahead of time that Bob is a member > of OBAMA. Even if Alice had the OBAMA keying info at hand to use, > she wouldn't know Bob is a member of it until she tries reaching > Bob. Since that would happen a lot, there's no serious advantage > over conventional pub-key retrieval to encrypt, methinks. But if both the "CLINTON" and "OBAMA" groups were both subsidiaries of the "DEMOCRAT" group, hierarchical inheritance takes care of the problem. You can also do some things using DNS or the like to figure out which "group" an identity is in if you can't deduce from the domain. But where it really shines is in bounded user groups -- say, the set of participants in Skype, or people in the Department of Defense, or employees of Walmart, when the communication is WITHIN that group. And if we're talking about something like a single P2PSIP overlay or confederation of overlays, then group closure is easy. The larger the group and the more relatively frequent communications are within that group, the greater the efficiency gain from IB crypto. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 21:15:59 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C948628C9B6; Thu, 28 Feb 2008 21:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.114 X-Spam-Level: X-Spam-Status: No, score=0.114 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_65=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-WZlu53emGo; Thu, 28 Feb 2008 21:15:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CEF628C9A4; Thu, 28 Feb 2008 21:15:58 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498DB28C62B for ; Thu, 28 Feb 2008 21:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvzllSfxDIOj for ; Thu, 28 Feb 2008 21:15:56 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 4CB5828C9A4 for ; Thu, 28 Feb 2008 21:15:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,424,1199644200"; d="scan'208";a="98656213" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 29 Feb 2008 10:45:46 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1T5FiMV002939; Fri, 29 Feb 2008 13:15:44 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m1T5Fhax026676; Fri, 29 Feb 2008 05:15:44 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 13:14:38 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 13:15:27 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Contact header in 1xx responses/updates remote target or not? Thread-Index: Ach6MfQ+3S5Y7/eVSX+Xy2Vl3VsJiwAEE/nwABNCQfA= References: <47C6F37B.7010609@cisco.com> From: "Rockson Li (zhengyli)" To: "Christer Holmberg" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 29 Feb 2008 05:14:38.0012 (UTC) FILETIME=[FB0207C0:01C87A91] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6095; t=1204262145; x=1205126145; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20(zhengyli)=22=20 |Subject:=20RE=3A=20[Sip]=20Contact=20header=20in=201xx=20r esponses/updates=20remote=20target=20or=20not? |Sender:=20; bh=uypw47FT8mOIl5V90MkvakXY18QUvGJcUTamyJ/+HEU=; b=MUu1TwCcTpTKUVa1N+j2mNkO6bvelpvz+f+hOzETPs4kEDqIv2Jj3ypcKm xaHkyZov7jb4tj4mLgwb+maLzOYcqSF/0HlvibuW1y//EzvGQSwYBotO5IMP hi1kj1g/ZnXt46YQkT8qpmea8EixJghQJqbhI0w0ICVHdhUfh4I+I=; Authentication-Results: hkg-dkim-1; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul and Christer, As I understand the contact/remote-target update is remote-target is only set when dialog created , there's no way of changing it after dialog(early of confirmed) establishment except target-refresh req(re-inv/update) the reason is as follows, in RFC3261 13.2.2.1 1xx Response If a provisional response has a tag in the To field, and if the dialog ID of the response does not match an existing dialog, one is constructed using the procedures defined in Section 12.1.2. which means the contact would only be set in UAC upon dialog creation, even later the non-100 1xx response(wether reliable or not) change contact, the dialog state would not change as above. similar meaning is stated in http://www.ietf.org/mail-archive/web/sip/current/msg07893.html and here only says to tag is the sole criteria for early-dialog construction, not contact header mentioned at all. similar discussion at http://www.ietf.org/mail-archive/web/sipping/current/msg14510.html if dialog-creating-non-100-1xx does not have contact, looks like the it's RFC2543-compliant UA and remote-target of the UAC should be To as per RFC2543 section 11.3 check Brette's option here http://www.ietf.org/mail-archive/web/sipping/current/msg14514.html When dialog transitioned from early to confirmed. sec 13.2.2.4 2xx Responses If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2. Note that the *only* piece of state that is recomputed is the route set. Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example. So only route set could be changed, remote-target just remains as the same as early dialog, even 200 change the contact. comments? Regards, -Rockson -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, February 29, 2008 3:49 AM To: Paul Kyzivat (pkyzivat); Rockson Li (zhengyli) Cc: sip@ietf.org Subject: RE: [Sip] Contact header in 1xx responses/updates remote target or not? Hi, I agree with Paul's conclusion. But, I still think that is somethin that we should somehow document and clarify. This is a common reason for interop problems, so just agree on a mailing list and leave it there is not a good thing to do. IF (To-tag && Contact) THEN dialog And, it IS allowed to update the Contact in subsequence provisional responses. But, as Paul said: it is asking for trouble, so it should not be done unless you have a really good reason for it. I also think that updating the Contact in a re-INVITE/UPDATE is asking for trouble. At least you also there need to be prepared to receive requests on both the new and old contact for a period of time. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 28. helmikuuta 2008 19:47 > To: Rockson Li (zhengyli) > Cc: Christer Holmberg; sip@ietf.org > Subject: Re: [Sip] Contact header in 1xx responses/updates remote > target or not? > > No, I don't think we have an answer, though I do have an opinion. :-) > > Are you asking about whether the contact may be omitted? Or if it may > be changed? > > AFAIK there is nothing normative that *forbids* the contact from being > changed in subsequent provisional responses. But doing so is *asking* > for trouble, so you shouldn't do it. > Perhaps you could get away with it in a *reliable* provisional, but > then you would still have a bunch of messy cases. The likelihood of it > working is slim. Doing it with > *unreliable* provisionals is going to cause trouble because they can > be lost. Even with reliable provisionals, you will have to be prepared > to receive on both addresses for some period of time. > > It seems clear that a contact may be omitted in a 100, since it is hop > by hop, and presumably must be omitted in the 100 responses from > proxies. Some other 1xx responses may be returned by proxies (notably > 181) and presumably they should also not contain a contact in those > cases. > > A 1xx that establishes an early dialog must contain a contact or else > you really don't have a dialog. I think it is ambiguous whether: > - the first 1xx with a particular to-tag *does* establish an early > dialog and so *must* contain a contact, > > - OR a 1xx with a new to-tag, but without a contact, simply doesn't > establish a dialog, but is legal. > > I would split the difference and say that the UAS MUST include a > contact in the first 1xx it returns with a particular to-tag, but a > UAC should accept a 1xx with new to-tag and without a contact and > simply treat it as not establishing an early dialog. (Don't establish > the dialog until you get enough info to do so.) > > Paul > > Rockson Li (zhengyli) wrote: > > Paul , Christer and all, > > > > I am following the email thread as in subject above > > http://www.ietf.org/mail-archive/web/sip/current/msg19322.html > > > > However, I do not find the definite answer to Christer's > question, Do > > we have the answer now? > > > > Thanks a lot > > > > Regards, > > Rockson Li > > > > Cisco R&D Center, Shanghai, PRC > > > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 21:33:14 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F07228C964; Thu, 28 Feb 2008 21:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcP0i0S2DaCs; Thu, 28 Feb 2008 21:33:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9A23A6A5D; Thu, 28 Feb 2008 21:33:09 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31343A6A5B for ; Thu, 28 Feb 2008 21:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+p2tWgKoBeb for ; Thu, 28 Feb 2008 21:33:02 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1ADCC3A6767 for ; Thu, 28 Feb 2008 21:33:02 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2008 21:32:55 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1T5WsqR008276; Thu, 28 Feb 2008 21:32:54 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m1T5Wrbb011824; Fri, 29 Feb 2008 05:32:53 GMT From: Cullen Jennings To: Dean Willis In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> <47C73D16.9080103@cisco.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 21:32:43 -0800 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1671; t=1204263175; x=1205127175; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Revised=20agenda=20for=20SIP=20 --=20needs=20more=20work=20yet |Sender:=20; bh=qw7A0WxiKDCYyCE8ByRLY306iyfoEoYimBDTs+HynEU=; b=r3Tzs7PZK4zW/vxUBjXv1CzxtYdflKSiFSb/WyFcZsVSNn9c8/nKiZEZnM yhFPxl38HZ69W7upyjwEwCnZnKjy24iyf5RBEuyvlglRNBA6NAc5IJVK0Man MSdlYajaFH; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF SIP List Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 28, 2008, at 8:57 PM, Dean Willis wrote: > > On Feb 28, 2008, at 5:00 PM, Jonathan Rosenberg wrote: > > > 10 minutes on the phone number dichotomy thing isn't going to be > > even close enough to cut it. It should be either zero or a more > > significant number. > > > > We have 30 minutes on media security. The only chartered item there > > is the requiremetns document which I thought was mostly done. Why is > > there so much time dedicated to this? I would rather move that to > > INFO or the identity mess. > > Me too. But hey, the media security requirements document is > CHARTERED. We have permission to work on it and a commitment to a > deliverable, with a published milestone. We don't have that for INFO > or the identity mess (even though I think media security is blocked on > the identity mess -- our AD currently disagrees). > Dean - I think we must be having some serious miscommunications - many times in the past I have had enough typos in my emails that no one could understand what I might have been thinking but .... I don't think I said that. The two things I thought I said that might have been confused are: 1) I don't think the E.164 discussion is holding up milestone items in MEDIACTRL or SIMPLE 2) I don't think a problem in some mechanism such as 4474 should be holding up the media security requirements draft. (If I could bold requirements in the previous sentences I would) I certainly do think it is important that we have a clear understanding of how E.164 numbers fit into the overall SIP security picture. Sorry if I said something that made you think otherwise. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 21:34:02 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB8428C9AF; Thu, 28 Feb 2008 21:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.367 X-Spam-Level: X-Spam-Status: No, score=0.367 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4V0xstY8tp5; Thu, 28 Feb 2008 21:34:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1973628C46D; Thu, 28 Feb 2008 21:34:00 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003B528C964 for ; Thu, 28 Feb 2008 21:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHFKRLefFzod for ; Thu, 28 Feb 2008 21:33:58 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.177]) by core3.amsl.com (Postfix) with ESMTP id BE8B53A6AF4 for ; Thu, 28 Feb 2008 21:33:57 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r23so4347805elf.14 for ; Thu, 28 Feb 2008 21:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=RfdYip+SmFhcPdj0C7WDxCMuQbSmqsdluK+j1v4BV2I=; b=ijEBbmxGsgcZzkLcetGwvSs9pLq25yFdelPCbqTnOPormT7nbhE9hErNQIxvhl2aIyKorZpIQ4kf69JHeQyIZh7SZxyq/SWLLbL5ydwdG33RfWXAdtKTfRZ+A0fC0Az30o/4waHmUJPWqL523hDQFgB4/g+6gWUdPje2fVP6VNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=u6BGUu4N6LTbWeIKEz3gbo0kfGK4EE1TFiRdvR37mHYp4Lk6qsSHho3VuZk9lKtdOJ3icM+MqwEQ5ZxzLqdNq7rM+mk3t67c+YYM8cy6jRpzjmxaon1NzfL6JCiHsCCsgR14WxxyzMsNsBQrKPiaEmJz3LlnCvM2/dHbL78s/04= Received: by 10.114.191.1 with SMTP id o1mr10777497waf.66.1204263229197; Thu, 28 Feb 2008 21:33:49 -0800 (PST) Received: by 10.114.76.11 with HTTP; Thu, 28 Feb 2008 21:33:49 -0800 (PST) Message-ID: <66cd252f0802282133l5978fa0an485a2690ee5d7971@mail.gmail.com> Date: Fri, 29 Feb 2008 16:33:49 +1100 From: "Hisham Khartabil" To: "Karthikeyan Gopal , TLS-Chennai" In-Reply-To: MIME-Version: 1.0 References: Cc: sip@ietf.org, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] SIP Outbound : How to identify edge-proxy ? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1924580838==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1924580838== Content-Type: multipart/alternative; boundary="----=_Part_14060_1842713.1204263229185" ------=_Part_14060_1842713.1204263229185 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline How are you definig edge proxy? Edge proxy is the first hop from the UA. Hisham On 14/02/2008, Karthikeyan Gopal , TLS-Chennai wrote= : > > Hi All, > > How to identify edge-proxy in this topology? > > > > UA =96 P1 =96 P2 =96 P3 =96 REGISTRAR > > > > Here in this case P1 and P3 are Edge proxy's as per Path header RFC 3327. > > > > > > Edge proxy P1 can be identified based on VIA. > > > > Then how to edge proxy identify P3? > > > > Thanks & Regards, > > Karthikeyan.G > > > DISCLAIMER: > > -------------------------------------------------------------------------= ---------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect > the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > > -------------------------------------------------------------------------= ---------------------------------------------- > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_14060_1842713.1204263229185 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
    How are you definig edge proxy? Edge proxy is the first hop from the U= A.
     
    Hisham

     
    On 14/02/2008, Karthikeyan Gopal , TLS-Chennai <g_karthikeyan@hcl.in> wrote:

    Hi All,

       How to identify edge-proxy in this topology?

     

    UA =96 P1 =96 P2 =96 P3 =96 REGISTRAR

     

    Here in this case P1 and P3 are Edge proxy's as per Path header= RFC 3327.

     

     

    Edge proxy P1 can be identified based on VIA.

     

    Then how to edge proxy identify P3?

     

    Thanks & Regards,

    Karthikeyan.G

     

    DISCLAIMER:
    ------------= ---------------------------------------------------------------------------= --------------------------------

    The contents of this e-mail and any= attachment(s) are confidential and intended for the named recipient(s) onl= y.
    It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in
    this email are solely those of th= e author and may not necessarily reflect the opinions of HCL or its affilia= tes.
    Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
    this message without the prior wr= itten consent of the author of this e-mail is strictly prohibited. If you h= ave
    received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and
    attachments please check them for vir= uses and defect.

    ---------------------------------------------------= --------------------------------------------------------------------

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

    ------=_Part_14060_1842713.1204263229185-- --===============1924580838== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1924580838==-- From sip-bounces@ietf.org Thu Feb 28 21:36:38 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C4528C4F4; Thu, 28 Feb 2008 21:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES5dhPNIYyAA; Thu, 28 Feb 2008 21:36:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691333A6AD5; Thu, 28 Feb 2008 21:36:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40223A6767 for ; Thu, 28 Feb 2008 21:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq55u2DNP-Tb for ; Thu, 28 Feb 2008 21:36:31 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DB53C3A6A90 for ; Thu, 28 Feb 2008 21:36:30 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1T5aM3u022856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 28 Feb 2008 23:36:23 -0600 Message-Id: <41E96F53-A2D1-41EE-93A4-2E61099BDF1D@softarmor.com> From: Dean Willis To: "sip@ietf.org List" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 23:36:16 -0600 X-Mailer: Apple Mail (2.919.2) Subject: [Sip] Sanity check -- relationship between DTLS-SRTP and Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ok, maybe I'm reading something wrong here. From the list conversation, it seems like some people think there's a relationship between DTLS-SRTP and SIP Identity, aka RFC 4474. Other people think that there's a problem applying RFC 4474 when we use phone numbers. Some people think we use phone numbers a LOT, maybe almost all the time, and that therefore we really need to figure out how this impacts RFC 4474 and our other concepts of identity. This makes it seem to me like maybe we need to get the identity stuff nailed down before we commit to a final version of DTLS-SRTP. Or maybe the other way around -- we nail down DTLS -SRTP, then figure out what we need from Identity to support it, then fix Identity. Or maybe we need to fix them both together. Now our AD is telling me that by reading it this way, I'm unprofessionally evidencing bias in favor of some other protocol that may have been discussed prior to DTLS-SRTP (and the name of which I honestly can't remember right now). I find this unlikely, given that I don't actually understand any of the protocols and only parrot what I read on the mailing list earlier today. So let's put it to the working group. Is there a relationship between DTLS-SRTP, phone numbers, and identity that needs to be figured out? If so, how much of a problem is this? Do we care? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 22:30:33 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D5F3A6EB5; Thu, 28 Feb 2008 22:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXRjaEgnL+QI; Thu, 28 Feb 2008 22:30:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077473A6E0F; Thu, 28 Feb 2008 22:30:32 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9D93A6BB2 for ; Thu, 28 Feb 2008 22:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxGfQj48GhRV for ; Thu, 28 Feb 2008 22:30:30 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id E189C3A6CC3 for ; Thu, 28 Feb 2008 22:30:29 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 9E2A35081A; Thu, 28 Feb 2008 22:32:14 -0800 (PST) Date: Thu, 28 Feb 2008 22:32:14 -0800 From: Eric Rescorla To: Dean Willis In-Reply-To: <57ED2BE6-1A90-4D15-A7E0-8366082BD6BA@softarmor.com> References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <47C7213A.5090000@cisco.com> <57ED2BE6-1A90-4D15-A7E0-8366082BD6BA@softarmor.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080229063214.9E2A35081A@romeo.rtfm.com> Cc: sip@ietf.org, Michael Thomas Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Thu, 28 Feb 2008 22:54:17 -0600, Dean Willis wrote: > > > > 2. Key discovery: Callers can generate the public key of the callee > > from the identity (SIP URI) of the callee and vice versa. This > > eliminates a requirement for a key discovery mechanism using > > external sources, making deployment significantly easier. > > > > Or you can ship the key or cert in the signaling too. > > yes, although those keys may be big (a problem for network resource > constrained environments), AND you have to ship them before they can > be used for encryption. For signing, I can send my cert along with a > signed message. But if I'm going to encrypt the message to you, I need > your public key BEFORE sending the message. > > Since the IB model generates public keys from SIP URIs, if I have > enough info on you to send you the message, then I also have enough to > encrypt it. Yes, this is a clear advantage of IBE over PKI-based systems. But as I said, it doesn't apply to IBS. Moreover, if there's any kind of retargeting, then IBE has real problems. > > 3. Certificate validation: As a result caller or callee need not go > > through the complex path construction process to retrieve the > > public keys of a chain of CAs from the public key depositories > > which are controlled by the respective CAs. This allows > > deployment in a peer-to-per modality without a need to route SIP > > messages through a centralized identity service or trust peer > > nodes to operate as identity services. > > > > What is the KG if not a centralized entity? I guess I don't > > understand this part. > > It's a centralized entity, but OUTSIDE of the signaling path. > Interaction with it is independent of interaction within the signaling > plane. > > Consider, for example, a P2PSIP deployment that may initially > bootstrap in a connected environment. Everybody talks to their PKGs > and gets keyed up. Then a disaster occurs, people jump in their > response vehicles, and rush off to the impact zone where they form an > ad-hoc network. Their keys still work without further access to the PKG. > > Contrast this to RFC 4474 identity servers, where each SIP request has > to go through a server, where a cryptographic process occurs. This is > a very load-sensitive centralized device without which the system > cannot function. But this is *by design* because the original system for public key end-to-end authentication, S/MIME which *did* use end-user certificates, was determined to be impractical, because--wait for it--end-entity enrollment was such a PITA. A situation which is *exactly* the same for IB* systems. > Sure, we could do something similar by having the "initial bootstrap" > include a CA process wherein everbody gets a cert. But now we need a > way of distributing the certs, either by broadcast or some sort of > query protocol. Why bother when an identity-based-encryption model > makes it so much easier? Again, you're conflating encryption with data origin authentication. Yes, this is an advantage of IBE, for encryption. It doesn't make it any easier for signature however, as noted above. > > 4. Revocation: The ease of minting new identities and discovering > > keys allows short-lived identities, reducing the need for > > certificate revocation lists and the checking thereof. This > > offers very large operational advantages in resource constrained > > environments. > > > > I don't understand why this is "easy". Enrollment is > > "hard" unless there's something really new here. And > > if I wanted a short-lived identity, I could just gin > > up a new public key pair and use that as the identity > > too. But I thought that the real problem was dealing with > > long term identities like, oh say, mat@cisco.com. > > > > Secondary enrollment, or at least minting a new identity, is > relatively easy, While the server load for crypto is comparable to > that of generating a cert, the amount of data on the wire is much > smaller. Uh, sure. You authenticate to the CA/KG and it sends you your new credential. In the case of the PKI, you get a new certificate, which is definitely less than 1KB, but since it's almost exactly the same as the old cert, what you really need is the new signature, so we can compress that down to 320-1024 bits, depending on the signature algorithm. In the case of BB signatures, to take one instantiation, the private key is 320 bits, so we're basically looking at a wash. Except, of course, that you need to transmit the private key securely whereas the certificate can be distributed over an insecure protocol, so once you factor in the overhead of the SSL connection (or S/MIME, or whatever) you use to distribute the private key, things start to look a lot worse. > Let's talk about conventional certificate revocation. There are ways > to make it better, but the basic model is that the CA builds a file of > every certificate it has ever revoked. It keeps this file forever > (theoretically, it could prune expired certs, but nobody does as they > keep getting used past their expiry), and keeps adding stuff to it. > Every time it adds something, it has to re-sign the file using the CA > cert. This file is called a "certificate revocation list", or CRL. > > If a user of certs from that CA wants to see if a cert that has not > expired is still valid, it does a GET of the CRL. This might be a very > large file. Assuming, say, 1 million users, 100 bytes per cert (only a > part of the cert needs to be in the CRL), and a revocation rate of > just 10%, after a year the CRL is over a megabyte in size. Since stuff > constantly gets added, every time a user needs to check a cert it has > to download the whole thing (or it checks periodically, giving us > windows during which revoked certs will continue to be used). Then > the user software does a liner search through the CRL every time it > wants to use a key. > > This sucks, so we have things like OSCP to add validity-verification > protocols that add round-trip operations before every usage of a cert. > Gee, that's very helpful if your network is resource constrained or > partitioned. I happen to be following the IETF's "server migration" > test list, and I'll note that two weeks after cutover, we're still > reporting OSCP problems. It is non-trivial to get right. At the > moment, one of our Most Notable Persons is reporting that the OSCP > servers used by IETF aren't reachable from his digs in Australia, > meaning all accesses to IETF's secured web sites fail authentication > checks and pop up nasty errors after an unconscionable delay. This > would NOT be helpful to first-responders in a disaster zone, I assure > you. Strangely, enough it happens, that I'm aware of all this, but the situation is *no different* for Identity-based signature. The way that IBS handles revocation is to make each identity short-lived and force the user to periodically fetch a new private key. This is *totally equivalent* to forcing the user to get a new certificate instead. Yes, people do generally use CRLs, because short-lived certs are actually a PITA, but PKI models can definitely be operated the same way that an IBS system can. Once again, all the advantages you're talking about are advantages of IBE, not IBS. And yes, IBE indeed does have different operational characteristics than PKI and these certainly may be an advantage in some environments. But that's not what this draft is abut. This draft is about IBS. And as noted in my original review, the benefits of IBS over conventional PKI in this setting are marginal at best. So, if you want to propose a draft that uses IBE for SIP encryption (and note that since there's are IBE for S/MIME drafts, this is simply a matter of reprofiling the algorithm set) you'll get a totally different reaction from me. But to keep talking about advantages of IBE as if they apply to this draft completely confuses the issue. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 22:36:22 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751E228C429; Thu, 28 Feb 2008 22:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7kDe80Avedp; Thu, 28 Feb 2008 22:36:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18F33A6BD4; Thu, 28 Feb 2008 22:36:16 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546D83A6BB2 for ; Thu, 28 Feb 2008 22:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2aJlTqKPkxy for ; Thu, 28 Feb 2008 22:36:09 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B2C483A6A3C for ; Thu, 28 Feb 2008 22:36:09 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 29 Feb 2008 01:35:45 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 29 Feb 2008 01:35:46 -0500 From: Hadriel Kaplan To: Eric Rescorla , Jonathan Rosenberg Date: Fri, 29 Feb 2008 01:35:20 -0500 Thread-Topic: [Sip] Doc we need to have draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda? Thread-Index: Ach6QCYIqI3MvwjARe6+QHxF+BA+swAVQAyA Message-ID: References: <47C6F876.4060809@softarmor.com> <47C70906.8000802@cisco.com> <20080228193046.9E4EF5081A@romeo.rtfm.com> In-Reply-To: <20080228193046.9E4EF5081A@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Dean Willis Subject: Re: [Sip] Doc we need to have draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eric > Rescorla > Sent: Thursday, February 28, 2008 2:31 PM > > > Jonathan Rosenberg wrote: > > One of the points I raise in my rfc4474-concerns draft is that dtls-srtp > > is basing integrity of the fingerprint on 4474, and that 4474 does not > > provide integrity against intermediary modifications of the number, and > > even for user@domain names this can happen. > > > > I think this needs to be called out in the draft. The security > > considerations section does not discuss this. > > Because it's not a DTLS-SRTP issue. It's a SIP/4474 issue. > > The fingerprint in the SIP messaging does *not* tie the DTLS-SRTP > handshake to the phone number or to the domain name. Rather, it ties > the media to the SIP signalling. Period. It allows whatever guarantees > you are prepared to assert about the signalling to be extended to > media. If those guarantees allow you to make assertions about the > caller (or callee) identity, then great. If not, then DTLS-SRTP > doesn't help, nor is it intended to. > > Look at it this way: > When the phone rings (or your UA shows you that the other side has > answered), it can show you some meta-information about who you're > talking to. The objections you have to RFC 4474 (and I'm not saying I > agree with them) already apply at this point, before a single RTP > packet has traversed the wire. This is not a DTLS-SRTP issue. I don't think he's claiming it's a "DTLS-SRTP" protocol issue, it's an issue for draft-ietf-sip-dtls-srtp-framework-01. Reading this draft it sure seems to me the draft makes claims rfc4474 can't live up to. It's not a knock on the idea, just that some statements the draft makes need some clarification/softening or elaboration. Not everyone reading it in the future lives and breathes this stuff as you do. :) For example, the end of section 2 says: Alice and Bob will verify the fingerprints from the certificates received over the DTLS handshakes match with the fingerprints received in the SDP of the SIP signaling. This provides the security property that Alice knows that the media traffic is going to Bob and vice-versa without necessarily requiring global PKI certificates for Alice and Bob. That is not actually true. In fact, it's not even true with perfect end-end rfc4474 - it requires rfc4916, afaik. (4474 only helps Bob, not Alice, right?) But even then it doesn't mean "Alice" and "Bob" know it to be absolute. Also section 8 says: As long as each side of the connection can verify the integrity of the SDP INVITE then the DTLS handshake cannot be hijacked via a man-in-the-middle attack. This integrity protection is easily provided by the caller to the callee (see Alice to Bob in Section 7) via the SIP Identity [RFC4474] mechanism. Well, rfc4474 doesn't actually provide integrity by the caller to callee, so clearly it can't be "easily" done using it. I should also note that section 7, which is referenced there as the way to do this, actually says: The SIP signaling from Alice to her proxy is transported over TLS to ensure an integrity protected channel between Alice and her identity service. That is also a nit error, in that the term "ensure" isn't right. Using TLS from the UAC to proxy ensures you're using TLS from the UA to the proxy. The proxy may or may not be the identity service, or may or may not be using TLS to your registrar, and your registrar may or may not be the identity service, and so on. Also, section 8 does describe the weaknesses of other mechanisms to bind the media to signaling, such as section 8.2 on SIPS. But it does not do so with regard to rfc4474. That implies to the average RFC reader there are none. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 23:53:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3490228C3E9; Thu, 28 Feb 2008 23:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew2bdq1knHgz; Thu, 28 Feb 2008 23:53:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C32428C18D; Thu, 28 Feb 2008 23:53:06 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086D63A6EE8 for ; Thu, 28 Feb 2008 23:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8COQdZWnPgp for ; Thu, 28 Feb 2008 23:52:59 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 51A7728C21F for ; Thu, 28 Feb 2008 23:52:59 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 29 Feb 2008 02:52:35 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 29 Feb 2008 02:52:33 -0500 From: Hadriel Kaplan To: Dean Willis , "sip@ietf.org List" Date: Fri, 29 Feb 2008 02:52:00 -0500 Thread-Topic: [Sip] Sanity check -- relationship between DTLS-SRTP and Identity Thread-Index: Ach6lQu429D9QrBMT4yGjSsycdWxUgADooQQ Message-ID: References: <41E96F53-A2D1-41EE-93A4-2E61099BDF1D@softarmor.com> In-Reply-To: <41E96F53-A2D1-41EE-93A4-2E61099BDF1D@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] Sanity check -- relationship between DTLS-SRTP and Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > > From the list conversation, it seems like some people think there's a > relationship between DTLS-SRTP and SIP Identity, aka RFC 4474. Yes, DTLS-SRTP without rfc4474 is an emperor with no clothes. > Other people think that there's a problem applying RFC 4474 when we > use phone numbers. Right, it no workie. > Some people think we use phone numbers a LOT, maybe almost all the > time, and that therefore we really need to figure out how this impacts > RFC 4474 and our other concepts of identity. 10-4, we need the 411 on numbers. > This makes it seem to me like maybe we need to get the identity stuff > nailed down before we commit to a final version of DTLS-SRTP. Or maybe > the other way around -- we nail down DTLS -SRTP, then figure out what > we need from Identity to support it, then fix Identity. Or maybe we > need to fix them both together. Well, Identity's a much bigger deal. Identity may not be fixable for numbers. I vote we finish up the DTLS-SRTP-framework draft for submission, and move on to Identity. DTLS-SRTP works in the context it is claimed to, and should not be held up just because we want to extend the context. If we figure out something needs to change later, we fix with a -bis or update. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 28 23:55:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3B528C964; Thu, 28 Feb 2008 23:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W01Ux+ZvxLlp; Thu, 28 Feb 2008 23:55:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECB428C46D; Thu, 28 Feb 2008 23:55:01 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C7C28C2BC for ; Thu, 28 Feb 2008 23:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC-i5v0v181n for ; Thu, 28 Feb 2008 23:54:59 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 7C39328C180 for ; Thu, 28 Feb 2008 23:54:59 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JWZ0049BPZFP9@siemenscomms.co.uk> for sip@ietf.org; Fri, 29 Feb 2008 07:54:51 +0000 (GMT) Date: Fri, 29 Feb 2008 07:54:49 +0000 From: "Elwell, John" In-reply-to: <41E96F53-A2D1-41EE-93A4-2E61099BDF1D@softarmor.com> To: Dean Willis , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D070BCDD@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Sanity check -- relationship between DTLS-SRTP and Identity Thread-Index: Ach6l1BV6f6HaRx0QmyQgkc/5c7NkAAD+l9A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <41E96F53-A2D1-41EE-93A4-2E61099BDF1D@softarmor.com> Subject: Re: [Sip] Sanity check -- relationship between DTLS-SRTP and Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, The DTLS-SRTP framework is clear that you depend on RFC 4474 to bind the secure media stream to an identity. There are two issues with RFC 4474 that have received considerable discussion and have led to a long list of I-Ds: - The E.164 problem - not a problem if we use DTLS-SRTP only with email-style SIP URIs, but some people would argue that this is not feasible. - The SBC problem. Both of these are real world problems that aren't going to disappear overnight as soon as networks deploy DTLS-SRTP. Rather, DTLS-SRTP will not be deployed because it won't work on existing infrastructure. I do want to see DTLS-SRTP completed, but not in a way that is of no use to much of the market. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: 29 February 2008 05:36 > To: sip@ietf.org List > Subject: [Sip] Sanity check -- relationship between DTLS-SRTP > and Identity > > > Ok, maybe I'm reading something wrong here. > > From the list conversation, it seems like some people think > there's a > relationship between DTLS-SRTP and SIP Identity, aka RFC 4474. > > Other people think that there's a problem applying RFC 4474 when we > use phone numbers. > > Some people think we use phone numbers a LOT, maybe almost all the > time, and that therefore we really need to figure out how > this impacts > RFC 4474 and our other concepts of identity. > > This makes it seem to me like maybe we need to get the > identity stuff > nailed down before we commit to a final version of DTLS-SRTP. > Or maybe > the other way around -- we nail down DTLS -SRTP, then figure > out what > we need from Identity to support it, then fix Identity. Or maybe we > need to fix them both together. > > Now our AD is telling me that by reading it this way, I'm > unprofessionally evidencing bias in favor of some other > protocol that > may have been discussed prior to DTLS-SRTP (and the name of which I > honestly can't remember right now). I find this unlikely, > given that I > don't actually understand any of the protocols and only > parrot what I > read on the mailing list earlier today. > > So let's put it to the working group. Is there a relationship > between > DTLS-SRTP, phone numbers, and identity that needs to be figured out? > If so, how much of a problem is this? Do we care? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 01:45:40 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563E13A68F9; Fri, 29 Feb 2008 01:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLqVn7H8SWLR; Fri, 29 Feb 2008 01:45:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0FBC28C21F; Fri, 29 Feb 2008 01:45:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5C33A69D6 for ; Fri, 29 Feb 2008 01:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6Qi7SjVMsxo for ; Fri, 29 Feb 2008 01:45:32 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 570C33A6838 for ; Fri, 29 Feb 2008 01:45:32 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1T9jGGo028001; Fri, 29 Feb 2008 11:45:22 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 11:45:12 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 11:45:12 +0200 Received: from [10.144.23.25] ([10.144.23.25]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 11:45:12 +0200 Message-ID: <47C7D428.5030002@nsn.com> Date: Fri, 29 Feb 2008 11:45:12 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Adam Roach References: <47C54730.5030501@nsn.com> <47C5DCA6.9080302@cisco.com> <47C680E3.2030803@nsn.com> <47C6C841.2010201@cisco.com> <47C6D42D.8040506@nsn.com> <47C718A8.5080404@nostrum.com> In-Reply-To: <47C718A8.5080404@nostrum.com> X-OriginalArrivalTime: 29 Feb 2008 09:45:12.0601 (UTC) FILETIME=[C793B890:01C87AB7] X-Nokia-AV: Clean Cc: IETF SIP List Subject: [Sip] Canceling a file transfer [Was Re: Comments to the TOTE draft] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Adam Roach wrote: > > For canceling a file transfer -- that is, a single MIME object -- you're > better off using the approach described in section 10.5 of RFC 4975. > Otherwise, you're running the risk of throwing out an ongoing IM session > just because you don't want to complete a specific file transfer. Point taken, I agree with it. I think we will add this and other clarifications to the file transfer draft. > > In the pause case, I agree that putting the MSRP stream on hold is a > valid way to convey the semantics of, "I want you to pause everything > inside this MSRP session," including the file transfer, but by no means > limited to it. For most IM-related use cases, it would seem that this is > very unlikely to be what the user expects, wants, or is even willing to > put up with. Notice that the file transfer draft requires a single MSRP session for file transfer, so pausing the MSRP session will only have effect on the file transfer. In any case, I agree on the benefits of using the 413 response. > > For example: imagine that we're in an IM session using a client designed > as you propose above. You start sending me a 5 Mb file. A dialog box > pops up on my screen that conveys the progress of this file; it contains > two buttons: [Pause], and [Cancel]. I press the button marked "Pause," > and the file stops arriving. And suddenly you stop responding to my > instant messages. Perhaps I manage to guess that the IM session has > frozen because I paused the file transfer. So, to fix this, I press > [Cancel]. And the whole IM window just goes away. As I said, this wouldn't happen with any of the proposals, because the MSRP session of the file transfer is different from that of the instant messaging. /Miguel > > /a -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 03:03:13 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8CFB28C51D; Fri, 29 Feb 2008 03:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrYBf8bFROYv; Fri, 29 Feb 2008 03:03:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A725C28C50E; Fri, 29 Feb 2008 03:03:04 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E6D28C418 for ; Fri, 29 Feb 2008 03:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOu7FShHKlsS for ; Fri, 29 Feb 2008 03:03:01 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 08B2228C551 for ; Fri, 29 Feb 2008 03:02:43 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m1TB2L6X023024; Fri, 29 Feb 2008 05:02:22 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 05:01:05 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 12:00:44 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 12:00:42 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Revised agenda for SIP -- needs more work yet Thread-index: Ach6lJtyVqA0XcrFSw2lJTLkza0HswAJrFMQ References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com><47C73D16.9080103@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 29 Feb 2008 11:00:44.0314 (UTC) FILETIME=[54B03FA0:01C87AC2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: IETF SIP List Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (As SIP WG cochair) As Dean already said, we spend 3 hours last night trying to plan a 2 1/2 hour session based on input we do not completely have. We don't think we finished, but this was the best we could reach so far in the time available. Things can move up, but they don't solve the fundamental problem that we don't have enough time. It was not our idea to limit SIP to a single session - this was forced on us by the ADs. Modification of this agenda is more likely to occur not by complaining about the time allocated, but by the presence of technical discussion on list over the next 8 days. Some generals: We have taken the principle that if discussion time is needed on chartered items specifically, then they come first, and more specifically highest priority for any discussion needed to get something out of WGLC and into publication request. This is then followed by documents that we envisaged could hold up chartered items (in this and other groups) if not discussed. Then follow the other items where time has been requested. Some specifics based on comments received so far: Domain-certs and eku are in WGLC which ends of Friday next week. These are a dependency from other chartered items where we are ready to submit the publication request. We will not have a view of what specifically needs discussion on these in the meeting until the end of the WGLC, when all the comments are in. Many of the comments made will not need discussion in the SIP session and can be discussed on list by the editors after the end of last call. If any comment does need SIP WG session time, then we will give it on the above basis. Outbound is in WGLC and has no time. We are still waiting for input to know if it needs time - not helped by the authors dropping yet another new version in the inbox 3 minutes before the -xx deadline when it should have been there a month ago. Our current view is to issue a refreshed WGLC on this following the meeting but that can change. Location conveyance is in WGLC and has no time. Again author drops new version in inbox 3 minutes before -xx document deadline. This document is impacted by: http://www.ietf.org/internet-drafts/draft-peterson-geopriv-retransmissio n-00.txt Which will be discussed in the GEOPRIV group, but if followed reverses the decision we made in the location-conveyance breakout at the last meeting. We hope the GEOPRIV discussion does not force rediscussion in SIP, but please bear in mind that it could do so. RPH in responses is not chartered. 2 meetings back the WG expressed a wish to work on this. The AD pushed back to our request to charter. As the AD makes the decision, it is not chartered and has no milestones. That's why we had the further discussion in the last meeting - where again we came to no conclusions, and I assume the AD is still unconvinced. Fundamental problem - convince the AD. Put him in a corner somewhere in Philadelphia and kick hell out of him, but we don't need the SIP session to watch you do that - although it may be entertaining! Media security requirements is holding up other chartered items in both SIP and AVT. When we considered this for inclusion, we believed there were two items that may need agenda item. Overnight Dean seems to have taken the time away at the moment, but I remain unconvinced that this does not need time. This is the media-security requirements milestones: Sep 2007 Requirements for media keying to WGLC (Informational) Nov 2007 Requirements for media keying to IESG (Informational) Which provides the requirements for the mechanism in these charter items in SIP. Dec 2007 Establishment of secure media sessions using DTLS-SRTP to WGLC (PS) Feb 2008 Establishment of secure media sessions using DTLS-SRTP to IESG (PS) And these chartered items in AVT: Dec 2007 Submit in band keying mechanism for SRTP draft for Proposed Standard Regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Friday, February 29, 2008 5:33 AM > To: Dean Willis > Cc: IETF SIP List > Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet > > > On Feb 28, 2008, at 8:57 PM, Dean Willis wrote: > > > > > On Feb 28, 2008, at 5:00 PM, Jonathan Rosenberg wrote: > > > > > 10 minutes on the phone number dichotomy thing isn't going to be > > > even close enough to cut it. It should be either zero or a more > > > significant number. > > > > > > We have 30 minutes on media security. The only chartered > item there > > > is the requiremetns document which I thought was mostly > done. Why is > > > there so much time dedicated to this? I would rather move that to > > > INFO or the identity mess. > > > > Me too. But hey, the media security requirements document is > > CHARTERED. We have permission to work on it and a commitment to a > > deliverable, with a published milestone. We don't have that > for INFO > > or the identity mess (even though I think media security is > blocked on > > the identity mess -- our AD currently disagrees). > > > > Dean - I think we must be having some serious > miscommunications - many times in the past I have had enough > typos in my emails that no one could understand what I might > have been thinking but .... > > I don't think I said that. The two things I thought I said > that might have been confused are: > > 1) I don't think the E.164 discussion is holding up milestone > items in MEDIACTRL or SIMPLE > > 2) I don't think a problem in some mechanism such as 4474 > should be holding up the media security requirements draft. > (If I could bold requirements in the previous sentences I would) > > I certainly do think it is important that we have a clear > understanding of how E.164 numbers fit into the overall SIP > security picture. Sorry if I said something that made you > think otherwise. > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 06:12:08 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8D93A6F54; Fri, 29 Feb 2008 06:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT93aKYMRo5c; Fri, 29 Feb 2008 06:12:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A23D3A6F40; Fri, 29 Feb 2008 06:12:03 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D2D3A6F3A for ; Fri, 29 Feb 2008 06:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It0i8WeYU2cf for ; Fri, 29 Feb 2008 06:11:57 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id EBA833A68DF for ; Fri, 29 Feb 2008 06:11:56 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id B954D5081A; Fri, 29 Feb 2008 06:13:41 -0800 (PST) Date: Fri, 29 Feb 2008 06:13:41 -0800 From: Eric Rescorla To: "DRAGE, Keith (Keith)" In-Reply-To: <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> <47C73D16.9080103@cisco.com> <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080229141341.B954D5081A@romeo.rtfm.com> Cc: Cullen Jennings , IETF SIP List , Dean Willis Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Fri, 29 Feb 2008 12:00:42 +0100, DRAGE, Keith (Keith) wrote: > Media security requirements is holding up other chartered items in both > SIP and AVT. When we considered this for inclusion, we believed there > were two items that may need agenda item. Overnight Dean seems to have > taken the time away at the moment, but I remain unconvinced that this > does not need time. > > This is the media-security requirements milestones: > > Sep 2007 Requirements for media keying to WGLC (Informational) > Nov 2007 Requirements for media keying to IESG (Informational) > > Which provides the requirements for the mechanism in these charter items > in SIP. > > Dec 2007 Establishment of secure media sessions using DTLS-SRTP to > WGLC (PS) > Feb 2008 Establishment of secure media sessions using DTLS-SRTP to > IESG (PS) > > And these chartered items in AVT: > > Dec 2007 Submit in band keying mechanism for SRTP draft for Proposed > Standard For what it's worth, being neither chair nor AD, I absolutely want media-security-requirements to finish and if there are significant comments on the document, I 100% endorse giving it agenda time. That said, based on my review and the lack of traffic on the list, my opinion is that there aren't any major issues[0], so we should declare victory and move on! Thanks, -Ekr [0] The only real issues I raised in my comment were: - Should we remove the survey from the appendix. I'm fine leaving it in, since I was mostly worried about it needing constant update. - Requirement R-RECORD. I think we could just take a straw poll on this one. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 06:22:11 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2587828C3F7; Fri, 29 Feb 2008 06:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKw1VB-TABAD; Fri, 29 Feb 2008 06:22:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C5E3A6D50; Fri, 29 Feb 2008 06:22:05 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE283A6D50 for ; Fri, 29 Feb 2008 06:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXicdb8CxeNk for ; Fri, 29 Feb 2008 06:21:58 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 010773A6A02 for ; Fri, 29 Feb 2008 06:21:57 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1TELHjO025382; Fri, 29 Feb 2008 16:21:43 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:21:20 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:21:20 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:21:19 +0200 Received: from [172.21.40.116] (esdhcp040116.research.nokia.com [172.21.40.116]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1TELIQL030037; Fri, 29 Feb 2008 16:21:18 +0200 From: Aki Niemi To: ext Dean Willis In-Reply-To: References: <5D1A7985295922448D5550C94DE2918001636AF1@DEEXC1U01.de.lucent.com> <200709181506.l8IF6Bmp007748@dragon.ariadne.com> <1203976392.6192.88.camel@localhost> <200802262131.m1QLV7Rm008476@dragon.ariadne.com> <1204099738.16881.21.camel@localhost> Organization: Nokia Devices R&D Date: Fri, 29 Feb 2008 16:21:11 +0200 Message-Id: <1204294871.16881.142.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 29 Feb 2008 14:21:20.0018 (UTC) FILETIME=[5A86EF20:01C87ADE] X-Nokia-AV: Clean Cc: IETF SIP List Subject: Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On to, 2008-02-28 at 13:35 -0600, ext Dean Willis wrote: > > I see that Dale and Aki are discussing this draft. > > Do we need agenda time in Philadelphia for further discussion, or are > we really ready for publication? As far as I'm concerned, this is ready for publication. I think the issue that remains does not warrant WG time. I think in principal me and Dale agree, but we just need to figure out what (if anything) the draft should say on the issue. In any case, this text would probably end up being non-normative, which means it's not critical to flesh out in detail for a publication request. Cheers, Aki _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 06:38:39 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A618528C4AA; Fri, 29 Feb 2008 06:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd0yiEISGeJp; Fri, 29 Feb 2008 06:38:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7013A6B3A; Fri, 29 Feb 2008 06:38:28 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D491B3A6D5E for ; Fri, 29 Feb 2008 06:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAexFx9SfHpM for ; Fri, 29 Feb 2008 06:38:21 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 409383A6BD3 for ; Fri, 29 Feb 2008 06:37:27 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m1TEbClR028658; Fri, 29 Feb 2008 08:37:12 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 08:37:12 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 15:37:09 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 15:37:09 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001CB0782@DEEXC1U01.de.lucent.com> In-Reply-To: <20080229141341.B954D5081A@romeo.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-media-security-requirements-03 was RE: [Sip] Revised agenda for SIP -- needs more work yet Thread-index: Ach63Q/yrUFWjN71Tp+8+71zhgEz9gAAnEVA References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com><47C73D16.9080103@cisco.com><5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> <20080229141341.B954D5081A@romeo.rtfm.com> From: "DRAGE, Keith \(Keith\)" To: "Eric Rescorla" X-OriginalArrivalTime: 29 Feb 2008 14:37:09.0791 (UTC) FILETIME=[90A2CAF0:01C87AE0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: Cullen Jennings , IETF SIP List , Dean Willis Subject: [Sip] draft-ietf-sip-media-security-requirements-03 was RE: Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well one of the issues I thought needed agenda time was yours from yesterday. --------------------------------------------------------------------- GENERAL COMMENTS I'm concerned about the apparent lack of stability of this draft. When this draft was originally published, it seemed to me to have two purposes: - To capture the BOF consensus on the important security properties for an RTPSEC protocol. - To be a survey for the properties of the various protocols compared to those requirements. The first purpose still seems useful to me, but is best served by having a draft that reflects that consensus published ASAP. The second purpose seems to me to have been sort of overtaken by events and I'm not sure it's still valuable. With the first purpose firmly in mind, it seems a little problematic that this draft has changed so much in the past 6-12 months. In particular: - The -02 version totally renamed all the requirements - I'm not convinced that all the requirements introduced in -00 have WG consensus. Since there are other documents which need to reference these requirements, this presents a problem for them. ------------------------------------------------------------------- This seemed to be a concern about scope creep, and as it is the chairs that have probably allowed that creep, it is probably difficult for them to direct it back to where it ought to be. This is coupled with a concern about whether all the requirements have consensus. This seemed to be something that we would normally deal with in the WG session to see if this comment was representative on the rest of the group and trying to judge how to fix the problem. Note that we have absolutely no issue with resolving comments like this on list - if we are able to. Other input is welcome to resolve this, and please identify any specific requirements that you believe do not have consensus. Regards Keith > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Friday, February 29, 2008 2:14 PM > To: DRAGE, Keith (Keith) > Cc: Cullen Jennings; Dean Willis; IETF SIP List > Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet > > At Fri, 29 Feb 2008 12:00:42 +0100, > DRAGE, Keith (Keith) wrote: > > Media security requirements is holding up other chartered items in > > both SIP and AVT. When we considered this for inclusion, we > believed > > there were two items that may need agenda item. Overnight > Dean seems > > to have taken the time away at the moment, but I remain unconvinced > > that this does not need time. > > > > This is the media-security requirements milestones: > > > > Sep 2007 Requirements for media keying to WGLC (Informational) > > Nov 2007 Requirements for media keying to IESG (Informational) > > > > Which provides the requirements for the mechanism in these charter > > items in SIP. > > > > Dec 2007 Establishment of secure media sessions using > DTLS-SRTP to > > WGLC (PS) > > Feb 2008 Establishment of secure media sessions using > DTLS-SRTP to > > IESG (PS) > > > > And these chartered items in AVT: > > > > Dec 2007 Submit in band keying mechanism for SRTP draft > for Proposed > > Standard > > For what it's worth, being neither chair nor AD, I absolutely > want media-security-requirements to finish and if there are > significant comments on the document, I 100% endorse giving > it agenda time. > > That said, based on my review and the lack of traffic on the > list, my opinion is that there aren't any major issues[0], so > we should declare victory and move on! > > > Thanks, > -Ekr > > [0] The only real issues I raised in my comment were: > - Should we remove the survey from the appendix. I'm fine > leaving it in, since I was mostly worried about it > needing constant update. > - Requirement R-RECORD. I think we could just take a > straw poll on this one. > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 07:12:21 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51C028C539; Fri, 29 Feb 2008 07:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur8XVS8AJY7z; Fri, 29 Feb 2008 07:12:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7F43A6D50; Fri, 29 Feb 2008 07:12:16 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B883A685D for ; Fri, 29 Feb 2008 07:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHqmabcsG1nU for ; Fri, 29 Feb 2008 07:12:15 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id E60C23A6D50 for ; Fri, 29 Feb 2008 07:12:14 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m1TFC67j009073 for ; Fri, 29 Feb 2008 09:12:07 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 09:11:21 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:11:15 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 16:11:15 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001CB07B3@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [Sip] WGLC on domain-certs and eku Thread-index: Ach4SlpRAJ037ZR1QaiL0mG8gPEHnwCmuPUw From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 29 Feb 2008 15:11:15.0888 (UTC) FILETIME=[54346B00:01C87AE5] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [Sip] FW: FW: WGLC on domain-certs and eku X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org For info, some comments from Steven Kent of PKIX on the eku document Keith -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, February 25, 2008 5:49 PM To: DRAGE, Keith (Keith) Cc: pkix-chairs@tools.ietf.org; Dean Willis Subject: Re: FW: [Sip] WGLC on domain-certs and eku Keith, Here are a few comments on the SIP-EKU I-D: - the document does not seem to state explicitly that the cert SHOULD/MUST contain a SAN with a DNS name. The references to the domain name in section 2 never say where the name should appear. Even if this is discussed separately in the SIP domain cert I-D (I'm on a flight now and don't have access to the net to grab that I-D, so I don't now for sure), it should be reiterated here, so that a reader can be reminded of whatever constraints apply to where the domain name appears. - section 3 contains references to other EKUs, ones defined more broadly for TLS use, but it refers to them only by name. Some references and a brief note on he usual semantics associated with these EKUs would make this section more self-contained. - section 4 says "If the certificate contains the id-kp-sipDomain EKU extension, then the certificate MUST be accepted as valid for use as a SIP certificate." This probably should be reworded as cert path validation is a complex process and the presence of this EKU value does not cause the cert to be "valid" in a larger context. - the secruity considerations section is pretty thin. For example, I'd expect some discussion the implications of the various "local policy" bullets in section 4, and why they are there (e.g., for backward compatibility). Steve _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 07:19:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0922528C4C4; Fri, 29 Feb 2008 07:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WIMbdyVUa70; Fri, 29 Feb 2008 07:19:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D14A28C1D6; Fri, 29 Feb 2008 07:19:31 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808A528C1D6 for ; Fri, 29 Feb 2008 07:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0Veb1yBRDlO for ; Fri, 29 Feb 2008 07:19:23 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 850273A6D50 for ; Fri, 29 Feb 2008 07:19:13 -0800 (PST) Received: from [192.168.2.235] (pool-71-164-169-219.dllstx.fios.verizon.net [71.164.169.219]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m1TFHlEV041496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Feb 2008 09:17:47 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com><47C73D16.9080103@cisco.com> <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <5A561DF8-2237-4D1C-9B42-CB82C48A6C4A@nostrum.com> From: Robert Sparks Date: Fri, 29 Feb 2008 09:17:45 -0600 To: Keith Drage , Jonathan Rosenberg X-Mailer: Apple Mail (2.753) Received-SPF: pass (nostrum.com: 71.164.169.219 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92.1/6044/Fri Feb 29 08:17:12 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: Cullen Jennings , IETF SIP List , Dean Willis Subject: [Sip] Essential Corrections - invfix (was Re: Revised agenda for SIP -- needs more work yet) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Folks - Lets try to get the Essential Corrections and -invfix- discussion off the agenda since there are clearly gnarlier things to talk about. I sent in a revision to inv-fix attempting to address Jonathan's concern about stand-alone readability. Jonathan - is the new format better? Can we go with this? I sent a separate message showing what it would look like to build a diff against 3261 that we could put in the document. You'll remember that on looking at it, its my opinion that going down that path is a very bad idea. So far, there's only been one response on list to those messages. Please, everyone (especially those that have expressed strong opinions in the past), look those over and let us know if we're past the primary concerns, or if we still have something to work through that needs face time to do so. RjS On Feb 29, 2008, at 5:00 AM, DRAGE, Keith ((Keith)) wrote: > (As SIP WG cochair) > > As Dean already said, we spend 3 hours last night trying to plan a > 2 1/2 > hour session based on input we do not completely have. We don't > think we > finished, but this was the best we could reach so far in the time > available. Things can move up, but they don't solve the fundamental > problem that we don't have enough time. It was not our idea to > limit SIP > to a single session - this was forced on us by the ADs. > > Modification of this agenda is more likely to occur not by complaining > about the time allocated, but by the presence of technical > discussion on > list over the next 8 days. > > Some generals: > > We have taken the principle that if discussion time is needed on > chartered items specifically, then they come first, and more > specifically highest priority for any discussion needed to get > something > out of WGLC and into publication request. This is then followed by > documents that we envisaged could hold up chartered items (in this and > other groups) if not discussed. Then follow the other items where time > has been requested. > > Some specifics based on comments received so far: > > Domain-certs and eku are in WGLC which ends of Friday next week. These > are a dependency from other chartered items where we are ready to > submit > the publication request. We will not have a view of what specifically > needs discussion on these in the meeting until the end of the WGLC, > when > all the comments are in. Many of the comments made will not need > discussion in the SIP session and can be discussed on list by the > editors after the end of last call. If any comment does need SIP WG > session time, then we will give it on the above basis. > > Outbound is in WGLC and has no time. We are still waiting for input to > know if it needs time - not helped by the authors dropping yet another > new version in the inbox 3 minutes before the -xx deadline when it > should have been there a month ago. Our current view is to issue a > refreshed WGLC on this following the meeting but that can change. > > Location conveyance is in WGLC and has no time. Again author drops new > version in inbox 3 minutes before -xx document deadline. This document > is impacted by: > > http://www.ietf.org/internet-drafts/draft-peterson-geopriv- > retransmissio > n-00.txt > > Which will be discussed in the GEOPRIV group, but if followed reverses > the decision we made in the location-conveyance breakout at the last > meeting. We hope the GEOPRIV discussion does not force rediscussion in > SIP, but please bear in mind that it could do so. > > RPH in responses is not chartered. 2 meetings back the WG expressed a > wish to work on this. The AD pushed back to our request to charter. As > the AD makes the decision, it is not chartered and has no milestones. > That's why we had the further discussion in the last meeting - where > again we came to no conclusions, and I assume the AD is still > unconvinced. Fundamental problem - convince the AD. Put him in a > corner > somewhere in Philadelphia and kick hell out of him, but we don't need > the SIP session to watch you do that - although it may be > entertaining! > > Media security requirements is holding up other chartered items in > both > SIP and AVT. When we considered this for inclusion, we believed there > were two items that may need agenda item. Overnight Dean seems to have > taken the time away at the moment, but I remain unconvinced that this > does not need time. > > This is the media-security requirements milestones: > > Sep 2007 Requirements for media keying to WGLC (Informational) > Nov 2007 Requirements for media keying to IESG (Informational) > > Which provides the requirements for the mechanism in these charter > items > in SIP. > > Dec 2007 Establishment of secure media sessions using DTLS-SRTP to > WGLC (PS) > Feb 2008 Establishment of secure media sessions using DTLS-SRTP to > IESG (PS) > > And these chartered items in AVT: > > Dec 2007 Submit in band keying mechanism for SRTP draft for > Proposed > Standard > > > Regards > > Keith > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Cullen Jennings >> Sent: Friday, February 29, 2008 5:33 AM >> To: Dean Willis >> Cc: IETF SIP List >> Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet >> >> >> On Feb 28, 2008, at 8:57 PM, Dean Willis wrote: >> >>> >>> On Feb 28, 2008, at 5:00 PM, Jonathan Rosenberg wrote: >>> >>>> 10 minutes on the phone number dichotomy thing isn't going to be >>>> even close enough to cut it. It should be either zero or a more >>>> significant number. >>>> >>>> We have 30 minutes on media security. The only chartered >> item there >>>> is the requiremetns document which I thought was mostly >> done. Why is >>>> there so much time dedicated to this? I would rather move that to >>>> INFO or the identity mess. >>> >>> Me too. But hey, the media security requirements document is >>> CHARTERED. We have permission to work on it and a commitment to a >>> deliverable, with a published milestone. We don't have that >> for INFO >>> or the identity mess (even though I think media security is >> blocked on >>> the identity mess -- our AD currently disagrees). >>> >> >> Dean - I think we must be having some serious >> miscommunications - many times in the past I have had enough >> typos in my emails that no one could understand what I might >> have been thinking but .... >> >> I don't think I said that. The two things I thought I said >> that might have been confused are: >> >> 1) I don't think the E.164 discussion is holding up milestone >> items in MEDIACTRL or SIMPLE >> >> 2) I don't think a problem in some mechanism such as 4474 >> should be holding up the media security requirements draft. >> (If I could bold requirements in the previous sentences I would) >> >> I certainly do think it is important that we have a clear >> understanding of how E.164 numbers fit into the overall SIP >> security picture. Sorry if I said something that made you >> think otherwise. >> >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 07:24:24 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C7E3A6F5F; Fri, 29 Feb 2008 07:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5mvoTxfMyAI; Fri, 29 Feb 2008 07:24:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6685E3A6B0A; Fri, 29 Feb 2008 07:24:18 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDA73A6BD3 for ; Fri, 29 Feb 2008 07:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNlZhqttwUvO for ; Fri, 29 Feb 2008 07:24:16 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id EFD2B3A6A02 for ; Fri, 29 Feb 2008 07:24:15 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m1TFO1Rg025925 for ; Fri, 29 Feb 2008 09:24:08 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 09:24:06 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:24:03 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 16:24:03 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001CB07C2@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: domain certs for SIP I-D Thread-index: Ach6isKSSu8vryBXSoOXB7EuOU7hlwAXA9kw From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 29 Feb 2008 15:24:03.0883 (UTC) FILETIME=[1DF727B0:01C87AE7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [Sip] FW: domain certs for SIP I-D X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org For information from Stephen Kent of PKIX. There was an attachment with detailed comments which I have deleted to avoid exceeding the size limitations. If anyone wants to see this then please contact the domain-certs authors, or failing that myself, and request a personal copy. Regards Keith -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, February 29, 2008 4:22 AM To: Gurbani, Vijay K (Vijay); slawrence@bluesocket.com; Jeffrey, Alan S A (Alan) Cc: DRAGE, Keith (Keith); dean.willis@softarmor.com; Stephen Kent; Stefan Santesson; tim.polk@nist.gov Subject: domain certs for SIP I-D Folks, Having just read and reviewed the EKU use in SIP certs I-D, I thought it appropriate to review this I-D, since most of the details for SIP certs and their use line in this document. Overall I think the document does a very good job of making several clear statement about a cert profile for use with TLS in the SIP context, as well as usage conventions, and I think the statements are good ones as well! It does have some ambiguous text in the early parts of the document, which I have noted via comments. I also suggested a number of edits, which makes for a modest amount of "red ink." I think you should consider moving the EKU discussion into this I-D, since EKU details are minor relative to the rest of the cert profile and use discussion. If you have any questions, don't hesitate to contact me. Steve _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 07:28:34 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359073A6F6F; Fri, 29 Feb 2008 07:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BksPAi9VWaIg; Fri, 29 Feb 2008 07:28:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8293A6CF9; Fri, 29 Feb 2008 07:28:27 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAAE3A6A56 for ; Fri, 29 Feb 2008 07:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5JvhmcztWsV for ; Fri, 29 Feb 2008 07:28:24 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D42D23A685D for ; Fri, 29 Feb 2008 07:28:23 -0800 (PST) Received: from [192.168.2.235] (pool-71-164-169-219.dllstx.fios.verizon.net [71.164.169.219]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m1TFSEax042110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Feb 2008 09:28:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0602AEF@GBNTHT12009MSX.gb002.siemens.net> References: <20080207212223.2EF3B3A6F42@core3.amsl.com> <0D5F89FAC29E2C41B98A6A762007F5D0602AEF@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <1225B736-0A77-4E62-A275-9244BD3F3B86@nostrum.com> From: Robert Sparks Date: Fri, 29 Feb 2008 09:28:12 -0600 To: "Elwell, John" X-Mailer: Apple Mail (2.753) Received-SPF: pass (nostrum.com: 71.164.169.219 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92.1/6044/Fri Feb 29 08:17:12 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip List Subject: Re: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1169039098==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1169039098== Content-Type: multipart/alternative; boundary=Apple-Mail-39-505909598 --Apple-Mail-39-505909598 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed John - sorry for the slow reply - I wrote a reply the day you sent this, but as far as I can tell it got eaten before it made it to the list. I didn't intend section 7 to be "just" a description - you inferred that from "this section describes"?. Yes, the document has the risk you describe. I don't think we can avoid that without giving up making a standalone section that's as clear as Jonathan wants or specifying exactly what changes in 3261. The only way to mitigate that risk is careful review, which I think is possible given that the scope of this fix (and all *fix documents) should be pretty small. I feel pretty strongly that _for this change_, specifying exactly what gets touched in 3261 is important or we'll end up with interoperability arguments. The language that got touched is argued through at each SIPit already - not making it as crystal clear as possible how it gets impacted will make that worse. Whether or not we need to do that for every *fix document, I don't feel quite as strongly about, but this one is an existence proof that we'll need it for some. RjS On Feb 8, 2008, at 1:31 AM, Elwell, John wrote: > Robert, > > So we have two sections containing RFC 2119 language and saying the > same thing in different ways. If section 7 is just a description, > as it claims, then should it not avoid RFC 2119 language. > Otherwise, which section takes precedence in the event of a conflict? > > John > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf > Of Robert Sparks > Sent: 07 February 2008 21:35 > To: sip List > Subject: [Sip] Fwd: New Version Notification for draft-sparks-sip- > invfix-01 > > Based on the feedback from the -00 draft, I've added a section that > details the changes this draft makes > in a more descriptive form (in addition to the patching-the-text > form that already exists). > > Please look at the new section 7 and see if this addresses the > concerns around the document format. > > I also spent some time experimenting with the suggestions to > provide the changes in a diff format and have > not found anything promising. For the sake of discussion, I did > prepare a patch file that I'll send in a separate > message. I'm becoming more convinced that that's the wrong approach > to take though. We really don't want > to create some form of derived document that's the "current spec". > If we really want a new document, lets create > a bis and be done with it. > > The point of creating the patch-the-text form in the first place > was not to facilitate creating a new > document out of the old document. It was done so that the impact of > the changes on the spec is > expressed in as unambiguous a form as possible. The worst outcome > would be an update that > _didn't_ make these explicit statements and half of the > implementors in the world end up looking > at a section and saying "Oh, I didn't know it meant to change _that_". > > RjS > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: February 7, 2008 3:22:23 PM CST >> To: RjS@nostrum.com >> Subject: New Version Notification for draft-sparks-sip-invfix-01 >> >> >> A new version of I-D, draft-sparks-sip-invfix-01.txt has been >> successfuly submitted by Robert Sparks and posted to the IETF >> repository. >> >> Filename: draft-sparks-sip-invfix >> Revision: 01 >> Title: Correct transaction handling for 200 responses to Session >> Initiation Protocol INVITE requests >> Creation_date: 2008-02-07 >> WG ID: Independent Submission >> Number_of_pages: 18 >> >> Abstract: >> This document normatively updates RFC 3261, the Session Initiation >> Protocol (SIP), to address an error in the specified handling of >> success (200 class) responses to INVITE requests. Elements following >> RFC 3261 exactly will misidentify retransmissions of the request as a >> new, unassociated, request. The correction involves modifying the >> INVITE transaction state machines. The correction also changes the >> way responses that cannot be matched to an existing transaction are >> handled to address a security risk. >> >> >> >> The IETF Secretariat. >> >> > --Apple-Mail-39-505909598 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 John - sorry for the slow reply - I wrote a reply the day you sent this, = but as far as I can tell it got eaten before it made it to the = list.

    I didn't intend section 7 to be "just" a = description - you inferred that from "this section = describes"?.

    Yes, the document has the risk you = describe. I don't think we can avoid that without giving up making a = standalone section that's
    as clear as Jonathan wants or = specifying exactly what changes in 3261. The only way to mitigate that = risk is careful review, which
    I think is possible given that = the scope of this fix (and all *fix documents) should be pretty = small.

    I = feel pretty strongly that _for this change_, specifying exactly what = gets touched in 3261 is important or we'll end up with = interoperability
    arguments. The language that got touched is = argued through at each SIPit already - not making it as crystal clear as = possible how it gets
    impacted will make that worse. Whether or = not we need to do that for every *fix document, =A0I don't feel quite as = strongly about, but this one
    is an existence=A0proof that = we'll need it for some.

    RjS


    On Feb 8, = 2008, at 1:31 AM, Elwell, John wrote:

    Robert,
    =
    =A0
    So we have two sections = containing RFC 2119 language and saying the same thing in different = ways. If section 7 is just a description, as it claims, then should it = not avoid RFC 2119 language. Otherwise, which section takes precedence = in the event of a conflict?
    =A0
    John

    =
    From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf Of Robert Sparks
    Sent: 07 February 2008 = 21:35
    To: sip List
    Subject: [Sip] Fwd: New Version = Notification for draft-sparks-sip-invfix-01

    =
    Based on the feedback from the -00 draft, I've added a = section that details the changes this draft makes
    in a more = descriptive form (in addition to the patching-the-text form that = already exists).

    =
    Please look at the new section 7 and see if this addresses the = concerns around the document format.

    I also spent some time = experimenting with the suggestions to provide the changes in a diff = format and have
    not found anything promising. For the sake = of discussion, I did prepare a patch file that I'll send in a = separate
    message. I'm becoming more convinced that that's = the wrong approach to take though. We really don't want
    to = create some form of derived document that's the "current spec". If we = really want a new document, lets create
    a bis and be done = with it.

    =
    The point of creating the patch-the-text form in the first place = was not to facilitate creating a new
    document out of the = old document. It was done so that the impact of the changes on the = spec is
    expressed in as unambiguous a form as possible. The = worst outcome would be an update that
    _didn't_ make these = explicit statements and half of the implementors in the world end up = looking=A0
    at a section=A0and saying "Oh, I didn't know it = meant to change _that_".

    RjS

    Begin = forwarded message:

    =
    From: IETF I-D Submission Tool = <idsubmission@ietf.org>=
    Date: February 7, 2008 3:22:23 PM = CST
    Subject: = New Version Notification for = draft-sparks-sip-invfix-01=A0


    A new version of I-D, = draft-sparks-sip-invfix-01.txt has been successfuly submitted by Robert = Sparks and posted to the IETF repository.

    Filename: draft-sparks-sip-invfix
    Revision: 01
    Title: = Correct transaction handling for 200 responses to = Session Initiation Protocol INVITE requests
    Creation_date: 2008-02-07
    WG ID: Independent = Submission
    Number_of_pages: 18
    =

    Abstract:
    This = document normatively updates RFC 3261, the Session Initiation
    =
    Protocol (SIP), to address an error in the = specified handling of
    success = (200 class) responses to INVITE requests.=A0 Elements following
    =
    RFC 3261 exactly will misidentify = retransmissions of the request as a
    new, unassociated, request.=A0 = The correction involves modifying the
    INVITE transaction state machines.=A0 The correction also changes = the
    way responses that cannot be = matched to an existing transaction are
    handled to address a security risk.



    The IETF Secretariat.




    = --Apple-Mail-39-505909598-- --===============1169039098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1169039098==-- From sip-bounces@ietf.org Fri Feb 29 08:05:28 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D0728C1CF; Fri, 29 Feb 2008 08:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mte58wQ4pzox; Fri, 29 Feb 2008 08:05:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843C328C1D1; Fri, 29 Feb 2008 08:05:15 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D8A28C18E for ; Fri, 29 Feb 2008 08:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxF3PSpprLw7 for ; Fri, 29 Feb 2008 08:05:09 -0800 (PST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 2537328C26D for ; Fri, 29 Feb 2008 08:05:08 -0800 (PST) Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JV7jI-0001MO-45; Fri, 29 Feb 2008 11:05:00 -0500 Message-ID: <47C82C83.2090609@bbn.com> Date: Fri, 29 Feb 2008 11:02:11 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com><47C73D16.9080103@cisco.com><5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> <20080229141341.B954D5081A@romeo.rtfm.com> <5D1A7985295922448D5550C94DE2918001CB0782@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001CB0782@DEEXC1U01.de.lucent.com> Cc: Cullen Jennings , IETF SIP List , Dean Willis Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-03 was RE: Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree that sip-media-security-requirements needs to finished quickly, however, I hope that it does not require agenda time at IETF 71. With regards to Eric's comments about scope and on particular requirements: Personally, I don't see the appendices as an important part of this document, but if other working group members believe the appendices are valuable for historical archive, then I would not object to their inclusion (provided that the inclusion of the appendices does not hold up the rest of the document). R-ID-BINDING: Perhaps we could reword this as: "The media security key management protocol must enable the media security keys to be cryptographically bound to an identity of the endpoint." R-RECORDING and R-TRANSCODER: These requirements only call for a description (somewhere) of mechanisms to support (respectively) recording and transcoding. Personally, I think these are requirements. In particular, they could be satisfied by specifying that in environments where recording (or transcoding) is required, the endpoint must share its key with the recording (or transcoding) device. At some point in the future we can discuss whether there is a better approach for satisfying one (or both) of these requirements (and at such a point we can discuss whether there should be a recommended format for transferring a key to a recording device) but for the time being I think the requirements are reasonable and we can move on. - Matt Lepinski DRAGE, Keith (Keith) wrote: >Well one of the issues I thought needed agenda time was yours from >yesterday. > >--------------------------------------------------------------------- > >GENERAL COMMENTS >I'm concerned about the apparent lack of stability of this draft. >When this draft was originally published, it seemed to me to have two >purposes: > >- To capture the BOF consensus on the important security > properties for an RTPSEC protocol. >- To be a survey for the properties of > the various protocols compared to those requirements. > >The first purpose still seems useful to me, but is best served by having >a draft that reflects that consensus published ASAP. The second purpose >seems to me to have been sort of overtaken by events and I'm not sure >it's still valuable. > >With the first purpose firmly in mind, it seems a little problematic >that this draft has changed so much in the past 6-12 months. >In particular: > >- The -02 version totally renamed all the requirements >- I'm not convinced that all the requirements > introduced in -00 have WG consensus. > >Since there are other documents which need to reference these >requirements, this presents a problem for them. > >------------------------------------------------------------------- > >This seemed to be a concern about scope creep, and as it is the chairs >that have probably allowed that creep, it is probably difficult for them >to direct it back to where it ought to be. This is coupled with a >concern about whether all the requirements have consensus. This seemed >to be something that we would normally deal with in the WG session to >see if this comment was representative on the rest of the group and >trying to judge how to fix the problem. > >Note that we have absolutely no issue with resolving comments like this >on list - if we are able to. > >Other input is welcome to resolve this, and please identify any specific >requirements that you believe do not have consensus. > >Regards > >Keith > > > >>-----Original Message----- >>From: Eric Rescorla [mailto:ekr@networkresonance.com] >>Sent: Friday, February 29, 2008 2:14 PM >>To: DRAGE, Keith (Keith) >>Cc: Cullen Jennings; Dean Willis; IETF SIP List >>Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet >> >>At Fri, 29 Feb 2008 12:00:42 +0100, >>DRAGE, Keith (Keith) wrote: >> >> >>>Media security requirements is holding up other chartered items in >>>both SIP and AVT. When we considered this for inclusion, we >>> >>> >>believed >> >> >>>there were two items that may need agenda item. Overnight >>> >>> >>Dean seems >> >> >>>to have taken the time away at the moment, but I remain unconvinced >>>that this does not need time. >>> >>>This is the media-security requirements milestones: >>> >>>Sep 2007 Requirements for media keying to WGLC (Informational) >>>Nov 2007 Requirements for media keying to IESG (Informational) >>> >>>Which provides the requirements for the mechanism in these charter >>>items in SIP. >>> >>>Dec 2007 Establishment of secure media sessions using >>> >>> >>DTLS-SRTP to >> >> >>>WGLC (PS) >>>Feb 2008 Establishment of secure media sessions using >>> >>> >>DTLS-SRTP to >> >> >>>IESG (PS) >>> >>>And these chartered items in AVT: >>> >>>Dec 2007 Submit in band keying mechanism for SRTP draft >>> >>> >>for Proposed >> >> >>>Standard >>> >>> >>For what it's worth, being neither chair nor AD, I absolutely >>want media-security-requirements to finish and if there are >>significant comments on the document, I 100% endorse giving >>it agenda time. >> >>That said, based on my review and the lack of traffic on the >>list, my opinion is that there aren't any major issues[0], so >>we should declare victory and move on! >> >> >>Thanks, >>-Ekr >> >>[0] The only real issues I raised in my comment were: >> - Should we remove the survey from the appendix. I'm fine >> leaving it in, since I was mostly worried about it >> needing constant update. >> - Requirement R-RECORD. I think we could just take a >> straw poll on this one. >> >> >> >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 08:24:23 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFE03A6ACD; Fri, 29 Feb 2008 08:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thaAh15lxujT; Fri, 29 Feb 2008 08:24:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F42428C386; Fri, 29 Feb 2008 08:24:22 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7124E28C3F6 for ; Fri, 29 Feb 2008 08:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gh+E5P5o3-a for ; Fri, 29 Feb 2008 08:24:14 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 217E23A681E for ; Fri, 29 Feb 2008 08:24:14 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JX000C8VDK4F3@siemenscomms.co.uk> for sip@ietf.org; Fri, 29 Feb 2008 16:24:05 +0000 (GMT) Date: Fri, 29 Feb 2008 16:24:04 +0000 From: "Elwell, John" In-reply-to: <1225B736-0A77-4E62-A275-9244BD3F3B86@nostrum.com> To: Robert Sparks Message-id: <0D5F89FAC29E2C41B98A6A762007F5D070BFBC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01 Thread-Index: Ach66AGleUe5PUrFQ7K1PxlAe8JIOQAB2FqA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20080207212223.2EF3B3A6F42@core3.amsl.com> <0D5F89FAC29E2C41B98A6A762007F5D0602AEF@GBNTHT12009MSX.gb002.siemens.net> <1225B736-0A77-4E62-A275-9244BD3F3B86@nostrum.com> Cc: sip List Subject: Re: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0569564776==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0569564776== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C87AEF.7FA5742A" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C87AEF.7FA5742A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, =20 OK, I accept what you say. =20 John ________________________________ From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: 29 February 2008 15:28 To: Elwell, John Cc: sip List Subject: Re: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01 =09 =09 John - sorry for the slow reply - I wrote a reply the day you sent this, but as far as I can tell it got eaten before it made it to the list.=20 I didn't intend section 7 to be "just" a description - you inferred that from "this section describes"?. Yes, the document has the risk you describe. I don't think we can avoid that without giving up making a standalone section that's as clear as Jonathan wants or specifying exactly what changes in 3261. The only way to mitigate that risk is careful review, which I think is possible given that the scope of this fix (and all *fix documents) should be pretty small. I feel pretty strongly that _for this change_, specifying exactly what gets touched in 3261 is important or we'll end up with interoperability arguments. The language that got touched is argued through at each SIPit already - not making it as crystal clear as possible how it gets impacted will make that worse. Whether or not we need to do that for every *fix document, I don't feel quite as strongly about, but this one is an existence proof that we'll need it for some. RjS On Feb 8, 2008, at 1:31 AM, Elwell, John wrote: Robert, =20 So we have two sections containing RFC 2119 language and saying the same thing in different ways. If section 7 is just a description, as it claims, then should it not avoid RFC 2119 language. Otherwise, which section takes precedence in the event of a conflict? =20 John ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Robert Sparks Sent: 07 February 2008 21:35 To: sip List Subject: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01 =09 =09 Based on the feedback from the -00 draft, I've added a section that details the changes this draft makes=20 in a more descriptive form (in addition to the patching-the-text form that already exists). Please look at the new section 7 and see if this addresses the concerns around the document format. I also spent some time experimenting with the suggestions to provide the changes in a diff format and have not found anything promising. For the sake of discussion, I did prepare a patch file that I'll send in a separate message. I'm becoming more convinced that that's the wrong approach to take though. We really don't want to create some form of derived document that's the "current spec". If we really want a new document, lets create a bis and be done with it. The point of creating the patch-the-text form in the first place was not to facilitate creating a new document out of the old document. It was done so that the impact of the changes on the spec is expressed in as unambiguous a form as possible. The worst outcome would be an update that _didn't_ make these explicit statements and half of the implementors in the world end up looking=20 at a section and saying "Oh, I didn't know it meant to change _that_". RjS Begin forwarded message: From: IETF I-D Submission Tool Date: February 7, 2008 3:22:23 PM CST To: RjS@nostrum.com Subject: New Version Notification for draft-sparks-sip-invfix-01=20 A new version of I-D, draft-sparks-sip-invfix-01.txt has been successfuly submitted by Robert Sparks and posted to the IETF repository. Filename: draft-sparks-sip-invfix Revision: 01 Title: Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests Creation_date: 2008-02-07 WG ID: Independent Submission Number_of_pages: 18 Abstract: This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. The IETF Secretariat. ------_=_NextPart_001_01C87AEF.7FA5742A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Robert,
     
    OK, I accept what you say.
     
    John

    From: Robert Sparks=20 [mailto:rjsparks@nostrum.com]
    Sent: 29 February 2008=20 15:28
    To: Elwell, John
    Cc: sip = List
    Subject: Re:=20 [Sip] Fwd: New Version Notification for=20 draft-sparks-sip-invfix-01

    John - sorry for the slow reply - I wrote a reply the day = you sent=20 this, but as far as I can tell it got eaten before it made it to the = list.

    I didn't intend section 7 to be "just" a description - you = inferred that=20 from "this section describes"?.

    Yes, the document has the risk you describe. I don't think we can = avoid=20 that without giving up making a standalone section that's
    as clear as Jonathan wants or specifying exactly what changes in = 3261.=20 The only way to mitigate that risk is careful review, which
    I think is possible given that the scope of this fix (and all = *fix=20 documents) should be pretty small.

    I feel pretty strongly that _for this change_, specifying exactly = what=20 gets touched in 3261 is important or we'll end up with = interoperability
    arguments. The language that got touched is argued through at = each SIPit=20 already - not making it as crystal clear as possible how it gets
    impacted will make that worse. Whether or not we need to do that = for=20 every *fix document,  I don't feel quite as strongly about, but = this=20 one
    is an existence proof that we'll need it for some.

    RjS


    On Feb 8, 2008, at 1:31 AM, Elwell, John wrote:
    Robert,
     
    So we have two sections containing RFC 2119 = language=20 and saying the same thing in different ways. If section 7 is just a=20 description, as it claims, then should it not avoid RFC 2119 = language.=20 Otherwise, which section takes precedence in the event of a=20 conflict?
     
    John

    From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On=20 Behalf Of Robert Sparks
    Sent: 07 February 2008=20 21:35
    To: sip List
    Subject: [Sip] Fwd: New = Version=20 Notification for draft-sparks-sip-invfix-01

    Based on the feedback from the -00 draft, I've added a = section=20 that details the changes this draft makes=20
    in a more descriptive form (in addition to the = patching-the-text form=20 that already exists).

    Please look at the new section 7 and see if this addresses = the=20 concerns around the document format.

    I also spent some time experimenting with the suggestions to = provide=20 the changes in a diff format and have
    not found anything promising. For the sake of discussion, I = did=20 prepare a patch file that I'll send in a separate
    message. I'm becoming more convinced that that's the wrong = approach=20 to take though. We really don't want
    to create some form of derived document that's the "current = spec". If=20 we really want a new document, lets create
    a bis and be done with it.

    The point of creating the patch-the-text form in the first = place was=20 not to facilitate creating a new
    document out of the old document. It was done so that the = impact of=20 the changes on the spec is
    expressed in as unambiguous a form as possible. The worst = outcome=20 would be an update that
    _didn't_ make these explicit statements and half of the = implementors=20 in the world end up looking 
    at a section and saying "Oh, I didn't know it meant to = change=20 _that_".

    RjS

    Begin forwarded message:

    From: IETF = I-D Submission=20 Tool <idsubmission@ietf.org>
    Date: February 7, 2008=20 3:22:23 PM CST
    To: RjS@nostrum.com
    Subject: New = Version=20 Notification for draft-sparks-sip-invfix-01 


    A new version of I-D,=20 draft-sparks-sip-invfix-01.txt has been successfuly submitted by = Robert=20 Sparks and posted to the IETF repository.

    Filename: draft-sparks-sip-invfix
    Revision: 01
    Title: Correct transaction handling = for 200=20 responses to Session Initiation Protocol INVITE requests
    Creation_date: 2008-02-07
    WG ID: Independent Submission
    Number_of_pages: 18

    Abstract:
    This document normatively updates RFC = 3261, the=20 Session Initiation
    Protocol (SIP), to address an error = in the=20 specified handling of
    success (200 class) responses to = INVITE=20 requests.  = Elements=20 following
    RFC 3261 exactly will misidentify=20 retransmissions of the request as a
    new, unassociated, request.  The correction = involves=20 modifying the
    INVITE transaction state = machines.  The correction also = changes=20 the
    way responses that cannot be matched = to an=20 existing transaction are
    handled to address a security = risk.



    The IETF Secretariat.




    ------_=_NextPart_001_01C87AEF.7FA5742A-- --===============0569564776== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0569564776==-- From sip-bounces@ietf.org Fri Feb 29 10:01:06 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EFB828C599; Fri, 29 Feb 2008 10:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4kBw46JUSWo; Fri, 29 Feb 2008 10:01:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06A428C5A4; Fri, 29 Feb 2008 10:01:00 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B607428C599 for ; Fri, 29 Feb 2008 10:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha28HyYcr6uv for ; Fri, 29 Feb 2008 10:00:57 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id BCE4928C569 for ; Fri, 29 Feb 2008 10:00:57 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1TI0m0v000810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 29 Feb 2008 12:00:49 -0600 Message-Id: <5A14409B-690B-4DF2-9D6C-15FEC07CDA9C@softarmor.com> From: Dean Willis To: "sip@ietf.org List" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 29 Feb 2008 12:00:42 -0600 X-Mailer: Apple Mail (2.919.2) Subject: [Sip] External ref: "Wired" article for consideration in context of phone-identity discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I thought this was an interesting read and might raise our awareness of just what sort of situation we're facing when we design security mechanisms. http://www.wired.com/politics/law/news/2008/02/blind_hacker?currentPage=1 -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 10:15:18 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E613A6953; Fri, 29 Feb 2008 10:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy063cYQHmaT; Fri, 29 Feb 2008 10:15:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0529F28C544; Fri, 29 Feb 2008 10:15:13 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C033A6953 for ; Fri, 29 Feb 2008 10:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T90p9ui5PXA for ; Fri, 29 Feb 2008 10:15:06 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D8AB028C602 for ; Fri, 29 Feb 2008 10:15:05 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1TIEt1k005906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Feb 2008 12:14:57 -0600 Message-Id: <3CC70159-1B55-4AAC-9B1A-D465ED346ED4@softarmor.com> From: Dean Willis To: Eric Rescorla In-Reply-To: <20080229063214.9E2A35081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 29 Feb 2008 12:14:50 -0600 References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <47C7213A.5090000@cisco.com> <57ED2BE6-1A90-4D15-A7E0-8366082BD6BA@softarmor.com> <20080229063214.9E2A35081A@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, Michael Thomas Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 29, 2008, at 12:32 AM, Eric Rescorla wrote: > At Thu, 28 Feb 2008 22:54:17 -0600, > Dean Willis wrote: >>> >>> 2. Key discovery: Callers can generate the public key of the >>> callee >>> from the identity (SIP URI) of the callee and vice versa. This >>> eliminates a requirement for a key discovery mechanism using >>> external sources, making deployment significantly easier. >>> >>> Or you can ship the key or cert in the signaling too. >> >> yes, although those keys may be big (a problem for network resource >> constrained environments), AND you have to ship them before they can >> be used for encryption. For signing, I can send my cert along with a >> signed message. But if I'm going to encrypt the message to you, I >> need >> your public key BEFORE sending the message. >> >> Since the IB model generates public keys from SIP URIs, if I have >> enough info on you to send you the message, then I also have enough >> to >> encrypt it. > > Yes, this is a clear advantage of IBE over PKI-based systems. But > as I said, it doesn't apply to IBS. Moreover, if there's any > kind of retargeting, then IBE has real problems. > I see it as applying directly to IBS. Every message carries enough information (without the overhead of carrying a cert) for any recipient in the hierarchy to be able to validate a signature on that message. That's very useful in a P2P sort of world. For example, if you're a peer making an admitting decision, you can validate a signature on an admission request without having to "get" the cert for that user from the DHT. > > >>> 3. Certificate validation: As a result caller or callee need not >>> go >>> through the complex path construction process to retrieve the >>> public keys of a chain of CAs from the public key depositories >>> which are controlled by the respective CAs. This allows >>> deployment in a peer-to-per modality without a need to route >>> SIP >>> messages through a centralized identity service or trust peer >>> nodes to operate as identity services. >>> >>> What is the KG if not a centralized entity? I guess I don't >>> understand this part. >> >> It's a centralized entity, but OUTSIDE of the signaling path. >> Interaction with it is independent of interaction within the >> signaling >> plane. >> >> Consider, for example, a P2PSIP deployment that may initially >> bootstrap in a connected environment. Everybody talks to their PKGs >> and gets keyed up. Then a disaster occurs, people jump in their >> response vehicles, and rush off to the impact zone where they form an >> ad-hoc network. Their keys still work without further access to the >> PKG. >> >> Contrast this to RFC 4474 identity servers, where each SIP request >> has >> to go through a server, where a cryptographic process occurs. This is >> a very load-sensitive centralized device without which the system >> cannot function. > > But this is *by design* because the original system for public key > end-to-end authentication, S/MIME which *did* use end-user > certificates, was determined to be impractical, because--wait for > it--end-entity enrollment was such a PITA. A situation which is > *exactly* the same for IB* systems. But by examination, it's easy to solve for IB systems. You say the same solution can apply to cert-based systems. Why doesn't anyone do it that way? There must be more to it -- maybe just a cognitive gap, but there MUST be some underlying reason or reasons. Skype, for example, has the "feel" of an IB system as I describe it, even though it's really more conventional crypto underneath. But they don't pretend to be a CA. > > > >> Sure, we could do something similar by having the "initial bootstrap" >> include a CA process wherein everbody gets a cert. But now we need a >> way of distributing the certs, either by broadcast or some sort of >> query protocol. Why bother when an identity-based-encryption model >> makes it so much easier? > > Again, you're conflating encryption with data origin authentication. > Yes, this is an advantage of IBE, for encryption. It doesn't make it > any easier for signature however, as noted above. As noted above, it DOES. Anybody who has an identity within the hierarchy can validate signatures on messages without needing to fetch a cert. > > > > >>> 4. Revocation: The ease of minting new identities and discovering >>> keys allows short-lived identities, reducing the need for >>> certificate revocation lists and the checking thereof. This >>> offers very large operational advantages in resource >>> constrained >>> environments. >>> >>> I don't understand why this is "easy". Enrollment is >>> "hard" unless there's something really new here. And >>> if I wanted a short-lived identity, I could just gin >>> up a new public key pair and use that as the identity >>> too. But I thought that the real problem was dealing with >>> long term identities like, oh say, mat@cisco.com. >>> >> >> Secondary enrollment, or at least minting a new identity, is >> relatively easy, While the server load for crypto is comparable to >> that of generating a cert, the amount of data on the wire is much >> smaller. > > Uh, sure. You authenticate to the CA/KG and it sends you your new > credential. In the case of the PKI, you get a new certificate, which > is definitely less than 1KB, but since it's almost exactly the same as > the old cert, what you really need is the new signature, so we can > compress that down to 320-1024 bits, depending on the signature > algorithm. > > In the case of BB signatures, to take one instantiation, the private > key is 320 bits, so we're basically looking at a wash. Except, > of course, that you need to transmit the private key securely > whereas the certificate can be distributed over an insecure > protocol, so once you factor in the overhead of the SSL connection > (or S/MIME, or whatever) you use to distribute the private key, > things start to look a lot worse. Given that we have a two-layer model with permanent and temporary secrets, the permanent secret could be used to encrypt the temporary private key, making it work just like a protected cert. But wait, there's more. There is math available that makes the thing that comes back from the PKG a "partial" key that then has to be combined with the secret held by the user to be useful. As such, the partial key isn't secret -- it can be transmitted in plain text. > -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 10:25:09 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CFCB28C655; Fri, 29 Feb 2008 10:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL+A6mR-lVj3; Fri, 29 Feb 2008 10:25:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0AB3A6C8B; Fri, 29 Feb 2008 10:25:01 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEC53A6BE9 for ; Fri, 29 Feb 2008 10:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ggNpWXaqB7R for ; Fri, 29 Feb 2008 10:24:54 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id AC4183A6C8B for ; Fri, 29 Feb 2008 10:24:47 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m1TIMxFd028133; Fri, 29 Feb 2008 12:24:11 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 12:24:07 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 19:24:06 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 19:24:05 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001CB081D@DEEXC1U01.de.lucent.com> In-Reply-To: <5A561DF8-2237-4D1C-9B42-CB82C48A6C4A@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Essential Corrections - invfix (was Re: [Sip] Revised agenda for SIP -- needs more work yet) Thread-index: Ach65m7ypd8WSfBORSqHr40NILARcQAGWawg References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com><47C73D16.9080103@cisco.com> <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> <5A561DF8-2237-4D1C-9B42-CB82C48A6C4A@nostrum.com> From: "DRAGE, Keith \(Keith\)" To: "Robert Sparks" , "Jonathan Rosenberg" X-OriginalArrivalTime: 29 Feb 2008 18:24:06.0189 (UTC) FILETIME=[44A43DD0:01C87B00] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Cullen Jennings , IETF SIP List , Dean Willis Subject: Re: [Sip] Essential Corrections - invfix (was Re: Revised agenda for SIP -- needs more work yet) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The key issue to getting this (and a couple of others where we have agreed "essential") into WGLC and progressing is to work out the final format for presenting, as Robert indicates below. We have people saying they don't like what we have had previously, but I don't see them addressing the issue now. In future maybe we ignore people who rant at the mic and then don't address the issue on the list. Keith > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Friday, February 29, 2008 3:18 PM > To: DRAGE, Keith (Keith); Jonathan Rosenberg > Cc: Cullen Jennings; Dean Willis; IETF SIP List > Subject: Essential Corrections - invfix (was Re: [Sip] > Revised agenda for SIP -- needs more work yet) > > Folks - > > Lets try to get the Essential Corrections and -invfix- > discussion off the agenda since there are clearly gnarlier > things to talk about. > > I sent in a revision to inv-fix attempting to address > Jonathan's concern about stand-alone readability. > Jonathan - is the new format better? Can we go with this? > > I sent a separate message showing what it would look like to > build a diff against 3261 that we could put in the document. > You'll remember that on looking at it, its my opinion that > going down that path is a very bad idea. > > So far, there's only been one response on list to those messages. > > Please, everyone (especially those that have expressed strong > opinions in the past), look those over and let us know if > we're past the primary concerns, or if we still have > something to work through that needs face time to do so. > > RjS > > On Feb 29, 2008, at 5:00 AM, DRAGE, Keith ((Keith)) wrote: > > > (As SIP WG cochair) > > > > As Dean already said, we spend 3 hours last night trying to plan a > > 2 1/2 > > hour session based on input we do not completely have. We don't > > think we > > finished, but this was the best we could reach so far in the time > > available. Things can move up, but they don't solve the fundamental > > problem that we don't have enough time. It was not our idea to > > limit SIP > > to a single session - this was forced on us by the ADs. > > > > Modification of this agenda is more likely to occur not by > complaining > > about the time allocated, but by the presence of technical > > discussion on > > list over the next 8 days. > > > > Some generals: > > > > We have taken the principle that if discussion time is needed on > > chartered items specifically, then they come first, and more > > specifically highest priority for any discussion needed to get > > something > > out of WGLC and into publication request. This is then followed by > > documents that we envisaged could hold up chartered items > (in this and > > other groups) if not discussed. Then follow the other items > where time > > has been requested. > > > > Some specifics based on comments received so far: > > > > Domain-certs and eku are in WGLC which ends of Friday next > week. These > > are a dependency from other chartered items where we are ready to > > submit > > the publication request. We will not have a view of what > specifically > > needs discussion on these in the meeting until the end of > the WGLC, > > when > > all the comments are in. Many of the comments made will not need > > discussion in the SIP session and can be discussed on list by the > > editors after the end of last call. If any comment does need SIP WG > > session time, then we will give it on the above basis. > > > > Outbound is in WGLC and has no time. We are still waiting > for input to > > know if it needs time - not helped by the authors dropping > yet another > > new version in the inbox 3 minutes before the -xx deadline when it > > should have been there a month ago. Our current view is to issue a > > refreshed WGLC on this following the meeting but that can change. > > > > Location conveyance is in WGLC and has no time. Again > author drops new > > version in inbox 3 minutes before -xx document deadline. > This document > > is impacted by: > > > > http://www.ietf.org/internet-drafts/draft-peterson-geopriv- > > retransmissio > > n-00.txt > > > > Which will be discussed in the GEOPRIV group, but if > followed reverses > > the decision we made in the location-conveyance breakout at the last > > meeting. We hope the GEOPRIV discussion does not force > rediscussion in > > SIP, but please bear in mind that it could do so. > > > > RPH in responses is not chartered. 2 meetings back the WG > expressed a > > wish to work on this. The AD pushed back to our request to > charter. As > > the AD makes the decision, it is not chartered and has no > milestones. > > That's why we had the further discussion in the last meeting - where > > again we came to no conclusions, and I assume the AD is still > > unconvinced. Fundamental problem - convince the AD. Put him in a > > corner > > somewhere in Philadelphia and kick hell out of him, but we > don't need > > the SIP session to watch you do that - although it may be > > entertaining! > > > > Media security requirements is holding up other chartered items in > > both > > SIP and AVT. When we considered this for inclusion, we > believed there > > were two items that may need agenda item. Overnight Dean > seems to have > > taken the time away at the moment, but I remain unconvinced > that this > > does not need time. > > > > This is the media-security requirements milestones: > > > > Sep 2007 Requirements for media keying to WGLC (Informational) > > Nov 2007 Requirements for media keying to IESG (Informational) > > > > Which provides the requirements for the mechanism in these charter > > items > > in SIP. > > > > Dec 2007 Establishment of secure media sessions using > DTLS-SRTP to > > WGLC (PS) > > Feb 2008 Establishment of secure media sessions using > DTLS-SRTP to > > IESG (PS) > > > > And these chartered items in AVT: > > > > Dec 2007 Submit in band keying mechanism for SRTP draft for > > Proposed > > Standard > > > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >> Behalf Of Cullen Jennings > >> Sent: Friday, February 29, 2008 5:33 AM > >> To: Dean Willis > >> Cc: IETF SIP List > >> Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet > >> > >> > >> On Feb 28, 2008, at 8:57 PM, Dean Willis wrote: > >> > >>> > >>> On Feb 28, 2008, at 5:00 PM, Jonathan Rosenberg wrote: > >>> > >>>> 10 minutes on the phone number dichotomy thing isn't going to be > >>>> even close enough to cut it. It should be either zero or a more > >>>> significant number. > >>>> > >>>> We have 30 minutes on media security. The only chartered > >> item there > >>>> is the requiremetns document which I thought was mostly > >> done. Why is > >>>> there so much time dedicated to this? I would rather move that to > >>>> INFO or the identity mess. > >>> > >>> Me too. But hey, the media security requirements document is > >>> CHARTERED. We have permission to work on it and a commitment to a > >>> deliverable, with a published milestone. We don't have that > >> for INFO > >>> or the identity mess (even though I think media security is > >> blocked on > >>> the identity mess -- our AD currently disagrees). > >>> > >> > >> Dean - I think we must be having some serious > >> miscommunications - many times in the past I have had enough > >> typos in my emails that no one could understand what I might > >> have been thinking but .... > >> > >> I don't think I said that. The two things I thought I said > >> that might have been confused are: > >> > >> 1) I don't think the E.164 discussion is holding up milestone > >> items in MEDIACTRL or SIMPLE > >> > >> 2) I don't think a problem in some mechanism such as 4474 > >> should be holding up the media security requirements draft. > >> (If I could bold requirements in the previous sentences I would) > >> > >> I certainly do think it is important that we have a clear > >> understanding of how E.164 numbers fit into the overall SIP > >> security picture. Sorry if I said something that made you > >> think otherwise. > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 10:25:16 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6C63A6C8B; Fri, 29 Feb 2008 10:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFP0-GZve23D; Fri, 29 Feb 2008 10:25:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CEE3A6F10; Fri, 29 Feb 2008 10:25:08 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1BF3A6871 for ; Fri, 29 Feb 2008 10:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT+c7JalNIQU for ; Fri, 29 Feb 2008 10:25:02 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 5E10D3A6D78 for ; Fri, 29 Feb 2008 10:25:01 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 0F0935081A; Fri, 29 Feb 2008 10:26:46 -0800 (PST) Date: Fri, 29 Feb 2008 10:26:45 -0800 From: Eric Rescorla To: Dean Willis In-Reply-To: <3CC70159-1B55-4AAC-9B1A-D465ED346ED4@softarmor.com> References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <47C7213A.5090000@cisco.com> <57ED2BE6-1A90-4D15-A7E0-8366082BD6BA@softarmor.com> <20080229063214.9E2A35081A@romeo.rtfm.com> <3CC70159-1B55-4AAC-9B1A-D465ED346ED4@softarmor.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080229182646.0F0935081A@romeo.rtfm.com> Cc: sip@ietf.org, Michael Thomas Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Fri, 29 Feb 2008 12:14:50 -0600, Dean Willis wrote: > On Feb 29, 2008, at 12:32 AM, Eric Rescorla wrote: > > Yes, this is a clear advantage of IBE over PKI-based systems. But > > as I said, it doesn't apply to IBS. Moreover, if there's any > > kind of retargeting, then IBE has real problems. > > > > I see it as applying directly to IBS. Every message carries enough > information (without the overhead of carrying a cert) for any > recipient in the hierarchy to be able to validate a signature on that > message. That's very useful in a P2P sort of world. We're going around in circles. The only overhead here of carrying the cert is the certificate data itself. In other words, this is a fancy form of certificate compression, just as I said at the beginning. I've deleted the rest of your message since it primarily goes over the same ground. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 10:30:39 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166253A6D98; Fri, 29 Feb 2008 10:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvpdVdfG09rA; Fri, 29 Feb 2008 10:30:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBFD3A6D7A; Fri, 29 Feb 2008 10:30:31 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADC83A6C8B for ; Fri, 29 Feb 2008 10:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGM6KNOmMqpf for ; Fri, 29 Feb 2008 10:30:25 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6216D28C473 for ; Fri, 29 Feb 2008 10:30:24 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1TITm1u010005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Feb 2008 12:29:49 -0600 Message-Id: <6460E318-B449-4415-9E0B-EF0F76AA5C04@softarmor.com> From: Dean Willis To: "DRAGE, Keith (Keith)" In-Reply-To: <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 29 Feb 2008 12:29:42 -0600 References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com><47C73D16.9080103@cisco.com> <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> X-Mailer: Apple Mail (2.919.2) Cc: Cullen Jennings , IETF SIP List Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 29, 2008, at 5:00 AM, DRAGE, Keith (Keith) wrote: > > Media security requirements is holding up other chartered items in > both > SIP and AVT. When we considered this for inclusion, we believed there > were two items that may need agenda item. Overnight Dean seems to have > taken the time away at the moment, but I remain unconvinced that this > does not need time. > > This is the media-security requirements milestones: > > Sep 2007 Requirements for media keying to WGLC (Informational) > Nov 2007 Requirements for media keying to IESG (Informational) > > Which provides the requirements for the mechanism in these charter > items > in SIP. > > Dec 2007 Establishment of secure media sessions using DTLS-SRTP to > WGLC (PS) > Feb 2008 Establishment of secure media sessions using DTLS-SRTP to > IESG (PS) > > And these chartered items in AVT: > > Dec 2007 Submit in band keying mechanism for SRTP draft for > Proposed > Standard It still has 30 minutes on the draft agenda, if I'm reading it correctly. It's the framework draft (draft-ietf-sip-dtls-srtp-framework-01) that currently doesn't have agenda time. The framework depends on the requirements, right? -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 10:30:52 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C4328C761; Fri, 29 Feb 2008 10:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7c44Wj1R+KX; Fri, 29 Feb 2008 10:30:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE1B28C6AE; Fri, 29 Feb 2008 10:30:44 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4BA28C6AE for ; Fri, 29 Feb 2008 10:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL6KMu4pA1ly for ; Fri, 29 Feb 2008 10:30:42 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 93E6B28C636 for ; Fri, 29 Feb 2008 10:30:40 -0800 (PST) Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1TITm1v010005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Feb 2008 12:30:30 -0600 Message-Id: <01B5F785-99EE-4407-9968-A4B974AE2C1F@softarmor.com> From: Dean Willis To: Robert Sparks In-Reply-To: <5A561DF8-2237-4D1C-9B42-CB82C48A6C4A@nostrum.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 29 Feb 2008 12:30:30 -0600 References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com><47C73D16.9080103@cisco.com> <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> <5A561DF8-2237-4D1C-9B42-CB82C48A6C4A@nostrum.com> X-Mailer: Apple Mail (2.919.2) Cc: Cullen Jennings , IETF SIP List , Keith Drage Subject: Re: [Sip] Essential Corrections - invfix (was Re: Revised agenda for SIP -- needs more work yet) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 29, 2008, at 9:17 AM, Robert Sparks wrote: > Folks - > > Lets try to get the Essential Corrections and -invfix- discussion > off the agenda since there are clearly gnarlier things to talk about. > I have removed its time allocation from the draft agenda. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 10:50:01 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB0E3A6F67; Fri, 29 Feb 2008 10:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agdUatKb-1RU; Fri, 29 Feb 2008 10:49:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00A93A6E2A; Fri, 29 Feb 2008 10:49:55 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DDD3A6E2A for ; Fri, 29 Feb 2008 10:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TXvWGcPxG0w for ; Fri, 29 Feb 2008 10:49:49 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 624E83A6D71 for ; Fri, 29 Feb 2008 10:49:49 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 3621550850; Fri, 29 Feb 2008 10:51:34 -0800 (PST) Date: Fri, 29 Feb 2008 10:51:34 -0800 From: Eric Rescorla To: Dean Willis In-Reply-To: <6460E318-B449-4415-9E0B-EF0F76AA5C04@softarmor.com> References: <54811460-0364-4794-8E4F-1EE47CC94B64@softarmor.com> <47C73D16.9080103@cisco.com> <5D1A7985295922448D5550C94DE2918001CB067E@DEEXC1U01.de.lucent.com> <6460E318-B449-4415-9E0B-EF0F76AA5C04@softarmor.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080229185134.3621550850@romeo.rtfm.com> Cc: Cullen Jennings , IETF SIP List , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Fri, 29 Feb 2008 12:29:42 -0600, Dean Willis wrote: > > > On Feb 29, 2008, at 5:00 AM, DRAGE, Keith (Keith) wrote: > > > > Media security requirements is holding up other chartered items in > > both > > SIP and AVT. When we considered this for inclusion, we believed there > > were two items that may need agenda item. Overnight Dean seems to have > > taken the time away at the moment, but I remain unconvinced that this > > does not need time. > > > > This is the media-security requirements milestones: > > > > Sep 2007 Requirements for media keying to WGLC (Informational) > > Nov 2007 Requirements for media keying to IESG (Informational) > > > > Which provides the requirements for the mechanism in these charter > > items > > in SIP. > > > > Dec 2007 Establishment of secure media sessions using DTLS-SRTP to > > WGLC (PS) > > Feb 2008 Establishment of secure media sessions using DTLS-SRTP to > > IESG (PS) > > > > And these chartered items in AVT: > > > > Dec 2007 Submit in band keying mechanism for SRTP draft for > > Proposed > > Standard > > It still has 30 minutes on the draft agenda, if I'm reading it > correctly. > > It's the framework draft (draft-ietf-sip-dtls-srtp-framework-01) that > currently doesn't have agenda time. The framework depends on the > requirements, right? Well, sort of. To the extent to which we're discussing new requirements that might require modifying the technical content of the framework, yes. I'm not aware of any such requirements. To the extent to which we're discussing editorial changes that affect the "requirements analysis" at the end of the framework document (e.g., changing the name of requirements but not their content) then there's an editorial dependency, but I'm fine with having that analysis be against a given version of the requirements document. To the extent to which we're just wordsmithing the requirements document (for instance, discussing whether to remove the appendix), then no. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 13:06:10 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7733A28C80F; Fri, 29 Feb 2008 13:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MlR+FUe3FqA; Fri, 29 Feb 2008 13:06:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C96028C6AF; Fri, 29 Feb 2008 13:06:04 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410A93A697A for ; Fri, 29 Feb 2008 13:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih2rriVSUlEx for ; Fri, 29 Feb 2008 13:05:57 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C880428C605 for ; Fri, 29 Feb 2008 13:05:56 -0800 (PST) Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JVCQO-0007C5-5J; Fri, 29 Feb 2008 16:05:48 -0500 Message-ID: <47C87303.9090300@bbn.com> Date: Fri, 29 Feb 2008 16:02:59 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" References: <41E96F53-A2D1-41EE-93A4-2E61099BDF1D@softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D070BCDD@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D070BCDD@GBNTHT12009MSX.gb002.siemens.net> Cc: sip@ietf.org, Dean Willis Subject: Re: [Sip] Sanity check -- relationship between DTLS-SRTP and Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree with John that there are two identity-related issues related to DTLS-SRTP framework. For each of the two problems (the E.164 problem and the SBC problem), the working group needs to decide whether it's better to complete DTLS-SRTP framework quickly and add appropriate text regarding the lack of applicability in certain deployment scenarios; or whether it's better to delay DTLS-SRTP framework while we work on solving the problem. Personally, I think that the E.164 problem is going to be hard to solve, and that it should not hold up DTLS-SRTP framework. (That is, that we should release a DTLS-SRTP framework that only works with "email-style" SIP URIs.) That being said, E.164 numbers aren't going away any time soon and so I think RAI should definitely perform work on how to obtain useful (as least PSTN-grade) identity guarantees for SIP requests with an E.164 number in the From: field. On the other hand, perhaps the SBC problem is one that we should resolve before advancing DTLS-SRTP framework. In particular, there are at least two proposals on the table (I.D-wing-identity-media and I.D-fischer-sip-e2e-sec-media) that say "use something other than RFC4474 for DTLS-SRTP framework". However, the concern that I have in solving this problem is that, in the absence of guidelines for how a 'well-behaving' SBC will handle particular headers or SDP bodies, it's hard to design a protocol that will interoperate well with SBCs. Note: Obviously, this concern is not DTLS-SRTP-Framework specific and given that SBC-issues keep coming up in a variety of working groups, perhaps RAI needs to reach consensus that either: A) We will not address SBC-related concerns when engineering protocols (e.g. we advance DTLS-SRTP without solving the SBC problem). B) We will seek to design protocols that interoperate with "most" existing SBCs at the time the protocol specification is written. C) We will seek to design protocols that interoperate with "well-behaving" SBCs (i.e. SBCs that adhere to the following set of guidelines). D) ????? (A) is ignoring the reality that SBCs aren't going away. (B) is difficult in practice because SBC behavior is not always well-documented and seems to change over time. (C) requires significant work writing appropriate guidelines that takes cycles away from (more important) RAI work. Perhaps someone can suggest a good (D)? - Matt Lepinski Elwell, John wrote: >Dean, > >The DTLS-SRTP framework is clear that you depend on RFC 4474 to bind the >secure media stream to an identity. There are two issues with RFC 4474 >that have received considerable discussion and have led to a long list >of I-Ds: >- The E.164 problem - not a problem if we use DTLS-SRTP only with >email-style SIP URIs, but some people would argue that this is not >feasible. >- The SBC problem. >Both of these are real world problems that aren't going to disappear >overnight as soon as networks deploy DTLS-SRTP. Rather, DTLS-SRTP will >not be deployed because it won't work on existing infrastructure. I do >want to see DTLS-SRTP completed, but not in a way that is of no use to >much of the market. > >John > > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Dean Willis >>Sent: 29 February 2008 05:36 >>To: sip@ietf.org List >>Subject: [Sip] Sanity check -- relationship between DTLS-SRTP >>and Identity >> >> >>Ok, maybe I'm reading something wrong here. >> >> From the list conversation, it seems like some people think >>there's a >>relationship between DTLS-SRTP and SIP Identity, aka RFC 4474. >> >>Other people think that there's a problem applying RFC 4474 when we >>use phone numbers. >> >>Some people think we use phone numbers a LOT, maybe almost all the >>time, and that therefore we really need to figure out how >>this impacts >>RFC 4474 and our other concepts of identity. >> >>This makes it seem to me like maybe we need to get the >>identity stuff >>nailed down before we commit to a final version of DTLS-SRTP. >>Or maybe >>the other way around -- we nail down DTLS -SRTP, then figure >>out what >>we need from Identity to support it, then fix Identity. Or maybe we >>need to fix them both together. >> >>Now our AD is telling me that by reading it this way, I'm >>unprofessionally evidencing bias in favor of some other >>protocol that >>may have been discussed prior to DTLS-SRTP (and the name of which I >>honestly can't remember right now). I find this unlikely, >>given that I >>don't actually understand any of the protocols and only >>parrot what I >>read on the mailing list earlier today. >> >>So let's put it to the working group. Is there a relationship >>between >>DTLS-SRTP, phone numbers, and identity that needs to be figured out? >>If so, how much of a problem is this? Do we care? >> >>-- >>Dean >> >>_______________________________________________ >>Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> >> >> >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 14:03:35 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ABC928C865; Fri, 29 Feb 2008 14:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n35FGxXCjttP; Fri, 29 Feb 2008 14:03:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D4F28C848; Fri, 29 Feb 2008 14:03:34 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4D13A697A for ; Fri, 29 Feb 2008 14:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EdrWaRhFdMU for ; Fri, 29 Feb 2008 14:03:27 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AE3F93A6DBD for ; Fri, 29 Feb 2008 14:02:57 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 Feb 2008 14:02:50 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1TM2o3i008438 for ; Fri, 29 Feb 2008 14:02:50 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id m1TM2ncD024195 for ; Fri, 29 Feb 2008 22:02:50 GMT Message-Id: From: Cullen Jennings To: IETF SIP List In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 29 Feb 2008 14:02:39 -0800 References: <77EA4502-7DE1-40F8-9051-8D7F965FEE56@softarmor.com> <47C480FB.8070608@gmx.net> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1186; t=1204322570; x=1205186570; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Draft=20SIP=20agenda=20for=20IE TF=2071 |Sender:=20; bh=RGeHYoDTB+JzTTrOnM0Cggwb6a0nm9Mt/H2Q8o1B7wA=; b=fVjvttgYHX4fshT/Bp+OnC4ADvT5Nq7wkRiUbce429J+Ek8zdRjUpA5el5 biJtNy89F3C++xd2+jF6PzOOxu6xjgR2l1JRNrfOw4gYBAQ399++22H0ZAu7 j66Czkzg6i; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] Draft SIP agenda for IETF 71 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm pushing back on finding a time to do this. Of course, I would want it to be productive use of time but I think Dean and Keith can figure out a way to accomplish that. Cullen with my AD hat on. On Feb 26, 2008, at 9:42 PM, Dean Willis wrote: > > On Feb 26, 2008, at 3:13 PM, Hannes Tschofenig wrote: > >> How are you going to cover all the identity related documents? I see >> only a few documents on the agenda > > Badly, most probably. I've suggested a breakout on e.164 identity to > AD Cullen, and he is pushing back on the idea, as it has the potential > to be full of sound and fury but signify nothing. It's not chartered, > and it might not be productive to just get into a bunch of shouting > matches. > > Perhaps you folks have some suggestions on how these things could be > covered effectively in a meeting? > > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 14:39:08 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D6728C7D8; Fri, 29 Feb 2008 14:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTqKLGXJk7ci; Fri, 29 Feb 2008 14:39:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64793A6F17; Fri, 29 Feb 2008 14:39:06 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6580C3A6E74 for ; Fri, 29 Feb 2008 14:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQsKwh1PBDAz for ; Fri, 29 Feb 2008 14:39:04 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 862EA3A6D0D for ; Fri, 29 Feb 2008 14:39:04 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 25so4367314wfa.31 for ; Fri, 29 Feb 2008 14:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=59w7tyGxAp1pRp5q49i8tGxp6jcuRSqIbYFfdpw8kiA=; b=l90giqObg4/bVMrWtaBX8LOkkRYIilKHxcbAxC3Vjmv2P8MS/pgpNoZMhhoorDqf13au41utEda8uHAc38cOfRMGiRKjxVFalRN7cxyzNLy1GUzW1ilxLV/xWW5n2PPLh/cw2PVR7HT08Hqk8vS90EYtOs4VSF0kHcmhb76tyI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=DbJcKRSnBjVzaPWHo3ZefYYNIuLEW/M6IjY3v1/5t7qABLb8r8GKdMJ8WJ3O0XkSJZo4cm9f7ZG5f+F/ShDQ3AkS4Gwswiz3qKr5+/9AzNBkrIMgOHhx11GBhvYP4u5rmaruFUW/toK6fk0wD48CdSbsKkoB8KRO4cQbLHQa0Mw= Received: by 10.142.215.5 with SMTP id n5mr7372368wfg.11.1204324736773; Fri, 29 Feb 2008 14:38:56 -0800 (PST) Received: by 10.142.156.14 with HTTP; Fri, 29 Feb 2008 14:38:56 -0800 (PST) Message-ID: <953beacc0802291438x7f06c4bcod0d33963bfcf54a9@mail.gmail.com> Date: Fri, 29 Feb 2008 14:38:56 -0800 From: "Rohan Mahy" To: SIP MIME-Version: 1.0 Cc: Cullen Jennings , Francois Audet Subject: [Sip] substantive changes to outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0855709167==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0855709167== Content-Type: multipart/alternative; boundary="----=_Part_8647_17398208.1204324736761" ------=_Part_8647_17398208.1204324736761 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Folks, As many of you probably saw, I submitted a new version of the outbound specification just before the draft deadline on Monday. There was a lot of general rewording to try to improve clarity and readability, but we received a number of contradictory suggestions, so hopefully it flow well. The major changes are: - removed references to the 'keep' and 'timed-keepalives' parameters - added the 'Flow-Timer' header - changed the wording for the recommended timing over TCP. if battery consumption is an issue, the recommended keepalives are approximately every 14 minutes. If battery consumption is not an issue, the recommended keepalives are approximately every two minutes. - added text explaining that an edge proxy which sees an 'ob' parameter in its Route header (probably copied form the Path vector by the authoritative proxy) in a dialog-forming request, the edge proxy needs to insure that the route set will allow in-dialog requests to arrive over some valid flow to the UA instance. In the simplest cae, the edge proxy could just copy the URI (with flow token) from the Route header into the Record-Route header and delete the 'ob' parameter. If the Contact is a GRUU that should be sufficient too. If the edge proxy wants to do something fancy that even without GRUU allows mid-dialog recovery of a specific flow, that's allowed as well. - added the 439 (First Hop Lacks Outbound Support) response code - wrote a very complete example (which is hopefully correct) I hope this is satisfactory to the group. The way timers work is much simpler and more powerful and will hopefully please both server and client folks (wired and wireless alike). In addition, there was a comment on the list about using outbound with transaction stateless proxies. As it turns out, it is impossible to implement an RFC3261-compliant proxy that always operates statelessly. Implementation of TCP (and TLS over TCP) is required in RFC 3261 and when sending or receiving over TCP a proxy MUST become stateful. Based on this, I do not feel badly stating that proxies which implement outbound MUST be transaction stateful. thanks, -rohan ------=_Part_8647_17398208.1204324736761 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Folks,

    As many of you probably saw, I submitted a new version of the outbound specification just before the draft deadline on Monday. There was a lot of general rewording to try to improve clarity and readability, but we received a number of contradictory suggestions, so hopefully it flow well.  The major changes are:

    - removed references to the 'keep' and 'timed-keepalives' parameters
    - added the 'Flow-Timer' header
    - changed the wording for the recommended timing over TCP. if battery consumption is an issue, the recommended keepalives are approximately every 14 minutes.  If battery consumption is not an issue, the recommended keepalives are approximately every two minutes.
    - added text explaining that an edge proxy which sees an 'ob' parameter in its Route header (probably copied form the Path vector by the authoritative proxy) in a dialog-forming request, the edge proxy needs to insure that the route set will allow in-dialog requests to arrive over some valid flow to the UA instance. In the simplest cae, the edge proxy could just copy the URI (with flow token) from the Route header into the Record-Route header and delete the 'ob' parameter. If the Contact is a GRUU that should be sufficient too.  If the edge proxy wants to do something fancy that even without GRUU allows mid-dialog recovery of a specific flow, that's allowed as well.
    - added the 439 (First Hop Lacks Outbound Support) response code
    - wrote a very complete example (which is hopefully correct)

    I hope this is satisfactory to the group. The way timers work is much simpler and more powerful and will hopefully please both server and client folks (wired and wireless alike).

    In addition, there was a comment on the list about using outbound with transaction stateless proxies.  As it turns out, it is impossible to implement an RFC3261-compliant proxy that always operates statelessly. Implementation of TCP (and TLS over TCP) is required in RFC 3261 and when sending or receiving over TCP a proxy MUST become stateful. Based on this, I do not feel badly stating that proxies which implement outbound MUST be transaction stateful.

    thanks,
    -rohan

    ------=_Part_8647_17398208.1204324736761-- --===============0855709167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0855709167==-- From sip-bounces@ietf.org Fri Feb 29 14:43:31 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2FF3A6F8A; Fri, 29 Feb 2008 14:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8i5S4ww25SS; Fri, 29 Feb 2008 14:43:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCFE3A6F4A; Fri, 29 Feb 2008 14:43:24 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D4B3A6F53 for ; Fri, 29 Feb 2008 14:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJJ+RyNu2-Eo for ; Fri, 29 Feb 2008 14:43:21 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id DFADE3A6F3D for ; Fri, 29 Feb 2008 14:43:21 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Feb 2008 14:43:14 -0800 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 m1TMhEVA005584; Fri, 29 Feb 2008 14:43:14 -0800 Received: from dwingwxp01 (dhcp-128-107-163-88.cisco.com [128.107.163.88]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m1TMh9LH026499; Fri, 29 Feb 2008 22:43:14 GMT From: "Dan Wing" To: "'Matt Lepinski'" , "'Elwell, John'" References: <41E96F53-A2D1-41EE-93A4-2E61099BDF1D@softarmor.com><0D5F89FAC29E2C41B98A6A762007F5D070BCDD@GBNTHT12009MSX.gb002.siemens.net> <47C87303.9090300@bbn.com> Date: Fri, 29 Feb 2008 14:43:09 -0800 Message-ID: <7c0101c87b24$780f0af0$5c4f150a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47C87303.9090300@bbn.com> Thread-Index: Ach7FvA7rUR4mQKmT7OkDgTybdj+MQADP05w DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7099; t=1204324994; x=1205188994; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Sanity=20check=20--=20relations hip=20between=20DTLS-SRTPand=09Identity |Sender:=20; bh=sK1/oJay8vwEXOjhTO1FkKBnqId4UWPdKz3aTxGt5V4=; b=ruvgseWw23tbN9dGIhiFFHR+xvsJsoK4DFzBNiHS6nXC3XVPHlH4CkDv8n n1ObT8DWyToUjPp20JNPlb2FUI3t4LhKRu8NVZbSDF3wJH+ErSg9XoG4mxnN tGkHrRCcOS; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, 'Dean Willis' Subject: Re: [Sip] Sanity check -- relationship between DTLS-SRTPand Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Matt Lepinski > Sent: Friday, February 29, 2008 1:03 PM > To: Elwell, John > Cc: sip@ietf.org; Dean Willis > Subject: Re: [Sip] Sanity check -- relationship between > DTLS-SRTPand Identity > > I agree with John that there are two identity-related issues > related to > DTLS-SRTP framework. > > For each of the two problems (the E.164 problem and the SBC problem), > the working group needs to decide whether it's better to complete > DTLS-SRTP framework quickly and add appropriate text > regarding the lack > of applicability in certain deployment scenarios; or whether > it's better > to delay DTLS-SRTP framework while we work on solving the problem. > > Personally, I think that the E.164 problem is going to be > hard to solve, > and that it should not hold up DTLS-SRTP framework. (That is, that we > should release a DTLS-SRTP framework that only works with > "email-style" > SIP URIs.) That being said, E.164 numbers aren't going away any time > soon and so I think RAI should definitely perform work on how > to obtain > useful (as least PSTN-grade) identity guarantees for SIP > requests with > an E.164 number in the From: field. We can do PSTN-grade identity assertions of E.164's today already: just trust your pre-configured SIP trunk to not lie. You set up SIP trunks to organizations with a contractual or gentleman's agreement to not lie. You don't even need RFC4474 to do that. That is exactly as good as the PSTN's identity. > On the other hand, perhaps the SBC problem is one that we > should resolve > before advancing DTLS-SRTP framework. In particular, there > are at least > two proposals on the table (I.D-wing-identity-media and > I.D-fischer-sip-e2e-sec-media) that say "use something other than > RFC4474 for DTLS-SRTP framework". However, the concern that I have in > solving this problem is that, in the absence of guidelines for how a > 'well-behaving' SBC will handle particular headers or SDP > bodies, it's > hard to design a protocol that will interoperate well with SBCs. > > Note: Obviously, this concern is not DTLS-SRTP-Framework specific and > given that SBC-issues keep coming up in a variety of working groups, > perhaps RAI needs to reach consensus that either: > A) We will not address SBC-related concerns when engineering > protocols > (e.g. we advance DTLS-SRTP without solving the SBC problem). > B) We will seek to design protocols that interoperate with "most" > existing SBCs at the time the protocol specification is written. > C) We will seek to design protocols that interoperate with > "well-behaving" SBCs (i.e. SBCs that adhere to the following set of > guidelines). > D) ????? This is all feeling very much like the history of the IETF's involvement with NATs and the IETF's involvement with firewalls. -d > (A) is ignoring the reality that SBCs aren't going away. (B) is > difficult in practice because SBC behavior is not always > well-documented > and seems to change over time. (C) requires significant work writing > appropriate guidelines that takes cycles away from (more > important) RAI > work. Perhaps someone can suggest a good (D)? > > - Matt Lepinski > > Elwell, John wrote: > > >Dean, > > > >The DTLS-SRTP framework is clear that you depend on RFC 4474 > to bind the > >secure media stream to an identity. There are two issues > with RFC 4474 > >that have received considerable discussion and have led to a > long list > >of I-Ds: > >- The E.164 problem - not a problem if we use DTLS-SRTP only with > >email-style SIP URIs, but some people would argue that this is not > >feasible. > >- The SBC problem. > >Both of these are real world problems that aren't going to disappear > >overnight as soon as networks deploy DTLS-SRTP. Rather, > DTLS-SRTP will > >not be deployed because it won't work on existing > infrastructure. I do > >want to see DTLS-SRTP completed, but not in a way that is of > no use to > >much of the market. > > > >John > > > > > > > >>-----Original Message----- > >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >>Behalf Of Dean Willis > >>Sent: 29 February 2008 05:36 > >>To: sip@ietf.org List > >>Subject: [Sip] Sanity check -- relationship between DTLS-SRTP > >>and Identity > >> > >> > >>Ok, maybe I'm reading something wrong here. > >> > >> From the list conversation, it seems like some people think > >>there's a > >>relationship between DTLS-SRTP and SIP Identity, aka RFC 4474. > >> > >>Other people think that there's a problem applying RFC 4474 > when we > >>use phone numbers. > >> > >>Some people think we use phone numbers a LOT, maybe almost all the > >>time, and that therefore we really need to figure out how > >>this impacts > >>RFC 4474 and our other concepts of identity. > >> > >>This makes it seem to me like maybe we need to get the > >>identity stuff > >>nailed down before we commit to a final version of DTLS-SRTP. > >>Or maybe > >>the other way around -- we nail down DTLS -SRTP, then figure > >>out what > >>we need from Identity to support it, then fix Identity. Or > maybe we > >>need to fix them both together. > >> > >>Now our AD is telling me that by reading it this way, I'm > >>unprofessionally evidencing bias in favor of some other > >>protocol that > >>may have been discussed prior to DTLS-SRTP (and the name of > which I > >>honestly can't remember right now). I find this unlikely, > >>given that I > >>don't actually understand any of the protocols and only > >>parrot what I > >>read on the mailing list earlier today. > >> > >>So let's put it to the working group. Is there a relationship > >>between > >>DTLS-SRTP, phone numbers, and identity that needs to be > figured out? > >>If so, how much of a problem is this? Do we care? > >> > >>-- > >>Dean > >> > >>_______________________________________________ > >>Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > >> > >> > >_______________________________________________ > >Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 16:36:07 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82E428C8B8; Fri, 29 Feb 2008 16:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p57tCcXCMkld; Fri, 29 Feb 2008 16:36:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4575A28C901; Fri, 29 Feb 2008 16:36:02 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C23928C81C for ; Fri, 29 Feb 2008 16:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTrFLy24ocHX for ; Fri, 29 Feb 2008 16:35:59 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C619228C80D for ; Fri, 29 Feb 2008 16:35:59 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Feb 2008 16:35:52 -0800 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 m210ZqfS010041; Fri, 29 Feb 2008 16:35:52 -0800 Received: from dwingwxp01 (dhcp-128-107-163-88.cisco.com [128.107.163.88]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m210ZhCQ024427; Sat, 1 Mar 2008 00:35:52 GMT From: "Dan Wing" To: "'David Schwartz'" References: <1DDB0D3CC4E7F14FAE946361C0A6065504FCB700@isr-jlm-mail.Kayote.com> Date: Fri, 29 Feb 2008 16:35:43 -0800 Message-ID: <004d01c87b34$3406dd00$58a36b80@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach4x0TCNh6QwqPNQeO7TMN1gaeTRACbLenw In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A6065504FCB700@isr-jlm-mail.Kayote.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=996; t=1204331752; x=1205195752; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20nit=20in=20draft-wing-sip-e164- rrc-01 |Sender:=20; bh=C0ontvuKXJR+3+nYKe098hYtlKB6sZw1/YrkXaNZ98U=; b=fP+n9NQUXDocJ3Mg6X4Z41BAeQO2cuUnwd/GiDmfsqaW09sa5utgoiq6xC plNugsnO1g4xfy/mqAJfCUYne36DgdBDgJtSpfUZAzvR0dJVodqX6h9PS8bz qOZTMXIHia; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] nit in draft-wing-sip-e164-rrc-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of David Schwartz > Sent: Tuesday, February 26, 2008 2:31 PM > To: dwing@cisco.com > Cc: sip@ietf.org > Subject: [Sip] nit in draft-wing-sip-e164-rrc-01 > > > Hi Dan > > a quick comment on this draft... > > There is no discussion of what happens when there is a > validation failure. While obvious, you should probably > reference 4474 processing upon validation failure (i.e. > respond with 438 'Invalid Identity Header'). And while on the > topic in your second example where the cert comparison test > fails your diagram still shows the call proceeding to its > destination (hence the earlier comment). I'm not sure we want to fail a call if validation fails; rather, we may want to allow it to complete and tell the user 'unauthenticated caller' (similar to what the PSTN does today by displaying "unidentified call" when caller ID failed). -d _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 17:13:41 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6610828C147; Fri, 29 Feb 2008 17:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y06KnvgsncTs; Fri, 29 Feb 2008 17:13:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B3128C75A; Fri, 29 Feb 2008 17:13:35 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94963A6DAD for ; Fri, 29 Feb 2008 17:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75fi8M2INiKI for ; Fri, 29 Feb 2008 17:13:34 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id E3C133A67B4 for ; Fri, 29 Feb 2008 17:13:33 -0800 (PST) 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 m211DMC05888; Sat, 1 Mar 2008 01:13:22 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 19:12:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <1ECE0EB50388174790F9694F77522CCF15315BAB@zrc2hxm0.corp.nortel.com> In-Reply-To: <953beacc0802291438x7f06c4bcod0d33963bfcf54a9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-outbound-12: Flow Timer Thread-Index: Ach7I+Pdgg5iXTDSSpmv5UAa99hyXgADv1vQ References: <953beacc0802291438x7f06c4bcod0d33963bfcf54a9@mail.gmail.com> From: "Francois Audet" To: "SIP" Cc: Cullen Jennings Subject: [Sip] draft-ietf-sip-outbound-12: Flow Timer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org When I went through the list of comments relating to draft-ietf-sip-outbound-11 in preparation for draft-ietf-sip-outbound-12, there was one item I agreed with Rohan and Cullen that I would bring to the list. There were some questions raised about the usefulness of the Flow-Timer parameter. Interestingly enough, it appears that this originally came from... myself. While I remember why I originally tought it would be useful, I no longuer believe that it is useful. My suggestion would therefore to remove the Flow-Timer parameter altogether. (I will note that previous versions of the draft didn't have it). Comments? _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 17:40:40 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4530228C8E9; Fri, 29 Feb 2008 17:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8ofBlTntcfL; Fri, 29 Feb 2008 17:40:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE58B28C848; Fri, 29 Feb 2008 17:40:38 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A945D28C588 for ; Fri, 29 Feb 2008 17:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+TDLLRny87u for ; Fri, 29 Feb 2008 17:40:32 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 57CBF28C5F3 for ; Fri, 29 Feb 2008 17:40:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,430,1199692800"; d="scan'208";a="15452828" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 29 Feb 2008 17:40:24 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m211eOiS013579; Fri, 29 Feb 2008 17:40:24 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id m211eMcD027365; Sat, 1 Mar 2008 01:40:26 GMT From: Cullen Jennings To: "Francois Audet" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15315BAB@zrc2hxm0.corp.nortel.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <953beacc0802291438x7f06c4bcod0d33963bfcf54a9@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF15315BAB@zrc2hxm0.corp.nortel.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 29 Feb 2008 17:40:08 -0800 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1103; t=1204335624; x=1205199624; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20draft-ietf-sip-outbound-12=3A=20Flow=20 Timer |Sender:=20; bh=Ua+bmHx5d81nQ3EmkDdx2ax9y+7WK2+3TGDTxXgllNA=; b=MfFXJMua5LSWjsR8gnDagszFxgZ38KYH/tzGdRkIldEam8kxoh98LosNAH JlAJs4JvzPPBz9mqhHxa0+w+r4IrQPD47EzOaX+tzC+9akyVt77eWWxqTNzR ZqQZlK9Prm/73sp8qztvPQT5klgH1iVNavg/8x274Mrl+IqF+zRnU=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP Subject: Re: [Sip] draft-ietf-sip-outbound-12: Flow Timer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 29, 2008, at 5:12 PM, Francois Audet wrote: > > When I went through the list of comments relating to draft-ietf-sip- > outbound-11 > in preparation for draft-ietf-sip-outbound-12, there was one item I > agreed > with Rohan and Cullen that I would bring to the list. > > There were some questions raised about the usefulness of the Flow- > Timer > parameter. Interestingly enough, it appears that this originally > came from... myself. > > While I remember why I originally tought it would be useful, I no > longuer believe > that it is useful. > When you first suggested it, I was not in favor of it. But you convinced me over time that it was great. Now I love it. Seriously, I don't feel strongly one way or the other. If no one wants it and is going to use it, I think we should remove it in the name of simplifying the draft. Cullen > > > My suggestion would therefore to remove the Flow-Timer parameter > altogether. > (I will note that previous versions of the draft didn't have it). > > Comments? _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 19:09:06 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C1F28C3DF; Fri, 29 Feb 2008 19:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFZ4jJvsr8fd; Fri, 29 Feb 2008 19:09:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211B23A6907; Fri, 29 Feb 2008 19:09:01 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2FE3A6907 for ; Fri, 29 Feb 2008 19:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMLWZMjjD6aV for ; Fri, 29 Feb 2008 19:08:54 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 6C0B93A6859 for ; Fri, 29 Feb 2008 19:08:54 -0800 (PST) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id veT81Y00516AWCUA701J00; Sat, 01 Mar 2008 03:08:11 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id vf8j1Y00402AVH08S00000; Sat, 01 Mar 2008 03:08:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=5ZMP7OrXdx3HqsSvWWYA:9 a=AmIZo3c-shltmC2q26oA:7 a=YBxAV1HprOh8Fcq7Zq5v2T9fIE8A:4 a=1pxjJC3EenQA:10 a=gi0PWCVxevcA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m2138gMj024973 for ; Fri, 29 Feb 2008 22:08:42 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m2138gWu024969; Fri, 29 Feb 2008 22:08:42 -0500 Date: Fri, 29 Feb 2008 22:08:42 -0500 Message-Id: <200803010308.m2138gWu024969@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1204099738.16881.21.camel@localhost> (aki.niemi@nokia.com) References: <5D1A7985295922448D5550C94DE2918001636AF1@DEEXC1U01.de.lucent.com> <200709181506.l8IF6Bmp007748@dragon.ariadne.com> <1203976392.6192.88.camel@localhost> <200802262131.m1QLV7Rm008476@dragon.ariadne.com> <1204099738.16881.21.camel@localhost> Subject: Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree that the point we're discussing is largely a matter of providing a "beware" statement, except with the exception of a possible *solution* to the problem which I will mention at the bottom. But in any case, I don't see the need for agenda time at the metting to discuss this. From: Aki Niemi > The notifier cannot know what routing is in front of it, because it > cannot know what URIs might route to it. Then that's bad. How does the notifier then know which PIDF to pick in presence subscriptions? Especially if it's not a presence subscription. But seriously, is this proposal confined to presence events? I see no such text. In general, a SUBSCRIBE will fork, and the subscriber presumably knows how it wants to integrate the events it will receive from the various subscriptions, based on the semantics of its situation. I agree this kind of setup presents a problem. But I also think that what we're dealing with here is not that different from the web world. There are a lot of load balancing schemes that can be used with HTTP, which result in a GET ending up in different data centers in different parts of the world at different times. What's important to note there is that if the service that is accessed via this GET needs sessions and gives out cookies, then the backend system needs to be synchronized. Otherwise, the servers will be unaware of each others cookies, and the service won't work correctly. Similarly, the backend to the SIP notifiers needs a synchronized backend, otherwise, subnot-etags won't work. Naturally, the etags just like cookies can be constructed in such a way that they contain the necessary state. There's a hidden philosophical problem: People think of SIP routing as being like PSTN routing, where the caller sends the call to a number which designates one destination, or at least, a single device which has total knowledge of a small number of possible destinations. The caller knows the globally-recongized *name* of the destination-group, and every destination knows of and is coordinated with *every other possible destination*. Your HTTP model is similar; you assume the request will reach one of a set of servers that are co-adminstered. But the reality is that SIP routing can be like sending e-mail to a mailing list -- the sender doesn't know what the possible destinations are, and each destination doesn't know what all the destinations are either, because some of the routing can be done by agents that are not co-administered with either the sender or the destination. Now I think the first case is more common, but if we are going to design a general mechanism, it should not fail badly in practice in the second case. Getting back to possible solutions: Looking at section 6.1, I see '[An entity-tag] can have any value, except for "*".' (Let's correct that to 'An entity-tag can be any token, except for "*".') We can dodge the problem of uncoordinated notifiers by demanding that entity-tags have some minimum amount of randomness. E.g., if any group of coordinated notifiers picks a 64-bit random value, and the entity-tag is generated by making a 64-bit hash of that value with the event information, the chances of an etag-value collision in any single instance is 2^-64. One can easily encode a 64-bit value in 11 token characters using (modified) base64. Compare that to the 5-character values used as examples in the I-D. Though if we used 6 base64 characters, we would still have a 36-bit hash, which is probably good enough. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 19:11:59 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B5B28C88F; Fri, 29 Feb 2008 19:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.581 X-Spam-Level: X-Spam-Status: No, score=-0.581 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90w3OfZP36o2; Fri, 29 Feb 2008 19:11:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E6E3A6B29; Fri, 29 Feb 2008 19:11:53 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8822C3A6B24 for ; Fri, 29 Feb 2008 19:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mMbEZb6n7Kh for ; Fri, 29 Feb 2008 19:11:46 -0800 (PST) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 05DF328C747 for ; Fri, 29 Feb 2008 19:11:45 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id vecz1Y0720lTkoCA201A00; Sat, 01 Mar 2008 03:11:02 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id vfBW1Y00L02AVH08Q00000; Sat, 01 Mar 2008 03:11:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=ED3SmDOBDsr-MUTBo0kA:9 a=8aowL38VVIRlJQdDppVlfc3PikIA:4 a=1pxjJC3EenQA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m213BUMj025213 for ; Fri, 29 Feb 2008 22:11:30 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m213BUPf025209; Fri, 29 Feb 2008 22:11:30 -0500 Date: Fri, 29 Feb 2008 22:11:30 -0500 Message-Id: <200803010311.m213BUPf025209@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1204294871.16881.142.camel@localhost> (aki.niemi@nokia.com) References: <5D1A7985295922448D5550C94DE2918001636AF1@DEEXC1U01.de.lucent.com> <200709181506.l8IF6Bmp007748@dragon.ariadne.com> <1203976392.6192.88.camel@localhost> <200802262131.m1QLV7Rm008476@dragon.ariadne.com> <1204099738.16881.21.camel@localhost> <1204294871.16881.142.camel@localhost> Subject: Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Aki Niemi In any case, this text would probably end up being non-normative, which means it's not critical to flesh out in detail for a publication request. I originally expected any text to be non-normative (since it was a warning about an unavoidable danger), but after the random hashes came up, it seems that it would be conceivable to specify a minimum randomness content for entity-tags. (We already have a randomness requirement for to/from-tags.) Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 29 19:27:13 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6339E28C76F; Fri, 29 Feb 2008 19:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvmaRmXPZ0Xa; Fri, 29 Feb 2008 19:27:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1C628C1F7; Fri, 29 Feb 2008 19:27:12 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9EF3A6A7F for ; Fri, 29 Feb 2008 19:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZvrDPMnuDNb for ; Fri, 29 Feb 2008 19:27:06 -0800 (PST) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id B626B3A6820 for ; Fri, 29 Feb 2008 19:27:06 -0800 (PST) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id veYQ1Y0020vp7WLA603y00; Sat, 01 Mar 2008 03:26:28 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id vfSw1Y00M02AVH08R00000; Sat, 01 Mar 2008 03:26:58 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOs_LcPODeIA:10 a=3fP2b-eVBxZrz_Aes1EA:9 a=fSwVwRwZlRH6FRxvf2QA:7 a=0WnyPZL4uC3ijnTtyLjJcLFxaIEA:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m213QuMj026329 for ; Fri, 29 Feb 2008 22:26:56 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m213QuF8026325; Fri, 29 Feb 2008 22:26:56 -0500 Date: Fri, 29 Feb 2008 22:26:56 -0500 Message-Id: <200803010326.m213QuF8026325@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <47C6F37B.7010609@cisco.com> (pkyzivat@cisco.com) References: <47C6F37B.7010609@cisco.com> Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Paul Kyzivat A 1xx that establishes an early dialog must contain a contact or else you really don't have a dialog. I think it is ambiguous whether: - the first 1xx with a particular to-tag *does* establish an early dialog and so *must* contain a contact, - OR a 1xx with a new to-tag, but without a contact, simply doesn't establish a dialog, but is legal. I would split the difference and say that the UAS MUST include a contact in the first 1xx it returns with a particular to-tag, but a UAC should accept a 1xx with new to-tag and without a contact and simply treat it as not establishing an early dialog. (Don't establish the dialog until you get enough info to do so.) I'd say that it does create a dialog, but it's an anomalous dialog in that you can't send any requests to it. (Though it's unlikely that you'd want to.) But you might well get a final response from the dialog, and you could get media from it. I think it's the fact that the UAC is unlikely to send a request until the dialog becomes confirmed is why we haven't worried about this case much. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip