From hannu.hietalahti@nokia.com Wed Dec 1 07:16:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9683A6B40 for ; Wed, 1 Dec 2010 07:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.661 X-Spam-Level: X-Spam-Status: No, score=-4.661 tagged_above=-999 required=5 tests=[AWL=-2.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCwLe-bEGBB9 for ; Wed, 1 Dec 2010 07:16:57 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id EA3183A6C66 for ; Wed, 1 Dec 2010 07:16:56 -0800 (PST) Received: from esebh102.NOE.Nokia.com (esebh102.ntc.nokia.com [172.21.138.183]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oB1FI5Y6007010; Wed, 1 Dec 2010 17:18:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Dec 2010 17:17:08 +0200 Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.109]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 1 Dec 2010 16:17:07 +0100 From: To: , , Date: Wed, 1 Dec 2010 16:17:05 +0100 Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust use Supported Thread-Index: AcuAat6XIt/v9PlARv6xOHOMfSzVMAACn+BqAANhOpAD+bjPkAAUNcGfACvu9HA= Message-ID: <5BAF85033CB5F3439C4DE153165522B110A01B63C5@NOK-EUMSG-06.mgdnok.nokia.com> References: <4CD9E189.6050704@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502F9C72C@ESESSCMS0356.eemea.ericsson.se>, <79C4240C13B4C84B910850B96B1B431201CCCCB8@DEMUEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A058502C718CD@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C718CD@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Dec 2010 15:17:08.0004 (UTC) FILETIME=[D1A58E40:01CB916A] X-Nokia-AV: Clean Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust use Supported X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 15:16:59 -0000 Hi, indeed some Rel-10 CRs were agreed that would add a reference to this draft= and also the use of it in earlier releases has been considered.=20 CRs that introduce the dependency towards this draft are coming for approva= l in TSG CT plenary next week, so it would be useful to understand the leve= l of interest to work on this in IETF, and any possible opposition that mig= ht risk timely completion. (Rel-10 is foreseen to freeze in March 2011). BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext Christer Holmberg >Sent: 30 November, 2010 20:16 >To: Leis, Peter (NSN - DE/Munich); sipcore@ietf.org >Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature-=20 >why notjust use Supported > >Hi, > >At the previous 3GPP CT1 meeting, the group indicated=20 >willingness to use the mechanism in the draft in the work on=20 >session continuity. > >There has been some comments on that we need text regarding=20 >"directionality", ie if an indicated capability is only valid=20 >in one direction, and I agree to that we need to address that. > >But, in general I would like to know what to do in order to=20 >move the draft forward and adopt it as a working group item. > >Regards, > >Christer > >________________________________________ >From: Leis, Peter (NSN - DE/Munich) [peter.leis@nsn.com] >Sent: Tuesday, November 30, 2010 10:51 AM >To: sipcore@ietf.org >Cc: Christer Holmberg; Andrew Allen; pkyzivat@cisco.com >Subject: RE: [sipcore] draft-holmberg-sipcore-proxy-feature-=20 >why notjust use Supported > >hello, > >I support solving the 3GPP use case that Christer was refering=20 >to in the >draft, using the draft as the basis for the work. > >regards >Peter > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of ext Christer Holmberg >> Sent: Wednesday, November 10, 2010 4:01 AM >> To: Andrew Allen; pkyzivat@cisco.com; sipcore@ietf.org >> Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why >> notjust use Supported >> >> >> Hi, >> >> Andrew is correct: just because something isn't a "pure" proxy, it >> doesn't mean it is going to modify the Contact header, Supported >header >> etc. >> >> Also, I think the use-case (which I have presented on the list) where >a >> proxy indicates that the Path address information can be used for >> routing requests in both direction is an example of a "pure" proxy >use- >> case. That is also an old problem, that we have discussed earlier >every >> now and then. >> >> Regards, >> >> Christer >> >> >> >> >> > -----Original Message----- >> > From: sipcore-bounces@ietf.org >> > [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen >> > Sent: 10. marraskuuta 2010 3:20 >> > To: pkyzivat@cisco.com; sipcore@ietf.org >> > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- >> > why not just use Supported >> > >> > >> > I think the second case Paul describes is what in 3GPP is >> > called a Routing B2BUA which sometimes behaves like a proxy >> > and sometimes like a UA. IMHO these entities should use >> > Record-Route to keep themselves on the path and not write >> > their own URI in the Contact but pass the Contact header >> > transparently. To do otherwise breaks things like GRUU and >> > callee caps. >> > >> > I support the solving in a general way of how an intermediary >> > that provides some kind of funtionality on behalf of a UA can >> > indicate its presence to other entities. >> > >> > Another use case for this is helping to solve service >> > interaction problems where multiple application servers are >> > involved and the service logic performed by one may need to >> > be taken into account by the other. >> > >> > I also think it is necessary that UAs can detect the presence >> > of intermediaries such as IP-PBXs and application servers in >> > the path of a session and obtain a URI to which they can send >> > requests to invoke service logic at those servers without >> > them having to overwrite the contact URI for the reasons stated >above. >> > >> > Andrew. >> > >> > ----- Original Message ----- >> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> > Sent: Tuesday, November 09, 2010 07:04 PM >> > To: sipcore@ietf.org >> > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- >> > why not just use Supported >> > >> > I'm tempted to agree with Cullen on this. >> > But I think it "depends". >> > >> > If the B2BUA is a "proper" UA, and inserts its own Contact >> > address in the call, then I think Cullen's description is right. >> > >> > If its a B2BUA because it messes with things a proxy cannot, but >> > *doesn't* modify the Contact address, then just manipulating >> > Supported isn't enough. Then the features that *it* supports >> > are obtainable directly only by sending a request to *it*, >> > using the Route header, etc. >> > to identify that address. >> > >> > Its always seemed to me that a UA should always supply its >> > own Contact address, but I've looked for verification of that >> > in 3261 and not found it. >> > >> > Thanks, >> > Paul >> > >> > On 11/10/2010 4:42 AM, Cullen Jennings wrote: >> > > >> > > So, in my week of agreeing with Hadriel, I think he got it >> > exactly right when he said there is pretty much no feature a >> > "plain" proxy would need for this. If we are talking about >> > things that would be a strict technical read be considered >> > B2BUA even if they are implemented a lot like a proxy, then I >> > can why something provided something like this functionality >> > would be needed. >> > > >> > > But given this would be used by a B2BUA, I don't see why >> > you need anything more than just normal option tags. Say a >> > SIP message comes from A to B to C and now the response is >> > coming back. C says it supports feature c1, c2, and c3. B >> > knows that it can transparently forward on whatever is needed >> > for c1, c2, but not c3 and it knows that in additional to >> > this it can do features b4 and b5. It modifies the Supported >> > header to have c1,c2,b4, and b5. and sends that back to A. >> > > >> > > If the real uses cases have to do with caller pref >> > features, then B can modify those in the same way. >> > > >> > > Anyways, I think we are way way ahead of ourselves >> > discussing mechanism before we even understand what the use >> > cases are we are trying to solve. I'd like to see some >> > specific real world use cases and so we can work out the real >> > requirements. I'm expect the uses cases will contain B2BUA in >> > the call flows - that's reality. >> > > >> > > >> > > On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote: >> > > >> > >> >> > >> >> > >> Hi, >> > >> >> > >> I've submitted a draft, which extends the rr-param rule, >> > allowing proxies to indicate supported features using feature >> > tags in Path, Record-Route etc. >> > >> >> > >> The draft can also be found at: >> > >> >> > >http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-f >> > >> eature-00.txt >> > >> >> > >> As I indicated earlier on the list, and as you can read in >> > the draft, there is a 3GPP use-case where we believe the >> > mechanism could be used. But, there is nothing 3GPP specific >> > about the mechanism as such. >> > >> >> > >> Regards, >> > >> >> > >> Christer >> > >> _______________________________________________ >> > >> sipcore mailing list >> > >> sipcore@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/sipcore >> > > >> > > _______________________________________________ >> > > sipcore mailing list >> > > sipcore@ietf.org >> > > https://www.ietf.org/mailman/listinfo/sipcore >> > > >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> > >> > >--------------------------------------------------------------------- >> > This transmission (including any attachments) may contain >> > confidential information, privileged material (including >> > material protected by the solicitor-client or other >> > applicable privileges), or constitute non-public information. >> > Any use of this information by anyone other than the intended >> > recipient is prohibited. If you have received this >> > transmission in error, please immediately reply to the sender >> > and delete this information from your system. Use, >> > dissemination, distribution, or reproduction of this >> > transmission by unintended recipients is not authorized and >> > may be unlawful. >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> > >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore >= From dworley@avaya.com Thu Dec 2 09:19:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D7528C1BC for ; Thu, 2 Dec 2010 09:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vflAgg0WG5fS for ; Thu, 2 Dec 2010 09:19:20 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 7715A28C1C7 for ; Thu, 2 Dec 2010 09:19:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEpk90yHCzI1/2dsb2JhbACjInGpdAKZD4VHBIReiTM X-IronPort-AV: E=Sophos;i="4.59,289,1288584000"; d="scan'208";a="252935122" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Dec 2010 12:20:35 -0500 X-IronPort-AV: E=Sophos;i="4.59,289,1288584000"; d="scan'208";a="549036432" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Dec 2010 12:20:35 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 2 Dec 2010 12:20:35 -0500 From: "Worley, Dale R (Dale)" To: Christer Holmberg , Paul Kyzivat , "youssef.chadli@orange-ftgroup.com" Date: Thu, 2 Dec 2010 12:19:46 -0500 Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: AcuGucJgDasXXQisTj27OAMu8zhX2wHA82BUASHjmBs= Message-ID: References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr>, <4CE476E2.70801@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A058502C71893@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C71893@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 17:19:24 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Chri= ster Holmberg [christer.holmberg@ericsson.com] Not exactly the same case that Youssef is talking about, but every now and = then I have had discussions that it would be useful to be able to re-negoti= ate the route set (not only the local/remote targets, but also the record-r= outes) during a dialog. E.g. in Outbound cases it could be used to move ong= oing dialogs from a failed flow to another (it is not always possible to ac= hieve it by using domain names and DNS). No, I did not suggest that we start work on such functionality :) _______________________________________________ You mean that the renegotiation would be initiated by an *intermediate* pro= xy. That is extremely ugly! Dale From christer.holmberg@ericsson.com Thu Dec 2 12:35:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83CA63A69EB for ; Thu, 2 Dec 2010 12:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ajiba8SHCZdl for ; Thu, 2 Dec 2010 12:35:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D549A28C0D6 for ; Thu, 2 Dec 2010 12:35:48 -0800 (PST) X-AuditID: c1b4fb3d-b7b8cae0000016b1-73-4cf8036f31ab Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F0.13.05809.F6308FC4; Thu, 2 Dec 2010 21:37:03 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 2 Dec 2010 21:37:03 +0100 From: Christer Holmberg To: "Worley, Dale R (Dale)" , Paul Kyzivat , "youssef.chadli@orange-ftgroup.com" Date: Thu, 2 Dec 2010 21:33:46 +0100 Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: AcuGucJgDasXXQisTj27OAMu8zhX2wHA82BUASHjmBsABsZ9LQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C718D9@ESESSCMS0356.eemea.ericsson.se> References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr>, <4CE476E2.70801@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A058502C71893@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 20:35:52 -0000 Hi, >>Not exactly the same case that Youssef is talking about, but every now an= d then I have had discussions that it would be useful to be able to re-nego= tiate the route set (not only the local/remote targets, but also the record= -routes) during a dialog. E.g. in Outbound cases it could be used to move o= ngoing dialogs=20 >>from a failed flow to another (it is not always possible to achieve it by= using domain names and DNS). >> >>No, I did not suggest that we start work on such functionality :) > >You mean that the renegotiation would be initiated by an *intermediate* pr= oxy. That is extremely ugly! I agree. I later said that it would be good to have a response code which t= he proxy could send in order to trigger a renegotiation by the UA. Regards, Christer= From david.black@emc.com Fri Dec 3 12:26:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4C628C0DC for ; Fri, 3 Dec 2010 12:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6L9-KJ55prg for ; Fri, 3 Dec 2010 12:26:55 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id AC22D3A6995 for ; Fri, 3 Dec 2010 12:26:54 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oB3KSCmO013298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Dec 2010 15:28:12 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Fri, 3 Dec 2010 15:28:05 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oB3KR1DM019578 for ; Fri, 3 Dec 2010 15:27:02 -0500 Received: from mx14a.corp.emc.com ([169.254.1.117]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Fri, 3 Dec 2010 15:27:01 -0500 From: To: Date: Fri, 3 Dec 2010 15:27:00 -0500 Thread-Topic: OPS-DIR review of draft-ietf-sipcore-sec-flows-06 Thread-Index: AcuTKDK1i/d95a1XQqSssN6UvLh23QAACSnw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D5B61CEA@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Fri, 03 Dec 2010 12:35:37 -0800 Subject: [sipcore] FW: OPS-DIR review of draft-ietf-sipcore-sec-flows-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 20:26:58 -0000 From: Black, David=20 Sent: Friday, December 03, 2010 3:25 PM To: Cullen Jennings; kumiko@cs.columbia.edu; rjsparks@estacado.net; brian@e= stacado.net; 'ops-dir@ietf.org' Cc: Black, David; Adam Roach; Paul Kyzivat Subject: OPS-DIR review of draft-ietf-sipcore-sec-flows-06 I have performed an Operations Directorate review of draft-ietf-sipcore-sec= -flows-06 Operations directorate reviews are solicited primarily to help the area dir= ectors improve their efficiency, particularly when preparing for IESG telec= hats, and allowing them to focus on documents requiring their attention and= spend less time on the trouble-free ones. Improving the documents is impo= rtant, but clearly a secondary purpose. A third purpose is to broaden the = OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to r= aise issue with a document. The reviews may, however, convince individual I= ESG members to raise concern over a particular document requiring further d= iscussion. The reviews, particularly those conducted in last call and earli= er, may also help the document editors improve their documents. -------------- Summary: This draft is basically ready for publication, but has nits that s= hould be fixed before publication. This draft is aimed at improving the productivity of SIP over TLS interoper= ability events and the interoperability of SIP over TLS implementations. A= s such, it's a positive contribution to network operations and management, = as improved interoperability reduces operational issues that would otherwis= e arise. I found a few nits and have a few suggestions: The CA certificate uses a 1024-bit RSA key, whereas the host and user certi= ficates use 2048-bit RSA keys. This results in using a 1024-bit RSA key to= vouch for the validity of 2048-bit RSA keys. While acceptable for interop= erability testing, this is not good operational security practice - I would= suggest asking a PKIX expert (e.g., Steve Kent) for appropriate language t= o warn about this. At the end of Section 2.2, the Section citation from RFC 5280 is wrong. Se= ctions 6.1 and 6.2 should be cited, instead of just Section 6.1.4. Also, t= he CRL checking in Section 6.3 of RFC 5280 should be added as a reference c= ited in the last paragraph of the security considerations section. Somewhere, probably in Section 5, a warning should be added that the certif= icate path validation algorithm is a complex algorithm for which *all* the = details matter - there are numerous ways in which failing to precisely impl= ement the algorithm as specified in Section 6 of RFC 5280 can create a secu= rity flaw, a simple example of which is the failure to check the expiration= date that is already mentioned in Section 5. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From mary.ietf.barnes@gmail.com Mon Dec 6 07:37:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A353A6832 for ; Mon, 6 Dec 2010 07:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.125 X-Spam-Level: X-Spam-Status: No, score=-103.125 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCwyLjEwmIgl for ; Mon, 6 Dec 2010 07:37:14 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 814CD3A6827 for ; Mon, 6 Dec 2010 07:37:13 -0800 (PST) Received: by yxt33 with SMTP id 33so2672206yxt.31 for ; Mon, 06 Dec 2010 07:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=8oOZ+TcnuPdPXySiMhO7f1oqzhOUjVdywtrsbSDo4+4=; b=r3sUqT2UpTwAJe5wrviQ3M0u3lJnXq0Sd4D8FZND7jxUBpSHPJKXjJCevjtL6uh+1T c1E+AXTjrgsTZ77i4QyBeioEPEmTaZGRRivhsKg4tx4wg+zTHp+Qv+waoyyuU9nbCGfw LdUB3SNFo7bPNFi09Q/AMo8k927HCTLRyxKug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ABRuWAkvJG+dgiOnFlThQTvPbP02ruSQtfVhRlokqKVhx+oW+NgdFP1ht6ZQp8DQya RKcfKW3VCRar2QzObGWnrugbEM7mCyviOxGl2/D9aUeLYiAyo9uQM+R8f8xlUk8PRuwM 9bwnZ+AEtwT/oNZXADFNQVrTW3f/8owXj9G60= MIME-Version: 1.0 Received: by 10.150.148.17 with SMTP id v17mr9856402ybd.90.1291649913597; Mon, 06 Dec 2010 07:38:33 -0800 (PST) Received: by 10.236.95.35 with HTTP; Mon, 6 Dec 2010 07:38:33 -0800 (PST) In-Reply-To: References: <4CDC04F2.3010701@cisco.com> <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> <4CED9370.5010001@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 6 Dec 2010 09:38:33 -0600 Message-ID: From: Mary Barnes To: marianne.mohali@orange-ftgroup.com Content-Type: multipart/alternative; boundary=000e0cd4053046a39d0496bfaea3 Cc: sipcore@ietf.org, dworley@avaya.com Subject: Re: [sipcore] Reason as a parameter rather than an escaped header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 15:37:15 -0000 --000e0cd4053046a39d0496bfaea3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marianne et al, I totally agree that there was some text removed from RFC 4244 that was intended to handle the internal retargeting case. I would suggest we add that back, updating the paragraph to be a little more concise as I suggeste= d earlier in the thread and add a note with regards the definition of any new Reason headers - something like the following: If the response contains any Reason header fields, then the Reason header fields MUST be captured as Reasons associated with the hi-targeted-to-uri that has been retargeted. If the SIP response does not include a Reason header field (see [RFC3326]), the SIP Response Code that triggered the retargeting MUST be included as the Reason associated with the hi-targeted-to-uri that has been retargeted. For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted. [MB: this is the original text from RFC 4244.] In the case that additional Reason headers are defined, per RFC 3326, the use of these Reason headers for the History-Info header field MUST follow the same rules as described above. Thanks, Mary. On Thu, Nov 25, 2010 at 4:33 PM, wrote= : > Hi, > > I agree that draft-mohali-sipcore-reason-extension-application could live > independently of 4244bis, except for the section "Reason in the History-I= nfo > header" that should still allow wat is proposed in draft-reason. > > Note that RFC4244 is compatible with the draft-reason proposal: As work o= n > 4244bis was in progress, we based the draft on the following text from > RFC4244: "For retargets as a result of timeouts or internal events, a Rea= son > MAY be associated with the hi-targeted-to-uri that has been retargeted." > > Unfortunately, this sentence disappeared and only the last sentence about > timeout suggests to insert a Reason for an internal process. > > If there is no objection, we could put this text back in 4244bis to keep > explicit the ability to insert the Reason header field in a H-I entry for > *internal* reasons (with a MAY). > > > Regards, > Marianne > > > -----Message d'origine----- > > De : sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] De la part de Christer Holmberg > > Envoy=E9 : jeudi 25 novembre 2010 07:48 > > =C0 : Paul Kyzivat > > Cc : Worley, Dale R (Dale); sipcore@ietf.org > > Objet : Re: [sipcore] Reason as a parameter rather than an > > escaped header > > > > > > Hi, > > > > >>I think we should ask ourselves: assuming we allowed to do what > > >>Marianne is proposing, would anything break? > > >> > > >>Does anyone really care whether a H-I entry was inserted based on a > > >>"real" or "virtual" response? Aren't people more interested in the > > >>actual reason value? > > > > > >I don't currently see a problem with permitting this (though I'm > > >interested to hear if somebody else sees an issue). > > > > > >But IMO the current text doesn't suggest to me that this is valid. > > >So if the desire is for it to be valid it would be good to have some > > >text that makes it so. > > > > I agree. We would need to add some text. > > > > Regards, > > > > Christer > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000e0cd4053046a39d0496bfaea3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marianne et al,
=A0
I totally agree that there was some text removed from RFC 4244 that wa= s intended to handle the internal retargeting case. I would suggest we add = that back, updating the paragraph to be a little more concise as I suggeste= d earlier in the thread and add a note with regards the definition of any n= ew Reason headers=A0- something like the following:
=A0
=A0 If the response contains any Reason header fields, then
=A0 th= e Reason header fields MUST be captured as Reasons
=A0 associated with = the hi-targeted-to-uri that has been
=A0 retargeted.=A0 If the SIP respo= nse does not include a Reason header field
=A0 (see [RFC3326]), the SIP =A0Response Code that triggered the retar= geting
=A0 MUST be included as the Reason associated with the hi-targeted-to-= uri
=A0 that has been=A0retargeted.=A0
=A0
=A0 For retargets as a result of timeouts or internal events, a Reason=
=A0=A0MAY be associated with the hi-targeted-to-uri that has been
= =A0=A0retargeted.=A0 [MB: this is the original text from RFC 4244.]
=A0
=A0 In the case that additional Reason headers are defined, per RFC 33= 26,
=A0 the use of these Reason headers for the History-Info header field =
=A0 MUST follow the same rules as described above.
=A0
Thanks,
Mary.

On Thu, Nov 25, 2010 at 4:33 PM, <marianne.mohal= i@orange-ftgroup.com> wrote:
Hi,

I agree that draft-mo= hali-sipcore-reason-extension-application could live independently of 4244b= is, except for the section "Reason in the History-Info header" th= at should still allow wat is proposed in draft-reason.

Note that RFC4244 is compatible with the draft-reason proposal: As work= on 4244bis was in progress, we based the draft on the following text from = RFC4244: "For retargets as a result of timeouts or internal events, a = Reason MAY be associated with the hi-targeted-to-uri that has been retarget= ed."

Unfortunately, this sentence disappeared and only the last sentence abo= ut timeout suggests to insert a Reason for an internal process.

If t= here is no objection, we could put this text back in 4244bis to keep explic= it the ability to insert the Reason header field in a H-I entry for *intern= al* reasons (with a MAY).


Regards,
Marianne

> -----Message d'origine-----> De : sipcore-bounces@ietf= .org
> [mailto:sipcor= e-bounces@ietf.org] De la part de Christer Holmberg
> Envoy=E9 : jeudi 25 novembre 2010 07:48
> =C0 : Paul Kyzivat
= > Cc : Worley, Dale R (Dale); sipcor= e@ietf.org
> Objet : Re: [sipcore] Reason as a parameter rather t= han an
> escaped header
>
>
> Hi,
>
> >>I think = we should ask ourselves: assuming we allowed to do what
> >>Mar= ianne is proposing, would anything break?
> >>
> >>= Does anyone really care whether a H-I entry was inserted based on a
> >>"real" or "virtual" response? Aren't p= eople more interested in the
> >>actual reason value?
> &= gt;
> >I don't currently see a problem with permitting this (t= hough I'm
> >interested to hear if somebody else sees an issue).
> >> >But IMO the current text doesn't suggest to me that this is = valid.
> >So if the desire is for it to be valid it would be good = to have some
> >text that makes it so.
>
> I agree. We would need to a= dd some text.
>
> Regards,
>
> Christer
>
=
> _______________________________________________
> si= pcore mailing list
> sipcore@ietf.org
> http= s://www.ietf.org/mailman/listinfo/sipcore
>
__________________= _____________________________
sipcore mailing list
sipcore@ietf.or= g
https://www.ietf.org/mailman/listinfo/sipcore

--000e0cd4053046a39d0496bfaea3-- From rjsparks@nostrum.com Mon Dec 6 10:44:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50BC3A6873; Mon, 6 Dec 2010 10:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2epL+Y7Ri3oO; Mon, 6 Dec 2010 10:44:45 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id AF8323A685E; Mon, 6 Dec 2010 10:44:44 -0800 (PST) Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB6Ik7wL034288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Dec 2010 12:46:07 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Dec 2010 12:46:07 -0600 Message-Id: <3030C310-064A-43AC-942E-902A125A0A21@nostrum.com> To: rai@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 173.71.48.4 is authenticated by a trusted mechanism) Cc: SIPCORE , sipping LIST Subject: [sipcore] Moving offeranswer forward X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 18:44:48 -0000 (Apologies for the cross-post - please reply to rai@ietf.org) All - We had a thread earlier in the year about finishing = draft-ietf-sipping-sip-offeranswer. Based on that thread and recent discussion with the authors, I am going = to take this back=20 into IETF LC as an AD sponsored individual submission for publication as = Informational to=20 get a final review of the changes that were made since its last LC. The = tracker will probably=20 make several bits of noise as its state changes.=20 Any normative changes to the specifications reflecting the discussion = captured in this document=20 can be made through other drafts. Many thanks to the editors and reviewers that have put so much effort = into this draft. Hopefully we can get it out the door soon. RjS From pkyzivat@cisco.com Mon Dec 6 17:43:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA733A68DA for ; Mon, 6 Dec 2010 17:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+SQCRe+nt5Z for ; Mon, 6 Dec 2010 17:43:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 483FE3A67EF for ; Mon, 6 Dec 2010 17:43:15 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPQf/UxAZnwM/2dsb2JhbACjOHGkB5tLhUkEhF+GD4MT X-IronPort-AV: E=Sophos;i="4.59,308,1288569600"; d="scan'208";a="189917671" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Dec 2010 01:44:39 +0000 Received: from [161.44.174.115] (dhcp-161-44-174-115.cisco.com [161.44.174.115]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oB71idXi022333 for ; Tue, 7 Dec 2010 01:44:39 GMT Message-ID: <4CFD9187.3090207@cisco.com> Date: Mon, 06 Dec 2010 20:44:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Required normative revisions to support 199 response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 01:43:17 -0000 In offline discussions, Robert, Cullen (and maybe others?) have questioned whether draft-ietf-sipcore-199-02.txt requires a normative change to RFC 3262 (100rel). We've gotten deep enough into this that it seemed proper to bring it back to the list for further discussion. The issue is that this draft, as currently written, requires that the 199 response be sent *un*reliably even if Require:100rel was specified by the UAC. It is (partially) mitigated by the introduction of a new '199' option tag. If Supported:199 is not present in the request, the 199 response can't be sent. So the draft makes the argument that there is no backward compatibility issue, making this an extension rather than a change. BUT, there is still a potential backward compatibility issue for other proxies that don't know about the 199 option. A dialog-stateful proxy upstream of the 199-sender might observe the unreliable 199 and not it to be inconsistent with the Require:100rel. In addition, I realized that this draft also extends RFC 3261, in that it for the first time introduces a case where a *proxy* may *originate* (not just forward) a response in the context of an existing (early) dialog. According to 3261 a proxy that initiates a response is actually doing so in the role of a UAS, and so must add its own to-tag, thus creating a new dialog. So, I have proposed that the specification for what goes on when sending 199 be tweaked, in a way that is trivially different from an implementation perspective but that is conceptually significant. Namely: - There should be no exception from Require:100rel. When a UAS sends a 199, if Require:100rel is in effect it MUST send the 199 reliably. - When a *proxy* *originates*a 199, it is considered to be operating as a *proxy*, not as a UAS. Hence it is not bound by Require:100rel. Rather it is bound by Proxy-Require:100rel. The proposal is to make a revision to 3262 that says 100rel MUST NOT be used in Proxy-Require. And as now the proxy MUST NOT send the 199 reliably. That ensures there won't be a PRACK that would then possibly be forwarded on to the UAS that doesn't expect it. But the proxy is *originating* the 199 response in the context of the existing (early) dialog. It must make a response that is valid in that context. (E.g. the to-tag.) This does not eliminate the impact on upstream proxies. They will still see an unreliable provisional response that might be surprising. So this still requires a revision to 3262. I really hated the idea of making a special case for the single 199 response code. So my proposal is: - in any case where a proxy is permitted to originate a provisional response within an existing dialog (early or not) it must do so unreliably. (For now the only case this applies to is 199.) - the 100rel option MUST NOT be sent (ever) in Proxy-Require. The effect of this is that UACs and proxies may see unreliable provisionals even when Require:100rel is in effect. This is a (hopefully insignificant) backward incompatibility from 3262. *** I'm requesting feedback on the above approach. *** Are you happy with it? *** Do you have a better idea? While writing this I thought of another issue that needs discussion. When the proxy is constructing the 199, to be in the context of the dialog, how should it be constructed? The following are questionable: - Contact address - Record-Route - History-Info - (did I forget any that matter?) The straightforward answer is that these should all be copied from the final response that triggered the sending of the 199. An alternative might be to copy from the response that the proxy considers to have established the early dialog. These *might* not be the same. Alternatively, perhaps the proxy should generate the 199 response without the Contact since the contact does not reflect the sender of the response. But that would be contrary to some discussions that occurred a couple of years ago (aug 2008) on the sip-implementors list, which concluded (IMO) that 3261 implies Contact is required in all provisional responses. *** Feedback on this issue also requested. Disclaimer - the following is my take on things. While this has been discussed with Christer and Robert, they have not seen this message. Thanks, Paul From christer.holmberg@ericsson.com Tue Dec 7 05:36:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D603A6954 for ; Tue, 7 Dec 2010 05:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKY36IllgUKm for ; Tue, 7 Dec 2010 05:36:22 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id ED4BA3A698C for ; Tue, 7 Dec 2010 05:36:13 -0800 (PST) X-AuditID: c1b4fb3d-b7ceeae0000031e4-45-4cfe38a28e2c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 29.F8.12772.2A83EFC4; Tue, 7 Dec 2010 14:37:38 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 7 Dec 2010 14:37:37 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Tue, 7 Dec 2010 14:37:36 +0100 Thread-Topic: Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: AcuWE+kQHPR3a668Th+74O6FYhCCTA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A058502B84084ESESSCMS0356eem_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 13:36:23 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A058502B84084ESESSCMS0356eem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the proxy-feature draft. It now contains more use-cases, for which the usage of the draft have been = discussed in 3GPP. In the examples there is also some wording about why the usage of the Conta= ct header field is not seen as appropriate. I have added some text about the "direction" of capabilities. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A058502B84084ESESSCMS0356eem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I've submitted a new version of the proxy-feature dra= ft.
 
It now contains more use-cases, for which the usage o= f the draft have been discussed in 3GPP.
 
In the examples there is also some wording about why = the usage of the Contact header field is not seen as appropriate.
 
I have added some text about the "direction"= ; of capabilities.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A058502B84084ESESSCMS0356eem_-- From rjsparks@nostrum.com Tue Dec 7 08:29:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780B53A6816; Tue, 7 Dec 2010 08:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvEO1tpTjjQm; Tue, 7 Dec 2010 08:29:49 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 27AE23A6823; Tue, 7 Dec 2010 08:29:47 -0800 (PST) Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB7GVC5F037009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 10:31:13 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Dec 2010 10:31:12 -0600 References: To: rai@ietf.org, SIPCORE Message-Id: <2DDCA6E9-81BE-469C-86B6-AAF05413ED65@nostrum.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 173.71.48.4 is authenticated by a trusted mechanism) Subject: [sipcore] Fwd: [IANA #403457] Wrong name of a registry X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 16:29:57 -0000 All - for your information: Patrik F=E4ltstr=F6m and Liman Lars-Johan identified a misnaming of a = registry that RFC3263 created. IANA will be making the suggested correction below. RjS >=20 > You have one registry named "Registry for the Session Initiation = Protocol (SIP) SRV Resource Record Services Field": >=20 > http://www.iana.org/assignments/sip-table/sip-table.xhtml >=20 > It is actually not service fields for SRV records, but for NAPTR = records. >=20 > I therefore suggest a change of the name of the registry. >=20 > OLD: >=20 > Registry for the Session Initiation Protocol (SIP) SRV Resource Record = Services Field >=20 > NEW: >=20 > Registry for the Session Initiation Protocol (SIP) NAPTR Resource = Record Services Field >=20 > Patrik From marianne.mohali@orange-ftgroup.com Tue Dec 7 11:49:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91903A67FF for ; Tue, 7 Dec 2010 11:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.958 X-Spam-Level: X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBuuEO3+y7W7 for ; Tue, 7 Dec 2010 11:49:28 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4B68D3A6891 for ; Tue, 7 Dec 2010 11:49:28 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B18FF858001; Tue, 7 Dec 2010 20:54:50 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A5D1F798007; Tue, 7 Dec 2010 20:54:50 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Dec 2010 20:50:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9648.0E180C13" Date: Tue, 7 Dec 2010 20:50:51 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuVW6b6/18kWRWiSxqvrGvHmZy9HwA0W6Ew References: <4CDC04F2.3010701@cisco.com><4CEC570D.8080700@cisco.com><7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se><4CED9370.5010001@cisco.com><7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> From: To: X-OriginalArrivalTime: 07 Dec 2010 19:50:53.0620 (UTC) FILETIME=[0E8E2740:01CB9648] Cc: sipcore@ietf.org, dworley@avaya.com Subject: Re: [sipcore] Reason as a parameter rather than an escaped header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 19:49:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB9648.0E180C13 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, =20 It's OK for me ! =20 Thanks, Marianne ________________________________ De : Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Envoy=E9 : lundi 6 d=E9cembre 2010 16:39 =C0 : MOHALI Marianne RD-CORE-ISS Cc : christer.holmberg@ericsson.com; pkyzivat@cisco.com; = dworley@avaya.com; sipcore@ietf.org Objet : Re: [sipcore] Reason as a parameter rather than an escaped = header =09 =09 Hi Marianne et al, =20 I totally agree that there was some text removed from RFC 4244 that was = intended to handle the internal retargeting case. I would suggest we add = that back, updating the paragraph to be a little more concise as I = suggested earlier in the thread and add a note with regards the = definition of any new Reason headers - something like the following: =20 If the response contains any Reason header fields, then=20 the Reason header fields MUST be captured as Reasons=20 associated with the hi-targeted-to-uri that has been retargeted. If the SIP response does not include a Reason header = field=20 (see [RFC3326]), the SIP Response Code that triggered the = retargeting=20 MUST be included as the Reason associated with the hi-targeted-to-uri = that has been retargeted. =20 =20 For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted. [MB: this is the original text from RFC 4244.] =20 In the case that additional Reason headers are defined, per RFC 3326, = the use of these Reason headers for the History-Info header field=20 MUST follow the same rules as described above.=20 =20 Thanks, Mary.=20 =09 =09 On Thu, Nov 25, 2010 at 4:33 PM, = wrote: =09 Hi, =09 I agree that draft-mohali-sipcore-reason-extension-application could = live independently of 4244bis, except for the section "Reason in the = History-Info header" that should still allow wat is proposed in = draft-reason. =09 Note that RFC4244 is compatible with the draft-reason proposal: As = work on 4244bis was in progress, we based the draft on the following = text from RFC4244: "For retargets as a result of timeouts or internal = events, a Reason MAY be associated with the hi-targeted-to-uri that has = been retargeted." =09 Unfortunately, this sentence disappeared and only the last sentence = about timeout suggests to insert a Reason for an internal process. =09 If there is no objection, we could put this text back in 4244bis to = keep explicit the ability to insert the Reason header field in a H-I = entry for *internal* reasons (with a MAY). =09 =09 Regards, Marianne =09 > -----Message d'origine----- > De : sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] De la part de Christer Holmberg > Envoy=E9 : jeudi 25 novembre 2010 07:48 > =C0 : Paul Kyzivat > Cc : Worley, Dale R (Dale); sipcore@ietf.org > Objet : Re: [sipcore] Reason as a parameter rather than an > escaped header =09 > > > Hi, > > >>I think we should ask ourselves: assuming we allowed to do what > >>Marianne is proposing, would anything break? > >> > >>Does anyone really care whether a H-I entry was inserted based on = a > >>"real" or "virtual" response? Aren't people more interested in the > >>actual reason value? > > > >I don't currently see a problem with permitting this (though I'm > >interested to hear if somebody else sees an issue). > > > >But IMO the current text doesn't suggest to me that this is valid. > >So if the desire is for it to be valid it would be good to have = some > >text that makes it so. > > I agree. We would need to add some text. > > Regards, > > Christer > =09 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ------_=_NextPart_001_01CB9648.0E180C13 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mary,
 
It's OK for me !
 
Thanks,
Marianne

De : Mary Barnes=20 [mailto:mary.ietf.barnes@gmail.com]
Envoy=E9 : lundi 6 = d=E9cembre=20 2010 16:39
=C0 : MOHALI Marianne = RD-CORE-ISS
Cc :=20 christer.holmberg@ericsson.com; pkyzivat@cisco.com; dworley@avaya.com; = sipcore@ietf.org
Objet : Re: [sipcore] Reason as a = parameter=20 rather than an escaped header

Hi Marianne et al,
 
I totally agree that there was some text removed from RFC 4244 = that was=20 intended to handle the internal retargeting case. I would suggest we = add that=20 back, updating the paragraph to be a little more concise as I = suggested=20 earlier in the thread and add a note with regards the definition of = any new=20 Reason headers - something like the following:
 
  If the response contains any Reason header fields, then =
 =20 the Reason header fields MUST be captured as Reasons
  = associated=20 with the hi-targeted-to-uri that has been
  retargeted.  = If the=20 SIP response does not include a Reason header field
  (see [RFC3326]), the SIP  Response Code that = triggered the=20 retargeting
  MUST be included as the Reason associated with the=20 hi-targeted-to-uri
  that has been retargeted. 
 
  For retargets as a result of timeouts or internal events, = a=20 Reason
  MAY be associated with the hi-targeted-to-uri = that has=20 been
  retargeted.  [MB: this is the original text = from RFC=20 4244.]
 
  In the case that additional Reason headers are defined, = per RFC=20 3326,
  the use of these Reason headers for the History-Info = header field=20
  MUST follow the same rules as described above.
 
Thanks,
Mary.

On Thu, Nov 25, 2010 at 4:33 PM, <marianne.mohali@orange= -ftgroup.com>=20 wrote:
Hi,

I=20 agree that draft-mohali-sipcore-reason-extension-application could = live=20 independently of 4244bis, except for the section "Reason in the = History-Info=20 header" that should still allow wat is proposed in = draft-reason.

Note=20 that RFC4244 is compatible with the draft-reason proposal: As work = on=20 4244bis was in progress, we based the draft on the following text = from=20 RFC4244: "For retargets as a result of timeouts or internal events, = a Reason=20 MAY be associated with the hi-targeted-to-uri that has been=20 retargeted."

Unfortunately, this sentence disappeared and = only the=20 last sentence about timeout suggests to insert a Reason for an = internal=20 process.

If there is no objection, we could put this text = back in=20 4244bis to keep explicit the ability to insert the Reason header = field in a=20 H-I entry for *internal* reasons (with a=20 MAY).


Regards,
Marianne

> -----Message=20 d'origine-----
> De : sipcore-bounces@ietf.org
= >=20 [mailto:sipcore-bounces@ietf.org] = De la=20 part de Christer Holmberg
> Envoy=E9 : jeudi 25 novembre 2010=20 07:48
> =C0 : Paul Kyzivat
> Cc : Worley, Dale R (Dale); = sipcore@ietf.org
> Objet = : Re:=20 [sipcore] Reason as a parameter rather than an
> escaped = header
>
>
> Hi,
>
> >>I = think we=20 should ask ourselves: assuming we allowed to do what
>=20 >>Marianne is proposing, would anything break?
>=20 >>
> >>Does anyone really care whether a H-I entry = was=20 inserted based on a
> >>"real" or "virtual" response? = Aren't=20 people more interested in the
> >>actual reason = value?
>=20 >
> >I don't currently see a problem with permitting = this=20 (though I'm
> >interested to hear if somebody else sees an=20 issue).
> >
> >But IMO the current text doesn't = suggest to=20 me that this is valid.
> >So if the desire is for it to be = valid it=20 would be good to have some
> >text that makes it=20 so.
>
> I agree. We would need to add some = text.
>
>=20 Regards,
>
> Christer
>
>=20 _______________________________________________
> sipcore = mailing=20 list
> sipcore@ietf.org
>=20 https://www.ietf.org/mailman/listinfo/sipcore
>=
_______________________________________________
sipcore=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------_=_NextPart_001_01CB9648.0E180C13-- From christer.holmberg@ericsson.com Tue Dec 7 12:16:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D0728C0EE for ; Tue, 7 Dec 2010 12:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxev2IwughiZ for ; Tue, 7 Dec 2010 12:16:46 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DF07828C0ED for ; Tue, 7 Dec 2010 12:16:45 -0800 (PST) X-AuditID: c1b4fb39-b7bd2ae000001d22-da-4cfe96826ceb Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A4.41.07458.2869EFC4; Tue, 7 Dec 2010 21:18:10 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 7 Dec 2010 21:18:10 +0100 From: Christer Holmberg To: Paul Kyzivat , SIPCORE Date: Tue, 7 Dec 2010 21:18:09 +0100 Thread-Topic: [sipcore] Required normative revisions to support 199 response Thread-Index: AcuVsFP3DYAm/1VWSUaLuAtw0x4AbQAlpvDV Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se> References: <4CFD9187.3090207@cisco.com> In-Reply-To: <4CFD9187.3090207@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Required normative revisions to support 199 response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 20:16:47 -0000 Hi, >In offline discussions, Robert, Cullen (and maybe others?) have >questioned whether draft-ietf-sipcore-199-02.txt requires a normative >change to RFC 3262 (100rel). We've gotten deep enough into this that it >seemed proper to bring it back to the list for further discussion. > >The issue is that this draft, as currently written, requires that the >199 response be sent *un*reliably even if Require:100rel was specified >by the UAC. It is (partially) mitigated by the introduction of a new >'199' option tag. If Supported:199 is not present in the request, the >199 response can't be sent. So the draft makes the argument that there >is no backward compatibility issue, making this an extension rather than >a change. > >BUT, there is still a potential backward compatibility issue for other >proxies that don't know about the 199 option. A dialog-stateful proxy >upstream of the 199-sender might observe the unreliable 199 and not it >to be inconsistent with the Require:100rel. > >In addition, I realized that this draft also extends RFC 3261, in that >it for the first time introduces a case where a *proxy* may *originate* >(not just forward) a response in the context of an existing (early) >dialog. According to 3261 a proxy that initiates a response is actually >doing so in the role of a UAS, and so must add its own to-tag, thus >creating a new dialog. > >So, I have proposed that the specification for what goes on when sending >199 be tweaked, in a way that is trivially different from an >implementation perspective but that is conceptually significant. Namely: > >- There should be no exception from Require:100rel. When a UAS sends > a 199, if Require:100rel is in effect it MUST send the 199 reliably. I know that people (including me) wanted to allow a UAS to always send 199 = unreliably. However, I can live with Paul's suggestion (partly because I don't think Re= quire:100rel is very often used in real deployments)., >- When a *proxy* *originates*a 199, it is considered to be operating > as a *proxy*, not as a UAS. Hence it is not bound by Require:100rel. > Rather it is bound by Proxy-Require:100rel. The proposal is to > make a revision to 3262 that says 100rel MUST NOT be used in > Proxy-Require. And as now the proxy MUST NOT send the 199 reliably. > That ensures there won't be a PRACK that would then possibly be > forwarded on to the UAS that doesn't expect it. > > But the proxy is *originating* the 199 response in the context of the > existing (early) dialog. It must make a response that is valid in that > context. (E.g. the to-tag.) > >This does not eliminate the impact on upstream proxies. They will still >see an unreliable provisional response that might be surprising. So this >still requires a revision to 3262. I really hated the idea of making a >special case for the single 199 response code. So my proposal is: > >- in any case where a proxy is permitted to originate a provisional > response within an existing dialog (early or not) it must do so > unreliably. (For now the only case this applies to is 199.) I had a look at 3262, and the follwoing statement could be added to section= 4 (UAC behavior) of RFC 3262: "The UAC MUST, even if it has required provisional responses to be sent rel= iably, be prepared to receive unreliably sent provisional response, as such responses might have been sent by SIP pr= oxies." >- the 100rel option MUST NOT be sent (ever) in Proxy-Require. I had a look at 3262, and one could argue that the usage of Proxy-Require i= sn't defined in the first place. But, if we want to be explicit, the following statement could be added to s= ection 4 (UAC behavior) of RFC 3262: "A UAC MUST NOT insert a Proxy-Require header field with the option tag 100= rel into the request." >The effect of this is that UACs and proxies may see unreliable >provisionals even when Require:100rel is in effect. This is a (hopefully >insignificant) backward incompatibility from 3262. > >*** I'm requesting feedback on the above approach. >*** Are you happy with it? >*** Do you have a better idea? I am ok with the approach. ----- >While writing this I thought of another issue that needs discussion. >When the proxy is constructing the 199, to be in the context of the >dialog, how should it be constructed? The following are questionable: > >- Contact address >- Record-Route >- History-Info >- (did I forget any that matter?) > >The straightforward answer is that these should all be copied from the >final response that triggered the sending of the 199. An alternative >might be to copy from the response that the proxy considers to have >established the early dialog. These *might* not be the same. > >Alternatively, perhaps the proxy should generate the 199 response >without the Contact since the contact does not reflect the sender of the >response. But that would be contrary to some discussions that occurred a >couple of years ago (aug 2008) on the sip-implementors list, which >concluded (IMO) that 3261 implies Contact is required in all provisional >responses. I think this has been discussed before, and as far as I remember none of th= e header fields above are required to be present in a provisional response = - unless the response is used to create a dialog, which is not the case wit= h 199. So, unless I'm wrong, I would not like to re-open that discussion, because = it is not part of what was supposed to be be brought to the list for discus= sion. (From a debugging perspective, I actually think it could be good if the res= ponse from the proxy does not contain the header fields, which gives a hint= that the response might have been generated by a proxy). Regards, Christer= From pkyzivat@cisco.com Tue Dec 7 15:18:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69FA3A69B1 for ; Tue, 7 Dec 2010 15:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmwC8rPaiRPm for ; Tue, 7 Dec 2010 15:18:18 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 446783A67FF for ; Tue, 7 Dec 2010 15:18:18 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHdP/kxAZnwM/2dsb2JhbACjSnGmWJtPhUkEhGKGD4MT X-IronPort-AV: E=Sophos;i="4.59,313,1288569600"; d="scan'208";a="190146314" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2010 23:19:44 +0000 Received: from [161.44.174.115] (dhcp-161-44-174-115.cisco.com [161.44.174.115]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oB7NJilv001996; Tue, 7 Dec 2010 23:19:44 GMT Message-ID: <4CFEC10F.5000700@cisco.com> Date: Tue, 07 Dec 2010 18:19:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Christer Holmberg References: <4CFD9187.3090207@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Required normative revisions to support 199 response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 23:18:20 -0000 inline On 12/7/2010 3:18 PM, Christer Holmberg wrote: > Hi, > >> In offline discussions, Robert, Cullen (and maybe others?) have >> questioned whether draft-ietf-sipcore-199-02.txt requires a normative >> change to RFC 3262 (100rel). We've gotten deep enough into this that it >> seemed proper to bring it back to the list for further discussion. >> >> The issue is that this draft, as currently written, requires that the >> 199 response be sent *un*reliably even if Require:100rel was specified >> by the UAC. It is (partially) mitigated by the introduction of a new >> '199' option tag. If Supported:199 is not present in the request, the >> 199 response can't be sent. So the draft makes the argument that there >> is no backward compatibility issue, making this an extension rather than >> a change. >> >> BUT, there is still a potential backward compatibility issue for other >> proxies that don't know about the 199 option. A dialog-stateful proxy >> upstream of the 199-sender might observe the unreliable 199 and not it >> to be inconsistent with the Require:100rel. >> >> In addition, I realized that this draft also extends RFC 3261, in that >> it for the first time introduces a case where a *proxy* may *originate* >> (not just forward) a response in the context of an existing (early) >> dialog. According to 3261 a proxy that initiates a response is actually >> doing so in the role of a UAS, and so must add its own to-tag, thus >> creating a new dialog. >> >> So, I have proposed that the specification for what goes on when sending >> 199 be tweaked, in a way that is trivially different from an >> implementation perspective but that is conceptually significant. Namely: >> >> - There should be no exception from Require:100rel. When a UAS sends >> a 199, if Require:100rel is in effect it MUST send the 199 reliably. > > I know that people (including me) wanted to allow a UAS to always send 199 unreliably. > > However, I can live with Paul's suggestion (partly because I don't think Require:100rel is very often used in real deployments)., I raise this because I am not happy with carving out response-code specific exceptions to 100rel. And I don't find the efficiency argument compelling in this case. >> - When a *proxy* *originates*a 199, it is considered to be operating >> as a *proxy*, not as a UAS. Hence it is not bound by Require:100rel. >> Rather it is bound by Proxy-Require:100rel. The proposal is to >> make a revision to 3262 that says 100rel MUST NOT be used in >> Proxy-Require. And as now the proxy MUST NOT send the 199 reliably. >> That ensures there won't be a PRACK that would then possibly be >> forwarded on to the UAS that doesn't expect it. >> >> But the proxy is *originating* the 199 response in the context of the >> existing (early) dialog. It must make a response that is valid in that >> context. (E.g. the to-tag.) >> >> This does not eliminate the impact on upstream proxies. They will still >> see an unreliable provisional response that might be surprising. So this >> still requires a revision to 3262. I really hated the idea of making a >> special case for the single 199 response code. So my proposal is: >> >> - in any case where a proxy is permitted to originate a provisional >> response within an existing dialog (early or not) it must do so >> unreliably. (For now the only case this applies to is 199.) > > I had a look at 3262, and the follwoing statement could be added to section 4 (UAC behavior) of RFC 3262: > > "The UAC MUST, even if it has required provisional responses to be sent reliably, be prepared to receive unreliably > sent provisional response, as such responses might have been sent by SIP proxies." I think I am ok with that, though currently only 199 gives proxies dispensation to send a provisional response that wasn't originated by a UAS. >> - the 100rel option MUST NOT be sent (ever) in Proxy-Require. > > I had a look at 3262, and one could argue that the usage of Proxy-Require isn't defined in the first place. > But, if we want to be explicit, the following statement could be added to section 4 (UAC behavior) of RFC 3262: > > "A UAC MUST NOT insert a Proxy-Require header field with the option tag 100rel into the request." You are right that 3262 doesn't assign any special behavior to a proxy if Proxy-Require:100rel is present. There is nothing in 3261 or 3262 that would prevent the insertion of Proxy-Require:100rel. It would require all proxies to understand it, but that understanding doesn't call for any behavior. So I guess no added language is required. >> The effect of this is that UACs and proxies may see unreliable >> provisionals even when Require:100rel is in effect. This is a (hopefully >> insignificant) backward incompatibility from 3262. >> >> *** I'm requesting feedback on the above approach. >> *** Are you happy with it? >> *** Do you have a better idea? > > I am ok with the approach. > > ----- > >> While writing this I thought of another issue that needs discussion. >> When the proxy is constructing the 199, to be in the context of the >> dialog, how should it be constructed? The following are questionable: >> >> - Contact address >> - Record-Route >> - History-Info >> - (did I forget any that matter?) >> >> The straightforward answer is that these should all be copied from the >> final response that triggered the sending of the 199. An alternative >> might be to copy from the response that the proxy considers to have >> established the early dialog. These *might* not be the same. >> >> Alternatively, perhaps the proxy should generate the 199 response >> without the Contact since the contact does not reflect the sender of the >> response. But that would be contrary to some discussions that occurred a >> couple of years ago (aug 2008) on the sip-implementors list, which >> concluded (IMO) that 3261 implies Contact is required in all provisional >> responses. > > I think this has been discussed before, and as far as I remember none of the header fields above are required to be present in a provisional response - unless the response is used to create a dialog, which is not the case with 199. The requirement, or not, to include the Contact is my major concern. You say that the response is not establishing a dialog, but that is not certain. The proxy believes the dialog to have been established, based on a previously received response. But unless that response was reliable and the PRACK returned, there is no certainty that the UAC knows the dialog to have been established. Its possible that the earlier provisional was lost, and the 199 is the first time the UAC knows there is a dialog. > So, unless I'm wrong, I would not like to re-open that discussion, because it is not part of what was supposed to be be brought to the list for discussion. Well, I think the above makes you theoretically wrong in rare cases. But also, the question of whether non-100 1xx messages must have a Contact has not, afaik, been settled. So we at least need to consider what behavior is required regarding Contact, and whether that is a normative change. Right now the 199 draft doesn't say one way or the other. > (From a debugging perspective, I actually think it could be good if the response from the proxy does not contain the header fields, which gives a hint that the response might have been generated by a proxy). Yes, it probably would be better for the Contact to be missing, since it definitely should not be used. Same for Record-Route. Thanks, Paul From christer.holmberg@ericsson.com Tue Dec 7 23:02:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5190D3A67AB for ; Tue, 7 Dec 2010 23:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh5c0Q4oQOhZ for ; Tue, 7 Dec 2010 23:01:58 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6B8F63A66B4 for ; Tue, 7 Dec 2010 23:01:58 -0800 (PST) X-AuditID: c1b4fb39-b7bd2ae000001d22-ad-4cff2dbb4815 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 63.CF.07458.BBD2FFC4; Wed, 8 Dec 2010 08:03:24 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 8 Dec 2010 08:03:23 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 8 Dec 2010 08:03:22 +0100 Thread-Topic: [sipcore] Required normative revisions to support 199 response Thread-Index: AcuWZTzF/OGd7NDtQBGttKa0VPxH0AAPVDr9 Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C7190F@ESESSCMS0356.eemea.ericsson.se> References: <4CFD9187.3090207@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se>, <4CFEC10F.5000700@cisco.com> In-Reply-To: <4CFEC10F.5000700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Required normative revisions to support 199 response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 07:02:00 -0000 Hi Paul, >>> In offline discussions, Robert, Cullen (and maybe others?) have >>> questioned whether draft-ietf-sipcore-199-02.txt requires a normative >>> change to RFC 3262 (100rel). We've gotten deep enough into this that it >>> seemed proper to bring it back to the list for further discussion. >>> >>> The issue is that this draft, as currently written, requires that the >>> 199 response be sent *un*reliably even if Require:100rel was specified >>> by the UAC. It is (partially) mitigated by the introduction of a new >>> '199' option tag. If Supported:199 is not present in the request, the >>> 199 response can't be sent. So the draft makes the argument that there >>> is no backward compatibility issue, making this an extension rather tha= n >>> a change. >>> >>> BUT, there is still a potential backward compatibility issue for other >>> proxies that don't know about the 199 option. A dialog-stateful proxy >>> upstream of the 199-sender might observe the unreliable 199 and not it >>> to be inconsistent with the Require:100rel. >>> >>> In addition, I realized that this draft also extends RFC 3261, in that >>> it for the first time introduces a case where a *proxy* may *originate* >>> (not just forward) a response in the context of an existing (early) >>> dialog. According to 3261 a proxy that initiates a response is actually >>> doing so in the role of a UAS, and so must add its own to-tag, thus >>> creating a new dialog. >>> >>> So, I have proposed that the specification for what goes on when sendin= g >>> 199 be tweaked, in a way that is trivially different from an >>> implementation perspective but that is conceptually significant. Namely= : >>> >>> - There should be no exception from Require:100rel. When a UAS sends >>> a 199, if Require:100rel is in effect it MUST send the 199 reliably. >> >>I know that people (including me) wanted to allow a UAS to always send 19= 9 unreliably. >> >>However, I can live with Paul's suggestion (partly because I don't think = Require:100rel is very often used in real deployments)., > >I raise this because I am not happy with carving out response-code specifi= c exceptions to 100rel. > >And I don't find the efficiency argument compelling in this case. So, propose to modify the text accordingly: The following paragraph in section 5: "When a 199 response is sent by a UAS, since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably even if the 100rel option tag [RFC3262] is present in the Require header of the associated request." ...will be modified into: "When a 199 response is sent by a UAS, since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably, unless the 100rel option tag [RFC3262] is present in the Require header of the associated request." The following paragraph in section 9: "When a 199 Early Dialog Terminated provisional response is sent by a UAS, since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably even if the 100rel option tag [RFC3262] is present in the Require header of the associated request." ...will be modified into: "When a 199 Early Dialog Terminated provisional response is sent by a UAS, since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably, unless the 100rel option tag [RFC3262] is present in the Require header of the associated request." (even if/, unless"/s) ---- >>> - When a *proxy* *originates*a 199, it is considered to be operating >>> as a *proxy*, not as a UAS. Hence it is not bound by Require:100rel. >>> Rather it is bound by Proxy-Require:100rel. The proposal is to >>> make a revision to 3262 that says 100rel MUST NOT be used in >>> Proxy-Require. And as now the proxy MUST NOT send the 199 reliably. >>> That ensures there won't be a PRACK that would then possibly be >>> forwarded on to the UAS that doesn't expect it. >>> >>> But the proxy is *originating* the 199 response in the context of th= e >>> existing (early) dialog. It must make a response that is valid in th= at >>> context. (E.g. the to-tag.) >>> >>> This does not eliminate the impact on upstream proxies. They will still >>> see an unreliable provisional response that might be surprising. So thi= s >>> still requires a revision to 3262. I really hated the idea of making a >>> special case for the single 199 response code. So my proposal is: >>> >>> - in any case where a proxy is permitted to originate a provisional >>> response within an existing dialog (early or not) it must do so >>> unreliably. (For now the only case this applies to is 199.) >> >>I had a look at 3262, and the follwoing statement could be added to secti= on 4 (UAC behavior) of RFC 3262: >> >>"The UAC MUST, even if it has required provisional responses to be sent r= eliably, be prepared to receive unreliably >>sent provisional response, as such responses might have been sent by SIP = proxies." > >I think I am ok with that, though currently only 199 gives proxies dispens= ation to send a provisional response that wasn't originated by a UAS. So, first I suggest adding the following text to section 1 (Introduction): "In addition, this specification updates RFC 3262 [reference], by mandating= a UAC to be prepared to receive unreliably sent provisional responses even if it has required provisional responses to be sent reliably." Then, the question is then how to document the normative change. Do I inclu= de the whole new section 4 in the draft, or do I only say that the statemen= t above is added to section 4 (see below)? "X. Update the RFC 3262 The following statement is added to section 4 of RFC 3262[reference]: The UAC MUST, even if it has required provisional responses to be sent reli= ably, be prepared to receive unreliably sent provisional response, as such responses might have been sent by SIP pr= oxies." ---- >>> - the 100rel option MUST NOT be sent (ever) in Proxy-Require. >> >> I had a look at 3262, and one could argue that the usage of Proxy-Requir= e isn't defined in the first place. > >> But, if we want to be explicit, the following statement could be added t= o section 4 (UAC behavior) of RFC 3262: >> >> "A UAC MUST NOT insert a Proxy-Require header field with the option tag = 100rel into the request." > >You are right that 3262 doesn't assign any special behavior to a proxy >if Proxy-Require:100rel is present. There is nothing in 3261 or 3262 >that would prevent the insertion of Proxy-Require:100rel. It would >require all proxies to understand it, but that understanding doesn't >call for any behavior. So I guess no added language is required. Ok. (I also think that an INVITE with P-R:100rel in most cases would be rejecte= d) ---- >>> While writing this I thought of another issue that needs discussion. >>> When the proxy is constructing the 199, to be in the context of the >>> dialog, how should it be constructed? The following are questionable: >>> >>> - Contact address >>> - Record-Route >>> - History-Info >>> - (did I forget any that matter?) >>> >>> The straightforward answer is that these should all be copied from the >>> final response that triggered the sending of the 199. An alternative >>> might be to copy from the response that the proxy considers to have >>> established the early dialog. These *might* not be the same. >>> >>> Alternatively, perhaps the proxy should generate the 199 response >>> without the Contact since the contact does not reflect the sender of th= e >>> response. But that would be contrary to some discussions that occurred = a >>> couple of years ago (aug 2008) on the sip-implementors list, which >>> concluded (IMO) that 3261 implies Contact is required in all provisiona= l >>> responses. >> >>I think this has been discussed before, and as far as I remember none of = the header fields above are required to be present in a provisional respons= e - unless the response is used to create a dialog, which is not the case w= ith 199. > >The requirement, or not, to include the Contact is my major concern. >You say that the response is not establishing a dialog, but that is not >certain. The proxy believes the dialog to have been established, based >on a previously received response. But unless that response was reliable >and the PRACK returned, there is no certainty that the UAC knows the >dialog to have been established. Its possible that the earlier >provisional was lost, and the 199 is the first time the UAC knows there >is a dialog. > >>So, unless I'm wrong, I would not like to re-open that discussion, becaus= e it is not part of what was supposed to be be brought to the list for disc= ussion. > >Well, I think the above makes you theoretically wrong in rare cases. >But also, the question of whether non-100 1xx messages must have a >Contact has not, afaik, been settled. > >So we at least need to consider what behavior is required regarding >Contact, and whether that is a normative change. Right now the 199 draft >doesn't say one way or the other. We need to separate between a 199 sent by a UAS and a 199 sent by a proxy. When a UAS sends a 199, we can say that it must be generated according to 3= 261, 3262 etc. So, whatever header fields are required in a provisional res= ponse will be included in the 199. When a proxy sends a 199, it will always be triggered by a final response. = So, the race condition you mention would only take place when the dialog-es= tablishment provisional response from the UAS doesn't reach the UAC before = the 199, triggered by the final response from the UAC, does. >>(From a debugging perspective, I actually think it could be good if the r= esponse from the proxy does not contain the header fields, which gives a hi= nt that the response might have been generated by a proxy). > >Yes, it probably would be better for the Contact to be missing, since it d= efinitely should not be used. Same for Record-Route. Would you like me to add some text, e.g. something like: "When a proxy send a 199 response, it SHALL NOT insert a Contact header fie= ld or a Record-Route header field to the response." Regards, Christer= From samirs.lists@gmail.com Wed Dec 8 00:24:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A36F3A6920 for ; Wed, 8 Dec 2010 00:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC5EWYBBDLIV for ; Wed, 8 Dec 2010 00:24:09 -0800 (PST) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by core3.amsl.com (Postfix) with ESMTP id 4D1FF3A6894 for ; Wed, 8 Dec 2010 00:24:08 -0800 (PST) Received: by iwn39 with SMTP id 39so1306219iwn.27 for ; Wed, 08 Dec 2010 00:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=wTGnNczuiX81Yad6BsEVtv3NNrPZQW4KALEPF46N03g=; b=sUGrxWMd/l9u8aG1y4xKLuRs29UoH2NvMluoaAKKDI77gReFpGvfJRh2mBpiwpft6m ovv4sBkHH+JnoMVWPWG7omZZQ3bvX7fwTMMyqJRqY3I04eEOL9whMa5zvDS8mdhE8O+n McGTOCn6XqILKH4v6LAvOmoczzZN4lu5x4woY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ie4RYM4Bxebdutdw1GuPJaRtlStAxhxpCGR83ezJOe1T0QLoRne8er/hFud7Xjhieq v4sv7eoHPfmlSY/77AC/Xp3ZbEO2TZrcbmnLnKYORgkeQMOOEjIsycMHGUTJFMWSmVGX c6thFG7m0OefA1mRDZrk4sTPT9MVz+D0VjWas= MIME-Version: 1.0 Received: by 10.231.17.195 with SMTP id t3mr8778030iba.174.1291796732568; Wed, 08 Dec 2010 00:25:32 -0800 (PST) Received: by 10.231.178.82 with HTTP; Wed, 8 Dec 2010 00:25:32 -0800 (PST) Date: Wed, 8 Dec 2010 00:25:32 -0800 Message-ID: From: Samir Srivastava To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=0003255758de5de7690496e1dd50 Subject: [sipcore] Security Issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 08:24:12 -0000 --0003255758de5de7690496e1dd50 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am getting active after a long pause. Trying to figure out the details. I posted earlier on the SIP Implementors regarding the 1) security for other URI such as IM, PRES, TEL 2) feature control such as presence information sent over the secure channel is distributed over the unsecure channel. 3) Alongwith other issues, which I was pointing earlier on the list. Does anybody has answer to 1) and 2) or not or what is the plan? Paul, Dale other folks active here and active there too. I was expecting it might have resolved either way to know the result. Thx Samir Srivastava --0003255758de5de7690496e1dd50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
=A0 I am getting active after a long pause. Trying to figure out the d= etails.
=A0
=A0 I posted earlier on the SIP Implementors regarding the
=A0
=A0 1)=A0 security for other URI such as IM, PRES, TEL
=A0=A02)=A0 feature=A0control such as presence information sent over t= he secure channel is distributed over the unsecure channel.
=A0 3)=A0 Alongwith other issues, which I was pointing earlier on the = list.
=A0
=A0 Does anybody has answer to 1) and 2) or not or what is the plan?
=A0 Paul, Dale other folks active here and active there too. I was exp= ecting it might have resolved either way to know the result.
=A0
Thx
Samir Srivastava
--0003255758de5de7690496e1dd50-- From keith.drage@alcatel-lucent.com Wed Dec 8 05:31:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDD33A6947 for ; Wed, 8 Dec 2010 05:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.574 X-Spam-Level: X-Spam-Status: No, score=-105.574 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 888c0XMyaPYD for ; Wed, 8 Dec 2010 05:31:46 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 55A533A693E for ; Wed, 8 Dec 2010 05:31:39 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oB8DWFCa025187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Dec 2010 14:33:02 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 8 Dec 2010 14:32:55 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Paul Kyzivat , SIPCORE Date: Wed, 8 Dec 2010 14:32:54 +0100 Thread-Topic: [sipcore] Required normative revisions to support 199 response Thread-Index: AcuVsFP3DYAm/1VWSUaLuAtw0x4AbQAlpvDVACO+SPA= Message-ID: References: <4CFD9187.3090207@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [sipcore] Required normative revisions to support 199 response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 13:31:49 -0000 > "The UAC MUST, even if it has required provisional responses=20 > to be sent reliably, be prepared to receive unreliably sent=20 > provisional response, as such responses might have been sent=20 > by SIP proxies." > How about:=20 "The UAC MUST support reception of all provisional responses, sent reliably= or unreliably; use of the option tag value "100rel" in a Require header fi= eld does not change this requirement." regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Tuesday, December 07, 2010 8:18 PM > To: Paul Kyzivat; SIPCORE > Subject: Re: [sipcore] Required normative revisions to=20 > support 199 response >=20 > Hi, >=20 > >In offline discussions, Robert, Cullen (and maybe others?) have=20 > >questioned whether draft-ietf-sipcore-199-02.txt requires a=20 > normative=20 > >change to RFC 3262 (100rel). We've gotten deep enough into=20 > this that it=20 > >seemed proper to bring it back to the list for further discussion. > > > >The issue is that this draft, as currently written, requires that the > >199 response be sent *un*reliably even if Require:100rel was=20 > specified=20 > >by the UAC. It is (partially) mitigated by the introduction of a new=20 > >'199' option tag. If Supported:199 is not present in the request, the > >199 response can't be sent. So the draft makes the argument=20 > that there=20 > >is no backward compatibility issue, making this an extension rather=20 > >than a change. > > > >BUT, there is still a potential backward compatibility issue=20 > for other=20 > >proxies that don't know about the 199 option. A=20 > dialog-stateful proxy=20 > >upstream of the 199-sender might observe the unreliable 199=20 > and not it=20 > >to be inconsistent with the Require:100rel. > > > >In addition, I realized that this draft also extends RFC=20 > 3261, in that=20 > >it for the first time introduces a case where a *proxy* may=20 > *originate*=20 > >(not just forward) a response in the context of an existing (early)=20 > >dialog. According to 3261 a proxy that initiates a response=20 > is actually=20 > >doing so in the role of a UAS, and so must add its own to-tag, thus=20 > >creating a new dialog. > > > >So, I have proposed that the specification for what goes on when=20 > >sending > >199 be tweaked, in a way that is trivially different from an=20 > >implementation perspective but that is conceptually=20 > significant. Namely: > > > >- There should be no exception from Require:100rel. When a UAS sends > > a 199, if Require:100rel is in effect it MUST send the=20 > 199 reliably. >=20 > I know that people (including me) wanted to allow a UAS to=20 > always send 199 unreliably. >=20 > However, I can live with Paul's suggestion (partly because I=20 > don't think Require:100rel is very often used in real deployments)., >=20 > >- When a *proxy* *originates*a 199, it is considered to be operating > > as a *proxy*, not as a UAS. Hence it is not bound by=20 > Require:100rel. > > Rather it is bound by Proxy-Require:100rel. The proposal is to > > make a revision to 3262 that says 100rel MUST NOT be used in > > Proxy-Require. And as now the proxy MUST NOT send the 199=20 > reliably. > > That ensures there won't be a PRACK that would then possibly be > > forwarded on to the UAS that doesn't expect it. > > > > But the proxy is *originating* the 199 response in the=20 > context of the > > existing (early) dialog. It must make a response that is=20 > valid in that > > context. (E.g. the to-tag.) > > > >This does not eliminate the impact on upstream proxies. They=20 > will still=20 > >see an unreliable provisional response that might be surprising. So=20 > >this still requires a revision to 3262. I really hated the idea of=20 > >making a special case for the single 199 response code. So=20 > my proposal is: > > > >- in any case where a proxy is permitted to originate a provisional > > response within an existing dialog (early or not) it must do so > > unreliably. (For now the only case this applies to is 199.) >=20 > I had a look at 3262, and the follwoing statement could be=20 > added to section 4 (UAC behavior) of RFC 3262: >=20 > "The UAC MUST, even if it has required provisional responses=20 > to be sent reliably, be prepared to receive unreliably sent=20 > provisional response, as such responses might have been sent=20 > by SIP proxies." >=20 >=20 > >- the 100rel option MUST NOT be sent (ever) in Proxy-Require. >=20 > I had a look at 3262, and one could argue that the usage of=20 > Proxy-Require isn't defined in the first place. >=20 > But, if we want to be explicit, the following statement could=20 > be added to section 4 (UAC behavior) of RFC 3262: >=20 > "A UAC MUST NOT insert a Proxy-Require header field with the=20 > option tag 100rel into the request." >=20 >=20 > >The effect of this is that UACs and proxies may see unreliable=20 > >provisionals even when Require:100rel is in effect. This is a=20 > >(hopefully > >insignificant) backward incompatibility from 3262. > > > >*** I'm requesting feedback on the above approach. > >*** Are you happy with it? > >*** Do you have a better idea? >=20 > I am ok with the approach. >=20 > ----- >=20 > >While writing this I thought of another issue that needs discussion. > >When the proxy is constructing the 199, to be in the context of the=20 > >dialog, how should it be constructed? The following are questionable: > > > >- Contact address > >- Record-Route > >- History-Info > >- (did I forget any that matter?) > > > >The straightforward answer is that these should all be=20 > copied from the=20 > >final response that triggered the sending of the 199. An alternative=20 > >might be to copy from the response that the proxy considers to have=20 > >established the early dialog. These *might* not be the same. > > > >Alternatively, perhaps the proxy should generate the 199 response=20 > >without the Contact since the contact does not reflect the sender of=20 > >the response. But that would be contrary to some discussions that=20 > >occurred a couple of years ago (aug 2008) on the=20 > sip-implementors list,=20 > >which concluded (IMO) that 3261 implies Contact is required in all=20 > >provisional responses. >=20 > I think this has been discussed before, and as far as I=20 > remember none of the header fields above are required to be=20 > present in a provisional response - unless the response is=20 > used to create a dialog, which is not the case with 199. >=20 > So, unless I'm wrong, I would not like to re-open that=20 > discussion, because it is not part of what was supposed to be=20 > be brought to the list for discussion. >=20 > (From a debugging perspective, I actually think it could be=20 > good if the response from the proxy does not contain the=20 > header fields, which gives a hint that the response might=20 > have been generated by a proxy). >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Wed Dec 8 05:41:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0253A693D for ; Wed, 8 Dec 2010 05:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3LNP2qQBHlO for ; Wed, 8 Dec 2010 05:41:04 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 29BC03A6783 for ; Wed, 8 Dec 2010 05:41:04 -0800 (PST) X-AuditID: c1b4fb3d-b7ceeae0000031e4-5e-4cff8b470db9 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 69.C0.12772.74B8FFC4; Wed, 8 Dec 2010 14:42:31 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 8 Dec 2010 14:42:30 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Paul Kyzivat , SIPCORE Date: Wed, 8 Dec 2010 14:42:29 +0100 Thread-Topic: [sipcore] Required normative revisions to support 199 response Thread-Index: AcuVsFP3DYAm/1VWSUaLuAtw0x4AbQAlpvDVACO+SPAAAfG1IA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058503155208@ESESSCMS0356.eemea.ericsson.se> References: <4CFD9187.3090207@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Required normative revisions to support 199 response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 13:41:06 -0000 Hi Keith,=20 >>"The UAC MUST, even if it has required provisional responses to be=20 >>sent reliably, be prepared to receive unreliably sent provisional=20 >>response, as such responses might have been sent by SIP proxies." >> >=20 >How about:=20 > >"The UAC MUST support reception of all provisional responses,=20 >sent reliably or unreliably; use of the option tag value=20 >"100rel" in a Require header field does not change this requirement." Looks good to me. Regards, Christer > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: Tuesday, December 07, 2010 8:18 PM > > To: Paul Kyzivat; SIPCORE > > Subject: Re: [sipcore] Required normative revisions to support 199=20 > > response > >=20 > > Hi, > >=20 > > >In offline discussions, Robert, Cullen (and maybe others?) have=20 > > >questioned whether draft-ietf-sipcore-199-02.txt requires a > > normative > > >change to RFC 3262 (100rel). We've gotten deep enough into > > this that it > > >seemed proper to bring it back to the list for further discussion. > > > > > >The issue is that this draft, as currently written,=20 > requires that the > > >199 response be sent *un*reliably even if Require:100rel was > > specified > > >by the UAC. It is (partially) mitigated by the=20 > introduction of a new=20 > > >'199' option tag. If Supported:199 is not present in the=20 > request, the > > >199 response can't be sent. So the draft makes the argument > > that there > > >is no backward compatibility issue, making this an=20 > extension rather=20 > > >than a change. > > > > > >BUT, there is still a potential backward compatibility issue > > for other > > >proxies that don't know about the 199 option. A > > dialog-stateful proxy > > >upstream of the 199-sender might observe the unreliable 199 > > and not it > > >to be inconsistent with the Require:100rel. > > > > > >In addition, I realized that this draft also extends RFC > > 3261, in that > > >it for the first time introduces a case where a *proxy* may > > *originate* > > >(not just forward) a response in the context of an=20 > existing (early)=20 > > >dialog. According to 3261 a proxy that initiates a response > > is actually > > >doing so in the role of a UAS, and so must add its own=20 > to-tag, thus=20 > > >creating a new dialog. > > > > > >So, I have proposed that the specification for what goes on when=20 > > >sending > > >199 be tweaked, in a way that is trivially different from an=20 > > >implementation perspective but that is conceptually > > significant. Namely: > > > > > >- There should be no exception from Require:100rel. When a=20 > UAS sends > > > a 199, if Require:100rel is in effect it MUST send the > > 199 reliably. > >=20 > > I know that people (including me) wanted to allow a UAS to=20 > always send=20 > > 199 unreliably. > >=20 > > However, I can live with Paul's suggestion (partly because I don't=20 > > think Require:100rel is very often used in real deployments)., > >=20 > > >- When a *proxy* *originates*a 199, it is considered to be=20 > operating > > > as a *proxy*, not as a UAS. Hence it is not bound by > > Require:100rel. > > > Rather it is bound by Proxy-Require:100rel. The proposal is to > > > make a revision to 3262 that says 100rel MUST NOT be used in > > > Proxy-Require. And as now the proxy MUST NOT send the 199 > > reliably. > > > That ensures there won't be a PRACK that would then possibly be > > > forwarded on to the UAS that doesn't expect it. > > > > > > But the proxy is *originating* the 199 response in the > > context of the > > > existing (early) dialog. It must make a response that is > > valid in that > > > context. (E.g. the to-tag.) > > > > > >This does not eliminate the impact on upstream proxies. They > > will still > > >see an unreliable provisional response that might be=20 > surprising. So=20 > > >this still requires a revision to 3262. I really hated the idea of=20 > > >making a special case for the single 199 response code. So > > my proposal is: > > > > > >- in any case where a proxy is permitted to originate a provisional > > > response within an existing dialog (early or not) it must do so > > > unreliably. (For now the only case this applies to is 199.) > >=20 > > I had a look at 3262, and the follwoing statement could be added to=20 > > section 4 (UAC behavior) of RFC 3262: > >=20 > > "The UAC MUST, even if it has required provisional responses to be=20 > > sent reliably, be prepared to receive unreliably sent provisional=20 > > response, as such responses might have been sent by SIP proxies." > >=20 > >=20 > > >- the 100rel option MUST NOT be sent (ever) in Proxy-Require. > >=20 > > I had a look at 3262, and one could argue that the usage of=20 > > Proxy-Require isn't defined in the first place. > >=20 > > But, if we want to be explicit, the following statement could=20 > > be added to section 4 (UAC behavior) of RFC 3262: > >=20 > > "A UAC MUST NOT insert a Proxy-Require header field with the=20 > > option tag 100rel into the request." > >=20 > >=20 > > >The effect of this is that UACs and proxies may see unreliable=20 > > >provisionals even when Require:100rel is in effect. This is a=20 > > >(hopefully > > >insignificant) backward incompatibility from 3262. > > > > > >*** I'm requesting feedback on the above approach. > > >*** Are you happy with it? > > >*** Do you have a better idea? > >=20 > > I am ok with the approach. > >=20 > > ----- > >=20 > > >While writing this I thought of another issue that needs=20 > discussion. > > >When the proxy is constructing the 199, to be in the=20 > context of the=20 > > >dialog, how should it be constructed? The following are=20 > questionable: > > > > > >- Contact address > > >- Record-Route > > >- History-Info > > >- (did I forget any that matter?) > > > > > >The straightforward answer is that these should all be=20 > > copied from the=20 > > >final response that triggered the sending of the 199. An=20 > alternative=20 > > >might be to copy from the response that the proxy=20 > considers to have=20 > > >established the early dialog. These *might* not be the same. > > > > > >Alternatively, perhaps the proxy should generate the 199 response=20 > > >without the Contact since the contact does not reflect the=20 > sender of=20 > > >the response. But that would be contrary to some discussions that=20 > > >occurred a couple of years ago (aug 2008) on the=20 > > sip-implementors list,=20 > > >which concluded (IMO) that 3261 implies Contact is required in all=20 > > >provisional responses. > >=20 > > I think this has been discussed before, and as far as I=20 > > remember none of the header fields above are required to be=20 > > present in a provisional response - unless the response is=20 > > used to create a dialog, which is not the case with 199. > >=20 > > So, unless I'm wrong, I would not like to re-open that=20 > > discussion, because it is not part of what was supposed to be=20 > > be brought to the list for discussion. > >=20 > > (From a debugging perspective, I actually think it could be=20 > > good if the response from the proxy does not contain the=20 > > header fields, which gives a hint that the response might=20 > > have been generated by a proxy). > >=20 > > Regards, > >=20 > > Christer > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > = From pkyzivat@cisco.com Wed Dec 8 07:50:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA1D3A6803 for ; Wed, 8 Dec 2010 07:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cSICz9068Jy for ; Wed, 8 Dec 2010 07:50:22 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9711E3A695C for ; Wed, 8 Dec 2010 07:50:22 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAOY4/0xAZnwN/2dsb2JhbACVN44keKRim0GFSQSEYoYPgxQ X-IronPort-AV: E=Sophos;i="4.59,316,1288569600"; d="scan'208";a="190647664" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2010 15:51:50 +0000 Received: from [161.44.174.115] (dhcp-161-44-174-115.cisco.com [161.44.174.115]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB8Fpn6g001109 for ; Wed, 8 Dec 2010 15:51:50 GMT Message-ID: <4CFFA995.8000408@cisco.com> Date: Wed, 08 Dec 2010 10:51:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Security Issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 15:50:26 -0000 IIUC you posted earier to sip-implementors, not sipcore. If your issues are simply implementation concerns, it would be best to continue your discussion there. If you think your issues are deficiencies or errors in the specs, then this is probably the right place. If so, please repost here the details you are concerned with. (I seem to recall some message(s) on the subjects you mention, but not any details. I get too much mail to monitor and respond more than sporadically and opportunistically to sip-implementors.) Thanks, Paul On 12/8/2010 3:25 AM, Samir Srivastava wrote: > Hi, > I am getting active after a long pause. Trying to figure out the details. > I posted earlier on the SIP Implementors regarding the > 1) security for other URI such as IM, PRES, TEL > 2) feature control such as presence information sent over the secure > channel is distributed over the unsecure channel. > 3) Alongwith other issues, which I was pointing earlier on the list. > Does anybody has answer to 1) and 2) or not or what is the plan? > Paul, Dale other folks active here and active there too. I was > expecting it might have resolved either way to know the result. > Thx > Samir Srivastava > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From samirs.lists@gmail.com Wed Dec 8 10:13:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496143A6866 for ; Wed, 8 Dec 2010 10:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJpyo3zBjqFm for ; Wed, 8 Dec 2010 10:13:42 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 0D9213A6961 for ; Wed, 8 Dec 2010 10:13:41 -0800 (PST) Received: by ywk9 with SMTP id 9so911813ywk.31 for ; Wed, 08 Dec 2010 10:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tuXsAE7tmf5d4nUT5lIHx2sKuHHWg1ORpXRYfmkM+J0=; b=MzHFGrko5f/hQDPeIawow9XAX5Z3ZKMUPiqZO4iLOw+dTai8KdUsHjsYwMZnBojb95 DA7Tx7sPlZ1MJ7FPR4AyieTpio/LHqU9h4c5WrF7ixxmofC5jJ+HaptDhKgzvahfi2JV Jh2v4qs2HSj4RPXguntAToTaBPQUjoKrI2Pmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GSMiPsuwZTxNge5Dv9IuLVWXtUbaEC63m++4RCfgw7kMrIX7ztctm+EwG8QAAtfDxY lY5TCgK4vj611Nzq1IKJE1zLxxPeVOlTla8fNAmn13A/shjvbnCokqZFd5eoFh7d1z4g NK0Di1HxKze9ZwZOPx/WQ5YplmODORQAgrDSY= MIME-Version: 1.0 Received: by 10.231.144.70 with SMTP id y6mr9419969ibu.99.1291832109055; Wed, 08 Dec 2010 10:15:09 -0800 (PST) Received: by 10.231.178.82 with HTTP; Wed, 8 Dec 2010 10:15:09 -0800 (PST) In-Reply-To: <4CFFA995.8000408@cisco.com> References: <4CFFA995.8000408@cisco.com> Date: Wed, 8 Dec 2010 10:15:09 -0800 Message-ID: From: Samir Srivastava To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0016e64c2a1af840c20496ea19b0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Security Issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 18:13:43 -0000 --0016e64c2a1af840c20496ea19b0 Content-Type: text/plain; charset=ISO-8859-1 Hi, Paul, you will be getting two copies, as I didn't include sipcore in earlier email. This is with reference to ciphersuite draft long time back. When we were discussing the issues with SIPS vs Proxy-Require/ Require etc within SIP group (which I see as concluded group now). I am getting back to active within IETF SIP activities. I want to know what we had decided for the below Or these issues are still open 1) Securing messages with different URI schemes such as im:, pres:, tel: etc. 2) I see SIPS as standard now, how did we decide for feature control case, e.,g. Presence information sent over the secure channel and it is distributed over the unsecure channel to the watchers. 3) Degradation of cipher-suites if group with security advisor agreed 4) Security with other Secure Protocol. Such as double enryption due to TLS and IPSEC tunnel.between two SIP addressable end points. The answers to above will help me in deciding to bring the next version of cipher-suite draft to the community, Thx Samir On Wed, Dec 8, 2010 at 7:51 AM, Paul Kyzivat wrote: > IIUC you posted earier to sip-implementors, not sipcore. > > If your issues are simply implementation concerns, it would be best to > continue your discussion there. > > If you think your issues are deficiencies or errors in the specs, then this > is probably the right place. If so, please repost here the details you are > concerned with. > > (I seem to recall some message(s) on the subjects you mention, but not any > details. I get too much mail to monitor and respond more than sporadically > and opportunistically to sip-implementors.) > > Thanks, > Paul > > > On 12/8/2010 3:25 AM, Samir Srivastava wrote: > >> Hi, >> I am getting active after a long pause. Trying to figure out the >> details. >> I posted earlier on the SIP Implementors regarding the >> 1) security for other URI such as IM, PRES, TEL >> 2) feature control such as presence information sent over the secure >> channel is distributed over the unsecure channel. >> 3) Alongwith other issues, which I was pointing earlier on the list. >> Does anybody has answer to 1) and 2) or not or what is the plan? >> Paul, Dale other folks active here and active there too. I was >> expecting it might have resolved either way to know the result. >> Thx >> Samir Srivastava >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0016e64c2a1af840c20496ea19b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
=A0 Paul, you=A0will be getting two copies, as I didn't include si= pcore in earlier email.

