From exim@www1.ietf.org Thu Apr 1 01:48:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07701 for ; Thu, 1 Apr 2004 01:48:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8vzZ-0004Jr-Bj for sip-archive@odin.ietf.org; Thu, 01 Apr 2004 01:47:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i316lvXe016547 for sip-archive@odin.ietf.org; Thu, 1 Apr 2004 01:47:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8vyf-0004BA-L2; Thu, 01 Apr 2004 01:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7HRQ-0006My-M4 for sip@optimus.ietf.org; Sat, 27 Mar 2004 12:17:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20681 for ; Sat, 27 Mar 2004 12:17:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7HRP-0000Za-00 for sip@ietf.org; Sat, 27 Mar 2004 12:17:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7HQY-0000Vt-00 for sip@ietf.org; Sat, 27 Mar 2004 12:16:58 -0500 Received: from bay12-f75.bay12.hotmail.com ([64.4.35.75] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B7HPi-0000O2-00 for sip@ietf.org; Sat, 27 Mar 2004 12:16:06 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 27 Mar 2004 09:15:29 -0800 Received: from 64.230.67.178 by by12fd.bay12.hotmail.msn.com with HTTP; Sat, 27 Mar 2004 17:15:29 GMT X-Originating-IP: [64.230.67.178] X-Originating-Email: [whitakercd@hotmail.com] X-Sender: whitakercd@hotmail.com From: "Chris Whitaker" To: sip@ietf.org Date: Sat, 27 Mar 2004 12:15:29 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2004 17:15:29.0496 (UTC) FILETIME=[1A893D80:01C4141F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] Question regarding SDP and holds Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , In rfc3264, it states: If the stream to be placed on hold was previously a sendrecv media stream, it is placed on hold by marking it as sendonly. So my question is this. If the stream being altered was previously a sendrecv media stream, and has become a sendonly stream... how does one communicate that without implying that the stream is on hold [ie neither sending nor receiving]? To be clear within the existing recommended proceedures for communcating a hold, I am trying to understand a means of differentiating when the source of media stream has stopped receiving but NOT stopped sending and when it has stopped BOTH. Secondly, if a sendrecv stream is becoming neither a sending nor receiving stream [which often occurs when it goes on hold] why does the rfc suggest claiming it is sendonly... would not inactive be more accurate? Chris _________________________________________________________________ MSN Premium includes powerful parental controls and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Apr 2 12:17:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19415 for ; Fri, 2 Apr 2004 12:17:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QIp-0000Ym-1T for sip-archive@odin.ietf.org; Fri, 02 Apr 2004 10:09:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32F9pE1002153 for sip-archive@odin.ietf.org; Fri, 2 Apr 2004 10:09:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9N7b-0002UI-9f; Fri, 02 Apr 2004 06:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9JOx-0000X2-3m for sip@optimus.ietf.org; Fri, 02 Apr 2004 02:47:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27361 for ; Fri, 2 Apr 2004 02:47:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9JOt-0004xD-00 for sip@ietf.org; Fri, 02 Apr 2004 02:47:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9JNx-0004rq-00 for sip@ietf.org; Fri, 02 Apr 2004 02:46:41 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9JNn-0004mO-00 for sip@ietf.org; Fri, 02 Apr 2004 02:46:32 -0500 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i327kHNr001755; Fri, 2 Apr 2004 02:46:18 -0500 (EST) Message-ID: <406CE1BC.6050109@dynamicsoft.com> Date: Thu, 01 Apr 2004 22:45:00 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: sip@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: GRUU, device and un-REGISTER with * Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Changed to sip, since I dont think this is a SIMPLE issue. The meaning of Contact: * with Expires:0 remains unchanged; delete all contacts. The change you are proposing would necessitate a Require in registrations, whereas the current gruu stuff is all backwards compatible and thus Supported is sufficient. I am disinclined to make such a change; we're not redefining the REGISTER operation as opposed to adding gruu, and I am unsure what real problem is being solved by such a change. Thanks, Jonathan R. Orit Levin wrote: > Guys, > Now when we have GRUU, device identifier and the expanded registration > procedure, what would be the meaning of un-REGISTER with *? > It makes a lot of sense to un-REGISTER a specific device with all its > contacts at once. Some would say that it is more useful (and reasonable > from authentication/security point of view) than un-REGISTERing all the > devices of the same user at once. > > I personally think that we need both semantics and the syntax for each > needs to be defined/agreed upon. > > Thanks, > Orit. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Apr 2 16:12:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29661 for ; Fri, 2 Apr 2004 16:12:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SSH-0000Hz-Be for sip-archive@odin.ietf.org; Fri, 02 Apr 2004 12:27:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32HRjUo001043 for sip-archive@odin.ietf.org; Fri, 2 Apr 2004 12:27:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QcV-0006Qq-4K; Fri, 02 Apr 2004 10:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9NaQ-00052R-F1 for sip@optimus.ietf.org; Fri, 02 Apr 2004 07:15:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05884 for ; Fri, 2 Apr 2004 07:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9NaP-0005LZ-00 for sip@ietf.org; Fri, 02 Apr 2004 07:15:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9NZV-0005FK-00 for sip@ietf.org; Fri, 02 Apr 2004 07:14:53 -0500 Received: from [62.119.82.43] (helo=hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 1B9NYa-000532-00 for sip@ietf.org; Fri, 02 Apr 2004 07:13:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE Date: Fri, 2 Apr 2004 14:13:24 +0200 Message-ID: Thread-Topic: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE Thread-Index: AcQSdofDfTFhWfYNRQeFxG1bVlmA9gA2kTLgAVaLoUA= From: "Christian Jansson" To: "Steve Langstaff" , "Paul Kyzivat" Cc: "Jonathan Rosenberg" , "Alex Bligh" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable comments inline =20 > A "NAT-friendly" RTP implementation could periodically send=20 > no-ops or silence (depending on the payload types already=20 > negotiated) if it is not sending anything else - or is this=20 > outlawed by being set to "recvonly" or "inactive"? Do we really have to use special no-ops or silence RTP packets? Why not just send zero length payload UDP packets, then we do not have to invent something new. An RTP stack should already today handle this, otherwise that would be a simple attack method. As long as the UDP packets pass through the NATs and firewalls it does not matter whether the receiver is implemented to understand the zero length packet or not. / Christian Jansson, Hotsip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Apr 4 10:25:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01326 for ; Sun, 4 Apr 2004 10:25:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA8Y6-0006De-Ph for sip-archive@odin.ietf.org; Sun, 04 Apr 2004 10:24:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i34EOY0t023890 for sip-archive@odin.ietf.org; Sun, 4 Apr 2004 10:24:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA8Xa-0006BK-1U; Sun, 04 Apr 2004 10:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA8XG-00069x-SB for sip@optimus.ietf.org; Sun, 04 Apr 2004 10:23:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01278 for ; Sun, 4 Apr 2004 10:23:39 -0400 (EDT) From: alan.duric@globalipsound.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA8XE-0005hr-00 for sip@ietf.org; Sun, 04 Apr 2004 10:23:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA8WL-0005bM-00 for sip@ietf.org; Sun, 04 Apr 2004 10:22:46 -0400 Received: from [202.88.174.148] (helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BA8VX-0005TY-00 for sip@ietf.org; Sun, 04 Apr 2004 10:21:57 -0400 To: sip@ietf.org Date: Sun, 4 Apr 2004 19:53:35 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_00005283.00000D21" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.6 required=5.0 tests=AWL,MISSING_MIMEOLE, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 0.0 AWL AWL: Auto-whitelist adjustment Subject: [Sip] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0002_00005283.00000D21 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_NETSKY.C in file product.scr (in product.zip) The uncleanable file is deleted. --------------------------------------------------------- ------=_NextPart_000_0002_00005283.00000D21 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit here is it. ------=_NextPart_000_0002_00005283.00000D21 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) product.zip is removed from here because it contains a virus. --------------------------------------------------------- ------=_NextPart_000_0002_00005283.00000D21-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 5 06:30:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20959 for ; Mon, 5 Apr 2004 06:30:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARMe-0003MH-CL for sip-archive@odin.ietf.org; Mon, 05 Apr 2004 06:30:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35AU0Je012892 for sip-archive@odin.ietf.org; Mon, 5 Apr 2004 06:30:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARM2-00032M-MW; Mon, 05 Apr 2004 06:29:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARLB-0002aS-Sw for sip@optimus.ietf.org; Mon, 05 Apr 2004 06:28:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20819 for ; Mon, 5 Apr 2004 06:28:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BARL7-0004WO-00 for sip@ietf.org; Mon, 05 Apr 2004 06:28:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BARKJ-0004QB-00 for sip@ietf.org; Mon, 05 Apr 2004 06:27:35 -0400 Received: from relay1.loniis.spb.ru ([62.152.70.129]) by ietf-mx with smtp (Exim 4.12) id 1BARJe-0004JI-00 for sip@ietf.org; Mon, 05 Apr 2004 06:26:54 -0400 Received: (qmail 4255 invoked from network); 5 Apr 2004 10:26:48 -0000 Received: from relay1.nio1.loniis (HELO loniis.spb.su) (192.168.0.104) by lgw.nio1.loniis with SMTP; 5 Apr 2004 10:26:48 -0000 Received: (qmail 26251 invoked from network); 5 Apr 2004 10:26:47 -0000 Received: from dhcp-0-14.nio1.loniis (HELO samorezov) (192.168.0.14) by relay1.nio1.loniis with SMTP; 5 Apr 2004 10:26:47 -0000 From: "=?koi8-r?B?58HMwcvUyc/Oz9cg4c7Uz84g7snLz8zBxdfJ3g==?=" To: Subject: [SIP] Sending 2xx responses to INVITE Date: Mon, 5 Apr 2004 14:34:15 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear SIP experts, I have following questions (maybe already discussed on the list in the past) regarding the sending of 2xx responses to INVITE. In what way does TU send retransmissions of 2xx responses to INVITE? What is the interval between these retransmissions? How many retansmissions can be sent? Best regards Anton _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 5 07:00:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22978 for ; Mon, 5 Apr 2004 07:00:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARpw-00008Y-MJ for sip-archive@odin.ietf.org; Mon, 05 Apr 2004 07:00:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35B0GWa000508 for sip-archive@odin.ietf.org; Mon, 5 Apr 2004 07:00:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARpj-000056-1u; Mon, 05 Apr 2004 07:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARpI-0008Vk-4c for sip@optimus.ietf.org; Mon, 05 Apr 2004 06:59:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22919 for ; Mon, 5 Apr 2004 06:59:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BARpD-000160-00 for sip@ietf.org; Mon, 05 Apr 2004 06:59:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BARoG-0000zN-00 for sip@ietf.org; Mon, 05 Apr 2004 06:58:32 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BARno-0000rd-00 for sip@ietf.org; Mon, 05 Apr 2004 06:58:04 -0400 Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i35AvYEP011657; Mon, 5 Apr 2004 12:57:34 +0200 Received: from zagh102a.zag.siemens.hr (vies1kbx [158.226.135.174]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i35AvWZ8017662; Mon, 5 Apr 2004 12:57:33 +0200 Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Apr 2004 12:48:30 +0200 Message-ID: From: Bilajbegovic Damir To: ??????????? ????? ?????????? , sip@ietf.org Subject: RE: [SIP] Sending 2xx responses to INVITE Date: Mon, 5 Apr 2004 12:48:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, Not sure but I think 1st Invite and 7 retransmission. Intervals are increasing by double. Hope I helped. Bilaj -----Original Message----- From: galactionov@loniis.ru [mailto:galactionov@loniis.ru] Sent: Monday, April 05, 2004 12:34 PM To: sip@ietf.org Subject: [SIP] Sending 2xx responses to INVITE Dear SIP experts, I have following questions (maybe already discussed on the list in the past) regarding the sending of 2xx responses to INVITE. In what way does TU send retransmissions of 2xx responses to INVITE? What is the interval between these retransmissions? How many retansmissions can be sent? Best regards Anton _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 5 08:09:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26224 for ; Mon, 5 Apr 2004 08:09:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASum-0008SE-Ge for sip-archive@odin.ietf.org; Mon, 05 Apr 2004 08:09:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35C9KqI032499 for sip-archive@odin.ietf.org; Mon, 5 Apr 2004 08:09:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASuT-0008MW-Nu; Mon, 05 Apr 2004 08:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAStx-0008C9-D2 for sip@optimus.ietf.org; Mon, 05 Apr 2004 08:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26186 for ; Mon, 5 Apr 2004 08:08:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAStw-0001xh-00 for sip@ietf.org; Mon, 05 Apr 2004 08:08:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASt6-0001qO-00 for sip@ietf.org; Mon, 05 Apr 2004 08:07:37 -0400 Received: from www.pspl.co.in ([202.54.11.65] helo=smtp.pspl.co.in) by ietf-mx with esmtp (Exim 4.12) id 1BASsG-0001aL-00 for sip@ietf.org; Mon, 05 Apr 2004 08:06:45 -0400 Received: (from root@localhost) by smtp.pspl.co.in (8.12.9/8.12.9) id i35C6EZ5007329 for ; Mon, 5 Apr 2004 17:36:14 +0530 X-Scanned: XAM28854 Scanned by XAMIME Received: from grandin (grandin.intranet.pspl.co.in [192.168.8.223]) (authenticated bits=0) by persistent.co.in (8.12.9/8.12.9) with ESMTP id i35C62RG007114; Mon, 5 Apr 2004 17:36:03 +0530 From: "Umesh Sharma" To: "Bilajbegovic Damir" , "??????????? ????? ??????????" , Subject: RE: [SIP] Sending 2xx responses to INVITE Date: Mon, 5 Apr 2004 17:35:52 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi >>In what way does TU send retransmissions of 2xx responses to INVITE? What is >>the interval between these retransmissions? To quote from rfc 3261 directly: "The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received. This is independent of whatever transport protocols are used to send the response." >>How many retansmissions can be sent? "If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated." In 17.1.1.1 "Eventually, the server transaction decides to send a final response. For unreliable transports, that response is retransmitted periodically, and for reliable transports, it is sent once." I have a question too here, Now this line above seems to contradict this paragraph in 13.3.1.4. "Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable." Am I reading this incorrectly? regards -umesh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Bilajbegovic Damir Sent: Monday, April 05, 2004 4:18 PM To: ??????????? ????? ??????????; sip@ietf.org Subject: RE: [SIP] Sending 2xx responses to INVITE Hi, Not sure but I think 1st Invite and 7 retransmission. Intervals are increasing by double. Hope I helped. Bilaj -----Original Message----- From: galactionov@loniis.ru [mailto:galactionov@loniis.ru] Sent: Monday, April 05, 2004 12:34 PM To: sip@ietf.org Subject: [SIP] Sending 2xx responses to INVITE Dear SIP experts, I have following questions (maybe already discussed on the list in the past) regarding the sending of 2xx responses to INVITE. In what way does TU send retransmissions of 2xx responses to INVITE? What is the interval between these retransmissions? How many retansmissions can be sent? Best regards Anton _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 5 21:43:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02926 for ; Mon, 5 Apr 2004 21:43:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAfbj-0002T3-Vv for sip-archive@odin.ietf.org; Mon, 05 Apr 2004 21:42:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i361gVts009486 for sip-archive@odin.ietf.org; Mon, 5 Apr 2004 21:42:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAfbG-0002PH-CE; Mon, 05 Apr 2004 21:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAfb0-0002GT-Er for sip@optimus.ietf.org; Mon, 05 Apr 2004 21:41:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02694 for ; Mon, 5 Apr 2004 21:41:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAfax-0004XC-00 for sip@ietf.org; Mon, 05 Apr 2004 21:41:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAfA7-0001oQ-00 for sip@ietf.org; Mon, 05 Apr 2004 21:14:00 -0400 Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 1BAetk-0007ft-00 for sip@ietf.org; Mon, 05 Apr 2004 20:57:05 -0400 Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id i360uhj07861; Tue, 6 Apr 2004 08:56:44 +0800 (CST) Received: from pekw096e.cn001.siemens.net (pekw096e.cn001.siemens.net [140.231.51.134]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id i360uo824546; Tue, 6 Apr 2004 08:56:50 +0800 (CST) Received: by pekw096e with Internet Mail Service (5.5.2653.19) id <2AJPVJC8>; Tue, 6 Apr 2004 08:56:59 +0800 Message-ID: <31F31018FE2DC941A70BD30477510B0C19D643@biscm02> From: "Hu Yijun,BISC R&D SA(BJ)" To: "'Umesh Sharma'" , Bilajbegovic Damir , ??????????? ????? ?????????? , sip@ietf.org Subject: RE: [SIP] Sending 2xx responses to INVITE Date: Tue, 6 Apr 2004 09:01:39 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=AWL,ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, Please see my comments below. regards hu yijun >-----Original Message----- >From: Umesh Sharma [mailto:umesh_sharma@persistent.co.in] >Sent: Monday, April 05, 2004 8:06 PM >To: Bilajbegovic Damir; ??????????? ????? ??????????; sip@ietf.org >Subject: RE: [SIP] Sending 2xx responses to INVITE > > >Hi > >>>In what way does TU send retransmissions of 2xx responses to >INVITE? What >is >>>the interval between these retransmissions? > >To quote from rfc 3261 directly: > >"The 2xx response is passed to the transport with an > interval that starts at T1 seconds and doubles for each > retransmission until it reaches T2 seconds (T1 and T2 are defined in > Section 17). Response retransmissions cease when an ACK request for > the response is received. This is independent of whatever transport > protocols are used to send the response." > >>>How many retansmissions can be sent? > >"If the server retransmits the 2xx response for 64*T1 seconds without > receiving an ACK, the dialog is confirmed, but the session SHOULD be > terminated." > >In 17.1.1.1 > >"Eventually, the server transaction decides > to send a final response. For unreliable transports, that response > is retransmitted periodically, and for reliable transports, it is > sent once." > >I have a question too here, Now this line above seems to >contradict this >paragraph in >13.3.1.4. > > "Since 2xx is retransmitted end-to-end, there may be hops between > UAS and UAC that are UDP. To ensure reliable delivery across > these hops, the response is retransmitted periodically >even if the > transport at the UAS is reliable." > >Am I reading this incorrectly? The description of ch 17.1.1.1 was foucs on the retransmission of the non-2xx final response to INVITE, which were administered by the transaction layer. Those responses are delivered hop-by-hop. So that, for a certain hop, which uses reliable transport, the non-2xx final response is sent only once. However, the retransmission of the 2XX to INVITE was administered by the transaction user (TU). It MUST comply with the ch13.3.1.4 of rfc3261: "the response is retransmitted periodically even if the transport at the UAS is reliable". > >regards >-umesh >-----Original Message----- >From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of >Bilajbegovic Damir >Sent: Monday, April 05, 2004 4:18 PM >To: ??????????? ????? ??????????; sip@ietf.org >Subject: RE: [SIP] Sending 2xx responses to INVITE > > >Hi, > Not sure but I think 1st Invite and 7 retransmission. >Intervals are >increasing by double. > Hope I helped. > Bilaj > >-----Original Message----- >From: galactionov@loniis.ru [mailto:galactionov@loniis.ru] >Sent: Monday, April 05, 2004 12:34 PM >To: sip@ietf.org >Subject: [SIP] Sending 2xx responses to INVITE > > >Dear SIP experts, > >I have following questions (maybe already discussed on the >list in the past) >regarding the sending of 2xx responses to INVITE. > >In what way does TU send retransmissions of 2xx responses to >INVITE? What is >the interval between these retransmissions? How many >retansmissions can be >sent? > >Best regards >Anton > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 02:26:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10979 for ; Tue, 6 Apr 2004 02:26:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAk2L-0002Oo-Db for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 02:26:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i366QHDv009188 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 02:26:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAk26-0002Fj-Ki; Tue, 06 Apr 2004 02:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAk1F-0001zW-8M for sip@optimus.ietf.org; Tue, 06 Apr 2004 02:25:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10565 for ; Tue, 6 Apr 2004 02:25:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAk1B-0006HH-00 for sip@ietf.org; Tue, 06 Apr 2004 02:25:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAjpD-00049m-00 for sip@ietf.org; Tue, 06 Apr 2004 02:12:44 -0400 Received: from mx04.263.net ([211.150.96.24] helo=smtp.263.net) by ietf-mx with esmtp (Exim 4.12) id 1BAjMT-00019u-00 for sip@ietf.org; Tue, 06 Apr 2004 01:43:01 -0400 Received: by smtp.263.net (Postfix, from userid 500) id 61E281BDDA; Tue, 6 Apr 2004 13:42:56 +0800 (CST) From: =?gb2312?B?bmFtZQ==?= To: sip@ietf.org Date: Tue, 6 Apr 2004 13:42:54 +0800 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 X-Mailer: XMail-1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Message-Id: <20040406054256.61E281BDDA@smtp.263.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,MIME_BASE64_TEXT, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Sip] research area Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 aGVsbG8sIGFsbA0KaSB3YW50IHRvIGtub3cgdGhlcmUgYXJlIHdoYXQgaG90c3BvdCByZXNl YXJjaCBhcmVhIGFib3V0IHNpcCB1c2VkIGluIG1vYmlsZSBuZXR3b3JrLg0KY2FuIHlvdSBo ZWxwIG1lPw0KDQoNCg0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09DQoyNjO159fT 08q8/qOt0MXAtdPK19TXqNK1 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 07:13:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05349 for ; Tue, 6 Apr 2004 07:13:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoWC-0007m7-Vx for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 07:13:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36BDOYu029887 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 07:13:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoVo-0007b4-Qe; Tue, 06 Apr 2004 07:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoVS-0007Pj-Ma for sip@optimus.ietf.org; Tue, 06 Apr 2004 07:12:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04963 for ; Tue, 6 Apr 2004 07:12:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAoVR-0001fo-00 for sip@ietf.org; Tue, 06 Apr 2004 07:12:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAoJh-0007Gy-00 for sip@ietf.org; Tue, 06 Apr 2004 07:00:31 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BAnql-0004K2-00 for sip@ietf.org; Tue, 06 Apr 2004 06:30:35 -0400 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 314BB1FDCB; Tue, 6 Apr 2004 11:30:32 +0100 (BST) Date: Tue, 06 Apr 2004 11:30:09 +0100 From: Alex Bligh Reply-To: Alex Bligh To: sip@ietf.org Cc: Alex Bligh Message-ID: <2999530066.1081251009@[192.168.100.5]> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] RFC3261 & authenticating PROXIES to other proxies & UAS's Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit First, apologies if this is a dumb suggestion - it seems so obvious that it must either be an even more obvious reason not to do it, or someone must have thought of it before. The (general) problem I am trying to solve looks like this: UAC <-----/\/\/\/\/---> P1 <--/\/--> P2 <---> UAS => PSTN (CPE) (proxy) (proxy) (media gateway) P2 may or may not be present. Let us assume UAC and P1 are very distant, and P1 & either P2 or UAS are sufficiently distant that host security is impractical without adding some additional layer (ipsec, tls etc.). UAC is CPE on a site of a customer of SP1, who operates P1. UAS is a media gateway, and P2 a (possibly) intervening proxy, operated by SP2. Let us further assume that UAC registers to P1, and that P1 has already authenticated UAC, and that any INVITE passed through P1 has already been authenticated as coming from UAC and been authorized by P1 according to SP1's local policy, prior to being forwarded to P2. Let us further assume that it is the local policy of SP1 that any such authorized calls it passes to SP2 would be authorized by SP1. So for instance SP2 is a VoIP termination provider, and SP1 a VoIP service provider. SP2 wishes to authenticate & authorize calls made to UAS. It uses HTTP Digest Authentication (per RFC3261 s.22). This could either be done at P2, or at UAS. RFC3261 section 16.7 suggests that Proxies MUST forward such final 4xx responses received back towards the UAS (as there will still be Via: header(s)). This means that credentials for P2 or UAS must be supplied by UAC, not by P1. This has a number of disadvantages, for instance 1. The 401/407 response is forwarded hop-by-hop all the way to UAC, and a retry made. This causes unnecessary network traffic and delay. 2. Either a) UAS/P2 must challenge UAC with the same realm as P1 did, in which case in practice SP2 must be able to query SP1's authentication database, which necessitates yet another protocol; or b) UAS/P2 challenges UAC in a different realm to P1, which means UAC must hold two sets of credentials (and, in the case where SP3, SP4, etc. are providing similar services to SP1, a possibly unlimited set of credentials). 3. In either case, UAC has credentials which allow it to traverse P2 / UAS, which may be undesirable from both SP1 and SP2's point of view, if (say) the contractual relationship is between User and SP1, and SP1 and SP2, but not between User and SP2. What I am trying to determine is why a 401/407 challenge from P2/UAS could not result in a response by P1, i.e. P1 itself provide the credentials to P2/UAS. Whilst this would seem to be in breach of RC3261, I can't see what harm it does, and it would bring considerable benefit - for instance P1 could authenticate to P2/UAC using its own credentials, as opposed to credentials belonging to the particular user making the call. IE P1 detects that the response comes from P2 with a realm that it knows, and behaves (in essence) a little like a UAC. So the traffic flow would look like this (assuming P1 authenticates to P2) UAC P1 P2 UAS | | | | | INVITE | | | | ------------> | | | | | | | | 407 Unauth | | | | <----------- | | | | | | | | ACK | | | | -----------> | | | | | | | | INVITE with | | | | user creds | | | | for SP1 | | | | -----------> | | | | | | | | 100 Trying | INVITE | | | <----------- | ------------> | | } | | | | } | | 407 Unauth | | } | | <------------ | | } | | | | } | | ACK | | } new | | -------------> | | } | | | | } | | INVITE with | | } | | SP1 creds for | | } | | SP2 | | } | | -------------> | | } | | | | | | 100 Trying | INVITE | | 100 Trying | <----------- | -------------> | | <------------ | | | | | | 200 OK | | | 200 OK | <------------- | | 200 OK | <------------- | | | <------------- | | | | | | | | | | | | | | | | | | | It is relatively easy to imagine variations where P1 alternatively or additionally authenticates to UAS, or P2 alternatively or additionally authenticates to UAS. Now, it seems to me, apart from a slight alteration to section 16.7 of RFC3261, this could be achieved with no protocol changes. To support it would only require a change at those proxies wishing to authenticate themselves to other proxies or UAS's, and no change is required at proxies or UAS's being authenticated to. So: 1. Is this in fact not in breach of RFC3261 at all? 2. If not, is this a good solution to the problem? 3. If not, why not, and what should I do instead? Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 08:53:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11881 for ; Tue, 6 Apr 2004 08:53:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAq53-0005eF-7d for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 08:53:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36CrTF2021712 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 08:53:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAq4n-0005X5-V0; Tue, 06 Apr 2004 08:53:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAq4F-00059v-0q for sip@optimus.ietf.org; Tue, 06 Apr 2004 08:52:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11646 for ; Tue, 6 Apr 2004 08:52:36 -0400 (EDT) From: Viktor.Bekesi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAq4D-00054h-00 for sip@ietf.org; Tue, 06 Apr 2004 08:52:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BApak-0001za-00 for sip@ietf.org; Tue, 06 Apr 2004 08:22:11 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BApF6-0006it-00 for sip@ietf.org; Tue, 06 Apr 2004 07:59:48 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i36Bxlx18542 for ; Tue, 6 Apr 2004 14:59:47 +0300 (EET DST) X-Scanned: Tue, 6 Apr 2004 14:59:43 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i36Bxh7M021457 for ; Tue, 6 Apr 2004 14:59:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 005ZSv15; Tue, 06 Apr 2004 14:59:42 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i36BxbF01331 for ; Tue, 6 Apr 2004 14:59:37 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Apr 2004 14:31:26 +0300 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Apr 2004 14:31:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Caller-Preferences: Representing negated Boolean feature tags Date: Tue, 6 Apr 2004 13:31:24 +0200 Message-ID: thread-topic: [Sip] Caller-Preferences: Representing negated Boolean feature tags thread-index: AcQbyrEYPgB2CpcHRb+gH9kTJKJfzg== To: X-OriginalArrivalTime: 06 Apr 2004 11:31:25.0809 (UTC) FILETIME=[B2121610:01C41BCA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, I am implementing SIP Caller-Preferences related functionalities, and = there is one thing that is not clear for me after reading the relevant = drafts and rfcs: Does it make sense to negate a Boolean type feature = tag? like the audio in the example: (& (! (audio=3DTRUE)) (video=3DTRUE) (sip.mobility=3Dfixed) (message=3DTRUE) (| (sip.methods=3DINVITE) (sip.methods=3DOPTIONS) = (sip.methods=3DBYE) (sip.methods=3DCANCEL) (sip.methods=3DACK)) (| (sip.schemes=3Dsip) (sip.schemes=3Dhttp))) If yes, then the next question arises: How can I represent negated = Boolean type feature tags in SIP header parameters?=20 According to draft-ietf-sip-callerprefs-10,=20 (& (sip.mobility=3Dfixed) (| (! (sip.events=3Dpresence)) (sip.events=3Dwinfo)) (| (language=3Den) (language=3Dde)) (sip.description=3D"PC") (sip.newparam=3DTRUE) (rangeparam=3D-4..5125/1000)) this declaration can be turned into this representation: = Accept-Contact:*;mobility=3D"fixed";events=3D"!presence,winfo";language=3D= "en,de" ;description=3D"";+sip.newparam;+rangeparam=3D"#-4:+5.125" (I reversed the order as it was in the document) Here the events are negated and that is indicated by the exclamation = mark at the beginning of the event-tag-value. Boolean type tags are = turned into flag parameters with no value. So then how can the very = first example represented? Thanks in advance, best regards:=20 Viktor Bekesi Nokia Networks +36-20 9849-202 =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 09:09:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14751 for ; Tue, 6 Apr 2004 09:09:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAqKQ-00044N-Kl for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 09:09:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36D9Mq1015612 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 09:09:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAqK6-0003w8-Kp; Tue, 06 Apr 2004 09:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAqJh-0003m8-I2 for sip@optimus.ietf.org; Tue, 06 Apr 2004 09:08:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14663 for ; Tue, 6 Apr 2004 09:08:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAqJf-0000DI-00 for sip@ietf.org; Tue, 06 Apr 2004 09:08:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAqAq-0006KI-00 for sip@ietf.org; Tue, 06 Apr 2004 08:59:30 -0400 Received: from www.pspl.co.in ([202.54.11.65] helo=smtp.pspl.co.in) by ietf-mx with esmtp (Exim 4.12) id 1BApsU-0003PP-00 for sip@ietf.org; Tue, 06 Apr 2004 08:40:30 -0400 Received: (from root@localhost) by smtp.pspl.co.in (8.12.9/8.12.9) id i36Ce8VD002940 for ; Tue, 6 Apr 2004 18:10:08 +0530 X-Scanned: XAM28854 Scanned by XAMIME Received: from grandin (pasidew.pspl.co.in [210.210.81.195] (may be forged)) (authenticated bits=0) by persistent.co.in (8.12.9/8.12.9) with ESMTP id i36Ce026002889; Tue, 6 Apr 2004 18:10:05 +0530 From: "Umesh Sharma" To: "Hu Yijun,BISC R&D SA\(BJ\)" , Subject: RE: [SIP] Sending 2xx responses to INVITE Date: Tue, 6 Apr 2004 18:09:54 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <31F31018FE2DC941A70BD30477510B0C19D643@biscm02> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Hu I re-read the section 17.1.1.1, it looks to me a general statement which does not distinguishes between non-2xx final & 2xx response. -regards umesh -----Original Message----- From: Hu Yijun,BISC R&D SA(BJ) [mailto:yijun.hu@siemens.com] Sent: Tuesday, April 06, 2004 6:32 AM To: 'Umesh Sharma'; Bilajbegovic Damir; ??????????? ????? ??????????; sip@ietf.org Subject: RE: [SIP] Sending 2xx responses to INVITE Hello, Please see my comments below. regards hu yijun >-----Original Message----- >From: Umesh Sharma [mailto:umesh_sharma@persistent.co.in] >Sent: Monday, April 05, 2004 8:06 PM >To: Bilajbegovic Damir; ??????????? ????? ??????????; sip@ietf.org >Subject: RE: [SIP] Sending 2xx responses to INVITE > > >Hi > >>>In what way does TU send retransmissions of 2xx responses to >INVITE? What >is >>>the interval between these retransmissions? > >To quote from rfc 3261 directly: > >"The 2xx response is passed to the transport with an > interval that starts at T1 seconds and doubles for each > retransmission until it reaches T2 seconds (T1 and T2 are defined in > Section 17). Response retransmissions cease when an ACK request for > the response is received. This is independent of whatever transport > protocols are used to send the response." > >>>How many retansmissions can be sent? > >"If the server retransmits the 2xx response for 64*T1 seconds without > receiving an ACK, the dialog is confirmed, but the session SHOULD be > terminated." > >In 17.1.1.1 > >"Eventually, the server transaction decides > to send a final response. For unreliable transports, that response > is retransmitted periodically, and for reliable transports, it is > sent once." > >I have a question too here, Now this line above seems to >contradict this >paragraph in >13.3.1.4. > > "Since 2xx is retransmitted end-to-end, there may be hops between > UAS and UAC that are UDP. To ensure reliable delivery across > these hops, the response is retransmitted periodically >even if the > transport at the UAS is reliable." > >Am I reading this incorrectly? The description of ch 17.1.1.1 was foucs on the retransmission of the non-2xx final response to INVITE, which were administered by the transaction layer. Those responses are delivered hop-by-hop. So that, for a certain hop, which uses reliable transport, the non-2xx final response is sent only once. However, the retransmission of the 2XX to INVITE was administered by the transaction user (TU). It MUST comply with the ch13.3.1.4 of rfc3261: "the response is retransmitted periodically even if the transport at the UAS is reliable". > >regards >-umesh >-----Original Message----- >From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of >Bilajbegovic Damir >Sent: Monday, April 05, 2004 4:18 PM >To: ??????????? ????? ??????????; sip@ietf.org >Subject: RE: [SIP] Sending 2xx responses to INVITE > > >Hi, > Not sure but I think 1st Invite and 7 retransmission. >Intervals are >increasing by double. > Hope I helped. > Bilaj > >-----Original Message----- >From: galactionov@loniis.ru [mailto:galactionov@loniis.ru] >Sent: Monday, April 05, 2004 12:34 PM >To: sip@ietf.org >Subject: [SIP] Sending 2xx responses to INVITE > > >Dear SIP experts, > >I have following questions (maybe already discussed on the >list in the past) >regarding the sending of 2xx responses to INVITE. > >In what way does TU send retransmissions of 2xx responses to >INVITE? What is >the interval between these retransmissions? How many >retansmissions can be >sent? > >Best regards >Anton > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 10:10:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20991 for ; Tue, 6 Apr 2004 10:10:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArHT-0007Jl-QX for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 10:10:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36EAN8p028080 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 10:10:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArHC-00078b-GM; Tue, 06 Apr 2004 10:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArGr-00073A-RC for sip@optimus.ietf.org; Tue, 06 Apr 2004 10:09:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20720 for ; Tue, 6 Apr 2004 10:09:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BArGp-0007WP-00 for sip@ietf.org; Tue, 06 Apr 2004 10:09:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAr8P-0005l1-00 for sip@ietf.org; Tue, 06 Apr 2004 10:01:01 -0400 Received: from webbox100.server-home.net ([195.137.212.21]) by ietf-mx with esmtp (Exim 4.12) id 1BAqkQ-0002aQ-00 for sip@ietf.org; Tue, 06 Apr 2004 09:36:14 -0400 Received: from pernau.at (mirnixdirnix.ict.tuwien.ac.at [128.131.80.218]) by webbox100.server-home.net (Postfix) with ESMTP id BEE801604FA; Tue, 6 Apr 2004 15:36:07 +0200 (CEST) Message-ID: <4072B245.5070602@pernau.at> Date: Tue, 06 Apr 2004 15:36:05 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 0.5a (Windows/20040120) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: sip@ietf.org Subject: Re: [Sip] RFC3261 & authenticating PROXIES to other proxies & UAS's References: <2999530066.1081251009@[192.168.100.5]> In-Reply-To: <2999530066.1081251009@[192.168.100.5]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Alex! Alex Bligh wrote: > So: > 1. Is this in fact not in breach of RFC3261 at all? > 2. If not, is this a good solution to the problem? I think (not sure) another problem is the CSeq - which will be increased with every request, and if the proxy P! inreases it on behalf of UAC1, then this might cause problems. > 3. If not, why not, and what should I do instead? SP2 can authenticate your IP address (IP address of P1) and all requests from your IP address will be billed on your account. To avaid spoffing, UDP should be disabled on P2 and you should send your requests using TCP. Klaus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 13:53:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11726 for ; Tue, 6 Apr 2004 13:53:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuk5-0005X0-JI for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 13:53:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36HpxdV021205 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 13:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuZq-0003rb-8D; Tue, 06 Apr 2004 13:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuFW-00072c-9A for sip@optimus.ietf.org; Tue, 06 Apr 2004 13:20:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08098 for ; Tue, 6 Apr 2004 13:20:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuFU-0003Hw-00 for sip@ietf.org; Tue, 06 Apr 2004 13:20:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAtzk-0001KA-00 for sip@ietf.org; Tue, 06 Apr 2004 13:04:17 -0400 Received: from smtp2.su.se ([130.237.93.212]) by ietf-mx with esmtp (Exim 4.12) id 1BAtbf-0006Xg-00 for sip@ietf.org; Tue, 06 Apr 2004 12:39:23 -0400 Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id B70CC2005EB; Tue, 6 Apr 2004 18:39:12 +0200 (CEST) Received: from smtp2.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14724-01-22; Tue, 6 Apr 2004 18:39:12 +0200 (CEST) Received: from min.it.su.se (min.it.su.se [130.237.95.62]) by smtp2.su.se (Postfix) with ESMTP id 21A98200035; Tue, 6 Apr 2004 18:39:12 +0200 (CEST) From: Fredrik Thulin To: Klaus Darilion , Alex Bligh Subject: Re: [Sip] RFC3261 & authenticating PROXIES to other proxies & UAS's Date: Tue, 6 Apr 2004 18:39:08 +0200 User-Agent: KMail/1.5.4 Cc: sip@ietf.org References: <2999530066.1081251009@[192.168.100.5]> <4072B245.5070602@pernau.at> In-Reply-To: <4072B245.5070602@pernau.at> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404061839.08824.ft@it.su.se> X-Virus-Scanned: by amavisd-new at su.se X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday 06 April 2004 15.36, Klaus Darilion wrote: > Hi Alex! > > Alex Bligh wrote: > > So: > > 1. Is this in fact not in breach of RFC3261 at all? > > 2. If not, is this a good solution to the problem? > > I think (not sure) another problem is the CSeq - which will be increased > with every request, and if the proxy P! inreases it on behalf of UAC1, > then this might cause problems. Yes, this is even pointed out in RFC3261 #22.3 Proxy-to-User Authentication : If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to increment the CSeq in the new request. However, this would cause the UAC that submitted the original request to discard a response from the UAS, as the CSeq value would be different. > > 3. If not, why not, and what should I do instead? > > SP2 can authenticate your IP address (IP address of P1) and all requests > from your IP address will be billed on your account. To avaid spoffing, > UDP should be disabled on P2 and you should send your requests using TCP. There is wording in section 22.3 saying proxys MUST NOT add things to authorization headers, and that all 407 responses MUST be forwarded upstreams. That is a pity, since I think otherwise the following could solve the problem : P1 could, upon receiving the 407 from P2, start a new transaction with a different branch parameter and added authentication credentials. The request could then be re-submitted to P2. Perhaps someone can explain what was the reason for not permitting proxy to proxy authentication? For example, I would have wanted to do that when someone chooses to redirect incoming calls to their cellular phone. In that case, it is not fair to send a 3xx to the caller and let them pay for the PSTN costs. Instead, I would like for the proxy making the redirection decision to send the request to my PSTN gateway, providing credentials for the user who requested the redirection. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 13:58:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11988 for ; Tue, 6 Apr 2004 13:58:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuok-0006S9-Vd for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 13:57:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36Hum88024613 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 13:56:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAueW-0004c1-DR; Tue, 06 Apr 2004 13:46:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuVk-0002uq-DF for sip@optimus.ietf.org; Tue, 06 Apr 2004 13:37:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09764 for ; Tue, 6 Apr 2004 13:37:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuVh-0005nZ-00 for sip@ietf.org; Tue, 06 Apr 2004 13:37:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAuLN-0004Kr-00 for sip@ietf.org; Tue, 06 Apr 2004 13:26:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAuAV-0002je-01 for sip@ietf.org; Tue, 06 Apr 2004 13:15:23 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAtxO-00055e-I5 for sip@ietf.org; Tue, 06 Apr 2004 13:01:50 -0400 Received: from [192.168.0.11] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id D05E31FDCB; Tue, 6 Apr 2004 18:01:47 +0100 (BST) Date: Tue, 06 Apr 2004 18:01:47 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Fredrik Thulin , Klaus Darilion Cc: sip@ietf.org, Alex Bligh Subject: Re: [Sip] RFC3261 & authenticating PROXIES to other proxies & UAS's Message-ID: <532219491.1081274507@[192.168.0.4]> In-Reply-To: <200404061839.08824.ft@it.su.se> References: <200404061839.08824.ft@it.su.se> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 06 April 2004 18:39 +0200 Fredrik Thulin wrote: > P1 could, upon receiving the 407 from P2, start a new transaction with a > different branch parameter and added authentication credentials. The > request could then be re-submitted to P2. Far neater. And still no need to change UAC, P2 or UAS. Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 14:33:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15456 for ; Tue, 6 Apr 2004 14:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvNa-0002hb-HT for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 14:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36IWwWS010383 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 14:32:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvMy-0001te-Ae; Tue, 06 Apr 2004 14:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAu1S-0004PF-1E for sip@optimus.ietf.org; Tue, 06 Apr 2004 13:06:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06522 for ; Tue, 6 Apr 2004 13:05:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAu1Q-0001bw-00 for sip@ietf.org; Tue, 06 Apr 2004 13:06:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAtgJ-0006x0-00 for sip@ietf.org; Tue, 06 Apr 2004 12:44:12 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BAt4J-0005FK-00 for sip@ietf.org; Tue, 06 Apr 2004 12:04:56 -0400 Received: from [192.168.0.11] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id DEB991FDCB; Tue, 6 Apr 2004 17:04:52 +0100 (BST) Date: Tue, 06 Apr 2004 17:04:52 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Klaus Darilion Cc: sip@ietf.org, Alex Bligh Subject: Re: [Sip] RFC3261 & authenticating PROXIES to other proxies & UAS's Message-ID: <528804690.1081271092@[192.168.0.4]> In-Reply-To: <4072B245.5070602@pernau.at> References: <4072B245.5070602@pernau.at> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 06 April 2004 15:36 +0200 Klaus Darilion wrote: > >> So: >> 1. Is this in fact not in breach of RFC3261 at all? >> 2. If not, is this a good solution to the problem? > > I think (not sure) another problem is the CSeq - which will be increased > with every request, and if the proxy P! inreases it on behalf of UAC1, > then this might cause problems. IE you are saying one has to increment (well, anyway, change) CSeq so that INVITE can be distinguished by P2/UAS from a delayed retransmit, yes? Which is what is meant by: If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to increment the CSeq in the new request. However, this would cause the UAC that submitted the original request to discard a response from the UAS, as the CSeq value would be different. Which means as UAC will be expecting the remainder of the transaction to be carrying the first CSeq number, you would have to rewrite CSeq back to the original CSeq number for the responses, and rewrite the ACK etc. too the other way. Which is starting to get rather dirty. Hmmm... I shall think more on that. Perhaps one option would be for P1, on reception of the 407, to 407 the INVITE *LOCALLY* (i.e. from P1) saying it had a stale nonce, and effectively ignore the request for authorization from P2/UAS. UAC would then retry the INVITE (new CSeq) with a new set of credentials for P1, and P1, now having the challenge from P2/UAS in relation to that CallID, it could insert the the Proxy-Authorization header itself. This does mean that UAC is still going to have to authenticate the INVITE twice. But at least the other problems I mentioned are solved. >> 3. If not, why not, and what should I do instead? > > SP2 can authenticate your IP address (IP address of P1) and all requests > from your IP address will be billed on your account. To avaid spoffing, > UDP should be disabled on P2 and you should send your requests using TCP. Sadly that does not much help (I don't think). If P2 is (say) a PSTN voice gatweay, it doesn't take a lot of imagination to work out how to do sufficient sequence number guessing to open a channel and issue one invite. If the reward is n calls of infinite length to an international premium-rate number, then it's going to be worth trying. Remember once people said "this won't be a problem" for BGP. The only (sensible) solutions I can see other than the above tweaks or relying on TCP and IP address (which I am loath to do as I've seen it go wrong before) are: a) IPSec / TLS - proper transport layer authentication - which is unfortunate as it is relatively CPU intensive; or b) Proxy (on every transaction) simply inserts a header which is identifies the proxy, and then has a hash of some (shared) secret, the proxy name, and To:/From:/CSeq:, which the UA/other proxy then checks is there. But that requires a separate authentication scheme which I was trying to avoid. Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 14:39:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15670 for ; Tue, 6 Apr 2004 14:39:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvSr-000281-Pj for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 14:38:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36IcP9O008175 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 14:38:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvSW-0001lC-L1; Tue, 06 Apr 2004 14:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuzU-0008LT-Jf for sip@optimus.ietf.org; Tue, 06 Apr 2004 14:08:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12778 for ; Tue, 6 Apr 2004 14:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuzS-0002Nu-00 for sip@ietf.org; Tue, 06 Apr 2004 14:08:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAutR-0001MJ-00 for sip@ietf.org; Tue, 06 Apr 2004 14:01:50 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BAukH-0000EP-01 for sip@ietf.org; Tue, 06 Apr 2004 13:52:22 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2004 09:59:29 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i36HpmKj013237; Tue, 6 Apr 2004 10:51:49 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARU49912; Tue, 6 Apr 2004 10:51:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51A3598E-87F3-11D8-BF5F-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Dean Willis , Hisham Khartabil , Allison Mankin , Robert Sparks , John Peterson , Ted Hardie , Gonzalo Camarillo , Rohan Mahy , Alan Johnston , Adam Roach From: Rohan Mahy Date: Tue, 6 Apr 2004 10:53:32 -0700 To: "'sip@ietf.org'" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello All, Please mark your calendars. I'd like to announce a joint interim of the SIP, SIPPING, SIMPLE, and XCON WGs. Nokia has generously agreed to host the event either at their offices near Boston or in a neighboring hotel during the week of May 24. Please reserve the following dates for the WGs that you are interested in: Monday May 24 SIP and SIPPING tentatively 9 am start Tuesday May 25 SIMPLE All day Wednesday May 26 XCON tentatively finish at 4pm so folks can catch flights. (the actual agenda is subject to change, including the dates of various WG meetings). There will be no fee, however please let Hisham and myself know if you are planning to attend by clicking on the Yes or Maybe links below: mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]yes mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]maybe Wireless will be provided. As usual, I will be making T-shirts. If you are interested in buying one, please send your shirt size to me. More details on the agenda and hotel accommodations will be forthcoming shortly. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 16:54:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26706 for ; Tue, 6 Apr 2004 16:54:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAxaJ-0004Io-DO for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 16:54:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36KsFT1016534 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 16:54:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAxa6-00049a-Cj; Tue, 06 Apr 2004 16:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAxZn-00044u-OZ for sip@optimus.ietf.org; Tue, 06 Apr 2004 16:53:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26642 for ; Tue, 6 Apr 2004 16:53:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAxZl-0000Bt-00 for sip@ietf.org; Tue, 06 Apr 2004 16:53:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwjA-0001T7-00 for sip@ietf.org; Tue, 06 Apr 2004 15:59:21 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BAw04-0002yj-00 for sip@ietf.org; Tue, 06 Apr 2004 15:12:44 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 11:21:02 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i36JCAKj013155; Tue, 6 Apr 2004 12:12:11 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA25383; Tue, 6 Apr 2004 12:12:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20040406140611.036ca390@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 14:12:20 -0600 To: Rohan Mahy , "'sip@ietf.org'" From: "James M. Polk" Subject: Re: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26 Cc: Dean Willis , Hisham Khartabil , Allison Mankin , Robert Sparks , John Peterson , Ted Hardie , Gonzalo Camarillo , Rohan Mahy , Alan Johnston , Adam Roach In-Reply-To: <51A3598E-87F3-11D8-BF5F-0003938AF740@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , There were enough open issues surrounding the emergency team/effort that I'm concerned that there might not be enough time to have all of SIP & SIPPING in one day (with respect to how much time we took just during the e2m discussions in Seoul (2.5 hours) - virtually all of which was useful). I otherwise like the ordering of WGs in the tentative scheduling At 10:53 AM 4/6/2004 -0700, Rohan Mahy wrote: >Hello All, > >Please mark your calendars. > >I'd like to announce a joint interim of the SIP, SIPPING, SIMPLE, and >XCON WGs. >Nokia has generously agreed to host the event either at their offices >near Boston or in a neighboring hotel during the week of May 24. > >Please reserve the following dates for the WGs that you are interested >in: >Monday May 24 SIP and SIPPING tentatively 9 am start >Tuesday May 25 SIMPLE All day >Wednesday May 26 XCON tentatively finish at 4pm so folks can catch >flights. >(the actual agenda is subject to change, including the dates of various >WG meetings). > >There will be no fee, however please let Hisham and myself know if you >are planning to attend by clicking on the Yes or Maybe links below: > >mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]yes >mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]maybe > >Wireless will be provided. As usual, I will be making T-shirts. If you >are interested in buying one, please send your shirt size to me. > >More details on the agenda and hotel accommodations will be forthcoming >shortly. > >thanks, >-rohan > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 19:06:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08493 for ; Tue, 6 Apr 2004 19:06:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAze4-00030k-CM for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 19:06:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36N6GjL011575 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 19:06:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzdq-0002tA-BN; Tue, 06 Apr 2004 19:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzd5-0002pj-Ml for sip@optimus.ietf.org; Tue, 06 Apr 2004 19:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08418 for ; Tue, 6 Apr 2004 19:05:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAzd2-00003N-00 for sip@ietf.org; Tue, 06 Apr 2004 19:05:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAya1-00014M-00 for sip@ietf.org; Tue, 06 Apr 2004 17:58:03 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1BAxr8-0001xd-00 for sip@ietf.org; Tue, 06 Apr 2004 17:11:38 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i36LAp315300; Tue, 6 Apr 2004 16:10:51 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Apr 2004 16:10:52 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF579171@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James M. Polk'" , Rohan Mahy , "'sip@ietf.org'" Cc: Dean Willis , Hisham Khartabil , Allison Mankin , Robert Sparks , John Peterson , Ted Hardie , Gonzalo Camarillo , Rohan Mahy , Alan Johnston , Adam Roach Subject: RE: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26 Date: Tue, 6 Apr 2004 16:10:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41C1B.A1EE0784" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41C1B.A1EE0784 Content-Type: text/plain I also hate to say that it does look like a tight schedule given current issues and past history of interim meetings. Previous Interims for SIP/SIPPING were 2 full days and SIMPLE last year was also 2 full days. I don't think anyone would suggest the time was not well utilized at any of those meetings. Since the start day has been moved to Monday (rather than the initial proposal of Tuesday), is there a possibility of continuing into Thursday? Mary. -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Tuesday, April 06, 2004 3:12 PM To: Rohan Mahy; 'sip@ietf.org' Cc: Dean Willis; Hisham Khartabil; Allison Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; Rohan Mahy; Alan Johnston; Adam Roach Subject: Re: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26 There were enough open issues surrounding the emergency team/effort that I'm concerned that there might not be enough time to have all of SIP & SIPPING in one day (with respect to how much time we took just during the e2m discussions in Seoul (2.5 hours) - virtually all of which was useful). I otherwise like the ordering of WGs in the tentative scheduling At 10:53 AM 4/6/2004 -0700, Rohan Mahy wrote: >Hello All, > >Please mark your calendars. > >I'd like to announce a joint interim of the SIP, SIPPING, SIMPLE, and >XCON WGs. Nokia has generously agreed to host the event either at their >offices near Boston or in a neighboring hotel during the week of May >24. > >Please reserve the following dates for the WGs that you are interested >in: >Monday May 24 SIP and SIPPING tentatively 9 am start >Tuesday May 25 SIMPLE All day >Wednesday May 26 XCON tentatively finish at 4pm so folks can catch >flights. (the actual agenda is subject to change, including the dates >of various WG meetings). > >There will be no fee, however please let Hisham and myself know if you >are planning to attend by clicking on the Yes or Maybe links below: > >mailto:rohan@cisco.com? >Cc=hisham.khartabil@nokia.com&Subject=[interim]yes >mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]maybe > >Wireless will be provided. As usual, I will be making T-shirts. If you >are interested in buying one, please send your shirt size to me. > >More details on the agenda and hotel accommodations will be forthcoming >shortly. > >thanks, >-rohan > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C41C1B.A1EE0784 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26

I also hate to say that it does look like a tight = schedule given current issues and past history of interim = meetings.  Previous Interims for SIP/SIPPING were 2 full days and = SIMPLE last year was also 2 full days. I don't think anyone would = suggest the time was not well utilized at any of those meetings.  = Since the start day has been moved to Monday (rather than the initial = proposal of Tuesday), is there a possibility of continuing into = Thursday?

Mary.

-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Tuesday, April 06, 2004 3:12 PM
To: Rohan Mahy; 'sip@ietf.org'
Cc: Dean Willis; Hisham Khartabil; Allison Mankin; = Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; Rohan = Mahy; Alan Johnston; Adam Roach

Subject: Re: [Sip] Joint Interim Meeting Mon May 24 - = Wed May 26


There were enough open issues surrounding the = emergency team/effort that
I'm concerned that there might not be enough time to = have all of SIP &
SIPPING in one day (with respect to how much time we = took just during the
e2m discussions in Seoul (2.5 hours) - virtually all = of which was useful).

I otherwise like the ordering of WGs in the tentative = scheduling

At 10:53 AM 4/6/2004 -0700, Rohan Mahy wrote:
>Hello All,
>
>Please mark your calendars.
>
>I'd like to announce a joint interim of the SIP, = SIPPING, SIMPLE, and
>XCON WGs. Nokia has generously agreed to host = the event either at their
>offices near Boston or in a neighboring hotel = during the week of May
>24.
>
>Please reserve the following dates for the WGs = that you are interested
>in:
>Monday May 24 SIP and SIPPING  tentatively = 9 am start
>Tuesday May 25 SIMPLE   All day
>Wednesday May 26 XCON  tentatively finish = at 4pm so folks can catch
>flights. (the actual agenda is subject to = change, including the dates
>of various WG meetings).
>
>There will be no fee, however please let Hisham = and myself know if you
>are planning to attend by clicking on the Yes or = Maybe links below:
>
>mailto:rohan@cisco.com?
>Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes<= /FONT>
>mailto:rohan@cisco.com? = Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe
>
>Wireless will be provided. As usual, I will be = making T-shirts.  If you
>are interested in buying one, please send your = shirt size to me.
>
>More details on the agenda and hotel = accommodations will be forthcoming
>shortly.
>
>thanks,
>-rohan
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP = Protocol
>Use sip-implementors@cs.columbia.edu for = questions on current sip Use
>sipping@ietf.org for new developments on the = application of sip


cheers,
James

          &nb= sp;           &nb= sp;         = *******************
          &nb= sp;      Truth is not to be argued... it is to = be presented


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP = 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_01C41C1B.A1EE0784-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 22:21:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28459 for ; Tue, 6 Apr 2004 22:21:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2h1-0002ar-Gb for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 22:21:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i372LVFc009968 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 22:21:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2fc-0001us-0o; Tue, 06 Apr 2004 22:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2eu-0001ns-56 for sip@optimus.ietf.org; Tue, 06 Apr 2004 22:19:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27902 for ; Tue, 6 Apr 2004 22:19:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2eq-00001w-00 for sip@ietf.org; Tue, 06 Apr 2004 22:19:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB29p-0002tx-00 for sip@ietf.org; Tue, 06 Apr 2004 21:47:14 -0400 Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 1BB18k-0003j6-00 for sip@ietf.org; Tue, 06 Apr 2004 20:42:02 -0400 Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id i370ffj08491; Wed, 7 Apr 2004 08:41:42 +0800 (CST) Received: from pekw096e.cn001.siemens.net (pekw096e.cn001.siemens.net [140.231.51.134]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id i370fk806034; Wed, 7 Apr 2004 08:41:46 +0800 (CST) Received: by pekw096e with Internet Mail Service (5.5.2653.19) id <2M1ZCLYS>; Wed, 7 Apr 2004 08:41:55 +0800 Message-ID: <31F31018FE2DC941A70BD30477510B0C19D644@biscm02> From: "Hu Yijun,BISC R&D SA(BJ)" To: "'Umesh Sharma'" , "Hu Yijun,BISC R&D SA(BJ)" , sip@ietf.org Subject: RE: [SIP] Sending 2xx responses to INVITE Date: Wed, 7 Apr 2004 08:46:38 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=AWL,ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , hello, Umesh The more detailed statement to the sever transaction is described in ch17.2.1: " If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU. The server transaction MUST then transition to the "Terminated" state. While in the "Proceeding" state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response MUST be passed to the transport layer for transmission, and the state machine MUST enter the "Completed" state. For unreliable transports, timer G is set to fire in T1 seconds, and is not set to fire for reliable transports." BR hu yijun >-----Original Message----- >From: Umesh Sharma [mailto:umesh_sharma@persistent.co.in] >Sent: Tuesday, April 06, 2004 8:40 PM >To: Hu Yijun,BISC R&D SA(BJ); sip@ietf.org >Subject: RE: [SIP] Sending 2xx responses to INVITE > > >hi Hu > >I re-read the section 17.1.1.1, it looks to me a general >statement which >does not >distinguishes between non-2xx final & 2xx response. > >-regards >umesh > >-----Original Message----- >From: Hu Yijun,BISC R&D SA(BJ) [mailto:yijun.hu@siemens.com] >Sent: Tuesday, April 06, 2004 6:32 AM >To: 'Umesh Sharma'; Bilajbegovic Damir; ??????????? ????? ??????????; >sip@ietf.org >Subject: RE: [SIP] Sending 2xx responses to INVITE > > >Hello, > >Please see my comments below. > >regards >hu yijun > >>-----Original Message----- >>From: Umesh Sharma [mailto:umesh_sharma@persistent.co.in] >>Sent: Monday, April 05, 2004 8:06 PM >>To: Bilajbegovic Damir; ??????????? ????? ??????????; sip@ietf.org >>Subject: RE: [SIP] Sending 2xx responses to INVITE >> >> >>Hi >> >>>>In what way does TU send retransmissions of 2xx responses to >>INVITE? What >>is >>>>the interval between these retransmissions? >> >>To quote from rfc 3261 directly: >> >>"The 2xx response is passed to the transport with an >> interval that starts at T1 seconds and doubles for each >> retransmission until it reaches T2 seconds (T1 and T2 are defined in >> Section 17). Response retransmissions cease when an ACK request for >> the response is received. This is independent of whatever transport >> protocols are used to send the response." >> >>>>How many retansmissions can be sent? >> >>"If the server retransmits the 2xx response for 64*T1 seconds without >> receiving an ACK, the dialog is confirmed, but the session SHOULD be >> terminated." >> >>In 17.1.1.1 >> >>"Eventually, the server transaction decides >> to send a final response. For unreliable transports, that response >> is retransmitted periodically, and for reliable transports, it is >> sent once." >> >>I have a question too here, Now this line above seems to >>contradict this >>paragraph in >>13.3.1.4. >> >> "Since 2xx is retransmitted end-to-end, there may be >hops between >> UAS and UAC that are UDP. To ensure reliable delivery across >> these hops, the response is retransmitted periodically >>even if the >> transport at the UAS is reliable." >> >>Am I reading this incorrectly? > >The description of ch 17.1.1.1 was foucs on the retransmission of the >non-2xx final response to INVITE, which were administered by >the transaction >layer. Those responses are delivered hop-by-hop. So that, for >a certain hop, >which uses reliable transport, the non-2xx final response is >sent only once. > >However, the retransmission of the 2XX to INVITE was >administered by the >transaction user (TU). It MUST comply with the ch13.3.1.4 of >rfc3261: "the >response is retransmitted periodically even if the transport >at the UAS is >reliable". > >> >>regards >>-umesh >>-----Original Message----- >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of >>Bilajbegovic Damir >>Sent: Monday, April 05, 2004 4:18 PM >>To: ??????????? ????? ??????????; sip@ietf.org >>Subject: RE: [SIP] Sending 2xx responses to INVITE >> >> >>Hi, >> Not sure but I think 1st Invite and 7 retransmission. >>Intervals are >>increasing by double. >> Hope I helped. >> Bilaj >> >>-----Original Message----- >>From: galactionov@loniis.ru [mailto:galactionov@loniis.ru] >>Sent: Monday, April 05, 2004 12:34 PM >>To: sip@ietf.org >>Subject: [SIP] Sending 2xx responses to INVITE >> >> >>Dear SIP experts, >> >>I have following questions (maybe already discussed on the >>list in the past) >>regarding the sending of 2xx responses to INVITE. >> >>In what way does TU send retransmissions of 2xx responses to >>INVITE? What is >>the interval between these retransmissions? How many >>retansmissions can be >>sent? >> >>Best regards >>Anton >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip Use >>sipping@ietf.org for new developments on the application of sip >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 6 22:22:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28476 for ; Tue, 6 Apr 2004 22:22:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2h1-0002au-Gj for sip-archive@odin.ietf.org; Tue, 06 Apr 2004 22:21:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i372LVC9009967 for sip-archive@odin.ietf.org; Tue, 6 Apr 2004 22:21:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2fe-0001vc-64; Tue, 06 Apr 2004 22:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2ez-0001oM-LL for sip@optimus.ietf.org; Tue, 06 Apr 2004 22:19:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27920 for ; Tue, 6 Apr 2004 22:19:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2ew-00003D-00 for sip@ietf.org; Tue, 06 Apr 2004 22:19:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB2AH-0002zQ-00 for sip@ietf.org; Tue, 06 Apr 2004 21:47:44 -0400 Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BB1AK-0003o4-00 for sip@ietf.org; Tue, 06 Apr 2004 20:43:40 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i370h1iK019778 for ; Tue, 6 Apr 2004 19:43:11 -0500 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (6.5.032) id 405DCB76005173CD; Tue, 6 Apr 2004 20:42:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41C39.4B701BB4" Subject: RE: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26 Date: Tue, 6 Apr 2004 19:43:07 -0500 Message-ID: <28F05913385EAC43AF019413F674A01708145A5C@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcK9xl10z4GozqQ1SEWefKTdWUZQADMZrg From: "Dolly, Martin C, ALABS" To: "Mary Barnes" , "James M. Polk" , "Rohan Mahy" , Cc: "Dean Willis" , "Hisham Khartabil" , "Allison Mankin" , "Robert Sparks" , "John Peterson" , "Ted Hardie" , "Gonzalo Camarillo" , "Rohan Mahy" , "Alan Johnston" , "Adam Roach" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C41C39.4B701BB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that 2 days for SIP/SIPPING would be more approriate =20 Cheers, =20 Martin -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Mary Barnes Sent: Tuesday, April 06, 2004 5:11 PM To: 'James M. Polk'; Rohan Mahy; 'sip@ietf.org' Cc: Dean Willis; Hisham Khartabil; Allison Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; Rohan Mahy; Alan Johnston; Adam Roach Subject: RE: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26 I also hate to say that it does look like a tight schedule given current issues and past history of interim meetings. Previous Interims for SIP/SIPPING were 2 full days and SIMPLE last year was also 2 full days. I don't think anyone would suggest the time was not well utilized at any of those meetings. Since the start day has been moved to Monday (rather than the initial proposal of Tuesday), is there a possibility of continuing into Thursday?=20 Mary.=20 -----Original Message-----=20 From: James M. Polk [ mailto:jmpolk@cisco.com]=20 Sent: Tuesday, April 06, 2004 3:12 PM=20 To: Rohan Mahy; 'sip@ietf.org'=20 Cc: Dean Willis; Hisham Khartabil; Allison Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; Rohan Mahy; Alan Johnston; Adam Roach Subject: Re: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26=20 There were enough open issues surrounding the emergency team/effort that I'm concerned that there might not be enough time to have all of SIP &=20 SIPPING in one day (with respect to how much time we took just during the=20 e2m discussions in Seoul (2.5 hours) - virtually all of which was useful).=20 I otherwise like the ordering of WGs in the tentative scheduling=20 At 10:53 AM 4/6/2004 -0700, Rohan Mahy wrote:=20 >Hello All,=20 >=20 >Please mark your calendars.=20 >=20 >I'd like to announce a joint interim of the SIP, SIPPING, SIMPLE, and=20 >XCON WGs. Nokia has generously agreed to host the event either at their >offices near Boston or in a neighboring hotel during the week of May=20 >24.=20 >=20 >Please reserve the following dates for the WGs that you are interested=20 >in:=20 >Monday May 24 SIP and SIPPING tentatively 9 am start=20 >Tuesday May 25 SIMPLE All day=20 >Wednesday May 26 XCON tentatively finish at 4pm so folks can catch=20 >flights. (the actual agenda is subject to change, including the dates=20 >of various WG meetings).=20 >=20 >There will be no fee, however please let Hisham and myself know if you=20 >are planning to attend by clicking on the Yes or Maybe links below:=20 >=20 > mailto:rohan@cisco.com?=20 >Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes=20 > mailto:rohan@cisco.com? Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe=20 >=20 >Wireless will be provided. As usual, I will be making T-shirts. If you >are interested in buying one, please send your shirt size to me.=20 >=20 >More details on the agenda and hotel accommodations will be forthcoming >shortly.=20 >=20 >thanks,=20 >-rohan=20 >=20 >=20 >_______________________________________________=20 >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 >This list is for NEW development of the core SIP Protocol=20 >Use sip-implementors@cs.columbia.edu for questions on current sip Use=20 >sipping@ietf.org for new developments on the application of sip=20 cheers,=20 James=20 *******************=20 Truth is not to be argued... it is to be presented=20 _______________________________________________=20 Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol=20 Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C41C39.4B701BB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] Joint Interim Meeting Mon May 24 - Wed May 26
I=20 believe that 2 days for SIP/SIPPING would be more = approriate
 
Cheers,
 
Martin
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Mary = Barnes
Sent:=20 Tuesday, April 06, 2004 5:11 PM
To: 'James M. Polk'; Rohan = Mahy;=20 'sip@ietf.org'
Cc: Dean Willis; Hisham Khartabil; Allison = Mankin;=20 Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; Rohan = Mahy; Alan=20 Johnston; Adam Roach
Subject: RE: [Sip] Joint Interim = Meeting Mon=20 May 24 - Wed May 26

I also hate to say that it does look like a tight = schedule=20 given current issues and past history of interim meetings.  = Previous=20 Interims for SIP/SIPPING were 2 full days and SIMPLE last year was = also 2 full=20 days. I don't think anyone would suggest the time was not well = utilized at any=20 of those meetings.  Since the start day has been moved to Monday = (rather=20 than the initial proposal of Tuesday), is there a possibility of = continuing=20 into Thursday?

Mary.

-----Original Message-----
From: James=20 M. Polk [mailto:jmpolk@cisco.com]=20
Sent: Tuesday, April 06, 2004 3:12 PM =
To: Rohan Mahy; 'sip@ietf.org'
Cc: = Dean Willis;=20 Hisham Khartabil; Allison Mankin; Robert Sparks; John Peterson; Ted = Hardie;=20 Gonzalo Camarillo; Rohan Mahy; Alan Johnston; Adam Roach

Subject: Re: [Sip] Joint Interim Meeting Mon May 24 = - Wed May=20 26


There were enough open issues surrounding the = emergency=20 team/effort that
I'm concerned that there = might not be=20 enough time to have all of SIP &
SIPPING = in one=20 day (with respect to how much time we took just during the =
e2m discussions in Seoul (2.5 hours) - virtually all of which = was=20 useful).

I otherwise like the ordering of WGs in the = tentative=20 scheduling

At 10:53 AM 4/6/2004 -0700, Rohan Mahy wrote: =
>Hello All,
> =
>Please mark your calendars.
>=20
>I'd like to announce a joint interim of the = SIP, SIPPING,=20 SIMPLE, and
>XCON WGs. Nokia has = generously agreed=20 to host the event either at their
>offices near=20 Boston or in a neighboring hotel during the week of May =
>24.
>
>Please=20 reserve the following dates for the WGs that you are interested =
>in:
>Monday May 24 = SIP and=20 SIPPING  tentatively 9 am start
>Tuesday May=20 25 SIMPLE   All day
>Wednesday = May 26=20 XCON  tentatively finish at 4pm so folks can catch =
>flights. (the actual agenda is subject to change, = including the=20 dates
>of various WG meetings). =
>
>There will be no fee, = however please=20 let Hisham and myself know if you
>are = planning to=20 attend by clicking on the Yes or Maybe links below:
>
>mailto:rohan@cisco.com? =
>Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes=20
>mailto:rohan@cisco.com?=20 Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe =
>
>Wireless will be provided. = As usual, I=20 will be making T-shirts.  If you
>are=20 interested in buying one, please send your shirt size to me. =
>
>More details on the agenda = and hotel=20 accommodations will be forthcoming
>shortly.=20
>
>thanks, =
>-rohan
>
>
>_______________________________________________ =
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip =
>This list is for NEW development of the core SIP = Protocol=20
>Use sip-implementors@cs.columbia.edu for = questions on=20 current sip Use
>sipping@ietf.org for new = developments on the application of sip


cheers,
James

          &nbs= p;            = ;        =20 *******************
          &nbs= p;     =20 Truth is not to be argued... it is to be presented


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

------_=_NextPart_001_01C41C39.4B701BB4-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 7 02:37:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16518 for ; Wed, 7 Apr 2004 02:37:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB6fo-00032d-O0 for sip-archive@odin.ietf.org; Wed, 07 Apr 2004 02:36:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i376aWSM011675 for sip-archive@odin.ietf.org; Wed, 7 Apr 2004 02:36:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB6fS-0002vU-KM; Wed, 07 Apr 2004 02:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB6f2-0002pa-77 for sip@optimus.ietf.org; Wed, 07 Apr 2004 02:35:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16197 for ; Wed, 7 Apr 2004 02:35:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB6ey-0004c5-00 for sip@ietf.org; Wed, 07 Apr 2004 02:35:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB5hh-0003xm-00 for sip@ietf.org; Wed, 07 Apr 2004 01:34:26 -0400 Received: from bay16-f44.bay16.hotmail.com ([65.54.186.94] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BB4UM-0003m4-00 for sip@ietf.org; Wed, 07 Apr 2004 00:16:34 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Apr 2004 21:14:26 -0700 Received: from 210.12.42.5 by by16fd.bay16.hotmail.msn.com with HTTP; Wed, 07 Apr 2004 04:14:26 GMT X-Originating-IP: [210.12.42.5] X-Originating-Email: [hongchuan_yuan@hotmail.com] X-Sender: hongchuan_yuan@hotmail.com From: "yuan hongchuan" To: sip@ietf.org Date: Wed, 07 Apr 2004 04:14:26 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 07 Apr 2004 04:14:26.0450 (UTC) FILETIME=[D0872720:01C41C56] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA16198 Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hello,all. i will kick off my master study. the research area is about sip in 3G mobile network. anyone can give some advices about it. Give me some direction. thanks. _________________________________________________________________ =D3=EB=C1=AA=BB=FA=B5=C4=C5=F3=D3=D1=BD=F8=D0=D0=BD=BB=C1=F7=A3=AC=C7=EB=CA= =B9=D3=C3 MSN Messenger: http://messenger.msn.com/cn =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 7 04:57:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27667 for ; Wed, 7 Apr 2004 04:57:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8sG-0002EI-9M for sip-archive@odin.ietf.org; Wed, 07 Apr 2004 04:57:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i378vW0X008370 for sip-archive@odin.ietf.org; Wed, 7 Apr 2004 04:57:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8ro-0001mf-Dd; Wed, 07 Apr 2004 04:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbNn-0006SX-Ca for sip@optimus.ietf.org; Mon, 05 Apr 2004 17:11:51 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10108 for ; Mon, 5 Apr 2004 17:11:47 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAbNJ-0006Il-22; Mon, 05 Apr 2004 17:11:21 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 05 Apr 2004 17:11:21 -0400 Subject: [Sip] Last Call: 'Session Initiation Protocol (SIP) Extension for Event State Publication' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Session Initiation Protocol (SIP) Extension for Event State Publication ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-03.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 7 04:58:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27672 for ; Wed, 7 Apr 2004 04:58:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8sG-0002EJ-9P for sip-archive@odin.ietf.org; Wed, 07 Apr 2004 04:57:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i378vW9h008369 for sip-archive@odin.ietf.org; Wed, 7 Apr 2004 04:57:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8rp-0001nD-OC; Wed, 07 Apr 2004 04:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbOq-0006gF-Bp for sip@optimus.ietf.org; Mon, 05 Apr 2004 17:12:56 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10111 for ; Mon, 5 Apr 2004 17:12:52 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAbOM-0006V4-1M; Mon, 05 Apr 2004 17:12:26 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 05 Apr 2004 17:12:26 -0400 Subject: [Sip] Last Call: 'S/MIME AES Requirement for SIP' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'S/MIME AES Requirement for SIP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-01.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 7 05:50:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27668 for ; Wed, 7 Apr 2004 04:57:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8sG-0002EK-9k for sip-archive@odin.ietf.org; Wed, 07 Apr 2004 04:57:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i378vW5X008371 for sip-archive@odin.ietf.org; Wed, 7 Apr 2004 04:57:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8rm-0001ll-NK; Wed, 07 Apr 2004 04:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZKq-0006aT-Ji for sip@optimus.ietf.org; Mon, 05 Apr 2004 15:00:40 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24692 for ; Mon, 5 Apr 2004 15:00:36 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAZKM-0004tV-5x; Mon, 05 Apr 2004 15:00:10 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 05 Apr 2004 15:00:10 -0400 Subject: [Sip] Last Call: 'The Session Inititation Protocol (SIP) 'Join' Header' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'The Session Inititation Protocol (SIP) 'Join' Header ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-join-03.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 7 14:04:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21976 for ; Wed, 7 Apr 2004 14:04:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHOv-0001y1-4m for sip-archive@odin.ietf.org; Wed, 07 Apr 2004 14:03:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37I3nLi007560 for sip-archive@odin.ietf.org; Wed, 7 Apr 2004 14:03:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHOO-0001aQ-7f; Wed, 07 Apr 2004 14:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHLi-0006nr-PB for sip@optimus.ietf.org; Wed, 07 Apr 2004 14:00:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21216 for ; Wed, 7 Apr 2004 14:00:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHLg-0006ch-00 for sip@ietf.org; Wed, 07 Apr 2004 14:00:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGZJ-0006Ha-00 for sip@ietf.org; Wed, 07 Apr 2004 13:10:30 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BBFBs-0003gI-00 for sip@ietf.org; Wed, 07 Apr 2004 11:42:12 -0400 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id D56661FE67; Wed, 7 Apr 2004 16:42:07 +0100 (BST) Date: Wed, 07 Apr 2004 16:41:44 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Fredrik Thulin , Klaus Darilion Cc: sip@ietf.org, Alex Bligh Subject: Re: [Sip] RFC3261 & authenticating PROXIES to other proxies & UAS's Message-ID: <3104625164.1081356104@[192.168.100.5]> In-Reply-To: <200404061839.08824.ft@it.su.se> References: <2999530066.1081251009@[192.168.100.5]> <4072B245.5070602@pernau.at> <200404061839.08824.ft@it.su.se> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 06 April 2004 18:39 +0200 Fredrik Thulin wrote: > There is wording in section 22.3 saying proxys MUST NOT add things to > authorization headers, and that all 407 responses MUST be forwarded > upstreams. That is a pity, since I think otherwise the following could > solve the problem : > > P1 could, upon receiving the 407 from P2, start a new transaction with a > different branch parameter and added authentication credentials. The > request could then be re-submitted to P2. If I read things right, the branch parameter is going to be different /anyway/ for a proxy with loop detection: 16.6 Request Forwarding [Section 8] ... If a proxy wishes to detect loops, the "branch" parameter it supplies MUST depend on all information affecting processing of a request, including the incoming Request-URI and any header fields affecting the request's admission or routing. This is necessary to distinguish looped requests from requests whose routing parameters have changed before returning to this server. On this basis, if the proxy retries the INVITE with the same CSeq, what is the problem? IE how is this any different from spiraling (which is allowed)? Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 7 14:19:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23271 for ; Wed, 7 Apr 2004 14:19:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHdr-0000rY-S9 for sip-archive@odin.ietf.org; Wed, 07 Apr 2004 14:19:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37IJF5L003293 for sip-archive@odin.ietf.org; Wed, 7 Apr 2004 14:19:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHde-0000Yj-6J; Wed, 07 Apr 2004 14:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHcf-0000FQ-4G for sip@optimus.ietf.org; Wed, 07 Apr 2004 14:18:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22858 for ; Wed, 7 Apr 2004 14:17:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHcc-0001JA-00 for sip@ietf.org; Wed, 07 Apr 2004 14:17:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGnS-0000zY-00 for sip@ietf.org; Wed, 07 Apr 2004 13:25:07 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BBFex-00077n-00 for sip@ietf.org; Wed, 07 Apr 2004 12:12:16 -0400 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B8D0E1FDCB; Wed, 7 Apr 2004 17:12:15 +0100 (BST) Date: Wed, 07 Apr 2004 17:11:52 +0100 From: Alex Bligh Reply-To: Alex Bligh To: sip@ietf.org Cc: Alex Bligh Message-ID: <3106433605.1081357912@[192.168.100.5]> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Unknown via-params Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit SHOULD / MUST SIP devices ignore/strip/reject via-params that are not defined by RFC3261? IE if I build a proxy which inserts a proprietary via-param (so for instance inserts a Via line like): Via: SIP/2.0/UDP host.user.com:4321; maddr=224.1.2.3;branch=f4fs34.1;myparam=foobar can I guarantee that compliant proxies & UAs will ignore (rather than reject, or, in the case of a proxy strip) the myparam=foobar? Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 7 22:36:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10089 for ; Wed, 7 Apr 2004 22:36:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPOr-0007Ce-Pi for sip-archive@odin.ietf.org; Wed, 07 Apr 2004 22:36:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i382aHbP027592 for sip-archive@odin.ietf.org; Wed, 7 Apr 2004 22:36:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPOf-000706-4a; Wed, 07 Apr 2004 22:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPO4-0006xD-S9 for sip@optimus.ietf.org; Wed, 07 Apr 2004 22:35:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09978 for ; Wed, 7 Apr 2004 22:35:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBPO1-0005G2-00 for sip@ietf.org; Wed, 07 Apr 2004 22:35:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBO3t-0001Qx-00 for sip@ietf.org; Wed, 07 Apr 2004 21:10:34 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1BBMAd-0003NP-00 for sip@ietf.org; Wed, 07 Apr 2004 19:09:23 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4]) by broadsoft.com (8.12.11/8.12.9) with SMTP id i37N9IH6068212 for ; Wed, 7 Apr 2004 19:09:19 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Unknown via-params Date: Wed, 7 Apr 2004 19:13:45 -0400 Message-ID: <009b01c41cf5$fa7f0490$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3106433605.1081357912@[192.168.100.5]> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > SHOULD / MUST SIP devices ignore/strip/reject > via-params that are not defined by RFC3261? The receiver MUST echo them back. However extra Via parameters were not part of rfc2543. Thus some older devices might strip the extra parameters or reject the message. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Apr 8 12:54:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03035 for ; Thu, 8 Apr 2004 12:54:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBcnF-0001Y1-43 for sip-archive@odin.ietf.org; Thu, 08 Apr 2004 12:54:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38GsLjQ005949 for sip-archive@odin.ietf.org; Thu, 8 Apr 2004 12:54:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBcm1-0000lv-BM; Thu, 08 Apr 2004 12:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBclA-0000hn-1M for sip@optimus.ietf.org; Thu, 08 Apr 2004 12:52:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02927 for ; Thu, 8 Apr 2004 12:52:08 -0400 (EDT) From: Viktor.Bekesi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBcl7-0007DX-00 for sip@ietf.org; Thu, 08 Apr 2004 12:52:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBaAJ-00051M-00 for sip@ietf.org; Thu, 08 Apr 2004 10:06:01 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BBXp8-0004aJ-00 for sip@ietf.org; Thu, 08 Apr 2004 07:35:58 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38BZu804664 for ; Thu, 8 Apr 2004 14:35:56 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 14:35:55 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i38BZt0P031649 for ; Thu, 8 Apr 2004 14:35:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 009xPXv8; Thu, 08 Apr 2004 14:35:55 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38BYms21559 for ; Thu, 8 Apr 2004 14:34:48 +0300 (EET DST) Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Apr 2004 14:28:26 +0300 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Apr 2004 14:28:27 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Caller-Preferences: Representing negated Boolean feature tags Date: Thu, 8 Apr 2004 13:28:24 +0200 Message-ID: thread-topic: [Sip] Caller-Preferences: Representing negated Boolean feature tags thread-index: AcQbyrEYPgB2CpcHRb+gH9kTJKJfzgBkc/WA To: X-OriginalArrivalTime: 08 Apr 2004 11:28:27.0059 (UTC) FILETIME=[9C5A8030:01C41D5C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, I am implementing SIP Caller-Preferences related functionalities, and = there is one thing that is not clear for me after reading the relevant = drafts and rfcs: Does it make sense to negate a Boolean type feature = tag? like the audio in the example: (& (! (audio=3DTRUE)) (video=3DTRUE) (sip.mobility=3Dfixed) (message=3DTRUE) (| (sip.methods=3DINVITE) (sip.methods=3DOPTIONS) = (sip.methods=3DBYE) (sip.methods=3DCANCEL) (sip.methods=3DACK)) (| (sip.schemes=3Dsip) (sip.schemes=3Dhttp))) If yes, then the next question arises: How can I represent negated = Boolean type feature tags in SIP header parameters?=20 According to draft-ietf-sip-callerprefs-10,=20 (& (sip.mobility=3Dfixed) (| (! (sip.events=3Dpresence)) (sip.events=3Dwinfo)) (| (language=3Den) (language=3Dde)) (sip.description=3D"PC") (sip.newparam=3DTRUE) (rangeparam=3D-4..5125/1000)) this declaration can be turned into this representation: = Accept-Contact:*;mobility=3D"fixed";events=3D"!presence,winfo";language=3D= "en,de" ;description=3D"";+sip.newparam;+rangeparam=3D"#-4:+5.125" (I reversed the order as it was in the document) Here the events are negated and that is indicated by the exclamation = mark at the beginning of the event-tag-value. Boolean type tags are = turned into flag parameters with no value. So then how can the very = first example represented? Thanks in advance, best regards:=20 Viktor Bekesi Nokia Networks +36-20 9849-202 =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Apr 8 13:41:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07601 for ; Thu, 8 Apr 2004 13:41:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdWp-0005MC-P3 for sip-archive@odin.ietf.org; Thu, 08 Apr 2004 13:41:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38HfR6P020592 for sip-archive@odin.ietf.org; Thu, 8 Apr 2004 13:41:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdWQ-0005H7-Si; Thu, 08 Apr 2004 13:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdW7-0005EJ-8e for sip@optimus.ietf.org; Thu, 08 Apr 2004 13:40:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07378 for ; Thu, 8 Apr 2004 13:40:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBdW3-0004nK-00 for sip@ietf.org; Thu, 08 Apr 2004 13:40:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBb2U-0003m6-00 for sip@ietf.org; Thu, 08 Apr 2004 11:01:59 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BBYyZ-0004An-00 for sip@ietf.org; Thu, 08 Apr 2004 08:49:48 -0400 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 058431FDCB; Thu, 8 Apr 2004 13:49:43 +0100 (BST) Date: Thu, 08 Apr 2004 13:49:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: sip@ietf.org Cc: Alex Bligh Message-ID: <3180678573.1081432157@[192.168.100.5]> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] RFC3261 and authenticating PROXIES to other proxies & UAS - 2 possible solutions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I am still trying to work out how one might authenticate that a call has been transmitted by a proxy that the headers claimed transmitted it. SIP provides facilities (in protocol) for proxies and UAS's to determine that a call originated at a UAC with credentials, but no manner of determining whether the call passed through a proxy with credentials. Whilst in some circumstances this can be handled with network layer or transport layer security, (a) this requires support on a hop by hop basis from the proxy downstream, (b) the overhead may be substantial, and (c) it is somewhat inconsistent that SIP supports this type of authentication for the UAC but not proxies. I've come up with 2 mechanisms to provide the support - one I posted earlier (which requires only a change on the proxy with credentials) and goes into the "Despite being against RFC3261, I can't see what this would break" category, and the second (which requires a change both at the proxy supplying credentials and at the server authenticating them) certainly breaks nothing, but is less functional. I'd appreciate comments, particularly on what the first mechanism breaks. I (now) know that it is (today) against various bits of RFC3261. But I cannot see what in practice it would break. And as a couple of people (on and off list) have pointed out, it would be very useful (even for reasons I hadn't thought of). BACKGROUND ========== The (general) problem I am trying to solve looks like this: UAC <-----/\/\/\/\/---> P1 <--/\/--> P2 <---> UAS => PSTN (CPE) (proxy) (proxy) (media gateway) P2 may or may not be present. Let us assume UAC and P1 are very distant, and P1 & either P2 or UAS are sufficiently distant that host security is impractical without adding some additional layer (ipsec, tls etc.). UAC is CPE on a site of a customer of SP1, who operates P1. UAS is a media gateway, and P2 a (possibly) intervening proxy, operated by SP2. Let us further assume that UAC registers to P1, and that P1 has already authenticated UAC, and that any INVITE passed through P1 has already been authenticated as coming from UAC and been authorized by P1 according to SP1's local policy, prior to being forwarded to P2. Let us further assume that it is the local policy of SP1 that any such authorized calls it passes to SP2 would be authorized by SP1. So for instance SP2 is a VoIP termination provider, and SP1 a VoIP service provider. SP2 wishes to authenticate & authorize calls made to UAS. It uses some form of authentication. What it in essence is trying to authenticate is that the call actually came from P1, not that the call actually came from UAC. This could either be done at P2, or at UAS. I have two mechanisms of doing this MECHANISM (AB)USING HTTP DIGEST AUTHENTICATION ============================================== As per previous email, (ab)use HTTP digest authentication so that the proxy retries the Invite with the same CSeq but with a different branch parameter. This seems to me indistinguishable from a spiraling scenario where the proxy concerned happens to call the same Request-URI twice but other information in the message header (in this case authentication) that may be used to route the call has changed. As such, I can't see what it would break, and it has the major advantage it works with all existing (challenging) UA's & proxies, and that being challenge-response, it is more secure than other mechanisms. But, for the sake of argument ALTERNATIVE MECHANISM USING vauth Via-Parameter =============================================== This mechanism introduces a new Via Parameter (vauth). A UAC or Proxy inserting a Via Header with a RFC3261 compliant branch parameter MAY introduce one or vauth parameter into the Via header, in each case to identify authenticate the via header to one or more downstream proxies or UAS's. Such UAS's or proxies MAY use a vauth header to take local-policy dependent routing or access decisions. A UAC or Proxy which does not insert a Via Header with a RFC3261 compliant branch parameter MUST NOT insert any vauth parameters. The vauth parameter is intended to allow a server to authenticate a subset of the Via: header (being the sent-by entry and the branch token), together with an opaque string, to downstream servers. Multiple vauth parameters MAY be used in order to support multiple realms of authentication. The vauth parameter supports extensible mechanisms of authentication, but the mechanism specified herein is MD5 authentication using a shared secret. The mechanism of exchange of the shared secret and authentication realm is outside the scope of this document. The vauthid field specifies the realm of authentication. The vauthid field MUST be unique across instances if the vauth parameter in a single Via: header. Those specifying vauth fields SHOULD ensure that they are globally unique, for example a domain name MAY be used. The vauthopaque field is an opaque field intended to pass information to servers in the authentication realm which MAY be used to influence their routing decisions - for instance it might be used to specify that access should be permitted or denied, or have an accounting function. The vauthmeth field specifies the mechanism of authentication. The only currently defined method of authentication is MD5. In this mechanism, the vauthmd5data field contains a hash of the sent-by field, the branch parameter (which is, by RFC3261 unique across time and space), the vauthid field, the vauthopaque field, the vauthexpire field (if any), and the shared secret, which should be a string of printable characters no more than 64 octets in length. The hash is calculated using MD5 (RFC 1321 [35]), expressed in hexadecimal. The optional vauthexpire field is a date in the SIP date format (i.e. the preferred RFC1123 format) after which it should be assumed that the header is not authentic. If a vauthexpire field is inserted, the server MUST be synchronized to an accurate time source, and the expiry time MUST be no shorter than 32 seconds beyond the time at which the Via: header is to be transmitted. A server MAY check the authenticity of a Via: header using vauth parameters by performing each of the following checks: 1. Isolate the vauth field(s) corresponding to a realm for which the checking server possesses a shared secret. 2. If vauthexpire is present: if the checking server does not support vauthexpire, it MUST silently discard the request. If the checking server does support vauthexpire, it MUST check that the current time is not beyond the expiry time, and if it is, it MUST silently discard the request, else proceed. The silent discards are used to ensure that excessive transmission delays result only in the symptoms of packet loss, rather than false authentication refusals. 3. The server MUST recalculate the hash value and check whether it corresponds to the hash value in the vauthmd5data field. 4. The result of (3), the vauthopaque field, and the presence or absence of a vauthexpire field, MAY then be used to influence routing decisions The vauth mechnanism is primarily designed to protect against spoofing attacks, as the shared secret will not be known. It provides only limited protection against replay attacks, in that replays are time-limited by the vauth-expire header. Further limitation of replay attacks can be given by the implementor using the vauthopaque field - for instance in an environment where the Request-URI is known not to change between the server inserting the Via header and the server checking it, the vauthopaque field could be set to contain a hash of the Request-URI, which could be checked upon receipt. Further, it should be noted that mechanism provides no protection against malicious or accidental modification of the message between transmission by the server inserting the Via: header and the server analyzing it. It is not intended as a substitute for network or transport layer security. An example of a Via: header with vauth parameters follows: Via: SIP/2/0/UDP 4.3.2.1:5060 branch=1fe452.12; vauth="server.example.com:5061,y,MD5=1234567890abcdef1234567890abcdef"; vauth="server2.example.com:5060,,MD5=fedcba0987654321fedcba0987654321:Fri, 13 Oct 1998 23:50:00 GMT" RFC3261 specifies: via-params = via-ttl / via-maddr / via-received / via-branch / via-extension via-extension = generic-param generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) This document introduces a new via-param which matches the generic-param model: via-params = via-ttl / via-maddr / via-received / via-branch / via-vauth ; new / via-extension via-vauth = "vauth" EQUAL vauth vauth = LTQUOT vauthid COMMA vauthopaque COMMA vauthmeth [ COLON vauthexpire ]RDQUOT vauthid = vauthstr vauthopaque = [ vauthstr ] vauthexpire = SIP-date vauthstr = 1*(alphanum / "-" / "." / "/" / ":" / "_" / "[" / "]") vauthmeth = vauthmeth-md5 / vauthmeth-ext vauthmeth-ext = vauthextension EQUAL vauthextdata vauthextension = 1*(alphanum) vauthextdat = 1*(alphanum) vauthmeth-md5 = vauthmmd5 EQUAL vauthmd5data vauthmmd5 = "MD5" vauthmd5data = 32LHEX Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Apr 8 20:26:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15077 for ; Thu, 8 Apr 2004 20:26:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjpv-0002x4-Es for sip-archive@odin.ietf.org; Thu, 08 Apr 2004 20:25:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i390PZ0C011344 for sip-archive@odin.ietf.org; Thu, 8 Apr 2004 20:25:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjpY-0002gp-0O; Thu, 08 Apr 2004 20:25:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBitZ-0005P9-El for sip@optimus.ietf.org; Thu, 08 Apr 2004 19:25:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07973 for ; Thu, 8 Apr 2004 19:25:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBitX-0004Ob-00 for sip@ietf.org; Thu, 08 Apr 2004 19:25:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhmf-0003jA-00 for sip@ietf.org; Thu, 08 Apr 2004 18:14:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfnk-00031y-00 for sip@ietf.org; Thu, 08 Apr 2004 16:07:04 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2004 12:15:42 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i38K6Rn2019355; Thu, 8 Apr 2004 13:06:27 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL91651; Thu, 8 Apr 2004 16:06:26 -0400 (EDT) Message-ID: <4075B0C2.9050506@cisco.com> Date: Thu, 08 Apr 2004 16:06:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Viktor.Bekesi@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Caller-Preferences: Representing negated Boolean feature tags References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Viktor, Sure, it makes sense to negate boolean feature tags. More below. Paul Viktor.Bekesi@nokia.com wrote: > Hello, > > I am implementing SIP Caller-Preferences related functionalities, and there is one thing that is not clear for me after reading the relevant drafts and rfcs: Does it make sense to negate a Boolean type feature tag? like the audio in the example: > > (& (! (audio=TRUE)) > (video=TRUE) > (sip.mobility=fixed) > (message=TRUE) > (| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE) > (sip.methods=CANCEL) (sip.methods=ACK)) > (| (sip.schemes=sip) (sip.schemes=http))) The first thing to decide is whether you want (! (audio=TRUE)), or (audio=FALSE). For some purposes they are the same, for others they are not. The difference comes when matching against another feature predicate that doesn't mention audio. > If yes, then the next question arises: How can I represent negated Boolean type feature tags in SIP header parameters? > According to draft-ietf-sip-callerprefs-10, > > (& (sip.mobility=fixed) > (| (! (sip.events=presence)) (sip.events=winfo)) > (| (language=en) (language=de)) > (sip.description="PC") > (sip.newparam=TRUE) > (rangeparam=-4..5125/1000)) > > this declaration can be turned into this representation: > > Accept-Contact:*;mobility="fixed";events="!presence,winfo";language="en,de" > ;description="";+sip.newparam;+rangeparam="#-4:+5.125" > > (I reversed the order as it was in the document) > > Here the events are negated and that is indicated by the exclamation mark at the beginning of the event-tag-value. Boolean type tags are turned into flag parameters with no value. So then how can the very first example represented? The suppression of the TRUE value for boolean feature tags is syntactic sugar, and is optional. So the following are equivalent: audio audio="TRUE" So, you can represent (! (audio=TRUE)) as audio="!TRUE" > Thanks in advance, best regards: > > Viktor Bekesi > Nokia Networks > +36-20 9849-202 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Apr 9 03:12:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15438 for ; Fri, 9 Apr 2004 03:12:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqBT-0001Je-PP for sip-archive@odin.ietf.org; Fri, 09 Apr 2004 03:12:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i397CFr4005053 for sip-archive@odin.ietf.org; Fri, 9 Apr 2004 03:12:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqBG-0001E4-NE; Fri, 09 Apr 2004 03:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqAi-0001DN-Bz for sip@optimus.ietf.org; Fri, 09 Apr 2004 03:11:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15329 for ; Fri, 9 Apr 2004 03:11:24 -0400 (EDT) From: Viktor.Bekesi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBqAc-0001KR-00 for sip@ietf.org; Fri, 09 Apr 2004 03:11:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBq8k-00016o-00 for sip@ietf.org; Fri, 09 Apr 2004 03:09:27 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BBq7I-0000wW-00 for sip@ietf.org; Fri, 09 Apr 2004 03:07:56 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3977kn16501; Fri, 9 Apr 2004 10:07:47 +0300 (EET DST) X-Scanned: Fri, 9 Apr 2004 10:07:44 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3977iAR029346; Fri, 9 Apr 2004 10:07:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00Us96S7; Fri, 09 Apr 2004 10:07:43 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3977gs28862; Fri, 9 Apr 2004 10:07:42 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Apr 2004 10:07:41 +0300 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Apr 2004 10:07:41 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Caller-Preferences: Representing negated Boolean feature tags Date: Fri, 9 Apr 2004 09:07:41 +0200 Message-ID: thread-topic: [Sip] Caller-Preferences: Representing negated Boolean feature tags thread-index: AcQdybFwkhW6k1SCT4qBtyRih7OukgANyNaQ To: Cc: X-OriginalArrivalTime: 09 Apr 2004 07:07:41.0915 (UTC) FILETIME=[5988BAB0:01C41E01] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thank You for the answer. Just one last question: (audio =3D FALSE) is equal to not including the = audio tag at all? Many thanks, BR: Viktor -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext Paul Kyzivat Sent: Thursday April 08,2004 22:06 To: Bekesi Viktor (Nokia-NET/Budapest) Cc: sip@ietf.org Subject: Re: [Sip] Caller-Preferences: Representing negated Boolean feature tags Viktor, Sure, it makes sense to negate boolean feature tags. More below. Paul Viktor.Bekesi@nokia.com wrote: > Hello, >=20 > I am implementing SIP Caller-Preferences related functionalities, and = there is one thing that is not clear for me after reading the relevant = drafts and rfcs: Does it make sense to negate a Boolean type feature = tag? like the audio in the example: >=20 > (& (! (audio=3DTRUE)) > (video=3DTRUE) > (sip.mobility=3Dfixed) > (message=3DTRUE) > (| (sip.methods=3DINVITE) (sip.methods=3DOPTIONS) = (sip.methods=3DBYE) > (sip.methods=3DCANCEL) (sip.methods=3DACK)) > (| (sip.schemes=3Dsip) (sip.schemes=3Dhttp))) The first thing to decide is whether you want (! (audio=3DTRUE)), or=20 (audio=3DFALSE). For some purposes they are the same, for others they = are=20 not. The difference comes when matching against another feature=20 predicate that doesn't mention audio. > If yes, then the next question arises: How can I represent negated = Boolean type feature tags in SIP header parameters?=20 > According to draft-ietf-sip-callerprefs-10,=20 >=20 > (& (sip.mobility=3Dfixed) > (| (! (sip.events=3Dpresence)) (sip.events=3Dwinfo)) > (| (language=3Den) (language=3Dde)) > (sip.description=3D"PC") > (sip.newparam=3DTRUE) > (rangeparam=3D-4..5125/1000)) >=20 > this declaration can be turned into this representation: >=20 > = Accept-Contact:*;mobility=3D"fixed";events=3D"!presence,winfo";language=3D= "en,de" > ;description=3D"";+sip.newparam;+rangeparam=3D"#-4:+5.125" > > (I reversed the order as it was in the document) >=20 > Here the events are negated and that is indicated by the exclamation = mark at the beginning of the event-tag-value. Boolean type tags are = turned into flag parameters with no value. So then how can the very = first example represented? The suppression of the TRUE value for boolean feature tags is syntactic=20 sugar, and is optional. So the following are equivalent: audio audio=3D"TRUE" So, you can represent (! (audio=3DTRUE)) as audio=3D"!TRUE" > Thanks in advance, best regards:=20 >=20 > Viktor Bekesi > Nokia Networks > +36-20 9849-202 > =20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Apr 9 16:50:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20619 for ; Fri, 9 Apr 2004 16:50:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2we-0000Lh-OI for sip-archive@odin.ietf.org; Fri, 09 Apr 2004 16:49:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39KnmXB001306 for sip-archive@odin.ietf.org; Fri, 9 Apr 2004 16:49:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2vw-00009J-4u; Fri, 09 Apr 2004 16:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2vT-00006f-3Q for sip@optimus.ietf.org; Fri, 09 Apr 2004 16:48:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20418 for ; Fri, 9 Apr 2004 16:48:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC2vR-0001Rc-00 for sip@ietf.org; Fri, 09 Apr 2004 16:48:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC2iy-0007Zj-00 for sip@ietf.org; Fri, 09 Apr 2004 16:35:41 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BC2KR-0005hn-00 for sip@ietf.org; Fri, 09 Apr 2004 16:10:19 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2004 13:20:10 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i39K9aCE005077; Fri, 9 Apr 2004 16:09:39 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM65243; Fri, 9 Apr 2004 16:09:35 -0400 (EDT) Message-ID: <407702FF.7050506@cisco.com> Date: Fri, 09 Apr 2004 16:09:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Viktor.Bekesi@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Caller-Preferences: Representing negated Boolean feature tags References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Viktor.Bekesi@nokia.com wrote: > Thank You for the answer. > Just one last question: (audio = FALSE) is equal to not including the audio tag at all? Not exactly. When matching two feature predicates, the matching algorithm considers it a match if one mentions a feature tag and another does not. This behavior is then modified by the presence of "require" and "explicit" parameters on Accept-Contact. You need to read in detail how it works. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Apr 9 18:28:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28212 for ; Fri, 9 Apr 2004 18:28:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4TH-0002cM-1g for sip-archive@odin.ietf.org; Fri, 09 Apr 2004 18:27:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39MRZPX010063 for sip-archive@odin.ietf.org; Fri, 9 Apr 2004 18:27:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Sk-0002OI-Tc; Fri, 09 Apr 2004 18:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4SN-0002NT-VQ for sip@optimus.ietf.org; Fri, 09 Apr 2004 18:26:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28170 for ; Fri, 9 Apr 2004 18:26:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4SJ-0001Qe-00 for sip@ietf.org; Fri, 09 Apr 2004 18:26:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4MU-0000vY-00 for sip@ietf.org; Fri, 09 Apr 2004 18:20:35 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BC4FK-0000G4-00 for sip@ietf.org; Fri, 09 Apr 2004 18:13:10 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Apr 2004 14:20:50 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i39MCYGF013892; Fri, 9 Apr 2004 15:12:34 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM72945; Fri, 9 Apr 2004 18:12:33 -0400 (EDT) Message-ID: <40771FD1.1030600@cisco.com> Date: Fri, 09 Apr 2004 18:12:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Whitaker CC: sip@ietf.org Subject: Re: [Sip] Question regarding SDP and holds References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chris Whitaker wrote: > In rfc3264, it states: > > If the stream to be placed on hold was previously a sendrecv media > stream, it is placed on hold by marking it as sendonly. > > So my question is this. > If the stream being altered was previously a sendrecv media stream, and > has become a sendonly stream... how does one communicate that without > implying that the stream is on hold [ie neither sending nor receiving]? > To be clear within the existing recommended proceedures for communcating > a hold, I am trying to understand a means of differentiating when the > source of media stream has stopped receiving but NOT stopped sending and > when it has stopped BOTH. > > Secondly, if a sendrecv stream is becoming neither a sending nor > receiving stream [which often occurs when it goes on hold] why does the > rfc suggest claiming it is sendonly... would not inactive be more accurate? I *think* the assumption is that "putting on hold" may cause something (music, or beeps, ...) to be sent by the holder to the holdee. So sendonly is used. If the intent is truly to neither send nor receive, then it would be more appropriate to use inactive. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 13 03:11:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24882 for ; Tue, 13 Apr 2004 03:11:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI3y-0003aO-0K for sip-archive@odin.ietf.org; Tue, 13 Apr 2004 03:10:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D7AT9H013782 for sip-archive@odin.ietf.org; Tue, 13 Apr 2004 03:10:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI3X-0003TP-Lg; Tue, 13 Apr 2004 03:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI2g-0003Mr-8E for sip@optimus.ietf.org; Tue, 13 Apr 2004 03:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24799 for ; Tue, 13 Apr 2004 03:09:07 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI2c-0000D7-00 for sip@ietf.org; Tue, 13 Apr 2004 03:09:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDHzm-00001T-00 for sip@ietf.org; Tue, 13 Apr 2004 03:06:10 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BDHyC-0007hx-00 for sip@ietf.org; Tue, 13 Apr 2004 03:04:32 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D73jn14233; Tue, 13 Apr 2004 10:03:45 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 10:02:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3D72wxc000788; Tue, 13 Apr 2004 10:02:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00utB7Ey; Tue, 13 Apr 2004 10:02:57 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D72gs12791; Tue, 13 Apr 2004 10:02:42 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 10:02:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2004 10:02:41 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D7@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABBH+m96wbjLR7CKc21Y58VQWgFJNj1gAAAYTfA= To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 07:02:41.0828 (UTC) FILETIME=[50521640:01C42125] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable One small correction: Rooms will be help until 3rd May. Thanks, Hisham > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: 13.April.2004 10:00 > To: 'ext Rohan Mahy'; 'sip@ietf.org' > Cc: Dean Willis; Allison Mankin; Robert Sparks; John Peterson; Ted > Hardie; Gonzalo Camarillo; Alan Johnston; Adam Roach > Subject: RE: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > Here is the hotel information: >=20 > Renaissance Boston Hotel Bedford > 44 Middlesex Turnpike Bedford, MA 01730 USA > Phone: 1 781-275-5500 Fax: 1 781-275-3042 >=20 > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB >=20 > There are 50 rooms booked for this event at the rate of $99=20 > per night (from Sunday 23rd until Wednesday 26th). These=20 > rooms will be held until 3th May, so please reserve your room=20 > on or before that date. >=20 > You can reserve online or by telephone using the Group Code: NONOKA >=20 > Also, please use the links that Rohan provided to confirm=20 > your attendance. This will aid us in determining the catering=20 > requirements. Here is the link again: >=20 > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > interim]yes >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 06.April.2004 20:54 > > To: 'sip@ietf.org' > > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; > > Rohan Mahy; Alan Johnston; Adam Roach > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > Hello All, > >=20 > > Please mark your calendars. > >=20 > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > SIMPLE, and =20 > > XCON WGs. > > Nokia has generously agreed to host the event either at their=20 > > offices =20 > > near Boston or in a neighboring hotel during the week of May 24. > >=20 > > Please reserve the following dates for the WGs that you are=20 > > interested =20 > > in: > > Monday May 24 SIP and SIPPING tentatively 9 am start > > Tuesday May 25 SIMPLE All day > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > can catch =20 > > flights. > > (the actual agenda is subject to change, including the dates=20 > > of various =20 > > WG meetings). > >=20 > > There will be no fee, however please let Hisham and myself=20 > > know if you =20 > > are planning to attend by clicking on the Yes or Maybe links below: > >=20 > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > >=20 > > Wireless will be provided. As usual, I will be making=20 > > T-shirts. If you =20 > > are interested in buying one, please send your shirt size to me. > >=20 > > More details on the agenda and hotel accommodations will be=20 > > forthcoming =20 > > shortly. > >=20 > > thanks, > > -rohan > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 13 03:25:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25711 for ; Tue, 13 Apr 2004 03:25:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDIIU-0006XD-7P for sip-archive@odin.ietf.org; Tue, 13 Apr 2004 03:25:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D7PUbV025101 for sip-archive@odin.ietf.org; Tue, 13 Apr 2004 03:25:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDII3-0006Qs-5H; Tue, 13 Apr 2004 03:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDIHp-0006PR-5z for sip@optimus.ietf.org; Tue, 13 Apr 2004 03:24:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25657 for ; Tue, 13 Apr 2004 03:24:47 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDIHl-0001Io-00 for sip@ietf.org; Tue, 13 Apr 2004 03:24:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDIBC-0000y0-00 for sip@ietf.org; Tue, 13 Apr 2004 03:18:00 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BDI6A-0000YH-00 for sip@ietf.org; Tue, 13 Apr 2004 03:12:46 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D7BYk17843; Tue, 13 Apr 2004 10:11:34 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 10:10:10 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3D7AAG4012066; Tue, 13 Apr 2004 10:10:10 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00BNWG1x; Tue, 13 Apr 2004 10:10:09 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D700s10556; Tue, 13 Apr 2004 10:00:00 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 09:59:56 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 09:59:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2004 09:59:55 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D3@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABBH+m96wbjLR7CKc21Y58VQWgFJNj1g To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 06:59:54.0756 (UTC) FILETIME=[ECBCEC40:01C42124] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Here is the hotel information: Renaissance Boston Hotel Bedford 44 Middlesex Turnpike Bedford, MA 01730 USA Phone: 1 781-275-5500 Fax: 1 781-275-3042 http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB There are 50 rooms booked for this event at the rate of $99 per night = (from Sunday 23rd until Wednesday 26th). These rooms will be held until = 3th May, so please reserve your room on or before that date. You can reserve online or by telephone using the Group Code: NONOKA Also, please use the links that Rohan provided to confirm your = attendance. This will aid us in determining the catering requirements. = Here is the link again: mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim= ]yes Thanks, Hisham > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: 06.April.2004 20:54 > To: 'sip@ietf.org' > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; > Rohan Mahy; Alan Johnston; Adam Roach > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > Hello All, >=20 > Please mark your calendars. >=20 > I'd like to announce a joint interim of the SIP, SIPPING,=20 > SIMPLE, and =20 > XCON WGs. > Nokia has generously agreed to host the event either at their=20 > offices =20 > near Boston or in a neighboring hotel during the week of May 24. >=20 > Please reserve the following dates for the WGs that you are=20 > interested =20 > in: > Monday May 24 SIP and SIPPING tentatively 9 am start > Tuesday May 25 SIMPLE All day > Wednesday May 26 XCON tentatively finish at 4pm so folks can catch =20 > flights. > (the actual agenda is subject to change, including the dates=20 > of various =20 > WG meetings). >=20 > There will be no fee, however please let Hisham and myself=20 > know if you =20 > are planning to attend by clicking on the Yes or Maybe links below: >=20 > mailto:rohan@cisco.com?=20 > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > mailto:rohan@cisco.com?=20 > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe >=20 > Wireless will be provided. As usual, I will be making=20 > T-shirts. If you =20 > are interested in buying one, please send your shirt size to me. >=20 > More details on the agenda and hotel accommodations will be=20 > forthcoming =20 > shortly. >=20 > thanks, > -rohan >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 13 09:01:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09756 for ; Tue, 13 Apr 2004 09:01:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNXc-00038t-5A for sip-archive@odin.ietf.org; Tue, 13 Apr 2004 09:01:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DD1Snn012079 for sip-archive@odin.ietf.org; Tue, 13 Apr 2004 09:01:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNXC-00030A-8m; Tue, 13 Apr 2004 09:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNX1-0002xp-GG for sip@optimus.ietf.org; Tue, 13 Apr 2004 09:00:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09702 for ; Tue, 13 Apr 2004 09:00:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNX0-0007Oa-00 for sip@ietf.org; Tue, 13 Apr 2004 09:00:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNVy-0007JN-00 for sip@ietf.org; Tue, 13 Apr 2004 08:59:47 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDNUz-0007E0-00 for sip@ietf.org; Tue, 13 Apr 2004 08:58:46 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DCwfH22716 for ; Tue, 13 Apr 2004 15:58:41 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 15:58:22 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3DCwMIX013459 for ; Tue, 13 Apr 2004 15:58:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00TyPgjQ; Tue, 13 Apr 2004 15:58:20 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DCvns12104 for ; Tue, 13 Apr 2004 15:57:49 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 15:57:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Date: Tue, 13 Apr 2004 15:57:45 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978DE@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABBH+m96wbjLR7CKc21Y58VQWgFJNj1gAAx9IoA= To: X-OriginalArrivalTime: 13 Apr 2004 12:57:45.0773 (UTC) FILETIME=[EA761DD0:01C42156] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,BIZ_TLD,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable It was pointed out to me that the Group Code for booking was incorrect. = Here is the correct Group Code: NOKNOKA. Apologies for the inconvenience. Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 13.April.2004 10:00 > To: rohan@cisco.com; sip@ietf.org > Cc: dean.willis@softarmor.com; mankin@psg.com; rjsparks@nostrum.com; > jon.peterson@neustar.biz; hardie@qualcomm.com; > Gonzalo.Camarillo@ericsson.com; alan.johnston@wcom.com; > adam@dynamicsoft.com > Subject: [Sip] RE: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > Here is the hotel information: >=20 > Renaissance Boston Hotel Bedford > 44 Middlesex Turnpike Bedford, MA 01730 USA > Phone: 1 781-275-5500 Fax: 1 781-275-3042 >=20 > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB >=20 > There are 50 rooms booked for this event at the rate of $99=20 > per night (from Sunday 23rd until Wednesday 26th). These=20 > rooms will be held until 3th May, so please reserve your room=20 > on or before that date. >=20 > You can reserve online or by telephone using the Group Code: NONOKA >=20 > Also, please use the links that Rohan provided to confirm=20 > your attendance. This will aid us in determining the catering=20 > requirements. Here is the link again: >=20 > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > interim]yes >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 06.April.2004 20:54 > > To: 'sip@ietf.org' > > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; > > Rohan Mahy; Alan Johnston; Adam Roach > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > Hello All, > >=20 > > Please mark your calendars. > >=20 > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > SIMPLE, and =20 > > XCON WGs. > > Nokia has generously agreed to host the event either at their=20 > > offices =20 > > near Boston or in a neighboring hotel during the week of May 24. > >=20 > > Please reserve the following dates for the WGs that you are=20 > > interested =20 > > in: > > Monday May 24 SIP and SIPPING tentatively 9 am start > > Tuesday May 25 SIMPLE All day > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > can catch =20 > > flights. > > (the actual agenda is subject to change, including the dates=20 > > of various =20 > > WG meetings). > >=20 > > There will be no fee, however please let Hisham and myself=20 > > know if you =20 > > are planning to attend by clicking on the Yes or Maybe links below: > >=20 > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > >=20 > > Wireless will be provided. As usual, I will be making=20 > > T-shirts. If you =20 > > are interested in buying one, please send your shirt size to me. > >=20 > > More details on the agenda and hotel accommodations will be=20 > > forthcoming =20 > > shortly. > >=20 > > thanks, > > -rohan > >=20 > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 14 04:33:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09422 for ; Wed, 14 Apr 2004 04:33:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfoR-0005ea-Hp for sip-archive@odin.ietf.org; Wed, 14 Apr 2004 04:32:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E8W3e5021732 for sip-archive@odin.ietf.org; Wed, 14 Apr 2004 04:32:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfic-0004Ta-RU; Wed, 14 Apr 2004 04:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBrwC-0001RA-JF for sip@optimus.ietf.org; Fri, 09 Apr 2004 05:04:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18922 for ; Fri, 9 Apr 2004 05:04:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBrw7-0003SH-00 for sip@ietf.org; Fri, 09 Apr 2004 05:04:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBrv0-0003L9-00 for sip@ietf.org; Fri, 09 Apr 2004 05:03:23 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1BBrty-0003EK-00 for sip@ietf.org; Fri, 09 Apr 2004 05:02:18 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Apr 2004 11:02:12 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41E11.5882FB1F" Subject: [Sip] Presence of two Via headers in a response X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 9 Apr 2004 11:02:10 +0200 Message-ID: Thread-Topic: [Sip] Presence of two Via headers in a response Thread-Index: AcQeEVd5vQvT3/02RzSdwH4HdgqGYA== From: =?iso-8859-1?Q?PROUVOST_S=E9bastien_FTRD/DAC/ISS?= To: X-OriginalArrivalTime: 09 Apr 2004 09:02:12.0320 (UTC) FILETIME=[589D5600:01C41E11] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C41E11.5882FB1F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : = "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message." However if the UAC Core layer discards the response and if this response = was the only one sent (for example a 200 OK to an UPDATE), then this = leads to a situation when the transaction is terminated (the transaction = layer received the response and passed it to the UA Core) but the UA = Core is still waiting for a response (it discarded the 200 OK because of = the presence of two Via header field values and so is still waiting for = the response). What are the procedures that tells the UAC when to stop waiting for the = response ? Should there be a Timer (not described in RFC 3261) that = tells the UAC when to CANCEL a request when no response is received ? Additionally, what shall be the procedures when receiving more than one = To, From, CSeq, Call-ID or Max-Forward header field values? Thanks for your clarifications, S=E9bastien Prouvost France T=E9l=E9com R&D ------_=_NextPart_001_01C41E11.5882FB1F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Sip] Presence of two Via headers in a response

Hi all,

In RFC 3261, it is written = (section 8.1.3.3 for UAC Core procedures) : "If more than one Via = header field value is present in a response, the UAC SHOULD discard the = message."

However if the UAC Core layer = discards the response and if this response was the only one sent (for = example a 200 OK to an UPDATE), then this leads to a situation when the = transaction is terminated (the transaction layer received the response = and passed it to the UA Core) but the UA Core is still waiting for a = response (it discarded the 200 OK because of the presence of two Via = header field values and so is still waiting for the = response).

What are the procedures that = tells the UAC when to stop waiting for the response ? Should there be a = Timer (not described in RFC 3261) that tells the UAC when to CANCEL a = request when no response is received ?

Additionally, what shall be the = procedures when receiving more than one To, From, CSeq, Call-ID or = Max-Forward header field values?

Thanks for your = clarifications,

S=E9bastien Prouvost
France T=E9l=E9com = R&D

------_=_NextPart_001_01C41E11.5882FB1F-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 14 11:11:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00245 for ; Wed, 14 Apr 2004 11:11:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm0Y-00085I-Ua for sip-archive@odin.ietf.org; Wed, 14 Apr 2004 11:08:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EF8wg7031072 for sip-archive@odin.ietf.org; Wed, 14 Apr 2004 11:08:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlo2-0005Og-DW; Wed, 14 Apr 2004 10:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDljG-0004g1-IM for sip@optimus.ietf.org; Wed, 14 Apr 2004 10:51:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28877 for ; Wed, 14 Apr 2004 10:51:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDljD-0007eT-00 for sip@ietf.org; Wed, 14 Apr 2004 10:51:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlin-0007XO-00 for sip@ietf.org; Wed, 14 Apr 2004 10:50:37 -0400 Received: from email10.etsi.org ([212.234.161.112] helo=email10.etsihq.org) by ietf-mx with esmtp (Exim 4.12) id 1BDlhm-0007Kd-00; Wed, 14 Apr 2004 10:49:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2004 16:49:03 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A3302DFB197@email10.etsihq.org> Thread-Topic: Start of maintenance activity on VoIP test specification at ETSI Thread-Index: AcQiL6DkSaf2slKYR3uBd3Dtu79Ddg== From: =?iso-8859-1?Q?Fran=E7ois_Fischer?= To: , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Start of maintenance activity on VoIP test specification at ETSI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all, I would like to inform you that ETSI has just started a maintenance = activity on the Test specification for: SIP, H.225 and H.248. In order to improve as much as possible these Test Specifications, ETSI = needs to collect feedback and comments on the current version. The release of these Test Specifications will be produced as following = (for SIP, H.225 and H.248): PICS : 11 June 2004 TSS&TP : 23 July 2004 ATS&PIXIT : 17 September 2004 We would appreciate you to look at these test specification releases and = to make comments latest 4 weeks before the corresponding dates above. Please consider the Test specification as a critical part of the quality = process to ensure Interoperability and reliability of equipments. Furthermore, test specifications, when used by the test labs, operator = and vendors will give confidence in VoIP and Internet Telephony = protocols. For more information on Testing of VoIP Protocols, and TTCN3, please = visit: http://www.etsi.org/ptcc/home.htm You will also find the current release of the Test Specification in the = following links: Links to H.225: PICS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00095-1/v1.0.0/ TSS&TP: http://docbox.etsi.org/MTS/MTS/07-Drafts/00095-2/v1.0.0/ ATS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00095-3/ Links to H.248: PICS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00096-1/v1.0.0/ TSS&TP: http://docbox.etsi.org/MTS/MTS/07-Drafts/00096-2/ ATS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00096-3/ Links to SIP: PICS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00097-1/v1.0.0/ TSS&TP: http://docbox.etsi.org/MTS/MTS/07-Drafts/00097-2/v1.0.0/ ATS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00097-3/ In order to transmit your comments please use the dedicated Email = exploder list: H.323 : MTS-IPT-H323 H.248 : MTS-IPT-H248 SIP : MTS-IPT-SIP. You will subscribe these lists independantly by sending an email to: = listserv@list.etsi.org with the following command in the message body: subscribe "listname" (firstname lastname) eg subcribe MTS-IPT-SIP (firstname lastname) Please contribute in maintening these specifications, which enable VoIP = actors to ensure the right level of quality for VoIP and Internet = Telephony items. Many thanks in advance. Francois FISCHER - STF expert ************************************************* ETSI Einstein Building - 650 route des Lucioles F-06560 Sophia Antipolis cedex, FRANCE ************************************************* Tel: +33 (0)4 92944330 - Fax: +33 (0)4 92385244 Email: francois.fischer@etsi.org _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Apr 16 12:44:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20517 for ; Fri, 16 Apr 2004 12:44:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWMS-0001Pc-HB for sip-archive@odin.ietf.org; Fri, 16 Apr 2004 12:38:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GGcepC005428 for sip-archive@odin.ietf.org; Fri, 16 Apr 2004 12:38:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEW8P-0006GB-88; Fri, 16 Apr 2004 12:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVs5-0001DN-LG for sip@optimus.ietf.org; Fri, 16 Apr 2004 12:07:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18247 for ; Fri, 16 Apr 2004 12:07:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEVs4-0007ib-7X for sip@ietf.org; Fri, 16 Apr 2004 12:07:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVr8-0007ea-00 for sip@ietf.org; Fri, 16 Apr 2004 12:06:19 -0400 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BEVqH-0007Xq-00 for sip@ietf.org; Fri, 16 Apr 2004 12:05:25 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3GG4sR02443 for ; Fri, 16 Apr 2004 09:04:54 -0700 (PDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Apr 2004 11:04:53 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF5791BA@zrc2c000.us.nortel.com> From: "Mary Barnes" To: sip@ietf.org Date: Fri, 16 Apr 2004 11:04:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C423CC.8DFF310E" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] History-Info status - Security open issue Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C423CC.8DFF310E Content-Type: text/plain Hi all, There are still two open issues around History-Info (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt ) that require list discussion: privacy and security. I'll post some details on the privacy proposal in a separate posting so that I can more easily track the responses. On the security, based upon some of the discussion in the e2m, m2e, policy adhoc (per my recollection and the notes at: http://softarmor.com/sipping/meets/ietf59/notes/notes-cyrus-sipping-adhoc-ie tf59.txt ) there does not seem to be WG consensus that History-Info really requires m2e (i.e. TLS may be sufficient). I do agree that if there was an m2e (and m2m) security mechanism in place for SIP at this point in time, that the use of it for History-Info would add value and actually make History-Info itself more useful to the end applications. What I would like to propose is that the draft reference the context of some of these current works in progress in this area as informational and possibly applicable to History-Info. And, of course, define TLS as the normative and mandatory security solution for History-Info. This results in the security for History-Info initially being as robust as that of the other headers added by Intermediaries (Via, etc.), per RFC 3261 and in the future, could be made more robust. In the end, it is up to the applications making use of History-Info to choose the security solution that best meets its requirements and if there is a m2m and m2e solution developed in the future, applications can certainly take advantage of those. If there's general agreement on this approach, I believe this only requires some minor rewording in section 3.2. The remaining work to complete the draft would be updating and cleaning up the examples. [I realize that this will likely start a long thread on the more general topic of m2e, which does need discussion, but if folks could, please, upfront in their postings say whether they believe History-Info can and should be progressed without that solution fully specified]. Regards, Mary mary.barnes@nortelnetworks.com ------_=_NextPart_001_01C423CC.8DFF310E Content-Type: text/html Content-Transfer-Encoding: quoted-printable History-Info status - Security open issue

Hi all,

There are still two open issues around History-Info = (http://www.ietf.org/internet-drafts/draft-ietf-sip-his= tory-info-02.txt ) that require list discussion: privacy and = security.  I'll post some details on the privacy proposal in a = separate posting so that I can more easily track the responses.  =

On the security, based upon some of the discussion in = the e2m, m2e, policy adhoc (per my recollection and the notes at: http://softarmor.com/sipping/meets/ietf59/notes/notes-= cyrus-sipping-adhoc-ietf59.txt  ) there does not seem to be WG = consensus that History-Info really requires m2e (i.e. TLS may be = sufficient).  I do agree that if there was an m2e (and m2m) = security mechanism in place for SIP at this point in time, that the use = of it for History-Info would add value and actually make History-Info = itself more useful to the end applications.

What I would like to propose is that the draft = reference the context of some of these current works in progress in = this area as informational and possibly applicable to = History-Info.  And, of course, define TLS as the normative and = mandatory security solution for History-Info. This results in the = security for History-Info initially being as robust as that of the = other headers added by Intermediaries (Via, etc.), per RFC 3261 and in = the future, could be made more robust.  In the end, it is up to = the applications making use of History-Info to choose the security = solution that best meets its requirements and if there is a m2m and m2e = solution developed in the future, applications can certainly take = advantage of those. 

If there's general agreement on this approach, I = believe this only requires some minor rewording in section 3.2. The = remaining work to complete the draft would be updating and cleaning up = the examples.

[I realize that this will likely start a long thread = on the more general topic of m2e, which does need discussion, but if = folks could, please, upfront in their postings say whether they believe = History-Info can and should be progressed without that solution fully = specified].

Regards,
Mary
mary.barnes@nortelnetworks.com


------_=_NextPart_001_01C423CC.8DFF310E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Apr 16 12:45:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20576 for ; Fri, 16 Apr 2004 12:45:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWOz-00029y-Ot for sip-archive@odin.ietf.org; Fri, 16 Apr 2004 12:41:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GGfHeu008296 for sip-archive@odin.ietf.org; Fri, 16 Apr 2004 12:41:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEW8R-0006Gm-Cz; Fri, 16 Apr 2004 12:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVsD-0001Jf-Aj for sip@optimus.ietf.org; Fri, 16 Apr 2004 12:07:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18274 for ; Fri, 16 Apr 2004 12:07:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEVsB-0007ji-UO for sip@ietf.org; Fri, 16 Apr 2004 12:07:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVrF-0007fi-00 for sip@ietf.org; Fri, 16 Apr 2004 12:06:26 -0400 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BEVqu-0007bN-00 for sip@ietf.org; Fri, 16 Apr 2004 12:06:04 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3GG5WR02551 for ; Fri, 16 Apr 2004 09:05:33 -0700 (PDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Apr 2004 11:05:32 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF5791BB@zrc2c000.us.nortel.com> From: "Mary Barnes" To: sip@ietf.org Date: Fri, 16 Apr 2004 11:05:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C423CC.A475D906" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] History-Info Privacy Issue Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C423CC.A475D906 Content-Type: text/plain Per my posting on the status of History-Info, Privacy is one of the remaining open issues. The proposal currently in the draft is quite simple: If the Privacy header has a priv-value of "Session" or "Header" privacy, the History-Info SHOULD not be included in the Request (or subsequent responses). This is effectively applying the fundamental recommendation in RFC3323 that any optional information that can divulge information about the user(s) should not be included in the requests. A proposal was made that there are scenarios (e.g. where local policy limits the applicability of History-Info within a specific domain) where you would want to capture the History-Info but not send it beyond certain intermediaries or domains. To support this, it was proposed that we could extend the Privacy header defined in RFC 3323 with tags for History-Info something like the following: priv-value = "history" / "history-index" The "history" priv-value would mean that all the History-Info entries should be removed. The "history-index" would be used to indicate that the specific entry is to be removed and would need to have the Privacy header escaped in the URI so that it can be associated with a specific History-Info entry (or we need to add another field to History-Info for this). So, I think we have two options here: 1) Extend History-Info to have an optional privacy field along the lines of what's detailed above. 2) Defer the definition of the privacy field to a separate draft, since it appears to be primarily limited to scenarios with certain trust models. So, if folks could just take a bit of time and consider their preference, I would like to get the draft updated soon and closed off prior to the Interim meeting. Regards, Mary H. Barnes mary.barnes@nortelnetworks.com ------_=_NextPart_001_01C423CC.A475D906 Content-Type: text/html Content-Transfer-Encoding: quoted-printable History-Info Privacy Issue

Per my posting on the status of History-Info, Privacy = is one of the remaining open issues.  The proposal currently in = the draft is quite simple:

If the Privacy header has a priv-value of = "Session" or "Header" privacy, the = History-Info  SHOULD not be included in the Request (or subsequent = responses). 

This is effectively applying the fundamental = recommendation in RFC3323 that any optional information that can = divulge information about the user(s) should not be included in the = requests. 

A proposal was made that there are scenarios (e.g. = where local policy limits the applicability of History-Info within a = specific domain) where you would want to capture the History-Info but = not send it beyond certain intermediaries or domains.  To support = this, it was proposed that we could extend the Privacy header defined = in RFC 3323 with tags for History-Info something like the = following:

priv-value =3D "history" / = "history-index" 

The "history" priv-value would mean that = all the History-Info entries should be removed.  The = "history-index" would be used to indicate that the specific = entry is to be removed and would need to have the Privacy header = escaped in the URI so that it can be associated with a specific = History-Info entry (or we need to add another field to History-Info for = this).   

So, I think we have two options here:
1) Extend History-Info to have an optional privacy = field along the lines of what's detailed above. 

2) Defer the definition of the privacy field to a = separate draft, since it appears to be primarily limited to scenarios = with certain trust models. 

So, if folks could just take a bit of time and = consider their preference, I would like to get the draft updated soon = and closed off prior to the Interim meeting.

Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com

------_=_NextPart_001_01C423CC.A475D906-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 02:33:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20090 for ; Mon, 19 Apr 2004 02:33:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFSG9-0001io-Ff for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 02:28:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J6S1IQ006619 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 02:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFS9Q-0007xD-1d; Mon, 19 Apr 2004 02:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFS5O-000604-9d for sip@optimus.ietf.org; Mon, 19 Apr 2004 02:16:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18750 for ; Mon, 19 Apr 2004 02:16:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFS5K-00038d-JO for sip@ietf.org; Mon, 19 Apr 2004 02:16:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFS4N-0002uu-00 for sip@ietf.org; Mon, 19 Apr 2004 02:15:51 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx with esmtp (Exim 4.12) id 1BFS3x-0002go-00 for sip@ietf.org; Mon, 19 Apr 2004 02:15:25 -0400 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 71DB938D48; Mon, 19 Apr 2004 08:15:25 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27301-01-12; Mon, 19 Apr 2004 08:15:25 +0200 (CEST) Received: from min.it.su.se (min.it.su.se [130.237.95.62]) by smtp1.su.se (Postfix) with ESMTP id 0E04E38CEE; Mon, 19 Apr 2004 08:15:25 +0200 (CEST) From: Fredrik Thulin To: Alex Bligh Date: Mon, 19 Apr 2004 08:15:24 +0200 User-Agent: KMail/1.5.4 Cc: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404190815.24768.ft@it.su.se> X-Virus-Scanned: by amavisd-new at su.se X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] unanswered: RFC3261 & authenticating PROXIES to other proxies & UAS's Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday 07 April 2004 17.41, Alex Bligh wrote: > --On 06 April 2004 18:39 +0200 Fredrik Thulin wrote: > > There is wording in section 22.3 saying proxys MUST NOT add things to > > authorization headers, and that all 407 responses MUST be forwarded > > upstreams. That is a pity, since I think otherwise the following could > > solve the problem : > > > > P1 could, upon receiving the 407 from P2, start a new transaction with a > > different branch parameter and added authentication credentials. The > > request could then be re-submitted to P2. > > If I read things right, the branch parameter is going to be different > /anyway/ for a proxy with loop detection: > > 16.6 Request Forwarding [Section 8] > > ... > If a proxy wishes to detect loops, the "branch" parameter it > supplies MUST depend on all information affecting processing of > a request, including the incoming Request-URI and any header > fields affecting the request's admission or routing. This is > necessary to distinguish looped requests from requests whose > routing parameters have changed before returning to this > server. > > On this basis, if the proxy retries the INVITE with the same CSeq, > what is the problem? IE how is this any different from spiraling > (which is allowed)? I think you have a very good point here. Now that people should be well back from their easter vacation I would like to ask again that someone explains the reason for explicitly forbidding proxys to respond to 407 challenges. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 15:51:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05561 for ; Mon, 19 Apr 2004 15:51:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFemb-0007EQ-Lw for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 15:50:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JJoLUt027796 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 15:50:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeYp-0004kO-Pl; Mon, 19 Apr 2004 15:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeW8-0004Ek-6F for sip@optimus.ietf.org; Mon, 19 Apr 2004 15:33:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04407 for ; Mon, 19 Apr 2004 15:33:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeW6-0000XE-QH for sip@ietf.org; Mon, 19 Apr 2004 15:33:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeVE-0000Il-00 for sip@ietf.org; Mon, 19 Apr 2004 15:32:25 -0400 Received: from webbox100.server-home.net ([195.137.212.21]) by ietf-mx with esmtp (Exim 4.12) id 1BFeUW-00004K-00 for sip@ietf.org; Mon, 19 Apr 2004 15:31:40 -0400 Received: from pernau.at (mirnixdirnix.ict.tuwien.ac.at [128.131.80.218]) by webbox100.server-home.net (Postfix) with ESMTP id 8A06B1601F3; Mon, 19 Apr 2004 21:31:27 +0200 (CEST) Message-ID: <4084290A.9020602@pernau.at> Date: Mon, 19 Apr 2004 21:31:22 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 0.5a (Windows/20040120) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fredrik Thulin Cc: Alex Bligh , sip@ietf.org Subject: Re: [Sip] unanswered: RFC3261 & authenticating PROXIES to other proxies & UAS's References: <200404190815.24768.ft@it.su.se> In-Reply-To: <200404190815.24768.ft@it.su.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi! I think I found another problem - if the proxy inserts the Authentication header, the authentication user will likely be different to the user in the From: header. Such messages typically will be refused by a SIP proxy as this allows to fake the sender id. regards, Klaus Fredrik Thulin wrote: > On Wednesday 07 April 2004 17.41, Alex Bligh wrote: > >>--On 06 April 2004 18:39 +0200 Fredrik Thulin wrote: >> >>>There is wording in section 22.3 saying proxys MUST NOT add things to >>>authorization headers, and that all 407 responses MUST be forwarded >>>upstreams. That is a pity, since I think otherwise the following could >>>solve the problem : >>> >>>P1 could, upon receiving the 407 from P2, start a new transaction with a >>>different branch parameter and added authentication credentials. The >>>request could then be re-submitted to P2. >> >>If I read things right, the branch parameter is going to be different >>/anyway/ for a proxy with loop detection: >> >>16.6 Request Forwarding [Section 8] >> >>... >> If a proxy wishes to detect loops, the "branch" parameter it >> supplies MUST depend on all information affecting processing of >> a request, including the incoming Request-URI and any header >> fields affecting the request's admission or routing. This is >> necessary to distinguish looped requests from requests whose >> routing parameters have changed before returning to this >> server. >> >>On this basis, if the proxy retries the INVITE with the same CSeq, >>what is the problem? IE how is this any different from spiraling >>(which is allowed)? > > > I think you have a very good point here. Now that people should be well back > from their easter vacation I would like to ask again that someone explains > the reason for explicitly forbidding proxys to respond to 407 challenges. > > /Fredrik > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 16:12:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06741 for ; Mon, 19 Apr 2004 16:12:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFexD-0000mm-Rg for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 16:01:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JK1J8x003015 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 16:01:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeoG-0007qE-CN; Mon, 19 Apr 2004 15:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFecv-0005i9-PW for sip@optimus.ietf.org; Mon, 19 Apr 2004 15:40:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04893 for ; Mon, 19 Apr 2004 15:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFecu-0002EF-Be for sip@ietf.org; Mon, 19 Apr 2004 15:40:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeby-00020Y-00 for sip@ietf.org; Mon, 19 Apr 2004 15:39:23 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BFebV-0001lR-00 for sip@ietf.org; Mon, 19 Apr 2004 15:38:53 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3JJcK7t014524; Mon, 19 Apr 2004 12:38:20 -0700 (PDT) Received: from stealth-10-32-245-156.cisco.com (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOF63387; Mon, 19 Apr 2004 12:38:19 -0700 (PDT) Date: Mon, 19 Apr 2004 15:38:15 -0400 From: "David R. Oran" To: Mary Barnes , sip@ietf.org Subject: Re: [Sip] History-Info status - Security open issue Message-ID: <2147483647.1082389095@[10.32.245.156]> In-Reply-To: <870397D7C140C84DB081B88396458DAF5791BA@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF5791BA@zrc2c000.us.nortel.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========9EE46D88AA1C8EF8814F==========" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --==========9EE46D88AA1C8EF8814F========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think it's fine to allow history-info to progress before we have e2m=20 security nailed. Think of how many hacks we can deprecate (which themselves = present the same security concerns) if we finally get this beastie=20 last-called. so, put me down in the "yes" column. Dave. --On Friday, April 16, 2004 11:04 AM -0500 Mary Barnes=20 wrote: > > Hi all, > > There are still two open issues around History-Info > (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt ) > that require list discussion: privacy and security. I'll post some > details on the privacy proposal in a separate posting so that I can more > easily track the responses. > > On the security, based upon some of the discussion in the e2m, m2e, > policy adhoc (per my recollection and the notes at: > http://softarmor.com/sipping/meets/ietf59/notes/notes-cyrus-sipping-adhoc > -ietf59.txt ) there does not seem to be WG consensus that History-Info > really requires m2e (i.e. TLS may be sufficient). I do agree that if > there was an m2e (and m2m) security mechanism in place for SIP at this > point in time, that the use of it for History-Info would add value and > actually make History-Info itself more useful to the end applications. > > What I would like to propose is that the draft reference the context of > some of these current works in progress in this area as informational and > possibly applicable to History-Info. And, of course, define TLS as the > normative and mandatory security solution for History-Info. This results > in the security for History-Info initially being as robust as that of the > other headers added by Intermediaries (Via, etc.), per RFC 3261 and in > the future, could be made more robust. In the end, it is up to the > applications making use of History-Info to choose the security solution > that best meets its requirements and if there is a m2m and m2e solution > developed in the future, applications can certainly take advantage of > those. > > If there's general agreement on this approach, I believe this only > requires some minor rewording in section 3.2. The remaining work to > complete the draft would be updating and cleaning up the examples. > > [I realize that this will likely start a long thread on the more general > topic of m2e, which does need discussion, but if folks could, please, > upfront in their postings say whether they believe History-Info can and > should be progressed without that solution fully specified]. > > Regards, > Mary > mary.barnes@nortelnetworks.com --==========9EE46D88AA1C8EF8814F========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAhCqnjWaEtlTdKuYRAtpJAJ4/yALcEhKdhR9Wmao42aZ5EmB0OQCfQW5e ldlTub0lEMYbFL46P11KnL8= =aEnF -----END PGP SIGNATURE----- --==========9EE46D88AA1C8EF8814F==========-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 16:12:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06758 for ; Mon, 19 Apr 2004 16:12:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf5Y-0002gr-EQ for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 16:09:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JK9uMh010334 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 16:09:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeoK-0007r6-Hs; Mon, 19 Apr 2004 15:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFefu-00063V-8z for sip@optimus.ietf.org; Mon, 19 Apr 2004 15:43:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05055 for ; Mon, 19 Apr 2004 15:43:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFefs-0002ym-QD for sip@ietf.org; Mon, 19 Apr 2004 15:43:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFef2-0002kS-00 for sip@ietf.org; Mon, 19 Apr 2004 15:42:33 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BFeeF-0002SP-00 for sip@ietf.org; Mon, 19 Apr 2004 15:41:43 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Apr 2004 11:52:35 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3JJf98k002601; Mon, 19 Apr 2004 12:41:10 -0700 (PDT) Received: from stealth-10-32-245-156.cisco.com (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOF63689; Mon, 19 Apr 2004 12:41:07 -0700 (PDT) Date: Mon, 19 Apr 2004 15:41:04 -0400 From: David Oran To: Mary Barnes , sip@ietf.org Subject: Re: [Sip] History-Info Privacy Issue Message-ID: <2147483647.1082389264@[10.32.245.156]> In-Reply-To: <870397D7C140C84DB081B88396458DAF5791BB@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF5791BB@zrc2c000.us.nortel.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Either resolution is fine with me. dave. --On Friday, April 16, 2004 11:05 AM -0500 Mary Barnes wrote: > > Per my posting on the status of History-Info, Privacy is one of the > remaining open issues. The proposal currently in the draft is quite > simple: > > If the Privacy header has a priv-value of "Session" or "Header" privacy, > the History-Info SHOULD not be included in the Request (or subsequent > responses). > > This is effectively applying the fundamental recommendation in RFC3323 > that any optional information that can divulge information about the > user(s) should not be included in the requests. > > A proposal was made that there are scenarios (e.g. where local policy > limits the applicability of History-Info within a specific domain) where > you would want to capture the History-Info but not send it beyond certain > intermediaries or domains. To support this, it was proposed that we > could extend the Privacy header defined in RFC 3323 with tags for > History-Info something like the following: > > priv-value = "history" / "history-index" > > The "history" priv-value would mean that all the History-Info entries > should be removed. The "history-index" would be used to indicate that > the specific entry is to be removed and would need to have the Privacy > header escaped in the URI so that it can be associated with a specific > History-Info entry (or we need to add another field to History-Info for > this). > > So, I think we have two options here: > 1) Extend History-Info to have an optional privacy field along the lines > of what's detailed above. > > 2) Defer the definition of the privacy field to a separate draft, since > it appears to be primarily limited to scenarios with certain trust > models. > > So, if folks could just take a bit of time and consider their preference, > I would like to get the draft updated soon and closed off prior to the > Interim meeting. > > Regards, > Mary H. Barnes > mary.barnes@nortelnetworks.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 16:30:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07901 for ; Mon, 19 Apr 2004 16:30:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfIG-00066c-Hx for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 16:23:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JKN4KX023464 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 16:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf8f-0003V8-Kn; Mon, 19 Apr 2004 16:13:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFez7-000197-07 for sip@optimus.ietf.org; Mon, 19 Apr 2004 16:03:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06288 for ; Mon, 19 Apr 2004 16:03:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFez5-000060-5d for sip@ietf.org; Mon, 19 Apr 2004 16:03:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFey3-0007eI-00 for sip@ietf.org; Mon, 19 Apr 2004 16:02:12 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BFex3-0007Jo-00 for sip@ietf.org; Mon, 19 Apr 2004 16:01:09 -0400 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 927B21FDCB; Mon, 19 Apr 2004 21:01:08 +0100 (BST) Date: Mon, 19 Apr 2004 21:00:32 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Klaus Darilion , Fredrik Thulin Cc: sip@ietf.org, Alex Bligh Subject: Re: [Sip] unanswered: RFC3261 & authenticating PROXIES to other proxies & UAS's Message-ID: <4156953332.1082408432@[192.168.100.5]> In-Reply-To: <4084290A.9020602@pernau.at> References: <200404190815.24768.ft@it.su.se> <4084290A.9020602@pernau.at> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 19 April 2004 21:31 +0200 Klaus Darilion wrote: > I think I found another problem - if the proxy inserts the Authentication > header, the authentication user will likely be different to the user in > the From: header. Such messages typically will be refused by a SIP proxy > as this allows to fake the sender id. That should not create a problem. The original proxy (the one inserting the header) will presumably have already authorized the user to /its/ satisfaction if it is going to then give its own credentials to the downstream proxy, i.e. in UAC ------> P1 ------> P2 ------> UAS P1 can authenticate UAC against its own database; only if it is authenticated will it in turn respond to an authentication request from either P2 or UAS. It is /desirable/ that the authentication user is different from the From: user. This allows P1 to identify /itself/ (in the authentication user). The idea of the scheme is to prevent P2, UAC from having to know credentials about UA's such as UAC. Whether the SIP Proxy P2 or the UAS refuses packets with an authentication user different from the From: user is a matter of local policy, and is explicitly not mandated in the standard. In SER, for example, you have to explicitly require that it checks this. It is quite legal for the auth user to differ from the From: user. All P2/UAS wants to know is that the call has been authorized **BY P1**. Whether this is the "remote media gateway in different administrative zone" problem, or the "I wish to authorize this SIP call to be diverted at my expense to my cellphone" problem... Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 16:57:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09702 for ; Mon, 19 Apr 2004 16:57:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfl5-0003TY-FI for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 16:52:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JKqpW0013328 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 16:52:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfab-00022w-L7; Mon, 19 Apr 2004 16:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfT9-0008PS-Ur for sip@optimus.ietf.org; Mon, 19 Apr 2004 16:34:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08108 for ; Mon, 19 Apr 2004 16:34:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfT7-000054-Tj for sip@ietf.org; Mon, 19 Apr 2004 16:34:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfSC-0007ce-00 for sip@ietf.org; Mon, 19 Apr 2004 16:33:21 -0400 Received: from webbox100.server-home.net ([195.137.212.21]) by ietf-mx with esmtp (Exim 4.12) id 1BFfRN-0007O5-00 for sip@ietf.org; Mon, 19 Apr 2004 16:32:29 -0400 Received: from pernau.at (mirnixdirnix.ict.tuwien.ac.at [128.131.80.218]) by webbox100.server-home.net (Postfix) with ESMTP id C6F1A1601F0; Mon, 19 Apr 2004 22:32:23 +0200 (CEST) Message-ID: <40843756.8070707@pernau.at> Date: Mon, 19 Apr 2004 22:32:22 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 0.5a (Windows/20040120) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: Fredrik Thulin , sip@ietf.org Subject: Re: [Sip] unanswered: RFC3261 & authenticating PROXIES to other proxies & UAS's References: <200404190815.24768.ft@it.su.se> <4084290A.9020602@pernau.at> <4156953332.1082408432@[192.168.100.5]> In-Reply-To: <4156953332.1082408432@[192.168.100.5]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Bligh wrote: > ... > Whether the SIP Proxy P2 or the UAS refuses packets with an authentication > user different from the From: user is a matter of local policy, and is > explicitly not mandated in the standard. In SER, for example, you > have to explicitly require that it checks this. It is quite legal for > the auth user to differ from the From: user. I do this check - but only for local users. So if P2 is the proxy of any termination provider, the From: will be an external domain for P2 and no check is necessary. Short answer: you are right - i shot too fast. I'm currently thinking about a really dirty hack for this: before forwarding the request in P1, the request will be handled to an externel script (exec module in ser). The script takes the request, decreases cseq by 1, sends the request to P2, catches the response, filters realm and nonce, calculates the hash and gives the new Authentication header back to ser (exec must be enhanced to add headers). Then ser will forward the request, which should now include proper credentials. Yes of course this is terrible and wont scale. :-) klaus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 17:43:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12479 for ; Mon, 19 Apr 2004 17:43:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgTP-000794-DY for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 17:38:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JLcdWT027444 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 17:38:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgK5-00056o-Qc; Mon, 19 Apr 2004 17:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgFc-00040C-55 for sip@optimus.ietf.org; Mon, 19 Apr 2004 17:24:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11542 for ; Mon, 19 Apr 2004 17:24:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFgFZ-0004iy-Nz for sip@ietf.org; Mon, 19 Apr 2004 17:24:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFgEk-0004Vg-00 for sip@ietf.org; Mon, 19 Apr 2004 17:23:31 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BFgEM-0004Hh-00 for sip@ietf.org; Mon, 19 Apr 2004 17:23:06 -0400 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 82B671FDCB; Mon, 19 Apr 2004 22:23:05 +0100 (BST) Date: Mon, 19 Apr 2004 22:22:30 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Klaus Darilion Cc: Fredrik Thulin , sip@ietf.org, Alex Bligh Subject: Re: [Sip] unanswered: RFC3261 & authenticating PROXIES to other proxies & UAS's Message-ID: <4161870954.1082413350@[192.168.100.5]> In-Reply-To: <40843756.8070707@pernau.at> References: <200404190815.24768.ft@it.su.se> <4084290A.9020602@pernau.at> <4156953332.1082408432@[192.168.100.5]> <40843756.8070707@pernau.at> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 19 April 2004 22:32 +0200 Klaus Darilion wrote: > I'm currently thinking about a really dirty hack for this: ... > Then ser will forward the request, which should now include proper > credentials. It doesn't actually look that hard to hack it in ser. But I know I will (rightly) get far more support from the iptel.org folks if there is some support for this "not being against the standard" or rather "a useful modification to the standard", hence my asking the question. I am sufficiently confident/pigheaded to think "it will work" anyway. [ your hack decrements cseq by one - I think you will run into the possibility with a collision with a previous message, and that the proxy etc. may thus ignore it thinking it's a retransmission - you would be better to use the same cseq but insert a bogus branch value; but even better, do it properly :-) ] Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 18:19:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16030 for ; Mon, 19 Apr 2004 18:19:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFh31-0002Ez-UK for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 18:15:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JMFRfe008604 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 18:15:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgsw-000621-4z; Mon, 19 Apr 2004 18:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgmZ-0002I9-EU for sip@optimus.ietf.org; Mon, 19 Apr 2004 17:58:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13544 for ; Mon, 19 Apr 2004 17:58:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFgmW-0005Td-OG for sip@ietf.org; Mon, 19 Apr 2004 17:58:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFgld-0005F2-00 for sip@ietf.org; Mon, 19 Apr 2004 17:57:29 -0400 Received: from webbox100.server-home.net ([195.137.212.21]) by ietf-mx with esmtp (Exim 4.12) id 1BFgkm-0004zN-00 for sip@ietf.org; Mon, 19 Apr 2004 17:56:36 -0400 Received: from pernau.at (mirnixdirnix.ict.tuwien.ac.at [128.131.80.218]) by webbox100.server-home.net (Postfix) with ESMTP id AC7EC160AC7; Mon, 19 Apr 2004 23:56:34 +0200 (CEST) Message-ID: <40844B12.5020605@pernau.at> Date: Mon, 19 Apr 2004 23:56:34 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 0.5a (Windows/20040120) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: Fredrik Thulin , sip@ietf.org Subject: Re: [Sip] unanswered: RFC3261 & authenticating PROXIES to other proxies & UAS's References: <200404190815.24768.ft@it.su.se> <4084290A.9020602@pernau.at> <4156953332.1082408432@[192.168.100.5]> <40843756.8070707@pernau.at> <4161870954.1082413350@[192.168.100.5]> In-Reply-To: <4161870954.1082413350@[192.168.100.5]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I just come around another problem: The reason for me to let the proxy doing the authentication is for example the following scenario: A small company (@smallcomp.com) has its own sip proxy (P1). Local and IP calls will work fine. Now, the company wants to make also PSTN calls, and gets a single account by any termination provider (vonage, sipgate, nikotel...) -> P2. So, their proxy P1 should forward PSTN calls to P2 and add credentials. And here is my problem - P2 will verify the From: header. P2 identifies an external user (@smallcomp.com != @nikotel.com) and refuses the request as externel users are not allowed to access the gateway, even if they would send proper credentials. Only local users will be asked for credentials. So, I can't use such a workaround anyway. and more generic: how will P2 know if the request from P1 should be challenged or handled as incoming call (without challenging)? klaus Alex Bligh wrote: > > > --On 19 April 2004 22:32 +0200 Klaus Darilion > wrote: > >> I'm currently thinking about a really dirty hack for this: > > ... > >> Then ser will forward the request, which should now include proper >> credentials. > > > It doesn't actually look that hard to hack it in ser. But I know I will > (rightly) get far more support from the iptel.org folks if there is some > support for this "not being against the standard" or rather "a useful > modification to the standard", hence my asking the question. I am > sufficiently confident/pigheaded to think "it will work" anyway. > > [ your hack decrements cseq by one - I think you will run into the > possibility with a collision with a previous message, and that the > proxy etc. may thus ignore it thinking it's a retransmission - you > would be better to use the same cseq but insert a bogus branch > value; but even better, do it properly :-) ] > > Alex > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 19:18:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20176 for ; Mon, 19 Apr 2004 19:18:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFhqc-0001Bp-3W for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 19:06:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JN6gQn004573 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 19:06:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFhhL-0006Xl-QH; Mon, 19 Apr 2004 18:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFhZC-0003z8-Ry for sip@optimus.ietf.org; Mon, 19 Apr 2004 18:48:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18222 for ; Mon, 19 Apr 2004 18:48:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFhZ9-0003MT-Kq for sip@ietf.org; Mon, 19 Apr 2004 18:48:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFhXx-00030M-00 for sip@ietf.org; Mon, 19 Apr 2004 18:47:27 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1BFhWu-0002Q9-00 for sip@ietf.org; Mon, 19 Apr 2004 18:46:21 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i3JMjASt002595; Mon, 19 Apr 2004 22:45:10 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 19 Apr 2004 18:45:10 -0400 Message-ID: From: "Peterson, Jon" To: "'Alex Bligh'" , sip@ietf.org Subject: RE: [Sip] RFC3261 and authenticating PROXIES to other proxies & U AS - 2 possible solutions Date: Mon, 19 Apr 2004 18:45:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I have some (lengthy) comments on this. First of all, "authenticating that a call has been transmitted by a proxy that the headers claimed transmitted it" is an aspect of a relatively familiar SIP problem called the "request history" problem. It is difficult to discuss this issue, or any solutions to it, outside of the long back-story of request history and middle-to-middle security. Please see Mary Barnes' work on the subject, especially her requirements and solutions drafts (some references are at the end of this mail). For the very simple SIP trapezoid case you describe below, there is of course a solution provided in RFC3261, specifically in 26.3.2.2: P1 and P2 would use mutual TLS to authenticate one another. In that fashion, P2 would have the necessary assurance that "the call came from P1", as your requirements below state. P1 is happy if the call came from the UAC, P2 is happy if it came from P1, and the UAS is happy if it came from P2 - we call all of this collective happiness "transitive trust". And unlike your solutions, it does not require that P1 and P2 exchange any keying information with one another. So why isn't 26.3.2.2 sufficient to solve all request history problems? Because sometimes transitive trust is insufficient. Request history also takes into account cases where the UAS, for example, would want to have a direct cryptographic assurance that P1 handled the call, rather than just being content to know that P2 forwarded it. So, if you're content with the simple transitive trust case, there's a solution for you already in RFC3261 - transitive trust and mutual TLS between P1 and P2. If you require something stronger than transitive trust, we've landed ourselves in request history / m2m territory. Now, specifically speaking to your solutions: the first one, as this thread noted earlier, suffers from a transaction-matching problem. In a nutshell, the problem is this: if the proxy server resubmits the INVITE (adding a Proxy-Authorization) with a new CSeq, then the UAC will reject the final response from the UAS since it is out of sequence (vide RFC3261 22.3). So why shouldn't P1 just resubmit the INVITE with the old CSeq and a Proxy-Authorization header? Well, for the sake of argument, let's say it could (although I remain a little nervous that implementation snafus with P2 matching nonces/transactions/branches/CSeqs could arise, since RFC3261 says that the resubmitted INVITE will arrive on a new CSeq). This approach suffers from the general problem of conflating the semantics of two distinct operations. Suppose that P1 resubmits the INVITE with credentials that are not accepted by P2, for whatever reason? How is the UAC going to understand that situation when the call fails? Also, shouldn't the UAC have its own opportunity to supply credentials to P2? If the user of the UAC has their own account/relationship with P2, they might want to rely on that rather than on allowing P1 to assert its own credentials - P1 is essentially interposing in the challenge. Essentially, by allowing P1 to consume the 407, you are proposing a change to the security semantics of the Digest mechanism. If I'm operating a proxy server, and I send a 407, I expect that the UAC will handle it and resubmit. I can imagine various scenarios in which I'd be unhappy if that challenge were intercepted and answered by a proxy server. If we did want to do something like this, I imagine we'd want a specific mechanism (new response code, or something) that makes it unambiguous that P2 intends to challenge P1 - see the m2m work. Moreover, there is a security concern here. The HTTP Digest authentication mechanism uses the concept of 'realms' (as has previously been discussed in this thread). In order to prevent a malicious proxy server from impersonating a realm (i.e., P3 spoofs, with its own nonces and so on, a challenge from P2 asserting the realm of P2, in an attempt to capture or interrupt authentication for P2's realm), realms must be correlated with certificate-based security. In fact, the recommendations in RFC3261 specifically state that the Digest realm should be identical to the subjectAltName in the certificate of the issuing proxy server - if they are not, there's always a potential for a security concern (26.3.2 passim). Accordingly, the establishment of a TLS connection (and the resulting certificate exchange) is more or less a prerequisite for the secure use of HTTP Digest. But of course, in your case, if certificates are exchanged, the use of HTTP Digest is entirely superfluous - you don't really care about the usernames/passwords, you just want to know which proxy server is forwarding the request. You'll get that information from TLS anyway. So using HTTP Digest without TLS is insecure, using it with TLS is superfluous. In short, my recommendation would be just to use mutual TLS. Regarding your second proposed solution, I think the n-squared problem of distributing and managing shared secrets for MD5 hashes in Via headers is intractable. For one thing, it requires you (as P1, say) to be able to anticipate ALL of the proxy servers/UASes to which your request might be forwarded, and to include suitable MD5 hashes for each. But the problem is, a proxy in the position of P1 simply doesn't know where their request is going to be forwarded. Sure, they know it is going to P2, but what if P2 forwards the request to P3 (because all of its UASes are overloaded, or something)? How is P1 supposed to know that it needs to insert a vauth parameter that will be verifiable by P3? Moreover, why on earth would P1 have exchanged a shared secret to every possible destination to which its requests could be forwarded? The fact that proxy servers are not psychic makes this extremely problematic. Moreover, since it is not a challenge-response system, it has extreme forgeability/replay problems. While the 'vauthexpire' parameter is obviously intended to mitigate the replay issue, as written, it is impracticable (i.e. messages containing it are silently discarded if vauthexpire is unsupported or invalid). And finally, as you hint, a malicious proxy server or man-in-the-middle could just strip this vauth parameter anyway. But of course, the only reason to have this parameter is because you don't trust the Via headers in the first place. And why don't you trust the Via headers? Because a malicious proxy server or man-in-the-middle could just strip or modify Via headers. So how exactly has the vauth parameter improved our situation? You don't trust an intermediary to keep leave the meat of the Via headers untouched, but you do trust them to leave vauth untouched? Mutual TLS between proxy servers prevents interceptors between the proxies from modifying signaling, but if the proxies are misbehaving, you're in the same boat with or without vauth. Might as well just use SIPS and mutual TLS to protect your Vias, or do something like request history and/or m2m. Earlier in the request history work, there were a number of proposed via-signing solutions along the lines of your second solution. I don't think an MD5-based Via header parameter is a profitable line of inquiry into this problem. I'd suggest contributing to the request history work if you're interested in some of the possible alternatives. Today, the mature form of that work is in: http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt You might also be interested inb the work on middle-to-middle security in: http://www.ietf.org/internet-drafts/draft-barnes-sipping-sec-inserted-info-0 1.txt Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Alex Bligh [mailto:alex@alex.org.uk] > Sent: Thursday, April 08, 2004 5:49 AM > To: sip@ietf.org > Cc: Alex Bligh > Subject: [Sip] RFC3261 and authenticating PROXIES to other > proxies & UAS > - 2 possible solutions > > > I am still trying to work out how one might authenticate that a call has > been transmitted by a proxy that the headers claimed transmitted it. SIP > provides facilities (in protocol) for proxies and UAS's to determine that a > call originated at a UAC with credentials, but no manner of determining > whether the call passed through a proxy with credentials. Whilst in some > circumstances this can be handled with network layer or transport layer > security, (a) this requires support on a hop by hop basis from the proxy > downstream, (b) the overhead may be substantial, and (c) it is somewhat > inconsistent that SIP supports this type of authentication > for the UAC but > not proxies. > > I've come up with 2 mechanisms to provide the support - one I posted > earlier (which requires only a change on the proxy with > credentials) and > goes into the "Despite being against RFC3261, I can't see > what this would > break" category, and the second (which requires a change both > at the proxy > supplying credentials and at the server authenticating them) certainly > breaks nothing, but is less functional. > > I'd appreciate comments, particularly on what the first > mechanism breaks. > I (now) know that it is (today) against various bits of RFC3261. But I > cannot see what in practice it would break. And as a couple of people > (on and off list) have pointed out, it would be very useful (even for > reasons I hadn't thought of). > > BACKGROUND > ========== > > The (general) problem I am trying to solve looks like this: > > > UAC <-----/\/\/\/\/---> P1 <--/\/--> P2 <---> UAS => PSTN > (CPE) (proxy) (proxy) (media > gateway) > > P2 may or may not be present. > > Let us assume UAC and P1 are very distant, and P1 & either P2 > or UAS are > sufficiently distant that host security is impractical > without adding some > additional layer (ipsec, tls etc.). > > UAC is CPE on a site of a customer of SP1, who operates P1. > UAS is a media > gateway, and P2 a (possibly) intervening proxy, operated by SP2. > > Let us further assume that UAC registers to P1, and that P1 > has already > authenticated UAC, and that any INVITE passed through P1 has > already been > authenticated as coming from UAC and been authorized by P1 > according to > SP1's local policy, prior to being forwarded to P2. > > Let us further assume that it is the local policy of SP1 that any such > authorized calls it passes to SP2 would be authorized by SP1. So for > instance SP2 is a VoIP termination provider, and SP1 a VoIP service > provider. > > SP2 wishes to authenticate & authorize calls made to UAS. It > uses some form > of authentication. What it in essence is trying to > authenticate is that the > call actually came from P1, not that the call actually came > from UAC. This > could either be done at P2, or at UAS. > > I have two mechanisms of doing this > > MECHANISM (AB)USING HTTP DIGEST AUTHENTICATION > ============================================== > > As per previous email, (ab)use HTTP digest authentication so > that the proxy retries the Invite with the same CSeq but with > a different branch parameter. This seems to me indistinguishable > from a spiraling scenario where the proxy concerned happens to > call the same Request-URI twice but other information in the message > header (in this case authentication) that may be used to route the > call has changed. > > As such, I can't see what it would break, and it has the major > advantage it works with all existing (challenging) UA's & proxies, > and that being challenge-response, it is more secure than > other mechanisms. > > But, for the sake of argument > > ALTERNATIVE MECHANISM USING vauth Via-Parameter > =============================================== > > This mechanism introduces a new Via Parameter (vauth). > > A UAC or Proxy inserting a Via Header with a RFC3261 compliant branch > parameter MAY introduce one or vauth parameter into the Via > header, in each > case to identify authenticate the via header to one or more downstream > proxies or UAS's. Such UAS's or proxies MAY use a vauth header to take > local-policy dependent routing or access decisions. A UAC or > Proxy which > does not insert a Via Header with a RFC3261 compliant branch > parameter MUST > NOT insert any vauth parameters. > > The vauth parameter is intended to allow a server to > authenticate a subset > of the Via: header (being the sent-by entry and the branch > token), together > with an opaque string, to downstream servers. Multiple vauth > parameters MAY > be used in order to support multiple realms of > authentication. The vauth > parameter supports extensible mechanisms of authentication, but the > mechanism specified herein is MD5 authentication using a > shared secret. > The mechanism of exchange of the shared secret and > authentication realm > is outside the scope of this document. > > The vauthid field specifies the realm of authentication. The > vauthid field > MUST be unique across instances if the vauth parameter in a > single Via: > header. Those specifying vauth fields SHOULD ensure that they > are globally > unique, for example a domain name MAY be used. > > The vauthopaque field is an opaque field intended to pass > information to > servers in the authentication realm which MAY be used to > influence their > routing decisions - for instance it might be used to specify > that access > should be permitted or denied, or have an accounting function. > > The vauthmeth field specifies the mechanism of > authentication. The only > currently defined method of authentication is MD5. In this > mechanism, the > vauthmd5data field contains a hash of the sent-by field, the branch > parameter (which is, by RFC3261 unique across time and > space), the vauthid > field, the vauthopaque field, the vauthexpire field (if any), and the > shared secret, which should be a string of printable > characters no more > than 64 octets in length. The hash is calculated using MD5 > (RFC 1321 [35]), > expressed in hexadecimal. > > The optional vauthexpire field is a date in the SIP date > format (i.e. the > preferred RFC1123 format) after which it should be assumed that the > header is not authentic. If a vauthexpire field is inserted, > the server > MUST be synchronized to an accurate time source, and the expiry time > MUST be no shorter than 32 seconds beyond the time at which the Via: > header is to be transmitted. > > A server MAY check the authenticity of a Via: header using > vauth parameters > by performing each of the following checks: > > 1. Isolate the vauth field(s) corresponding to a realm for which the > checking server possesses a shared secret. > > 2. If vauthexpire is present: if the checking server does not support > vauthexpire, it MUST silently discard the request. If the checking > server does support vauthexpire, it MUST check that the current > time is not beyond the expiry time, and if it is, it MUST > silently discard the request, else proceed. > The silent discards are used to ensure that excessive > transmission delays result only in the symptoms of packet loss, > rather than false authentication refusals. > > 3. The server MUST recalculate the hash value and check whether > it corresponds to the hash value in the vauthmd5data field. > > 4. The result of (3), the vauthopaque field, and the presence or > absence of a vauthexpire field, MAY then be used > to influence routing decisions > > The vauth mechnanism is primarily designed to protect against spoofing > attacks, as the shared secret will not be known. It provides > only limited > protection against replay attacks, in that replays are > time-limited by the > vauth-expire header. Further limitation of replay attacks can > be given by > the implementor using the vauthopaque field - for instance in an > environment where the Request-URI is known not to change > between the server > inserting the Via header and the server checking it, the > vauthopaque field > could be set to contain a hash of the Request-URI, which > could be checked > upon receipt. Further, it should be noted that mechanism provides no > protection against malicious or accidental modification of the message > between transmission by the server inserting the Via: header > and the server > analyzing it. It is not intended as a substitute for network > or transport > layer security. > > An example of a Via: header with vauth parameters follows: > Via: SIP/2/0/UDP 4.3.2.1:5060 branch=1fe452.12; > > vauth="server.example.com:5061,y,MD5=1234567890abcdef123456789 > 0abcdef"; > > vauth="server2.example.com:5060,,MD5=fedcba0987654321fedcba098 > 7654321:Fri, > 13 Oct 1998 23:50:00 GMT" > > RFC3261 specifies: > > via-params = via-ttl / via-maddr > / via-received / via-branch > / via-extension > via-extension = generic-param > generic-param = token [ EQUAL gen-value ] > gen-value = token / host / quoted-string > token = 1*(alphanum / "-" / "." / "!" / "%" / "*" > / "_" / "+" / "`" / "'" / "~" ) > > This document introduces a new via-param which matches the > generic-param > model: > > via-params = via-ttl / via-maddr > / via-received / via-branch > / via-vauth ; new > / via-extension > via-vauth = "vauth" EQUAL vauth > vauth = LTQUOT vauthid COMMA vauthopaque > COMMA vauthmeth [ COLON vauthexpire ]RDQUOT > vauthid = vauthstr > vauthopaque = [ vauthstr ] > vauthexpire = SIP-date > vauthstr = 1*(alphanum / "-" / "." / "/" / ":" / "_" / > "[" / "]") > vauthmeth = vauthmeth-md5 / vauthmeth-ext > vauthmeth-ext = vauthextension EQUAL vauthextdata > vauthextension = 1*(alphanum) > vauthextdat = 1*(alphanum) > vauthmeth-md5 = vauthmmd5 EQUAL vauthmd5data > vauthmmd5 = "MD5" > vauthmd5data = 32LHEX > > > Alex > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 19:20:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20305 for ; Mon, 19 Apr 2004 19:20:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFi1Q-0004kb-BG for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 19:17:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JNHqh2018251 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 19:17:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFho1-0000Rq-Fp; Mon, 19 Apr 2004 19:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFhcc-0005Af-0k for sip@optimus.ietf.org; Mon, 19 Apr 2004 18:52:14 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18625 for ; Mon, 19 Apr 2004 18:52:09 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BFhLe-0006vi-EB; Mon, 19 Apr 2004 18:34:42 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , sip mailing list , sip chair , sip chair Message-Id: Date: Mon, 19 Apr 2004 18:34:42 -0400 Subject: [Sip] Protocol Action: 'S/MIME AES Requirement for SIP' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has approved the following document: - 'S/MIME AES Requirement for SIP ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary RFC3261 currently specifies 3DES as the required minimum ciphersuite for implementations of S/MIME in SIP. This document updates the normative guidance of RFC3261 to require the Advanced Encryption Standard (AES) for S/MIME. Working Group Summary The Working Group supported this document. It was adopted immediately on its initial airing. It was gated by progress on S/MIME support. Protocol Quality General S/MIME implementation for SIP has been fairly slow to progress. Some prototype implementations have been tested at the SIP interoperability events, without testing their cryptography to date. The specification was reviewed for the IESG by Allison Mankin and Russ Housley. RFC Editor Notes OLD: S/MIME implementations MUST at a minimum support RSA as a digital signature algorithm, SHA1 as a digest algorithm, and AES as an encryption algorithm (as specified in [4]. For key wrap, S/MIME implementations MUST support the AES Key Wrap Algorithm ([5]). NEW: S/MIME implementations MUST at a minimum support RSA as a digital signature algorithm and SHA1 as a digest algorithm [ xx], and AES as an encryption algorithm (as specified in [yy]). For key transport, S/MIME implementations MUST support RSA key transport as specified in section 4.2.1 of [xx]. RFC Editor, replace [xx] with the citation number of a reference to RFC 3370 added to the Normative References. Replace [yy] with the citation number of a reference to RFC 3565 added to the Normative References. 3370 Cryptographic Message Syntax (CMS) Algorithms. R. Housley. August 2002. 3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS). J. Schaad. July 2003. **** Abstract OLD: required minimum ciphersuite NEW: mandatory-to-implement ciphersuite **** Section 4 OLD: Triples-DES NEW: Triple-DES **** Several places: Adjust line breaks to avoid funny line break placement -- Avoid S/ MIME _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 19:42:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21520 for ; Mon, 19 Apr 2004 19:42:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFiIX-0000Xe-0m for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 19:35:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JNZWK0002077 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 19:35:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFiAK-0007OO-IS; Mon, 19 Apr 2004 19:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFi5n-0006Ba-4h for sip@optimus.ietf.org; Mon, 19 Apr 2004 19:22:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20544 for ; Mon, 19 Apr 2004 19:22:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFi5l-0004Pj-Ge for sip@ietf.org; Mon, 19 Apr 2004 19:22:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFi4p-00049t-00 for sip@ietf.org; Mon, 19 Apr 2004 19:21:24 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BFi3q-0003cY-00 for sip@ietf.org; Mon, 19 Apr 2004 19:20:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 Apr 2004 15:30:04 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3JNJn7t012253; Mon, 19 Apr 2004 16:19:50 -0700 (PDT) Received: from imail.cisco.com (imail.cisco.com [172.19.216.204]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOF85977; Mon, 19 Apr 2004 16:19:49 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by imail.cisco.com (8.12.5/8.12.10) with SMTP id i3JKJgTh031394; Mon, 19 Apr 2004 16:19:42 -0400 From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16516.24213.193581.481291@thomasm-u1.cisco.com> Date: Mon, 19 Apr 2004 16:19:49 -0700 (PDT) To: "Peterson, Jon" Cc: "'Alex Bligh'" , sip@ietf.org Subject: RE: [Sip] RFC3261 and authenticating PROXIES to other proxies & U AS - 2 possible solutions In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! X-IMAIL-VERIFY: n X-IMAIL-SIG: v:"1"; h:"imail"; d:"cisco.com"; t:"1082405982.967867"; x:"1082837982"; a:"rsa-md5"; e:"Iw=="; n:"zENKN0zaH/mP5LiZTgt3a6GLujyFhzfX3u+xqFsgHQjb39S/iqb85nZyjukRv" "kkOMh2YpWWcJJqGivi7M6b6L07liP6grQ86f+CWrlVXfbFqtPDdHkna9WW6n3" "TI5DcA2TU4+Iuokj2oVeDfQFpnZqdNCGB/hDV+Q5qwTM4JIj0="; s:"Z9lvz+W7vCKeXCrzAZRzILmHN6LowfKn2Y0yntzO9aHEuR3jjjbEDuBSmQirv" "mSfAY73BeQgSGjlXY6K2FaGLmQqaQWn28OPtEqAoiIlTXWG3EyG8k2MOXneVZ" "yqMTsGDD/6Q+BKhuVtzqiocxX/60WSZR4oNKAVXelfBMcxuKU="; c:"From: Michael Thomas "; c:"Subject: RE: [Sip] RFC3261 and authenticating PROXIES to other proxies" " & U\n AS - 2 possible solutions" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Peterson, Jon writes: > Moreover, there is a security concern here. The HTTP Digest authentication > mechanism uses the concept of 'realms' (as has previously been discussed in > this thread). In order to prevent a malicious proxy server from > impersonating a realm (i.e., P3 spoofs, with its own nonces and so on, a > challenge from P2 asserting the realm of P2, in an attempt to capture or > interrupt authentication for P2's realm), realms must be correlated with > certificate-based security. In fact, the recommendations in RFC3261 > specifically state that the Digest realm should be identical to the > subjectAltName in the certificate of the issuing proxy server - if they are > not, there's always a potential for a security concern (26.3.2 passim). > Accordingly, the establishment of a TLS connection (and the resulting > certificate exchange) is more or less a prerequisite for the secure use of > HTTP Digest. But of course, in your case, if certificates are exchanged, the > use of HTTP Digest is entirely superfluous - you don't really care about the > usernames/passwords, you just want to know which proxy server is forwarding > the request. You'll get that information from TLS anyway. So using HTTP > Digest without TLS is insecure, using it with TLS is superfluous. I can think of a pretty trivial example, I think, that breaks this assumption. Suppose that I'm at a public kiosk UAC and want to read my voice mail back at mega.corprahome.com. The UAC would use TLS and cert based credentials to the first hop proxy, but my home proxie or UAS is going to want to see _my_ (as in mat@cisco.com's) credentials, not the UAC's. And telling me personally that I have to, well, use x.509 credentials is going to be something of a problem as I can barely remember a half way decent password, let alone ~2k characters of credentials. So it seems fairly obvious to me that you'd want to use x.509 credentials if you can, but the real world sez that they're not always going to be feasible, so you're really to have to deal with e2m, m2m, and e2e symmetric key credentials for... anything you can envision using asymmetric key credentials. In that case, TLS is providing a useful service (keeping outsiders of the conversation out), but doesn't really solve a pretty important case. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 19 20:04:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22593 for ; Mon, 19 Apr 2004 20:04:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFiiF-0006zk-2S for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 20:02:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K0276T026878 for sip-archive@odin.ietf.org; Mon, 19 Apr 2004 20:02:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFiUb-0004Hj-Vo; Mon, 19 Apr 2004 19:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFiTI-0003rJ-VA for sip@optimus.ietf.org; Mon, 19 Apr 2004 19:46:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21816 for ; Mon, 19 Apr 2004 19:46:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFiTH-0002c6-0u for sip@ietf.org; Mon, 19 Apr 2004 19:46:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFiSL-0002Md-00 for sip@ietf.org; Mon, 19 Apr 2004 19:45:42 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1BFiRo-00023s-00 for sip@ietf.org; Mon, 19 Apr 2004 19:45:08 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i3JNiOSt005229; Mon, 19 Apr 2004 23:44:24 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 19 Apr 2004 19:44:24 -0400 Message-ID: From: "Peterson, Jon" To: "'Michael Thomas'" Cc: "'Alex Bligh'" , sip@ietf.org Subject: RE: [Sip] RFC3261 and authenticating PROXIES to other proxies & U AS - 2 possible solutions Date: Mon, 19 Apr 2004 19:44:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I'm not sure you're breaking any assumption I had in mind, but... > > I can think of a pretty trivial example, I think, > that breaks this assumption. Suppose that I'm at > a public kiosk UAC and want to read my voice mail > back at mega.corprahome.com. The UAC would use TLS > and cert based credentials to the first hop proxy, > but my home proxie or UAS is going to want to see > _my_ (as in mat@cisco.com's) credentials, not > the UAC's. And telling me personally that I > have to, well, use x.509 credentials is going > to be something of a problem as I can barely > remember a half way decent password, let alone > ~2k characters of credentials. > I would not recommend that SIP users get PKI certs to vouch for their own identities (something, as far as I can recall, that I've never recommended). In the passage you cited, I recommended that proxy servers get PKI certs and use them to mutually authenticate one another on a hop-by-hop basis in SIP trapezoids, since that was the use case under discussion in Alex's mail, and as this would rid us of an insecurity in the proposed use of Digest for hop-by-hop proxy server mutual authentication. This is completely orthogonal to the end-to-end or end-to-middle authentication that you describe above. This is just middle-to-middle. > So it seems fairly obvious to me that you'd > want to use x.509 credentials if you can, but > the real world sez that they're not always > going to be feasible, so you're really to have > to deal with e2m, m2m, and e2e symmetric key > credentials for... anything you can envision > using asymmetric key credentials. In that case, > TLS is providing a useful service (keeping > outsiders of the conversation out), but doesn't > really solve a pretty important case. > TLS provides an important and feasible service even for e2m-ish cases - when a UAC authenticates itself to a proxy server via symmetric credentials like Digest (over TLS), the proxy server authenticates itself to the UAC with asymmetric credentials(passed in TLS). This does not require or even suggest that users should get their own X.509 certificates - merely that users are able to validate certificates and signatures, and so on. This is in keeping with the baseline RFC3261 recommendations for end-user authentication (RFC3261 26.3.2). > Mike > Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 20 04:32:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01548 for ; Tue, 20 Apr 2004 04:32:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqZR-0007Gd-64 for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 04:25:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K8PX5F027935 for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 04:25:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqNL-0004Kz-Ee; Tue, 20 Apr 2004 04:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqJD-0003HA-V1 for sip@optimus.ietf.org; Tue, 20 Apr 2004 04:08:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00232 for ; Tue, 20 Apr 2004 04:08:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFqJB-0005dj-8K for sip@ietf.org; Tue, 20 Apr 2004 04:08:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFqIK-0005Oe-00 for sip@ietf.org; Tue, 20 Apr 2004 04:07:52 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx with esmtp (Exim 4.12) id 1BFqHX-0004tz-00 for sip@ietf.org; Tue, 20 Apr 2004 04:07:03 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HWG00001MGLC2@siemenscomms.co.uk> for sip@ietf.org; Tue, 20 Apr 2004 09:05:09 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HWG00M96MGLHH@siemenscomms.co.uk>; Tue, 20 Apr 2004 09:05:09 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2653.19) id <29J840L1>; Tue, 20 Apr 2004 09:06:33 +0100 Content-return: allowed Date: Tue, 20 Apr 2004 09:06:32 +0100 From: "Elwell, John" Subject: RE: [Sip] History-Info status - Security open issue To: "'Mary Barnes'" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670252CFA3@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Mary, I would support the solution you propose for progressing History-Info. John Elwell (john.elwell@siemens.com) -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] Sent: 16 April 2004 17:05 To: sip@ietf.org Subject: [Sip] History-Info status - Security open issue Hi all, There are still two open issues around History-Info (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt ) that require list discussion: privacy and security. I'll post some details on the privacy proposal in a separate posting so that I can more easily track the responses. On the security, based upon some of the discussion in the e2m, m2e, policy adhoc (per my recollection and the notes at: http://softarmor.com/sipping/meets/ietf59/notes/notes-cyrus-sipping-adhoc-ie tf59.txt ) there does not seem to be WG consensus that History-Info really requires m2e (i.e. TLS may be sufficient). I do agree that if there was an m2e (and m2m) security mechanism in place for SIP at this point in time, that the use of it for History-Info would add value and actually make History-Info itself more useful to the end applications. What I would like to propose is that the draft reference the context of some of these current works in progress in this area as informational and possibly applicable to History-Info. And, of course, define TLS as the normative and mandatory security solution for History-Info. This results in the security for History-Info initially being as robust as that of the other headers added by Intermediaries (Via, etc.), per RFC 3261 and in the future, could be made more robust. In the end, it is up to the applications making use of History-Info to choose the security solution that best meets its requirements and if there is a m2m and m2e solution developed in the future, applications can certainly take advantage of those. If there's general agreement on this approach, I believe this only requires some minor rewording in section 3.2. The remaining work to complete the draft would be updating and cleaning up the examples. [I realize that this will likely start a long thread on the more general topic of m2e, which does need discussion, but if folks could, please, upfront in their postings say whether they believe History-Info can and should be progressed without that solution fully specified]. Regards, Mary mary.barnes@nortelnetworks.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 20 05:08:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03465 for ; Tue, 20 Apr 2004 05:08:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFrBm-0000lf-ON for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 05:05:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K95AMY002941 for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 05:05:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFr1z-0006Vq-9Z; Tue, 20 Apr 2004 04:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFquE-0004ss-1W for sip@optimus.ietf.org; Tue, 20 Apr 2004 04:47:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02458 for ; Tue, 20 Apr 2004 04:46:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFquA-0000NW-UK for sip@ietf.org; Tue, 20 Apr 2004 04:46:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFqtC-00006g-00 for sip@ietf.org; Tue, 20 Apr 2004 04:45:59 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BFqsQ-0007ca-00 for sip@ietf.org; Tue, 20 Apr 2004 04:45:10 -0400 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 3FF5A1FDCB; Tue, 20 Apr 2004 09:45:10 +0100 (BST) Date: Tue, 20 Apr 2004 09:44:33 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Peterson, Jon" , sip@ietf.org Cc: Alex Bligh Subject: RE: [Sip] RFC3261 and authenticating PROXIES to other proxies & U AS - 2 possible solutions Message-ID: <4202794258.1082454273@[192.168.100.5]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jon, Thanks for your mail. There are several things I will have to think further about in it, but here are some comments on bits of it: > For the very simple SIP trapezoid case you describe below, there is of > course a solution provided in RFC3261, specifically in 26.3.2.2: P1 and P2 > would use mutual TLS to authenticate one another. In that fashion, P2 > would have the necessary assurance that "the call came from P1", as your > requirements below state. P1 is happy if the call came from the UAC, P2 is > happy if it came from P1, and the UAS is happy if it came from P2 - we > call all of this collective happiness "transitive trust". And unlike your > solutions, it does not require that P1 and P2 exchange any keying > information with one another. TLS is neither a necessary nor sufficient solution, I think. Here are some reasons. a) In the trapezoid, it does not cover the situation where UAS wants to authenticate P1 (possibly against injection at P2), or where a third proxy P3 wants to authenticate P1. This is because TLS is essentially hop-by-hop. A further consequence of this is we need to TLS secure every possible hop between authenticator and authenticatee, which presupposes we know each possible route packets may take in advance. Certainly in the trapezoid illustration I presented, that is true, but I think it would be a mistake to assume hop-by-hop security is per-se equivalent to middle-to-middle security (or, in the case of UAS, end-to-middle security). This is precisely because we may not always be able to rely on hop-wise transitive trust. b) You say P1 and P2 don't exchange any keying information; I think that's not entirely true. They do exchange keying, just at the TLS layer. c) Using TLS requires it to be supported and switched on. Whilst this may well be a "good thing", there are plenty of instances in where it currently is unsupported, and plenty of instances in applications crossing administrative domains where turning it on is not necessarily simple. It also requires certification which may be a too heavyweight solution. We allow non-TLS digest authentication under 3261 providing the UAC is providing the credentials (misusing the terminology start-to-middle auth) - my argument is not to replace TLS, simply that the same mechanism could be used for middle-to-middle and middle-to-end. > So why isn't 26.3.2.2 sufficient to solve > all request history problems? Because sometimes transitive trust is > insufficient. Request history also takes into account cases where the UAS, > for example, would want to have a direct cryptographic assurance that P1 > handled the call, rather than just being content to know that P2 forwarded > it. I think the request-history stuff (which I have only briefly read) is trying to solve a slightly different problem; it seems to be more about the ability for a downstream node to be able to determine how and why a request reached it. In the problem space I'm looking out, the downstream node (P2 or UAS) does not care how the request reached it, merely that it has passed through P1. Further, it's eminently possible that any credential challenge it seeks to make may be dependent on routing information available to P2 only when the packet arrives - for instance some URIs might be billable, and some not billable. As request-history doesn't give P2 the mechanism to challenge P1, this would seem to require P1 either giving P2 "free reign", or having a complete understanding of P2's own authentication rules. > Now, specifically speaking to your solutions: the first one, as this > thread noted earlier, suffers from a transaction-matching problem. In a > nutshell, the problem is this: if the proxy server resubmits the INVITE > (adding a Proxy-Authorization) with a new CSeq, then the UAC will reject > the final response from the UAS since it is out of sequence (vide RFC3261 > 22.3). To be clear, I am advocating resubmitting with the same CSeq and a different branch ID. > So why shouldn't P1 just resubmit the INVITE with the old CSeq and > a Proxy-Authorization header? Well, for the sake of argument, let's say it > could (although I remain a little nervous that implementation snafus with > P2 matching nonces/transactions/branches/CSeqs could arise, since RFC3261 > says that the resubmitted INVITE will arrive on a new CSeq). > > This approach suffers from the general problem of conflating the semantics > of two distinct operations. Suppose that P1 resubmits the INVITE with > credentials that are not accepted by P2, for whatever reason? How is the > UAC going to understand that situation when the call fails? When P1 resubmits the invite, P2 will respond with a further 407. Just as a UAC can distinguish the "first" 407 (when it needs to add credentials, or notes the nonce has expired) from a subsequent 407, so can P1, using the same mechanism. On receipt of a second 407, P1 sends a 4xx upstream to the UAC saying "call failed" - doesn't much matter which 4xx code so long as it isn't 407 etc.; alternatively it can reroute just as it might if it received a 404 (say) from P2. What it isn't to do is pass the 407 straight to UAC (as it will then seek credentials etc.) > Also, > shouldn't the UAC have its own opportunity to supply credentials to P2? > If the user of the UAC has their own account/relationship with P2, they > might want to rely on that rather than on allowing P1 to assert its own > credentials - P1 is essentially interposing in the challenge. This, it seems to me, is a policy decision for P1 and P2. P2 sees the packet purports to come via P1 (it is unimportant for this purpose whether it actually comes via P1), and thus use a realm identifier that P1 matches, on the basis that P1 has asked that /it/ supply credentials to P2. If the packet does not purport to come via P1, P2 might use a different realm. I fail to see a useful application where P2 wishes first to challenge P1, and then P1. I'm not saying there is no such case, and to the extent there is, it is a limitation of this mechanism. > Essentially, by allowing P1 to consume the 407, you are proposing a > change to the security semantics of the Digest mechanism. If I'm > operating a proxy server, and I send a 407, I expect that the UAC will > handle it and resubmit. I can imagine various scenarios in which I'd be > unhappy if that challenge were intercepted and answered by a proxy > server. I don't understand why. You may well be "unhappy" about it, but it doesn't weaken security any putting it in the standard, as people can do this /now/ (in apparent breach of the RFC). IE as P2 you already have to cope with the situation that people might attempt to intercept and reply to an upstream challenge. Note the intercept will be unsuccessful unless the interceptor has valid credentials. So if you don't like it, don't give credentials to those "in the middle". Perhaps I am missing the point here. > If we did want to do something like this, I imagine we'd want a > specific mechanism (new response code, or something) that makes it > unambiguous that P2 intends to challenge P1 - see the m2m work. That's what I am trying to /avoid/. Take an extended trapezoid UAC ... P1 ... P2 ... P3 ... P4 ... UAS, and let's say P4 or UAS is performing the challenge. P3 is in the same administrative domain as P4 & UAS. P4/UAS may not know whether it's P1, or P2 that is going to authenticate the request. And moreover, it may not care. All it cares is that /someone/ has authenticated the request. If you are suggesting that there should be some additional field in the Authorization: header, which P1 (etc.) must fill in indicating that it is the one providing the credentials, then (provided it isn't going to break existing challengers) that seems like a good idea, as it will allow those challengers to discard such responses if they want. > Moreover, there is a security concern here. The HTTP Digest authentication > mechanism uses the concept of 'realms' (as has previously been discussed > in this thread). In order to prevent a malicious proxy server from > impersonating a realm (i.e., P3 spoofs, with its own nonces and so on, a > challenge from P2 asserting the realm of P2, in an attempt to capture or > interrupt authentication for P2's realm), realms must be correlated with > certificate-based security. Perhaps I am missing something here, but doesn't this problem exist to EXACTLY the same extent whether credentials are supplied to P2 by P1 (as suggested), or by UAC (as per the existing standard). IE yes, it exists, but no, the proposal doesn't make it any worse. Moreover, they both can be solved to the same extent in the same manner. > In fact, the recommendations in RFC3261 > specifically state that the Digest realm should be identical to the > subjectAltName in the certificate of the issuing proxy server - if they > are not, there's always a potential for a security concern (26.3.2 > passim). Accordingly, the establishment of a TLS connection (and the > resulting certificate exchange) is more or less a prerequisite for the > secure use of HTTP Digest. ... (depending on which aspect of security you are concerned about), yes, but equally so for conventional challenges and the challenges I suggest. However, unless I'm mistaken, even TLS doesn't solve everything: D1 : D2A : D3 : D4 : : : --:--P1-----P2-:---P3--:--P4----P5-- / : : | : \ UAC :............: | : UAS \ : : / --:--P11---P12-:-/ : : : D2B : Let's assume D1, D2A, D2B, D3, D4 are different administrative domains. Suppose P5 challenges UAC. TLS on each hop will prevent an attack from an arbitrary P99, but it won't (as far as I can see) prevent (say) P2, P3 impersonating P5's realm, unless UAC has some direct certificate exchange with P5. And that's no greater and no lesser a problem than if P5 is challenging P1 (as I suggest), and or P5 challenging UAC. > But of course, in your case, if certificates > are exchanged, the use of HTTP Digest is entirely superfluous - you don't > really care about the usernames/passwords, you just want to know which > proxy server is forwarding the request. No, that's not true - possibly that impression has been given by me being less than clear. Using the above extended trapezoid, P5 wants to know an administrative domain with whom it has a trust relationship authorizes the routing. That might be (say) any one of P1..P2 or their redundant siblings. So it wants to know someone from D2A authenticated the transaction. It does indeed care about the username (which identifies it came from D2A, as opposed to D2B). And it cares about the password too, as that authenticates it comes from D2A as opposed to D2B. > You'll get that information from > TLS anyway. So using HTTP Digest without TLS is insecure, using it with > TLS is superfluous. Only if it is the immediately preceding hop (unless I've missed something) > In short, my recommendation would be just to use mutual TLS. I am not denying that TLS is helpful - I think it's orthogonal to the problem though, just as TLS does not replace the existing digest authentication but is best used in parallel with it. > Regarding your second proposed solution, It's (the vauth header stuff) is clearly inferior to the first, and if the request-history stuff can be authenticated, it's largely pointless. But for the same reasons I identify above, I don't think even an authenticated request-history solves the problems I am talking about. Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 20 05:50:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05376 for ; Tue, 20 Apr 2004 05:50:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFrs4-0002YM-Ss for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 05:48:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K9mqg0009787 for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 05:48:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFrjc-0000mR-Ci; Tue, 20 Apr 2004 05:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFrfa-0007xo-Dk for sip@optimus.ietf.org; Tue, 20 Apr 2004 05:35:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04874 for ; Tue, 20 Apr 2004 05:35:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFrfW-0005iq-Ub for sip@ietf.org; Tue, 20 Apr 2004 05:35:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFrei-0005TM-00 for sip@ietf.org; Tue, 20 Apr 2004 05:35:05 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BFre7-00059X-00 for sip@ietf.org; Tue, 20 Apr 2004 05:34:27 -0400 Received: from earth.office (earth.office [10.1.1.5]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i3K9Xuri073986 for ; Tue, 20 Apr 2004 11:33:56 +0200 (CEST) Received: from netlab.nec.de (n-stud14-e.students [10.1.2.119]) by earth.office (Postfix) with ESMTP id 5C52063166 for ; Tue, 20 Apr 2004 11:30:38 +0200 (CEST) Message-ID: <4084EEDF.9080109@netlab.nec.de> Date: Tue, 20 Apr 2004 11:35:27 +0200 From: Ali Fessi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] User-to-User Authentication Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, RFC3261 provides mechanisms for authentication user agent-to-user agent. (Section 22.2) The UAC is required to provide some credentials. Although that might be not a part of the standard, but I would like to know how the UAs should agree on the credentials. This assumes that the UAs "know" each other! In some environments this might be realized with a trust third party that distributes the credentials. But what is if the UAs don't have any trust relationship?! Regards, Ali. -- Ali Fessi NEC Network Laboratories _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 20 10:05:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19228 for ; Tue, 20 Apr 2004 10:05:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvla-0006cE-DF for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 09:58:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KDwQ1I025424 for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 09:58:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvZk-0000AB-In; Tue, 20 Apr 2004 09:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvQs-0002t1-Gd for sip@optimus.ietf.org; Tue, 20 Apr 2004 09:37:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17268 for ; Tue, 20 Apr 2004 09:37:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvQq-0001vU-Mt for sip@ietf.org; Tue, 20 Apr 2004 09:37:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvPq-0001dV-00 for sip@ietf.org; Tue, 20 Apr 2004 09:35:59 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BFvOt-0001L2-00 for sip@ietf.org; Tue, 20 Apr 2004 09:34:59 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KDYvk29721 for ; Tue, 20 Apr 2004 16:34:57 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 16:34:52 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3KDYqLt032389 for ; Tue, 20 Apr 2004 16:34:52 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 000j4fem; Tue, 20 Apr 2004 16:34:51 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KDYnF25011 for ; Tue, 20 Apr 2004 16:34:49 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 16:31:18 +0300 Received: from agni.research.nokia.com (hedhc04nrc040-139.research.nokia.com [172.21.40.139]) by kusti.research.nokia.com (Postfix) with ESMTP id 642D093B84 for ; Tue, 20 Apr 2004 16:30:30 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i3KDRXd1029546 for ; Tue, 20 Apr 2004 16:27:33 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i3KDRXpi029545; Tue, 20 Apr 2004 16:27:33 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: sip@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Tue, 20 Apr 2004 16:27:33 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 20 Apr 2004 13:31:18.0468 (UTC) FILETIME=[C3034040:01C426DB] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] Error in RFC 3261 definition of the Accept header syntax Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello all, RFC 3261 defines the Accept header as follows: 20.1 Accept The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header field is present, the server SHOULD assume a default value of application/sdp. [H14.1] refers to RFC 2616 section 14.1, which plainly states that there must be a q parameter between media-type-specific parameters and other accept-parameters, IOW the first accept-parameter must always be q parameter. Now, the grammar part in RFC 3261 defines syntax for the Accept header as follows: Accept = "Accept" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range = ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-param = ("q" EQUAL qvalue) / generic-param The error was introduced during the great grammar rewrite, I believe. The RFC3261-style syntax following the [H14.1] would be as follows: Accept = "Accept" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range [ accept-params ] media-range = ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-params = SEMI "q" EQUAL qvalue *(SEMI generic-param) --Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 20 18:17:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02525 for ; Tue, 20 Apr 2004 18:17:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Mv-0004sR-3g for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 18:05:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KM5TSB018740 for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 18:05:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG33i-0000P7-NP; Tue, 20 Apr 2004 17:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2Fy-0007oY-M5 for sip@optimus.ietf.org; Tue, 20 Apr 2004 16:54:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24126 for ; Tue, 20 Apr 2004 16:54:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG2Fw-0004j7-FU for sip@ietf.org; Tue, 20 Apr 2004 16:54:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2F9-0004cy-00 for sip@ietf.org; Tue, 20 Apr 2004 16:53:25 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1BG2E0-0004KE-00 for sip@ietf.org; Tue, 20 Apr 2004 16:52:12 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i3KKpZSt030700; Tue, 20 Apr 2004 20:51:36 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Apr 2004 16:51:35 -0400 Message-ID: From: "Peterson, Jon" To: "'Alex Bligh'" , sip@ietf.org Subject: RE: [Sip] RFC3261 and authenticating PROXIES to other proxies & U AS - 2 possible solutions Date: Tue, 20 Apr 2004 16:51:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Okay. At a high level, I understand that you don't think transitive trust meets your requirements, because you envision situations in which there are multiple intermediaries or in which there is a need for a security asseriton between entities that are not directly connected to one another. In those circumstances, I agree that mutual TLS is not sufficient. I do think that mutual TLS is (by definition) sufficient for the (hopefully) common trapezoid case in which P1 and P2 need to mutually authenticate one another. I also understand that you feel request history is trying to solve a different problem. I agree that request history is (possibly) broader than what you want to do, but I do think it nicely encompasses the use cases and requirements that you have articulated so far. While your note suggests that Digest challenges from P2 could be customized in some fashion to the particular circumstances of the transaction, that idea would need to be flushed out a bit more before we can make any judgment about whether or not request history cannot meet the underlying requirement. Whatever the requirement is there, it could possibly serve as input to ongoing considerations of the request history problem. Finally, I remain unpersuaded that Digest authentication challenge interception at proxies is really the right way to go, for two main reasons: - I think you underestimate the complexity of pre-sharing symmetric keys for proxy servers. Sharing symmetric keys works well as a deployment model for the sorts of cases where usernames and passwords are successful today. For monolithic servers like proxies, a PKI-based approach has a much cleaner deployment model that does not suffer from any n-squared pre-sharing problems. Proxy servers shouldn't have to have pre-shared keys in order to be able to identify one another; their relationships are just too transient and they may need to relate to way too many peers (unlike, say an end user's relationship with a PSTN termination service). - Challenge interception bends the semantics of the Digest authentication system in ways that have foreseen undesirable consequences, and may have unforeseen undesirable consequences. If we really need a way to do this, it should be specific to challenging proxies, and not conflated with challenges that are semantically designated for end users in RFC3261. More details responses are below, for the truly dedicated. Jon Peterson NeuStar, Inc. ---- > TLS is neither a necessary nor sufficient solution, I think. Here are > some reasons. > a) In the trapezoid, it does not cover the situation where UAS wants > to authenticate P1 (possibly against injection at P2), or where a > third proxy P3 wants to authenticate P1. Well, as I said, I wasn't sure if you were satisfied with transitive trust, or if you wanted to solve the full gamut of middle-to-middle problems. I was trying to flush out your problem a bit. If the cases above are in your requirements space, then I agree, TLS is not sufficient, and you need something like request history / m2m. I also get the sense that you require middle-to-end authentication as well. > b) You say P1 and P2 don't exchange any keying information; I think > that's not entirely true. They do exchange keying, just at the TLS > layer. I said that they do not have to pre-share their keying material with one another. In order for Digest to work, P1 and P2 need to have shared symmetric keys at some prior point in time. In TLS, P1 and P2 need never to have met before in order to validate one anothers' certificates when they are exchanged during the TLS handshake. One cannot dynamically exchange symmetric keys in the same fashion for the purposes of Digest authentication. In order for TLS to work, P1 and P2 only need to be in the same PKI. There is a world of difference between the deployments for which these alternatives are valid. > c) Using TLS requires it to be supported and switched on. Whilst this > may well be a "good thing", there are plenty of instances in > where it currently is unsupported This argument is of the form "your mechanism isn't implemented or used very widely, but my (purely conceptual and totally unimplemented) proposal doesn't suffer from that problem." While it may be annoying to deploy a PKI, I believe it is much more annoying to deploy and n-squared mesh of symmetric keys to proxy servers, especially given the fact that it is very difficult to anticipate which proxy servers are likely to need to have a relationship with one another. And again, just so there's no mistake, I'm talking about giving certificates to proxy servers here, not end users. The issues with giving certificates to end users are well known, and essentially insurmountable in our problem space. > > > So why isn't 26.3.2.2 sufficient to solve all request history problems? > I think the request-history stuff (which I have only briefly read) is > trying to solve a slightly different problem; it seems to be more about the > ability for a downstream node to be able to determine how and why a request > reached it. But surely you agree that solving the request history problem also solves the problem of determining whether or not a request when through a given proxy server - it is sufficient, if not necessary. I also pointed you to the m2m/m2e work, which is perhaps more directly applicable. The two are pretty inextricably linked in my mind, though. > Further, it's eminently possible that any credential challenge > it seeks to make may be dependent on routing information available to P2 > only when the packet arrives - for instance some URIs might be billable, > and some not billable. As request-history doesn't give P2 the mechanism to > challenge P1, this would seem to require P1 either giving P2 "free reign", > or having a complete understanding of P2's own authentication rules. Well, this is a requirement I didn't understand from your previous mails, and one I'm still not sure I understand now. In what sense might the credential challenge be different? Isn't the purpose of this challenge to ascertain the identity of an intermediary? If so, that identity information will be provided by request history. The "billability" of a URI wouldn't impact P2's challenge in any obvious way - except perhaps insofar as it might choose not to issue a call if the transaction has no settlement implications, or something. Whatever it is you mean here, it sounds like you are going beyond just knowing that a request passed through P1 on the way to P2. If there is additional information that P1 might provide which would be instrumental in P2's decision, that's something that should be factored into the request history work as well. As you noted, request history can carry additional information that helps its consumer to make decisions. If you mean that P2 might challenge with a different realm, or something, see my notes on realm below. I'm not really sure what else about the challenge P2 might change in order to elicit a different response from P1, and realms in SIP are intended to be scoped to domain, not chosen arbitrarily. > > > > Suppose that P1 resubmits the INVITE with > > credentials that are not accepted by P2, for whatever reason? How is the > > UAC going to understand that situation when the call fails? > > On receipt of a second 407, P1 sends a 4xx upstream to the > UAC saying "call failed" - doesn't much matter which 4xx code so long as it > isn't 407 etc.; alternatively it can reroute just as it might if it > received a 404 (say) from P2. What it isn't to do is pass the 407 > straight to UAC (as it will then seek credentials etc.) > This is more or less exactly my point. P1 is shielding the UAC from the authentication system. What if P2 wants to authenticate the UAC, not P1? What gives P1 the right to interpose? This is why, if we want to authenticate proxies with Digest, we should use a new, unambiguous status code - so P1 can know whether it should consume and reply to the challenge, or whether it should forward them back. You're conflating two semantically distinct operations. > > If the user of the UAC has their own account/relationship with P2, they > > might want to rely on that rather than on allowing P1 to assert its own > > credentials - P1 is essentially interposing in the challenge. > > This, it seems to me, is a policy decision for P1 and P2. So it's a policy decision, one that can be made by any old proxy server in the response path, whether or not the UAC should be entitled to respond to a 407 challenge? That sets a very dangerous precedent of interventionism, from my perspective. I can imagine several cases where I personally might have an account on P2 (say, P2 is a proxy for a PSTN termination service), but my local proxy server, which obstinantly insists in the face of all evidence that it has or must have an account at P2, refuses to let me answer the challenge. The Digest tools are intended for authentication of the UAC. If you want a tool to authenticate middlemen, then please propose something distinct that accomplishes that function rather than conflating this with an existing tool which does something else entirely. But of course, once you do, you're effectively in the m2m space, and you should be contributing to the longstanding existing work that has been done there. > P2 sees the > packet purports to come via P1 (it is unimportant for this purpose whether > it actually comes via P1), and thus use a realm identifier that P1 matches, > on the basis that P1 has asked that /it/ supply credentials to P2. If > the packet does not purport to come via P1, P2 might use a different > realm. This is contrary to the meaning of realm as it is defined in RFC3261, which is not as broad as the definition of realm in RFC2617. > I fail to see a useful application where P2 wishes first > to challenge P1, and then P1. I'm not saying there is no such case, > and to the extent there is, it is a limitation of this mechanism. > > > Essentially, by allowing P1 to consume the 407, you are proposing a > > change to the security semantics of the Digest mechanism. If I'm > > operating a proxy server, and I send a 407, I expect that the UAC will > > handle it and resubmit. I can imagine various scenarios in which I'd be > > unhappy if that challenge were intercepted and answered by a proxy > > server. > > I don't understand why. You may well be "unhappy" about it, but it > doesn't weaken security any putting it in the standard, as people > can do this /now/ (in apparent breach of the RFC). "Unhappy" = my PSTN termination service might be getting revenue from a paying customer, if the proxy at P1 were not preventing me from authenticating my customer. Understand? I agree that this isn't a potential security violation as such, it's an introduction of an intermediary that can impede the operation of an existing security mechanism (as a trade-off in order to facilitate an unrelated security operation). SIP intermediaries today can also choose to replace the Contact header field, the m= and c= lines of the SDP, and other aspects of messages with the content of their choosing, in apparent breach of the RFC, as you say. This does not mean that we should publish standards that condone any possible course of action that a protocol entity might take to mangle SIP. > IE as P2 you already > have to cope with the situation that people might attempt to > intercept and reply to an upstream challenge. Note the intercept > will be unsuccessful unless the interceptor has valid credentials. > So if you don't like it, don't give credentials to those "in the > middle". Perhaps I am missing the point here. > Well, in your case as described above, if the interceptor in the middle does not have valid credentials, they send back a cryptic 4xx message to the UAC, effectively saying "your call failed". So, if P1 does act this way, and the UAC has valid credentials, a call fails which should not have failed. Perhaps that is the point here. > > If we did want to do something like this, I imagine we'd want a > > specific mechanism (new response code, or something) that makes it > > unambiguous that P2 intends to challenge P1 - see the m2m work. > > That's what I am trying to /avoid/. Take an extended trapezoid > UAC ... P1 ... P2 ... P3 ... P4 ... UAS, and let's say P4 or UAS is > performing the challenge. P3 is in the same administrative domain > as P4 & UAS. P4/UAS may not know whether it's P1, or P2 that is > going to authenticate the request. And moreover, it may not care. > All it cares is that /someone/ has authenticated the request. > ... well, that isn't how I originally understood your requirements from your earlier mail, but okay. I think that this just broadens your problem space, and makes it much clearer to me that you want something like RH/M2M/M2E. Also, be careful when you say that it doesn't care who authenticated the request. I assume you mean that it doesn't care who replied to the challenge. But what is the purpose of replying to the challenge? To provided credentials proving someone's identity. That is the key to this. I don't think there's something magical about Digest as a means to prove identity. With request history, P4 would see the identity of P1, P2 and P3, with a cryptographic assurance, and could make its own decision whether or not any or all of them were authorized to proxy this transaction. > If you are suggesting that there should be some additional field > in the Authorization: header, which P1 (etc.) must fill in indicating > that it is the one providing the credentials, then (provided it > isn't going to break existing challengers) that seems like a good > idea, as it will allow those challengers to discard such responses > if they want. No, but I can see why that might be requirement (and the username portion of Proxy-Authorization would no doubt make it clear who is providing the credentials). I was thinking more that P2 should have a way to say who it intends to challenge when it issues a 407. Today, 407 means ONLY that P2 intends to challenge the UAC. If you want to change that, then we need some way of qualifying the challenge to indicate that someone other than the UAC should answer it. > > > Moreover, there is a security concern here. The HTTP Digest > authentication > > mechanism uses the concept of 'realms' (as has previously > been discussed > > in this thread). In order to prevent a malicious proxy server from > > impersonating a realm (i.e., P3 spoofs, with its own nonces > and so on, a > > challenge from P2 asserting the realm of P2, in an attempt > to capture or > > interrupt authentication for P2's realm), realms must be > correlated with > > certificate-based security. > > Perhaps I am missing something here, but doesn't this problem > exist to EXACTLY the same extent whether credentials are supplied > to P2 by P1 (as suggested), or by UAC (as per the existing standard). > IE yes, it exists, but no, the proposal doesn't make it any worse. > > Moreover, they both can be solved to the same extent in the same > manner. > Of course. Your proposal does not make this problem any worse. It was raised to show that your solution is unnecessary in transitive trapezoid cases. If your solution space goes beyond transitive cases, though, then this will not apply. You clearly seem to want a direct assurance, rather than a transitive assurance, so I agree, mutual TLS is not sufficent for that. > > I am not denying that TLS is helpful - I think it's orthogonal to > the problem though, just as TLS does not replace the existing digest > authentication but is best used in parallel with it. > In trapezoid cases where your interest is in P2 determining that a request was received via P1, it is sufficient. In that sense, it's not orthogonal to the problem - the issue is that it is only valid for that one case (though it is a case that seems to be a common one). Again, you clearly want to cover other spaces. > > Regarding your second proposed solution, > > It's (the vauth header stuff) is clearly inferior to the first, and if the > request-history stuff can be authenticated, it's largely pointless. But for > the same reasons I identify above, I don't think even an authenticated > request-history solves the problems I am talking about. > Above, I did not see any reason that request-history does not solve your problem. You argued, perhaps, that request-history is broader than your problem, but that doesn't mean that it doesn't solve it. If you have some additional requirements for request history that have not yet been captured (whatever flavor you think you might get from a dynamic challenge from P2), those should be submitted for consideration to the request history work. > Alex > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 20 19:30:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06934 for ; Tue, 20 Apr 2004 19:30:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4Yv-0005cY-9X for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 19:21:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KNLvtY021607 for sip-archive@odin.ietf.org; Tue, 20 Apr 2004 19:21:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4Cm-0004Zo-Fn; Tue, 20 Apr 2004 18:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3vj-0004SU-Ff for sip@optimus.ietf.org; Tue, 20 Apr 2004 18:41:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04525 for ; Tue, 20 Apr 2004 18:41:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG3vg-0000xG-A0 for sip@ietf.org; Tue, 20 Apr 2004 18:41:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3uk-0000tE-00 for sip@ietf.org; Tue, 20 Apr 2004 18:40:28 -0400 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1BG3uQ-0000pK-00 for sip@ietf.org; Tue, 20 Apr 2004 18:40:06 -0400 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 9A1B01FDCB; Tue, 20 Apr 2004 23:39:55 +0100 (BST) Date: Tue, 20 Apr 2004 23:39:12 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Peterson, Jon" , sip@ietf.org Cc: Alex Bligh Subject: RE: [Sip] RFC3261 and authenticating PROXIES to other proxies & U AS - 2 possible solutions Message-ID: <4252873458.1082504352@[192.168.100.5]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jon, > I also understand that you feel request history is trying to solve a > different problem. I agree that request history is (possibly) broader than > what you want to do, but I do think it nicely encompasses the use cases > and requirements that you have articulated so far. The requirements possibly, but it doesn't actually provide a solution (see draft-barnes-sipping-sec-inserted-info-01.txt section 4. for why :-) ). Of course this is not to say it couldn't provide a solution, but it is a bit difficult to compare a concrete proposal to what in essence is a framework stating a problem, but not yet proposing a solution. Note that I am in no way trying to denigrate either the request history work or the sec-inserted-info work; all I am saying is that a simple change will provide a pragmatic solution to a particular problem space. Not in either as general terms or as secure terms as you are proposing, but in a manner which works /currently/ with all devices producing a challenge (as far as I can see). > While your note > suggests that Digest challenges from P2 could be customized in some > fashion to the particular circumstances of the transaction, that idea > would need to be flushed out a bit more before we can make any judgment > about whether or not request history cannot meet the underlying > requirement. See below. > - I think you underestimate the complexity of pre-sharing symmetric keys > for proxy servers. Sharing symmetric keys works well as a deployment > model for the sorts of cases where usernames and passwords are successful > today. For monolithic servers like proxies, a PKI-based approach has a > much cleaner deployment model that does not suffer from any n-squared > pre-sharing problems. Proxy servers shouldn't have to have pre-shared > keys in order to be able to identify one another; their relationships are > just too transient and they may need to relate to way too many peers > (unlike, say an end user's relationship with a PSTN termination service). I am not sure why the problem is n-squared. In all the examples of problems in the space this solution is proposed to solve, there is a 1:few problem, and more relevantly the authentication relationship is a "symptom" of some greater trust relationship that has already been set up. For instance, in the "my proxy diverts incoming SIP calls to me to my cellphone when my SIP UAS is unavailble" environment, there is already some form of (administrative) trust relationship between the SIP proxy and the gateway used to perform the diversion. You are entirely correct that digest authentication does not and could not solve the general problem of how a given proxy P(n) authenticates that any and all intermediate notes P(1)..P(n-1) are who they say they are. However, I am not sure of what problem that is a solution to. > - Challenge interception bends the semantics of the Digest authentication > system in ways that have foreseen undesirable consequences, and may have > unforeseen undesirable consequences. I am still not sure what the /foreseen/ undesirable consequences are (modulo those that you mention below which I have sought to address). Any protocol change might have unforeseen undesirable consequences, but that is not per-se an excuse not to ever change any protocols. The key it seems to me is minimizing the risk of ill-effect, and getting as many bright people on this list and elsewhere to look through and say "well I can't think of any". > If we really need a way to do this, > it should be specific to challenging proxies, and not conflated with > challenges that are semantically designated for end users in RFC3261. I respectfully disagree with you there. If you can use a general mechanism safely, rather than 2 specific mechanisms, the former seems better. If there is an inherent danger in using a general mechanism, then that should be avoided, but in the absence of that danger, I would suggest as much commonality as possible is a good thing in terms of protocol simplification. > In order for TLS to work, P1 and P2 only need to be in the > same PKI. Sure, but then you have added the additional necessity of full PKI certificates in order to provide authentication by a proxy. Whilst I can see why this may be useful in some circumstances, in a real world deployment, that sounds pretty heavyweight if the security of a simple digest challenge would be sufficient. >> c) Using TLS requires it to be supported and switched on. Whilst this >> may well be a "good thing", there are plenty of instances in >> where it currently is unsupported > > > This argument is of the form "your mechanism isn't implemented or used > very widely, but my (purely conceptual and totally unimplemented) proposal > doesn't suffer from that problem." :-) Whilst there is some truth in that, I think you've missed the point. My (purely conceptual) proposal is already currently implemented on every device (UAS and Proxy) which can provide a challenge. It's only unimplemented on those that need to respond to the challenge. Having looked at the code for ser (and, admittedly, nothing else), it doesn't seem like too great a change to me - I would suggest rather less of a change than to add (say) TLS and appropriate PKI. Besides which, your proposed solution that /does/ fully address the problem, IE the request history stuff, if the security aspect is maximally documented at in draft-barnes-sipping-sec-inserted-info-01.txt, is not even *DESCRIBED* in full yet , thus cannot be implemented or used at all. Again, I am not in any way denigrating the work, I am just saying from a pragmatic point of view what I am suggesting is a minimal change fix. > While it may be annoying to deploy a > PKI, I believe it is much more annoying to deploy and n-squared mesh of > symmetric keys to proxy servers, especially given the fact that it is > very difficult to anticipate which proxy servers are likely to need to > have a relationship with one another. There is no argument that if the problem space demands an n-squared mesh, PKI is better than any digest system (and, for authentication of UACs too). However, I don't believe this (requirement for n to m authentication) is the case. > But surely you agree that solving the request history problem also solves > the problem of determining whether or not a request when through a given > proxy server - it is sufficient, if not necessary. I also pointed you to > the m2m/m2e work, which is perhaps more directly applicable. The two are > pretty inextricably linked in my mind, though. Well it might well solve that problem. But it's difficult to see whether it actually does or will solve that problem as the security stuff is at quite an early stage. >> Further, it's eminently possible that any credential challenge >> it seeks to make may be dependent on routing information available to P2 >> only when the packet arrives - for instance some URIs might be billable, >> and some not billable. As request-history doesn't give P2 the mechanism >> to challenge P1, this would seem to require P1 either giving P2 "free >> reign", or having a complete understanding of P2's own authentication >> rules. > > Well, this is a requirement I didn't understand from your previous mails, > and one I'm still not sure I understand now. In what sense might the > credential challenge be different? Isn't the purpose of this challenge to > ascertain the identity of an intermediary? To ascertain the that an intermediary has appropriate credentials. IE I don't necessarily care which server from an authorized intermediate administrative domain inserted them, I just care they have a username and password tuple. If I can tell only that it is a specific intermediate server, I then have to map that back to an appropriate administrative domain etc.; not necessarily a problem, but it does mean if administrative domain X has 100 different servers, all with different certificates, then proxy server Y outside there has to have each of the 100 different certificates (or have some other way of mapping each of the ID's to administrative domain X). > If so, that identity > information will be provided by request history. The "billability" of a > URI wouldn't impact P2's challenge in any obvious way - except perhaps > insofar as it might choose not to issue a call if the transaction has no > settlement implications, or something. What I was suggesting is the information P1 might provide (or chose not to provide) might depend on information P2 would pass it in the challenge. As relatively trivial examples, it could pass the cost of the call, the QoS it could provide, the RTT etc. It needn't be passed in the realm necessarily. P1 might decide not to authenticate the request based on this information. >> On receipt of a second 407, P1 sends a 4xx upstream to the >> UAC saying "call failed" - doesn't much matter which 4xx code so long as > it >> isn't 407 etc.; alternatively it can reroute just as it might if it >> received a 404 (say) from P2. What it isn't to do is pass the 407 >> straight to UAC (as it will then seek credentials etc.) >> > > This is more or less exactly my point. P1 is shielding the UAC from the > authentication system. What if P2 wants to authenticate the UAC, not P1? > What gives P1 the right to interpose? This is why, if we want to > authenticate proxies with Digest, we should use a new, unambiguous status > code - so P1 can know whether it should consume and reply to the > challenge, or whether it should forward them back. You're conflating two > semantically distinct operations. The advantage of using the same status code is that both proxies and UAC's can authenticate to the same proxy. Very useful in the case of (say) a media gateway service where some of its subscribers are UAs, some are (effectively) B2BUAs or media-gateway-esque devices (asterisk for example), and some are other proxies. As the proxy does not at this stage know who the call came from, how would it know to respond with "Proxy Authentication Required" or your new code? However, saying that I do think you make a reasonable point that there should be some mechanism to forbid an intervening proxy from intercepting (perhaps a perjorative word) the 407. I am unsure whether it would be best that an originating UAC said "No, *I* want to authenticate this call", or whether the proxy should be saying "I want this to go right back to the UAC". >> > If the user of the UAC has their own account/relationship with P2, they >> > might want to rely on that rather than on allowing P1 to assert its own >> > credentials - P1 is essentially interposing in the challenge. >> >> This, it seems to me, is a policy decision for P1 and P2. > > So it's a policy decision, one that can be made by any old proxy server in > the response path, whether or not the UAC should be entitled to respond > to a 407 challenge? The UAC is always entitled to respond. The question is whether an intervening proxy is entitled to "intercept" (as you call it). And my answer is that this MUST NOT be done UNLESS there is a preexisting trust relationship between the proxy issuing the challenge and the proxy replying to the challenge. That is not "any old proxy server". That is a proxy server which the administrators of both systems have agreed should respond (as it has credentials). >> P2 sees the >> packet purports to come via P1 (it is unimportant for this purpose >> whether it actually comes via P1), and thus use a realm identifier that >> P1 > matches, >> on the basis that P1 has asked that /it/ supply credentials to P2. If >> the packet does not purport to come via P1, P2 might use a different >> realm. > > This is contrary to the meaning of realm as it is defined in RFC3261, > which is not as broad as the definition of realm in RFC2617. Are you saying that under RFC3261 I can't configure a single machine to carry two security certificates (i.e. act as sip.mynet.com and sip.mywhitelabel.com)? >> I don't understand why. You may well be "unhappy" about it, but it >> doesn't weaken security any putting it in the standard, as people >> can do this /now/ (in apparent breach of the RFC). > > "Unhappy" = my PSTN termination service might be getting revenue from a > paying customer, if the proxy at P1 were not preventing me from > authenticating my customer. Understand? Nope I don't understand. P1 is only "preventing" you from authenticating your customer as you (P2) have previously come to an agreement with P1 that P1 is your customer (which does not exclude UAC being your customer too), and P1 is thus attempting to give you customer traffic as per a previously established customer relationship. P1 must not arbitrarily respond to realms "on the off chance" it can authenticated the transaction. > Well, in your case as described above, if the interceptor in the middle > does not have valid credentials, they send back a cryptic 4xx message to > the UAC, effectively saying "your call failed". So, if P1 does act this > way, and the UAC has valid credentials, a call fails which should not > have failed. Perhaps that is the point here. I am not sure the above call should NOT have failed. Let's take the case where UAC makes a SIP call via P1 and P2 to a switched off UASX, and P2 wants to divert the call to a cellphone via P3 and a media-gw. The idea here is that P3 or media-gw (UAS) authenticates the call came via P2, as P2 (providing service to UAS) is going to be billed for it. UAC thinks the call is going to cost whatever a SIP call normally costs. If P2's authentication works, then indeed the call should proceed. However, let's suppose P2's authentication fails (perhaps they've forgotten to pay their bill), and by some chance, UAC also has credentials with P3 (perhaps P3 is actually the same administrative domain as P1, i.e. UAC's provider). Then automagically UAC will supply its own credentials to P3, the call will get through, but UAC will be billed for the privilege. This was exactly what UASX sought to avoid. The message back need only be as cryptic or descriptive as P2 wants it to be. If the call went to a media-gateway that hadn't paid its POTS bill, it will get a far more cryptic message back. > ... well, that isn't how I originally understood your requirements from > your earlier mail, but okay. I think that this just broadens your problem > space, and makes it much clearer to me that you want something like > RH/M2M/M2E. > > Also, be careful when you say that it doesn't care who authenticated the > request. I assume you mean that it doesn't care who replied to the > challenge. I mean I care only that valid credentials identifying are presented (whether they are used to identify individual servers, or administrative domains is not necessarily relevant). In many applications it is unnecessary to identify individual nodes. > But what is the purpose of replying to the challenge? To > provided credentials proving someone's identity. That is the key to this. > I don't think there's something magical about Digest as a means to prove > identity. With request history, P4 would see the identity of P1, P2 and > P3, with a cryptographic assurance, and could make its own decision > whether or not any or all of them were authorized to proxy this > transaction. This would indeed be true, if the specification and the software to implement it existed. What I am proposing (a) has a specification, (b) has one end of the software already written. >> If you are suggesting that there should be some additional field >> in the Authorization: header, which P1 (etc.) must fill in indicating >> that it is the one providing the credentials, then (provided it >> isn't going to break existing challengers) that seems like a good >> idea, as it will allow those challengers to discard such responses >> if they want. > > No, but I can see why that might be requirement (and the username portion > of Proxy-Authorization would no doubt make it clear who is providing the > credentials). I was thinking more that P2 should have a way to say who it > intends to challenge when it issues a 407. Today, 407 means ONLY that P2 > intends to challenge the UAC. If you want to change that, then we need > some way of qualifying the challenge to indicate that someone other than > the UAC should answer it. Perhaps "noone other than UAC should answer it". > Above, I did not see any reason that request-history does not solve your > problem. You argued, perhaps, that request-history is broader than your > problem, but that doesn't mean that it doesn't solve it. If you have some > additional requirements for request history that have not yet been > captured (whatever flavor you think you might get from a dynamic > challenge from P2), those should be submitted for consideration to the > request history work. This argument sounds a bit like "we cannot solve a small isolated problem by generalizing an existing mechanism, if we have the opportunity of solving at a rather later date a much larger more complicated problem which a rather heavier-weight solution that will probably solve the small problem too". That's one of the things that broke OSI, X.400 etc.; not doing that made IP et al. work. I am not suggesting this replace request-history etc. - there is no reason the two cannot live together in harmony. I will take your word for it than when request-history & appropriate security stuff is written you can use it to satisfactorily authenticate a request has passed through a proxy, but it seems a bit like a sledgehammer to crack a nut. Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 21 19:09:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28774 for ; Wed, 21 Apr 2004 19:09:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQYm-0007Tx-C1 for sip-archive@odin.ietf.org; Wed, 21 Apr 2004 18:51:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMpGZV028761 for sip-archive@odin.ietf.org; Wed, 21 Apr 2004 18:51:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQFC-0004YH-4z; Wed, 21 Apr 2004 18:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPrC-0003lf-Rn for sip@optimus.ietf.org; Wed, 21 Apr 2004 18:06:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20757 for ; Wed, 21 Apr 2004 18:06:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPrA-0003wo-3g for sip@ietf.org; Wed, 21 Apr 2004 18:06:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPqA-0003ma-00 for sip@ietf.org; Wed, 21 Apr 2004 18:05:11 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGPpD-0003TH-00 for sip@ietf.org; Wed, 21 Apr 2004 18:04:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 14:15:29 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LM3eW9022429; Wed, 21 Apr 2004 15:03:40 -0700 (PDT) Received: from [128.107.170.235] ([128.107.170.235]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOH64886; Wed, 21 Apr 2004 15:03:39 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 21 Apr 2004 15:03:38 -0700 Subject: Re: [Sip] History-Info Privacy Issue From: Cullen Jennings To: Mary Barnes , Message-ID: In-Reply-To: <870397D7C140C84DB081B88396458DAF5791BB@zrc2c000.us.nortel.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3165404618_122344" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3165404618_122344 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I don=B9t care a huge amount but I think I slightly favor 2. On 4/16/04 9:05 AM, "Mary Barnes" wrote: > Per my posting on the status of History-Info, Privacy is one of the remai= ning > open issues. The proposal currently in the draft is quite simple: >=20 > If the Privacy header has a priv-value of "Session" or "Header" privacy, = the > History-Info SHOULD not be included in the Request (or subsequent respon= ses). >=20 > This is effectively applying the fundamental recommendation in RFC3323 th= at > any optional information that can divulge information about the user(s) s= hould > not be included in the requests. >=20 > A proposal was made that there are scenarios (e.g. where local policy lim= its > the applicability of History-Info within a specific domain) where you wou= ld > want to capture the History-Info but not send it beyond certain intermedi= aries > or domains. To support this, it was proposed that we could extend the Pr= ivacy > header defined in RFC 3323 with tags for History-Info something like the > following: >=20 > priv-value =3D "history" / "history-index" >=20 > The "history" priv-value would mean that all the History-Info entries sho= uld > be removed. The "history-index" would be used to indicate that the speci= fic > entry is to be removed and would need to have the Privacy header escaped = in > the URI so that it can be associated with a specific History-Info entry (= or we > need to add another field to History-Info for this). >=20 > So, I think we have two options here: > 1) Extend History-Info to have an optional privacy field along the lines = of > what's detailed above. >=20 > 2) Defer the definition of the privacy field to a separate draft, since i= t > appears to be primarily limited to scenarios with certain trust models. >=20 > So, if folks could just take a bit of time and consider their preference,= I > would like to get the draft updated soon and closed off prior to the Inte= rim > meeting. >=20 > Regards,=20 > Mary H. Barnes=20 > mary.barnes@nortelnetworks.com >=20 --B_3165404618_122344 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] History-Info Privacy Issue
I don’t care a huge amount but I think I slightly favor 2.


On 4/16/04 9:05 AM, "Mary Barnes" <mary.barnes@nortelnetworks.= com> wrote:

Per my posting on the status of History-Info, Privacy is one of the remai= ning open issues.  The proposal currently in the draft is quite simple:=

If the Privacy header has a priv-value of "Session" or "Head= er" privacy, the History-Info  SHOULD not be included in the Reque= st (or subsequent responses).  

This is effectively applying the fundamental recommendation in RFC3323 that= any optional information that can divulge information about the user(s) sho= uld not be included in the requests.  

A proposal was made that there are scenarios (e.g. where local policy limit= s the applicability of History-Info within a specific domain) where you woul= d want to capture the History-Info but not send it beyond certain intermedia= ries or domains.  To support this, it was proposed that we could extend= the Privacy header defined in RFC 3323 with tags for History-Info something= like the following:

priv-value =3D "history" / "history-index"  

The "history" priv-value would mean that all the History-Info ent= ries should be removed.  The "history-index" would be used to= indicate that the specific entry is to be removed and would need to have th= e Privacy header escaped in the URI so that it can be associated with a spec= ific History-Info entry (or we need to add another field to History-Info for= this).    

So, I think we have two options here:
1) Extend History-Info to have an optional privacy field along the lines of= what's detailed above.  

2) Defer the definition of the privacy field to a separate draft, since it = appears to be primarily limited to scenarios with certain trust models. &nbs= p;

So, if folks could just take a bit of time and consider their preference, I= would like to get the draft updated soon and closed off prior to the Interi= m meeting.

Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com


--B_3165404618_122344-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 21 19:21:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29485 for ; Wed, 21 Apr 2004 19:21:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQca-0001hq-JX for sip-archive@odin.ietf.org; Wed, 21 Apr 2004 18:55:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMtCgn006547 for sip-archive@odin.ietf.org; Wed, 21 Apr 2004 18:55:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQH8-0005sT-5u; Wed, 21 Apr 2004 18:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ2R-0004IX-Ro for sip@optimus.ietf.org; Wed, 21 Apr 2004 18:17:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22022 for ; Wed, 21 Apr 2004 18:17:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQ2O-000693-VT for sip@ietf.org; Wed, 21 Apr 2004 18:17:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPxF-00057Q-00 for sip@ietf.org; Wed, 21 Apr 2004 18:12:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGPve-0004fp-01 for sip@ietf.org; Wed, 21 Apr 2004 18:10:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGPlE-0000ZM-91 for sip@ietf.org; Wed, 21 Apr 2004 18:00:04 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 14:11:19 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LLxUW9013669; Wed, 21 Apr 2004 14:59:31 -0700 (PDT) Received: from [128.107.170.235] ([128.107.170.235]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOH64280; Wed, 21 Apr 2004 14:59:30 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 21 Apr 2004 14:59:28 -0700 Subject: Re: [Sip] History-Info status - Security open issue From: Cullen Jennings To: Mary Barnes , Message-ID: In-Reply-To: <870397D7C140C84DB081B88396458DAF5791BA@zrc2c000.us.nortel.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3165404369_109628" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3165404369_109628 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes. Sounds reasonable to me. On 4/16/04 9:04 AM, "Mary Barnes" wrote: > Hi all, > > There are still two open issues around History-Info > (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt ) that > require list discussion: privacy and security. I'll post some details on the > privacy proposal in a separate posting so that I can more easily track the > responses. > > On the security, based upon some of the discussion in the e2m, m2e, policy > adhoc (per my recollection and the notes at: > http://softarmor.com/sipping/meets/ietf59/notes/notes-cyrus-sipping-adhoc-ietf > 59.txt ) there does not seem to be WG consensus that History-Info really > requires m2e (i.e. TLS may be sufficient). I do agree that if there was an > m2e (and m2m) security mechanism in place for SIP at this point in time, that > the use of it for History-Info would add value and actually make History-Info > itself more useful to the end applications. > > What I would like to propose is that the draft reference the context of some > of these current works in progress in this area as informational and possibly > applicable to History-Info. And, of course, define TLS as the normative and > mandatory security solution for History-Info. This results in the security for > History-Info initially being as robust as that of the other headers added by > Intermediaries (Via, etc.), per RFC 3261 and in the future, could be made more > robust. In the end, it is up to the applications making use of History-Info > to choose the security solution that best meets its requirements and if there > is a m2m and m2e solution developed in the future, applications can certainly > take advantage of those. > > If there's general agreement on this approach, I believe this only requires > some minor rewording in section 3.2. The remaining work to complete the draft > would be updating and cleaning up the examples. > > [I realize that this will likely start a long thread on the more general topic > of m2e, which does need discussion, but if folks could, please, upfront in > their postings say whether they believe History-Info can and should be > progressed without that solution fully specified]. > > Regards, > Mary > mary.barnes@nortelnetworks.com > > --B_3165404369_109628 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Sip] History-Info status - Security open issue
Yes. Sounds reasonable to me.

On 4/16/04 9:04 AM, "Mary Barnes" <mary.barnes@nortelnetworks.= com> wrote:

Hi all,

There are still two open issues around History-Info (http://www.ietf.o= rg/internet-drafts/draft-ietf-sip-history-info-02.txt ) that require lis= t discussion: privacy and security.  I'll post some details on the priv= acy proposal in a separate posting so that I can more easily track the respo= nses.  

On the security, based upon some of the discussion in the e2m, m2e, policy = adhoc (per my recollection and the notes at: http://softa= rmor.com/sipping/meets/ietf59/notes/notes-cyrus-sipping-adhoc-ietf59.txt=  ) there does not seem to be WG consensus that History-Info really req= uires m2e (i.e. TLS may be sufficient).  I do agree that if there was a= n m2e (and m2m) security mechanism in place for SIP at this point in time, t= hat the use of it for History-Info would add value and actually make History= -Info itself more useful to the end applications.

What I would like to propose is that the draft reference the context of som= e of these current works in progress in this area as informational and possi= bly applicable to History-Info.  And, of course, define TLS as the norm= ative and mandatory security solution for History-Info. This results in the = security for History-Info initially being as robust as that of the other hea= ders added by Intermediaries (Via, etc.), per RFC 3261 and in the future, co= uld be made more robust.  In the end, it is up to the applications maki= ng use of History-Info to choose the security solution that best meets its r= equirements and if there is a m2m and m2e solution developed in the future, = applications can certainly take advantage of those.  

If there's general agreement on this approach, I believe this only requires= some minor rewording in section 3.2. The remaining work to complete the dra= ft would be updating and cleaning up the examples.

[I realize that this will likely start a long thread on the more general to= pic of m2e, which does need discussion, but if folks could, please, upfront = in their postings say whether they believe History-Info can and should be pr= ogressed without that solution fully specified].

Regards,
Mary
mary.barnes@nortelnetworks.com



--B_3165404369_109628-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Apr 22 10:02:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27478 for ; Thu, 22 Apr 2004 10:02:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeiN-0005yb-1m for sip-archive@odin.ietf.org; Thu, 22 Apr 2004 09:58:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MDw71a022973 for sip-archive@odin.ietf.org; Thu, 22 Apr 2004 09:58:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeM4-0008MP-EK; Thu, 22 Apr 2004 09:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeCL-0004oi-Iy for sip@optimus.ietf.org; Thu, 22 Apr 2004 09:25:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25495 for ; Thu, 22 Apr 2004 09:24:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGeCE-0004Ow-5k for sip@ietf.org; Thu, 22 Apr 2004 09:24:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeBG-00049g-00 for sip@ietf.org; Thu, 22 Apr 2004 09:23:55 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 1BGeAG-0003gr-00 for sip@ietf.org; Thu, 22 Apr 2004 09:22:53 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 22 Apr 2004 15:21:33 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Apr 2004 15:19:53 +0200 Message-Id: <953B9B08F98DD61183F8000347AE66010618635E@G8PPV.blf01.telekom.de> From: "Jesske, R" To: fluffy@cisco.com, mary.barnes@nortelnetworks.com, sip@ietf.org Subject: AW: [Sip] History-Info Privacy Issue Date: Thu, 22 Apr 2004 15:19:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4286C.281F8F74" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4286C.281F8F74 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I favour 1, because I think this should be kept together. =20 Best Regards =20 Roland -----Urspr=FCngliche Nachricht----- Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org]Im Auftrag von = Cullen Jennings Gesendet: Donnerstag, 22. April 2004 00:04 An: Mary Barnes; sip@ietf.org Betreff: Re: [Sip] History-Info Privacy Issue I don't care a huge amount but I think I slightly favor 2.=20 On 4/16/04 9:05 AM, "Mary Barnes" = wrote: Per my posting on the status of History-Info, Privacy is one of the = remaining open issues. The proposal currently in the draft is quite = simple:=20 If the Privacy header has a priv-value of "Session" or "Header" = privacy, the History-Info SHOULD not be included in the Request (or = subsequent responses). =20 This is effectively applying the fundamental recommendation in RFC3323 = that any optional information that can divulge information about the = user(s) should not be included in the requests. =20 A proposal was made that there are scenarios (e.g. where local policy = limits the applicability of History-Info within a specific domain) = where you would want to capture the History-Info but not send it beyond = certain intermediaries or domains. To support this, it was proposed = that we could extend the Privacy header defined in RFC 3323 with tags = for History-Info something like the following: priv-value =3D "history" / "history-index" =20 The "history" priv-value would mean that all the History-Info entries = should be removed. The "history-index" would be used to indicate that = the specific entry is to be removed and would need to have the Privacy = header escaped in the URI so that it can be associated with a specific = History-Info entry (or we need to add another field to History-Info for = this). =20 So, I think we have two options here:=20 1) Extend History-Info to have an optional privacy field along the = lines of what's detailed above. =20 2) Defer the definition of the privacy field to a separate draft, since = it appears to be primarily limited to scenarios with certain trust = models. =20 So, if folks could just take a bit of time and consider their = preference, I would like to get the draft updated soon and closed off = prior to the Interim meeting. Regards,=20 Mary H. Barnes=20 mary.barnes@nortelnetworks.com=20 ------_=_NextPart_001_01C4286C.281F8F74 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] History-Info Privacy Issue
I=20 favour 1, because I think this should be kept = together.
 
Best=20 Regards
 
Roland
-----Urspr=FCngliche Nachricht-----
Von: = sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]Im Auftrag von Cullen=20 Jennings
Gesendet: Donnerstag, 22. April 2004 = 00:04
An:=20 Mary Barnes; sip@ietf.org
Betreff: Re: [Sip] History-Info = Privacy=20 Issue


I don't care a huge amount but I think = I slightly=20 favor 2.


On 4/16/04 9:05 AM, "Mary Barnes"=20 <mary.barnes@nortelnetworks.com> wrote:
Per = my posting=20 on the status of History-Info, Privacy is one of the remaining open = issues.=20  The proposal currently in the draft is quite simple: =

If the=20 Privacy header has a priv-value of "Session" or "Header" privacy, = the=20 History-Info  SHOULD not be included in the Request (or = subsequent=20 responses).  

This is effectively applying the = fundamental=20 recommendation in RFC3323 that any optional information that can = divulge=20 information about the user(s) should not be included in the = requests.=20  

A proposal was made that there are scenarios (e.g. = where local=20 policy limits the applicability of History-Info within a specific = domain)=20 where you would want to capture the History-Info but not send it = beyond=20 certain intermediaries or domains.  To support this, it was = proposed=20 that we could extend the Privacy header defined in RFC 3323 with = tags for=20 History-Info something like the following:

priv-value =3D = "history" /=20 "history-index"  

The "history" priv-value would mean = that all=20 the History-Info entries should be removed.  The = "history-index" would=20 be used to indicate that the specific entry is to be removed and = would need=20 to have the Privacy header escaped in the URI so that it can be = associated=20 with a specific History-Info entry (or we need to add another field = to=20 History-Info for this).    

So, I think we = have two=20 options here:
1) Extend History-Info to have an optional = privacy field=20 along the lines of what's detailed above.  

2) Defer = the=20 definition of the privacy field to a separate draft, since it = appears to be=20 primarily limited to scenarios with certain trust models. =  

So,=20 if folks could just take a bit of time and consider their = preference, I=20 would like to get the draft updated soon and closed off prior to = the Interim=20 meeting.

Regards,
Mary H. Barnes=20
mary.barnes@nortelnetworks.com =


------_=_NextPart_001_01C4286C.281F8F74-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Apr 22 17:43:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03155 for ; Thu, 22 Apr 2004 17:43:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlRL-0006aO-Vk for sip-archive@odin.ietf.org; Thu, 22 Apr 2004 17:09:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ML8xgA025307 for sip-archive@odin.ietf.org; Thu, 22 Apr 2004 17:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkbT-0005on-AB; Thu, 22 Apr 2004 16:15:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkG9-0004vQ-PP for sip@optimus.ietf.org; Thu, 22 Apr 2004 15:53:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24049 for ; Thu, 22 Apr 2004 15:53:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGkG5-0004m4-T7 for sip@ietf.org; Thu, 22 Apr 2004 15:53:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGkFN-0004V9-00 for sip@ietf.org; Thu, 22 Apr 2004 15:52:34 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGkEU-0003ur-00; Thu, 22 Apr 2004 15:51:38 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 12:01:56 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3MJp8Su019862; Thu, 22 Apr 2004 12:51:08 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA20166; Thu, 22 Apr 2004 12:51:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20040422144516.02607ba8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Apr 2004 14:51:23 -0500 To: Hisham Khartabil , Rohan Mahy , Dean Willis From: "James M. Polk" Cc: sipping@ietf.org, sip@ietf.org In-Reply-To: <200404221531.LAA05708@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] Re: SIMPLE/SIP/SIPPING/XCON Working Groups Joint Interim Meeting Announcement Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , What happened to time for Emergency and E2M Security? In Seoul, these were mentioned as two of the prevailing topic areas for the interim (along with Session Policy and Exploders). At 11:31 AM 4/22/2004 -0400, Hisham Khartabil wrote: >An joint interim meeting for the SIMPLE, SIP, SIPPING and XCON working groups >will be help from Monday 24th May until Wednesday 26th May in Boston, >Massachusetts. > >Location: >Renaissance Boston Hotel Bedford >44 Middlesex Turnpike Bedford, MA 01730 USA >Phone: 1 781-275-5500 Fax: 1 781-275-3042 > >http://marriott.com/property/propertyPage.mi?marshaCode=BOSSB > >Agenda: > >MONDAY - SIMPLE > >9:00-12:00 - MSRP/MSRP Relays >12:00-13:00 - Lunch >13:00-16:00 - XCAP >16:00-16:30 - Filtering >16:30-17:00 - Partial Publish >17:00-17:30 - Advanced Messaging > >TUESDAY - SIP/SIPPING > >9:00-10:30 - KPML >10:30-11:00 - GRUU >11:00-12:00 - Session Policies >12:00-13:00 - Lunch >13:00-14:30 - Session Policies Cont. >14:30-15:30 - Exploders >time permitting: >15:30-16:15 - Connected Party >16:15-17:00 - Application Interaction >17:00-17:30 - Dialog Package >17:30-18:00 - Connection Re-use > >WEDNESDAY - XCON > >9:00-11:00 - Floor Control >11:00-12:00 - CPCP >12:00-13:00 - Lunch >13:00-14:00 - CPCP Cont. >14:00-16:00 - MPCP > >The chairs would like to thank Nokia for sponsoring the event. > > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Apr 22 19:46:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13343 for ; Thu, 22 Apr 2004 19:46:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnnl-00026p-JD for sip-archive@odin.ietf.org; Thu, 22 Apr 2004 19:40:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MNeHXu008103 for sip-archive@odin.ietf.org; Thu, 22 Apr 2004 19:40:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGneq-0006Sf-7u; Thu, 22 Apr 2004 19:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnSg-0002Pi-GB for sip@optimus.ietf.org; Thu, 22 Apr 2004 19:18:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11768 for ; Thu, 22 Apr 2004 19:18:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnSc-0002x9-QL for sip@ietf.org; Thu, 22 Apr 2004 19:18:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnRZ-0002iE-00 for sip@ietf.org; Thu, 22 Apr 2004 19:17:22 -0400 Received: from mailbo.vtcif.telstra.com.au ([202.12.144.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnR6-0002RX-00 for sip@ietf.org; Thu, 22 Apr 2004 19:16:53 -0400 Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 5AC6E23163 for ; Fri, 23 Apr 2004 09:16:17 +1000 (EST) Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id C35B522885 for ; Fri, 23 Apr 2004 09:16:16 +1000 (EST) Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA13021 for ; Fri, 23 Apr 2004 09:16:16 +1000 (EST) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C428BF.CA0DC0A0" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 23 Apr 2004 09:16:06 +1000 Message-ID: <1FD836F38652D211A63E0008C7244343125171F1@ntmsg0008.corpmail.telstra.com.au> Thread-Topic: [Query] SIP security and trusted spontaneous interactions between end points Thread-Index: AcQov/r4QbGl725jQRi37LD8KUD+Ag== From: "Khare, Anir" To: Cc: "Khare, Anir" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] [Query] SIP security and trusted spontaneous interactions between end points Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C428BF.CA0DC0A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 Can someone please point me to the known issues with SIP security?=20 =20 Also are there any initiatives in progress for using Liberty alliance like identity/trust infrastructure in conjunction with SIP protocols to facilitate spontaneous trusted real time communication between a A party and a B party, who are not registered with one SIP proxy?=20 =20 Thanks, Anir ------_=_NextPart_001_01C428BF.CA0DC0A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Can someone please = point me to the known issues with SIP security?

 

Also are there any initiatives in progress for using Liberty alliance like identity/trust infrastructure in conjunction with SIP protocols to facilitate = spontaneous trusted real time communication between a A party = and a B party, who are not registered with one SIP proxy? =

 

Thanks,

Anir<= /font>

------_=_NextPart_001_01C428BF.CA0DC0A0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Apr 23 03:37:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19645 for ; Fri, 23 Apr 2004 03:37:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGv7k-0002XU-Re for sip-archive@odin.ietf.org; Fri, 23 Apr 2004 03:29:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N7TOFv009739 for sip-archive@odin.ietf.org; Fri, 23 Apr 2004 03:29:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGuwm-0007w6-2H; Fri, 23 Apr 2004 03:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGutb-0006Qg-5n for sip@optimus.ietf.org; Fri, 23 Apr 2004 03:14:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18573 for ; Fri, 23 Apr 2004 03:14:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGutW-00073y-RK for sip@ietf.org; Fri, 23 Apr 2004 03:14:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGusa-0006nn-00 for sip@ietf.org; Fri, 23 Apr 2004 03:13:44 -0400 Received: from bay16-f98.bay16.hotmail.com ([65.54.186.148] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BGuri-0006Ib-00 for sip@ietf.org; Fri, 23 Apr 2004 03:12:50 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Apr 2004 00:12:23 -0700 Received: from 210.12.42.4 by by16fd.bay16.hotmail.msn.com with HTTP; Fri, 23 Apr 2004 07:12:23 GMT X-Originating-IP: [210.12.42.4] X-Originating-Email: [hongchuan_yuan@hotmail.com] X-Sender: hongchuan_yuan@hotmail.com From: "yuan hongchuan" To: sip@ietf.org Date: Fri, 23 Apr 2004 07:12:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 23 Apr 2004 07:12:23.0570 (UTC) FILETIME=[53325F20:01C42902] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA18574 Subject: [Sip] How should i apprehend this sentence? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable in the section 8.2.2.1 of RFC3261,there is a sentence "Other potential=20 sources of received Request-URIs include the Contact header fields of=20 requests and responses sent by the UA that establish or refresh dialogs." How should i apprehend it? thx _________________________________________________________________ =C3=E2=B7=D1=CF=C2=D4=D8 MSN Explorer: http://explorer.msn.com/lccn =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Apr 23 11:20:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14192 for ; Fri, 23 Apr 2004 11:20:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2MV-00058Z-1j for sip-archive@odin.ietf.org; Fri, 23 Apr 2004 11:13:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NFD7t4019747 for sip-archive@odin.ietf.org; Fri, 23 Apr 2004 11:13:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2Fe-00038l-KC; Fri, 23 Apr 2004 11:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH28z-0001OS-IT for sip@optimus.ietf.org; Fri, 23 Apr 2004 10:59:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13083 for ; Fri, 23 Apr 2004 10:59:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH28w-00079z-W7 for sip@ietf.org; Fri, 23 Apr 2004 10:59:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH27u-0006rj-00 for sip@ietf.org; Fri, 23 Apr 2004 10:58:02 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BH26s-0006Ox-00 for sip@ietf.org; Fri, 23 Apr 2004 10:56:58 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i3NEuQrk044279 for ; Fri, 23 Apr 2004 16:56:26 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i3NEpQ8p043771 for ; Fri, 23 Apr 2004 16:51:26 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from earth.office (earth.office [10.1.1.5]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i3NEpPri043769; Fri, 23 Apr 2004 16:51:26 +0200 (CEST) Received: from netlab.nec.de (n-stud14-e.students [10.1.2.119]) by earth.office (Postfix) with ESMTP id CA07463166; Fri, 23 Apr 2004 16:48:03 +0200 (CEST) Message-ID: <40892DC8.6090108@netlab.nec.de> Date: Fri, 23 Apr 2004 16:52:56 +0200 From: Ali Fessi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khare, Anir" Cc: sip@ietf.org Subject: Re: [Sip] [Query] SIP security and trusted spontaneous interactions between end points References: <1FD836F38652D211A63E0008C7244343125171F1@ntmsg0008.corpmail.telstra.com.au> In-Reply-To: <1FD836F38652D211A63E0008C7244343125171F1@ntmsg0008.corpmail.telstra.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Anir, to be clear, I'm not an expert! But I have been also working on SIP security lately. (I have been mostly working on different solutions for SIP deployment with firewalls and NATs). Check these links for some infomation about SIP security. I found them helpful. http://www.dynamicsoft.com/news/presentations/SIPSecurity.pdf http://www.off-pisteconsulting.com/research/pubs/ndss03-slides.ppt Considering your question about spontanous calls: I think there are several reasons that make this not possible. Except DOS attacks to SIP servers/user agents, one of the issue that I was thinking about is: you can very easily write a little script that generates INVITE messages and sends them to random SIP URLs. Without any authentication mechanisms, the result will be: you will make the SIP phones of tousends of peaple ringing!! Note here that this is more a social issue, a sort of SIP spam!! Any comments are welcome! If I misunderstood your question, please let me know! Ali -- Ali Fessi NEC Network Laboratories Khare, Anir wrote: >Hello, > >Can someone please point me to the known issues with SIP security? > >Also are there any initiatives in progress for using Liberty alliance >like identity/trust infrastructure in conjunction with SIP protocols to >facilitate spontaneous trusted real time communication between a A party >and a B party, who are not registered with one SIP proxy? > >Thanks, >Anir > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Apr 25 19:04:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23143 for ; Sun, 25 Apr 2004 19:04:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHsa6-0000HE-7S for sip-archive@odin.ietf.org; Sun, 25 Apr 2004 18:58:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3PMwcKx001064 for sip-archive@odin.ietf.org; Sun, 25 Apr 2004 18:58:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHsUg-0006pf-6v; Sun, 25 Apr 2004 18:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHsQB-0005fn-2q for sip@optimus.ietf.org; Sun, 25 Apr 2004 18:48:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22345 for ; Sun, 25 Apr 2004 18:48:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHsQ7-0003mr-Ui for sip@ietf.org; Sun, 25 Apr 2004 18:48:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHsPD-0003aa-00 for sip@ietf.org; Sun, 25 Apr 2004 18:47:23 -0400 Received: from mailbo.ntcif.telstra.com.au ([202.12.233.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHsOO-0003PE-00 for sip@ietf.org; Sun, 25 Apr 2004 18:46:33 -0400 Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailbo.ntcif.telstra.com.au (Postfix) with ESMTP id A64EC1606D; Mon, 26 Apr 2004 08:46:24 +1000 (EST) Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id F388412983; Mon, 26 Apr 2004 08:46:23 +1000 (EST) Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id IAA21513; Mon, 26 Apr 2004 08:46:23 +1000 (EST) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] [Query] SIP security and trusted spontaneous interactions between end points Date: Mon, 26 Apr 2004 08:46:19 +1000 Message-ID: <1FD836F38652D211A63E0008C7244343125171FE@ntmsg0008.corpmail.telstra.com.au> Thread-Topic: [Sip] [Query] SIP security and trusted spontaneous interactions between end points Thread-Index: AcQpQyxf9O8YCfYkQo60cn5oZc4feABI62tgACwVI+A= From: "Khare, Anir" To: "Ali Fessi" , Cc: , , , , "Khare, Anir" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Except DOS attacks to SIP servers/user agents, one of the issue that I > was thinking about is: > you can very easily write a little script that generates INVITE messages=20 > and sends them to random SIP URLs. Without any authentication=20 > mechanisms, the result will be: you will make the SIP phones of tousends=20 > of peaple ringing!! > Note here that this is more a social issue, a sort of SIP spam!! Yes, this is the scenario I was thinking about.=20 In the existing SIP standard, is there any way for a UAS to specify at the time of REGISTER or otherwise, to avoid such spams by restricting the incoming requests to some circle of trust, either introduced by the SIP proxy server of the domain or by the UAS itself? Also: I came across following internet draft draft-ietf-sipping-trait-authz-00 - Trait based Authorization Requirements for Session Initiation Protocol (SIP) Feb 7, 2004, by Jon Peterson et.al. on SIPPING. I think, this is a very good step towards handling the spam issues by tracking the sender's traits. Liberty alliances deal with such issues in the context of http interactions between service consumer and service provider of online (web) services. Along with other standard single sign on scenarios, liberty also covers the scenarios like service providers using selective credentials authorizations (e.g. charging)and attributes (e.g. ZIP code) provided by identity providers and identity services providers, about a service consumer (principal, in order to provide access to online services. The service providers don't need to have user accounts on their sites and users don't need to disclose their identity to such service providers. It provides the mechanisms for allowing spontaneous trusted interactions between the liberty enabled entities. The interactions between SIP UAC and SIP UAS, in large open communities with few pre-existing relationships, will have similar issues.=20 Probably the liberty framework (Liberty ID-FF and ID-WSF) can be used as an authorization service as mentioned in section 5 of the abovementioned draft by Jon Peterson et.al. Additionally use of Liberty architecture may streamline some of the issues related to management of authorization assertions carried by the SIP requests, as proposed in this draft. The assertions may not be required to be physically added in the SIP requests. The SIP requests can carry Liberty pseudonyms for example and the authorization assertions can be retrieved by the UASs from the identity web services, which are supposed to provide access control in terms of who can access what attributes. Just trying to understand, whether there is any synergy between the two architectures or are there any known issues which prevent a protocol like SIP from using Liberty architecture for achieving desired trust in open environments. Anir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Apr 25 19:09:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23279 for ; Sun, 25 Apr 2004 19:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHseH-0001uU-6r for sip-archive@odin.ietf.org; Sun, 25 Apr 2004 19:02:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3PN2vlW007338 for sip-archive@odin.ietf.org; Sun, 25 Apr 2004 19:02:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHsUi-0006q6-5I; Sun, 25 Apr 2004 18:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHsRA-0005ke-Sc for sip@optimus.ietf.org; Sun, 25 Apr 2004 18:49:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22393 for ; Sun, 25 Apr 2004 18:49:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHsR7-00040S-MG for sip@ietf.org; Sun, 25 Apr 2004 18:49:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHsQ8-0003n5-00 for sip@ietf.org; Sun, 25 Apr 2004 18:48:21 -0400 Received: from mailbo.ntcif.telstra.com.au ([202.12.233.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHsPE-0003ai-00 for sip@ietf.org; Sun, 25 Apr 2004 18:47:25 -0400 Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailbo.ntcif.telstra.com.au (Postfix) with ESMTP id 5C5611617E; Mon, 26 Apr 2004 08:47:24 +1000 (EST) Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id C7D2E12981; Mon, 26 Apr 2004 08:47:23 +1000 (EST) Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id IAA22445; Mon, 26 Apr 2004 08:47:23 +1000 (EST) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] [Query] SIP security and trusted spontaneous interactions between end points Date: Mon, 26 Apr 2004 08:47:17 +1000 Message-ID: <1FD836F38652D211A63E0008C7244343125171FF@ntmsg0008.corpmail.telstra.com.au> Thread-Topic: [Sip] [Query] SIP security and trusted spontaneous interactions between end points Thread-Index: AcQpFK/mhjLy9pS9QPqdjjA4SFvtjQBWiLVQACoi9NA= From: "Khare, Anir" To: "Harry Behrens" , Cc: , "Khare, Anir" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Harry, This is interesting. A general query: Did you consider using Liberty alliance like protocols = for security and accounting interactions between VN and HN. Are there = any known issues about using Liberty protocols in this context? A specific question about the requirements (section 2). Is ability for = Alice to get a SIP URI in VN a mandatory requirement? i.e. why can't = Alice use Mobile IP and continue using SIP infrastructure at HN? Is it = because Alice wants to use some resources like PSTN gateway in the VN?=20 Regards, Anir=20 -----Original Message----- From: Harry Behrens [mailto:hb@snom.de]=20 Sent: Friday, 23 April 2004 7:07 PM To: Khare, Anir Cc: sip@ietf.org; knuettel@fokus.fraunhofer.de Subject: Re: [Sip] [Query] SIP security and trusted spontaneous = interactions between end points Khare, Anir wrote: > Hello, > > =20 > > Can someone please point me to the known issues with SIP security? > > =20 > > Also are there any initiatives in progress for using Liberty alliance=20 > like identity/trust infrastructure in conjunction with SIP protocols=20 > to facilitate spontaneous trusted real time communication between a A=20 > party and a B party, who are not registered with one SIP proxy? > > =20 > Karsten Kn=FCttel and I have proposed something to that extent in March = on=20 the SIPPING list, which uses PKI to allow dynamic agreement on trust and billing=20 relationships. Maybe it proves useful to you: Interdomain Trust-Relationships for SIP-based Roaming This draft describes an authentication mechanism which can be used to=20 enable users of VoIP to globally roam between any number of ITSPs=20 (Internet Telephony Service Providers) without needing to have a prior=20 customer or billing relationship with all of them. This enables=20 profiles and one-line-billing.=20 Providers using this authentication mechanism do neither need full-mesh=20 trust relationships or roaming agreements with every other possible=20 provider nor do they need to rely on a centralized brokerage entity to=20 process calls.=20 The Home Network (HN), which handles all AAA for a user attempting to=20 use an ITSP's service is determined through a unique identifier=20 submitted by the user. This Network Access Identifier [RFC2486]=20 contains information about the trust domain or trust realm the user=20 belongs to. Based on a simple discovery mechanism a provider can=20 establish a trust path to this home network. Once this is established,=20 the provider can authenticate the user and check his credit with the=20 home network. Accounting and rate information will be sent to the home=20 network for mediation and processing.=20 @ http://www.snom.com/download/draft-behrens-sipping-roaming-architecture-0= 1.txt Regards, Harry > Thanks, > > Anir > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 26 10:12:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22300 for ; Mon, 26 Apr 2004 10:12:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6oG-00013r-2r for sip-archive@odin.ietf.org; Mon, 26 Apr 2004 10:10:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QEAC1p004075 for sip-archive@odin.ietf.org; Mon, 26 Apr 2004 10:10:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6fO-0002GS-EY; Mon, 26 Apr 2004 10:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Wl-0007Zx-Sg for sip@optimus.ietf.org; Mon, 26 Apr 2004 09:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20490 for ; Mon, 26 Apr 2004 09:52:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6Wj-0000Gi-QX for sip@ietf.org; Mon, 26 Apr 2004 09:52:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6Vu-0000Dd-00 for sip@ietf.org; Mon, 26 Apr 2004 09:51:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BI6V1-00004m-00 for sip@ietf.org; Mon, 26 Apr 2004 09:50:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 06:01:18 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QDnkW9028705; Mon, 26 Apr 2004 06:49:46 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHW22750; Mon, 26 Apr 2004 09:49:45 -0400 (EDT) Message-ID: <408D1379.4030503@cisco.com> Date: Mon, 26 Apr 2004 09:49:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.elwell@siemens.com CC: sip@ietf.org References: <200404231936.PAA03461@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re:draft-elwell-sip-state-update-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, I agree with you that some clarification would be helpful. I just have a few nits with your draft: Some other potential pieces of state could be mentioned in section 2: - a body part with a content-disposition of "alert" - a body part with the content-disposition of "icon" These have never been very well explained, and have some semantic overlap with the Alert-Info and Call-Info header. It may be that the best way to deal with them would be to simply remove these content dispositions, or document that they must be used together with a Content-Id and a reference from an Alert-Info or Call-Info header. Section 3.1 says "The UPDATE mechanism [2] provides a means for updating the session using a 2-message sequence (request/response) during an INVITE-initiated dialog." AFAIK it isn't limited to use in invite-initiated dialogs. For instance, it could be used for target refresh in a subscribe-initiated dialog. Section 4 makes some specific proposals. One it doesn't make, that shoudl be considered, is updating 3261 to further elaborate the state that is maintained as part of a dialog, and that is subject to change. Re the open issue in section 5: presumably the purpose of sending an UPDATE is to change some aspect of the state of the dialog. No matter what piece of state that is, sending overlapping UPDATE requests makes it difficult to reach a consistent agreement about what the state of the dialog is. For instance: A B | (1)UPDATE(From=C) | |------------------>| | | | (2)UPDATE(From=D) | |------------------>| | | | 200 OK (2) | |<------------------| | 200 OK (1) | |<------------------| (Perhaps this happened because message (1) got lost in the network for awhile.) You could try to tighten this up by saying that you can't have concurrent requests outstanding that revise the same aspect of state. But that starts to get very complex to define precisely, especially since some aspects of state (like the Contact) are required to be transmitted in every UPDATE or reINVITE, even if unchanged. But its perhaps simpler to just leave this alone. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Apr 26 15:18:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12597 for ; Mon, 26 Apr 2004 15:18:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBXe-0004tf-Da for sip-archive@odin.ietf.org; Mon, 26 Apr 2004 15:13:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QJDMiL018813 for sip-archive@odin.ietf.org; Mon, 26 Apr 2004 15:13:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBKn-00034v-78; Mon, 26 Apr 2004 15:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBBC-0001Tg-Aq for sip@optimus.ietf.org; Mon, 26 Apr 2004 14:50:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09795 for ; Mon, 26 Apr 2004 14:50:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBB9-0006hW-Dl for sip@ietf.org; Mon, 26 Apr 2004 14:50:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBAH-0006e3-00 for sip@ietf.org; Mon, 26 Apr 2004 14:49:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIB9f-0006YM-00 for sip@ietf.org; Mon, 26 Apr 2004 14:48:35 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 11:00:49 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QIm2W9006186; Mon, 26 Apr 2004 11:48:02 -0700 (PDT) Received: from [10.0.0.107] (sjc-vpn1-480.cisco.com [10.21.97.224]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOK45541; Mon, 26 Apr 2004 11:48:01 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 23 Apr 2004 21:17:15 -1000 Subject: Re: RE : [Sip] History-Info Privacy Issue From: Cullen Jennings To: PROUVOST S=?ISO-8859-1?B?6Q==?=bastien FTRD/DAC/ISS , "Jesske, R" , , CC: GARCIN S=?ISO-8859-1?B?6Q==?=bastien FTRD/DAC/ISS Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3165814081_1341657" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3165814081_1341657 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I think that is a fair concern. The privacy of this is going to be somewhat confusing at best. Defining it across two drafts will add to the confusion. I still don=B9t care greatly one way or the other but I see your point. On 4/22/04 8:14 AM, "PROUVOST S=E9bastien FTRD/DAC/ISS" wrote: > I also support 1 because I think 2 will lead to have two different privac= y > mechanisms associated with a single header (depending on whether the > additional draft is supported or not) which is not what we want. > =20 > Sebastien Prouvost > France Telecom R&D >> =20 >> =20 >> -----Message d'origine----- >> De : sip-admin@ietf.org [mailto:sip-admin@ietf.org] De la part de Jessk= e, R >> Envoy=E9 : jeudi 22 avril 2004 15:20 >> =C0 : fluffy@cisco.com; mary.barnes@nortelnetworks.com; sip@ietf.org >> Objet : AW: [Sip] History-Info Privacy Issue >>=20 >> =20 >> I favour 1, because I think this should be kept together. >> =20 >> =20 >> =20 >> Best Regards >> =20 >> =20 >> =20 >> Roland >> =20 >>> =20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org]Im Auftrag von Cull= en >>> Jennings >>> Gesendet: Donnerstag, 22. April 2004 00:04 >>> An: Mary Barnes; sip@ietf.org >>> Betreff: Re: [Sip] History-Info Privacy Issue >>>=20 >>>=20 >>> I don't care a huge amount but I think I slightly favor 2. >>>=20 >>>=20 >>> On 4/16/04 9:05 AM, "Mary Barnes" wro= te: >>>=20 >>> =20 >>>> Per my posting on the status of History-Info, Privacy is one of the >>>> remaining open issues. The proposal currently in the draft is quite >>>> simple: =20 >>>>=20 >>>> If the Privacy header has a priv-value of "Session" or "Header" priva= cy, >>>> the History-Info SHOULD not be included in the Request (or subsequen= t >>>> responses). =20 >>>>=20 >>>> This is effectively applying the fundamental recommendation in RFC332= 3 >>>> that any optional information that can divulge information about the >>>> user(s) should not be included in the requests. >>>>=20 >>>> A proposal was made that there are scenarios (e.g. where local policy >>>> limits the applicability of History-Info within a specific domain) wh= ere >>>> you would want to capture the History-Info but not send it beyond cer= tain >>>> intermediaries or domains. To support this, it was proposed that we = could >>>> extend the Privacy header defined in RFC 3323 with tags for History-I= nfo >>>> something like the following: >>>>=20 >>>> priv-value =3D "history" / "history-index" >>>>=20 >>>> The "history" priv-value would mean that all the History-Info entries >>>> should be removed. The "history-index" would be used to indicate tha= t the >>>> specific entry is to be removed and would need to have the Privacy he= ader >>>> escaped in the URI so that it can be associated with a specific >>>> History-Info entry (or we need to add another field to History-Info f= or >>>> this). =20 >>>>=20 >>>> So, I think we have two options here: >>>> 1) Extend History-Info to have an optional privacy field along the li= nes >>>> of what's detailed above. >>>>=20 >>>> 2) Defer the definition of the privacy field to a separate draft, sin= ce it >>>> appears to be primarily limited to scenarios with certain trust model= s. >>>>=20 >>>> So, if folks could just take a bit of time and consider their prefere= nce, >>>> I would like to get the draft updated soon and closed off prior to th= e >>>> Interim meeting. >>>>=20 >>>> Regards,=20 >>>> Mary H. Barnes >>>> mary.barnes@nortelnetworks.com >>>>=20 >>>=20 >=20 --B_3165814081_1341657 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: RE : [Sip] History-Info Privacy Issue
I think that is a fair concern. The privacy of this is going to be somewhat= confusing at best. Defining it across two drafts will add to the confusion.= I still don’t care greatly one way or the other but I see your point.=


On 4/22/04 8:14 AM, "PROUVOST Sébastien FTRD/DAC/ISS" <= sebastien.prouvost@francetelecom.com> wrote:

I also support 1 because I think 2 will lead to have = two different privacy mechanisms associated with a single header (depending = on whether the additional draft is supported or not) which is not what we wa= nt.
Sebastien Prouvost
France Telecom R&D

 
-----Message d'origine-----
De : sip-admin@ietf.org  [= mailto:sip-admin@ietf.org] De la part de Jesske,  R
Envoyé : jeudi 22 avril 2004 15:20
À :  fluffy@cisco.com; mary.barnes@nortelnetworks.com; &= nbsp;sip@ietf.org
Objet : AW: [Sip] History-Info Privacy  Issue
I  favour 1, because I= think this should be kept together.
 
 
Best  Regards
 
 
Roland

-----Ursprüngliche Nachricht-----
Von: sip-admin@ietf.org  [= mailto:sip-admin@ietf.org]Im Auftrag von Cullen  Jennings Gesendet: Donnerstag, 22. April 2004 00:04
An:  Mary Barnes; sip@ietf.org
Betreff: Re: [Sip] History-Info Privacy  Issue


I don't care a huge amount but I think I  slightly favor 2.


On 4/16/04 9:05 AM, "Mary Barnes"  <mary.barnes@nortelnet= works.com> wrote:

 
Per my  posting on the status of History-Info, Privacy is one of the= remaining  open issues.  The proposal currently in the draft is q= uite simple:  

If the Privacy header has a priv-value of "Session" or "Head= er"  privacy, the History-Info  SHOULD not be included in the= Request (or  subsequent responses).  

This is effectively applying the  fundamental recommendation in RFC332= 3 that any optional information that  can divulge information about the= user(s) should not be included in the  requests.  

A proposal was made that there are scenarios (e.g.  where local policy= limits the applicability of History-Info within a  specific domain) wh= ere you would want to capture the History-Info but not  send it beyond = certain intermediaries or domains.  To support this,  it was propo= sed that we could extend the Privacy header defined in RFC  3323 with t= ags for History-Info something like the  following:

priv-value =3D "history" / "history-index"   
The "history" priv-value would mean that all the  History-In= fo entries should be removed.  The "history-index" would be &= nbsp;used to indicate that the specific entry is to be removed and would nee= d  to have the Privacy header escaped in the URI so that it can be asso= ciated  with a specific History-Info entry (or we need to add another f= ield to  History-Info for this).    

So, I think we have two  options here:
1) Extend History-Info to have an optional privacy field  along the li= nes of what's detailed above.  

2) Defer the  definition of the privacy field to a separate draft, sin= ce it appears to  be primarily limited to scenarios with certain trust = models.   