=A0 This is with reference to ciphersuite draft long time back. Wh= en we were discussing the issues with SIPS vs Proxy-Require/ Require etc wi= thin SIP group (which I see as concluded group now). I am getting back to a= ctive within IETF SIP activities.
=A0
=A0 I want to know what we had decided for the below Or these issues= are still open
=A0
1) Securing messages with different URI schemes s= uch as im:, pres:, tel: etc.
=A0
2) I see SIPS as standard now, how d= id we decide for feature control case, e.,g. Presence information sent over= the secure channel and it is distributed over the unsecure channel to the = watchers.

3) Degradation of cipher-suites if group with security advisor agreed=A0
4) Security with other Secure Protocol. Such as double enryption du= e to TLS and IPSEC tunnel.between two SIP addressable end points.
=A0 =A0 The answers to above will help me in deciding to bring the next version= of cipher-suite draft to the community,
=A0
Thx
Samir=A0

=

On Wed, Dec 8, 2010 at 7:51 AM, Paul Kyzivat <pkyzivat@cisco.com= > wrote:
IIUC you posted earier to sip-im= plementors, not sipcore.

If your issues are simply implementation co= ncerns, it would be best to continue your discussion there.

If you think your issues are deficiencies or errors in the specs, then = this is probably the right place. If so, please repost here the details you= are concerned with.

(I seem to recall some message(s) on the subjec= ts you mention, but not any details. I get too much mail to monitor and res= pond more than sporadically and opportunistically to sip-implementors.)

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul=20


On 12/8/2010 3:25 AM, Samir Srivastava wrote:
=
Hi,
=A0 I am getting active after a long pause. Trying= to figure out the details.
=A0 I posted earlier on the SIP Implementors= regarding the
=A0 1) =A0security for other URI such as IM, PRES, TEL=A0 2) =A0feature control such as presence information sent over the secur= e
channel is distributed over the unsecure channel.
=A0 3) =A0Alongwith ot= her issues, which I was pointing earlier on the list.
=A0 Does anybody h= as answer to 1) and 2) or not or what is the plan?
=A0 Paul, Dale other = folks active here and active there too. I was
expecting it might have resolved either way to know the result.
Thx
S= amir Srivastava



________________________________= _______________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
________= _______________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
--0016e64c2a1af840c20496ea19b0-- From rjsparks@nostrum.com Wed Dec 8 11:44:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E2A3A6869 for ; Wed, 8 Dec 2010 11:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.862 X-Spam-Level: X-Spam-Status: No, score=-101.862 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTBtOZcwOqos for ; Wed, 8 Dec 2010 11:44:54 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A0D623A6823 for ; Wed, 8 Dec 2010 11:44:53 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB8JkH5B067835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Dec 2010 13:46:18 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Wed, 8 Dec 2010 13:46:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <72CAC7D1-E370-4D2E-AF68-8FBFE0469641@nostrum.com> References: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585030B1833@ESESSCMS0356.eemea.ericsson.se>, <02688FBA-D5B4-403E-944E-FB9245936F36@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502C718A9@ESESSCMS0356.eemea.ericsson.se> To: Robert Sparks X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Security issue in -keep-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 19:44:56 -0000 Here's a quick attempt at the text I said I'd suggest. Please note it = contains new normative requirements. This would replace the 3rd paragraph of section 10 of -03. --- The behavior defined in Sections 4.3 and 4.4 require an element using the mechanism defined in this document to place a value in the "keep" parameter in the topmost Via header field value of a response the element sends. They do not instruct the element to place a value in a "keep" parameter of any request it forwards. In particular, SIP proxies MUST NOT place a value into the keep parameter of the topmost Via header field value of a request it receives before forwarding it. A SIP proxy implementing this specification SHOULD remove any keep parameter values in any Via header field values below the topmost one in responses it receives before forwarding them. When requests are forwarded across multiple hops, it is possible for a=20= malicious downstream element to tamper with the accrued values in the Via header field. The malicious element could place a value, or change an existing value in a "keep" parameter in any of the Via header field values, not just the topmost value. A proxy implementation that simply forwards responses by stripping the topmost Via header field value and not inspecting the resulting new topmost Via header field value risks being adversely affected by such a malicious downstream element. In particular, such a proxy may start receiving STUN requests if it blindly forwards a response with a keep parameter with a value it did not create in the topmost Via header field. To lower the chances of the malicious element's actions having adverse affects on such proxies, when an entity sends STUN keep-alives to an adjacent downstream entity and does not receive a response to those STUN messages, it MUST stop sending the keep-alive requests for the remaining duration of the dialog (if the sending of keep-alives were negotiated for a dialog) or until the sending of keep-alives is re-negotiated for the registration (if the sending keep-alives were negotiated for a registration). On Nov 29, 2010, at 2:32 PM, Robert Sparks wrote: >=20 > On Nov 29, 2010, at 2:23 PM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >>> I don't object to the direction this text is taking, but it doesn't = _prevent_ attacks. It only mitigates the damage, >and it assumes the = attacked element doesn't just break when it gets the first STUN message = on its SIP=20 >>> listening port. >>=20 >> Well, if it breaks from a single STUN mesage I think there is going = to be trouble sooner or later anyway, because nothing prevents entities = from sending STUN messages (or whatever data) to the listening port even = if keep support is not indicated. > Of course, and it might break if something sends any other protocol = (or line noise) to it as well. > But, there's a difference between "things might break if something = sends an unrequested alien message" and "we'll force the system to send = what might be an alien message as a matter of normal operation and hope = things don't break" >=20 >>=20 >> I have no idea what I could write in order to prevent the attack from = happening. >=20 > As I indicated in my earlier note, I don't think we _can_ prevent this = attack with the current tools, and I don't think > it's this document's job to make a new tool to address it. > What the document can do is capture what we understand, documenting = the risk. I'll suggest some text if someone else doesn't > beat me to it - it will be later this week at the earliest for me. >=20 > RjS >=20 >=20 >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >> On Nov 26, 2010, at 1:30 AM, Christer Holmberg wrote: >>=20 >>>=20 >>> Hi Robert, >>>=20 >>> I suggest adding the following new paragraph to the security = considerations section: >>>=20 >>> "In order to prevent attacks, when an entity sends STUN keep-alives = to an adjacent downstream entity that is not willing to receive = keep-alives (or does not support STUN), but for which willingess to = receive keep-alives has been inidicated by some other downstream entity, = if the sending entity does not receive a response to any of the STUN = keep-alive requests, it MUST stop >>> sending the keep-alive requests for the remaining duration of the = dialog (if the sending of keep-alives were negotiated for a dialog) or = until the sending of keep-alives is re-negotiated for the registration = (if the sending keep-alives were negotiated for a registration). Further = actions taken by the sending entity is outside the scope of this = specification." >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: 24. marraskuuta 2010 14:50 >>>> To: Robert Sparks; SIPCORE >>>> Subject: Re: [sipcore] Security issue in -keep-08 >>>>=20 >>>>=20 >>>> Hi Robert, >>>>=20 >>>> Thanks for reviewing the document! >>>>=20 >>>> I guess the attack you describe could also happen in >>>> Outbound, if someone inserts an "ob" parameter in the Path >>>> header of the proxy adjacent to the UA, and that proxy does >>>> not check its Path header before forwarding the response to the UA. >>>>=20 >>>> Having said that, I guess a way to protect against this >>>> attack could be to say that an entity MUST stop sending STUN >>>> messages if it doesn't receive a response to them. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>>> Sent: 23. marraskuuta 2010 22:00 >>>>> To: SIPCORE >>>>> Cc: Christer Holmberg >>>>> Subject: Security issue in -keep-08 >>>>>=20 >>>>> I believe there is a serious problem with the >>>> recommendations in the >>>>> Security Considerations section in keep-08 where it >>>> discusses having >>>>> downstream elements change the keep parameter. >>>>>=20 >>>>> Consider this scenario. A user agent implementing this >>>> specification >>>>> sends a request that goes through two proxies before it >>>> arrives at its >>>>> destination. The first proxy does not know about this >>>> specification. >>>>> The second proxy does, and chooses to attempt to maliciously = affect >>>>> the relationship between UA1 and P1 as suggested in these security >>>>> considerations. >>>>>=20 >>>>> View the following flow in a fixed-width font: >>>>>=20 >>>>> UA1 P1 P2 UA2 >>>>> | | | | >>>>> | INVITE | | | >>>>> | Via: UA;keep | INVITE | | >>>>> |------------------>| Via: P1 | | >>>>> | | Via: UA;keep | | >>>>> | |--------------->| | >>>>> | | |----->| >>>>> | | | 200 | >>>>> | | 200 |<-----| >>>>> | | Via: P1 | | >>>>> | 200 | Via: UA;keep=3D1 | | >>>>> | Via: UA;keep=3D1 |<---------------| | >>>>> |<------------------| | | >>>>> | | | | >>>>>=20 >>>>>=20 >>>>> Since P1 doesn't support this specification, it does not >>>> know to look >>>>> at "it's" Via to see if some downstream element has >>>> modified what it >>>>> would have put in the keep parameter value - the >>>> recommendation in the >>>>> current draft does not mitigate this attack at all. If the >>>> hop between >>>>> UA1 and P1 is UDP, this may result in STUN being send >>>> towards P1's SIP >>>>> listening port with P1 not expecting (or being able to deal >>>> with) it. >>>>>=20 >>>>> This is a general problem with attempting to use Via parameters to >>>>> indicate support for extensions. A similar problem exists >>>> for ;rport, >>>>> and for ;lr. However, if a downstream element abused those >>>> parameters, >>>>> signaling is guaranteed to fail. This proposed parameter has a >>>>> different property - this abuse may only result in extra >>>> traffic for >>>>> someone else. >>>>>=20 >>>>> I don't think this document is the right place to solve the = general >>>>> problem, but this discussion needs to be rewritten to be >>>> clearer about >>>>> the problem and the lack of any current way to mitigate it. >>>>>=20 >>>>> RjS >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Dec 8 12:13:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1D23A69A6 for ; Wed, 8 Dec 2010 12:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5UPJcirNEGq for ; Wed, 8 Dec 2010 12:13:33 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3A71A3A6870 for ; Wed, 8 Dec 2010 12:13:33 -0800 (PST) X-AuditID: c1b4fb3d-b7ceeae0000031e4-b0-4cffe744cc1d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AC.55.12772.447EFFC4; Wed, 8 Dec 2010 21:15:00 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 8 Dec 2010 21:15:00 +0100 From: Christer Holmberg To: 'Robert Sparks' Date: Wed, 8 Dec 2010 21:14:59 +0100 Thread-Topic: [sipcore] Security issue in -keep-08 Thread-Index: AcuXEJZKjXW2ou41Qy+5A99K62MWPQAA95gg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502B84087@ESESSCMS0356.eemea.ericsson.se> References: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585030B1833@ESESSCMS0356.eemea.ericsson.se>, <02688FBA-D5B4-403E-944E-FB9245936F36@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502C718A9@ESESSCMS0356.eemea.ericsson.se> <72CAC7D1-E370-4D2E-AF68-8FBFE0469641@nostrum.com> In-Reply-To: <72CAC7D1-E370-4D2E-AF68-8FBFE0469641@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Security issue in -keep-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 20:13:35 -0000 Hi Robert, Thanks for providing the text! I will take a detailed look at it tomorrow, but after a first read it looks= ok. Regards, Christer=20 -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: 8. joulukuuta 2010 21:46 To: Robert Sparks Cc: Christer Holmberg; SIPCORE Subject: Re: [sipcore] Security issue in -keep-08 Here's a quick attempt at the text I said I'd suggest. Please note it conta= ins new normative requirements. This would replace the 3rd paragraph of section 10 of -03. --- The behavior defined in Sections 4.3 and 4.4 require an element using the m= echanism defined in this document to place a value in the "keep" parameter = in the topmost Via header field value of a response the element sends. They= do not instruct the element to place a value in a "keep" parameter of any = request it forwards. In particular, SIP proxies MUST NOT place a value into= the keep parameter of the topmost Via header field value of a request it r= eceives before forwarding it. A SIP proxy implementing this specification S= HOULD remove any keep parameter values in any Via header field values below= the topmost one in responses it receives before forwarding them. When requests are forwarded across multiple hops, it is possible for a mali= cious downstream element to tamper with the accrued values in the Via heade= r field. The malicious element could place a value, or change an existing v= alue in a "keep" parameter in any of the Via header field values, not just = the topmost value. A proxy implementation that simply forwards responses by= stripping the topmost Via header field value and not inspecting the result= ing new topmost Via header field value risks being adversely affected by su= ch a malicious downstream element. In particular, such a proxy may start re= ceiving STUN requests if it blindly forwards a response with a keep paramet= er with a value it did not create in the topmost Via header field. To lower= the chances of the malicious element's actions having adverse affects on s= uch proxies, when an entity sends STUN keep-alives to an adjacent downstrea= m entity and does not receive a response to those STUN messages, it MUST st= op sending the keep-alive requests for the remaining duration of the dialog= (if the sending of keep-alives were negotiated for a dialog) or until the = sending of keep-alives is re-negotiated for the registration (if the sendin= g keep-alives were negotiated for a registration). On Nov 29, 2010, at 2:32 PM, Robert Sparks wrote: >=20 > On Nov 29, 2010, at 2:23 PM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >>> I don't object to the direction this text is taking, but it doesn't=20 >>> _prevent_ attacks. It only mitigates the damage, >and it assumes the at= tacked element doesn't just break when it gets the first STUN message on it= s SIP listening port. >>=20 >> Well, if it breaks from a single STUN mesage I think there is going to b= e trouble sooner or later anyway, because nothing prevents entities from se= nding STUN messages (or whatever data) to the listening port even if keep s= upport is not indicated. > Of course, and it might break if something sends any other protocol (or l= ine noise) to it as well. > But, there's a difference between "things might break if something sends = an unrequested alien message" and "we'll force the system to send what migh= t be an alien message as a matter of normal operation and hope things don't= break" >=20 >>=20 >> I have no idea what I could write in order to prevent the attack from ha= ppening. >=20 > As I indicated in my earlier note, I don't think we _can_ prevent this=20 > attack with the current tools, and I don't think it's this document's job= to make a new tool to address it. > What the document can do is capture what we understand, documenting=20 > the risk. I'll suggest some text if someone else doesn't beat me to it - = it will be later this week at the earliest for me. >=20 > RjS >=20 >=20 >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >> On Nov 26, 2010, at 1:30 AM, Christer Holmberg wrote: >>=20 >>>=20 >>> Hi Robert, >>>=20 >>> I suggest adding the following new paragraph to the security considerat= ions section: >>>=20 >>> "In order to prevent attacks, when an entity sends STUN keep-alives=20 >>> to an adjacent downstream entity that is not willing to receive keep-al= ives (or does not support STUN), but for which willingess to receive keep-a= lives has been inidicated by some other downstream entity, if the sending e= ntity does not receive a response to any of the STUN keep-alive requests, i= t MUST stop sending the keep-alive requests for the remaining duration of t= he dialog (if the sending of keep-alives were negotiated for a dialog) or u= ntil the sending of keep-alives is re-negotiated for the registration (if t= he sending keep-alives were negotiated for a registration). Further actions= taken by the sending entity is outside the scope of this specification." >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: 24. marraskuuta 2010 14:50 >>>> To: Robert Sparks; SIPCORE >>>> Subject: Re: [sipcore] Security issue in -keep-08 >>>>=20 >>>>=20 >>>> Hi Robert, >>>>=20 >>>> Thanks for reviewing the document! >>>>=20 >>>> I guess the attack you describe could also happen in Outbound, if=20 >>>> someone inserts an "ob" parameter in the Path header of the proxy=20 >>>> adjacent to the UA, and that proxy does not check its Path header=20 >>>> before forwarding the response to the UA. >>>>=20 >>>> Having said that, I guess a way to protect against this attack=20 >>>> could be to say that an entity MUST stop sending STUN messages if=20 >>>> it doesn't receive a response to them. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>>> Sent: 23. marraskuuta 2010 22:00 >>>>> To: SIPCORE >>>>> Cc: Christer Holmberg >>>>> Subject: Security issue in -keep-08 >>>>>=20 >>>>> I believe there is a serious problem with the >>>> recommendations in the >>>>> Security Considerations section in keep-08 where it >>>> discusses having >>>>> downstream elements change the keep parameter. >>>>>=20 >>>>> Consider this scenario. A user agent implementing this >>>> specification >>>>> sends a request that goes through two proxies before it >>>> arrives at its >>>>> destination. The first proxy does not know about this >>>> specification. >>>>> The second proxy does, and chooses to attempt to maliciously=20 >>>>> affect the relationship between UA1 and P1 as suggested in these=20 >>>>> security considerations. >>>>>=20 >>>>> View the following flow in a fixed-width font: >>>>>=20 >>>>> UA1 P1 P2 UA2 >>>>> | | | | >>>>> | INVITE | | | >>>>> | Via: UA;keep | INVITE | | >>>>> |------------------>| Via: P1 | | >>>>> | | Via: UA;keep | | >>>>> | |--------------->| | >>>>> | | |----->| >>>>> | | | 200 | >>>>> | | 200 |<-----| >>>>> | | Via: P1 | | >>>>> | 200 | Via: UA;keep=3D1 | | >>>>> | Via: UA;keep=3D1 |<---------------| | >>>>> |<------------------| | | >>>>> | | | | >>>>>=20 >>>>>=20 >>>>> Since P1 doesn't support this specification, it does not >>>> know to look >>>>> at "it's" Via to see if some downstream element has >>>> modified what it >>>>> would have put in the keep parameter value - the >>>> recommendation in the >>>>> current draft does not mitigate this attack at all. If the >>>> hop between >>>>> UA1 and P1 is UDP, this may result in STUN being send >>>> towards P1's SIP >>>>> listening port with P1 not expecting (or being able to deal >>>> with) it. >>>>>=20 >>>>> This is a general problem with attempting to use Via parameters to=20 >>>>> indicate support for extensions. A similar problem exists >>>> for ;rport, >>>>> and for ;lr. However, if a downstream element abused those >>>> parameters, >>>>> signaling is guaranteed to fail. This proposed parameter has a=20 >>>>> different property - this abuse may only result in extra >>>> traffic for >>>>> someone else. >>>>>=20 >>>>> I don't think this document is the right place to solve the=20 >>>>> general problem, but this discussion needs to be rewritten to be >>>> clearer about >>>>> the problem and the lack of any current way to mitigate it. >>>>>=20 >>>>> RjS >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Dec 8 22:59:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F443A6A31 for ; Wed, 8 Dec 2010 22:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcMmq55VjRNT for ; Wed, 8 Dec 2010 22:59:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CC9403A6A2E for ; Wed, 8 Dec 2010 22:58:59 -0800 (PST) X-AuditID: c1b4fb39-b7bd2ae000001d22-21-4d007e8b05b9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.C1.07458.B8E700D4; Thu, 9 Dec 2010 08:00:28 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 9 Dec 2010 08:00:27 +0100 From: Christer Holmberg To: 'Robert Sparks' Date: Thu, 9 Dec 2010 08:00:27 +0100 Thread-Topic: [sipcore] Security issue in -keep-08 Thread-Index: AcuXEJZKjXW2ou41Qy+5A99K62MWPQAA95ggABZ/6SA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850315547D@ESESSCMS0356.eemea.ericsson.se> References: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585030B1833@ESESSCMS0356.eemea.ericsson.se>, <02688FBA-D5B4-403E-944E-FB9245936F36@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502C718A9@ESESSCMS0356.eemea.ericsson.se> <72CAC7D1-E370-4D2E-AF68-8FBFE0469641@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502B84087@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502B84087@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Security issue in -keep-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 06:59:01 -0000 Hi, I am ok with the text proposed by Robert, and I intend to include it in a n= ew version of the draft. (Robert, you mentioned section 10 of -03, but I assume you meant -08?) Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 8. joulukuuta 2010 22:15 > To: 'Robert Sparks' > Cc: SIPCORE > Subject: Re: [sipcore] Security issue in -keep-08 >=20 >=20 > Hi Robert, >=20 > Thanks for providing the text! >=20 > I will take a detailed look at it tomorrow, but after a first=20 > read it looks ok. >=20 > Regards, >=20 > Christer=20 >=20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: 8. joulukuuta 2010 21:46 > To: Robert Sparks > Cc: Christer Holmberg; SIPCORE > Subject: Re: [sipcore] Security issue in -keep-08 >=20 > Here's a quick attempt at the text I said I'd suggest. Please=20 > note it contains new normative requirements. > This would replace the 3rd paragraph of section 10 of -03. >=20 > --- > The behavior defined in Sections 4.3 and 4.4 require an=20 > element using the mechanism defined in this document to place=20 > a value in the "keep" parameter in the topmost Via header=20 > field value of a response the element sends. They do not=20 > instruct the element to place a value in a "keep" parameter=20 > of any request it forwards. In particular, SIP proxies MUST=20 > NOT place a value into the keep parameter of the topmost Via=20 > header field value of a request it receives before forwarding=20 > it. A SIP proxy implementing this specification SHOULD remove=20 > any keep parameter values in any Via header field values=20 > below the topmost one in responses it receives before forwarding them. >=20 > When requests are forwarded across multiple hops, it is=20 > possible for a malicious downstream element to tamper with=20 > the accrued values in the Via header field. The malicious=20 > element could place a value, or change an existing value in a=20 > "keep" parameter in any of the Via header field values, not=20 > just the topmost value. A proxy implementation that simply=20 > forwards responses by stripping the topmost Via header field=20 > value and not inspecting the resulting new topmost Via header=20 > field value risks being adversely affected by such a=20 > malicious downstream element. In particular, such a proxy may=20 > start receiving STUN requests if it blindly forwards a=20 > response with a keep parameter with a value it did not create=20 > in the topmost Via header field. To lower the chances of the=20 > malicious element's actions having adverse affects on such=20 > proxies, when an entity sends STUN keep-alives to an adjacent=20 > downstream entity and does not receive a response to those=20 > STUN messages, it MUST stop sending the keep-alive requests=20 > for the remaining duration of the dialog (if the sending of=20 > keep-alives were negotiated for a dialog) or until the=20 > sending of keep-alives is re-negotiated for the registration=20 > (if the sending keep-alives were negotiated for a registration). >=20 > On Nov 29, 2010, at 2:32 PM, Robert Sparks wrote: >=20 > >=20 > > On Nov 29, 2010, at 2:23 PM, Christer Holmberg wrote: > >=20 > >> Hi, > >>=20 > >>> I don't object to the direction this text is taking, but=20 > it doesn't=20 > >>> _prevent_ attacks. It only mitigates the damage, >and it=20 > assumes the attacked element doesn't just break when it gets=20 > the first STUN message on its SIP listening port. > >>=20 > >> Well, if it breaks from a single STUN mesage I think there=20 > is going to be trouble sooner or later anyway, because=20 > nothing prevents entities from sending STUN messages (or=20 > whatever data) to the listening port even if keep support is=20 > not indicated. > > Of course, and it might break if something sends any other=20 > protocol (or line noise) to it as well. > > But, there's a difference between "things might break if=20 > something sends an unrequested alien message" and "we'll=20 > force the system to send what might be an alien message as a=20 > matter of normal operation and hope things don't break" > >=20 > >>=20 > >> I have no idea what I could write in order to prevent the=20 > attack from happening. > >=20 > > As I indicated in my earlier note, I don't think we _can_=20 > prevent this=20 > > attack with the current tools, and I don't think it's this=20 > document's job to make a new tool to address it. > > What the document can do is capture what we understand, documenting=20 > > the risk. I'll suggest some text if someone else doesn't=20 > beat me to it - it will be later this week at the earliest for me. > >=20 > > RjS > >=20 > >=20 > >>=20 > >> Regards, > >>=20 > >> Christer > >>=20 > >>=20 > >>=20 > >>=20 > >> On Nov 26, 2010, at 1:30 AM, Christer Holmberg wrote: > >>=20 > >>>=20 > >>> Hi Robert, > >>>=20 > >>> I suggest adding the following new paragraph to the=20 > security considerations section: > >>>=20 > >>> "In order to prevent attacks, when an entity sends STUN=20 > keep-alives=20 > >>> to an adjacent downstream entity that is not willing to=20 > receive keep-alives (or does not support STUN), but for which=20 > willingess to receive keep-alives has been inidicated by some=20 > other downstream entity, if the sending entity does not=20 > receive a response to any of the STUN keep-alive requests, it=20 > MUST stop sending the keep-alive requests for the remaining=20 > duration of the dialog (if the sending of keep-alives were=20 > negotiated for a dialog) or until the sending of keep-alives=20 > is re-negotiated for the registration (if the sending=20 > keep-alives were negotiated for a registration). Further=20 > actions taken by the sending entity is outside the scope of=20 > this specification." > >>>=20 > >>> Regards, > >>>=20 > >>> Christer > >>>=20 > >>>> -----Original Message----- > >>>> From: sipcore-bounces@ietf.org > >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > >>>> Sent: 24. marraskuuta 2010 14:50 > >>>> To: Robert Sparks; SIPCORE > >>>> Subject: Re: [sipcore] Security issue in -keep-08 > >>>>=20 > >>>>=20 > >>>> Hi Robert, > >>>>=20 > >>>> Thanks for reviewing the document! > >>>>=20 > >>>> I guess the attack you describe could also happen in=20 > Outbound, if=20 > >>>> someone inserts an "ob" parameter in the Path header of=20 > the proxy=20 > >>>> adjacent to the UA, and that proxy does not check its=20 > Path header=20 > >>>> before forwarding the response to the UA. > >>>>=20 > >>>> Having said that, I guess a way to protect against this attack=20 > >>>> could be to say that an entity MUST stop sending STUN=20 > messages if=20 > >>>> it doesn't receive a response to them. > >>>>=20 > >>>> Regards, > >>>>=20 > >>>> Christer > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >>>>> Sent: 23. marraskuuta 2010 22:00 > >>>>> To: SIPCORE > >>>>> Cc: Christer Holmberg > >>>>> Subject: Security issue in -keep-08 > >>>>>=20 > >>>>> I believe there is a serious problem with the > >>>> recommendations in the > >>>>> Security Considerations section in keep-08 where it > >>>> discusses having > >>>>> downstream elements change the keep parameter. > >>>>>=20 > >>>>> Consider this scenario. A user agent implementing this > >>>> specification > >>>>> sends a request that goes through two proxies before it > >>>> arrives at its > >>>>> destination. The first proxy does not know about this > >>>> specification. > >>>>> The second proxy does, and chooses to attempt to maliciously=20 > >>>>> affect the relationship between UA1 and P1 as suggested=20 > in these=20 > >>>>> security considerations. > >>>>>=20 > >>>>> View the following flow in a fixed-width font: > >>>>>=20 > >>>>> UA1 P1 P2 UA2 > >>>>> | | | | > >>>>> | INVITE | | | > >>>>> | Via: UA;keep | INVITE | | > >>>>> |------------------>| Via: P1 | | > >>>>> | | Via: UA;keep | | > >>>>> | |--------------->| | > >>>>> | | |----->| > >>>>> | | | 200 | > >>>>> | | 200 |<-----| > >>>>> | | Via: P1 | | > >>>>> | 200 | Via: UA;keep=3D1 | | > >>>>> | Via: UA;keep=3D1 |<---------------| | > >>>>> |<------------------| | | > >>>>> | | | | > >>>>>=20 > >>>>>=20 > >>>>> Since P1 doesn't support this specification, it does not > >>>> know to look > >>>>> at "it's" Via to see if some downstream element has > >>>> modified what it > >>>>> would have put in the keep parameter value - the > >>>> recommendation in the > >>>>> current draft does not mitigate this attack at all. If the > >>>> hop between > >>>>> UA1 and P1 is UDP, this may result in STUN being send > >>>> towards P1's SIP > >>>>> listening port with P1 not expecting (or being able to deal > >>>> with) it. > >>>>>=20 > >>>>> This is a general problem with attempting to use Via=20 > parameters to=20 > >>>>> indicate support for extensions. A similar problem exists > >>>> for ;rport, > >>>>> and for ;lr. However, if a downstream element abused those > >>>> parameters, > >>>>> signaling is guaranteed to fail. This proposed parameter has a=20 > >>>>> different property - this abuse may only result in extra > >>>> traffic for > >>>>> someone else. > >>>>>=20 > >>>>> I don't think this document is the right place to solve the=20 > >>>>> general problem, but this discussion needs to be rewritten to be > >>>> clearer about > >>>>> the problem and the lack of any current way to mitigate it. > >>>>>=20 > >>>>> RjS > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Thu Dec 9 12:07:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B22A3A6BBC for ; Thu, 9 Dec 2010 12:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIVAmDmwuXor for ; Thu, 9 Dec 2010 12:06:59 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8DC003A6993 for ; Thu, 9 Dec 2010 12:06:59 -0800 (PST) X-AuditID: c1b4fb39-b7bd2ae000001d22-a6-4d01373cdc5e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AB.5F.07458.C37310D4; Thu, 9 Dec 2010 21:08:28 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 9 Dec 2010 21:08:28 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Thu, 9 Dec 2010 21:05:22 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-09 Thread-Index: AQHLl9zXltrq8i51dES/e3NjlNxZYA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C71919@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-09 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:07:00 -0000 Hi, Based on Robert's input for the security considerations, I've submitted a n= ew version (-09) of the keep draft. The draft also contains editorial changes based on IESG comments received s= o far. I assume that we now can move the draft back to IESG. Regards, Christer= From christer.holmberg@ericsson.com Thu Dec 9 12:13:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45FE63A6BC1 for ; Thu, 9 Dec 2010 12:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW1NlQJCjhap for ; Thu, 9 Dec 2010 12:13:03 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 50EE23A6BBD for ; Thu, 9 Dec 2010 12:13:03 -0800 (PST) X-AuditID: c1b4fb39-b7bd2ae000001d22-bd-4d0138a81e28 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 08.9F.07458.8A8310D4; Thu, 9 Dec 2010 21:14:32 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 9 Dec 2010 21:14:32 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Thu, 9 Dec 2010 21:14:32 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-199-03 Thread-Index: AQHLl92wDDYpemMjkUeQDDahs2rj1w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C7191A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-199-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:13:04 -0000 Hi, Based on the discussions and input regarding the unreliably vs reliably sen= ding of 199, I've submitted a new version (-03) of the 199 draft. Note that the draft now also updates RFC 3262. The draft also contains editorial changes based on IESG comments received s= o far. I assume that we now can move the draft back to IESG. Regards, Christer From Internet-Drafts@ietf.org Thu Dec 9 12:15:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF07528C128; Thu, 9 Dec 2010 12:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qpzDZ6KmEfr; Thu, 9 Dec 2010 12:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E2D3A6BBE; Thu, 9 Dec 2010 12:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101209201502.500.54435.idtracker@localhost> Date: Thu, 09 Dec 2010 12:15:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-09.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-09.txt Pages : 18 Date : 2010-12-09 This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-keep-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-09120456.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Thu Dec 9 12:15:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC8528C10B; Thu, 9 Dec 2010 12:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQhDSdsLvvKf; Thu, 9 Dec 2010 12:15:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B76F28C110; Thu, 9 Dec 2010 12:15:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101209201503.500.49009.idtracker@localhost> Date: Thu, 09 Dec 2010 12:15:03 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-199-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sipcore-199-03.txt Pages : 15 Date : 2010-12-09 This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate towards upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. In addition, this specification updates section 4 of RFC 3262. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-199-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-09121241.I-D@ietf.org> --NextPart-- From dean.willis@softarmor.com Thu Dec 9 12:53:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F7B28C131 for ; Thu, 9 Dec 2010 12:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex2nvNh-+aNn for ; Thu, 9 Dec 2010 12:53:38 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B9EDC28C122 for ; Thu, 9 Dec 2010 12:53:38 -0800 (PST) Received: by gyd12 with SMTP id 12so1781703gyd.31 for ; Thu, 09 Dec 2010 12:55:08 -0800 (PST) Received: by 10.91.203.6 with SMTP id f6mr91460agq.30.1291928108425; Thu, 09 Dec 2010 12:55:08 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-6-220.tx.res.rr.com [66.25.6.220]) by mx.google.com with ESMTPS id c28sm1683675ana.21.2010.12.09.12.55.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Dec 2010 12:55:06 -0800 (PST) Message-Id: From: Dean Willis To: Samir Srivastava In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 9 Dec 2010 14:55:04 -0600 References: <4CFFA995.8000408@cisco.com> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] Security Issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:53:39 -0000 On Dec 8, 2010, at 12:15 PM, Samir Srivastava wrote: > Hi, > > Paul, you will be getting two copies, as I didn't include sipcore > in earlier email. > > This is with reference to ciphersuite draft long time back. When > we were discussing the issues with SIPS vs Proxy-Require/ Require > etc within SIP group (which I see as concluded group now). I am > getting back to active within IETF SIP activities. > > I want to know what we had decided for the below Or these issues > are still open > > 1) Securing messages with different URI schemes such as im:, pres:, > tel: etc. > Who cares? Nobody actually seems to be willing to use most of these URIs. They're really more like placeholders for the sake of argument than they are well-used URI schemes. There have been some arguments made for tel:, but it obviously has no security properties. > 2) I see SIPS as standard now, how did we decide for feature control > case, e.,g. Presence information sent over the secure channel and it > is distributed over the unsecure channel to the watchers. There is no such control. Much like the State Department recently learned, once their cables had been compromised, the WikiLeaks people were technically free to send them out via an unsecured channel. > 3) Degradation of cipher-suites if group with security advisor agreed > No assertion about cipher-suite are made by the URI family used. > > 4) Security with other Secure Protocol. Such as double enryption due > to TLS and IPSEC tunnel.between two SIP addressable end points. > Multiple encryption may happen, but it's transparent to the user systems. Really, all we have is that if SIPS is used as a scheme, the sender can have a warm feeling (but not certainty) that downstream proxies will use SIPS to relay the message. It's a MUST-level requirement in the spec, but nodes can break the rules without getting caught (at least in normal cases). This says nothing about the behavior of user- agents, including back-to-back user agents that act somewhat like a proxy. -- Dean From HKaplan@acmepacket.com Fri Dec 10 08:45:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17ECB3A6CC2 for ; Fri, 10 Dec 2010 08:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnpfQk8gpE+L for ; Fri, 10 Dec 2010 08:45:49 -0800 (PST) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 3359628C0F7 for ; Fri, 10 Dec 2010 08:45:36 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 10 Dec 2010 11:46:54 -0500 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 10 Dec 2010 11:46:54 -0500 From: Hadriel Kaplan To: Mary Barnes Date: Fri, 10 Dec 2010 11:46:53 -0500 Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuYidnmGLPCFE06Ri2g4olG/+Jk8w== Message-ID: <9DF7AC2B-667B-41CF-842D-1E3BC5724C71@acmepacket.com> References: <4CDC04F2.3010701@cisco.com> <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> <4CED9370.5010001@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9DF7AC2B667B41CF842D1E3BC5724C71acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] Reason as a parameter rather than an escaped header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 16:45:51 -0000 --_000_9DF7AC2B667B41CF842D1E3BC5724C71acmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, so I think there's general agreement to add additional H-I header field= s for internal retargeting. I have two questions then: 1) the text below says: "For retargets as a result of timeouts or internal = events, a Reason MAY be associated with the hi-targeted-to-uri that has bee= n retargeted." Why is this a MAY? What's the alternative? Does it mean they may do somet= hing else, like use a RFC 4458 style cause URI parameter? Does it mean the= y may associate it with a different hi-targeted-to-uri? (I assume not, but = the text isn't clear) For example, is this what you really want to say: "For retargets as a resul= t of timeouts or internal events, a Reason MUST be associated with the hi-t= argeted-to-uri that has been retargeted and encoded as an embedded Reason h= eader field in the URI, unless the reason for the retargeting is unknown." 2) What form of reason-value protocol can be used for a Reason from an inte= rnal operation? Can it be a "SIP" cause? Ultimately if this info is used = by a receiver of the H-I entries to trigger different behavior/features, it= would be really nice not to have to create a bunch more values that the re= ceiver would have to understand/support. -hadriel On Dec 6, 2010, at 10:38 AM, Mary Barnes wrote: Hi Marianne et al, I totally agree that there was some text removed from RFC 4244 that was int= ended to handle the internal retargeting case. I would suggest we add that = back, updating the paragraph to be a little more concise as I suggested ear= lier in the thread and add a note with regards the definition of any new Re= ason headers - something like the following: If the response contains any Reason header fields, then the Reason header fields MUST be captured as Reasons associated with the hi-targeted-to-uri that has been retargeted. If the SIP response does not include a Reason header field (see [RFC3326]), the SIP Response Code that triggered the retargeting MUST be included as the Reason associated with the hi-targeted-to-uri that has been retargeted. For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted. [MB: this is the original text from RFC 4244.] In the case that additional Reason headers are defined, per RFC 3326, the use of these Reason headers for the History-Info header field MUST follow the same rules as described above. Thanks, Mary. On Thu, Nov 25, 2010 at 4:33 PM, > wrote: Hi, I agree that draft-mohali-sipcore-reason-extension-application could live i= ndependently of 4244bis, except for the section "Reason in the History-Info= header" that should still allow wat is proposed in draft-reason. Note that RFC4244 is compatible with the draft-reason proposal: As work on = 4244bis was in progress, we based the draft on the following text from RFC4= 244: "For retargets as a result of timeouts or internal events, a Reason MA= Y be associated with the hi-targeted-to-uri that has been retargeted." Unfortunately, this sentence disappeared and only the last sentence about t= imeout suggests to insert a Reason for an internal process. If there is no objection, we could put this text back in 4244bis to keep ex= plicit the ability to insert the Reason header field in a H-I entry for *in= ternal* reasons (with a MAY). Regards, Marianne > -----Message d'origine----- > De : sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] De la = part de Christer Holmberg > Envoy=E9 : jeudi 25 novembre 2010 07:48 > =C0 : Paul Kyzivat > Cc : Worley, Dale R (Dale); sipcore@ietf.org > Objet : Re: [sipcore] Reason as a parameter rather than an > escaped header > > > Hi, > > >>I think we should ask ourselves: assuming we allowed to do what > >>Marianne is proposing, would anything break? > >> > >>Does anyone really care whether a H-I entry was inserted based on a > >>"real" or "virtual" response? Aren't people more interested in the > >>actual reason value? > > > >I don't currently see a problem with permitting this (though I'm > >interested to hear if somebody else sees an issue). > > > >But IMO the current text doesn't suggest to me that this is valid. > >So if the desire is for it to be valid it would be good to have some > >text that makes it so. > > I agree. We would need to add some text. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_9DF7AC2B667B41CF842D1E3BC5724C71acmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