So, if folks could just take a bit of time and consider  their prefere= nce, I would like to get the draft updated soon and closed  off prior t= o the Interim meeting.

Regards,
Mary H. Barnes  
mary.barnes@nortelnetworks.com




--B_3165814081_1341657-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 27 04:03:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12571 for ; Tue, 27 Apr 2004 04:03:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINUT-000355-0n for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 03:58:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R7wqRa011843 for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 03:58:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINKw-0001vk-2n; Tue, 27 Apr 2004 03:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINFv-0001Hg-8y for sip@optimus.ietf.org; Tue, 27 Apr 2004 03:43:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11680 for ; Tue, 27 Apr 2004 03:43:48 -0400 (EDT) From: Jari.P.Kinnunen@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BINFs-00037H-Mw for sip@ietf.org; Tue, 27 Apr 2004 03:43:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINEq-0002wv-00 for sip@ietf.org; Tue, 27 Apr 2004 03:42:45 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BINEK-0002mt-00 for sip@ietf.org; Tue, 27 Apr 2004 03:42:12 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R7gDH13399 for ; Tue, 27 Apr 2004 10:42:13 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 10:42:00 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3R7g0HT020044 for ; Tue, 27 Apr 2004 10:42:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00sVFH2d; Tue, 27 Apr 2004 10:39:31 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R7cxJ05187 for ; Tue, 27 Apr 2004 10:38:59 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 10:38:52 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 10:38:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2004 10:38:49 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com> Thread-Topic: Application identification with callee caps/caller preferences Thread-Index: AcQsKq5Fd4YSeysSTwy/TyseMsFXCQ== To: X-OriginalArrivalTime: 27 Apr 2004 07:38:52.0186 (UTC) FILETIME=[AFBCEFA0:01C42C2A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Application identification with callee caps/caller preferences Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, I have a question on following scenario.=20 The user Y has two games installed Chess (named x-chess) and Othello = (named x-othello). The caller X has the equivalent chess-game (x-chess) = and would like to use SIP to invite Y for a game.=20 Is the following approach correct according to the callee caps/caller = preferences specs? Namely is it correct to use the 'type' media feature = tag in this way. In practice here the 'type' tag identifies the = application and on the other hand defines also the media capability of = the UA (since the x-chess in this case might use whatever = "gaming-protocol" as media stream). The callee Y would generate a registration which looks like, in part: For the Chess game: REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: sip:Y1@pc.example.com ;type=3D"application/x-chess" For the Othello game: REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: sip:Y2@pc.example.com ;type=3D"application/x-othello" Now when the caller X wants to play x-chess it would express its' = preference by generating an INVITE which looks like, in part: INVITE sip:Y@example.com SIP/2.0 From: sip:X@example.com To: sip:Y@example.com Accept-Contact: *;type=3D"application/x-chess";require;explicit Best Regards, Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 27 10:13:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02612 for ; Tue, 27 Apr 2004 10:13:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITGt-0002u6-Ep for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 10:09:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RE9FxW011162 for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 10:09:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITAr-00083m-Us; Tue, 27 Apr 2004 10:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISzS-0005Xb-Lt for sip@optimus.ietf.org; Tue, 27 Apr 2004 09:51:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01241 for ; Tue, 27 Apr 2004 09:51:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISzM-0000gv-NK for sip@ietf.org; Tue, 27 Apr 2004 09:51:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISyW-0000dJ-00 for sip@ietf.org; Tue, 27 Apr 2004 09:50:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BISxf-0000Wh-00 for sip@ietf.org; Tue, 27 Apr 2004 09:49:23 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2004 06:00:25 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3RDmUSu015618; Tue, 27 Apr 2004 06:48:30 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOL10179; Tue, 27 Apr 2004 06:48:23 -0700 (PDT) Date: Tue, 27 Apr 2004 09:48:22 -0400 From: David Oran To: Jari.P.Kinnunen@nokia.com, sip@ietf.org Subject: Re: [Sip] Application identification with callee caps/caller preferences Message-ID: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com > X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This seems a bit of a stretch for callee caps. What bothers me is the notion i that you want to play a game with somebody, and which game is determined by a preference matching scheme. I suppose there's nothing horrible in that - it just strikes me as weird. I would think that you would be more likely to choose the combination of participant+game through addressing, such as by having multiple registrations of the form sip:Y.othello@example.com and sip:Y.chess@example.com This has the additional benefit of not requiring a registry for game names. Dave. --On Tuesday, April 27, 2004 10:38 AM +0300 Jari.P.Kinnunen@nokia.com wrote: > Hi, I have a question on following scenario. > > The user Y has two games installed Chess (named x-chess) and Othello > (named x-othello). The caller X has the equivalent chess-game (x-chess) > and would like to use SIP to invite Y for a game. Is the following > approach correct according to the callee caps/caller preferences specs? > Namely is it correct to use the 'type' media feature tag in this way. In > practice here the 'type' tag identifies the application and on the other > hand defines also the media capability of the UA (since the x-chess in > this case might use whatever "gaming-protocol" as media stream). > > The callee Y would generate a registration which looks like, in part: > > For the Chess game: > > REGISTER sip:example.com SIP/2.0 > To: sip:Y@example.com > Contact: sip:Y1@pc.example.com > ;type="application/x-chess" > > For the Othello game: > > REGISTER sip:example.com SIP/2.0 > To: sip:Y@example.com > Contact: sip:Y2@pc.example.com > ;type="application/x-othello" > > Now when the caller X wants to play x-chess it would express its' > preference by generating an INVITE which looks like, in part: > > INVITE sip:Y@example.com SIP/2.0 > From: sip:X@example.com > To: sip:Y@example.com > Accept-Contact: *;type="application/x-chess";require;explicit > > > Best Regards, > Jari > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 27 12:28:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10475 for ; Tue, 27 Apr 2004 12:28:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVNd-0001Dk-Qb for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 12:24:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGOLoR004685 for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 12:24:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV23-0003wr-MQ; Tue, 27 Apr 2004 12:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUuC-00019I-OZ for sip@optimus.ietf.org; Tue, 27 Apr 2004 11:53:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08471 for ; Tue, 27 Apr 2004 11:53:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUu9-0007Sz-Fc for sip@ietf.org; Tue, 27 Apr 2004 11:53:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUtD-0007QT-00 for sip@ietf.org; Tue, 27 Apr 2004 11:52:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BIUsF-0007MR-00 for sip@ietf.org; Tue, 27 Apr 2004 11:51:55 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2004 08:52:36 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3RFp8Su023826; Tue, 27 Apr 2004 08:51:08 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHX15926; Tue, 27 Apr 2004 11:51:06 -0400 (EDT) Message-ID: <408E816A.8070601@cisco.com> Date: Tue, 27 Apr 2004 11:51:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Oran CC: Jari.P.Kinnunen@nokia.com, sip@ietf.org Subject: Re: [Sip] Application identification with callee caps/caller preferences References: <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com > Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think what is proposed is quite reasonable. Given that the game is defined by the type of media stream used to interact, the simplest approach is simply to send an INVITE to the AoR, offering the desired kind of media stream and not bothering with callerprefs at all. In that case the invite would be forked to all the callee's devices. Presumably those that couldn't handle the media type would refuse the call, and any that so support it and are available might respond with a 180. Using callerprefs here is possibly a slight optimization, especially in case the proxy were to try serial forking. And it is also insurance against devices that might accept the call while refusing the media. This would be more important if you want two streams - one for the game and another for voice. If you simply offer both then you run a real risk that an audio phone might accept the call and refuse the game stream. Of course it is also possible to use separate addresses for the games. But that might be inconvenient, and limiting if the game console also does voice and/or video. Paul David Oran wrote: > This seems a bit of a stretch for callee caps. What bothers me is the > notion i that you want to play a game with somebody, and which game is > determined by a preference matching scheme. I suppose there's nothing > horrible in that - it just strikes me as weird. > > I would think that you would be more likely to choose the combination of > participant+game through addressing, such as by having multiple > registrations of the form > > sip:Y.othello@example.com and sip:Y.chess@example.com > > This has the additional benefit of not requiring a registry for game names. > > Dave. > > --On Tuesday, April 27, 2004 10:38 AM +0300 Jari.P.Kinnunen@nokia.com > wrote: > >> Hi, I have a question on following scenario. >> >> The user Y has two games installed Chess (named x-chess) and Othello >> (named x-othello). The caller X has the equivalent chess-game (x-chess) >> and would like to use SIP to invite Y for a game. Is the following >> approach correct according to the callee caps/caller preferences specs? >> Namely is it correct to use the 'type' media feature tag in this way. In >> practice here the 'type' tag identifies the application and on the other >> hand defines also the media capability of the UA (since the x-chess in >> this case might use whatever "gaming-protocol" as media stream). >> >> The callee Y would generate a registration which looks like, in part: >> >> For the Chess game: >> >> REGISTER sip:example.com SIP/2.0 >> To: sip:Y@example.com >> Contact: sip:Y1@pc.example.com >> ;type="application/x-chess" >> >> For the Othello game: >> >> REGISTER sip:example.com SIP/2.0 >> To: sip:Y@example.com >> Contact: sip:Y2@pc.example.com >> ;type="application/x-othello" >> >> Now when the caller X wants to play x-chess it would express its' >> preference by generating an INVITE which looks like, in part: >> >> INVITE sip:Y@example.com SIP/2.0 >> From: sip:X@example.com >> To: sip:Y@example.com >> Accept-Contact: *;type="application/x-chess";require;explicit >> >> >> Best Regards, >> Jari >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 27 12:49:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12449 for ; Tue, 27 Apr 2004 12:49:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVaN-0004WA-7D for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 12:37:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGbV9E017364 for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 12:37:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVPG-0001oy-IJ; Tue, 27 Apr 2004 12:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV55-0004LI-77 for sip@optimus.ietf.org; Tue, 27 Apr 2004 12:05:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09342 for ; Tue, 27 Apr 2004 12:05:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIV51-0000jb-EV for sip@ietf.org; Tue, 27 Apr 2004 12:05:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIV47-0000fC-00 for sip@ietf.org; Tue, 27 Apr 2004 12:04:12 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1BIV3E-0000aj-00 for sip@ietf.org; Tue, 27 Apr 2004 12:03:16 -0400 Received: from softarmor.com (port-213-160-6-4.reverse.qsc.de [213.160.6.4]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i3RG3ju4029847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2004 11:03:47 -0500 Message-ID: <408E841B.70900@softarmor.com> Date: Tue, 27 Apr 2004 11:02:35 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Oran CC: Jari.P.Kinnunen@nokia.com, sip@ietf.org Subject: Re: [Sip] Application identification with callee caps/caller preferences References: <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com > In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David Oran wrote: > sip:Y.othello@example.com and sip:Y.chess@example.com > > This has the additional benefit of not requiring a registry for game names. This alternative has the additional disadvantage of either not resolving through any proxy/registrar that I know of, or of requiring a seperate REGISTER message and authentication transacation for each client-game combination (not to mention account creation). Suppose I had three hundred games on my PDA . . . Use of a preference/capability tag for a "chess" call gets routed to a machine with that game is just as reasonable as using pref/cap matching to make sure a "video" call request gets routed to a display device with a camera and sound. Of course, I'm still deeply confused between: 1) preference/capability negotiation enabled by offer/answer 2) preference/capability negotiation enabled by callee-caps/caller-pref. The issue of having a huge registry of names seems to be valid, however. Options that come to mind: 1) Non-registered "user capability" sub-tags 2) More SDP extensions . . . we're really describing the session we want, not the capabilities of the target. 3) URI parameters, anybody? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 27 13:31:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15539 for ; Tue, 27 Apr 2004 13:31:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWNk-0008Vs-Fr for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 13:28:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RHSW05032717 for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 13:28:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWBr-0006Ya-Mx; Tue, 27 Apr 2004 13:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIW6N-0004uj-1s for sip@optimus.ietf.org; Tue, 27 Apr 2004 13:10:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13983 for ; Tue, 27 Apr 2004 13:10:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIW6J-0006Dl-28 for sip@ietf.org; Tue, 27 Apr 2004 13:10:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIW5J-00061l-00 for sip@ietf.org; Tue, 27 Apr 2004 13:09:31 -0400 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BIW3W-0005XB-00 for sip@ietf.org; Tue, 27 Apr 2004 13:07:38 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3RH6h05021015 for ; Tue, 27 Apr 2004 12:07:10 -0500 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 4070325900359F54; Tue, 27 Apr 2004 13:02:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Application identification with callee caps/caller preferences Date: Tue, 27 Apr 2004 13:07:09 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A06E667C7@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Sip] Application identification with callee caps/caller preferences Thread-Index: AcQsdAwmjBEEZh7HRtmpqbeO/INVqgABU04w From: "Roy, Radhika R, ALABS" To: "Paul Kyzivat" , "David Oran" Cc: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Is not that game will be a kind of "shared application" consisting of audio synchronized with graphics? If so, SDP itself may also provide an opportunity for negotiations. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Paul Kyzivat Sent: Tuesday, April 27, 2004 11:51 AM To: David Oran Cc: Jari.P.Kinnunen@nokia.com; sip@ietf.org Subject: Re: [Sip] Application identification with callee caps/caller preferences I think what is proposed is quite reasonable. Given that the game is=20 defined by the type of media stream used to interact, the simplest=20 approach is simply to send an INVITE to the AoR, offering the desired=20 kind of media stream and not bothering with callerprefs at all. In that=20 case the invite would be forked to all the callee's devices. Presumably=20 those that couldn't handle the media type would refuse the call, and any that so support it and are available might respond with a 180. Using callerprefs here is possibly a slight optimization, especially in=20 case the proxy were to try serial forking. And it is also insurance=20 against devices that might accept the call while refusing the media. This would be more important if you want two streams - one for the game=20 and another for voice. If you simply offer both then you run a real risk that an audio phone might accept the call and refuse the game stream. Of course it is also possible to use separate addresses for the games.=20 But that might be inconvenient, and limiting if the game console also=20 does voice and/or video. Paul David Oran wrote: > This seems a bit of a stretch for callee caps. What bothers me is the=20 > notion i that you want to play a game with somebody, and which game is > determined by a preference matching scheme. I suppose there's nothing=20 > horrible in that - it just strikes me as weird. >=20 > I would think that you would be more likely to choose the combination of=20 > participant+game through addressing, such as by having multiple=20 > registrations of the form >=20 > sip:Y.othello@example.com and sip:Y.chess@example.com >=20 > This has the additional benefit of not requiring a registry for game names. >=20 > Dave. >=20 > --On Tuesday, April 27, 2004 10:38 AM +0300 Jari.P.Kinnunen@nokia.com=20 > wrote: >=20 >> Hi, I have a question on following scenario. >> >> The user Y has two games installed Chess (named x-chess) and Othello >> (named x-othello). The caller X has the equivalent chess-game (x-chess) >> and would like to use SIP to invite Y for a game. Is the following >> approach correct according to the callee caps/caller preferences specs? >> Namely is it correct to use the 'type' media feature tag in this way. In >> practice here the 'type' tag identifies the application and on the other >> hand defines also the media capability of the UA (since the x-chess in >> this case might use whatever "gaming-protocol" as media stream). >> >> The callee Y would generate a registration which looks like, in part: >> >> For the Chess game: >> >> REGISTER sip:example.com SIP/2.0 >> To: sip:Y@example.com >> Contact: sip:Y1@pc.example.com >> ;type=3D"application/x-chess" >> >> For the Othello game: >> >> REGISTER sip:example.com SIP/2.0 >> To: sip:Y@example.com >> Contact: sip:Y2@pc.example.com >> ;type=3D"application/x-othello" >> >> Now when the caller X wants to play x-chess it would express its' >> preference by generating an INVITE which looks like, in part: >> >> INVITE sip:Y@example.com SIP/2.0 >> From: sip:X@example.com >> To: sip:Y@example.com >> Accept-Contact: *;type=3D"application/x-chess";require;explicit >> >> >> Best Regards, >> Jari >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Apr 27 13:52:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16617 for ; Tue, 27 Apr 2004 13:52:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWZ5-0002rl-Jj for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 13:40:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RHeFIA011010 for sip-archive@odin.ietf.org; Tue, 27 Apr 2004 13:40:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWPM-0000ZP-9I; Tue, 27 Apr 2004 13:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWIX-0007Ud-2E for sip@optimus.ietf.org; Tue, 27 Apr 2004 13:23:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15031 for ; Tue, 27 Apr 2004 13:23:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIWIT-0007mA-2z for sip@ietf.org; Tue, 27 Apr 2004 13:23:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIWHc-0007hN-00 for sip@ietf.org; Tue, 27 Apr 2004 13:22:12 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIWH9-0007bG-00 for sip@ietf.org; Tue, 27 Apr 2004 13:21:43 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2004 09:32:58 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3RHLCW9001527; Tue, 27 Apr 2004 10:21:12 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHX23914; Tue, 27 Apr 2004 13:21:12 -0400 (EDT) Message-ID: <408E9687.2090008@cisco.com> Date: Tue, 27 Apr 2004 13:21:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: David Oran , Jari.P.Kinnunen@nokia.com, sip@ietf.org Subject: Re: [Sip] Application identification with callee caps/caller preferences References: <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com > <408E841B.70900@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean Willis wrote: > David Oran wrote: > >> sip:Y.othello@example.com and sip:Y.chess@example.com >> >> This has the additional benefit of not requiring a registry for game >> names. > > > This alternative has the additional disadvantage of either not resolving > through any proxy/registrar that I know of, or of requiring a seperate > REGISTER message and authentication transacation for each client-game > combination (not to mention account creation). Suppose I had three > hundred games on my PDA . . . > > Use of a preference/capability tag for a "chess" call gets routed to a > machine with that game is just as reasonable as using pref/cap matching > to make sure a "video" call request gets routed to a display device with > a camera and sound. > > Of course, I'm still deeply confused between: > 1) preference/capability negotiation enabled by offer/answer > 2) preference/capability negotiation enabled by callee-caps/caller-pref. See my earlier reply. Forking and offer/answer provide a partial solution. But offer/answer doesn't give you a way to say you don't want the call unless your offered media are accepted. At least not an easy way. Conceivably some new extension to preconditions could be made to handle this kind of thing. Lacking that you run the risk of having an unsuitable device answer, even if there is a suitable device present. Callerprefs gives you an increased likelihood that you will end up with a suitable device. > The issue of having a huge registry of names seems to be valid, however. I don't see how you can avoid that, one way or another. If you are going to set up the session with sip, then there needs to be some media stream. If the media stream protocol is game dependent then it needs to be registered somehow to be referenced in an m-line. I suppose the alternative is some generic game protocol. But I doubt that would fly, and even if it did, you would still have to discover somehow what games you had in common, and pick one. > Options that come to mind: > > 1) Non-registered "user capability" sub-tags > 2) More SDP extensions . . . we're really describing the session we > want, not the capabilities of the target. > 3) URI parameters, anybody? These really are capabilities. But you don't necessarily always enable all your capabilities, and so perhaps don't offer them all by default. This is a relatively new concept in practice, since practically speaking most sip devices today only do voice. (I'll bet that video phones aren't always going to want to offer video - there will probably be a button that turns that on/off.) If there are a *lot* of supported game protocols, and you just want to dynamically choose one that both ends support, then I think you will need a separate way of negotiating that. Maybe you simply establish an MSRP IM session, discuss what game to play, and then reinvite with an offer that adds a stream for the chosen game. Of course, if you started out with IM, the other party might not be IMing from a game console. But that should simply be a matter of him first transferring his end of the call to the game console before gaming begins. E.g. - Alice, from game console, opens IM session with Bob - IM session is established on Bob's PC. - Alice sends message to Bob espressing an interest in playing game. - They discuss what game to play. Decide on Doom. - Bob transfers the IM session to his X-Box so he has the good audio, TV screen, and game controllers. (This could also be done by conferencing in the X-Box.) - Alice sends reinvite, adding a Doom media session. This goes to Bob's X-Box. Now have both Doom and IM. - They play ... Other possibilities: - simply send invite with a separate m-line for each supported game, using ALT to say they are mutually exclusive. - publish presence, listing all the types (including games) supported. Then watcher can choose which of those to offer when calling. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 28 12:07:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24684 for ; Wed, 28 Apr 2004 12:07:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrN8-0000fy-Ih for sip-archive@odin.ietf.org; Wed, 28 Apr 2004 11:53:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SFrIsl002560 for sip-archive@odin.ietf.org; Wed, 28 Apr 2004 11:53:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrG5-0006lB-Uh; Wed, 28 Apr 2004 11:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqxB-00013e-4E for sip@optimus.ietf.org; Wed, 28 Apr 2004 11:26:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21410 for ; Wed, 28 Apr 2004 11:26:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqx8-0006u6-PB for sip@ietf.org; Wed, 28 Apr 2004 11:26:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqwT-0006oR-00 for sip@ietf.org; Wed, 28 Apr 2004 11:25:46 -0400 Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BIqva-0006ef-00 for sip@ietf.org; Wed, 28 Apr 2004 11:24:50 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Apr 2004 16:24:12 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E52B33@baker.datcon.co.uk> From: "Paul D.Smith" To: SIP WG Cc: "Paul D.Smith" Date: Wed, 28 Apr 2004 16:24:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] RFC 3261 bug in description of 487? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , It seems that the description of a 487 response in RFC 3261 is incomplete. Consider the following sections from RFC 3261. 21.4.25 487 Request Terminated The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself. This might be interpreted as meaning that a 487 should _only_ be sent if a request has been terminated by a BYE or a CANCEL. However this is not consistent with other parts of RFC 3261, where a 487 is generated without the involvement of either BYE or CANCEL. One example of this is section 13.3.1, reproduced here. 13.3.1 Processing of the INVITE The UAS core will receive INVITE requests from the transaction layer. It first performs the request processing procedures of Section 8.2, which are applied for both requests inside and outside of a dialog. Assuming these processing states are completed without generating a response, the UAS core performs the additional processing steps: 1. If the request is an INVITE that contains an Expires header field, the UAS core sets a timer for the number of seconds indicated in the header field value. When the timer fires, the invitation is considered to be expired. If the invitation expires before the UAS has generated a final response, a 487 (Request Terminated) response SHOULD be generated. In the this case a 487 response is generated without the involvement of either CANCEL or BYE. Am I correct in believing that sections such as 13.3.1 are correct and there is simply a bug in that section 21.4.25 is incomplete? Regards, Paul DS Paul D Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 28 17:40:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25114 for ; Wed, 28 Apr 2004 17:40:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwRT-0008T1-5O for sip-archive@odin.ietf.org; Wed, 28 Apr 2004 17:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLI7WD032514 for sip-archive@odin.ietf.org; Wed, 28 Apr 2004 17:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIw74-0006Ot-05; Wed, 28 Apr 2004 16:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfvs-00029a-6C for sip@optimus.ietf.org; Thu, 22 Apr 2004 11:16:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04329 for ; Thu, 22 Apr 2004 11:16:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfvp-00034k-Cb for sip@ietf.org; Thu, 22 Apr 2004 11:16:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfvV-0002pn-00 for sip@ietf.org; Thu, 22 Apr 2004 11:15:46 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1BGfuC-0002ZK-00 for sip@ietf.org; Thu, 22 Apr 2004 11:14:24 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 17:14:19 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4287C.7B776D2D" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE : [Sip] History-Info Privacy Issue Date: Thu, 22 Apr 2004 17:14:17 +0200 Message-ID: Thread-Topic: [Sip] History-Info Privacy Issue Thread-Index: AcQocVB6jMYhn05UR5+gK8DLH42twgACuVGQ From: =?iso-8859-1?Q?PROUVOST_S=E9bastien_FTRD/DAC/ISS?= To: "Jesske, R" , , , Cc: =?iso-8859-1?Q?GARCIN_S=E9bastien_FTRD/DAC/ISS?= X-OriginalArrivalTime: 22 Apr 2004 15:14:19.0072 (UTC) FILETIME=[7BC41400:01C4287C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C4287C.7B776D2D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I also support 1 because I think 2 will lead to have two different = privacy mechanisms associated with a single header (depending on whether = the additional draft is supported or not) which is not what we want. =20 Sebastien Prouvost France Telecom R&D -----Message d'origine----- De : sip-admin@ietf.org [mailto:sip-admin@ietf.org] De la part de = Jesske, R Envoy=E9 : jeudi 22 avril 2004 15:20 =C0 : fluffy@cisco.com; mary.barnes@nortelnetworks.com; sip@ietf.org Objet : AW: [Sip] History-Info Privacy Issue I favour 1, because I think this should be kept together. =20 Best Regards =20 Roland -----Urspr=FCngliche Nachricht----- Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org]Im Auftrag von Cullen = Jennings Gesendet: Donnerstag, 22. April 2004 00:04 An: Mary Barnes; sip@ietf.org Betreff: Re: [Sip] History-Info Privacy Issue I don't care a huge amount but I think I slightly favor 2.=20 On 4/16/04 9:05 AM, "Mary Barnes" = wrote: Per my posting on the status of History-Info, Privacy is one of the = remaining open issues. The proposal currently in the draft is quite = simple:=20 If the Privacy header has a priv-value of "Session" or "Header" privacy, = the History-Info SHOULD not be included in the Request (or subsequent = responses). =20 This is effectively applying the fundamental recommendation in RFC3323 = that any optional information that can divulge information about the = user(s) should not be included in the requests. =20 A proposal was made that there are scenarios (e.g. where local policy = limits the applicability of History-Info within a specific domain) where = you would want to capture the History-Info but not send it beyond = certain intermediaries or domains. To support this, it was proposed = that we could extend the Privacy header defined in RFC 3323 with tags = for History-Info something like the following: priv-value =3D "history" / "history-index" =20 The "history" priv-value would mean that all the History-Info entries = should be removed. The "history-index" would be used to indicate that = the specific entry is to be removed and would need to have the Privacy = header escaped in the URI so that it can be associated with a specific = History-Info entry (or we need to add another field to History-Info for = this). =20 So, I think we have two options here:=20 1) Extend History-Info to have an optional privacy field along the lines = of what's detailed above. =20 2) Defer the definition of the privacy field to a separate draft, since = it appears to be primarily limited to scenarios with certain trust = models. =20 So, if folks could just take a bit of time and consider their = preference, I would like to get the draft updated soon and closed off = prior to the Interim meeting. Regards,=20 Mary H. Barnes=20 mary.barnes@nortelnetworks.com=20 ------_=_NextPart_001_01C4287C.7B776D2D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
I also=20 support 1 because I think 2 will lead to have two different privacy = mechanisms=20 associated with a single header (depending on whether the additional = draft is=20 supported or not) which is not what we want.
 