OK, so= I think there's general agreement to add additional H-I header fields for = internal retargeting.

I have two questions then:

1) the text below says: "For retargets as a result = of timeouts or internal events, a Reason MAY be associated with the hi= -targeted-to-uri that has been retargeted."
Why is this a MA= Y?  What's the alternative?  Does it mean they may do something e= lse, like use a RFC 4458 style cause URI parameter?  Does it mean they= may associate it with a different hi-targeted-to-uri? (I assume not, but t= he text isn't clear)  

For example, is this w= hat you really want to say: "For retargets as a result of timeouts or inter= nal events, a Reason MUST be associated with the hi-targeted-to-uri that ha= s been retargeted and encoded as an embedded Reason header field in the URI= , unless the reason for the retargeting is unknown."

2) What form of reason-value protocol can be used for a Reason from an i= nternal operation?  Can it be a "SIP" cause?  Ultimately if this = info is used by a receiver of the H-I entries to trigger different behavior= /features, it would be really nice not to have to create a bunch more value= s that the receiver would have to understand/support.

<= div>-hadriel

On Dec 6, 2010, at 10:38 AM, Mary Barnes wr= ote:

Hi Marianne et al,
 
I totally agree that there was some text removed from RFC 4244 that wa= s intended to handle the internal retargeting case. I would suggest we add = that back, updating the paragraph to be a little more concise as I suggeste= d earlier in the thread and add a note with regards the definition of any n= ew Reason headers - something like the following:
 
  If the response contains any Reason header fields, then
&nb= sp; the Reason header fields MUST be captured as Reasons
  associa= ted with the hi-targeted-to-uri that has been
  retargeted.  I= f the SIP response does not include a Reason header field
  (see [RFC3326]), the SIP  Response Code that triggered the= retargeting
  MUST be included as the Reason associated with the hi-targeted-= to-uri
  that has been retargeted. 
 
  For retargets as a result of timeouts or internal events, a Rea= son
  MAY be associated with the hi-targeted-to-uri that has b= een
  retargeted.  [MB: this is the original text from RF= C 4244.]
 
  In the case that additional Reason headers are defined, per RFC= 3326,
  the use of these Reason headers for the History-Info header fie= ld
  MUST follow the same rules as described above.
 
Thanks,
Mary.

On Thu, Nov 25, 2010 at 4:33 PM, <marianne.mohal= i@orange-ftgroup.com> wrote:
Hi,

I agree that draft-mo= hali-sipcore-reason-extension-application could live independently of 4244b= is, except for the section "Reason in the History-Info header" that should = still allow wat is proposed in draft-reason.

Note that RFC4244 is compatible with the draft-reason proposal: As work= on 4244bis was in progress, we based the draft on the following text from = RFC4244: "For retargets as a result of timeouts or internal events, a Reaso= n MAY be associated with the hi-targeted-to-uri that has been retargeted."<= br>
Unfortunately, this sentence disappeared and only the last sentence abo= ut timeout suggests to insert a Reason for an internal process.