Sebastien = Prouvost
France Telecom=20 R&D
-----Message d'origine-----
De : = sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org] De la part de Jesske,=20 R
Envoy=E9 : jeudi 22 avril 2004 = 15:20
=C0 :=20 fluffy@cisco.com; mary.barnes@nortelnetworks.com;=20 sip@ietf.org
Objet : AW: [Sip] History-Info Privacy=20 Issue

I=20 favour 1, because I think this should be kept = together.
 
Best=20 Regards
 
Roland
-----Urspr=FCngliche Nachricht-----
Von: = sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]Im Auftrag von Cullen=20 Jennings
Gesendet: Donnerstag, 22. April 2004 = 00:04
An:=20 Mary Barnes; sip@ietf.org
Betreff: Re: [Sip] History-Info = Privacy=20 Issue


I don't care a huge amount but I think = I=20 slightly favor 2.


On 4/16/04 9:05 AM, "Mary Barnes"=20 <mary.barnes@nortelnetworks.com> wrote:
Per = my=20 posting on the status of History-Info, Privacy is one of the = remaining=20 open issues.  The proposal currently in the draft is quite = simple:=20

If the Privacy header has a priv-value of "Session" or = "Header"=20 privacy, the History-Info  SHOULD not be included in the = Request (or=20 subsequent responses).  