If t= here is no objection, we could put this text back in 4244bis to keep explic= it the ability to insert the Reason header field in a H-I entry for *intern= al* reasons (with a MAY).


Regards,
Marianne

> -----Message d'origine-----
>= ; De : sipcore-bounces@ietf.org=
> [mailto:sipcore-bo= unces@ietf.org] De la part de Christer Holmberg
> Envoy=E9 : jeudi 25 novembre 2010 07:48
> =C0 : Paul Kyzivat
= > Cc : Worley, Dale R (Dale); sipcor= e@ietf.org
> Objet : Re: [sipcore] Reason as a parameter rather t= han an
> escaped header
>
>
> Hi,
>
> >>I think = we should ask ourselves: assuming we allowed to do what
> >>Mar= ianne is proposing, would anything break?
> >>
> >>= Does anyone really care whether a H-I entry was inserted based on a
> >>"real" or "virtual" response? Aren't people more interested in= the
> >>actual reason value?
> >
> >I don't = currently see a problem with permitting this (though I'm
> >interested to hear if somebody else sees an issue).
> >> >But IMO the current text doesn't suggest to me that this is vali= d.
> >So if the desire is for it to be valid it would be good to h= ave some
> >text that makes it so.
>
> I agree. We would need to a= dd some text.
>
> Regards,
>
> Christer
>
=
> _______________________________________________
> si= pcore mailing list
> sipcore@ietf.org
> http= s://www.ietf.org/mailman/listinfo/sipcore
>
__________________= _____________________________
sipcore mailing list
sipcore@ietf.or= g
https://www.ietf.org/mailman/listinfo/sipcore