This is effectively applying = the=20 fundamental recommendation in RFC3323 that any optional = information that=20 can divulge information about the user(s) should not be included = in the=20 requests.  

A proposal was made that there are = scenarios (e.g.=20 where local policy limits the applicability of History-Info within = a=20 specific domain) where you would want to capture the History-Info = but not=20 send it beyond certain intermediaries or domains.  To support = this,=20 it was proposed that we could extend the Privacy header defined in = RFC=20 3323 with tags for History-Info something like the=20 following:

priv-value =3D "history" / "history-index"=20  

The "history" priv-value would mean that all the=20 History-Info entries should be removed.  The "history-index" = would be=20 used to indicate that the specific entry is to be removed and = would need=20 to have the Privacy header escaped in the URI so that it can be = associated=20 with a specific History-Info entry (or we need to add another = field to=20 History-Info for this).    

So, I think we = have two=20 options here:
1) Extend History-Info to have an optional = privacy field=20 along the lines of what's detailed above.  

2) Defer = the=20 definition of the privacy field to a separate draft, since it = appears to=20 be primarily limited to scenarios with certain trust models.=20  

So, if folks could just take a bit of time and = consider=20 their preference, I would like to get the draft updated soon and = closed=20 off prior to the Interim meeting.

Regards,
Mary H. = Barnes=20
mary.barnes@nortelnetworks.com =