<ATT00001..c>

= --_000_9DF7AC2B667B41CF842D1E3BC5724C71acmepacketcom_-- From R.Jesske@telekom.de Mon Dec 13 00:41:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14093A6D73 for ; Mon, 13 Dec 2010 00:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6ADRKQ63ZZO for ; Mon, 13 Dec 2010 00:41:21 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 5C5C53A6D70 for ; Mon, 13 Dec 2010 00:41:20 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 13 Dec 2010 09:42:53 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.187]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Mon, 13 Dec 2010 09:42:52 +0100 From: To: , Date: Mon, 13 Dec 2010 09:42:50 +0100 Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuYidnmGLPCFE06Ri2g4olG/+Jk8wCFtdew Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D050E70A6@HE111648.emea1.cds.t-internal.com> References: <4CDC04F2.3010701@cisco.com> <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> <4CED9370.5010001@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> <9DF7AC2B-667B-41CF-842D-1E3BC5724C71@acmepacket.com> In-Reply-To: <9DF7AC2B-667B-41CF-842D-1E3BC5724C71@acmepacket.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D050E70A6HE111648emea1cd_" MIME-Version: 1.0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Reason as a parameter rather than an escaped header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 08:41:22 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D050E70A6HE111648emea1cd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hadriel, for 1) I see this as a option which the service provider could choose. Not = everybody will be mandated to put in a Reason on a internal event within th= e server which ends in a retargeting/diversion. for 2) I think it could be a normal Reason value, based on a equivalent pro= cesses as it would be sent out by an other sever. E.G. If a timer expires a= 408 could be included. Best Regards Roland _____ Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von Hadriel Kaplan Gesendet: Freitag, 10. Dezember 2010 17:47 An: Mary Barnes Cc: sipcore@ietf.org WG Betreff: Re: [sipcore] Reason as a parameter rather than an escaped header OK, so I think there's general agreement to add additional H-I header field= s for internal retargeting. I have two questions then: 1) the text below says: "For retargets as a result of timeouts or internal = events, a Reason MAY be associated with the hi-targeted-to-uri that has bee= n retargeted." Why is this a MAY? What's the alternative? Does it mean they may do somet= hing else, like use a RFC 4458 style cause URI parameter? Does it mean the= y may associate it with a different hi-targeted-to-uri? (I assume not, but = the text isn't clear) For example, is this what you really want to say: "For retargets as a resul= t of timeouts or internal events, a Reason MUST be associated with the hi-t= argeted-to-uri that has been retargeted and encoded as an embedded Reason h= eader field in the URI, unless the reason for the retargeting is unknown." 2) What form of reason-value protocol can be used for a Reason from an inte= rnal operation? Can it be a "SIP" cause? Ultimately if this info is used = by a receiver of the H-I entries to trigger different behavior/features, it= would be really nice not to have to create a bunch more values that the re= ceiver would have to understand/support. -hadriel On Dec 6, 2010, at 10:38 AM, Mary Barnes wrote: Hi Marianne et al, I totally agree that there was some text removed from RFC 4244 that was int= ended to handle the internal retargeting case. I would suggest we add that = back, updating the paragraph to be a little more concise as I suggested ear= lier in the thread and add a note with regards the definition of any new Re= ason headers - something like the following: If the response contains any Reason header fields, then the Reason header fields MUST be captured as Reasons associated with the hi-targeted-to-uri that has been retargeted. If the SIP response does not include a Reason header field (see [RFC3326]), the SIP Response Code that triggered the retargeting MUST be included as the Reason associated with the hi-targeted-to-uri that has been retargeted. For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted. [MB: this is the original text from RFC 4244.] In the case that additional Reason headers are defined, per RFC 3326, the use of these Reason headers for the History-Info header field MUST follow the same rules as described above. Thanks, Mary. On Thu, Nov 25, 2010 at 4:33 PM, > wrote: Hi, I agree that draft-mohali-sipcore-reason-extension-application could live i= ndependently of 4244bis, except for the section "Reason in the History-Info= header" that should still allow wat is proposed in draft-reason. Note that RFC4244 is compatible with the draft-reason proposal: As work on = 4244bis was in progress, we based the draft on the following text from RFC4= 244: "For retargets as a result of timeouts or internal events, a Reason MA= Y be associated with the hi-targeted-to-uri that has been retargeted." Unfortunately, this sentence disappeared and only the last sentence about t= imeout suggests to insert a Reason for an internal process. If there is no objection, we could put this text back in 4244bis to keep ex= plicit the ability to insert the Reason header field in a H-I entry for *in= ternal* reasons (with a MAY). Regards, Marianne > -----Message d'origine----- > De : sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] De la = part de Christer Holmberg > Envoy=E9 : jeudi 25 novembre 2010 07:48 > =C0 : Paul Kyzivat > Cc : Worley, Dale R (Dale); sipcore@ietf.org > Objet : Re: [sipcore] Reason as a parameter rather than an > escaped header > > > Hi, > > >>I think we should ask ourselves: assuming we allowed to do what > >>Marianne is proposing, would anything break? > >> > >>Does anyone really care whether a H-I entry was inserted based on a > >>"real" or "virtual" response? Aren't people more interested in the > >>actual reason value? > > > >I don't currently see a problem with permitting this (though I'm > >interested to hear if somebody else sees an issue). > > > >But IMO the current text doesn't suggest to me that this is valid. > >So if the desire is for it to be valid it would be good to have some > >text that makes it so. > > I agree. We would need to add some text. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D050E70A6HE111648emea1cd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Hadriel,
 
for 1) I see this as a option whi= ch the service provider could choose. Not everybody will be mandated to put= in a Reason on a internal event within the server which ends in a retargeting/diversion.
for 2) I think it could be a norm= al Reason value, based on a equivalent processes as it would be sent out by= an other sever. E.G. If a timer expires a 408 could be included.
&= nbsp;
Best Regards
&= nbsp;
Roland 

Von: sipcore-bounces@ietf.org [mail= to:sipcore-bounces@ietf.org] Im Auftrag von Hadriel Kaplan
Gesendet: Freitag, 10. Dezember 2010 17:47
An: Mary Barnes
Cc: sipcore@ietf.org WG
Betreff: Re: [sipcore] Reason as a parameter rather than an escaped = header


OK, so I think there's general agreement to add additional H-I header = fields for internal retargeting.

I have two questions then:

1) the text below says: "For retargets as a result of timeouts or= internal events, a Reason MAY be associated with the hi-targeted-to-u= ri that has been retargeted."
Why is this a MAY?  What's the alternative?  Does it mean th= ey may do something else, like use a RFC 4458 style cause URI parameter? &n= bsp;Does it mean they may associate it with a different hi-targeted-to-uri?= (I assume not, but the text isn't clear)  

For example, is this what you really want to say: "For retargets = as a result of timeouts or internal events, a Reason MUST be associated wit= h the hi-targeted-to-uri that has been retargeted and encoded as an embedde= d Reason header field in the URI, unless the reason for the retargeting is unknown."

2) What form of reason-value protocol can be used for a Reason from an= internal operation?  Can it be a "SIP" cause?  Ultimat= ely if this info is used by a receiver of the H-I entries to trigger differ= ent behavior/features, it would be really nice not to have to create a bunch more values that the receiver would have to underst= and/support.

-hadriel

On Dec 6, 2010, at 10:38 AM, Mary Barnes wrote:

Hi Marianne et al,
 
I totally agree that there was some text removed from RFC 4244 that wa= s intended to handle the internal retargeting case. I would suggest we add = that back, updating the paragraph to be a little more concise as I suggeste= d earlier in the thread and add a note with regards the definition of any new Reason headers - someth= ing like the following:
 
  If the response contains any Reason header fields, then
  the Reason header fields MUST be captured as Reasons
  associated with the hi-targeted-to-uri that has been
  retargeted.  If the SIP response does not include a Reason head= er field
  (see [RFC3326]), the SIP  Response Code that triggered the= retargeting
  MUST be included as the Reason associated with the hi-targeted-= to-uri
  that has been retargeted. 
 
  For retargets as a result of timeouts or internal events, a Rea= son
  MAY be associated with the hi-targeted-to-uri that has been
  retargeted.  [MB: this is the original text from RFC 4244.= ]
 
  In the case that additional Reason headers are defined, per RFC= 3326,
  the use of these Reason headers for the History-Info header fie= ld
  MUST follow the same rules as described above.
 
Thanks,
Mary.

On Thu, Nov 25, 2010 at 4:33 PM, <marianne.mohal= i@orange-ftgroup.com> wrote:
Hi,

I agree that draft-mohali-sipcore-reason-extension-application could live i= ndependently of 4244bis, except for the section "Reason in the History= -Info header" that should still allow wat is proposed in draft-reason.=

Note that RFC4244 is compatible with the draft-reason proposal: As work on = 4244bis was in progress, we based the draft on the following text from RFC4= 244: "For retargets as a result of timeouts or internal events, a Reas= on MAY be associated with the hi-targeted-to-uri that has been retargeted."

Unfortunately, this sentence disappeared and only the last sentence about t= imeout suggests to insert a Reason for an internal process.

If there is no objection, we could put this text back in 4244bis to keep ex= plicit the ability to insert the Reason header field in a H-I entry for *in= ternal* reasons (with a MAY).


Regards,
Marianne

> -----Message d'origine-----
> De : sipcore-bounces@ietf.= org
> [mailto:sipcore-bounces@ie= tf.org] De la part de Christer Holmberg
> Envoy=E9 : jeudi 25 novembre 2010 07:48
> =C0 : Paul Kyzivat
> Cc : Worley, Dale R (Dale); sipcor= e@ietf.org
> Objet : Re: [sipcore] Reason as a parameter rather than an
> escaped header
>
>
> Hi,
>
> >>I think we should ask ourselves: assuming we allowed to do wha= t
> >>Marianne is proposing, would anything break?
> >>
> >>Does anyone really care whether a H-I entry was inserted based= on a
> >>"real" or "virtual" response? Aren't peopl= e more interested in the
> >>actual reason value?
> >
> >I don't currently see a problem with permitting this (though I'm > >interested to hear if somebody else sees an issue).
> >
> >But IMO the current text doesn't suggest to me that this is valid.=
> >So if the desire is for it to be valid it would be good to have so= me
> >text that makes it so.
>
> I agree. We would need to add some text.
>
> Regards,
>
> Christer
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

<ATT00001..c>

--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D050E70A6HE111648emea1cd_-- From Internet-Drafts@ietf.org Mon Dec 13 12:30:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA5128C116; Mon, 13 Dec 2010 12:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.258 X-Spam-Level: X-Spam-Status: No, score=-102.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDsQhuniIbKw; Mon, 13 Dec 2010 12:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBD228C0F5; Mon, 13 Dec 2010 12:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101213203002.31006.33441.idtracker@localhost> Date: Mon, 13 Dec 2010 12:30:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 20:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-07.txt Pages : 75 Date : 2010-12-13 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-sec-flows-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-13122918.I-D@ietf.org> --NextPart-- From marianne.mohali@orange-ftgroup.com Mon Dec 13 13:25:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFFBE28C0F8 for ; Mon, 13 Dec 2010 13:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNvSoZAAtLDb for ; Mon, 13 Dec 2010 13:25:52 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 2A37428C111 for ; Mon, 13 Dec 2010 13:25:52 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5C9A8FC400A; Mon, 13 Dec 2010 22:27:32 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 4E4F8FC4006; Mon, 13 Dec 2010 22:27:32 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Dec 2010 22:27:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Dec 2010 22:27:25 +0100 Message-ID: In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D050E70A6@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuYidnmGLPCFE06Ri2g4olG/+Jk8wCFtdewAAJi5zA= References: <4CDC04F2.3010701@cisco.com><4CEC570D.8080700@cisco.com><7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se><4CED9370.5010001@cisco.com><7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se><9DF7AC2B-667B-41CF-842D-1E3BC5724C71@acmepacket.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D050E70A6@HE111648.emea1.cds.t-internal.com> From: To: , , X-OriginalArrivalTime: 13 Dec 2010 21:27:29.0852 (UTC) FILETIME=[8BDB77C0:01CB9B0C] Cc: sipcore@ietf.org Subject: Re: [sipcore] Reason as a parameter rather than an escaped header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 21:25:53 -0000 Hi Hadriel, Roland, =20 I agree with Roland.=20 Additionally,=20 1) the text could be more clear as "For retargets as a result of = timeouts or internal events, a Reason header field MAY be inserted in = the History-Info header field. If inserted, the Reason header field MUST = be associated with the hi-targeted-to-uri that has been retargeted and = encoded as an embedded Reason header field in the URI." About the signification of the MAY, is it really needed to explain why = or why not? It is under the retargeting entity responsibility to decide, = non?=20 2) About the form of the reason-value, I'm not sure it is the purpose of = RFC4244bis, defining the History-Info header, to describe how the Reason = header field should be used (protocole-value...). And I don't know why = should we do such a thing. Best regards, Marianne ________________________________ De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la = part de R.Jesske@telekom.de Envoy=E9 : lundi 13 d=E9cembre 2010 09:43 =C0 : HKaplan@acmepacket.com; mary.ietf.barnes@gmail.com Cc : sipcore@ietf.org Objet : Re: [sipcore] Reason as a parameter rather than an escaped = header =09 =09 Hi Hadriel, =20 for 1) I see this as a option which the service provider could choose. = Not everybody will be mandated to put in a Reason on a internal event = within the server which ends in a retargeting/diversion.=20 for 2) I think it could be a normal Reason value, based on a equivalent = processes as it would be sent out by an other sever. E.G. If a timer = expires a 408 could be included. =20 Best Regards =20 Roland=20 ________________________________ Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Hadriel Kaplan Gesendet: Freitag, 10. Dezember 2010 17:47 An: Mary Barnes Cc: sipcore@ietf.org WG Betreff: Re: [sipcore] Reason as a parameter rather than an escaped = header =09 =09 =09 =09 OK, so I think there's general agreement to add additional H-I header = fields for internal retargeting. =09 =09 I have two questions then: =09 =09 1) the text below says: "For retargets as a result of timeouts or = internal events, a Reason MAY be associated with the hi-targeted-to-uri = that has been retargeted." Why is this a MAY? What's the alternative? Does it mean they may do = something else, like use a RFC 4458 style cause URI parameter? Does it = mean they may associate it with a different hi-targeted-to-uri? (I = assume not, but the text isn't clear) =20 For example, is this what you really want to say: "For retargets as a = result of timeouts or internal events, a Reason MUST be associated with = the hi-targeted-to-uri that has been retargeted and encoded as an = embedded Reason header field in the URI, unless the reason for the = retargeting is unknown." 2) What form of reason-value protocol can be used for a Reason from an = internal operation? Can it be a "SIP" cause? Ultimately if this info = is used by a receiver of the H-I entries to trigger different = behavior/features, it would be really nice not to have to create a bunch = more values that the receiver would have to understand/support. -hadriel On Dec 6, 2010, at 10:38 AM, Mary Barnes wrote: Hi Marianne et al, =20 I totally agree that there was some text removed from RFC 4244 that = was intended to handle the internal retargeting case. I would suggest we = add that back, updating the paragraph to be a little more concise as I = suggested earlier in the thread and add a note with regards the = definition of any new Reason headers - something like the following: =20 If the response contains any Reason header fields, then=20 the Reason header fields MUST be captured as Reasons=20 associated with the hi-targeted-to-uri that has been retargeted. If the SIP response does not include a Reason header = field=20 (see [RFC3326]), the SIP Response Code that triggered the = retargeting=20 MUST be included as the Reason associated with the = hi-targeted-to-uri=20 that has been retargeted. =20 =20 For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted. [MB: this is the original text from RFC 4244.] =20 In the case that additional Reason headers are defined, per RFC = 3326,=20 the use of these Reason headers for the History-Info header field=20 MUST follow the same rules as described above.=20 =20 Thanks, Mary.=20 =09 =09 On Thu, Nov 25, 2010 at 4:33 PM, = wrote: =09 Hi, =09 I agree that draft-mohali-sipcore-reason-extension-application could = live independently of 4244bis, except for the section "Reason in the = History-Info header" that should still allow wat is proposed in = draft-reason. =09 Note that RFC4244 is compatible with the draft-reason proposal: As = work on 4244bis was in progress, we based the draft on the following = text from RFC4244: "For retargets as a result of timeouts or internal = events, a Reason MAY be associated with the hi-targeted-to-uri that has = been retargeted." =09 Unfortunately, this sentence disappeared and only the last sentence = about timeout suggests to insert a Reason for an internal process. =09 If there is no objection, we could put this text back in 4244bis to = keep explicit the ability to insert the Reason header field in a H-I = entry for *internal* reasons (with a MAY). =09 =09 Regards, Marianne =09 > -----Message d'origine----- > De : sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] De la part de Christer Holmberg > Envoy=E9 : jeudi 25 novembre 2010 07:48 > =C0 : Paul Kyzivat > Cc : Worley, Dale R (Dale); sipcore@ietf.org > Objet : Re: [sipcore] Reason as a parameter rather than an > escaped header =09 > > > Hi, > > >>I think we should ask ourselves: assuming we allowed to do what > >>Marianne is proposing, would anything break? > >> > >>Does anyone really care whether a H-I entry was inserted based = on a > >>"real" or "virtual" response? Aren't people more interested in = the > >>actual reason value? > > > >I don't currently see a problem with permitting this (though I'm > >interested to hear if somebody else sees an issue). > > > >But IMO the current text doesn't suggest to me that this is = valid. > >So if the desire is for it to be valid it would be good to have = some > >text that makes it so. > > I agree. We would need to add some text. > > Regards, > > Christer > =09 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 From Internet-Drafts@ietf.org Wed Dec 15 13:45:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F079328C113; Wed, 15 Dec 2010 13:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqSoY4zMZkpF; Wed, 15 Dec 2010 13:45:06 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4400628C0DB; Wed, 15 Dec 2010 13:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101215214502.20118.15493.idtracker@localhost> Date: Wed, 15 Dec 2010 13:45:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-10.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 21:45:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-10.txt Pages : 18 Date : 2010-12-15 This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-keep-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-15133629.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Wed Dec 15 14:32:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FC928C106; Wed, 15 Dec 2010 14:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1ehgVOLa+Vr; Wed, 15 Dec 2010 14:32:10 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B3C28C102; Wed, 15 Dec 2010 14:32:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101215223209.21201.25813.idtracker@localhost> Date: Wed, 15 Dec 2010 14:32:09 -0800 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (Indication of support for keep-alive) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 22:32:11 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Indication of support for keep-alive' 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 substantive comments to the ietf@ietf.org mailing lists by 2011-01-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-keep/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-keep/ No IPR declarations have been submitted directly on this I-D. From dworley@avaya.com Fri Dec 17 09:04:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D431D3A692C for ; Fri, 17 Dec 2010 09:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i94IFHJb-ddA for ; Fri, 17 Dec 2010 09:04:09 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id D76D33A690B for ; Fri, 17 Dec 2010 09:04:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIQnC02HCzI1/2dsb2JhbACkMXOpDQKZIoVKBIRliUw X-IronPort-AV: E=Sophos;i="4.59,362,1288584000"; d="scan'208";a="50568070" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 17 Dec 2010 12:04:47 -0500 X-IronPort-AV: E=Sophos;i="4.59,362,1288584000"; d="scan'208";a="558895352" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Dec 2010 12:04:11 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 17 Dec 2010 12:04:10 -0500 From: "Worley, Dale R (Dale)" To: "Thomson, Martin" , Paul Kyzivat , "sipcore@ietf.org" Date: Fri, 17 Dec 2010 12:01:00 -0500 Thread-Topic: [sipcore] Extensions to the reg event package Thread-Index: ActxSNxgv9N7FJTlQcWWShNQZ2FghQAJW4oQCydsFBY= Message-ID: References: <4CC07E0F.4030508@cisco.com>, <8B0A9FCBB9832F43971E38010638454F03F31EABA6@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EABA6@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Extensions to the reg event package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 17:04:09 -0000 > From: Thomson, Martin [Martin.Thomson@andrew.com] >=20 > In practice, a processor that uses the original schema definitions is > likely to reject a document that uses the modified structure. >=20 > For instance, the original might define (A, B, *) where * is an > extension point, and the extension defines (A, B, C, *). Because if > the way that * is defined, it means anything not in this namespace. > If the original sees C, which claims to be in the same namespace, it > rejects it. Then, to phrase it another way, schemas are extensible in that elements of other namespaces may be inserted, but not new elements of the existing namespace. > The size of namespace declarations is a common source of complaints. > The usual response is to point folks at ASN.1+?ER. I wouldn't dream > of being so rude. The DER and PER encodings do seem to be much denser, but I don't see any mechanism for extensibility. XER seems to be essentially what we're already doing. Dale From Internet-Drafts@ietf.org Sun Dec 19 03:30:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A133A685B; Sun, 19 Dec 2010 03:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-c+Abk3+AOr; Sun, 19 Dec 2010 03:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515BE3A6862; Sun, 19 Dec 2010 03:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101219113002.9880.3428.idtracker@localhost> Date: Sun, 19 Dec 2010 03:30:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 11:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sipcore-reinvite-08.txt Pages : 25 Date : 2010-12-19 The procedures for handling SIP re-INVITEs are described in RFC 3261. Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-reinvite-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-19031758.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Wed Dec 22 08:38:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5A13A6B1A; Wed, 22 Dec 2010 08:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj4UbUc61grV; Wed, 22 Dec 2010 08:38:24 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBC83A6B3F; Wed, 22 Dec 2010 08:38:23 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101222163823.9845.72082.idtracker@localhost> Date: Wed, 22 Dec 2010 08:38:23 -0800 Cc: sipcore chair , Internet Architecture Board , sipcore mailing list , RFC Editor Subject: [sipcore] Protocol Action: 'Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP)' to Proposed Standard (draft-ietf-sipcore-reinvite-08.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 16:38:26 -0000 The IESG has approved the following document: - 'Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP)' (draft-ietf-sipcore-reinvite-08.txt) as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-reinvite/ Technical Summary In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. Working Group Summary There is consensus in the WG to publish this document. A single WGLC was issued, with minor comments and questions raised and addressed. Document Quality This document is narrowly focused to tighten up behavioral specification in specific ambiguous cases. It does that well. Personnel The document shepherd is Paul Kyzivat. The responsible AD is Robert Sparks. From christer.holmberg@ericsson.com Wed Dec 22 14:22:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825C93A68C6 for ; Wed, 22 Dec 2010 14:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHW7thj2pVpE for ; Wed, 22 Dec 2010 14:22:37 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F01F93A6B45 for ; Wed, 22 Dec 2010 14:22:33 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-6c-4d127aa0a34a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F5.50.23694.0AA721D4; Wed, 22 Dec 2010 23:24:32 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 22 Dec 2010 23:24:31 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Wed, 22 Dec 2010 23:24:31 +0100 Thread-Topic: Does a forking proxy send 481? Thread-Index: AQHLoicB3RtUyQIKOk6iYgKUeLVlzw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850482F0C3@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Does a forking proxy send 481? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 22:22:39 -0000 Hi, A minor old school SIP question to think about when getting prepared for th= e holidays: Fact: A stateful proxy forks an INVITE. Fact: Some early dialogs are created. Fact: The proxy receives a 4xx response on early dialog ED1. Fact: The proxy does not forward the 4xx response, as it waits for final re= sponses on the other early dialogs. Fact: The UAC sends an in-dialog request on ED1 (since it is not aware that= ED1 has been terminated). Question: Does the forking proxy send a 481 response to the request, or doe= s it forward it towards the remote UAS previously associated with ED1? The reason I ask is because of a question whether there should always be a = 2xx response to a PRACK, even if the associated dialog has been terminated.= But, a proxy that does not know PRACK would of course send a 481. Regards, Christer From mary.ietf.barnes@gmail.com Wed Dec 29 10:50:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40C33A6855 for ; Wed, 29 Dec 2010 10:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.248 X-Spam-Level: X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxBuUQhLI8H4 for ; Wed, 29 Dec 2010 10:50:00 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id BD2A63A67D6 for ; Wed, 29 Dec 2010 10:49:59 -0800 (PST) Received: by yxt33 with SMTP id 33so4776893yxt.31 for ; Wed, 29 Dec 2010 10:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3dsOc29YkMwmf5D9KHHH3/BGSHcwrz/BdBhst/E3zJA=; b=W6AQ4I7EpkgsXvafscs7+YWFvcu1+nLqVak2/xT07YoR+sLV9McE1XIGl8JbLU6EGk SIBUDtVkkswJAXm+8vdNj8H16nvBDD1lHz7gvdsb1n1BwJ2RUdnSq3oSz6KeBa1ta8iO z/RLMfhml8alsF/1Kx68Hu1WTxtkwpk7Na/UA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WuMYvditfKtQMzIzh/iI8jTbDJO81P1pQyKKGDsTxyQ44FTp+7n22jglxptwNqUlO9 o9MOS/+IjNmM2fGsCQp6G5e3h17T6D7SZDa3jlGlReQ/qUoxV8KtFpkCxllAsIOkR/gD VLAUKBTRnLzFdPFd/TLlxzBnFN40j6T8/8TTM= MIME-Version: 1.0 Received: by 10.236.109.168 with SMTP id s28mr27283517yhg.74.1293648725030; Wed, 29 Dec 2010 10:52:05 -0800 (PST) Received: by 10.236.95.35 with HTTP; Wed, 29 Dec 2010 10:52:04 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Dec 2010 12:52:04 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=0023547c8b43b839960498911011 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 18:50:06 -0000 --0023547c8b43b839960498911011 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I am in the process of completing the changes to 4244bis based on the oodles of comments. In re-reviewing the comments, I have a few additional responses below [MB2], one of which I would like feedback on - it's related to the case where the proxy is adding missing entries when there already hi-entires in the request. Thanks, Mary. On Wed, Nov 3, 2010 at 4:15 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 02 November 2010 19:25 > > To: Elwell, John > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 > > > > Hi John, > > > > Responses inline below [MB]. I will skip the ones that I replied to > > in the other response [MB]. > > > > Thanks, > > Mary. > > > > On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John > > wrote: > > > Despite the effort that has gone into addressing comments > > raised by people on -01, I still find -02 hard to understand > > in places. I have not had time to review the whole document, > > but here are some comments up to section 7. Just as I > > finished writing this I saw Mary's response to my comments on > > -01, which I will respond to tomorrow. Apologies for any > > overlap between the two. > > > > > > > > > > > 27. Section 6.1.1: > > > "The proxy MUST include an hi-index attribute > > > with a value of "1"" > > > It says we are inserting an entry, not replacing any > > existing entries. Value "1" will not apply if there is an > > existing entry. > > [MB] Correct. If the prior hop did not include an hi-entry, then one > > is added. Even if there are already other hi-entries, there is no way > > to know how many hops might have been missed and thus, the indexing > > needs to be reset to 1 to reflect such. [/MB] > [JRE] So this means a downstream entity can receive two entries with index > "1" (possibly with intervening entries 1.1 etc.), not because of any > incorrect behaviour of any of the nodes concerned, but merely because some > intervening nodes don't support H-I. This was the first time I was aware of > this. We should add some explanation. Personally I would prefer to continue > the indexing rather than reset to "1". > > [MB2] After reconsidering this, I agree with you that it would be better to not reset the index to "1" in cases where there are already hi-entries, but just not one for the previous hop However, I think it's important that it is obvious that there may be a gap. The only way I can think to do this would be to actually skip a value for the index - i.e., increment the value at the current level by 2 in the case where entries are added on behalf of prior hops in this case. This would flag that one or more intermediaries that forwarded the request did not support History-Info. This would also ensure that there are not duplicate values, which I agree could end up being extremely confusing (and the original intent was for the indices to be unique, although I am vaguely recalling this as a 4244 issue that we resolved by just setting the index to "1" - another broken aspect of 4244). [/MB2] > > > > 36. "MUST forward captured History-Info in subsequent, > > > provisional, and final responses to the request sent by > > the ultimate > > > UAS (see Section 5.2)" > > > If a response does not contain any captured H-I (because > > the UAS doesn't support it), is there any requirement on the > > proxy to generate it from its own information? > > [MB] A proxy would have added an hi-entry for the UAS if it follows > > the normative procedures in this document. But, there is no way for > > the proxy to generate any additional hi-entries (in cases where the > > UAS internally retargets or B2BUA case). [/MB] > [JRE] Understood. However, let me give you an example. A proxy receives a > request with entries 1 and 1.1, and forwards it thereby adding 1.1.1. > Suppose the next entity is the UAS and the UAS supports H-I. The UAS will > capture 1, 1.1 and 1.1.1 in the returned response, so therefore the proxy > forwards 1, 1.1 and 1.1.1 when it forwards the response. That's fine. > However, if the UAS does not support H-I, the response will contain no > entries. In this case, the proxy will be aware of entries 1, 1.1 and 1.2 and > could add them when forwarding the response. This assumes a certain amount > of state be held at the proxy, but no more than is required for forking, for > example. > Perhaps I have misinterpreted the word "captured" in the cited text - I had > assumed you meant captured in the received response, but of course it might > mean captured by the proxy from the time it forwarded the request. It > certainly needs some clarification. > [MB2] Agreed - the intent was that the proxy does keep track of the hi-entries and does include those in the subsequent response even in the case of a UAS that does not support History-Info. [/MB2] > > > > > > > > 41. Section 7.1.3, item 6: > > > "For example, if > > > a procesing entity received failure responses for > > forks 1.1.1 and > > > 1.1.2, it would return both the 1.1.1 and 1.1.2 entries to the > > > entity that generated the hi-entry with index of 1." > > > I can't figure this out - shouldn't "index of 1" be "index of 1.1"? > > [MB] No. The processing entity in that sentence has the index of 1.1. > > The processing entity is the subject of that sentence and "it" returns > > the response to the entity that would have added the hi-entry with > > index of 1.[/MB] > [JRE] I still can't figure this out. A proxy receives a request with > entries 1 and 1.1. It creates two branches, 1.1.1 and 1.1.2. Both fail, so > when the proxy sends a response back, it will include entries 1.1.1 and > 1.1.2. That response is sent to the entity that generated 1.1. > [MB2] Yep. I was thinking in terms of the entity that is associated with the hi-entry with index of 1.1. [/MB2] > > > > --0023547c8b43b839960498911011 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

I am in the process of completing the changes = to 4244bis based on the oodles of comments. In re-reviewing the comments, I= have a few additional responses below [MB2], one of which I would like fee= dback on - it's related to the case where the proxy is adding missing e= ntries when there already hi-entires in the request.=A0

Thanks,
Mary.

On Wed, Nov 3, 2010 at 4:15 AM, Elwell, John <john.elw= ell@siemens-enterprise.com> wrote:


> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> Sent: 02 November 2010 19:25
> To: Elwell, John
> Cc: sipcore@ietf= .org
> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 >
> Hi John,
>
> Responses inline below [MB]. =A0I will skip the ones that I replied to=
> in the other response [MB].
>
> Thanks,
> Mary.
>
> On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John
> <john.elwell@siemens-enterprise.com> wrote:
> > Despite the effort that has gone into addressing comments
> raised by people on -01, I still find -02 hard to understand
> in places. I have not had time to review the whole document,
> but here are some comments up to section 7. Just as I
> finished writing this I saw Mary's response to my comments on
> -01, which I will respond to tomorrow. Apologies for any
> overlap between the two.
> >
> >


> > 27. Section 6.1.1:
> > "The proxy MUST include an hi-index attribute
> > =A0 =A0 =A0with a value of "1""
> > It says we are inserting an entry, not replacing any
> existing entries. Value "1" will not apply if there is an > existing entry.
> [MB] Correct. If the prior hop did not include an hi-entry, then one > is added. Even if there are already other hi-entries, there is no way<= br> > to know how many hops might have been missed and thus, the indexing > needs to be reset to 1 to reflect such. [/MB]
[JRE] So this means a downstream entity can receive two entries with = index "1" (possibly with intervening entries 1.1 etc.), not becau= se of any incorrect behaviour of any of the nodes concerned, but merely bec= ause some intervening nodes don't support H-I. This was the first time = I was aware of this. We should add some explanation. Personally I would pre= fer to continue the indexing rather than reset to "1".

[MB2] After reconsidering this, I agree with you that= it would be better to not reset the index to "1" in cases where = there are already hi-entries, but just not one for the previous hop =A0 How= ever, I think it's important that it is obvious that there may be a gap= . The only way I can think to do this would be to actually skip a value for= the index - i.e., increment the value at the current level by 2 in the cas= e where entries are added on behalf of prior hops in this case. =A0This wou= ld flag that one or more intermediaries that forwarded the request did not = support History-Info. =A0This would also ensure that there are not duplicat= e values, which I agree could end up being extremely confusing (and the ori= ginal intent was for the indices to be unique, although I am vaguely recall= ing this as a 4244 issue that we resolved by just setting the index to &quo= t;1" - another broken aspect of 4244). [/MB2]
<snip/>
> > 36. "MUST forward captured History-Info in subsequent,<= br> > > =A0 provisional, and final responses to the request sent by
> the ultimate
> > =A0 UAS (see Section 5.2)"
> > If a response does not contain any captured H-I (because
> the UAS doesn't support it), is there any requirement on the
> proxy to generate it from its own information?
> [MB] A proxy would have added an hi-entry for the UAS if it follows > the normative procedures in this document. But, there is no way for > the proxy to generate any additional hi-entries (in cases where the > UAS internally retargets or B2BUA case). =A0 [/MB]
[JRE] Understood. However, let me give you an example. A proxy receiv= es a request with entries 1 and 1.1, and forwards it thereby adding 1.1.1. = Suppose the next entity is the UAS and the UAS supports H-I. The UAS will c= apture 1, 1.1 and 1.1.1 in the returned response, so therefore the proxy fo= rwards 1, 1.1 and 1.1.1 when it forwards the response. That's fine. How= ever, if the UAS does not support H-I, the response will contain no entries= . In this case, the proxy will be aware of entries 1, 1.1 and 1.2 and could= add them when forwarding the response. This assumes a certain amount of st= ate be held at the proxy, but no more than is required for forking, for exa= mple.
Perhaps I have misinterpreted the word "captured" in the cited te= xt - I had assumed you meant captured in the received response, but of cour= se it might mean captured by the proxy from the time it forwarded the reque= st. It certainly needs some clarification.
[MB2] Agreed - the intent was that the proxy does keep tr= ack of the hi-entries and does include those in the subsequent response eve= n in the case of a UAS that does not support History-Info. [/MB2]

<snip/>
> >
> > 41. Section 7.1.3, item 6:
> > "For example, if
> > =A0 =A0 =A0 a procesing entity received failure responses for
> forks 1.1.1 and
> > =A0 =A0 =A0 1.1.2, it would return both the 1.1.1 and 1.1.2 entri= es to the
> > =A0 =A0 =A0 entity that generated the hi-entry with index of 1.&q= uot;
> > I can't figure this out - shouldn't "index of 1"= ; be "index of 1.1"?
> [MB] No. =A0The processing entity in that sentence has the index of 1.= 1.
> The processing entity is the subject of that sentence and "it&quo= t; returns
> the response to the entity that would have added the hi-entry with
> index of 1.[/MB]
[JRE] I still can't figure this out. A proxy receives a request w= ith entries 1 and 1.1. It creates two branches, 1.1.1 and 1.1.2. Both fail,= so when the proxy sends a response back, it will include entries 1.1.1 and= 1.1.2. That response is sent to the entity that generated 1.1.
[MB2] =A0Yep. I was thinking in terms of the entity that = is associated with the hi-entry with index of 1.1. [/MB2]
=A0

<snip/>
<snip>
--0023547c8b43b839960498911011--