------_=_NextPart_001_01C4287C.7B776D2D-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 28 17:44:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25327 for ; Wed, 28 Apr 2004 17:44:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwUb-0001sh-6Y for sip-archive@odin.ietf.org; Wed, 28 Apr 2004 17:21:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLLL7a007220 for sip-archive@odin.ietf.org; Wed, 28 Apr 2004 17:21:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIw75-0006P6-Mr; Wed, 28 Apr 2004 16:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwvY-0000ug-Hg for sip@optimus.ietf.org; Fri, 23 Apr 2004 05:24:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24257 for ; Fri, 23 Apr 2004 05:24:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGwvT-0003gU-4E for sip@ietf.org; Fri, 23 Apr 2004 05:24:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGwuU-0003RO-00 for sip@ietf.org; Fri, 23 Apr 2004 05:23:50 -0400 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1BGwu9-0003CU-00 for sip@ietf.org; Fri, 23 Apr 2004 05:23:29 -0400 Received: from snom.de (pD9516902.dip.t-dialin.net [217.81.105.2]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i3N9NSCN012175; Fri, 23 Apr 2004 11:23:28 +0200 (MEST) Message-ID: <4088DCC8.6060303@snom.de> Date: Fri, 23 Apr 2004 11:07:20 +0200 From: Harry Behrens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khare, Anir" CC: sip@ietf.org, knuettel@fokus.fraunhofer.de Subject: Re: [Sip] [Query] SIP security and trusted spontaneous interactions between end points References: <1FD836F38652D211A63E0008C7244343125171F1@ntmsg0008.corpmail.telstra.com.au> In-Reply-To: <1FD836F38652D211A63E0008C7244343125171F1@ntmsg0008.corpmail.telstra.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by post.webmailer.de id i3N9NSCN012175 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Khare, Anir wrote: > Hello, > > =20 > > Can someone please point me to the known issues with SIP security? > > =20 > > Also are there any initiatives in progress for using Liberty alliance=20 > like identity/trust infrastructure in conjunction with SIP protocols=20 > to facilitate spontaneous trusted real time communication between a A=20 > party and a B party, who are not registered with one SIP proxy? > > =20 > Karsten Kn=FCttel and I have proposed something to that extent in March o= n=20 the SIPPING list, which uses PKI to allow dynamic agreement on trust and billing=20 relationships. Maybe it proves useful to you: Interdomain Trust-Relationships for SIP-based Roaming This draft describes an authentication mechanism which can be used to=20 enable users of VoIP to globally roam between any number of ITSPs=20 (Internet Telephony Service Providers) without needing to have a prior=20 customer or billing relationship with all of them. This enables=20 profiles and one-line-billing.=20 Providers using this authentication mechanism do neither need full-mesh=20 trust relationships or roaming agreements with every other possible=20 provider nor do they need to rely on a centralized brokerage entity to=20 process calls.=20 The Home Network (HN), which handles all AAA for a user attempting to=20 use an ITSP's service is determined through a unique identifier=20 submitted by the user. This Network Access Identifier [RFC2486]=20 contains information about the trust domain or trust realm the user=20 belongs to. Based on a simple discovery mechanism a provider can=20 establish a trust path to this home network. Once this is established,=20 the provider can authenticate the user and check his credit with the=20 home network. Accounting and rate information will be sent to the home=20 network for mediation and processing.=20 @ http://www.snom.com/download/draft-behrens-sipping-roaming-architecture-0= 1.txt Regards, Harry > Thanks, > > Anir > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Apr 28 17:44:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25344 for ; Wed, 28 Apr 2004 17:44:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwWv-0002yj-VT for sip-archive@odin.ietf.org; Wed, 28 Apr 2004 17:23:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLNjQc011405 for sip-archive@odin.ietf.org; Wed, 28 Apr 2004 17:23:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIw77-0006Pe-BN; Wed, 28 Apr 2004 16:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4eY-0003c0-7K for sip@optimus.ietf.org; Mon, 26 Apr 2004 07:52:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13360 for ; Mon, 26 Apr 2004 07:52:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI4eX-0001Fa-AX for sip@ietf.org; Mon, 26 Apr 2004 07:52:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI4df-00011z-00 for sip@ietf.org; Mon, 26 Apr 2004 07:51:07 -0400 Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1BI4cg-0000np-00 for sip@ietf.org; Mon, 26 Apr 2004 07:50:06 -0400 Received: from snom.de (pD9E0D93A.dip.t-dialin.net [217.224.217.58]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i3QBnxEC017591; Mon, 26 Apr 2004 13:50:01 +0200 (MEST) Message-ID: <408CF352.9030704@snom.de> Date: Mon, 26 Apr 2004 13:32:34 +0200 From: Harry Behrens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khare, Anir" CC: sip@ietf.org, knuettel@fokus.fraunhofer.de Subject: Re: [Sip] [Query] SIP security and trusted spontaneous interactions between end points References: <1FD836F38652D211A63E0008C7244343125171FF@ntmsg0008.corpmail.telstra.com.au> In-Reply-To: <1FD836F38652D211A63E0008C7244343125171FF@ntmsg0008.corpmail.telstra.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by post.webmailer.de id i3QBnxEC017591 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Aniruddha, inline Khare, Anir wrote: >Hello Harry, > >This is interesting. > >A general query: Did you consider using Liberty alliance like protocols = for security and accounting interactions between VN and HN. Are there any= known issues about using Liberty protocols in this context? > =20 > Yes. This was one of our first choices. The problem is that we are=20 trying to be pragmatic (IETF is not a scientists' but an engineers' forum= ). And the actual usage and implementation of LA is less than assuring of=20 its success and potential ubiquity. By using a derivate of Diffie-Helman - essentially that is what it boils=20 down to - we kept it generic as well as simple. Porting this to LA should be straightforward. >A specific question about the requirements (section 2). Is ability for A= lice to get a SIP URI in VN a mandatory requirement? i.e. why can't Alice= use Mobile IP and continue using SIP infrastructure at HN? Is it because= Alice wants to use some resources like PSTN gateway in the VN?=20 > =20 > That is exactly the point. One can assume that the choice given by=20 "local" carriers to be more competitive in terms of call termination to=20 "local" destinations. On the other hand, pls. note that we explicitly propose a double=20 registration in section 7.2.2 of the draft. This assures that Alice can make full use of any services its HN can=20 provide, especially being reachable under her "home" number. Pls. note that MIP would only become necessary in case of physical=20 handover during dialog. The scenario is written for "semi-stationary" or "nomadically mobile"=20 (nomadic in the sense that: "users have to shut down an application or a=20 session and restart it when they connect at the new point of attachment.") -> Layer-7 mobility Extensions would have to be used to provide mobility at layer 4 downwards. Regards, Harry >Regards, >Anir=20 > > >-----Original Message----- >From: Harry Behrens [mailto:hb@snom.de]=20 >Sent: Friday, 23 April 2004 7:07 PM >To: Khare, Anir >Cc: sip@ietf.org; knuettel@fokus.fraunhofer.de >Subject: Re: [Sip] [Query] SIP security and trusted spontaneous interact= ions between end points > >Khare, Anir wrote: > > =20 > >>Hello, >> >>=20 >> >>Can someone please point me to the known issues with SIP security? >> >>=20 >> >> =20 >> > > =20 > >>Also are there any initiatives in progress for using Liberty alliance=20 >>like identity/trust infrastructure in conjunction with SIP protocols=20 >>to facilitate spontaneous trusted real time communication between a A=20 >>party and a B party, who are not registered with one SIP proxy? >> >>=20 >> >> =20 >> > >Karsten Kn=FCttel and I have proposed something to that extent in March = on=20 >the SIPPING list, >which uses PKI to allow dynamic agreement on trust and billing=20 >relationships. >Maybe it proves useful to you: > >Interdomain Trust-Relationships for SIP-based Roaming > >This draft describes an authentication mechanism which can be used to=20 >enable users of VoIP to globally roam between any number of ITSPs=20 >(Internet Telephony Service Providers) without needing to have a prior=20 >customer or billing relationship with all of them. This enables=20 >profiles and one-line-billing.=20 >Providers using this authentication mechanism do neither need full-mesh=20 >trust relationships or roaming agreements with every other possible=20 >provider nor do they need to rely on a centralized brokerage entity to=20 >process calls.=20 >The Home Network (HN), which handles all AAA for a user attempting to=20 >use an ITSP's service is determined through a unique identifier=20 >submitted by the user. This Network Access Identifier [RFC2486]=20 >contains information about the trust domain or trust realm the user=20 >belongs to. Based on a simple discovery mechanism a provider can=20 >establish a trust path to this home network. Once this is established,=20 >the provider can authenticate the user and check his credit with the=20 >home network. Accounting and rate information will be sent to the home=20 >network for mediation and processing.=20 > >@ >http://www.snom.com/download/draft-behrens-sipping-roaming-architecture-= 01.txt > >Regards, > > Harry > > =20 > >>Thanks, >> >>Anir >> >> =20 >> > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > =20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Apr 29 15:52:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24543 for ; Thu, 29 Apr 2004 15:52:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHOr-0001W9-Kl for sip-archive@odin.ietf.org; Thu, 29 Apr 2004 15:41:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJenji005833 for sip-archive@odin.ietf.org; Thu, 29 Apr 2004 15:40:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH9k-0005s9-LJ; Thu, 29 Apr 2004 15:25:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGta-0004d7-4j for sip@optimus.ietf.org; Thu, 29 Apr 2004 15:08:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20462 for ; Thu, 29 Apr 2004 15:08:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGtR-0003CE-3V for sip@ietf.org; Thu, 29 Apr 2004 15:08:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGsV-0003A3-00 for sip@ietf.org; Thu, 29 Apr 2004 15:07:24 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BJGsI-00037p-00 for sip@ietf.org; Thu, 29 Apr 2004 15:07:11 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3TJ6GGe012452; Thu, 29 Apr 2004 13:06:17 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Status of SIP MIB Date: Thu, 29 Apr 2004 13:06:16 -0600 Message-ID: Thread-Topic: [Sip] Status of SIP MIB Thread-Index: AcQSyY4uRxGInwV3TvSDaU6mOOII0QbUWE/A From: "Jean-Francois Mule" To: "Bob Natale" , Cc: , "Kevin Lingle" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Here's one area where you & the wg participants may want to help. One of the comments we got was:=20 is the information model we have in the sip mib 07 sufficient to configure sip *protocol* parameters on basic sip entities (UA, proxy, registrar, etc.)? Both kevin and i implemented earlier versions of this mib on some early sip rfc2543 boxes but speaking for myself, it's been a while I looked closely at sip devices & their configuration. Back then, I was considered a fool to push for sip over tcp... so things have changed. It would be great if some of you could screen sip implementations with the above question in mind and drop us a minimal set of params you need to configure *basic* sip entities in a plain text email (no mib syntax please, just plain text param names with a description and may be a sip rfc section number as a ref but we can take care of the later). And we don't care whether those configuration params are provided on a java-based GUI on a sip phone or via CLI telnet/ssh to a sip proxy or via some kind of xml/netconf: what matters is the what (what protocol parameters get configured), not the how (not the actual configuration protocol & associated data model). This would be of good help. Jean-francois. jfm@cablelabs.com > -----Original Message----- > From: Kevin Lingle [mailto:klingle@cisco.com]=20 > Sent: Thursday, March 25, 2004 4:31 PM > To: Bob Natale > Cc: sip@ietf.org > Subject: Re: [Sip] Status of SIP MIB >=20 >=20 > bob, >=20 > you are welcome to review -07 and comment just as anyone > else is. we have a set of "official" reviewers (4-5 iirc) > from which we've fielded 90+ individual comments. we've=20 > addressed (as in read, corresponded about, given some thought=20 > to, and have a response/solution) a majority of those=20 > comments. the solution - in terms of changes to the mib is=20 > not done in many cases (minor changes are typically done, but=20 > others are larger changes across the mib). as with most=20 > things, it's just a matter of finding the time to work these=20 > changes and work through the remaining comments not yet addressed. >=20 > on one hand i'd love more review of the draft. > on the other hand more comments to address will delay > things more (potentially). >=20 > considering that i want -08 to be the wglc approved > revision we take to iesg, i'd say you should review > -07. >=20 > do you ever get involved as a mib > doctor type or expert reviewer of mib drafts that > have been submitted to iesg? >=20 > kevin >=20 >=20 >=20 > Bob Natale wrote: > > Hi Kevin, > >=20 > > Thanks...I understand...didn't mean to put more pressure on=20 > you or the=20 > > other authors personally...I'd like to help (I was until=20 > recently in a=20 > > role that kept me from being involved in these=20 > efforts)...would it be=20 > > helpful for me to review the -07 version at this point or should I=20 > > wait for the -08 version? (Or "neither"! :-) > >=20 > > Cheers, > > BobN > >=20 > >=20 > >>-----Original Message----- > >>From: Kevin Lingle [mailto:klingle@cisco.com] > >>Sent: Thursday, March 25, 2004 1:55 PM > >>To: Bob Natale > >>Cc: sip@ietf.org > >>Subject: Re: [Sip] Status of SIP MIB > >> > >>bob, > >> > >>agreed. and i think about the need to move the > >>draft forward almost all the time. the issue, for > >>me personally, has been product development priorities. working on=20 > >>this mib is by no means my main job ;) i think i speak for my=20 > >>co-author as well. > >> > >>i alluded to this being the _2nd wglc_ for this draft. > >>that was a result of us pausing, after the 1st wglc > >>was concluded, and taking the extra step to migrate the > >>mibs to be aligned with the 2nd rfc for sip (rfc3261). > >>the release of rfc3261 came about in the same timeframe. > >>so in that sense we are trying to provide the due diligence to make=20 > >>the mibs better. an rfc would probably exist if we had not=20 > taken this=20 > >>step. but it was the right thing to do. > >> > >>my comments about no ground swell relate to: > >>1) the fact that we, over the life of this draft > >> [which is waaaayyyy too long], we've not gotten > >> any sense of urgency to get the mibs done. > >> i expect/hope this will change as sip becomes more and > >> more mainstream. i may have been able to > >> justify more of my time for the draft work > >> had there been a more vocal response from the > >> sip community wrt the need for MIBs to be in > >> place sooner than later. > >> > >>2) our ability to solicit interest from the sip > >> community to review the various drafts has also > >> consistently been a problem. to the point where > >> sometimes i felt we were offering candidate mib > >> objects in a vaccum. having 2 last call reviews > >> has helped this issue though. it is also a case > >> of most folks being very interested in the protocol > >> but not really being "MIB folk" ;) > >> > >> > >>we will eventually get there with the draft (hopefully > >>sooner than later ;). > >> > >>kevin > >> > >>Bob Natale wrote: > >> > >>>Hi Kevin, > >>> > >>> > >>> > >>>>my sense has been all along that there isn't a ground swell of > >>> > >>>immediate > >>> > >>> > >>>>need for the SIP MIBs as of yet across the sip community. > >>> > >>> > >>>Perhaps. But good MIBs tend to beget good (SNMP[v3]-based) > >> > > management > >=20 > >>>applications, not the other way around. And the absence of good > >> > > MIBs > >=20 > >>>for otherwise good technology (e.g., SIP) virtually=20 > guarantees that=20 > >>>other management solutions will be deployed, increasingly lowering > >> > > the > >=20 > >>>sense of (but not the reality of) need for those good MIBs. > >>> > >>>Cheers, > >>>BobN > >>> > >>> > >>>_______________________________________________ > >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol Use=20 > >>>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>>sipping@ietf.org for new developments on the application of sip > >>> > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip