From christer.holmberg@ericsson.com Wed Apr 1 10:49:48 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17CB43A6D4D for ; Wed, 1 Apr 2009 10:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 Z5EE5o41tfoH for ; Wed, 1 Apr 2009 10:49:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4F60A3A6D87 for ; Wed, 1 Apr 2009 10:48:23 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A785020B99; Wed, 1 Apr 2009 19:49:22 +0200 (CEST) X-AuditID: c1b4fb3e-ab7b4bb000006d6d-00-49d3a9223bb9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7333421009; Wed, 1 Apr 2009 19:49:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 19:49:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 19:49:02 +0200 Message-ID: In-Reply-To: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcmyVBdU42VuiWQiS66xrAFOmbyUKwAnbMPw References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> From: "Christer Holmberg" To: "Hisham Khartabil" , "Simple WG" X-OriginalArrivalTime: 01 Apr 2009 17:49:03.0529 (UTC) FILETIME=[255A8990:01C9B2F2] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:49:48 -0000 Hi, Regarding 2), for those of you who were not in SFO, the proposed backwards compability solution was to change the session mapping function for legacy MSRP, so that only the user part is used when comparing the SDP a=3Dpath attribute with the URI carried in the MSRP message. Regards, Christer =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil Sent: Tuesday, March 31, 2009 11:58 PM To: Simple WG Subject: [Simple] MSRP-ACM compatibility The MSRP-ACM draft has an open requirements question on backwards compatibility with endpoints that use MSRP relays. In San Francisco some 20 or so people raised their hands one way or another on this question, yet only a much smaller number have engaged in the list discussion. Please offer your opinions on the following questions. We'd appreciate the reasoning behind your opinions, rather than just yes or no votes. We'd really like to hear from every person who raised a hand in San Francisco. If you stated an opinion at the microphone, please restate it here. 1) Is there a requirement for an endpoint that uses the C-line addressing mechanism in the MSRP-ACM draft to be able to talk to an endpoint that uses an MSRP relay (RFC 4976). 2) If you said yes to 1), is it acceptable to update RFC 4975 and/or RFC 4976 to achieve compatibility? If so, how extensively? Much appreciated, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From Markus.Isomaki@nokia.com Thu Apr 2 06:32:09 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE51C3A6ACA for ; Thu, 2 Apr 2009 06:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 zOu4s50fqARQ for ; Thu, 2 Apr 2009 06:32:09 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CDB403A6A83 for ; Thu, 2 Apr 2009 06:32:08 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n32DW3Za008916; Thu, 2 Apr 2009 08:33:07 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 16:31:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 16:31:47 +0300 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 15:31:46 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Thu, 2 Apr 2009 15:31:47 +0200 From: To: , Date: Thu, 2 Apr 2009 15:31:45 +0200 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcmyVBw31B8ei+K9R0m8tPDeGw2hlABQZLvA Message-ID: References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> In-Reply-To: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.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-OriginalArrivalTime: 02 Apr 2009 13:31:47.0632 (UTC) FILETIME=[5F415300:01C9B397] X-Nokia-AV: Clean Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:32:10 -0000 Hi, 1) I think that would be desirable, even though I haven't still heard of ot= her MSRP relay deployments or plans other than what Adrian Georgescu has br= ought up. (In reality SIP interconnect is still not that common, especially= for other media than voice, so even if there were deployments of both 4975= and ACM, they would probably still be isolated anyway.) 2) To my understanding there is no way to achieve compatibility without upd= ating at least 4975. It would be good if we could keep 4976 unchanged, so t= he existing relay implementations would not be affected. I'd also expect th= at 4975bis endpoint could talk to legacy 4975 endpoint. So, those would be = my main constraints for revising MSRP. I guess we would then be (in theory) in a situation where we have three typ= es of endpoints in the field: 4975, 4975bis and 4975+ACM. Others could talk= to each other except 4975 and 4975+ACM.=20 Question: If we do go and update 4975, would it then actually make sense to= fold the acm draft content in the revision?=20 Markus =20 >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >On Behalf Of ext Hisham Khartabil >Sent: 01 April, 2009 01:58 >To: Simple WG >Subject: [Simple] MSRP-ACM compatibility > >The MSRP-ACM draft has an open requirements question on=20 >backwards compatibility with endpoints that use MSRP relays.=20 >In San Francisco some 20 or so people raised their hands one=20 >way or another on this question, yet only a much smaller=20 >number have engaged in the list discussion. > >Please offer your opinions on the following questions. We'd=20 >appreciate the reasoning behind your opinions, rather than=20 >just yes or no votes. >We'd really like to hear from every person who raised a hand=20 >in San Francisco. If you stated an opinion at the microphone,=20 >please restate it here. > >1) Is there a requirement for an endpoint that uses the C-line=20 >addressing mechanism in the MSRP-ACM draft to be able to talk=20 >to an endpoint that uses an MSRP relay (RFC 4976). > >2) If you said yes to 1), is it acceptable to update RFC 4975=20 >and/or RFC 4976 to achieve compatibility? If so, how extensively? > >Much appreciated, >Hisham >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www.ietf.org/mailman/listinfo/simple >= From Markus.Isomaki@nokia.com Thu Apr 2 06:33:20 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF10D3A6952 for ; Thu, 2 Apr 2009 06:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_14=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 mKhJOUIQZvZX for ; Thu, 2 Apr 2009 06:33:20 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B4D6F3A689E for ; Thu, 2 Apr 2009 06:33:19 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n32DY3lH026257; Thu, 2 Apr 2009 16:34:15 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 16:34:03 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 16:33:58 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 16:33:53 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 2 Apr 2009 15:33:52 +0200 From: To: , , Date: Thu, 2 Apr 2009 15:33:51 +0200 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcmyVBdU42VuiWQiS66xrAFOmbyUKwAnbMPwACloUeA= Message-ID: References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> 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-OriginalArrivalTime: 02 Apr 2009 13:33:53.0383 (UTC) FILETIME=[AA356770:01C9B397] X-Nokia-AV: Clean Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:33:21 -0000 Hi Christer, Two questions on your proposal: * I assume no changes to relays would be required. * I assume upgared MSRP endpoint could establish a session with a legacy MS= RP endpoint. If this is correct, I'm fine with this approach. Markus =20 >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >On Behalf Of ext Christer Holmberg >Sent: 01 April, 2009 20:49 >To: Hisham Khartabil; Simple WG >Subject: Re: [Simple] MSRP-ACM compatibility > > >Hi, > >Regarding 2), for those of you who were not in SFO, the=20 >proposed backwards compability solution was to change the=20 >session mapping function for legacy MSRP, so that only the=20 >user part is used when comparing the SDP a=3Dpath attribute with=20 >the URI carried in the MSRP message. > >Regards, > >Christer > >=20 > >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >On Behalf Of Hisham Khartabil >Sent: Tuesday, March 31, 2009 11:58 PM >To: Simple WG >Subject: [Simple] MSRP-ACM compatibility > >The MSRP-ACM draft has an open requirements question on=20 >backwards compatibility with endpoints that use MSRP relays.=20 >In San Francisco some 20 or so people raised their hands one=20 >way or another on this question, yet only a much smaller=20 >number have engaged in the list discussion. > >Please offer your opinions on the following questions. We'd=20 >appreciate the reasoning behind your opinions, rather than=20 >just yes or no votes. >We'd really like to hear from every person who raised a hand=20 >in San Francisco. If you stated an opinion at the microphone,=20 >please restate it here. > >1) Is there a requirement for an endpoint that uses the C-line=20 >addressing mechanism in the MSRP-ACM draft to be able to talk=20 >to an endpoint that uses an MSRP relay (RFC 4976). > >2) If you said yes to 1), is it acceptable to update RFC 4975=20 >and/or RFC >4976 to achieve compatibility? If so, how extensively? > >Much appreciated, >Hisham >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www.ietf.org/mailman/listinfo/simple >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www.ietf.org/mailman/listinfo/simple >= From christer.holmberg@ericsson.com Thu Apr 2 07:43:44 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2E73A6AE3 for ; Thu, 2 Apr 2009 07:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.528 X-Spam-Level: X-Spam-Status: No, score=-5.528 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 jE9CvNZF8wIg for ; Thu, 2 Apr 2009 07:43:44 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BB6F228C14F for ; Thu, 2 Apr 2009 07:43:43 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 12C3421546; Thu, 2 Apr 2009 16:44:44 +0200 (CEST) X-AuditID: c1b4fb3e-affbdbb000006d6d-06-49d4cf5b17d5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C5C5B216F9; Thu, 2 Apr 2009 16:44:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 16:44:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 16:44:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcmyVBw31B8ei+K9R0m8tPDeGw2hlABQZLvAAAKpTkA= References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> From: "Christer Holmberg" To: , , X-OriginalArrivalTime: 02 Apr 2009 14:44:31.0675 (UTC) FILETIME=[886D70B0:01C9B3A1] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 14:43:45 -0000 Hi Markus, 4975 and 4975bis endpoints would be able to talk to each other, as today. 4975 and 4975+ACM endpoints would also able to talk to each other, as long as there is no intemediate which modifies the a=3Dpath attributes. You are right that, in theory, we could have 3 different types of endpoints. But, I think that would change, because new endpoints would be at least 4975bis. I think we should keep 4975bis and ACM separated. The reason is that I think a single document would be rather messy, since we would describe two different routing mechanisms. But I'm happy to hear what others think. Regards, Christer =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com Sent: Thursday, April 02, 2009 2:32 PM To: hisham.khartabil@gmail.com; simple@ietf.org Subject: Re: [Simple] MSRP-ACM compatibility Hi, 1) I think that would be desirable, even though I haven't still heard of other MSRP relay deployments or plans other than what Adrian Georgescu has brought up. (In reality SIP interconnect is still not that common, especially for other media than voice, so even if there were deployments of both 4975 and ACM, they would probably still be isolated anyway.) 2) To my understanding there is no way to achieve compatibility without updating at least 4975. It would be good if we could keep 4976 unchanged, so the existing relay implementations would not be affected. I'd also expect that 4975bis endpoint could talk to legacy 4975 endpoint. So, those would be my main constraints for revising MSRP. I guess we would then be (in theory) in a situation where we have three types of endpoints in the field: 4975, 4975bis and 4975+ACM. Others could talk to each other except 4975 and 4975+ACM.=20 Question: If we do go and update 4975, would it then actually make sense to fold the acm draft content in the revision?=20 Markus =20 >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >Behalf Of ext Hisham Khartabil >Sent: 01 April, 2009 01:58 >To: Simple WG >Subject: [Simple] MSRP-ACM compatibility > >The MSRP-ACM draft has an open requirements question on backwards=20 >compatibility with endpoints that use MSRP relays. >In San Francisco some 20 or so people raised their hands one way or=20 >another on this question, yet only a much smaller number have engaged=20 >in the list discussion. > >Please offer your opinions on the following questions. We'd appreciate=20 >the reasoning behind your opinions, rather than just yes or no votes. >We'd really like to hear from every person who raised a hand in San=20 >Francisco. If you stated an opinion at the microphone, please restate=20 >it here. > >1) Is there a requirement for an endpoint that uses the C-line=20 >addressing mechanism in the MSRP-ACM draft to be able to talk to an=20 >endpoint that uses an MSRP relay (RFC 4976). > >2) If you said yes to 1), is it acceptable to update RFC 4975 and/or=20 >RFC 4976 to achieve compatibility? If so, how extensively? > >Much appreciated, >Hisham >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Thu Apr 2 12:35:16 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DECD23A6A47 for ; Thu, 2 Apr 2009 12:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-9naDb5xp4c for ; Thu, 2 Apr 2009 12:35:16 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id A4E343A6A18 for ; Thu, 2 Apr 2009 12:35:15 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n32Ja8kG088539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Apr 2009 14:36:13 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <5258DF36-32C6-4FB2-A436-E7B693355154@estacado.net> From: Ben Campbell To: Hisham Khartabil In-Reply-To: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 14:36:08 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:35:17 -0000 (as an individual contributor) On Mar 31, 2009, at 5:57 PM, Hisham Khartabil wrote: > The MSRP-ACM draft has an open requirements question on backwards > compatibility with endpoints that use MSRP relays. In San Francisco > some 20 or so people raised their hands one way or another on this > question, yet only a much smaller number have engaged in the list > discussion. > > Please offer your opinions on the following questions. We'd appreciate > the reasoning behind your opinions, rather than just yes or no votes. > We'd really like to hear from every person who raised a hand in San > Francisco. If you stated an opinion at the microphone, please restate > it here. > > 1) Is there a requirement for an endpoint that uses the C-line > addressing mechanism in the MSRP-ACM draft to be able to talk to an > endpoint that uses an MSRP relay (RFC 4976). I believe this is a strong requirement for the C-Line part of the ACM draft to move forward. As I've mentioned, I do not want to see us create separate "camps" of MSRP implementations that are unable to communicate with each other. > > > 2) If you said yes to 1), is it acceptable to update RFC 4975 and/or > RFC 4976 to achieve compatibility? If so, how extensively? > I think minor updates to 4975 and/or 4976 are acceptable. By _minor_, I mean updates that do not remove significant features of the protocol, or dilute the security properties of the protocol, or require highly "invasive" changes to the architecture or current implementations. > Much appreciated, > Hisham > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Thu Apr 2 12:38:33 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498F53A6D49 for ; Thu, 2 Apr 2009 12:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6fLTTHnRuxB for ; Thu, 2 Apr 2009 12:38:32 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 1008028C259 for ; Thu, 2 Apr 2009 12:38:31 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n32JdLRT089306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Apr 2009 14:39:26 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Christer Holmberg 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 v930.3) Date: Thu, 2 Apr 2009 14:39:21 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:38:33 -0000 On Apr 1, 2009, at 12:49 PM, Christer Holmberg wrote: > > Hi, > > Regarding 2), for those of you who were not in SFO, the proposed > backwards compability solution was to change the session mapping > function for legacy MSRP, so that only the user part is used when > comparing the SDP a=path attribute with the URI carried in the MSRP > message. > > We also discussed the fact that this proposal may interfere with TLS certificate name matching, when one endpoint of the TLS association has a cert that is bound to an address or domain name. > > [...] From ben@estacado.net Thu Apr 2 12:40:33 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F30E3A6C62 for ; Thu, 2 Apr 2009 12:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 M4nO3bad+FFM for ; Thu, 2 Apr 2009 12:40:32 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 1F89A3A6AC9 for ; Thu, 2 Apr 2009 12:40:31 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n32JfPUx089639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Apr 2009 14:41:30 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <8E439724-7BDB-4F15-B7FE-EFEB614A4A9F@estacado.net> From: Ben Campbell To: "" 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 v930.3) Date: Thu, 2 Apr 2009 14:41:25 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: simple@ietf.org Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:40:33 -0000 A general comment: I don't think an update to 4975 or 4976 necessarily implies a bis draft. It's possible to do focused updates without revising the entire spec. For example, the SIP essential correction drafts. On Apr 2, 2009, at 8:31 AM, wrote: > Hi, > > 1) I think that would be desirable, even though I haven't still > heard of other MSRP relay deployments or plans other than what > Adrian Georgescu has brought up. (In reality SIP interconnect is > still not that common, especially for other media than voice, so > even if there were deployments of both 4975 and ACM, they would > probably still be isolated anyway.) > > 2) To my understanding there is no way to achieve compatibility > without updating at least 4975. It would be good if we could keep > 4976 unchanged, so the existing relay implementations would not be > affected. I'd also expect that 4975bis endpoint could talk to legacy > 4975 endpoint. So, those would be my main constraints for revising > MSRP. > > I guess we would then be (in theory) in a situation where we have > three types of endpoints in the field: 4975, 4975bis and 4975+ACM. > Others could talk to each other except 4975 and 4975+ACM. > > Question: If we do go and update 4975, would it then actually make > sense to fold the acm draft content in the revision? > > Markus > > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] >> On Behalf Of ext Hisham Khartabil >> Sent: 01 April, 2009 01:58 >> To: Simple WG >> Subject: [Simple] MSRP-ACM compatibility >> >> The MSRP-ACM draft has an open requirements question on >> backwards compatibility with endpoints that use MSRP relays. >> In San Francisco some 20 or so people raised their hands one >> way or another on this question, yet only a much smaller >> number have engaged in the list discussion. >> >> Please offer your opinions on the following questions. We'd >> appreciate the reasoning behind your opinions, rather than >> just yes or no votes. >> We'd really like to hear from every person who raised a hand >> in San Francisco. If you stated an opinion at the microphone, >> please restate it here. >> >> 1) Is there a requirement for an endpoint that uses the C-line >> addressing mechanism in the MSRP-ACM draft to be able to talk >> to an endpoint that uses an MSRP relay (RFC 4976). >> >> 2) If you said yes to 1), is it acceptable to update RFC 4975 >> and/or RFC 4976 to achieve compatibility? If so, how extensively? >> >> Much appreciated, >> Hisham >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Thu Apr 2 12:44:29 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78E728C102 for ; Thu, 2 Apr 2009 12:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 nTYl2NVg-ybk for ; Thu, 2 Apr 2009 12:44:29 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A0C153A6B38 for ; Thu, 2 Apr 2009 12:44:28 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A7E5720A08; Thu, 2 Apr 2009 21:45:28 +0200 (CEST) X-AuditID: c1b4fb3c-aef99bb0000004b9-1c-49d515d84221 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6EC1C20A1E; Thu, 2 Apr 2009 21:45:28 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 21:44:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 21:44:32 +0200 Message-ID: In-Reply-To: <8E439724-7BDB-4F15-B7FE-EFEB614A4A9F@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acmzywr8nGOrJCPbQR+J/wlqby86FgAAEhyw References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <8E439724-7BDB-4F15-B7FE-EFEB614A4A9F@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" , X-OriginalArrivalTime: 02 Apr 2009 19:44:56.0076 (UTC) FILETIME=[7FCEC4C0:01C9B3CB] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:44:29 -0000 Correct. As shown in SFO, the actual impacts (assuming we'll go for the presented solution) on 4975 are rather minor. Regards, Christer =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Thursday, April 02, 2009 8:41 PM To: Cc: simple@ietf.org Subject: Re: [Simple] MSRP-ACM compatibility A general comment: I don't think an update to 4975 or 4976 necessarily implies a bis draft. It's possible to do focused updates without revising the entire spec. For example, the SIP essential correction drafts. On Apr 2, 2009, at 8:31 AM, wrote: > Hi, > > 1) I think that would be desirable, even though I haven't still heard=20 > of other MSRP relay deployments or plans other than what Adrian=20 > Georgescu has brought up. (In reality SIP interconnect is still not=20 > that common, especially for other media than voice, so even if there=20 > were deployments of both 4975 and ACM, they would probably still be=20 > isolated anyway.) > > 2) To my understanding there is no way to achieve compatibility=20 > without updating at least 4975. It would be good if we could keep > 4976 unchanged, so the existing relay implementations would not be=20 > affected. I'd also expect that 4975bis endpoint could talk to legacy > 4975 endpoint. So, those would be my main constraints for revising=20 > MSRP. > > I guess we would then be (in theory) in a situation where we have=20 > three types of endpoints in the field: 4975, 4975bis and 4975+ACM. > Others could talk to each other except 4975 and 4975+ACM. > > Question: If we do go and update 4975, would it then actually make=20 > sense to fold the acm draft content in the revision? > > Markus > > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >> Behalf Of ext Hisham Khartabil >> Sent: 01 April, 2009 01:58 >> To: Simple WG >> Subject: [Simple] MSRP-ACM compatibility >> >> The MSRP-ACM draft has an open requirements question on backwards=20 >> compatibility with endpoints that use MSRP relays. >> In San Francisco some 20 or so people raised their hands one way or=20 >> another on this question, yet only a much smaller number have engaged >> in the list discussion. >> >> Please offer your opinions on the following questions. We'd=20 >> appreciate the reasoning behind your opinions, rather than just yes=20 >> or no votes. >> We'd really like to hear from every person who raised a hand in San=20 >> Francisco. If you stated an opinion at the microphone, please restate >> it here. >> >> 1) Is there a requirement for an endpoint that uses the C-line=20 >> addressing mechanism in the MSRP-ACM draft to be able to talk to an=20 >> endpoint that uses an MSRP relay (RFC 4976). >> >> 2) If you said yes to 1), is it acceptable to update RFC 4975 and/or=20 >> RFC 4976 to achieve compatibility? If so, how extensively? >> >> Much appreciated, >> Hisham >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Thu Apr 2 12:46:07 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A6A3A6D5C for ; Thu, 2 Apr 2009 12:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 8BMhbUsRT5-T for ; Thu, 2 Apr 2009 12:46:06 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 16DBF3A6D3A for ; Thu, 2 Apr 2009 12:46:05 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n32JkwSn090554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Apr 2009 14:47:03 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 14:46:58 -0500 X-Mailer: Apple Mail (2.930.3) Subject: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:46:07 -0000 (as an individual) From the list discussions and the meeting in San Francisco, we seem to have consensus around the COMEDIA provisions in the MSRP-ACM draft. All the controversy has been around the C-line vs path attribute changes. Furthermore, if I understand correctly, the COMEDIA portions and the C- Line portions are effectively separate extensions, i.e. you can use either one without the other. Does it make sense then to separate them into separate drafts? If we did so, we could go ahead and progress the COMEDIA part instead of blocking it on the discussions concerning the C-line part. From adam@nostrum.com Thu Apr 2 13:12:34 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067213A6D55 for ; Thu, 2 Apr 2009 13:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpX4ylU29gMr for ; Thu, 2 Apr 2009 13:12:33 -0700 (PDT) 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 DCD8E3A69E9 for ; Thu, 2 Apr 2009 13:12:32 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n32KDFRt063264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 15:13:16 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49D51C5B.1060702@nostrum.com> Date: Thu, 02 Apr 2009 15:13:15 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ben Campbell References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> In-Reply-To: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:12:34 -0000 Ben Campbell wrote: > (as an individual) > > From the list discussions and the meeting in San Francisco, we seem to > have consensus around the COMEDIA provisions in the MSRP-ACM draft. > All the controversy has been around the C-line vs path attribute changes. > > Furthermore, if I understand correctly, the COMEDIA portions and the > C-Line portions are effectively separate extensions, i.e. you can use > either one without the other. > > Does it make sense then to separate them into separate drafts? If we > did so, we could go ahead and progress the COMEDIA part instead of > blocking it on the discussions concerning the C-line part. I think it very much does make sense to separate these two mechanisms. The comedia changes -- which require no updates to 4975, if my understanding is correct -- should be quick, easy, and largely uncontroversial. They're also 100% backwards compatible with everything defined so far. We don't need to worry about Hisham's questions regarding backwards compatibility, since the only impacts are at the SIP/SDP level (where proper negotiation can take place), with zero impact on the MSRP behavior. On the other hand, the c= line changes are going to require a bit more consensus building (around backwards compatibility, mostly); and, depending on the outcome of those conversations, a bit more engineering (probably including normative updates to MSRP). I don't see why we need to wait on the outcome of this work before the comedia usage can be finalized and published. /a From christer.holmberg@ericsson.com Thu Apr 2 13:14:19 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDBB3A6C66 for ; Thu, 2 Apr 2009 13:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.834 X-Spam-Level: X-Spam-Status: No, score=-5.834 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 biAN1QFfNzzp for ; Thu, 2 Apr 2009 13:14:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DAD293A6B73 for ; Thu, 2 Apr 2009 13:14:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5E37F209D4; Thu, 2 Apr 2009 22:15:19 +0200 (CEST) X-AuditID: c1b4fb3c-ab792bb0000004b9-54-49d51cd7a6b7 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3A8E42098D; Thu, 2 Apr 2009 22:15:19 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 22:13:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 22:13:01 +0200 Message-ID: In-Reply-To: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP-ACM: C-line vs COMEDIA Thread-Index: Acmzy81wzUph2Hz+Q+iJ38PQqAAufQAAXk8g References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" , "Simple WG" X-OriginalArrivalTime: 02 Apr 2009 20:13:59.0048 (UTC) FILETIME=[8EB33080:01C9B3CF] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:14:20 -0000 Hi, You can use the extensions separately, but if you support the c/m-line part I see no reason why you shouldn't also support COMEDIA. It is helpful e.g. if both clients are behind NATs, and SBC based NAT traversal mechanisms are used. The COMEDIA part can be used with legacy MSRP. I think we should keep the extensions in a single draft for now, and try to close the interoperability issue asap. Otherwise we will just cause delay and confusion. So far nobody has objected to the proposed solution. We are aware of the issues (TLS etc), and nobody has proposed an alternative solution, so I really think we should aim for it. I have noticed increased interest (I get questions about the status almost every day) in MSRP due to ACM, so I really think people who don't like the proposed interoperability solution, and want something else, should say so NOW. We have discussed this for a while already, so everyone should have had time to think about it. Regards, Christer =20 -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: Thursday, April 02, 2009 8:47 PM To: Simple WG Cc: Christer Holmberg Subject: MSRP-ACM: C-line vs COMEDIA (as an individual) From the list discussions and the meeting in San Francisco, we seem to have consensus around the COMEDIA provisions in the MSRP-ACM draft. =20 All the controversy has been around the C-line vs path attribute changes. Furthermore, if I understand correctly, the COMEDIA portions and the C- Line portions are effectively separate extensions, i.e. you can use either one without the other. Does it make sense then to separate them into separate drafts? If we did so, we could go ahead and progress the COMEDIA part instead of blocking it on the discussions concerning the C-line part. From christer.holmberg@ericsson.com Thu Apr 2 13:19:42 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B253A69E9 for ; Thu, 2 Apr 2009 13:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.837 X-Spam-Level: X-Spam-Status: No, score=-5.837 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 eJMfmAa0a1jG for ; Thu, 2 Apr 2009 13:19:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 03F353A6B73 for ; Thu, 2 Apr 2009 13:19:41 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BEDB720A4B; Thu, 2 Apr 2009 22:18:27 +0200 (CEST) X-AuditID: c1b4fb3c-ac794bb0000004b9-fb-49d51d93fafa Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A23BD20A13; Thu, 2 Apr 2009 22:18:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 22:18:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 22:17:39 +0200 Message-ID: In-Reply-To: <49D51C5B.1060702@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM: C-line vs COMEDIA Thread-Index: Acmzz4QozO7pFcWmTsuJE857P9iamwAAEpsA References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> <49D51C5B.1060702@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "Ben Campbell" X-OriginalArrivalTime: 02 Apr 2009 20:18:01.0288 (UTC) FILETIME=[1F161480:01C9B3D0] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:19:43 -0000 I really hope we will get an outcome before COMEDIA is finsihed and published... We have discussed this on the list before the meeting, at the meeting, and now after the meeting. We have ONE proposed interoperability solution. We have discussed issues associated with it.=20 Let's go for it. Regards, Christer -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, April 02, 2009 9:13 PM To: Ben Campbell Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA Ben Campbell wrote: > (as an individual) > > From the list discussions and the meeting in San Francisco, we seem to > have consensus around the COMEDIA provisions in the MSRP-ACM draft. > All the controversy has been around the C-line vs path attribute changes. > > Furthermore, if I understand correctly, the COMEDIA portions and the=20 > C-Line portions are effectively separate extensions, i.e. you can use=20 > either one without the other. > > Does it make sense then to separate them into separate drafts? If we=20 > did so, we could go ahead and progress the COMEDIA part instead of=20 > blocking it on the discussions concerning the C-line part. I think it very much does make sense to separate these two mechanisms. The comedia changes -- which require no updates to 4975, if my understanding is correct -- should be quick, easy, and largely uncontroversial. They're also 100% backwards compatible with everything defined so far. We don't need to worry about Hisham's questions regarding backwards compatibility, since the only impacts are at the SIP/SDP level (where proper negotiation can take place), with zero impact on the MSRP behavior. On the other hand, the c=3D line changes are going to require a bit more consensus building (around backwards compatibility, mostly); and, depending on the outcome of those conversations, a bit more engineering (probably including normative updates to MSRP). I don't see why we need to wait on the outcome of this work before the comedia usage can be finalized and published. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Thu Apr 2 13:25:44 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C421428C264 for ; Thu, 2 Apr 2009 13:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 kreLRcVt27HK for ; Thu, 2 Apr 2009 13:25:43 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 631033A6CA1 for ; Thu, 2 Apr 2009 13:25:43 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n32KQavT096841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Apr 2009 15:26:41 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <06403A02-B82C-4A44-8361-7A3ABBF9E2DF@estacado.net> From: Ben Campbell To: Christer Holmberg 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 v930.3) Date: Thu, 2 Apr 2009 15:26:36 -0500 References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:25:44 -0000 (as an individual) On Apr 2, 2009, at 3:13 PM, Christer Holmberg wrote: > > Hi, > > You can use the extensions separately, but if you support the c/m-line > part I see no reason why you shouldn't also support COMEDIA. It is > helpful e.g. if both clients are behind NATs, and SBC based NAT > traversal mechanisms are used. > > The COMEDIA part can be used with legacy MSRP. > > I think we should keep the extensions in a single draft for now, and > try > to close the interoperability issue asap. Otherwise we will just cause > delay and confusion. > > So far nobody has objected to the proposed solution. We are aware of > the > issues (TLS etc), and nobody has proposed an alternative solution, > so I > really think we should aim for it. > > > I have noticed increased interest (I get questions about the status > almost every day) in MSRP due to ACM, so I really think people who > don't > like the proposed interoperability solution, and want something else, > should say so NOW. We have discussed this for a while already, so > everyone should have had time to think about it. > In case I have not been clear on this point: I object to the currently proposed solution, unless we also come up with a way to fix or avoid the TLS name matching issue. Otherwise we lose any hope of using TLS to authenticate MSRP server devices such as msrp relays, conference switches, off-line message storage servers, etc. > > Regards, > > Christer > > > > > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Thursday, April 02, 2009 8:47 PM > To: Simple WG > Cc: Christer Holmberg > Subject: MSRP-ACM: C-line vs COMEDIA > > (as an individual) > > From the list discussions and the meeting in San Francisco, we seem to > have consensus around the COMEDIA provisions in the MSRP-ACM draft. > All the controversy has been around the C-line vs path attribute > changes. > > Furthermore, if I understand correctly, the COMEDIA portions and the > C- > Line portions are effectively separate extensions, i.e. you can use > either one without the other. > > Does it make sense then to separate them into separate drafts? If we > did > so, we could go ahead and progress the COMEDIA part instead of > blocking > it on the discussions concerning the C-line part. From adam@nostrum.com Thu Apr 2 13:31:26 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1AB28C25F for ; Thu, 2 Apr 2009 13:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ3dCYeotMQt for ; Thu, 2 Apr 2009 13:31:25 -0700 (PDT) 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 F194628C114 for ; Thu, 2 Apr 2009 13:31:21 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n32KWKMI064755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 15:32:20 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49D520D4.3090603@nostrum.com> Date: Thu, 02 Apr 2009 15:32:20 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hisham Khartabil References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> In-Reply-To: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:31:26 -0000 Hisham Khartabil wrote: > 1) Is there a requirement for an endpoint that uses the C-line > addressing mechanism in the MSRP-ACM draft to be able to talk to an > endpoint that uses an MSRP relay (RFC 4976). > Yes. Unless we're going to fully deprecate relays, I think this is a hard requirement -- otherwise, you're effectively defining two mutually incompatible MSRP "profiles." That is not the recipe for protocol interoperation. > 2) If you said yes to 1), is it acceptable to update RFC 4975 and/or > RFC 4976 to achieve compatibility? If so, how extensively? > I have no objection to normatively updating MSRP so that the machine portion is no longer considered in matching message sessions. Anything more extensive than that would probably give me significant cause for concern. /a From adam@nostrum.com Thu Apr 2 13:39:57 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B0F3A6A18 for ; Thu, 2 Apr 2009 13:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay16z4GsSWlL for ; Thu, 2 Apr 2009 13:39:56 -0700 (PDT) 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 4D1BB3A6A6E for ; Thu, 2 Apr 2009 13:39:56 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n32KeZPb065400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 15:40:35 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49D522C3.1000109@nostrum.com> Date: Thu, 02 Apr 2009 15:40:35 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> <49D51C5B.1060702@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:39:57 -0000 Christer Holmberg wrote: > I really hope we will get an outcome before COMEDIA is finsihed and > published... > I'm confused. Are you claiming you think you can get the whole draft -- with the uncontroversial comedia part and the controversial c= part -- published faster than we could get the uncontroversial part published? > We have discussed this on the list before the meeting, at the meeting, > and now after the meeting. We have ONE proposed interoperability > solution. We have discussed issues associated with it. > The measure of discussion does not determine consensus. We do not (or, at least, are not supposed to) publish documents as RFCs simply because they have aged sufficiently. We publish them when they represent the consensus of the working group. I don't think what we have now does that. I think the largest part of it -- the comedia part -- already has consensus. It's not clear that the part designed to allow intermediaries to change media paths without informed client consent does. And I'm fairly sure that we haven't shaken the rough edges out of this second part anyway (cf. the TLS certificate issues). /a From ben@nostrum.com Thu Apr 2 13:45:52 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE45428C114 for ; Thu, 2 Apr 2009 13:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ogm6dMPaipf for ; Thu, 2 Apr 2009 13:45:52 -0700 (PDT) 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 8C1DC3A6A6E for ; Thu, 2 Apr 2009 13:45:51 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n32KkWEc065824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Apr 2009 15:46:32 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <4668EF2D-CC7D-4F58-B3C3-5FB026D88BD0@nostrum.com> From: Ben Campbell To: Ben Campbell In-Reply-To: <06403A02-B82C-4A44-8361-7A3ABBF9E2DF@estacado.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 15:46:32 -0500 References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> <06403A02-B82C-4A44-8361-7A3ABBF9E2DF@estacado.net> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 68.94.44.137 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:45:52 -0000 On Apr 2, 2009, at 3:26 PM, Ben Campbell wrote: >> I have noticed increased interest (I get questions about the status >> almost every day) in MSRP due to ACM, so I really think people who >> don't >> like the proposed interoperability solution, and want something else, >> should say so NOW. We have discussed this for a while already, so >> everyone should have had time to think about it. >> > > > In case I have not been clear on this point: I object to the > currently proposed solution, unless we also come up with a way to > fix or avoid the TLS name matching issue. Otherwise we lose any hope > of using TLS to authenticate MSRP server devices such as msrp > relays, conference switches, off-line message storage servers, etc Actually, let me elaborate on that a bit more. The change to match sessions by only the session-ID part of the MSRP URI does not break TLS per se. But the whole _point_ of that proposal was to allow an endpoint using a relay to talk with an endpoint using an SBC. Since the current proposal doesn't offer a way to do that that does not prevent the use of TLS at the relay, I do not believe that it solves the problem. From christer.holmberg@ericsson.com Thu Apr 2 13:57:32 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC893A6D5C for ; Thu, 2 Apr 2009 13:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 p4Nzghb7Tn-V for ; Thu, 2 Apr 2009 13:57:31 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 871513A6A6E for ; Thu, 2 Apr 2009 13:57:31 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0FA252098D; Thu, 2 Apr 2009 22:58:32 +0200 (CEST) X-AuditID: c1b4fb3c-af79abb0000004b9-19-49d526f7fcca Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DD5BF20516; Thu, 2 Apr 2009 22:58:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 22:57:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 22:56:24 +0200 Message-ID: In-Reply-To: <49D522C3.1000109@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM: C-line vs COMEDIA Thread-Index: Acmz00e3FowPjSzYQxSUwrwaQmKC8wAAMO6A References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> <49D51C5B.1060702@nostrum.com> <49D522C3.1000109@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 02 Apr 2009 20:57:10.0385 (UTC) FILETIME=[9741D610:01C9B3D5] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:57:32 -0000 Hi,=20 >>I really hope we will get an outcome before COMEDIA is finsihed and published... > =20 > >I'm confused. Are you claiming you think you can get the whole draft -- with the uncontroversial comedia part and the=20 >controversial c=3D part -- published faster than we could get the uncontroversial part published? I don't claim so, but I hope so :) >>We have discussed this on the list before the meeting, at the meeting, >>and now after the meeting. We have ONE proposed interoperability=20 >>solution. We have discussed issues associated with it. > =20 > >The measure of discussion does not determine consensus. We do not (or, at least, are not supposed to) publish documents=20 >as RFCs simply because they have aged sufficiently. We publish them when they represent the consensus of the working=20 >group.=20 I agree. But, nobody has objected to what we have proposed so far. Yes, we have some work with the TLS stuff, so let's focus on trying to solve that. Then, if we figure out that we don't get anywhere, we can start to discuss splitting of documents. >I don't think what we have now does that. That is why I ask people to speak up, and give opinions and proposals on how to solve things. >I think the largest part of it -- the comedia part -- already has consensus. Yes. >It's not clear that the part designed to allow intermediaries to change media paths without informed client consent does.=20 >And I'm fairly sure that we haven't shaken the rough edges out of this second part anyway (cf. the TLS certificate=20 >issues). Nobody has objected to the principle of c/m, but there are some TLS issues we need to deal with. However, as was said at the meeting, some of those are not MSRP specific. Regards, Christer /a From christer.holmberg@ericsson.com Thu Apr 2 14:37:57 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2043A6B39 for ; Thu, 2 Apr 2009 14:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.842 X-Spam-Level: X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 tixUXu5F5XtJ for ; Thu, 2 Apr 2009 14:37:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A94913A6950 for ; Thu, 2 Apr 2009 14:37:56 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 434B62045E; Thu, 2 Apr 2009 23:38:57 +0200 (CEST) X-AuditID: c1b4fb3c-ae798bb0000004b9-e6-49d53071ba8e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0E5EE20584; Thu, 2 Apr 2009 23:38:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 23:38:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 23:37:37 +0200 Message-ID: In-Reply-To: <49D520D4.3090603@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acmz0icM+kNLK4gAQ4qF1D8ZVMk/HwACFIbg References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <49D520D4.3090603@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "Hisham Khartabil" X-OriginalArrivalTime: 02 Apr 2009 21:38:17.0252 (UTC) FILETIME=[559FDE40:01C9B3DB] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:37:57 -0000 Hi,=20 >>1) Is there a requirement for an endpoint that uses the C-line=20 >>addressing mechanism in the MSRP-ACM draft to be able to talk to an=20 >>endpoint that uses an MSRP relay (RFC 4976). > =20 > >Yes. > >Unless we're going to fully deprecate relays, I think this is a hard requirement -- otherwise, you're effectively=20 >defining two mutually incompatible MSRP "profiles." That is not the recipe for protocol interoperation. I think most of us agree that the deployments of relays is relatively limited, so we need to keep that in mind when discussing something which I strongly believe is going to be much more deployed. That doesn't mean we shouldn't care, but maybe we will have to live with some limitations. We did have some off-line discussions regarding the TLS issue in SFO. Maybe Ben could say a few words about what was discussed? Regards, Christer From adam@nostrum.com Thu Apr 2 15:36:05 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618903A6D5B for ; Thu, 2 Apr 2009 15:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqKjG771Z-VT for ; Thu, 2 Apr 2009 15:36:04 -0700 (PDT) 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 2D47F3A6C13 for ; Thu, 2 Apr 2009 15:36:03 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n32MaiPW073941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 17:36:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49D53DFC.6090202@nostrum.com> Date: Thu, 02 Apr 2009 17:36:44 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> <49D51C5B.1060702@nostrum.com> <49D522C3.1000109@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:36:05 -0000 Christer Holmberg wrote: > Nobody has objected to the principle of c/m That's not true -- Ben has been objecting, repeatedly, to this portion of the document for some time now, and I objected at the microphone in Dublin. It's currently optional in the draft, which makes it imminently separable from the comedia portion. This is the only portion of the document that requires normative changes to MSRP. This is the portion of the document that raises very real security issues about TLS authentication. This is also the portion of the document that isn't particularly well motivated. It cites four purposes: 1. performance monitoring 2. lawful intercept 3. address domain bridging 4. interconnect SLA policy enforcement It's hard to see how #1 relates to MSRP -- it's not realtime media in the conventional sense, so monitoring things like jitter and latency are basically meaningless. The only metric that really makes any sense is throughput, and that's more sensibly measured at routers (especially since you can get cross-service metrics there, instead of having to intercept and process every service being used by the susbcriber). Number 2 is explicitly out of scope for making IETF protocol decisions -- RFC 1984 is still in effect until the IAB and IESG issue an obsoleting policy document. Number 3 is best served via client-controlled mechanisms, such as MSRP relays, TURN relays, SOCKS proxies, and ICE techniques. Number 4, like number 1, is best suited by a general cross-domain policy enforcement -- otherwise, you're upgrading the core of the network for every new deployed client service. That simply doesn't scale. The document also points out that, *if* someone is hellbent on doing things with the architecture you describe, then there is a perfectly valid solution for performing these activities (make the B2BUA in question have at least a tiny bit of understanding about MSRP) -- so the c/m stuff can, at best, be considered an optimization. Top this off with the TLS issues (which you apparently understand so poorly that you need Ben to explain it on your behalf), and I think you have plenty of controversy around the c/m changes. /a From HKaplan@acmepacket.com Thu Apr 2 17:56:40 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6623A6D19 for ; Thu, 2 Apr 2009 17:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hr60KT0WtPO for ; Thu, 2 Apr 2009 17:56:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7E5BD3A6B00 for ; Thu, 2 Apr 2009 17:56:39 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 20:57:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 2 Apr 2009 20:57:40 -0400 From: Hadriel Kaplan To: Hisham Khartabil , Simple WG Date: Thu, 2 Apr 2009 20:57:39 -0400 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcmyVBXRlBYHoxZLTp2c+oa7rJRhHABooscQ Message-ID: References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> In-Reply-To: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.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: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 00:56:40 -0000 My opinion is yes to both. My reasoning is since half the people said they wanted it to be backward co= mpatible as much as possible, and the other half said they didn't care abou= t backwards compatibility, I think the only path to reach consensus is to m= ake whatever changes we need to, to make it backward compatible. That way = a majority of the people should be satisfied. I personally don't care about backwards compatibility, but I do care that w= e reach consensus and move forward with a solution. -hadriel > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Hisham Khartabil > Sent: Tuesday, March 31, 2009 6:58 PM >=20 > The MSRP-ACM draft has an open requirements question on backwards > compatibility with endpoints that use MSRP relays. In San Francisco > some 20 or so people raised their hands one way or another on this > question, yet only a much smaller number have engaged in the list > discussion. >=20 > Please offer your opinions on the following questions. We'd appreciate > the reasoning behind your opinions, rather than just yes or no votes. > We'd really like to hear from every person who raised a hand in San > Francisco. If you stated an opinion at the microphone, please restate > it here. >=20 > 1) Is there a requirement for an endpoint that uses the C-line > addressing mechanism in the MSRP-ACM draft to be able to talk to an > endpoint that uses an MSRP relay (RFC 4976). >=20 > 2) If you said yes to 1), is it acceptable to update RFC 4975 and/or > RFC 4976 to achieve compatibility? If so, how extensively? >=20 > Much appreciated, > Hisham > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Thu Apr 2 18:01:28 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887DA28C25B for ; Thu, 2 Apr 2009 18:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwRPJZJHVw7S for ; Thu, 2 Apr 2009 18:01:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A58D528C23D for ; Thu, 2 Apr 2009 18:01:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 21:02:29 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 2 Apr 2009 21:02:28 -0400 From: Hadriel Kaplan To: Ben Campbell , Hisham Khartabil Date: Thu, 2 Apr 2009 21:02:22 -0400 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acmzyl+bK4bMQOi0TJSH9DRYFuZDqgALOCww Message-ID: References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <5258DF36-32C6-4FB2-A436-E7B693355154@estacado.net> In-Reply-To: <5258DF36-32C6-4FB2-A436-E7B693355154@estacado.net> 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: Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:01:28 -0000 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell >=20 > I believe this is a strong requirement for the C-Line part of the ACM > draft to move forward. As I've mentioned, I do not want to see us > create separate "camps" of MSRP implementations that are unable to > communicate with each other. While I agree it is obviously possible to separate some parts of the ACM dr= aft, I don't see how that wouldn't still end up with separate "camps" of MS= RP implementations. ISTM that we either solve it all in one go, or not at = all. The fewer final separate RFC docs there are, the better, imo - and th= e only people I've seen interested in using the comedia aspects are the sam= e ones who want the ACM aspects in general. (though that could just be a fa= lse impression on my part) -hadriel From HKaplan@acmepacket.com Thu Apr 2 18:05:03 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6503A6D5B for ; Thu, 2 Apr 2009 18:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 ncpcoYjxS9Cj for ; Thu, 2 Apr 2009 18:05:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CA8713A6971 for ; Thu, 2 Apr 2009 18:05:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 21:06:04 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 2 Apr 2009 21:06:01 -0400 From: Hadriel Kaplan To: Ben Campbell , Simple WG Date: Thu, 2 Apr 2009 21:05:58 -0400 Thread-Topic: [Simple] MSRP-ACM: C-line vs COMEDIA Thread-Index: Acmzy+j/b2ZQfXq4TNOv5R9AKAPUGQALCaiA Message-ID: References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> In-Reply-To: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> 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: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:05:03 -0000 I'm confused. In an earlier email you said "I believe this is a strong req= uirement for the C-Line part of the ACM draft to move forward." And below y= ou're talking about the "COMEDIA provisions". Which parts of COMEDIA are y= ou referring to - the setup and connection attributes, or using the c-line = for addressing? -hadriel > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell > Sent: Thursday, April 02, 2009 3:47 PM > To: Simple WG > Subject: [Simple] MSRP-ACM: C-line vs COMEDIA >=20 > (as an individual) >=20 > From the list discussions and the meeting in San Francisco, we seem > to have consensus around the COMEDIA provisions in the MSRP-ACM draft. > All the controversy has been around the C-line vs path attribute > changes. >=20 > Furthermore, if I understand correctly, the COMEDIA portions and the C- > Line portions are effectively separate extensions, i.e. you can use > either one without the other. >=20 > Does it make sense then to separate them into separate drafts? If we > did so, we could go ahead and progress the COMEDIA part instead of > blocking it on the discussions concerning the C-line part. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Thu Apr 2 18:27:35 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37C93A69A1 for ; Thu, 2 Apr 2009 18:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 VK82XtDS1ZAC for ; Thu, 2 Apr 2009 18:27:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E131B3A6971 for ; Thu, 2 Apr 2009 18:27:34 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 21:28:36 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 2 Apr 2009 21:28:30 -0400 From: Hadriel Kaplan To: Adam Roach , Christer Holmberg Date: Thu, 2 Apr 2009 21:28:22 -0400 Thread-Topic: [Simple] MSRP-ACM: C-line vs COMEDIA Thread-Index: Acmz45BAPPN/ZM0sREG9RESbHA81EwAFPOVg Message-ID: References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> <49D51C5B.1060702@nostrum.com> <49D522C3.1000109@nostrum.com> <49D53DFC.6090202@nostrum.com> In-Reply-To: <49D53DFC.6090202@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 Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:27:35 -0000 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Adam Roach >=20 > Christer Holmberg wrote: > > Nobody has objected to the principle of c/m >=20 > That's not true -- Ben has been objecting, repeatedly, to this portion > of the document for some time now, and I objected at the microphone in > Dublin. It's currently optional in the draft, which makes it imminently > separable from the comedia portion. > This is the only portion of the document that requires normative changes > to MSRP. > This is the portion of the document that raises very real security > issues about TLS authentication. The issue it raises is not really one that didn't exist before, though slig= htly different. In the 4976-relay approach, you already had to trust the M= SRP Relays to not lie to you, and also to do cert matching correctly. It w= as not end-to-end UA-to-UA TLS to begin with. What we're proposing to do f= or ACM is to use the Comedia-TLS model, using a fingerprint attribute in SD= P. You'll have to trust the SIP layer not to lie, just as you would have h= ad to trust the MSRP Relay not to lie. The only difference is the UA was k= nowingly using a Relay. (which is important, but not an actual guarantee) Interestingly having an IP/TCP-layer relay (e.g., an SBC) actually provides= an opportunity to do end-end TLS. In fact it's probably the most common t= hing to do in comedia-tls usage today for SBC's - let TLS go end-to-end. B= ut SBC's also terminate it sometimes, when they're offloading TLS work from= a server, though they then have the cert with the CN/SAN of the server. But anyway that's a separate thread topic, so I'll split it out in a separa= te email. =20 > This is also the portion of the document that isn't particularly well > motivated. It cites four purposes: The main motivation is undoubtedly supporting currently deployed networks. = I would honestly think that's pretty compelling, even if I didn't build an= SBC.=20 -hadriel From adam@nostrum.com Thu Apr 2 18:54:30 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52593A6C30 for ; Thu, 2 Apr 2009 18:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLrzguXd2aiF for ; Thu, 2 Apr 2009 18:54:30 -0700 (PDT) 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 EB9B93A6CD4 for ; Thu, 2 Apr 2009 18:53:53 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n331soRp087766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 20:54:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49D56C69.4040303@nostrum.com> Date: Thu, 02 Apr 2009 20:54:49 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hadriel Kaplan References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> <49D51C5B.1060702@nostrum.com> <49D522C3.1000109@nostrum.com> <49D53DFC.6090202@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:54:30 -0000 Hadriel Kaplan wrote: >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >> Of Adam Roach >> >> This is also the portion of the document that isn't particularly well >> motivated. It cites four purposes: >> > > The main motivation is undoubtedly supporting currently deployed networks. I would honestly think that's pretty compelling, even if I didn't build an SBC. > Are you claiming that anything more than a trivial minority of currently deployed SBCs in live networks understand comedia and support TLS/TCP transit for media streams? It seems highly unlikely, since the only obvious use cases (given the state of SIP deployment in large networks) inherently involve MSRP -- and if they support MSRP, then they support MSRP. What am I missing? What would have driven comedia and TLS/TCP support into _currently_ _deployed_ SBCs? /a From HKaplan@acmepacket.com Thu Apr 2 19:22:08 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B644028C277 for ; Thu, 2 Apr 2009 19:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 ZxG8spNljC8r for ; Thu, 2 Apr 2009 19:22:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D7AD528C0FA for ; Thu, 2 Apr 2009 19:22:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 22:23:09 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 2 Apr 2009 22:23:09 -0400 From: Hadriel Kaplan To: Adam Roach Date: Thu, 2 Apr 2009 22:23:07 -0400 Thread-Topic: [Simple] MSRP-ACM: C-line vs COMEDIA Thread-Index: Acmz/y9jL4/+bHAeQ/CqJlxKkXhPKAAADBag Message-ID: References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> <49D51C5B.1060702@nostrum.com> <49D522C3.1000109@nostrum.com> <49D53DFC.6090202@nostrum.com> <49D56C69.4040303@nostrum.com> In-Reply-To: <49D56C69.4040303@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 Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 02:22:08 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, April 02, 2009 9:55 PM > To: Hadriel Kaplan >=20 > Are you claiming that anything more than a trivial minority of currently > deployed SBCs in live networks understand comedia and support TLS/TCP > transit for media streams? I can't speak for them all, but every one of ours does or can. It may be a= dministratively disabled on some or a majority of them for all I know, but = someone made us implement support for it 2+ years ago which means by now mo= st if not all systems have been upgraded to at least be able to do it; and = it can be turned on with one config command, for free. And we're not the o= nly game in town so I assume others have done it by now too. > It seems highly unlikely, since the only obvious use cases (given the > state of SIP deployment in large networks) inherently involve MSRP -- > and if they support MSRP, then they support MSRP. What am I missing? > What would have driven comedia and TLS/TCP support into _currently_ > _deployed_ SBCs? The first application we saw using it was BFCP, but someone's doing RFC 457= 1 for RTP too (or at least it's been in RFI/RFP's, who knows if it's in use= ). -hadriel From HKaplan@acmepacket.com Thu Apr 2 20:06:12 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394713A69A1 for ; Thu, 2 Apr 2009 20:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WipE8pl9nKZp for ; Thu, 2 Apr 2009 20:06:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 07E923A6930 for ; Thu, 2 Apr 2009 20:06:10 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 23:07:12 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 2 Apr 2009 23:07:12 -0400 From: Hadriel Kaplan To: Simple WG Date: Thu, 2 Apr 2009 23:07:11 -0400 Thread-Topic: MSRP ACM and TLS Thread-Index: Acm0CUgMAjCdTrMZT5eFQDubyxoBNQ== Message-ID: 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: [Simple] MSRP ACM and TLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 03:06:12 -0000 [This email is just thinking out loud to try to understand the issue - no m= atter what we'll need to get some guidance from a security expert (ekr?)] The subject has been raised that an ACM model impacts the ability to do TLS= using the SAN (subjectAltName) of a public server host. I believe this wa= s based on the idea that ACM would let a middlebox not only change the c/m = lines, but in fact have it replace the host portion of the top path attribu= te, right? In such a case, the original host portion would be lost. If I understand the model 4975/4976 had in mind, as a UA when you're given = an MSRPS URI to use, you connect using TLS and verify the SAN of the far-en= d matches the hostname portion of the MSRPS URI you were given in SDP. Whe= n you offer a MSRPS URI, the hostname you put in the URI must likewise matc= h the SAN in your cert. As a Relay, when you're told to send an MSRP messa= ge to a MSRPS URI next-hop, you do a similar matching check to that next-ho= p, etc.=20 What's not clear to me is what actual security binding property is achieved= . For example, if I send a SIP Invite to sip:bob@biloxi.com, and the SDP a= nswer has an MSRPS URI of "msrps://foobar.com:1234/pwned4ever", then does v= erifying that my MSRP connection to foobar.com really is to foobar.com mean= anything? Is there some language in the RFC's that say the SIP target AoR= 's domain has to match the SAN as well? (I can't find it) Sans that (ooh, = a pun), then you're already believing the SIP layer isn't lying to you - be= cause anyone can just make a box be a b2bua-sip + b2bua-msrp and give you a= cert with a SAN of whatever, so long as the MSRPS URI matches it and you h= ave a common CA. (yes it would have to be a cert with a common CA, but all = the common CA says is "that sure is foobar.com", though at least then you'd= have non-reputable record of it) Another good property is your UA client can show you that it's foobar.com, = or prompt you for confirmation that's ok. And that's a good property to ha= ve. You don't actually need the msrps URI to match anything to do that, of= course. But it's good to have a match solely because at least it keeps ju= st any old MITM from intercepting MSRP connections - it would have to be mo= re than just a snooper, it would have to be a malicious SIP and MSRP MITM. = =20 So, in summary, I think the property we'd like to keep is that if the SDP l= ayer said foobar.com, that the MSRP layer really connects to foobar.com, wh= atever that may or may not imply. With ACM, if foobar.com is not left in t= he path attribute, that can't be achieved without some other means. The options as I see them are: 1) Use the fingerprint attribute, even for public SANs. A server with a re= al SAN can create a fingerprint just as any, and send that in its SDP. The= problem with that is a 4976bis-Relay can't be asked for its fingerprint, n= or be told to check one against a next-hop, afaict, without some real chang= es. (right?) That's really an issue with using fingerprints period with Re= lays. If we were to add such support for Relays, however, it would provide= the ability to connect to self-signed certs on UA's in general, even witho= ut ACM. 2) Do ACM differently to begin with - for example by having middleboxes ins= ert (instead of modify) a path attribute which has the same cookie portion,= but with a URI param that means something like "for the TCP connection but= not for the to/from-path URI". That way the original ones are left intact= and used for cert matching, while the inserted one is used for connection = ip/port. That would still require changes on Relays, but a smaller change = I guess. Would that work? -hadriel From christer.holmberg@ericsson.com Thu Apr 2 23:13:18 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA133A6972 for ; Thu, 2 Apr 2009 23:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.845 X-Spam-Level: X-Spam-Status: No, score=-5.845 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 KX9x9g0+qz6d for ; Thu, 2 Apr 2009 23:13:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DCFFD3A68A6 for ; Thu, 2 Apr 2009 23:13:16 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 916C320C3E; Fri, 3 Apr 2009 08:14:17 +0200 (CEST) X-AuditID: c1b4fb3c-ab792bb0000004b9-14-49d5a939ed29 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6816720056; Fri, 3 Apr 2009 08:14:17 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 08:14:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 08:13:38 +0200 Message-ID: In-Reply-To: <49D53DFC.6090202@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM: C-line vs COMEDIA Thread-Index: Acmz44FRUeGHB/HGTbmDYiO/PU9YTQAPhC7w References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> <49D51C5B.1060702@nostrum.com> <49D522C3.1000109@nostrum.com> <49D53DFC.6090202@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 03 Apr 2009 06:14:07.0554 (UTC) FILETIME=[65712A20:01C9B423] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 06:13:18 -0000 Hi,=20 >>Nobody has objected to the principle of c/m > >That's not true -- Ben has been objecting, repeatedly, to this portion of the document for some time now, I guess Ben can speak for himself, but in my undrstanding Ben has not objected to the principle, but wants to deal with the TLS impacts of it. >and I objected at the microphone in Dublin. It's currently optional in the draft, which makes it imminently separable=20 >from the comedia portion. True, but that doesn't mean it can't be in the same draft. And, as Hadriel said, most people will probably use both comedia and c/m anyway. >This is the only portion of the document that requires normative changes to MSRP. > >This is the portion of the document that raises very real security issues about TLS authentication. > >This is also the portion of the document that isn't particularly well motivated. It cites four purposes: > > 1. performance monitoring > 2. lawful intercept > 3. address domain bridging > 4. interconnect SLA policy enforcement > >It's hard to see how #1 relates to MSRP -- it's not realtime media in the conventional sense, so monitoring things like=20 >jitter and latency are basically meaningless. The only metric that really makes any sense is throughput, and that's more=20 >sensibly measured at routers (especially since you can get cross-service metrics there, instead of having to intercept=20 >and process every service being used by the susbcriber). > >Number 2 is explicitly out of scope for making IETF protocol decisions >->- RFC 1984 is still in effect until the IAB and IESG issue an obsoleting policy document. > >Number 3 is best served via client-controlled mechanisms, such as MSRP relays, TURN relays, SOCKS proxies, and ICE=20 >techniques. > >Number 4, like number 1, is best suited by a general cross-domain policy enforcement -- otherwise, you're upgrading the=20 >core of the network for every new deployed client service. That simply doesn't scale. > >The document also points out that, *if* someone is hellbent on doing things with the architecture you describe, then=20 >there is a perfectly valid solution for performing these activities (make the B2BUA in question have at least a tiny bit=20 >of understanding about MSRP) -- so the c/m stuff can, at best, be considered an optimization. The motivation is to make MSRP work with SBCs. In the real world that is a very good motivation. >Top this off with the TLS issues (which you apparently understand so poorly that you need Ben to explain it on your=20 >behalf), and I think you have plenty of controversy around the c/m changes. I do have an understanding of the TLS issue. But, we had off-line discussions about it in SFO, and I thought we had agreed on some assumptions and ways forward. Those are the ones I asked Ben to explain. Regards, Christer From Remi.Denis-Courmont@nokia.com Fri Apr 3 00:15:31 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCBF3A6845 for ; Fri, 3 Apr 2009 00:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 nsPw-WkD4cVS for ; Fri, 3 Apr 2009 00:15:30 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B3BFD3A67D8 for ; Fri, 3 Apr 2009 00:15:30 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n337G0bO030550; Fri, 3 Apr 2009 02:16:30 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 10:16:05 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 10:16:04 +0300 Received: from leon.remlab.net (esdhcp043152.research.nokia.com [172.21.43.152]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n337G2w8017383; Fri, 3 Apr 2009 10:16:03 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: simple@ietf.org Date: Fri, 3 Apr 2009 10:16:08 +0300 User-Agent: KMail/1.11.0 (Linux/2.6.28.9; KDE/4.2.0; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904031016.08922.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Apr 2009 07:16:04.0669 (UTC) FILETIME=[0D03E6D0:01C9B42C] X-Nokia-AV: Clean Subject: Re: [Simple] MSRP ACM and TLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 07:15:31 -0000 On Friday 03 April 2009 06:07:11 ext Hadriel Kaplan wrote: > [This email is just thinking out loud to try to understand the issue - no > matter what we'll need to get some guidance from a security expert (ekr?)] As was noted in my earlier & defunct COMEDIA-MSRP draft, COMEDIA-TLS can=20 anyway not work, at least not end-to-end through a SBC. COMEDIA-TLS ties the direction of TLS to the direction of TCP. Practically,= he=20 who sends the TCP/SYN sends the TLS/ClientHello, and he who sends the TCP/S= YN- ACK sends the TLS/ServerHello. In my understanding, with an SBC in the midd= le,=20 both endpoints are COMEDIA "active", meaning they both sends TCP/SYN, and b= oth=20 sends ClientHello. *caboom* > If I understand the model 4975/4976 had in mind, as a UA when you're given > an MSRPS URI to use, you connect using TLS and verify the SAN of the > far-end matches the hostname portion of the MSRPS URI you were given in > SDP. When you offer a MSRPS URI, the hostname you put in the URI must > likewise match the SAN in your cert. =A0As a Relay, when you're told to s= end > an MSRP message to a MSRPS URI next-hop, you do a similar matching check = to > that next-hop, etc.=20 My understanding is the opposite - hop-by-hop TLS. Or rather, every body do= es=20 hop-by-hop, clients and relays alike. In fact, I don't see how you can do e= nd- to-end TLS (without tunneling). =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From christer.holmberg@ericsson.com Fri Apr 3 02:56:07 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502AD3A6BFA for ; Fri, 3 Apr 2009 02:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 y18qrqqT8c-R for ; Fri, 3 Apr 2009 02:56:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 77F9E3A6B59 for ; Fri, 3 Apr 2009 02:56:06 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C39C32173F; Fri, 3 Apr 2009 11:57:07 +0200 (CEST) X-AuditID: c1b4fb3e-b0027bb0000024d5-b6-49d5dd73896e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A5A93215D9; Fri, 3 Apr 2009 11:57:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 11:56:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 11:56:16 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM: C-line vs COMEDIA Thread-Index: Acmz44FRUeGHB/HGTbmDYiO/PU9YTQAPhC7wAAgXCCA= References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net><49D51C5B.1060702@nostrum.com><49D522C3.1000109@nostrum.com><49D53DFC.6090202@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 03 Apr 2009 09:56:20.0010 (UTC) FILETIME=[703480A0:01C9B442] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 09:56:07 -0000 Hi,=20 >and I think you have plenty of controversy around the c/m changes. I am not sure what you mean by plenty of convroversy. As far as I know, the issue is regarding interoperability between ACM and MSRP relay, and how to deal with TLS in that case, but not about c/m as such. But, let's focus on how/if we can solve the TLS issue :) Regards, Christer From christer.holmberg@ericsson.com Fri Apr 3 03:07:16 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ABF73A6AE7 for ; Fri, 3 Apr 2009 03:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.703 X-Spam-Level: X-Spam-Status: No, score=-5.703 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 owepXOSfB5lD for ; Fri, 3 Apr 2009 03:07:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C27573A6AC7 for ; Fri, 3 Apr 2009 03:07:15 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2218321271; Fri, 3 Apr 2009 12:08:17 +0200 (CEST) X-AuditID: c1b4fb3e-ab01dbb0000024d5-af-49d5e0114c3b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 03BE02120B; Fri, 3 Apr 2009 12:08:17 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 12:07:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 12:07:18 +0200 Message-ID: In-Reply-To: <200904031016.08922.remi.denis-courmont@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP ACM and TLS Thread-Index: Acm0LCLMD71jQ7GmTmu5s9cYSdTuIgAFn+8Q References: <200904031016.08922.remi.denis-courmont@nokia.com> From: "Christer Holmberg" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , X-OriginalArrivalTime: 03 Apr 2009 10:07:42.0254 (UTC) FILETIME=[06DAACE0:01C9B444] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] MSRP ACM and TLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 10:07:16 -0000 Hi,=20 >>[This email is just thinking out loud to try to understand the issue - = >>no matter what we'll need to get some guidance from a security expert=20 >>(ekr?)] >=20 >As was noted in my earlier & defunct COMEDIA-MSRP draft,=20 >COMEDIA-TLS can anyway not work, at least not end-to-end=20 >through a SBC. >=20 >COMEDIA-TLS ties the direction of TLS to the direction of=20 >TCP. Practically, he who sends the TCP/SYN sends the=20 >TLS/ClientHello, and he who sends the TCP/SYN- ACK sends the=20 >TLS/ServerHello. In my understanding, with an SBC in the=20 >middle, both endpoints are COMEDIA "active", meaning they=20 >both sends TCP/SYN, and both sends ClientHello. *caboom* True. And, if both endpoints are "active" you of course may (depending = on the TCP stacks in the endpoints) have an end-to-end issue even = without TLS, for any protocol which uses TCP. To deal with this, SBCs sometimes act as TCP B2BUAs, and in the TLS case = the SBC would act as a TLS B2BUA (which it may have to do anyway, = depending on what functions it performs). Many SBCs (not only Hadriel's :) already support this, since it is not = MSRP specific. Regards, Christer From ben@estacado.net Fri Apr 3 13:17:28 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091FC3A69AB for ; Fri, 3 Apr 2009 13:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXzbpfzfpcvY for ; Fri, 3 Apr 2009 13:17:27 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id BC35F3A6996 for ; Fri, 3 Apr 2009 13:17:26 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n33KIMES030096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Apr 2009 15:18:22 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> From: Ben Campbell To: Christer Holmberg 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 v930.3) Date: Fri, 3 Apr 2009 15:18:22 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <49D520D4.3090603@nostrum.com> X-Mailer: Apple Mail (2.930.3) Cc: Adam Roach , Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:17:28 -0000 On Apr 2, 2009, at 4:37 PM, Christer Holmberg wrote: > > Hi, > >>> 1) Is there a requirement for an endpoint that uses the C-line >>> addressing mechanism in the MSRP-ACM draft to be able to talk to an >>> endpoint that uses an MSRP relay (RFC 4976). >> >> >> Yes. >> >> Unless we're going to fully deprecate relays, I think this is a hard > requirement -- otherwise, you're effectively >> defining two mutually incompatible MSRP "profiles." That is not the > recipe for protocol interoperation. > > I think most of us agree that the deployments of relays is relatively > limited, so we need to keep that in mind when discussing something > which > I strongly believe is going to be much more deployed. That doesn't > mean > we shouldn't care, but maybe we will have to live with some > limitations. Limited compared to what? The deployment of _MSRP_ is fairly limited. Does anyone have an actively functioning deployment of MSRP that uses firewall traversal techniques other than MSRP relays? > > > We did have some off-line discussions regarding the TLS issue in SFO. > Maybe Ben could say a few words about what was discussed? A summary of what I recall: When an MSRP endpoint uses TLS to connect to a peer, it needs to verify that the certificate presented by the peer does in fact belong to the party it wants to talk to, by making sure the SubjectAltName of the peer certificate matches the host name or IP address in the associated MSRP URI. The proposal we discussed in the work group meeting was designed to allow a middlebox to rewrite the host part of MSRP URIs inside the path attribute in the SDP. If they do this, there are scenarios where the certificate SubjectAltName will no longer match the URI. For example, assume A uses an MSRP Relay, and B uses an SBC, following the discussed proposal. A sends an SDP "path" attribute that looks something like the following. Furthermore, assume the SBC supports TCP media,and transparently relays the TLS handshake. a=path:MSRPS://A/823497w, MSRPS://relay/28g9345ikas But when the SBC changes this to look like a=path:MSRPS://A/823497w, MSRPS://sbc/28g9345ikas. If they actually In the case of two humans communicating over client- class devices, this is not likely to be an issue. B then opens a TCP connection to "sbc", and starts a TLS handshake. It expects to get a certificate matching "sbc". But since the SBC transparently relays the handshake to the MSRP relay, B instead gets a certificate for "relay". B interprets this as a TLS authentication failure. This may not be a problem for some scenarios with no MSRP relays, where the TLS association is peer to peer between the MSRP devices. First, TLS is not likely used in this case, due to client-certificate issues. If it _is_ used, it's probably with self-signed certs and cert fingerprints passed in the SDP. However, if one of the endpoints actually has a certificate bound to its host name or IP address, we still have the problem. For example, assume one of the peers is a MSRP conference server with a conventional server certificate. > > > Regards, > > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Fri Apr 3 13:22:42 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D70E3A6A3E for ; Fri, 3 Apr 2009 13:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 GONhvY3Fczug for ; Fri, 3 Apr 2009 13:22:41 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 48EEC3A69F1 for ; Fri, 3 Apr 2009 13:22:41 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n33KNdbK030942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Apr 2009 15:23:39 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <182F26AF-C31F-44B0-B6E2-170D42BC85ED@estacado.net> From: Ben Campbell To: "Christer Holmberg" 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 v930.3) Date: Fri, 3 Apr 2009 15:23:39 -0500 References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net><49D51C5B.1060702@nostrum.com><49D522C3.1000109@nostrum.com><49D53DFC.6090202@nostrum.com> X-Mailer: Apple Mail (2.930.3) Cc: Adam Roach , Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:22:42 -0000 On Apr 3, 2009, at 4:56 AM, Christer Holmberg wrote: > > Hi, > >> and I think you have plenty of controversy around the c/m changes. > > I am not sure what you mean by plenty of convroversy. > > As far as I know, the issue is regarding interoperability between ACM > and MSRP relay, and how to deal with TLS in that case, but not about > c/m > as such. In my opinion, interoperability is a central (and open) issue for ACM in general. I don't think you can separate the two; controversy over ACM interoperability is still controversy over ACM. > > > But, let's focus on how/if we can solve the TLS issue :) > > Regards, > > Christer > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Fri Apr 3 13:28:57 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A3F3A69F6 for ; Fri, 3 Apr 2009 13:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 194NlZ3fP9DI for ; Fri, 3 Apr 2009 13:28:57 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 7406F3A67FD for ; Fri, 3 Apr 2009 13:28:56 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n33KTt2m031927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Apr 2009 15:29:55 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <30120FDF-AD53-457B-9F6A-E63E276299E6@estacado.net> From: Ben Campbell To: Hadriel Kaplan 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 v930.3) Date: Fri, 3 Apr 2009 15:29:55 -0500 References: <6E3FFD71-C0D3-4007-A6A7-96700CBB3196@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:28:57 -0000 On Apr 2, 2009, at 8:05 PM, Hadriel Kaplan wrote: > > I'm confused. In an earlier email you said "I believe this is a > strong requirement for the C-Line part of the ACM draft to move > forward." And below you're talking about the "COMEDIA provisions". > Which parts of COMEDIA are you referring to - the setup and > connection attributes, or using the c-line for addressing? By "COMEDIA" part, I was referring to the ACM draft section 4.1, which describes the use of the COMEDIA setup attribute in SDP to determine which peer is is the active party for the TCP connection. By "C-Line" part, I was referring to the ACM draft section 4.2, entitled "Transport connection addressing", which describes using the SDP C-line to determine the destination address for the TCP connection. > > > -hadriel > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of Ben Campbell >> Sent: Thursday, April 02, 2009 3:47 PM >> To: Simple WG >> Subject: [Simple] MSRP-ACM: C-line vs COMEDIA >> >> (as an individual) >> >> From the list discussions and the meeting in San Francisco, we seem >> to have consensus around the COMEDIA provisions in the MSRP-ACM >> draft. >> All the controversy has been around the C-line vs path attribute >> changes. >> >> Furthermore, if I understand correctly, the COMEDIA portions and >> the C- >> Line portions are effectively separate extensions, i.e. you can use >> either one without the other. >> >> Does it make sense then to separate them into separate drafts? If we >> did so, we could go ahead and progress the COMEDIA part instead of >> blocking it on the discussions concerning the C-line part. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Fri Apr 3 13:53:33 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2353A6810 for ; Fri, 3 Apr 2009 13:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SVXzpeNNnst for ; Fri, 3 Apr 2009 13:53:32 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 277C13A6358 for ; Fri, 3 Apr 2009 13:53:31 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n33KsUar035829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Apr 2009 15:54:30 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <1F0B52C6-5E47-4093-822E-ACD9717D1AE2@estacado.net> From: Ben Campbell To: Hadriel Kaplan 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 v930.3) Date: Fri, 3 Apr 2009 15:54:30 -0500 References: X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] MSRP ACM and TLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:53:33 -0000 On Apr 2, 2009, at 10:07 PM, Hadriel Kaplan wrote: > [This email is just thinking out loud to try to understand the issue > - no matter what we'll need to get some guidance from a security > expert (ekr?)] > > The subject has been raised that an ACM model impacts the ability to > do TLS using the SAN (subjectAltName) of a public server host. I > believe this was based on the idea that ACM would let a middlebox > not only change the c/m lines, but in fact have it replace the host > portion of the top path attribute, right? In such a case, the > original host portion would be lost. That was the proposal in the room in SF. It's not yet in the ACM draft. > > > If I understand the model 4975/4976 had in mind, as a UA when you're > given an MSRPS URI to use, you connect using TLS and verify the SAN > of the far-end matches the hostname portion of the MSRPS URI you > were given in SDP. When you offer a MSRPS URI, the hostname you put > in the URI must likewise match the SAN in your cert. As a Relay, > when you're told to send an MSRP message to a MSRPS URI next-hop, > you do a similar matching check to that next-hop, etc. > > What's not clear to me is what actual security binding property is > achieved. For example, if I send a SIP Invite to > sip:bob@biloxi.com, and the SDP answer has an MSRPS URI of "msrps:// > foobar.com:1234/pwned4ever", then does verifying that my MSRP > connection to foobar.com really is to foobar.com mean anything? Is > there some language in the RFC's that say the SIP target AoR's > domain has to match the SAN as well? (I can't find it) Sans that > (ooh, a pun), then you're already believing the SIP layer isn't > lying to you - because anyone can just make a box be a b2bua-sip + > b2bua-msrp and give you a cert with a SAN of whatever, so long as > the MSRPS URI matches it and you have a common CA. (yes it would > have to be a cert with a common CA, but all the common CA says is > "that sure is foobar.com", though at least then you'd have non- > reputable record of it) MSRP security is very much based on the assumption that the signaling path is secure. This is discussed in the applicability statement in section 3. So in your example, you know that foobar.com is the right party because the signaling channel told you it was. > > > Another good property is your UA client can show you that it's > foobar.com, or prompt you for confirmation that's ok. And that's a > good property to have. You don't actually need the msrps URI to > match anything to do that, of course. But it's good to have a match > solely because at least it keeps just any old MITM from intercepting > MSRP connections - it would have to be more than just a snooper, it > would have to be a malicious SIP and MSRP MITM. > > So, in summary, I think the property we'd like to keep is that if > the SDP layer said foobar.com, that the MSRP layer really connects > to foobar.com, whatever that may or may not imply. With ACM, if > foobar.com is not left in the path attribute, that can't be achieved > without some other means. I agree that the best we can hope for is that we really connect to the device listed in the SDP. > > > The options as I see them are: > 1) Use the fingerprint attribute, even for public SANs. A server > with a real SAN can create a fingerprint just as any, and send that > in its SDP. The problem with that is a 4976bis-Relay can't be asked > for its fingerprint, nor be told to check one against a next-hop, > afaict, without some real changes. (right?) That's really an issue > with using fingerprints period with Relays. If we were to add such > support for Relays, however, it would provide the ability to connect > to self-signed certs on UA's in general, even without ACM. That's interesting. As you say, it would require some non-trivial changes to RFC 4976. I agree this sort of thing would need careful security review. (Elephant in room: We're still arguing over whether middleboxes can meddle with SDP payloads in the other working groups. Until that is resolved, we can't even really trust the fingerprints.) > > 2) Do ACM differently to begin with - for example by having > middleboxes insert (instead of modify) a path attribute which has > the same cookie portion, but with a URI param that means something > like "for the TCP connection but not for the to/from-path URI". > That way the original ones are left intact and used for cert > matching, while the inserted one is used for connection ip/port. > That would still require changes on Relays, but a smaller change I > guess. Would that work? I think it would require non-trivial changes to both RFC 4975 and 4976. (I think it would be cleaner to find a way to markup a single URI to carry both addressing and cert matching data, so a device doesn't have to guess which URI is for which purpose. But it is the same thing in principle.) I have not yet formed an opinion as to whether that level of change is reasonable. But if we did go that route, I wonder if this would not have architectural implications at a greater-than-just-MSRP scope. > > > -hadriel > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Fri Apr 3 13:58:28 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D903A6A90 for ; Fri, 3 Apr 2009 13:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 uXx20c6ZtJwg for ; Fri, 3 Apr 2009 13:58:27 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 0E0393A6358 for ; Fri, 3 Apr 2009 13:58:26 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n33KxPSY036574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Apr 2009 15:59:25 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: "Christer Holmberg" 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 v930.3) Date: Fri, 3 Apr 2009 15:59:25 -0500 References: <200904031016.08922.remi.denis-courmont@nokia.com> X-Mailer: Apple Mail (2.930.3) Cc: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , simple@ietf.org Subject: Re: [Simple] MSRP ACM and TLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:58:28 -0000 On Apr 3, 2009, at 5:07 AM, Christer Holmberg wrote: > > Hi, > >>> [This email is just thinking out loud to try to understand the >>> issue - >>> no matter what we'll need to get some guidance from a security >>> expert >>> (ekr?)] >> >> As was noted in my earlier & defunct COMEDIA-MSRP draft, >> COMEDIA-TLS can anyway not work, at least not end-to-end >> through a SBC. >> >> COMEDIA-TLS ties the direction of TLS to the direction of >> TCP. Practically, he who sends the TCP/SYN sends the >> TLS/ClientHello, and he who sends the TCP/SYN- ACK sends the >> TLS/ServerHello. In my understanding, with an SBC in the >> middle, both endpoints are COMEDIA "active", meaning they >> both sends TCP/SYN, and both sends ClientHello. *caboom* > > True. And, if both endpoints are "active" you of course may > (depending on the TCP stacks in the endpoints) have an end-to-end > issue even without TLS, for any protocol which uses TCP. > > To deal with this, SBCs sometimes act as TCP B2BUAs, and in the TLS > case the SBC would act as a TLS B2BUA (which it may have to do > anyway, depending on what functions it performs). Note that the TLS name matching issue (which I attempted to describe in a separate email), should not be a problem if the SBC actively terminates TLS for both legs, assuming that the rewritten URIs match the certificates the SBC presents in each direction. There is a risk, though, of giving endpoints a good-faith belief that they have achieved an end-to-end TLS association when they have in fact not done so. > > > Many SBCs (not only Hadriel's :) already support this, since it is > not MSRP specific. > > Regards, > > Christer > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Fri Apr 3 14:36:05 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7713A69AE for ; Fri, 3 Apr 2009 14:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.557 X-Spam-Level: X-Spam-Status: No, score=-5.557 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=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 4XYNoQ0aPeUK for ; Fri, 3 Apr 2009 14:36:04 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EDF553A6810 for ; Fri, 3 Apr 2009 14:36:03 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C921D2005D; Fri, 3 Apr 2009 23:37:05 +0200 (CEST) X-AuditID: c1b4fb3e-ab01dbb0000024d5-0d-49d681812aa6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9EEF320006; Fri, 3 Apr 2009 23:37:05 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 23:37:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 23:30:16 +0200 Message-ID: In-Reply-To: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm0mVjBXJYzTpVkTlaE6B1N1hRO+QABrDMg References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <49D520D4.3090603@nostrum.com> <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 03 Apr 2009 21:37:05.0499 (UTC) FILETIME=[5544FAB0:01C9B4A4] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 21:36:05 -0000 Hi,=20 >>>> 1) Is there a requirement for an endpoint that uses the C-line=20 >>>> addressing mechanism in the MSRP-ACM draft to be able to talk to an >>>> endpoint that uses an MSRP relay (RFC 4976). >>> >>> >>> Yes. >>> >>> Unless we're going to fully deprecate relays, I think this is a hard >>> requirement -- otherwise, you're effectively >>> defining two mutually incompatible MSRP "profiles." That is not the >>> recipe for protocol interoperation. >> >> I think most of us agree that the deployments of relays is relatively >> limited, so we need to keep that in mind when discussing something=20 >> which I strongly believe is going to be much more deployed. That=20 >> doesn't mean we shouldn't care, but maybe we will have to live with=20 >> some limitations. > >Limited compared to what? The deployment of _MSRP_ is fairly limited. =20 >Does anyone have an actively functioning deployment of MSRP that uses firewall traversal techniques other than MSRP=20 >relays? OMA has their own profile of MSRP, which in fact is similar to ACM (however, our intention has been to suggest that OMA adopts ACM, when/if it's done). But, apart from OMA I don't think there are many MSRP deployments using firewall traversal techniques in the first place - no matter what technique is used. The main reason is that people don't want to have MSRP specific solutions. They want to use solutions that they use for other types of media - which ACM is all about. I strongly (based on requests and feedback I've received) believe that ACM would increase MSRP deployments also in networks with SBCs etc, and there are quite a few of those networks :) Regards, Christer > > > We did have some off-line discussions regarding the TLS issue in SFO. > Maybe Ben could say a few words about what was discussed? A summary of what I recall: When an MSRP endpoint uses TLS to connect to a peer, it needs to =20 verify that the certificate presented by the peer does in fact belong =20 to the party it wants to talk to, by making sure the SubjectAltName of =20 the peer certificate matches the host name or IP address in the =20 associated MSRP URI. The proposal we discussed in the work group =20 meeting was designed to allow a middlebox to rewrite the host part of =20 MSRP URIs inside the path attribute in the SDP. If they do this, =20 there are scenarios where the certificate SubjectAltName will no =20 longer match the URI. For example, assume A uses an MSRP Relay, and B uses an SBC, following =20 the discussed proposal. A sends an SDP "path" attribute that looks =20 something like the following. Furthermore, assume the SBC supports TCP =20 media,and transparently relays the TLS handshake. a=3Dpath:MSRPS://A/823497w, MSRPS://relay/28g9345ikas But when the SBC changes this to look like a=3Dpath:MSRPS://A/823497w, MSRPS://sbc/28g9345ikas. If they actually In the case of two humans communicating over client-=20 class devices, this is not likely to be an issue. B then opens a TCP connection to "sbc", and starts a TLS handshake. It =20 expects to get a certificate matching "sbc". But since the SBC =20 transparently relays the handshake to the MSRP relay, B instead gets a =20 certificate for "relay". B interprets this as a TLS authentication =20 failure. This may not be a problem for some scenarios with no MSRP relays, =20 where the TLS association is peer to peer between the MSRP devices. =20 First, TLS is not likely used in this case, due to client-certificate =20 issues. If it _is_ used, it's probably with self-signed certs and cert =20 fingerprints passed in the SDP. However, if one of the endpoints =20 actually has a certificate bound to its host name or IP address, we =20 still have the problem. For example, assume one of the peers is a MSRP =20 conference server with a conventional server certificate. > > > Regards, > > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Fri Apr 3 14:40:06 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7053A6B2F for ; Fri, 3 Apr 2009 14:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 g1dZ5ONsMimR for ; Fri, 3 Apr 2009 14:40:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 938583A6A99 for ; Fri, 3 Apr 2009 14:40:05 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7646C208CA; Fri, 3 Apr 2009 23:41:07 +0200 (CEST) X-AuditID: c1b4fb3c-a7ee1bb000003b08-26-49d682736dfc Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 41F8820628; Fri, 3 Apr 2009 23:41:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 23:41:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 23:41:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP ACM and TLS Thread-Index: Acm0nxP3FRv4ap+/RL6D8TST3Ef1PgABFkwg References: <200904031016.08922.remi.denis-courmont@nokia.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 03 Apr 2009 21:41:06.0618 (UTC) FILETIME=[E4FCD1A0:01C9B4A4] X-Brightmail-Tracker: AAAAAA== Cc: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , simple@ietf.org Subject: Re: [Simple] MSRP ACM and TLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 21:40:06 -0000 Hi,=20 >>>> [This email is just thinking out loud to try to understand the = issue=20 >>>> - no matter what we'll need to get some guidance from a security=20 >>>> expert (ekr?)] >>> >>> As was noted in my earlier & defunct COMEDIA-MSRP draft, COMEDIA-TLS = >>> can anyway not work, at least not end-to-end through a SBC. >>> >>> COMEDIA-TLS ties the direction of TLS to the direction of TCP.=20 >>> Practically, he who sends the TCP/SYN sends the TLS/ClientHello, and = >>> he who sends the TCP/SYN- ACK sends the TLS/ServerHello. In my=20 >>> understanding, with an SBC in the middle, both endpoints are COMEDIA = >>> "active", meaning they both sends TCP/SYN, and both sends=20 >>> ClientHello. *caboom* >> >> True. And, if both endpoints are "active" you of course may = (depending=20 >> on the TCP stacks in the endpoints) have an end-to-end issue even=20 >> without TLS, for any protocol which uses TCP. >> >> To deal with this, SBCs sometimes act as TCP B2BUAs, and in the TLS=20 >> case the SBC would act as a TLS B2BUA (which it may have to do = anyway,=20 >> depending on what functions it performs). > >Note that the TLS name matching issue (which I attempted to describe in = a separate email), should not be a problem if the=20 >SBC actively terminates TLS for both legs, assuming that the rewritten = URIs match =20 >the certificates the SBC presents in each direction. Correct. And based on Remii's e-mail I think we can assume that will = happen quite often. >There is a risk, though, of giving endpoints a good-faith belief that = they have achieved an end-to-end TLS association=20 >when they have in fact not done so. I think that is the reality, and it is not specific to MSRP. People will = have to trust the intermediates.=20 Because, couldn't the endpoints have that good-faith belief even for the = SIP signalling, for which you won't have an end-to-end TLS association = either? Regards, Christer From christer.holmberg@ericsson.com Fri Apr 3 16:02:10 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C1B3A6A6D for ; Fri, 3 Apr 2009 16:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORTL0Xe0DAzZ for ; Fri, 3 Apr 2009 16:02:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 29B093A6912 for ; Fri, 3 Apr 2009 16:02:09 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1209C201CB; Sat, 4 Apr 2009 01:03:11 +0200 (CEST) X-AuditID: c1b4fb3e-ae824bb0000024d5-f6-49d695aea562 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D59502011C; Sat, 4 Apr 2009 01:03:10 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Apr 2009 01:03:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Apr 2009 00:54:13 +0200 Message-ID: In-Reply-To: <1F0B52C6-5E47-4093-822E-ACD9717D1AE2@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP ACM and TLS Thread-Index: Acm0nmnMIN3RlqtUTcC4QYeMGi+WkgADcEvg References: <1F0B52C6-5E47-4093-822E-ACD9717D1AE2@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" , "Hadriel Kaplan" X-OriginalArrivalTime: 03 Apr 2009 23:03:10.0719 (UTC) FILETIME=[5BFB00F0:01C9B4B0] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] MSRP ACM and TLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 23:02:10 -0000 Hi,=20 >> [This email is just thinking out loud to try to understand the issue >> - no matter what we'll need to get some guidance from a security=20 >> expert (ekr?)] >> >> The subject has been raised that an ACM model impacts the ability to=20 >> do TLS using the SAN (subjectAltName) of a public server host. I=20 >> believe this was based on the idea that ACM would let a middlebox not >> only change the c/m lines, but in fact have it replace the host=20 >> portion of the top path attribute, right? In such a case, the=20 >> original host portion would be lost. > >That was the proposal in the room in SF. It's not yet in the ACM draft. It would need to be added. And, even without TLS, that is needed in order to make the propsed session mapping change in 4975 to work. >>If I understand the model 4975/4976 had in mind, as a UA when you're=20 >>given an MSRPS URI to use, you connect using TLS and verify the SAN of >>the far-end matches the hostname portion of the MSRPS URI you were=20 >>given in SDP. When you offer a MSRPS URI, the hostname you put in the >>URI must likewise match the SAN in your cert. As a Relay, when you're >>told to send an MSRP message to a MSRPS URI next-hop, you do a similar >>matching check to that next-hop, etc. >> >>What's not clear to me is what actual security binding property is=20 >>achieved. For example, if I send a SIP Invite to sip:bob@biloxi.com,=20 >>and the SDP answer has an MSRPS URI of "msrps://=20 >>foobar.com:1234/pwned4ever", then does verifying that my MSRP=20 >>connection to foobar.com really is to foobar.com mean anything? Is=20 >>there some language in the RFC's that say the SIP target AoR's domain=20 >>has to match the SAN as well? (I can't find it) Sans that (ooh, a=20 >>pun), then you're already believing the SIP layer isn't lying to you - >>because anyone can just make a box be a b2bua-sip + b2bua-msrp and=20 >>give you a cert with a SAN of whatever, so long as the MSRPS URI=20 >>matches it and you have a common CA. (yes it would have to be a cert=20 >>with a common CA, but all the common CA says is "that sure is=20 >>foobar.com", though at least then you'd have non- reputable record of=20 >>it) > > >MSRP security is very much based on the assumption that the signaling path is secure. This is discussed in the=20 >applicability statement in section 3. So in your example, you know that foobar.com is the right party because the=20 >signaling channel told you it was. I guess that "Signaling path is secure" would also assume that any possible intermediate in the signalling path is trusted? >>Another good property is your UA client can show you that it's=20 >>foobar.com, or prompt you for confirmation that's ok. And that's a=20 >>good property to have. You don't actually need the msrps URI to match >>anything to do that, of course. But it's good to have a match solely=20 >>because at least it keeps just any old MITM from intercepting MSRP=20 >>connections - it would have to be more than just a snooper, it would=20 >>have to be a malicious SIP and MSRP MITM. >> >>So, in summary, I think the property we'd like to keep is that if the=20 >>SDP layer said foobar.com, that the MSRP layer really connects to=20 >>foobar.com, whatever that may or may not imply. With ACM, if=20 >>foobar.com is not left in the path attribute, that can't be achieved=20 >>without some other means. > >I agree that the best we can hope for is that we really connect to the device listed in the SDP. > >>The options as I see them are: >>1) Use the fingerprint attribute, even for public SANs. A server =20 >>with a real SAN can create a fingerprint just as any, and send that =20 >>in its SDP. The problem with that is a 4976bis-Relay can't be asked =20 >>for its fingerprint, nor be told to check one against a next-hop, =20 >>afaict, without some real changes. (right?) That's really an issue =20 >>with using fingerprints period with Relays. If we were to add such =20 >>support for Relays, however, it would provide the ability to connect =20 >>to self-signed certs on UA's in general, even without ACM. > >That's interesting. As you say, it would require some non-trivial =20 >changes to RFC 4976. I agree this sort of thing would need careful =20 >security review. > >(Elephant in room: We're still arguing over whether middleboxes can =20 >meddle with SDP payloads in the other working groups. Until that is =20 >resolved, we can't even really trust the fingerprints.) > >>2) Do ACM differently to begin with - for example by having =20 >>middleboxes insert (instead of modify) a path attribute which has =20 >>the same cookie portion, but with a URI param that means something =20 >>like "for the TCP connection but not for the to/from-path URI". =20 >>That way the original ones are left intact and used for cert =20 >>matching, while the inserted one is used for connection ip/port. =20 >>That would still require changes on Relays, but a smaller change I =20 >>guess. Would that work? > >I think it would require non-trivial changes to both RFC 4975 and =20 >4976. (I think it would be cleaner to find a way to markup a single =20 >URI to carry both addressing and cert matching data, so a device =20 >doesn't have to guess which URI is for which purpose. But it is the =20 >same thing in principle.) I think I proposed something similar at one point. But, a 4975 endpoint would of course have to understand the new markup. Regards, Christer >I have not yet formed an opinion as to whether that level of change is >reasonable. But if we did go that route, I wonder if this would not =20 >have architectural implications at a greater-than-just-MSRP scope. From HKaplan@acmepacket.com Fri Apr 3 21:51:07 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901CC3A687F for ; Fri, 3 Apr 2009 21:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP-EqknT3kwd for ; Fri, 3 Apr 2009 21:51:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AD9AF3A685E for ; Fri, 3 Apr 2009 21:51:06 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 4 Apr 2009 00:52:09 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 4 Apr 2009 00:52:06 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "simple@ietf.org" Date: Sat, 4 Apr 2009 00:51:59 -0400 Thread-Topic: [Simple] MSRP ACM and TLS Thread-Index: Acm0LCoJLd4yV3fwTt24ExIIMHEqPAAsTTxw Message-ID: References: <200904031016.08922.remi.denis-courmont@nokia.com> In-Reply-To: <200904031016.08922.remi.denis-courmont@nokia.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 Subject: Re: [Simple] MSRP ACM and TLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 04:51:07 -0000 > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] > Sent: Friday, April 03, 2009 3:16 AM >=20 > COMEDIA-TLS ties the direction of TLS to the direction of TCP. > Practically, he > who sends the TCP/SYN sends the TLS/ClientHello, and he who sends the > TCP/SYN- > ACK sends the TLS/ServerHello. In my understanding, with an SBC in the > middle, > both endpoints are COMEDIA "active", meaning they both sends TCP/SYN, and > both > sends ClientHello. *caboom* Good point. It seems to work right now, but that's with the SBC not settin= g both to active - the use cases of comedia-TLS we see in use right now are= mostly BFCP, afaict, and the SBC has an unencumbered path to the conferenc= e server. (the server is in a private network, but the SBC has an interface= in that private network, effectively bypassing one NAT side) So it's just= setting the direction such that the endpoint is always establishing the TC= P connection to the SBC, which relays it to the conference server which has= the cert. I don't think I've ever seen endpoint-NAT-SBC-NAT-endpoint by TCP-splicing = using comedia-TLS, because the endpoints don't seem to have certs (even sel= f-signed ones). How was TLS going to be done end-to-end with TURN-tcp? -hadriel From HKaplan@acmepacket.com Fri Apr 3 23:07:56 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88A13A6768 for ; Fri, 3 Apr 2009 23:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOqqWGRi4LXp for ; Fri, 3 Apr 2009 23:07:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E56E43A67DD for ; Fri, 3 Apr 2009 23:07:55 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 4 Apr 2009 02:08:57 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 4 Apr 2009 02:08:56 -0400 From: Hadriel Kaplan To: Christer Holmberg , Ben Campbell Date: Sat, 4 Apr 2009 02:08:56 -0400 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm0mVjBXJYzTpVkTlaE6B1N1hRO+QABrDMgABBi5TA= Message-ID: References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <49D520D4.3090603@nostrum.com> <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> 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 Cc: Adam Roach , Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 06:07:56 -0000 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Christer Holmberg >=20 > OMA has their own profile of MSRP, which in fact is similar to ACM > (however, our intention has been to suggest that OMA adopts ACM, when/if > it's done). > But, apart from OMA I don't think there are many MSRP deployments using > firewall traversal techniques in the first place - no matter what > technique is used. The main reason is that people don't want to have > MSRP specific solutions. They want to use solutions that they use for > other types of media - which ACM is all about. > I strongly (based on requests and feedback I've received) believe that > ACM would increase MSRP deployments also in networks with SBCs etc, and > there are quite a few of those networks :) I don't track the market of it myself, but personally I find that a big dri= ver for MSRP is coming from the 3GPP/IMS-type of cases, and I count OMA as = being one in that line. I believe it's being marketed under the "Rich Comm= unication Suite" initiative. I don't see MSRP being asked for much by anyone else for IM/file-transfer/v= ideo-share, because afaict, with few notable exceptions, most others use XM= PP if they use a standard protocol to begin with. (and I believe XMPP tries= to use SOCKS for file transfer relay, before falling back to XMPP app-laye= r relay) -hadriel From hisham.khartabil@gmail.com Sun Apr 5 22:26:52 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F023A6BBD for ; Sun, 5 Apr 2009 22:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRZY4n9btwla for ; Sun, 5 Apr 2009 22:26:52 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 5C4043A6B42 for ; Sun, 5 Apr 2009 22:26:46 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so2807277ywh.49 for ; Sun, 05 Apr 2009 22:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=zy5/p2DKk9ZOluBFT3baSvpouKGfMX7qU+GwpY7L1Cw=; b=fJQoTqbK/Ey5hKvGOLdUiiFhzvxO714BNvlj9PEHsekAJ1UifgkAIHtfju/CQ3iX5h CJbGTyYADFNYLsjUyt6kgB+BUXSv2300iLqY02ookJX3driAeko2m7OGj7ewowzhZaMh HTxB6a3yglkH84CkiZgl6gHoDrw4rb6kwT2uQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=bYl//nlppDCUtBna44dnA1HXpRYCAniDRkwe1bMjsc6QrV+yD35RF1fQfDR2ZuW/09 tY9tvcnTvBiN06yAcx4qbX3Aukb/MrHA+p3nxVm49Hx10BAq3DStt29FsWPb2/sn/JFu 9vyXOnbmKVXEvQZyZCcV3PuRz6RR8V3BB+TRo= MIME-Version: 1.0 Received: by 10.150.229.5 with SMTP id b5mr7712367ybh.130.1238995671704; Sun, 05 Apr 2009 22:27:51 -0700 (PDT) Date: Mon, 6 Apr 2009 15:27:51 +1000 Message-ID: <66cd252f0904052227o32a1513an4e4d55f7b29173c6@mail.gmail.com> From: Hisham Khartabil To: Simple WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Simple] WGLC for draft-ietf-simple-chat-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 05:26:52 -0000 This is to initiate a working group last call (WGLC) for Multi-party Chat Using MSRP draft (draft-ietf-simple-chat-04). http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-04.txt This is a 3 week WGLC instead of the usual 2 to accommodate for the long Easter weekend. Please send your comments to the SIMPLE mailing list as well as the authors. Please also let the authors, WG chairs and group know if you have read the draft and believe there are no issues with it. Minor nits are also important to fix and welcome. Much appreciated, Hisham From Remi.Denis-Courmont@nokia.com Sun Apr 5 23:30:49 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B35F3A68D2 for ; Sun, 5 Apr 2009 23:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 eCANXbDcG4Bi for ; Sun, 5 Apr 2009 23:30:48 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7A64B3A6846 for ; Sun, 5 Apr 2009 23:30:48 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n366VHBD025256 for ; Mon, 6 Apr 2009 09:31:49 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 09:31:40 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 09:31:36 +0300 Received: from leon.remlab.net (esdhcp043152.research.nokia.com [172.21.43.152]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n366VY5Z000530 for ; Mon, 6 Apr 2009 09:31:34 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: simple@ietf.org Date: Mon, 6 Apr 2009 09:31:43 +0300 User-Agent: KMail/1.11.0 (Linux/2.6.28.9; KDE/4.2.0; i686; ; ) References: <200904031016.08922.remi.denis-courmont@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904060931.44461.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 06 Apr 2009 06:31:37.0017 (UTC) FILETIME=[5635C290:01C9B681] X-Nokia-AV: Clean Subject: Re: [Simple] MSRP ACM and TLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 06:30:49 -0000 On Saturday 04 April 2009 07:51:59 ext Hadriel Kaplan wrote: > I don't think I've ever seen endpoint-NAT-SBC-NAT-endpoint by TCP-splicing > using comedia-TLS, because the endpoints don't seem to have certs (even > self-signed ones). > How was TLS going to be done end-to-end with TURN-tcp? My understanding is that normal COMEDIA negotiation takes place then, since= =20 the TURN server can provide a virtual listening socket to the TURN client. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From jon.peterson@neustar.biz Mon Apr 6 16:54:58 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458AC3A6C8C for ; Mon, 6 Apr 2009 16:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtEbsHELJ7Zh for ; Mon, 6 Apr 2009 16:54:50 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 5CAFB3A6D40 for ; Mon, 6 Apr 2009 16:54:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239062142; x=1239148542; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=Yy2+vv90qv6KZ8spIylMdGR7kp83PuWc1zQ0wA8luNpcyT9eLOdkHxs916K3ROhbVDPugE2M42zg+x U9Peh76Q== Received: from ([10.31.13.50]) by chihiron1.nc.neustar.com with ESMTP id 5202942.14962565; Mon, 06 Apr 2009 19:55:29 -0400 Received: from 10.31.13.138 ([10.31.13.138]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Apr 2009 23:55:28 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 06 Apr 2009 16:55:28 -0700 From: Jon Peterson To: Ben Campbell , Christer Holmberg Message-ID: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3Eykv0QDIicli2EaspoGXdu08cw== In-Reply-To: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Adam Roach , Simpletons Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 23:54:58 -0000 I think what's missing in the discussion of the TLS component of MSRP-ACM is a glance back at 9.3 of RFC4976 - that is, a question of what we're hoping to prevent with TLS in this case. TLS serves a number of purposes in the MSRP relay architecture, but the salient one here is to allow the client the opportunity to authenticate the next hop to which its traffic will not be confidential. The mandate of TLS usage by MSRP relays is supposed to ensure message confidentiality to the hop identified by the MSRPS URI. There's no point in keeping something encrypted on the wire only to hand it over to someone you can't identify - why bother to have kept it confidential at all? Even setting aside my predictable objections to a Standards Track document endorsing SBCs modifying the c, m and a= lines of SDP in SIP messages, I would be cautious about the approach under discussion. From the perspective of the client on the side with the SBC, when it sees an MSRPS URI in the path it locks in that hostname as the one it is trying to reach, and if a certificate with some other hostname is presented when it contacts that host, it should certainly view this as a security failure. That client really has no way to know what relay is supposed to be trusted unless the path attribute in SDP tells it so. Again, if you don't know who you're supposed to reveal the messages to, then you're forced to reveal it just anyone who presents a cert, and if you're revealing it to just anyone, in what sense is it confidential and why are you bothering to use TLS at all? Furthermore, into the details of the proposal a bit, I think I understand what you do when the offerer has a relay and the answerer has an SBC, and the SBC needs to modify the offerer's c/m and a=path:, but I'm a bit hazier on how you modify the answerer's SDP in this case in such a way that the offerer's relay will send MSRP to the SBC on it's way to the client. What does that case look like? Incidentally, the comedia stuff in the MRSP-ACM draft seems fine, and I'd have no problem with that going forward independently. Jon Peterson NeuStar, Inc. On 4/3/09 1:18 PM, "Ben Campbell" wrote: [snip] > A summary of what I recall: > > When an MSRP endpoint uses TLS to connect to a peer, it needs to > verify that the certificate presented by the peer does in fact belong > to the party it wants to talk to, by making sure the SubjectAltName of > the peer certificate matches the host name or IP address in the > associated MSRP URI. The proposal we discussed in the work group > meeting was designed to allow a middlebox to rewrite the host part of > MSRP URIs inside the path attribute in the SDP. If they do this, > there are scenarios where the certificate SubjectAltName will no > longer match the URI. > > For example, assume A uses an MSRP Relay, and B uses an SBC, following > the discussed proposal. A sends an SDP "path" attribute that looks > something like the following. Furthermore, assume the SBC supports TCP > media,and transparently relays the TLS handshake. > > a=path:MSRPS://A/823497w, MSRPS://relay/28g9345ikas > > But when the SBC changes this to look like > > a=path:MSRPS://A/823497w, MSRPS://sbc/28g9345ikas. > > > If they actually In the case of two humans communicating over client- > class devices, this is not likely to be an issue. > > B then opens a TCP connection to "sbc", and starts a TLS handshake. It > expects to get a certificate matching "sbc". But since the SBC > transparently relays the handshake to the MSRP relay, B instead gets a > certificate for "relay". B interprets this as a TLS authentication > failure. > > This may not be a problem for some scenarios with no MSRP relays, > where the TLS association is peer to peer between the MSRP devices. > First, TLS is not likely used in this case, due to client-certificate > issues. If it _is_ used, it's probably with self-signed certs and cert > fingerprints passed in the SDP. However, if one of the endpoints > actually has a certificate bound to its host name or IP address, we > still have the problem. For example, assume one of the peers is a MSRP > conference server with a conventional server certificate. > > From ben@estacado.net Mon Apr 6 18:18:06 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9293A6BCB for ; Mon, 6 Apr 2009 18:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnIeuix+afPZ for ; Mon, 6 Apr 2009 18:18:05 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 6227E3A6B92 for ; Mon, 6 Apr 2009 18:18:05 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n371J1vU027270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Apr 2009 20:19:05 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <395A9F15-91A5-4322-8672-B78EA7D28E84@estacado.net> From: Ben Campbell To: Jon Peterson 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 v930.3) Date: Mon, 6 Apr 2009 20:19:00 -0500 References: X-Mailer: Apple Mail (2.930.3) Cc: Adam Roach , Simpletons Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 01:18:06 -0000 This is an excellent summary of the concerns that, with considerably less eloquence, I have been trying to express. Thanks! Ben. On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: > > I think what's missing in the discussion of the TLS component of > MSRP-ACM is > a glance back at 9.3 of RFC4976 - that is, a question of what we're > hoping > to prevent with TLS in this case. TLS serves a number of purposes in > the > MSRP relay architecture, but the salient one here is to allow the > client the > opportunity to authenticate the next hop to which its traffic will > not be > confidential. The mandate of TLS usage by MSRP relays is supposed to > ensure > message confidentiality to the hop identified by the MSRPS URI. > There's no > point in keeping something encrypted on the wire only to hand it > over to > someone you can't identify - why bother to have kept it confidential > at all? > > Even setting aside my predictable objections to a Standards Track > document > endorsing SBCs modifying the c, m and a= lines of SDP in SIP > messages, I > would be cautious about the approach under discussion. From the > perspective > of the client on the side with the SBC, when it sees an MSRPS URI in > the > path it locks in that hostname as the one it is trying to reach, and > if a > certificate with some other hostname is presented when it contacts > that > host, it should certainly view this as a security failure. That client > really has no way to know what relay is supposed to be trusted > unless the > path attribute in SDP tells it so. Again, if you don't know who you're > supposed to reveal the messages to, then you're forced to reveal it > just > anyone who presents a cert, and if you're revealing it to just > anyone, in > what sense is it confidential and why are you bothering to use TLS > at all? > > Furthermore, into the details of the proposal a bit, I think I > understand > what you do when the offerer has a relay and the answerer has an > SBC, and > the SBC needs to modify the offerer's c/m and a=path:, but I'm a bit > hazier > on how you modify the answerer's SDP in this case in such a way that > the > offerer's relay will send MSRP to the SBC on it's way to the client. > What > does that case look like? > > Incidentally, the comedia stuff in the MRSP-ACM draft seems fine, > and I'd > have no problem with that going forward independently. > > Jon Peterson > NeuStar, Inc. > > On 4/3/09 1:18 PM, "Ben Campbell" wrote: > [snip] >> A summary of what I recall: >> >> When an MSRP endpoint uses TLS to connect to a peer, it needs to >> verify that the certificate presented by the peer does in fact belong >> to the party it wants to talk to, by making sure the SubjectAltName >> of >> the peer certificate matches the host name or IP address in the >> associated MSRP URI. The proposal we discussed in the work group >> meeting was designed to allow a middlebox to rewrite the host part of >> MSRP URIs inside the path attribute in the SDP. If they do this, >> there are scenarios where the certificate SubjectAltName will no >> longer match the URI. >> >> For example, assume A uses an MSRP Relay, and B uses an SBC, >> following >> the discussed proposal. A sends an SDP "path" attribute that looks >> something like the following. Furthermore, assume the SBC supports >> TCP >> media,and transparently relays the TLS handshake. >> >> a=path:MSRPS://A/823497w, MSRPS://relay/28g9345ikas >> >> But when the SBC changes this to look like >> >> a=path:MSRPS://A/823497w, MSRPS://sbc/28g9345ikas. >> >> >> If they actually In the case of two humans communicating over client- >> class devices, this is not likely to be an issue. >> >> B then opens a TCP connection to "sbc", and starts a TLS handshake. >> It >> expects to get a certificate matching "sbc". But since the SBC >> transparently relays the handshake to the MSRP relay, B instead >> gets a >> certificate for "relay". B interprets this as a TLS authentication >> failure. >> >> This may not be a problem for some scenarios with no MSRP relays, >> where the TLS association is peer to peer between the MSRP devices. >> First, TLS is not likely used in this case, due to client-certificate >> issues. If it _is_ used, it's probably with self-signed certs and >> cert >> fingerprints passed in the SDP. However, if one of the endpoints >> actually has a certificate bound to its host name or IP address, we >> still have the problem. For example, assume one of the peers is a >> MSRP >> conference server with a conventional server certificate. >> >> > From ben@estacado.net Mon Apr 6 18:28:35 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1DC73A6883 for ; Mon, 6 Apr 2009 18:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 LDnFE4QeUaQx for ; Mon, 6 Apr 2009 18:28:35 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 858853A6452 for ; Mon, 6 Apr 2009 18:28:34 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n371TW0f028959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Apr 2009 20:29:36 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> From: Ben Campbell To: Jon Peterson 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 v930.3) Date: Mon, 6 Apr 2009 20:29:31 -0500 References: X-Mailer: Apple Mail (2.930.3) Cc: Adam Roach , Simpletons Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 01:28:35 -0000 On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: > Even setting aside my predictable objections to a Standards Track > document > endorsing SBCs modifying the c, m and a= lines of SDP in SIP > messages, I > would be cautious about the approach under discussion. John's comment above inspired me to put words to another concern that has been bothering me. Nothing in the ACM draft says that an SBC or ALG SHOULD modify anything. But, the ACM draft (excepting the COMEDIA part) solves no problem unless they do so. Or maybe that should be rephrased, the draft not solve anything on it's own, but enable SBCs and ALGs to solve the problem. However, SBCs and ALGs are not very predictable in their behavior. There's not much in the way of standards there. I do not dispute Hadriel that this may work with his company's SBCs--but I have no reason to believe it will work with someone else's. Without some BEHAVE like effort to at least categorize and suggest best practices for these sorts of behaviors, I am skeptical of any standards effort to modify protocols to work around them. From KHBJ46@motorola.com Mon Apr 6 21:55:13 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BE83A6810 for ; Mon, 6 Apr 2009 21:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.604, 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 TF+zGlz1hYG5 for ; Mon, 6 Apr 2009 21:55:12 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 9DDA63A680A for ; Mon, 6 Apr 2009 21:55:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: KHBJ46@motorola.com X-Msg-Ref: server-15.tower-55.messagelabs.com!1239080174!89416990!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13672 invoked from network); 7 Apr 2009 04:56:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Apr 2009 04:56:15 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n374uENW027295 for ; Mon, 6 Apr 2009 21:56:14 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n374uEjC022308 for ; Mon, 6 Apr 2009 23:56:14 -0500 (CDT) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n374uCEe022290 for ; Mon, 6 Apr 2009 23:56:13 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 12:55:50 +0800 Message-ID: <7FAD6FCE52421841A11B441DEF3A88CA0216C597@ZMY16EXM70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please Help!!! Thread-Index: Acmi2eeSM/RClhFdTdO7RC4spOx+oQAL88fwA7i83eAABESt4AFP0M7w From: "Deka Sanjeeb Kumar-KHBJ46" To: X-CFilter-Loop: Reflected Subject: [Simple] Please Help!!! X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 04:55:13 -0000 Hi All, =20 I was trying to send FAX over IP network. =20 I enabled PCMU and t.38 codec on both endpoints. While checking the Wireshark trace of the session, i saw that first negotiation was done with PCMU and=20 media started flowing using this codec. After some time re-negotiation happened with t.38 codec and FAX was properly transmitted. But in the Wireshark trace could not see RTP packets with t.38 codec. RTP using PCMU was still flowing even after the successfull negotiation with t.38. =20 Could anyone help me out for the above scenario? =20 Regards. Sanjeeb _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From Markus.Isomaki@nokia.com Mon Apr 6 23:38:53 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D103A6359 for ; Mon, 6 Apr 2009 23:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 4gEIV-l7GOZp for ; Mon, 6 Apr 2009 23:38:52 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A5C933A67FD for ; Mon, 6 Apr 2009 23:38:51 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n376ccJL002525; Tue, 7 Apr 2009 09:38:58 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 09:38:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 09:38:28 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 7 Apr 2009 08:38:17 +0200 From: To: , Date: Tue, 7 Apr 2009 08:38:16 +0200 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3IFf54CxmvwNuRiK3i1+Y/jzU4gAKDvTA Message-ID: References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> In-Reply-To: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> 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: 07 Apr 2009 06:38:28.0784 (UTC) FILETIME=[760E2B00:01C9B74B] X-Nokia-AV: Clean Cc: adam@nostrum.com, simple@ietf.org Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 06:38:53 -0000 Hi, One of the main purposes of MSRP-ACM is to allow an SBC/ALG to modify SDP i= n such a way that User Agents behind NATs will open outbound TCP connection= s to that SBC/ALG and this way enabling them to communicate. The reason why= the draft does not explictly talk about this scenario is that the IETF has= not been fond of such things, so they must remain as "public secrets". But= , I think it is better to bring it all in the open and in the draft explain= how it works and even specify what the SBC/ALG SHOULD do, to make it predi= catable.=20 Markus =20 >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >On Behalf Of ext Ben Campbell >Sent: 07 April, 2009 04:30 >To: Jon Peterson >Cc: Adam Roach; Simpletons >Subject: Re: [Simple] MSRP-ACM compatibility > > >On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: > >> Even setting aside my predictable objections to a Standards Track=20 >> document endorsing SBCs modifying the c, m and a=3D lines of=20 >SDP in SIP=20 >> messages, I would be cautious about the approach under discussion. > >John's comment above inspired me to put words to another=20 >concern that has been bothering me. > >Nothing in the ACM draft says that an SBC or ALG SHOULD modify=20 >anything. But, the ACM draft (excepting the COMEDIA part)=20 >solves no problem unless they do so. Or maybe that should be=20 >rephrased, the draft not solve anything on it's own, but=20 >enable SBCs and ALGs to solve the problem. > >However, SBCs and ALGs are not very predictable in their behavior. =20 >There's not much in the way of standards there. I do not=20 >dispute Hadriel that this may work with his company's=20 >SBCs--but I have no reason to believe it will work with=20 >someone else's. Without some BEHAVE like effort to at least=20 >categorize and suggest best practices for these sorts of=20 >behaviors, I am skeptical of any standards effort to modify=20 >protocols to work around them. > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www.ietf.org/mailman/listinfo/simple >= From hisham.khartabil@gmail.com Tue Apr 7 00:06:24 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B550D3A6968 for ; Tue, 7 Apr 2009 00:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6BKFcjRcE7H for ; Tue, 7 Apr 2009 00:06:23 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id BEFB93A6822 for ; Tue, 7 Apr 2009 00:06:23 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2632221wfg.31 for ; Tue, 07 Apr 2009 00:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rFxnAYubsrfVy72R4nC4DQqLd1dU+IKKL3V7BEBj7J8=; b=X0UdydWwDMw0O4mMoifyZAggI6dKbeDqu6zyMW+8vmlliFXFhC1PC5+GMyQiIakuc4 lCGW3WsjwRUDIhI0X0KRKrYosRJ0rO1Z22YSluBXp5Q0T+efvTMXwZDyqUD+womKtfWF k8o7bjuc9YOtbbaHkwCK1GDCM9cdZChhjNaik= 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:content-transfer-encoding; b=mvc558PmhZwM1z2GrB/u6vYf6J9d7qkxrcKs4yfBIhuUTsCYvo+uli545pX6jvLydA y3zN0x2HyG6aBGmHuZZI9ucLXuVRCEHtokqCua/JnWHiCJxxPhSfl2/7ulR/0LB+p1Q1 FYV1RkKQMqUgYgVDbV5CqaojAPVcy2dBYTQKc= MIME-Version: 1.0 Received: by 10.142.166.7 with SMTP id o7mr1535597wfe.198.1239088050112; Tue, 07 Apr 2009 00:07:30 -0700 (PDT) In-Reply-To: References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> Date: Tue, 7 Apr 2009 17:07:30 +1000 Message-ID: <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> From: Hisham Khartabil To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: adam@nostrum.com, simple@ietf.org, jon.peterson@neustar.biz Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 07:06:24 -0000 (as an individual) In my opinion, what we need to do is standardise the comedia part (a=3Dsetup), figure out a way to interoperate with legacy MSRP when one side is using the c/m line to carry destination address, and that's it. Why are we talking about an intermediary that will modify messages and break security? We know those boxes exist in the world, but we don't standarise their behaviour. Why do we want to do that now? If an SBC vendor wants to work with MSRP-acm, then they can do that in their own proprietary way. They will break security, but that's new? Relating to interoperability, can we have the the acm-compliant client populate both path attribute and c/m lines in the offer? Hisham 2009/4/7 : > Hi, > > One of the main purposes of MSRP-ACM is to allow an SBC/ALG to modify SDP= in such a way that User Agents behind NATs will open outbound TCP connecti= ons to that SBC/ALG and this way enabling them to communicate. The reason w= hy the draft does not explictly talk about this scenario is that the IETF h= as not been fond of such things, so they must remain as "public secrets". B= ut, I think it is better to bring it all in the open and in the draft expla= in how it works and even specify what the SBC/ALG SHOULD do, to make it pre= dicatable. > > Markus > > >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] >>On Behalf Of ext Ben Campbell >>Sent: 07 April, 2009 04:30 >>To: Jon Peterson >>Cc: Adam Roach; Simpletons >>Subject: Re: [Simple] MSRP-ACM compatibility >> >> >>On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: >> >>> Even setting aside my predictable objections to a Standards Track >>> document endorsing SBCs modifying the c, m and a=3D lines of >>SDP in SIP >>> messages, I would be cautious about the approach under discussion. >> >>John's comment above inspired me to put words to another >>concern that has been bothering me. >> >>Nothing in the ACM draft says that an SBC or ALG SHOULD modify >>anything. But, the ACM draft (excepting the COMEDIA part) >>solves no problem unless they do so. Or maybe that should be >>rephrased, the draft not solve anything on it's own, but >>enable SBCs and ALGs to solve the problem. >> >>However, SBCs and ALGs are not very predictable in their behavior. >>There's not much in the way of standards there. I do not >>dispute Hadriel that this may work with his company's >>SBCs--but I have no reason to believe it will work with >>someone else's. Without some BEHAVE like effort to at least >>categorize and suggest best practices for these sorts of >>behaviors, I am skeptical of any standards effort to modify >>protocols to work around them. >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www.ietf.org/mailman/listinfo/simple >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From KHBJ46@motorola.com Tue Apr 7 00:47:52 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27BA3A6D8B for ; Tue, 7 Apr 2009 00:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.402, 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 ewYdkfv6jvlA for ; Tue, 7 Apr 2009 00:47:47 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id F046C3A6D94 for ; Tue, 7 Apr 2009 00:47:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: KHBJ46@motorola.com X-Msg-Ref: server-4.tower-55.messagelabs.com!1239090531!86120905!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19396 invoked from network); 7 Apr 2009 07:48:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Apr 2009 07:48:52 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n377ml86022643 for ; Tue, 7 Apr 2009 00:48:51 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n377mltv007669 for ; Tue, 7 Apr 2009 02:48:47 -0500 (CDT) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n377mj3u007665 for ; Tue, 7 Apr 2009 02:48:46 -0500 (CDT) 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_01C9B755.3A65D74E" Date: Tue, 7 Apr 2009 15:48:23 +0800 Message-ID: <7FAD6FCE52421841A11B441DEF3A88CA0216C601@ZMY16EXM70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ssrc identifier!!! Thread-Index: Acm3VToDrZ4IABpOS36CPyR5jC+9EQ== From: "Deka Sanjeeb Kumar-KHBJ46" To: X-CFilter-Loop: Reflected Subject: [Simple] Ssrc identifier!!! X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 07:47:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B755.3A65D74E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Can anyone let me know what SSRC=3D0x00 signifies in an RTP stream? =20 Can i use SSRC=3D0x00 for an RTP stream? =20 Regards, San ------_=_NextPart_001_01C9B755.3A65D74E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
Can = anyone let me=20 know what SSRC=3D0x00 signifies in an RTP stream?
 
Can i = use SSRC=3D0x00=20 for an RTP stream?
 
Regards,
San
------_=_NextPart_001_01C9B755.3A65D74E-- From christer.holmberg@ericsson.com Tue Apr 7 00:48:21 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6113A6DA4 for ; Tue, 7 Apr 2009 00:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Os4H83xlW3pt for ; Tue, 7 Apr 2009 00:48:16 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F18CE3A6D8B for ; Tue, 7 Apr 2009 00:48:15 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1BCB921435; Tue, 7 Apr 2009 09:49:21 +0200 (CEST) X-AuditID: c1b4fb3c-aaee7bb000003b08-c2-49db05809173 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5556520B67; Tue, 7 Apr 2009 09:49:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 09:49:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 09:48:16 +0200 Message-ID: In-Reply-To: <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3T7vNMXU2GeyoQO6FAWXGAI0Z7QABUXlg References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> From: "Christer Holmberg" To: "Hisham Khartabil" , X-OriginalArrivalTime: 07 Apr 2009 07:49:16.0893 (UTC) FILETIME=[5A2028D0:01C9B755] X-Brightmail-Tracker: AAAAAA== Cc: adam@nostrum.com, simple@ietf.org, jon.peterson@neustar.biz Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 07:48:21 -0000 Hi,=20 >(as an individual) > >In my opinion, what we need to do is standardise the comedia part (a=3Dsetup), figure out a way to interoperate with legacy MSRP when one side is using the c/m line to carry destination address, and that's=20 >it. Why are we talking about an intermediary that will modify messages and break security? We know those boxes exist in the world, but we don't standarise their behaviour. Why do we want to do that now?=20 >If an SBC vendor wants to work with MSRP-acm, then they can do that in their own proprietary way. They will break security, but that's new? > >Relating to interoperability, can we have the the acm-compliant client populate both path attribute and c/m lines in the offer? Yes, in order for the fallback mechanism to work. Regards, Christer Hisham 2009/4/7 : > Hi, > > One of the main purposes of MSRP-ACM is to allow an SBC/ALG to modify SDP in such a way that User Agents behind NATs will open outbound TCP connections to that SBC/ALG and this way enabling them to communicate. The reason why the draft does not explictly talk about this scenario is that the IETF has not been fond of such things, so they must remain as "public secrets". But, I think it is better to bring it all in the open and in the draft explain how it works and even specify what the SBC/ALG SHOULD do, to make it predicatable. > > Markus > > >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>Behalf Of ext Ben Campbell >>Sent: 07 April, 2009 04:30 >>To: Jon Peterson >>Cc: Adam Roach; Simpletons >>Subject: Re: [Simple] MSRP-ACM compatibility >> >> >>On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: >> >>> Even setting aside my predictable objections to a Standards Track=20 >>> document endorsing SBCs modifying the c, m and a=3D lines of >>SDP in SIP >>> messages, I would be cautious about the approach under discussion. >> >>John's comment above inspired me to put words to another concern that=20 >>has been bothering me. >> >>Nothing in the ACM draft says that an SBC or ALG SHOULD modify=20 >>anything. But, the ACM draft (excepting the COMEDIA part) solves no=20 >>problem unless they do so. Or maybe that should be rephrased, the=20 >>draft not solve anything on it's own, but enable SBCs and ALGs to=20 >>solve the problem. >> >>However, SBCs and ALGs are not very predictable in their behavior. >>There's not much in the way of standards there. I do not dispute=20 >>Hadriel that this may work with his company's SBCs--but I have no=20 >>reason to believe it will work with someone else's. Without some=20 >>BEHAVE like effort to at least categorize and suggest best practices=20 >>for these sorts of behaviors, I am skeptical of any standards effort=20 >>to modify protocols to work around them. >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www.ietf.org/mailman/listinfo/simple >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue Apr 7 01:06:45 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DF13A6D8D for ; Tue, 7 Apr 2009 01:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.55 X-Spam-Level: X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 XQsBCjfejjap for ; Tue, 7 Apr 2009 01:06:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C8A863A6D84 for ; Tue, 7 Apr 2009 01:06:44 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C33FF215E3; Tue, 7 Apr 2009 10:07:47 +0200 (CEST) X-AuditID: c1b4fb3c-a76e0bb000003b08-ea-49db09d39b79 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 80281205C7; Tue, 7 Apr 2009 10:07:47 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 10:07:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 10:07:19 +0200 Message-ID: In-Reply-To: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3IFJbTVUyY1duRXa7RHEIUjikWAANOjeg References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" , "Jon Peterson" X-OriginalArrivalTime: 07 Apr 2009 08:07:43.0039 (UTC) FILETIME=[ED70A4F0:01C9B757] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Simpletons Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 08:06:46 -0000 Hi, We don't say much about SGCs and ALGs - and that is the whole idea of ACM! :) The purpose is to allow SBC/ALG/B2BUA to treat MSRP in the same way they treat other media.=20 Yes, for MSRP they also may have to modify the a=3Dpath attribute, in order to be backward compatible, but the main point is to allow the SBC to anchor MSRP as any other media, without the media processing part having to be MSRP aware, and modify MSRP messages. And, that is not only Hadirel's SBC - it is every SBC I've ever seen. In addition, this is not something which only SBC vendors want - it is something the MARKET wants. Also, I don't really see the benfit in only moving forward with the comedia part. What would we gain by doing that? What problems would we solve? Regards, Christer =20 -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: Tuesday, April 07, 2009 4:30 AM To: Jon Peterson Cc: Christer Holmberg; Adam Roach; Simpletons Subject: Re: [Simple] MSRP-ACM compatibility On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: > Even setting aside my predictable objections to a Standards Track=20 > document endorsing SBCs modifying the c, m and a=3D lines of SDP in = SIP=20 > messages, I would be cautious about the approach under discussion. John's comment above inspired me to put words to another concern that has been bothering me. Nothing in the ACM draft says that an SBC or ALG SHOULD modify anything. But, the ACM draft (excepting the COMEDIA part) solves no problem unless they do so. Or maybe that should be rephrased, the draft not solve anything on it's own, but enable SBCs and ALGs to solve the problem. However, SBCs and ALGs are not very predictable in their behavior. =20 There's not much in the way of standards there. I do not dispute Hadriel that this may work with his company's SBCs--but I have no reason to believe it will work with someone else's. Without some BEHAVE like effort to at least categorize and suggest best practices for these sorts of behaviors, I am skeptical of any standards effort to modify protocols to work around them. From christer.holmberg@ericsson.com Tue Apr 7 01:24:25 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A2228C104 for ; Tue, 7 Apr 2009 01:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=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 8mUkOeRBM3Vf for ; Tue, 7 Apr 2009 01:24:18 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9ACAB28C112 for ; Tue, 7 Apr 2009 01:24:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9849521F85; Tue, 7 Apr 2009 10:24:13 +0200 (CEST) X-AuditID: c1b4fb3c-aaee7bb000003b08-a3-49db0dad4ea8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5E0C321F8C; Tue, 7 Apr 2009 10:24:13 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 10:24:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 10:23:47 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3Eykv0QDIicli2EaspoGXdu08cwARhiyQ References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> From: "Christer Holmberg" To: "Jon Peterson" , "Ben Campbell" X-OriginalArrivalTime: 07 Apr 2009 08:24:00.0732 (UTC) FILETIME=[3430C1C0:01C9B75A] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Simpletons Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 08:24:25 -0000 Hi,=20 >Even setting aside my predictable objections to a Standards Track document endorsing SBCs modifying the c, m and a=3D lines of SDP in SIP messages, I don't think we are "endorsing" - we are taking real life networks into consideration :) >Furthermore, into the details of the proposal a bit, I think I understand what you do when the offerer has a relay and the answerer has an SBC, and the SBC needs to modify the offerer's c/m and a=3Dpath:,=20 >but I'm a bit hazier on how you modify the answerer's SDP in this case in such a way that the offerer's relay will send MSRP to the SBC on it's way to the client. What does that case look like? The SBC would modify the path attribute of the answerer, so that it points towards the SBC - in the same way as it modifies the path attribute in the offer if the client behind the SBC acts as offerer. Regards, Christer On 4/3/09 1:18 PM, "Ben Campbell" wrote: [snip] > A summary of what I recall: >=20 > When an MSRP endpoint uses TLS to connect to a peer, it needs to=20 > verify that the certificate presented by the peer does in fact belong=20 > to the party it wants to talk to, by making sure the SubjectAltName of > the peer certificate matches the host name or IP address in the=20 > associated MSRP URI. The proposal we discussed in the work group=20 > meeting was designed to allow a middlebox to rewrite the host part of=20 > MSRP URIs inside the path attribute in the SDP. If they do this,=20 > there are scenarios where the certificate SubjectAltName will no=20 > longer match the URI. >=20 > For example, assume A uses an MSRP Relay, and B uses an SBC, following > the discussed proposal. A sends an SDP "path" attribute that looks=20 > something like the following. Furthermore, assume the SBC supports TCP > media,and transparently relays the TLS handshake. >=20 > a=3Dpath:MSRPS://A/823497w, MSRPS://relay/28g9345ikas >=20 > But when the SBC changes this to look like >=20 > a=3Dpath:MSRPS://A/823497w, MSRPS://sbc/28g9345ikas. >=20 >=20 > If they actually In the case of two humans communicating over client-=20 > class devices, this is not likely to be an issue. >=20 > B then opens a TCP connection to "sbc", and starts a TLS handshake. It > expects to get a certificate matching "sbc". But since the SBC=20 > transparently relays the handshake to the MSRP relay, B instead gets a > certificate for "relay". B interprets this as a TLS authentication=20 > failure. >=20 > This may not be a problem for some scenarios with no MSRP relays,=20 > where the TLS association is peer to peer between the MSRP devices. > First, TLS is not likely used in this case, due to client-certificate=20 > issues. If it _is_ used, it's probably with self-signed certs and cert > fingerprints passed in the SDP. However, if one of the endpoints=20 > actually has a certificate bound to its host name or IP address, we=20 > still have the problem. For example, assume one of the peers is a MSRP > conference server with a conventional server certificate. >=20 >=20 From christer.holmberg@ericsson.com Tue Apr 7 01:30:23 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0933A6823 for ; Tue, 7 Apr 2009 01:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 XkaH5yLREWQ8 for ; Tue, 7 Apr 2009 01:30:21 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2DE2E3A6D90 for ; Tue, 7 Apr 2009 01:30:21 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6819920486; Tue, 7 Apr 2009 10:31:26 +0200 (CEST) X-AuditID: c1b4fb3c-a8ee3bb000003b08-3f-49db0f5e075e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 255EE2045B; Tue, 7 Apr 2009 10:31:26 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 10:31:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 10:30:48 +0200 Message-ID: In-Reply-To: <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3T7vNMXU2GeyoQO6FAWXGAI0Z7QACtKHw References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> From: "Christer Holmberg" To: "Hisham Khartabil" , X-OriginalArrivalTime: 07 Apr 2009 08:31:25.0374 (UTC) FILETIME=[3D37BDE0:01C9B75B] X-Brightmail-Tracker: AAAAAA== Cc: adam@nostrum.com, simple@ietf.org, jon.peterson@neustar.biz Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 08:30:23 -0000 Hi,=20 >In my opinion, what we need to do is standardise the comedia part (a=3Dsetup), figure out a way to interoperate with legacy MSRP when one side is using the c/m line to carry destination address, >and that's it. Just to clarify: the draft already provides a fallback mechanism when only one side is using the c/m line. But, that only works when there is no SBC in the path, so that's what we need to solve. >From a pure MSRP perspective, the proposal to solve that has been to update the session mapping procedure in 4975.=20 What we are have now been discussing is the TLS part, and I believe that's where we see the main issues that still need to be sorted out. Regards, Christer 2009/4/7 : > Hi, > > One of the main purposes of MSRP-ACM is to allow an SBC/ALG to modify SDP in such a way that User Agents behind NATs will open outbound TCP connections to that SBC/ALG and this way enabling them to communicate. The reason why the draft does not explictly talk about this scenario is that the IETF has not been fond of such things, so they must remain as "public secrets". But, I think it is better to bring it all in the open and in the draft explain how it works and even specify what the SBC/ALG SHOULD do, to make it predicatable. > > Markus > > >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>Behalf Of ext Ben Campbell >>Sent: 07 April, 2009 04:30 >>To: Jon Peterson >>Cc: Adam Roach; Simpletons >>Subject: Re: [Simple] MSRP-ACM compatibility >> >> >>On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: >> >>> Even setting aside my predictable objections to a Standards Track=20 >>> document endorsing SBCs modifying the c, m and a=3D lines of >>SDP in SIP >>> messages, I would be cautious about the approach under discussion. >> >>John's comment above inspired me to put words to another concern that=20 >>has been bothering me. >> >>Nothing in the ACM draft says that an SBC or ALG SHOULD modify=20 >>anything. But, the ACM draft (excepting the COMEDIA part) solves no=20 >>problem unless they do so. Or maybe that should be rephrased, the=20 >>draft not solve anything on it's own, but enable SBCs and ALGs to=20 >>solve the problem. >> >>However, SBCs and ALGs are not very predictable in their behavior. >>There's not much in the way of standards there. I do not dispute=20 >>Hadriel that this may work with his company's SBCs--but I have no=20 >>reason to believe it will work with someone else's. Without some=20 >>BEHAVE like effort to at least categorize and suggest best practices=20 >>for these sorts of behaviors, I am skeptical of any standards effort=20 >>to modify protocols to work around them. >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www.ietf.org/mailman/listinfo/simple >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From xramtsov@gmail.com Tue Apr 7 03:32:18 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467133A6AAE for ; Tue, 7 Apr 2009 03:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EctmXmEQjJS for ; Tue, 7 Apr 2009 03:32:13 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 23A4D28C1D4 for ; Tue, 7 Apr 2009 03:32:07 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so798252fga.18 for ; Tue, 07 Apr 2009 03:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=87Fcbtbl/5bzkTXUqQff2chGTjfXSMm4CamMqh4l8jA=; b=PzUw4J122K9ysL0P22s1rPLaSMvxiGfLBg3O8OEoZWOqSKEZ6AtBLuLGrWbBAUsQQY KiSvYVhumw6snBctq/3UOu87NVEroCUsXXpQaiIxF6wjVXnbxfcxymUxk6aXRFF3/ZzO ThDqk8nrGn+oqfrEgMPI7fYPxPBHyQnh2VYhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=I1E1Iil4rSOX/LGIyL9Hvhh40X4aXjSltlLkcIlewh5epb2L9RwV+T2rZyDbz5iAmQ dhu3SR5zoYjRsg67E8PDVa7yJhCD1z7eAwEnI71U+KxklvYl2rCE7Ju1zmftTpeg0h9s TJ6RND9tf7JfWTNtOGew5iwpJH/S74lIZT+cA= Received: by 10.86.95.20 with SMTP id s20mr55270fgb.40.1239100392967; Tue, 07 Apr 2009 03:33:12 -0700 (PDT) Received: from zinid.ru ([79.105.247.28]) by mx.google.com with ESMTPS id 12sm645078fgg.22.2009.04.07.03.33.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Apr 2009 03:33:12 -0700 (PDT) Message-ID: <49DB2BE2.4010707@gmail.com> Date: Tue, 07 Apr 2009 20:33:06 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Simple WG References: <66cd252f0904052227o32a1513an4e4d55f7b29173c6@mail.gmail.com> In-Reply-To: <66cd252f0904052227o32a1513an4e4d55f7b29173c6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] WGLC for draft-ietf-simple-chat-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 10:32:18 -0000 Hisham Khartabil wrote: > This is to initiate a working group last call (WGLC) for Multi-party > Chat Using MSRP draft (draft-ietf-simple-chat-04). > > http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-04.txt Not for the flame: I'm just wondering why you guys reinventing a wheel? We already have an RFC XMPP with MUC. Where I can read an explanation of reasons to implement new RFC IM? From Markus.Isomaki@nokia.com Tue Apr 7 04:28:53 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C083A6968 for ; Tue, 7 Apr 2009 04:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 mPLmlTEaY5Vr for ; Tue, 7 Apr 2009 04:28:46 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1C3A93A6D66 for ; Tue, 7 Apr 2009 04:28:45 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n37BSvpE012993; Tue, 7 Apr 2009 06:29:14 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 14:28:39 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 14:28:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 14:28:33 +0300 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 7 Apr 2009 13:28:19 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Tue, 7 Apr 2009 13:28:19 +0200 From: To: Date: Tue, 7 Apr 2009 13:28:18 +0200 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3T4xsGceGSO40Ro+iMzmbCjtrlQAE+sgQ Message-ID: References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> In-Reply-To: <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.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-OriginalArrivalTime: 07 Apr 2009 11:28:33.0759 (UTC) FILETIME=[FC3A96F0:01C9B773] X-Nokia-AV: Clean Cc: adam@nostrum.com, simple@ietf.org, jon.peterson@neustar.biz Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 11:28:53 -0000 Hi, It's true we haven't standardized or even recommended how B2BUAs work. But = hasn't that exactly led us to the problems we have with e2e security and e2= e identifiers. I understand that having BEHAVE define recommendations on NA= Ts does not guarantee that every NAT box will follow them. The same would g= o for anything the IETF says about B2BUAs. But in this MSRP case it would b= e still valuable to explain how the B2BUA will act wrt. MSRP-ACM, just for = reference if nothing more.=20 But for me this is not the main thing about this draft. The main thing woul= d be to get the draft forward, as we clearly have a need for it. There are = some mobile operators who seem to have serious plans for MSRP deployment so= User Agent developers have to solve the problem in some way in the next fe= w months. Those customers won't care about TLS issues or backwards compatib= ility too much, but it is of course nice if we can solve them. =20 Markus =20 >-----Original Message----- >From: ext Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20 >Sent: 07 April, 2009 10:08 >To: Isomaki Markus (Nokia-CIC/Espoo) >Cc: ben@estacado.net; jon.peterson@neustar.biz;=20 >adam@nostrum.com; simple@ietf.org >Subject: Re: [Simple] MSRP-ACM compatibility > >(as an individual) > >In my opinion, what we need to do is standardise the comedia=20 >part (a=3Dsetup), figure out a way to interoperate with legacy=20 >MSRP when one side is using the c/m line to carry destination=20 >address, and that's it. Why are we talking about an=20 >intermediary that will modify messages and break security? We=20 >know those boxes exist in the world, but we don't standarise=20 >their behaviour. Why do we want to do that now? If an SBC=20 >vendor wants to work with MSRP-acm, then they can do that in=20 >their own proprietary way. They will break security, but that's new? > >Relating to interoperability, can we have the the=20 >acm-compliant client populate both path attribute and c/m=20 >lines in the offer? > >Hisham > >2009/4/7 : >> Hi, >> >> One of the main purposes of MSRP-ACM is to allow an SBC/ALG=20 >to modify SDP in such a way that User Agents behind NATs will=20 >open outbound TCP connections to that SBC/ALG and this way=20 >enabling them to communicate. The reason why the draft does=20 >not explictly talk about this scenario is that the IETF has=20 >not been fond of such things, so they must remain as "public=20 >secrets". But, I think it is better to bring it all in the=20 >open and in the draft explain how it works and even specify=20 >what the SBC/ALG SHOULD do, to make it predicatable. >> >> Markus >> >> >>>-----Original Message----- >>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>>Behalf Of ext Ben Campbell >>>Sent: 07 April, 2009 04:30 >>>To: Jon Peterson >>>Cc: Adam Roach; Simpletons >>>Subject: Re: [Simple] MSRP-ACM compatibility >>> >>> >>>On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: >>> >>>> Even setting aside my predictable objections to a Standards Track=20 >>>> document endorsing SBCs modifying the c, m and a=3D lines of >>>SDP in SIP >>>> messages, I would be cautious about the approach under discussion. >>> >>>John's comment above inspired me to put words to another=20 >concern that=20 >>>has been bothering me. >>> >>>Nothing in the ACM draft says that an SBC or ALG SHOULD modify=20 >>>anything. But, the ACM draft (excepting the COMEDIA part) solves no=20 >>>problem unless they do so. Or maybe that should be rephrased, the=20 >>>draft not solve anything on it's own, but enable SBCs and ALGs to=20 >>>solve the problem. >>> >>>However, SBCs and ALGs are not very predictable in their behavior. >>>There's not much in the way of standards there. I do not dispute=20 >>>Hadriel that this may work with his company's SBCs--but I have no=20 >>>reason to believe it will work with someone else's. Without some=20 >>>BEHAVE like effort to at least categorize and suggest best practices=20 >>>for these sorts of behaviors, I am skeptical of any standards effort=20 >>>to modify protocols to work around them. >>> >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www.ietf.org/mailman/listinfo/simple >>> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> >= From christer.holmberg@ericsson.com Tue Apr 7 04:46:59 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACFF3A6ABC for ; Tue, 7 Apr 2009 04:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.845 X-Spam-Level: X-Spam-Status: No, score=-5.845 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 XPfRfLjHGpDf for ; Tue, 7 Apr 2009 04:46:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5749E3A6784 for ; Tue, 7 Apr 2009 04:46:58 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6291C21FBC; Tue, 7 Apr 2009 13:48:03 +0200 (CEST) X-AuditID: c1b4fb3c-abee9bb000003b08-5c-49db3c7650d7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BBEB8214D8; Tue, 7 Apr 2009 13:43:50 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 13:43:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 13:43:04 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3T4xsGceGSO40Ro+iMzmbCjtrlQAE+sgQAARkjEA= References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net><66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> From: "Christer Holmberg" To: , X-OriginalArrivalTime: 07 Apr 2009 11:43:46.0200 (UTC) FILETIME=[1C160980:01C9B776] X-Brightmail-Tracker: AAAAAA== Cc: adam@nostrum.com, simple@ietf.org, jon.peterson@neustar.biz Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 11:46:59 -0000 Hi, I agree that we should describe how the B2BUA should modify the path attribute in order to be backward compatible. It's then up to the operators to decided whether they want that functionality or not. Some people I've talked to do wish to have interoperability with legacy MSRP, some don't, but none of the ones I've talk to care about MSRP relays. It's too expensive and "clumsy", since it requires knowledge about all relays in the path. So, I again think it would be sad if we stop the work on something people DO want just because of some potential issues with something which many people DO NOT want... Regards, Christer -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com Sent: Tuesday, April 07, 2009 2:28 PM To: hisham.khartabil@gmail.com Cc: adam@nostrum.com; simple@ietf.org; jon.peterson@neustar.biz Subject: Re: [Simple] MSRP-ACM compatibility Hi, It's true we haven't standardized or even recommended how B2BUAs work. But hasn't that exactly led us to the problems we have with e2e security and e2e identifiers. I understand that having BEHAVE define recommendations on NATs does not guarantee that every NAT box will follow them. The same would go for anything the IETF says about B2BUAs. But in this MSRP case it would be still valuable to explain how the B2BUA will act wrt. MSRP-ACM, just for reference if nothing more.=20 But for me this is not the main thing about this draft. The main thing would be to get the draft forward, as we clearly have a need for it. There are some mobile operators who seem to have serious plans for MSRP deployment so User Agent developers have to solve the problem in some way in the next few months. Those customers won't care about TLS issues or backwards compatibility too much, but it is of course nice if we can solve them. =20 Markus =20 >-----Original Message----- >From: ext Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >Sent: 07 April, 2009 10:08 >To: Isomaki Markus (Nokia-CIC/Espoo) >Cc: ben@estacado.net; jon.peterson@neustar.biz; adam@nostrum.com;=20 >simple@ietf.org >Subject: Re: [Simple] MSRP-ACM compatibility > >(as an individual) > >In my opinion, what we need to do is standardise the comedia part=20 >(a=3Dsetup), figure out a way to interoperate with legacy MSRP when one = >side is using the c/m line to carry destination address, and that's it. >Why are we talking about an intermediary that will modify messages and=20 >break security? We know those boxes exist in the world, but we don't=20 >standarise their behaviour. Why do we want to do that now? If an SBC=20 >vendor wants to work with MSRP-acm, then they can do that in their own=20 >proprietary way. They will break security, but that's new? > >Relating to interoperability, can we have the the acm-compliant client=20 >populate both path attribute and c/m lines in the offer? > >Hisham > >2009/4/7 : >> Hi, >> >> One of the main purposes of MSRP-ACM is to allow an SBC/ALG >to modify SDP in such a way that User Agents behind NATs will open=20 >outbound TCP connections to that SBC/ALG and this way enabling them to=20 >communicate. The reason why the draft does not explictly talk about=20 >this scenario is that the IETF has not been fond of such things, so=20 >they must remain as "public secrets". But, I think it is better to=20 >bring it all in the open and in the draft explain how it works and even >specify what the SBC/ALG SHOULD do, to make it predicatable. >> >> Markus >> >> >>>-----Original Message----- >>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>>Behalf Of ext Ben Campbell >>>Sent: 07 April, 2009 04:30 >>>To: Jon Peterson >>>Cc: Adam Roach; Simpletons >>>Subject: Re: [Simple] MSRP-ACM compatibility >>> >>> >>>On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: >>> >>>> Even setting aside my predictable objections to a Standards Track=20 >>>> document endorsing SBCs modifying the c, m and a=3D lines of >>>SDP in SIP >>>> messages, I would be cautious about the approach under discussion. >>> >>>John's comment above inspired me to put words to another >concern that >>>has been bothering me. >>> >>>Nothing in the ACM draft says that an SBC or ALG SHOULD modify=20 >>>anything. But, the ACM draft (excepting the COMEDIA part) solves no=20 >>>problem unless they do so. Or maybe that should be rephrased, the=20 >>>draft not solve anything on it's own, but enable SBCs and ALGs to=20 >>>solve the problem. >>> >>>However, SBCs and ALGs are not very predictable in their behavior. >>>There's not much in the way of standards there. I do not dispute=20 >>>Hadriel that this may work with his company's SBCs--but I have no=20 >>>reason to believe it will work with someone else's. Without some=20 >>>BEHAVE like effort to at least categorize and suggest best practices=20 >>>for these sorts of behaviors, I am skeptical of any standards effort=20 >>>to modify protocols to work around them. >>> >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www.ietf.org/mailman/listinfo/simple >>> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Tue Apr 7 06:12:21 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CD03A68EF for ; Tue, 7 Apr 2009 06:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+9-yCcfMHDF for ; Tue, 7 Apr 2009 06:12:20 -0700 (PDT) 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 52FEF3A677C for ; Tue, 7 Apr 2009 06:12:20 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n37DDNln062168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Apr 2009 08:13:24 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: From: Ben Campbell To: Evgeniy Khramtsov In-Reply-To: <49DB2BE2.4010707@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 08:13:25 -0500 References: <66cd252f0904052227o32a1513an4e4d55f7b29173c6@mail.gmail.com> <49DB2BE2.4010707@gmail.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 68.94.44.137 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] WGLC for draft-ietf-simple-chat-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:12:21 -0000 On Apr 7, 2009, at 5:33 AM, Evgeniy Khramtsov wrote: > Hisham Khartabil wrote: >> This is to initiate a working group last call (WGLC) for Multi-party >> Chat Using MSRP draft (draft-ietf-simple-chat-04). >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-04.txt > > Not for the flame: I'm just wondering why you guys reinventing a > wheel? We already have an RFC XMPP with MUC. Where I can read an > explanation of reasons to implement new RFC IM? SIMPLE has been working on IM for some time. The draft in question is not a new IM draft, but discusses how to use an existing IM RFC for chat-room type behavior. In any case, see the SIMPLE charter at http://www.ietf.org/html.charters/simple-charter.html . Thanks! Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From adam@nostrum.com Tue Apr 7 07:31:04 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66C23A6991 for ; Tue, 7 Apr 2009 07:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zIE3aJuCwEL for ; Tue, 7 Apr 2009 07:31:04 -0700 (PDT) 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 6AF363A6C05 for ; Tue, 7 Apr 2009 07:31:02 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n37EV2Dh069625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 09:31:02 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49DB63A5.1090505@nostrum.com> Date: Tue, 07 Apr 2009 09:31:01 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hisham Khartabil References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> In-Reply-To: <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: simple@ietf.org, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:31:05 -0000 Hisham Khartabil wrote: > In my opinion, what we need to do is standardise the comedia part > (a=setup), figure out a way to interoperate with legacy MSRP when one > side is using the c/m line to carry destination address, and that's > it. Why are we talking about an intermediary that will modify messages > and break security? We know those boxes exist in the world, but we > don't standarise their behaviour. Why do we want to do that now? If an > SBC vendor wants to work with MSRP-acm, then they can do that in their > own proprietary way. They will break security, but that's new? Your suggestion confuses me. What, in *your* view, is the purpose of using c/m lines for carrying addressing information? The MSRP URL does a fine job of that. /a From adam@nostrum.com Tue Apr 7 07:43:18 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8AB3A68D1 for ; Tue, 7 Apr 2009 07:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1toQ43S8p-kR for ; Tue, 7 Apr 2009 07:43:17 -0700 (PDT) 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 6B22E3A67D2 for ; Tue, 7 Apr 2009 07:43:17 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n37Ei2bF070792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 09:44:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49DB66B2.4030908@nostrum.com> Date: Tue, 07 Apr 2009 09:44:02 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: Simpletons , Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:43:18 -0000 Christer Holmberg wrote: > Also, I don't really see the benfit in only moving forward with the > comedia part. What would we gain by doing that? What problems would we > solve? > Right now, in MSRP, the offerer always makes the MSRP connection. This works in the following cases: 1. Neither party is behind a NAT (no relays) 2. Offerer is behind a NAT, answerer is not (no relays) 3. Both parties are behind NATs, answerer has a relay With comedia, the direction of the outbound MSRP connection is negotiated between the parties. This works in the following cases: 1. Neither party is behind a NAT (no relays) 2. Offerer is behind a NAT, answerer is not (no relays) 3. Offerer is not behind a NAT, answerer is (no relays) 4. Both parties are behind NATs, answerer has a relay 5. Both parties are behind NATs, offerer has a relay In other words, comedia significantly expands the scenarios in which MSRP works. /a From adam@nostrum.com Tue Apr 7 07:45:32 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA5B28C19C for ; Tue, 7 Apr 2009 07:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo8WGelixzCF for ; Tue, 7 Apr 2009 07:45:32 -0700 (PDT) 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 6907928C19F for ; Tue, 7 Apr 2009 07:45:31 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n37EkICV071059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 09:46:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49DB673A.6080804@nostrum.com> Date: Tue, 07 Apr 2009 09:46:18 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: Simpletons , Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:45:32 -0000 Christer Holmberg wrote: > The SBC would modify the path attribute of the answerer, so that it > points towards the SBC - in the same way as it modifies the path > attribute in the offer if the client behind the SBC acts as offerer. > If an SBC can operate by modifying the path, then why is there any discussion of c= and m= lines at all? /a From adam@nostrum.com Tue Apr 7 07:54:16 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8803A6DAD for ; Tue, 7 Apr 2009 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0VEgpNdLnaR for ; Tue, 7 Apr 2009 07:54:15 -0700 (PDT) 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 17CFA28C1C3 for ; Tue, 7 Apr 2009 07:54:14 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n37EtADE071898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 09:55:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49DB694E.30400@nostrum.com> Date: Tue, 07 Apr 2009 09:55:10 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net><66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: simple@ietf.org, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:54:16 -0000 Christer Holmberg wrote: > Some people I've talked to do wish to have interoperability with legacy > MSRP, some don't, but none of the ones I've talk to care about MSRP > relays. Hi. My name is Adam Roach, and I'm glad to meet you for the first time. Have you met my associate Ben Campbell? I'm sure he'd be glad to meet you as well. While I'm at it, I'd like to introduce you to a gentleman by the name of Ruud Klaver; you can check out his work at http://msrprelay.org/. Or, if that's too academic for you, perhaps you'd be better off making the acquaintance of Adrian Georgescu, who actually sells realtime infrastructure equipment to service providers across Europe, after having worked at a significant number of service providers himself. There. You now have the chance to go from "none" to "four" in a very short period of time. /a From BPenfield@acmepacket.com Tue Apr 7 08:10:11 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE973A6DEA for ; Tue, 7 Apr 2009 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed5ZB-scTjhq for ; Tue, 7 Apr 2009 08:10:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4ADFC3A6860 for ; Tue, 7 Apr 2009 08:10:10 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 7 Apr 2009 11:11:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 7 Apr 2009 11:11:09 -0400 From: Bob Penfield To: Adam Roach , Christer Holmberg Date: Tue, 7 Apr 2009 11:11:08 -0400 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3j+13gHorPN0TReWAuUfdNTmaywAArbqQ Message-ID: References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> <49DB673A.6080804@nostrum.com> In-Reply-To: <49DB673A.6080804@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 Cc: Simpletons , Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:10:11 -0000 If the SBC modifies the path, then it must parse and process all the MSRP m= essages in order to set it back the original one from the original SDP. The= desire is to simply relay the MSRP in the same manner as RTP. cheers, (-:bob=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Adam Roach Sent: Tuesday, April 07, 2009 10:46 AM To: Christer Holmberg Cc: Simpletons; Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility Christer Holmberg wrote: > The SBC would modify the path attribute of the answerer, so that it > points towards the SBC - in the same way as it modifies the path > attribute in the offer if the client behind the SBC acts as offerer. > =20 If an SBC can operate by modifying the path, then why is there any=20 discussion of c=3D and m=3D lines at all? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From adam@nostrum.com Tue Apr 7 12:11:40 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8956C3A6843 for ; Tue, 7 Apr 2009 12:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, SPF_PASS=-0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3tKp2XDjksK for ; Tue, 7 Apr 2009 12:11:39 -0700 (PDT) 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 68FF63A6A28 for ; Tue, 7 Apr 2009 12:11:39 -0700 (PDT) Received: from dn3-211.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 n37JCWXD099217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 14:12:32 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49DBA5A0.2020300@nostrum.com> Date: Tue, 07 Apr 2009 14:12:32 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Bob Penfield References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> <49DB673A.6080804@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simpletons , Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:11:40 -0000 Do you mean the SDP path lines? a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp Or the MSRP path lines? From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp I think we're talking about the SDP path lines in this thread, but your response sounds like you might be talking about the MSRP path lines. /a Bob Penfield wrote: > If the SBC modifies the path, then it must parse and process all the MSRP messages in order to set it back the original one from the original SDP. The desire is to simply relay the MSRP in the same manner as RTP. > > cheers, > (-:bob > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Tuesday, April 07, 2009 10:46 AM > To: Christer Holmberg > Cc: Simpletons; Jon Peterson > Subject: Re: [Simple] MSRP-ACM compatibility > > Christer Holmberg wrote: > >> The SBC would modify the path attribute of the answerer, so that it >> points towards the SBC - in the same way as it modifies the path >> attribute in the offer if the client behind the SBC acts as offerer. >> >> > > If an SBC can operate by modifying the path, then why is there any > discussion of c= and m= lines at all? > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From christer.holmberg@ericsson.com Tue Apr 7 12:26:53 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500DD3A69D2 for ; Tue, 7 Apr 2009 12:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 jB23gvstOU5D for ; Tue, 7 Apr 2009 12:26:52 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 10C4B3A6CCA for ; Tue, 7 Apr 2009 12:26:52 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4767B20EFA; Tue, 7 Apr 2009 21:27:57 +0200 (CEST) X-AuditID: c1b4fb3c-ab6e8bb000003b08-8d-49dba93d3b5e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1FDAC20008; Tue, 7 Apr 2009 21:27:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 21:27:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 21:27:36 +0200 Message-ID: In-Reply-To: <49DB694E.30400@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3kN0M+8oou3HgTJKnlu7PJpnaKgAJNWFQ References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net><66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> <49DB694E.30400@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 07 Apr 2009 19:27:56.0895 (UTC) FILETIME=[F464D6F0:01C9B7B6] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:26:53 -0000 With "people" I was referring to customers. I guess I should have made that more clear. Also, Adrian already earlier informed us about his relay stuff, which was one reason we decided to move forward with the relay depracation. I am sure you saw that also. Regards, Christer -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, April 07, 2009 5:55 PM To: Christer Holmberg Cc: Markus.Isomaki@nokia.com; hisham.khartabil@gmail.com; simple@ietf.org; jon.peterson@neustar.biz Subject: Re: [Simple] MSRP-ACM compatibility Christer Holmberg wrote: > Some people I've talked to do wish to have interoperability with=20 > legacy MSRP, some don't, but none of the ones I've talk to care about=20 > MSRP relays. Hi. My name is Adam Roach, and I'm glad to meet you for the first time.=20 Have you met my associate Ben Campbell? I'm sure he'd be glad to meet you as well. While I'm at it, I'd like to introduce you to a gentleman by the name of Ruud Klaver; you can check out his work at http://msrprelay.org/. Or, if that's too academic for you, perhaps you'd be better off making the acquaintance of Adrian Georgescu, who actually sells realtime infrastructure equipment to service providers across Europe, after having worked at a significant number of service providers himself. There. You now have the chance to go from "none" to "four" in a very short period of time. /a From christer.holmberg@ericsson.com Tue Apr 7 12:40:54 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EBB3A6D98 for ; Tue, 7 Apr 2009 12:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWKBFV-KM7Rv for ; Tue, 7 Apr 2009 12:40:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2DF2D3A6CB9 for ; Tue, 7 Apr 2009 12:40:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 44E5120484; Tue, 7 Apr 2009 21:41:58 +0200 (CEST) X-AuditID: c1b4fb3e-aa81cbb0000024d5-d0-49dbac8696e9 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1E1A320418; Tue, 7 Apr 2009 21:41:58 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 21:41:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 21:41:49 +0200 Message-ID: In-Reply-To: <49DBA5A0.2020300@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3tNP//LBy4DjvTCKANsjoAUQ38AAAshVA References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> <49DB673A.6080804@nostrum.com> <49DBA5A0.2020300@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "Bob Penfield" X-OriginalArrivalTime: 07 Apr 2009 19:41:57.0868 (UTC) FILETIME=[E9A722C0:01C9B7B8] X-Brightmail-Tracker: AAAAAA== Cc: Simpletons , Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:40:54 -0000 Hi, Maybe it would work also by only chaning the a=3Dpath attribute. I = haven't thought about that very much, since this new modify-the-path-in-order-to-work-with-relays issue is rather new. One small issue with that solution is that it would also require B2BUAs which are not communicating directly with endpoints (they only communicate with other B2BUAs) to also modify the path attribute, eventhough it would be enough for them to only modify the c/m line and leave the path attribute unchanged.=20 But, I don't think only modifying the path attribute would solve the TLS issue. Regards, Christer =20 -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, April 07, 2009 10:13 PM To: Bob Penfield Cc: Christer Holmberg; Simpletons; Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility Do you mean the SDP path lines? a=3Dpath:msrp://atlanta.example.com:7654/jshA7weztas;tcp Or the MSRP path lines? From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp I think we're talking about the SDP path lines in this thread, but your response sounds like you might be talking about the MSRP path lines. /a Bob Penfield wrote: > If the SBC modifies the path, then it must parse and process all the MSRP messages in order to set it back the original one from the original SDP. The desire is to simply relay the MSRP in the same manner as RTP. > > cheers, > (-:bob > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 > Behalf Of Adam Roach > Sent: Tuesday, April 07, 2009 10:46 AM > To: Christer Holmberg > Cc: Simpletons; Jon Peterson > Subject: Re: [Simple] MSRP-ACM compatibility > > Christer Holmberg wrote: > =20 >> The SBC would modify the path attribute of the answerer, so that it=20 >> points towards the SBC - in the same way as it modifies the path=20 >> attribute in the offer if the client behind the SBC acts as offerer. >> =20 >> =20 > > If an SBC can operate by modifying the path, then why is there any=20 > discussion of c=3D and m=3D lines at all? > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > =20 From christer.holmberg@ericsson.com Tue Apr 7 12:42:55 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F21E3A6A28 for ; Tue, 7 Apr 2009 12:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 jPrqvVO8AnNh for ; Tue, 7 Apr 2009 12:42:54 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F2BA23A6B17 for ; Tue, 7 Apr 2009 12:42:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BB5F0201B6; Tue, 7 Apr 2009 21:43:58 +0200 (CEST) X-AuditID: c1b4fb3e-ae824bb0000024d5-0e-49dbacfe6061 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 976B820065; Tue, 7 Apr 2009 21:43:58 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 21:43:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 21:43:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3kN0M+8oou3HgTJKnlu7PJpnaKgAJNWFQAADTJkA= References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net><66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com><49DB694E.30400@nostrum.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Adam Roach" X-OriginalArrivalTime: 07 Apr 2009 19:43:58.0462 (UTC) FILETIME=[318851E0:01C9B7B9] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:42:55 -0000 Which was one reason we decided to NOT move forward with the relay deprecation, that is.=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, April 07, 2009 10:28 PM To: Adam Roach Cc: simple@ietf.org; jon.peterson@neustar.biz; Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility With "people" I was referring to customers. I guess I should have made that more clear. Also, Adrian already earlier informed us about his relay stuff, which was one reason we decided to move forward with the relay depracation. I am sure you saw that also. Regards, Christer -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Tuesday, April 07, 2009 5:55 PM To: Christer Holmberg Cc: Markus.Isomaki@nokia.com; hisham.khartabil@gmail.com; simple@ietf.org; jon.peterson@neustar.biz Subject: Re: [Simple] MSRP-ACM compatibility Christer Holmberg wrote: > Some people I've talked to do wish to have interoperability with=20 > legacy MSRP, some don't, but none of the ones I've talk to care about=20 > MSRP relays. Hi. My name is Adam Roach, and I'm glad to meet you for the first time.=20 Have you met my associate Ben Campbell? I'm sure he'd be glad to meet you as well. While I'm at it, I'd like to introduce you to a gentleman by the name of Ruud Klaver; you can check out his work at http://msrprelay.org/. Or, if that's too academic for you, perhaps you'd be better off making the acquaintance of Adrian Georgescu, who actually sells realtime infrastructure equipment to service providers across Europe, after having worked at a significant number of service providers himself. There. You now have the chance to go from "none" to "four" in a very short period of time. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From BPenfield@acmepacket.com Tue Apr 7 13:17:24 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D21D3A6DE3 for ; Tue, 7 Apr 2009 13:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QnAg-gbMxEU for ; Tue, 7 Apr 2009 13:17:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 745A23A6D9A for ; Tue, 7 Apr 2009 13:17:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 7 Apr 2009 16:18:27 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 7 Apr 2009 16:18:27 -0400 From: Bob Penfield To: Adam Roach Date: Tue, 7 Apr 2009 16:18:25 -0400 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3tNT2cY5AARIQTqOpbSaT6Ka5ZQABw8Pw Message-ID: References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> <49DB673A.6080804@nostrum.com> <49DBA5A0.2020300@nostrum.com> In-Reply-To: <49DBA5A0.2020300@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 Cc: Simpletons , Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 20:17:24 -0000 If the SDP path is changed, the MSRP Path will not match what the UA expect= s unless the MSRP message is also changed. For example, A sends SDP with: a=3Dpath:msrp://atlanta.example.com:7654/jshA7weztas;tcp It gets changed to=20 a=3Dpath:msrp://b2bua.example.com:7654/jshA7weztas;tcp And is sent to B When A sends an MSRP message to B, A sends: From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp But B expects: From-Path: msrp://b2bua.example.com:7654/jshA7weztas;tcp If the MSRP message is not changed, then B should reject the message since = it does not match what it is expecting. If the m/c line was used for the connection, there is no need to change the= path attribute in the SDP, and the intermediary does not need to modify MS= RP messages. cheers, (-:bob -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, April 07, 2009 3:13 PM To: Bob Penfield Cc: Christer Holmberg; Simpletons; Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility Do you mean the SDP path lines? a=3Dpath:msrp://atlanta.example.com:7654/jshA7weztas;tcp Or the MSRP path lines? From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp I think we're talking about the SDP path lines in this thread, but your=20 response sounds like you might be talking about the MSRP path lines. /a Bob Penfield wrote: > If the SBC modifies the path, then it must parse and process all the MSRP= messages in order to set it back the original one from the original SDP. T= he desire is to simply relay the MSRP in the same manner as RTP. > > cheers, > (-:bob=20 > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Adam Roach > Sent: Tuesday, April 07, 2009 10:46 AM > To: Christer Holmberg > Cc: Simpletons; Jon Peterson > Subject: Re: [Simple] MSRP-ACM compatibility > > Christer Holmberg wrote: > =20 >> The SBC would modify the path attribute of the answerer, so that it >> points towards the SBC - in the same way as it modifies the path >> attribute in the offer if the client behind the SBC acts as offerer. >> =20 >> =20 > > If an SBC can operate by modifying the path, then why is there any=20 > discussion of c=3D and m=3D lines at all? > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > =20 From christer.holmberg@ericsson.com Tue Apr 7 13:34:38 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693253A6DFA for ; Tue, 7 Apr 2009 13:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 2x7SkNivJBUX for ; Tue, 7 Apr 2009 13:34:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6B40D3A69F1 for ; Tue, 7 Apr 2009 13:34:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0E00620AD2; Tue, 7 Apr 2009 22:35:10 +0200 (CEST) X-AuditID: c1b4fb3c-a76e0bb000003b08-4f-49dbb8fd99d5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D9DBC20008; Tue, 7 Apr 2009 22:35:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 22:35:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 22:34:35 +0200 Message-ID: In-Reply-To: <49DB66B2.4030908@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3j010RYvnR1AVRg+HdmST4e4IUAAKrniQ References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> <49DB66B2.4030908@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 07 Apr 2009 20:35:09.0731 (UTC) FILETIME=[5826C730:01C9B7C0] X-Brightmail-Tracker: AAAAAA== Cc: Simpletons , Jon Peterson Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 20:34:38 -0000 Hi,=20 >Right now, in MSRP, the offerer always makes the MSRP connection. This works in the following cases: > > 1. Neither party is behind a NAT (no relays) > 2. Offerer is behind a NAT, answerer is not (no relays) > 3. Both parties are behind NATs, answerer has a relay > >With comedia, the direction of the outbound MSRP connection is negotiated between the parties. This works in the=20 >following cases: > > 1. Neither party is behind a NAT (no relays) > 2. Offerer is behind a NAT, answerer is not (no relays) > 3. Offerer is not behind a NAT, answerer is (no relays) > 4. Both parties are behind NATs, answerer has a relay > 5. Both parties are behind NATs, offerer has a relay Regarding the new cases (3 and 5), the entities behind NATs (no relays) still need to know whether they are behind NATs or not, in order to set the approriate setup value?=20 Regarding 3, do the TLS issues that Remi raised apply? Many stacks also have issues with TCP simultaneous open. >In other words, comedia significantly expands the scenarios in which MSRP works. I was assuming that parties behind NATs would always use relays. But, if comedia allows legacy MSRP clients to do NAT traversal without relays, I guess they don't need relays anymore - at least not for NAT traversal purpose. Regards, Christer From hisham.khartabil@gmail.com Tue Apr 7 16:48:12 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9753A69AA for ; Tue, 7 Apr 2009 16:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drWj7ac9O4Rl for ; Tue, 7 Apr 2009 16:48:12 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id BE1F03A697D for ; Tue, 7 Apr 2009 16:48:11 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so3973319yxm.49 for ; Tue, 07 Apr 2009 16:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2uFbDV99hjibP9PCcSnOPOMbE8voFJ0V93pbpqgLTjY=; b=vj73ue882+n67fcUJhVdyDd+mp0QqgPr1CJUKM/HxGsVR0qgZeTu9sq3KXbI5ldmxP Qt6Wd5ew29HnP6UA97Ba2A/chSD+yoX1L3NCBuddeFzMfz5/1KqbKXnW0228eNel1tJu F8Uaib0jiX+V5zollk3oNljMCsCyB52Bhtw5Y= 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:content-transfer-encoding; b=wP6trPSrscZ0woZRRfsx8ccUZ7f0nui34D/jH+ATfSXsRa7YwW3ukwLpSq1IiPO70a 9CwkAqmtvxiFT56JEp4z4YF86fdooWPLuFMbKMpMkJSw9EfDXlFhXDnoC6WGFuy0MMiQ c3t8AWB4YPTTlnhknN5hWmvwM+Xcwk9tAJDh0= MIME-Version: 1.0 Received: by 10.150.196.20 with SMTP id t20mr1283943ybf.122.1239148158540; Tue, 07 Apr 2009 16:49:18 -0700 (PDT) In-Reply-To: References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> Date: Wed, 8 Apr 2009 09:49:18 +1000 Message-ID: <66cd252f0904071649n3607c49j9413ca7fc3111022@mail.gmail.com> From: Hisham Khartabil To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: adam@nostrum.com, simple@ietf.org, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 23:48:12 -0000 2009/4/7 Christer Holmberg : > > Hi, > >>In my opinion, what we need to do is standardise the comedia part > (a=3Dsetup), figure out a way to interoperate with legacy MSRP when one > side is using the c/m line to carry destination address, >>and that's it. > > Just to clarify: the draft already provides a fallback mechanism when > only one side is using the c/m line. But, that only works when there is > no SBC in the path, so that's what we need to solve. Then we're done. > > From a pure MSRP perspective, the proposal to solve that has been to > update the session mapping procedure in 4975. > > What we are have now been discussing is the TLS part, and I believe > that's where we see the main issues that still need to be sorted out. Those TLS issues are there because we are making the assumption that SBCs will modify the message. I'm suggesting that SBCs not get considered. Hisham > > Regards, > > Christer > > > > 2009/4/7 =A0: >> Hi, >> >> One of the main purposes of MSRP-ACM is to allow an SBC/ALG to modify > SDP in such a way that User Agents behind NATs will open outbound TCP > connections to that SBC/ALG and this way enabling them to communicate. > The reason why the draft does not explictly talk about this scenario is > that the IETF has not been fond of such things, so they must remain as > "public secrets". But, I think it is better to bring it all in the open > and in the draft explain how it works and even specify what the SBC/ALG > SHOULD do, to make it predicatable. >> >> Markus >> >> >>>-----Original Message----- >>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>Behalf Of ext Ben Campbell >>>Sent: 07 April, 2009 04:30 >>>To: Jon Peterson >>>Cc: Adam Roach; Simpletons >>>Subject: Re: [Simple] MSRP-ACM compatibility >>> >>> >>>On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: >>> >>>> Even setting aside my predictable objections to a Standards Track >>>> document endorsing SBCs modifying the c, m and a=3D lines of >>>SDP in SIP >>>> messages, I would be cautious about the approach under discussion. >>> >>>John's comment above inspired me to put words to another concern that >>>has been bothering me. >>> >>>Nothing in the ACM draft says that an SBC or ALG SHOULD modify >>>anything. But, the ACM draft (excepting the COMEDIA part) solves no >>>problem unless they do so. Or maybe that should be rephrased, the >>>draft not solve anything on it's own, but enable SBCs and ALGs to >>>solve the problem. >>> >>>However, SBCs and ALGs are not very predictable in their behavior. >>>There's not much in the way of standards there. I do not dispute >>>Hadriel that this may work with his company's SBCs--but I have no >>>reason to believe it will work with someone else's. Without some >>>BEHAVE like effort to at least categorize and suggest best practices >>>for these sorts of behaviors, I am skeptical of any standards effort >>>to modify protocols to work around them. >>> >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www.ietf.org/mailman/listinfo/simple >>> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From hisham.khartabil@gmail.com Tue Apr 7 16:51:36 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E983A6A72 for ; Tue, 7 Apr 2009 16:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRjI7WR1JLQD for ; Tue, 7 Apr 2009 16:51:35 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id 3D22E3A6986 for ; Tue, 7 Apr 2009 16:50:37 -0700 (PDT) Received: by gxk4 with SMTP id 4so6451249gxk.13 for ; Tue, 07 Apr 2009 16:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PjjMFYzI6JbAWbMy9vmk5Kz690NigG1rqRkELwWBy+Q=; b=EwqjGK8I8XgznKzYNIgj1I+m4LOnWlokgRYXeVU36sPXXcouh2/8jSxbCxZtiMGyjj 1+4ibRs3+udD5Qy+WsLXAqLX50OyBJWjAVfm40zRFMd4vIhzU1Xdh3xqdqpOodlnU0En kUBoTD+lIhuivUyBXzgX9ThvFla8H7fmc8PL8= 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:content-transfer-encoding; b=d9zm4zUsrKHK7KLb1NQdcbzRZ2a5xGgbPDsu0P6Mu14qWaZe56vSQVhloxl9ZMsfpb RXGAf4fqY4nMxidi3l4qsy74zrDlWMglY5Rk0WflzhkzwknkhRjKf35PH2lypV61nxX3 h2rZlftPkHDuh+bKzm6NvRZ7ShTjyagfo0f0o= MIME-Version: 1.0 Received: by 10.151.108.3 with SMTP id k3mr1315497ybm.46.1239148303765; Tue, 07 Apr 2009 16:51:43 -0700 (PDT) In-Reply-To: <49DB63A5.1090505@nostrum.com> References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> <49DB63A5.1090505@nostrum.com> Date: Wed, 8 Apr 2009 09:51:43 +1000 Message-ID: <66cd252f0904071651m3c9e4027y6bf138d4b99bb10a@mail.gmail.com> From: Hisham Khartabil To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 23:51:36 -0000 2009/4/8 Adam Roach : > Hisham Khartabil wrote: >> >> In my opinion, what we need to do is standardise the comedia part >> (a=setup), figure out a way to interoperate with legacy MSRP when one >> side is using the c/m line to carry destination address, and that's >> it. Why are we talking about an intermediary that will modify messages >> and break security? We know those boxes exist in the world, but we >> don't standarise their behaviour. Why do we want to do that now? If an >> SBC vendor wants to work with MSRP-acm, then they can do that in their >> own proprietary way. They will break security, but that's new? > > Your suggestion confuses me. What, in *your* view, is the purpose of using > c/m lines for carrying addressing information? The MSRP URL does a fine job > of that. I agree, but it is clear that some people in the wg want this method of addressing. Hisham > > /a > From christer.holmberg@ericsson.com Tue Apr 7 22:58:21 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274663A6AD0 for ; Tue, 7 Apr 2009 22:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.534 X-Spam-Level: X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 Jn-ib3YcVw6R for ; Tue, 7 Apr 2009 22:58:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0FCE03A6D58 for ; Tue, 7 Apr 2009 22:58:20 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AD92021716; Wed, 8 Apr 2009 07:59:18 +0200 (CEST) X-AuditID: c1b4fb3c-a7ee1bb000003b08-2b-49dc3d2eca78 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 568A021438; Wed, 8 Apr 2009 07:59:10 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 07:58:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 07:58:31 +0200 Message-ID: In-Reply-To: <66cd252f0904071651m3c9e4027y6bf138d4b99bb10a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm32/SGgrI67lZGR6mYiuPed1397gAKmhvA References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net><66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com><49DB63A5.1090505@nostrum.com> <66cd252f0904071651m3c9e4027y6bf138d4b99bb10a@mail.gmail.com> From: "Christer Holmberg" To: "Hisham Khartabil" , "Adam Roach" X-OriginalArrivalTime: 08 Apr 2009 05:58:59.0961 (UTC) FILETIME=[1C8A3690:01C9B80F] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 05:58:21 -0000 Hi,=20 >>>In my opinion, what we need to do is standardise the comedia part=20 >>>(a=3Dsetup), figure out a way to interoperate with legacy=20 >>>MSRP when one side is using the c/m line to carry destination address,=20 >>>and that's it. Why are we talking about an intermediary that will modify=20 >>>messages and break security? We know those boxes exist in the world,=20 >>>but we don't standarise their behaviour. Why do we want to do that=20 >>>now? If an SBC vendor wants to work with MSRP-acm, then they can do=20 >>>that in their own proprietary way. They will break security, but that's new? >> >>Your suggestion confuses me. What, in *your* view, is the purpose of=20 >>using c/m lines for carrying addressing information? The MSRP URL does >>a fine job of that. >=20 >I agree, but it is clear that some people in the wg want this method of addressing. The main requirement is to allow routing of MSRP media via intermeidates, without them having to modify the MSRP messages. If the mechanism works by the intermdiates only modifying the a=3Dpath = attribute we can discuss that option also. However, if the session contains other media than MSRP, the intermeidate would modify the c/m line anyway. But, I'm not religious - I'm probably too unacademic for that... :) Regards, Christer From hisham.khartabil@gmail.com Tue Apr 7 23:30:53 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3103A6A15 for ; Tue, 7 Apr 2009 23:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6zBuTVR9s3X for ; Tue, 7 Apr 2009 23:30:52 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 64B323A6962 for ; Tue, 7 Apr 2009 23:30:51 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so4147766yxm.49 for ; Tue, 07 Apr 2009 23:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iFV8LaF142envhdEPH0EVIr289R9YlSVt0sJSdR6XXw=; b=e3OVDdO7xwFpexMgmkxOTWXRiCNVpYd9pwk5fvT74pw/dkjSTzw73Mu0YsVwg+jX96 Xf/1JueE2yRZLes7TGLnrkMjeI2t8Hv9vfCVxmZualVYsfuc+rSfG3zmyLzbBlKwUaSu BsDpy5RNbP6QG1IGVNxsqS4HUPix1ORtFWV3w= 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:content-transfer-encoding; b=S1u4A7AIZGwbd6ysHCio1P7kSffqk+I4KJw9TrGOKw8rY5A2xm3BgqHcM8CFojM8QS odDJ6IpoQylCPQO+EQOXuv04AbvbPn5on958Bc03yCZBEGDpDt+HtbC/6xzLhPr6MHq6 UjBvTCIKbOBGZyelmUqF5y5xNsbYQPNQg4v30= MIME-Version: 1.0 Received: by 10.150.150.14 with SMTP id x14mr1854664ybd.190.1239172318082; Tue, 07 Apr 2009 23:31:58 -0700 (PDT) In-Reply-To: References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net> <66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com> Date: Wed, 8 Apr 2009 16:31:58 +1000 Message-ID: <66cd252f0904072331x27e2310h6deb2ab9116a4e6d@mail.gmail.com> From: Hisham Khartabil To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: adam@nostrum.com, simple@ietf.org, jon.peterson@neustar.biz Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 06:30:53 -0000 Hi, 2009/4/7 : > Hi, > > It's true we haven't standardized or even recommended how B2BUAs work. Bu= t hasn't that exactly led us to the problems we have with e2e security and = e2e identifiers. I understand that having > BEHAVE define recommendations on NATs does not guarantee that every NAT b= ox will follow them. The same would go for anything the IETF says about B2B= UAs. But in this MSRP case it would > be still valuable to explain how the B2BUA will act wrt. MSRP-ACM, just f= or reference if nothing more. Maybe someone can write a whitepaper for the sip or other forum. I don't think we need to recommend how to break the protocol and its security in an RFC. Hisham > > But for me this is not the main thing about this draft. The main thing wo= uld be to get the draft forward, as we clearly have a need for it. There ar= e some mobile operators who seem to have serious > plans for MSRP deployment so User Agent developers have to solve the prob= lem in some way in the next few months. Those customers won't care about TL= S issues or backwards compatibility too > much, but it is of course nice if we can solve them. > > Markus > > >>-----Original Message----- >>From: ext Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >>Sent: 07 April, 2009 10:08 >>To: Isomaki Markus (Nokia-CIC/Espoo) >>Cc: ben@estacado.net; jon.peterson@neustar.biz; >>adam@nostrum.com; simple@ietf.org >>Subject: Re: [Simple] MSRP-ACM compatibility >> >>(as an individual) >> >>In my opinion, what we need to do is standardise the comedia >>part (a=3Dsetup), figure out a way to interoperate with legacy >>MSRP when one side is using the c/m line to carry destination >>address, and that's it. Why are we talking about an >>intermediary that will modify messages and break security? We >>know those boxes exist in the world, but we don't standarise >>their behaviour. Why do we want to do that now? If an SBC >>vendor wants to work with MSRP-acm, then they can do that in >>their own proprietary way. They will break security, but that's new? >> >>Relating to interoperability, can we have the the >>acm-compliant client populate both path attribute and c/m >>lines in the offer? >> >>Hisham >> >>2009/4/7 =A0: >>> Hi, >>> >>> One of the main purposes of MSRP-ACM is to allow an SBC/ALG >>to modify SDP in such a way that User Agents behind NATs will >>open outbound TCP connections to that SBC/ALG and this way >>enabling them to communicate. The reason why the draft does >>not explictly talk about this scenario is that the IETF has >>not been fond of such things, so they must remain as "public >>secrets". But, I think it is better to bring it all in the >>open and in the draft explain how it works and even specify >>what the SBC/ALG SHOULD do, to make it predicatable. >>> >>> Markus >>> >>> >>>>-----Original Message----- >>>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>>Behalf Of ext Ben Campbell >>>>Sent: 07 April, 2009 04:30 >>>>To: Jon Peterson >>>>Cc: Adam Roach; Simpletons >>>>Subject: Re: [Simple] MSRP-ACM compatibility >>>> >>>> >>>>On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote: >>>> >>>>> Even setting aside my predictable objections to a Standards Track >>>>> document endorsing SBCs modifying the c, m and a=3D lines of >>>>SDP in SIP >>>>> messages, I would be cautious about the approach under discussion. >>>> >>>>John's comment above inspired me to put words to another >>concern that >>>>has been bothering me. >>>> >>>>Nothing in the ACM draft says that an SBC or ALG SHOULD modify >>>>anything. But, the ACM draft (excepting the COMEDIA part) solves no >>>>problem unless they do so. Or maybe that should be rephrased, the >>>>draft not solve anything on it's own, but enable SBCs and ALGs to >>>>solve the problem. >>>> >>>>However, SBCs and ALGs are not very predictable in their behavior. >>>>There's not much in the way of standards there. I do not dispute >>>>Hadriel that this may work with his company's SBCs--but I have no >>>>reason to believe it will work with someone else's. Without some >>>>BEHAVE like effort to at least categorize and suggest best practices >>>>for these sorts of behaviors, I am skeptical of any standards effort >>>>to modify protocols to work around them. >>>> >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www.ietf.org/mailman/listinfo/simple >>>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>> >> From christer.holmberg@ericsson.com Tue Apr 7 23:57:38 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C7A3A6807 for ; Tue, 7 Apr 2009 23:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.535 X-Spam-Level: X-Spam-Status: No, score=-5.535 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 foGvkJlqf3Lu for ; Tue, 7 Apr 2009 23:57:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F3C773A69DF for ; Tue, 7 Apr 2009 23:56:40 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C16C3215F8; Wed, 8 Apr 2009 08:57:46 +0200 (CEST) X-AuditID: c1b4fb3e-aa81cbb0000024d5-1a-49dc4aea6d4c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5B3CE21726; Wed, 8 Apr 2009 08:57:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 08:57:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 08:57:24 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm32/SGgrI67lZGR6mYiuPed1397gAKmhvAAAOoxnA= References: <65E8CF05-45A3-405D-938D-F731EBAC4F23@estacado.net><66cd252f0904070007h8d9e59awc674a75608c90ddf@mail.gmail.com><49DB63A5.1090505@nostrum.com><66cd252f0904071651m3c9e4027y6bf138d4b99bb10a@mail.gmail.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Hisham Khartabil" , "Adam Roach" X-OriginalArrivalTime: 08 Apr 2009 06:57:45.0879 (UTC) FILETIME=[52269A70:01C9B817] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 06:57:38 -0000 Hi, If we would go for the solution where only the a=3Dpath attribute is modified, then I guess we wouldn't need that part of the ACM draft in the first place (the draft would only contain the comedia part). The only thing we would need to do is to modify the session mapping procedures in RFC 4975, as we are discussed. Then we would basically only have one single IETF MSRP profile, which would of course be great. Would people be ok with that? Regards, Christer =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 8. huhtikuuta 2009 8:59 > To: Hisham Khartabil; Adam Roach > Cc: simple@ietf.org; jon.peterson@neustar.biz;=20 > Markus.Isomaki@nokia.com > Subject: Re: [Simple] MSRP-ACM compatibility >=20 >=20 > Hi,=20 >=20 > >>>In my opinion, what we need to do is standardise the comedia part=20 > >>>(a=3Dsetup), figure out a way to interoperate with legacy=20 > MSRP when one=20 > >>>side is using the c/m line to carry destination > address,=20 > >>>and that's it. Why are we talking about an intermediary that will > modify=20 > >>>messages and break security? We know those boxes exist in=20 > the world,=20 > >>>but we don't standarise their behaviour. Why do we want to do that=20 > >>>now? If an SBC vendor wants to work with MSRP-acm, then=20 > they can do=20 > >>>that in their own proprietary way. They will break security, but > that's new? > >> > >>Your suggestion confuses me. What, in *your* view, is the=20 > purpose of=20 > >>using c/m lines for carrying addressing information? The=20 > MSRP URL does >=20 > >>a fine job of that. > >=20 > >I agree, but it is clear that some people in the wg want=20 > this method of > addressing. >=20 > The main requirement is to allow routing of MSRP media via=20 > intermeidates, without them having to modify the MSRP=20 > messages. If the mechanism works by the intermdiates only=20 > modifying the a=3Dpath attribute we can discuss that option=20 > also. However, if the session contains other media than MSRP,=20 > the intermeidate would modify the c/m line anyway. >=20 > But, I'm not religious - I'm probably too unacademic for that... :) >=20 > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From jon.peterson@neustar.biz Wed Apr 8 12:41:41 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6FA3A68D5 for ; Wed, 8 Apr 2009 12:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoTr6KReArSY for ; Wed, 8 Apr 2009 12:41:40 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 123F23A68B5 for ; Wed, 8 Apr 2009 12:41:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239219763; x=1239306163; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=NykWSlAKxqht09ZdVDNsrTIqM+J8mA4+YvxosHzzH8B8/r+NGBgcB8iET/S2WVVdixUMK0c9PJbtcZ mWsxLERw== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.17301896; Wed, 08 Apr 2009 15:42:29 -0400 Received: from 10.31.13.120 ([10.31.13.120]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Apr 2009 19:42:24 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 08 Apr 2009 12:42:22 -0700 From: Jon Peterson To: Christer Holmberg , Hisham Khartabil , Adam Roach Message-ID: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm32/SGgrI67lZGR6mYiuPed1397gAKmhvAAAOoxnAAG0iaoQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Simpletons , "Markus.Isomaki@nokia.com" Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 19:41:41 -0000 Since the TLS problems that have been identified in this thread arise exclusively when the a=path attribute is modified and are completely irrespective of the status of the c/m lines, I fail to see how removing the bit about the c/m lines gets us any closer. If a design goal here is truly to prevent the SBCs from having the modify MSRP signaling, Bob's mail seems to suggest that even restricting the modifications to just the a=path attribute doesn't help anyway. For my part, I simply disagree with the underlying use case here. I do not believe we need to solve the problem of figuring out how a helpful intermediary can interpose itself in the middle of a TLS connection. Although the discussion has been largely about allowing that intermediary to proxy at the TCP layer (thus TLS could effectively be tunneled through it), I am a bit dubious, given that the motivation in the draft is logging and lawful interception, that tunneling TLS in this manner would really achieve the stated goal. To put it more concretely, if I attempt to contact an e-commerce website, and my browser throws me a warning about an unexpected certificate, I am rightly skeptical about divulging private information. This is exactly the exception that would arise from modifying the a=path element in the proposed manner, and a wise user in this instance has to assume the worst. In the web model, when you need a helpful intermediary you can elect to invoke it, and in so doing you will trigger no security exception. Our problem here, as usual, is the interposition of intermediaries that surprise the user, and which invoke themselves even when they are not necessary to realize the user's intention. At the risk of proposing a way forward, I would suggest that the interested parties define a new proposed intermediary function in the MSRP architecture. Talk of SBCs and B2BUAs and modifying SDP, in my opinion, merely salts wounds and guarantees that the discussion will go nowhere. Hiding behind all of this is a latent proposal of a new MSRP intermediary that instantiates a more lightweight set of features than a traditional relay, but one that is still useful in certain architectures (and presumably this function would be a role that SBCs might play). Before we worry about how this entity gets involved in an MSRP session, we need a consensus that it is sufficiently different from the MSRP relay function and worth incorporating into the MSRP architecture. If it proves prohibitive difficult to nail down what this proposed intermediary function does, then it probably isn't a good target for standardization. If we can define its behavior and arrive at a consensus that adding it to the architecture would be a good thing, though, then I think we can start figuring out how to introduce it into MSRP sessions in a way that will not startle MSRP's security mechanisms. The discussion right now, in my opinion, puts the cart way before the horse. Jon Peterson NeuStar, Inc. On 4/7/09 11:57 PM, "Christer Holmberg" wrote: > > Hi, > > If we would go for the solution where only the a=path attribute is > modified, then I guess we wouldn't need that part of the ACM draft in > the first place (the draft would only contain the comedia part). The > only thing we would need to do is to modify the session mapping > procedures in RFC 4975, as we are discussed. > > Then we would basically only have one single IETF MSRP profile, which > would of course be great. > > Would people be ok with that? > > Regards, > > Christer > > > > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 8. huhtikuuta 2009 8:59 >> To: Hisham Khartabil; Adam Roach >> Cc: simple@ietf.org; jon.peterson@neustar.biz; >> Markus.Isomaki@nokia.com >> Subject: Re: [Simple] MSRP-ACM compatibility >> >> >> Hi, >> >>>>> In my opinion, what we need to do is standardise the comedia part >>>>> (a=setup), figure out a way to interoperate with legacy >> MSRP when one >>>>> side is using the c/m line to carry destination >> address, >>>>> and that's it. Why are we talking about an intermediary that will >> modify >>>>> messages and break security? We know those boxes exist in >> the world, >>>>> but we don't standarise their behaviour. Why do we want to do that >>>>> now? If an SBC vendor wants to work with MSRP-acm, then >> they can do >>>>> that in their own proprietary way. They will break security, but >> that's new? >>>> >>>> Your suggestion confuses me. What, in *your* view, is the >> purpose of >>>> using c/m lines for carrying addressing information? The >> MSRP URL does >> >>>> a fine job of that. >>> >>> I agree, but it is clear that some people in the wg want >> this method of >> addressing. >> >> The main requirement is to allow routing of MSRP media via >> intermeidates, without them having to modify the MSRP >> messages. If the mechanism works by the intermdiates only >> modifying the a=path attribute we can discuss that option >> also. However, if the session contains other media than MSRP, >> the intermeidate would modify the c/m line anyway. >> >> But, I'm not religious - I'm probably too unacademic for that... :) >> >> Regards, >> >> Christer >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> From christer.holmberg@ericsson.com Thu Apr 9 03:22:06 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E6B3A6BFC for ; Thu, 9 Apr 2009 03:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 C6UbASZQHdW0 for ; Thu, 9 Apr 2009 03:22:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D35563A6C02 for ; Thu, 9 Apr 2009 03:21:02 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 893502153F; Thu, 9 Apr 2009 12:22:04 +0200 (CEST) X-AuditID: c1b4fb3c-aa6e6bb000003b08-0f-49ddcc4cb44d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5318D21439; Thu, 9 Apr 2009 12:22:04 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 12:22:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 12:22:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm32/SGgrI67lZGR6mYiuPed1397gAKmhvAAAOoxnAAG0iaoQACOH7Q References: From: "Christer Holmberg" To: "Jon Peterson" , "Hisham Khartabil" , "Adam Roach" X-OriginalArrivalTime: 09 Apr 2009 10:22:04.0157 (UTC) FILETIME=[071122D0:01C9B8FD] X-Brightmail-Tracker: AAAAAA== Cc: Simpletons , Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 10:22:06 -0000 =20 Hi, >Since the TLS problems that have been identified in this thread arise exclusively when the a=3Dpath attribute is modified=20 >and are completely irrespective of the status of the c/m lines, I fail to see how removing the bit about the c/m lines=20 >gets us any closer. If a design goal here is truly to prevent the SBCs from having the modify MSRP signaling, Bob's mail=20 >seems to suggest that even restricting the modifications to just the a=3Dpath attribute doesn't help anyway. > >For my part, I simply disagree with the underlying use case here. I do not believe we need to solve the problem of=20 >figuring out how a helpful intermediary can interpose itself in the middle of a TLS connection. >Although the discussion has been largely about allowing that intermediary to proxy at the TCP layer (thus TLS could=20 >effectively be tunneled through it), I am a bit dubious, given that the motivation in the draft is logging and lawful=20 >interception, that tunneling TLS in this manner would really achieve the stated goal. > >To put it more concretely, if I attempt to contact an e-commerce website, and my browser throws me a warning about an=20 >unexpected certificate, I am rightly skeptical about divulging private information. This is exactly the exception that=20 >would arise from modifying the a=3Dpath element in the proposed manner, and a wise user in this instance has to assume the=20 >worst. In the web model, when you need a helpful intermediary you can elect to invoke it, and in so doing you will=20 >trigger no security exception. Our problem here, as usual, is the interposition of intermediaries that surprise the user,=20 >and which invoke themselves even when they are not necessary to realize the user's intention.=20 >=20 >At the risk of proposing a way forward, I would suggest that the interested parties define a new proposed intermediary=20 >function in the MSRP architecture. Talk of SBCs and B2BUAs and modifying SDP, in my opinion, merely salts wounds and=20 >guarantees that the discussion will go nowhere. > >Hiding behind all of this is a latent proposal of a new MSRP intermediary that instantiates a more lightweight set of=20 >features than a traditional relay, but one that is still useful in certain architectures (and presumably this function=20 >would be a role that SBCs might play). Before we worry about how this entity gets involved in an MSRP session, we need a=20 >consensus that it is sufficiently different from the MSRP relay function and worth incorporating into the MSRP=20 >architecture. > >If it proves prohibitive difficult to nail down what this proposed intermediary function does, then it probably isn't a=20 >good target for standardization. If we can define its behavior and arrive at a consensus that adding it to the=20 >architecture would be a good thing, though, then I think we can start figuring out how to introduce it into MSRP sessions=20 >in a way that will not startle MSRP's security mechanisms. The discussion right now, in my opinion, puts the cart way=20 >before the horse. If we want to give the intermediate a specific name, instead of talking about "some SBC doing something", that's fine. It would allow us to describe how it behaves. But, as far as the actual procedures of that entity are concerned, I really don't see how we could do things in a different way than what we have discussed. The media routing path for MSRP - and other types of media - is established using SDP, so the SBC modifies the SDP in order to insert itself in the media path. Regards, Christer On 4/7/09 11:57 PM, "Christer Holmberg" wrote: >=20 > Hi, >=20 > If we would go for the solution where only the a=3Dpath attribute is=20 > modified, then I guess we wouldn't need that part of the ACM draft in=20 > the first place (the draft would only contain the comedia part). The=20 > only thing we would need to do is to modify the session mapping=20 > procedures in RFC 4975, as we are discussed. >=20 > Then we would basically only have one single IETF MSRP profile, which=20 > would of course be great. >=20 > Would people be ok with that? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > =20 >=20 >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 8. huhtikuuta 2009 8:59 >> To: Hisham Khartabil; Adam Roach >> Cc: simple@ietf.org; jon.peterson@neustar.biz;=20 >> Markus.Isomaki@nokia.com >> Subject: Re: [Simple] MSRP-ACM compatibility >>=20 >>=20 >> Hi, >>=20 >>>>> In my opinion, what we need to do is standardise the comedia part=20 >>>>> (a=3Dsetup), figure out a way to interoperate with legacy >> MSRP when one >>>>> side is using the c/m line to carry destination >> address, >>>>> and that's it. Why are we talking about an intermediary that will >> modify >>>>> messages and break security? We know those boxes exist in >> the world, >>>>> but we don't standarise their behaviour. Why do we want to do that >>>>> now? If an SBC vendor wants to work with MSRP-acm, then >> they can do >>>>> that in their own proprietary way. They will break security, but >> that's new? >>>>=20 >>>> Your suggestion confuses me. What, in *your* view, is the >> purpose of >>>> using c/m lines for carrying addressing information? The >> MSRP URL does >>=20 >>>> a fine job of that. >>>=20 >>> I agree, but it is clear that some people in the wg want >> this method of >> addressing. >>=20 >> The main requirement is to allow routing of MSRP media via=20 >> intermeidates, without them having to modify the MSRP messages. If=20 >> the mechanism works by the intermdiates only modifying the a=3Dpath=20 >> attribute we can discuss that option also. However, if the session=20 >> contains other media than MSRP, the intermeidate would modify the c/m >> line anyway. >>=20 >> But, I'm not religious - I'm probably too unacademic for that... :) >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 From KHBJ46@motorola.com Tue Apr 14 21:48:56 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D293A6A15 for ; Tue, 14 Apr 2009 21:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.301, 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 0sxr5lUqYjUp for ; Tue, 14 Apr 2009 21:48:53 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 929C43A6B23 for ; Tue, 14 Apr 2009 21:48:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: KHBJ46@motorola.com X-Msg-Ref: server-9.tower-55.messagelabs.com!1239771003!76288048!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29986 invoked from network); 15 Apr 2009 04:50:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Apr 2009 04:50:04 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n3F4nxhx010861 for ; Tue, 14 Apr 2009 21:50:03 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n3F4nxmn004641 for ; Tue, 14 Apr 2009 23:49:59 -0500 (CDT) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n3F4nvAJ004620 for ; Tue, 14 Apr 2009 23:49:58 -0500 (CDT) 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_01C9BD85.938A7076" Date: Wed, 15 Apr 2009 12:49:34 +0800 Message-ID: <7FAD6FCE52421841A11B441DEF3A88CA021ED361@ZMY16EXM70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: T.38 query!!! Thread-Index: Acm9hZKnD+Q7fmO1SVOi0YJjVvlTWw== From: "Deka Sanjeeb Kumar-KHBJ46" To: X-CFilter-Loop: Reflected Subject: [Simple] T.38 query!!! X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 04:48:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BD85.938A7076 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I am an infant in the field of Telecom. Please excuse if the query is too basic. =20 I know T.38 is a protocol for sending FAX over Internet Protocol.=20 But i wanted to know what codec it uses for encoding the data(i.e. whether T.38 itself is a codec). Is it necessary to use any codec (eg. PCMA, PCMU, G729) for encoding the data when i want to send FAX from one endpoint to another? =20 regards, san =20 ------_=_NextPart_001_01C9BD85.938A7076 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am = an infant in=20 the field of Telecom. Please excuse if the query is too=20 basic.
 
I know = T.38 is a=20 protocol for sending FAX over Internet Protocol.
But i = wanted to know=20 what codec it uses for encoding the data(i.e. whether T.38 itself is a=20 codec).
Is it = necessary to=20 use any codec (eg. PCMA, PCMU, G729) for encoding the data when i want = to send=20 FAX from one endpoint to another?
 
regards,
san
 
------_=_NextPart_001_01C9BD85.938A7076-- From ben@estacado.net Thu Apr 16 15:24:25 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DCC33A6DF4 for ; Thu, 16 Apr 2009 15:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTPeNO1PM8VY for ; Thu, 16 Apr 2009 15:24:24 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 6983B3A6D0D for ; Thu, 16 Apr 2009 15:24:24 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-137.dsl.rcsntx.swbell.net [68.94.44.137]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n3GMPUjg007393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 16 Apr 2009 17:25:35 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <5EFAF624-8101-41B8-B173-E7E77129E243@estacado.net> From: Ben Campbell To: Simple WG In-Reply-To: <66cd252f0904052227o32a1513an4e4d55f7b29173c6@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 17:25:30 -0500 References: <66cd252f0904052227o32a1513an4e4d55f7b29173c6@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Simple] WGLC for draft-ietf-simple-chat-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 22:24:25 -0000 Just a reminder--there's a bit over a week left on this WGLC and we've not seen any reviews. Even reviews of the form of "it's fine like it is" are useful. Thanks! Ben. On Apr 6, 2009, at 12:27 AM, Hisham Khartabil wrote: > This is to initiate a working group last call (WGLC) for Multi-party > Chat Using MSRP draft (draft-ietf-simple-chat-04). > > http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-04.txt > > This is a 3 week WGLC instead of the usual 2 to accommodate for the > long Easter weekend. > > Please send your comments to the SIMPLE mailing list as well as the > authors. Please also let the authors, WG chairs and group know if you > have read the draft and believe there are no issues with it. > > Minor nits are also important to fix and welcome. > > Much appreciated, > Hisham > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Thu Apr 16 16:07:01 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6C93A693A for ; Thu, 16 Apr 2009 16:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnk0t4AJO8bT for ; Thu, 16 Apr 2009 16:07:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 321413A6858 for ; Thu, 16 Apr 2009 16:07:00 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Apr 2009 19:08:12 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 16 Apr 2009 19:08:12 -0400 From: Hadriel Kaplan To: Jon Peterson , Ben Campbell , Christer Holmberg Date: Thu, 16 Apr 2009 19:08:11 -0400 Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3Eykv0QDIicli2EaspoGXdu08cwH0QvCA Message-ID: References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> 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 Cc: Adam Roach , Simpletons Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:07:01 -0000 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Jon Peterson > Sent: Monday, April 06, 2009 7:55 PM >=20 >=20 > I think what's missing in the discussion of the TLS component of MSRP-ACM > is > a glance back at 9.3 of RFC4976 - that is, a question of what we're hopin= g > to prevent with TLS in this case. TLS serves a number of purposes in the > MSRP relay architecture, but the salient one here is to allow the client > the > opportunity to authenticate the next hop to which its traffic will not be > confidential.=20 If I understand your comment, the property you believe is important is that= when a MSRP client is given an MSRPS next-hop to connect to, that it be ab= le to verify at the MSRP TLS connection level that it is in fact talking to= that next-hop. Correct? I agree with that being a very good property. =20 Luckily TLS relies on Certificate CNs/SANs, not IP Addresses/ports, for ide= ntity. (unlike some other identity mechanisms we've been discussing lately = ;)=20 If I am told to talk to foobar.com, it does not matter what IP/port at laye= r-3 I am talking to, so long as it has foobar.com's Cert. =20 So I think what we need in ACM is to provide a way to indicate what (1) the= IP/port to connect to is, vs. (2) what Cert identity to be verified is. C= omedia-tls (rfc4572) does that with a fingerprint attribute, but we have be= en discussing on this list what the appropriate way to do that for the ACM = case is. > The mandate of TLS usage by MSRP relays is supposed to > ensure > message confidentiality to the hop identified by the MSRPS URI. There's n= o > point in keeping something encrypted on the wire only to hand it over to > someone you can't identify - why bother to have kept it confidential at > all? The proposal has not been to hand it over to someone you can't identify. =20 > Furthermore, into the details of the proposal a bit, I think I understand > what you do when the offerer has a relay and the answerer has an SBC, and > the SBC needs to modify the offerer's c/m and a=3Dpath:, but I'm a bit > hazier > on how you modify the answerer's SDP in this case in such a way that the > offerer's relay will send MSRP to the SBC on it's way to the client. What > does that case look like? The current draft-acm does not consider working with rfc4976 Relays. One o= f the discussions on the list has been about how to go about doing that, wi= th as few changes as possible to Relays. -hadriel From christer.holmberg@ericsson.com Mon Apr 20 01:14:58 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45343A6B69 for ; Mon, 20 Apr 2009 01:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 w1JHeijadCaf for ; Mon, 20 Apr 2009 01:14:57 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9951B3A6925 for ; Mon, 20 Apr 2009 01:14:57 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D917B2160A; Mon, 20 Apr 2009 10:14:27 +0200 (CEST) X-AuditID: c1b4fb3e-abf85bb000005486-1e-49ec2dcee9e2 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 17BC120FA3; Mon, 20 Apr 2009 10:09:50 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 10:09:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2009 10:09:44 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: Acm3Eykv0QDIicli2EaspoGXdu08cwH0QvCAAKp8ocA= References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Jon Peterson" , "Ben Campbell" X-OriginalArrivalTime: 20 Apr 2009 08:09:45.0931 (UTC) FILETIME=[5E0F39B0:01C9C18F] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Simpletons Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:14:59 -0000 Hi,=20 >>I think what's missing in the discussion of the TLS component of=20 >>MSRP-ACM is a glance back at 9.3 of RFC4976 - that is, a question of=20 >>what we're hoping to prevent with TLS in this case. TLS serves a=20 >>number of purposes in the MSRP relay architecture, but the salient one >>here is to allow the client the opportunity to authenticate the next=20 >>hop to which its traffic will not be confidential. > >If I understand your comment, the property you believe is important is that when a MSRP client is given an MSRPS next-hop=20 >to connect to, that it be able to verify at the MSRP TLS connection level that it is in fact talking to that next-hop. =20 >Correct? I agree with that being a very good property. =20 > >Luckily TLS relies on Certificate CNs/SANs, not IP Addresses/ports, for identity. (unlike some other identity mechanisms=20 >we've been discussing lately ;)=20 > >If I am told to talk to foobar.com, it does not matter what IP/port at layer-3 I am talking to, so long as it has=20 >foobar.com's Cert. =20 > >So I think what we need in ACM is to provide a way to indicate what (1) the IP/port to connect to is, vs. (2) what Cert=20 >identity to be verified is. Comedia-tls (rfc4572) does that with a fingerprint attribute, but we have been discussing on=20 >this list what the appropriate way to do that for the ACM case is. During the off-line discussions in SFO we also discussed the usage of such fingerprint attribue for ACM. Regards, Christer From Markus.Isomaki@nokia.com Tue Apr 21 08:09:22 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A923A6901 for ; Tue, 21 Apr 2009 08:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 6Nwp0rWuoiDG for ; Tue, 21 Apr 2009 08:09:22 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8E1013A6AC8 for ; Tue, 21 Apr 2009 08:09:21 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3LF9bl3027918; Tue, 21 Apr 2009 18:09:57 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 18:09:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 18:09:21 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 21 Apr 2009 17:09:21 +0200 From: To: , , , Date: Tue, 21 Apr 2009 17:09:19 +0200 Thread-Topic: MSRP-ACM high level issues Thread-Index: Acm3Eykv0QDIicli2EaspoGXdu08cwH0QvCAAOsTyxA= Message-ID: References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> 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-OriginalArrivalTime: 21 Apr 2009 15:09:21.0626 (UTC) FILETIME=[265B2BA0:01C9C293] X-Nokia-AV: Clean Cc: adam@nostrum.com, simple@ietf.org Subject: [Simple] MSRP-ACM high level issues X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:09:22 -0000 Hi, Is it fair to say that MSRP-ACM draft currently has two main high level iss= ues: 1. How it works with TLS 2. How it can interoperate when the other end is using an MSRP relay Based on the discussion so far it seems that issue 1. can be technically so= lved, while with issue 2. there is no clean solution unless we also assume = updating the baseline MSRP specs (and implementations). Correct? I see value in going forward with the MSRP-ACM spec if we can: * address the TLS concern. * make the solution such that it allows the endpoints to establish the TCP = connection without any relays or middleboxes as long as one end can receive= TCP connections (e.g., it has a public address and is not firewalled). * make it possible for a B2BUA to manipulate the SDP in *MSRP-agnostic mann= er* (i.e., using the mechanisms they use for any TCP/TLS connections using = comedia) so that two endpoints who are both behind NAT can establish connec= tivity through the B2BUA. * make it possible to use ICE and TURN-TCP as yet another NAT traversal opt= ion for MSRP.=20 * address the backwards compatibility issue by introducing a small update/e= xtension to current MSRP RFCs (as long as there are no major deployments ye= t, I consider this still a reasonable requirement). Do we have a consensus over this set of requirements/targets? Markus = From mary.barnes@nortel.com Tue Apr 21 16:22:46 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917393A6B27 for ; Tue, 21 Apr 2009 16:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 UOOwgpAooBCM for ; Tue, 21 Apr 2009 16:22:45 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id AEE3328C1D6 for ; Tue, 21 Apr 2009 16:22:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3LNMkh21752; Tue, 21 Apr 2009 23:22:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Apr 2009 18:26:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D94512B@zrc2hxm0.corp.nortel.com> In-Reply-To: <5EFAF624-8101-41B8-B173-E7E77129E243@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC Review: draft-ietf-simple-chat-04 Thread-Index: Acm+4kyb2Xvi3cEqRhSpHxquTpbsPgDw4C/Q References: <66cd252f0904052227o32a1513an4e4d55f7b29173c6@mail.gmail.com> <5EFAF624-8101-41B8-B173-E7E77129E243@estacado.net> From: "Mary Barnes" To: "Simple WG" Cc: draft-ietf-simple-chat@tools.ietf.org Subject: [Simple] WGLC Review: draft-ietf-simple-chat-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 23:22:46 -0000 Document: draft-ietf-simple-chat-04 Reviewer: Mary Barnes Review Date: April 21, 2009 WGLC LC End Date: April 27, 2009 Summary: On the right track but needs a good bit more work prior to progressing. General comments/questions/caveats: ----------------------------------- 1) Caveat and comments: I am not an MSRP expert and the doc really needs review by one prior to forwarding, in particular with regards to ensuring normative protocol changes are correct. Obviously, if Ben is the PROTO shepherd, that should cover it. However, my personal opinion is the doc needs a couple more detailed reviews, or at a minimum feedback that folks believe the document is ready, since it is standard's track.=20 2) General question: Does anyone have a implementation of MSRP chat? That might help identify additional reviewers and would certainly help validate the completeness of the protocol changes in this document.=20 3) General question: What is the relationship between the "MSRP Switch" and an "MSRP Relay"? It might be good to also show a diagram of how the "MSRP Switch" fits into the overall MSRP model, including relays. This may be quite obvious to most folks, but I think it would help the average developer understand the "big picture". It would also help to clarify this in the definition of "MSRP Switch" (in Terminology - section 2) since the definition uses the term "relay". One suggestion might be to use the term "distributed" or "replicated and forwarded", which is the term that is used in the XCON chat document.=20 4) Caveat: I did not review the call flows in detail. Again, if there's an implementation, it might be good to pull real call flows or have one of the implementers validate the call flows in the document. Larger issues (i.e., must be resolved prior to leaving WG): ----------------------------------------------------------- 1) Section 6.2 Private Messages: Either I'm not understanding OR there is some duplicate text between paragraphs 5 (starting with "If the recipient is valid...") and paragraph 7. I also found that text rather dense and think that a table might help to clarify the handling of the various cases of support (or not) of private messages. Also, it might help to add some more discrete sections to section 6.2. In particular, it might help to split out the "sender" versus "recipient" processing, as well as "MSRP Switch". 2) Nicknames a) Section 3 (Requirements) i) REQ-3: deals with determining identities. I'm assuming this should include Nicknames, however, the definition of Nickname doesn't put it into the general category of being an Identifer. So, perhaps the definition of Nickname (in section 2) should be changed to something like the following OR a separate requirement for Nicknames should be added: OLD Nickname: a pseudonym or descriptive name associated to a participant. See Section 7 for details NEW Nickname: an additional identifier for a user which provides a pseudonym or descriptive name associated with the participant. See Section 7 for details This would consistent with its description in 7.1 - i.e., the statement "Nicknames are an alternate form of identity, associated ....." b) If a Nickname is another form of identifier, it should be mentioned in section 6.1 in the list of identities.=20 c) Section 7, 1st paragraph, last sentence. This is where some of my confusion is introduced, if a Nickname is another form of Identifier, then it doesn't seem to me that anonymity is being preserved. This likely be more clear when the security considerations are further documented.=20 d) Section 7.1 (Using Nicknames): i) Paragraph 4 introduces a normative reference to P-Asserted-Identity (RFC 3325) since this is the only mechanism described for the validation of the SIP AOR for Nicknames. =20 ii) RFC 3325 is not currently listed as a reference, but needs to be added (to the normative section).=20 iii) This security requirement needs to be added to the Security Considerations (Section 11). And, actually a more detailed description of potential security issues around the use of Nicknames should be added to Section 11. e) Section 7.2 & 7.3(Modifying a Nickname and Removing a Nickname): These sections do not seem to address the reuse of a Nickname that has been changed (i.e., the old one) or one that has been deleted. It would seem that the Nickname should certainly not be reusable within the same chat room instance in which it was previously being used. And, it would seem that a specific or recommended length of time should be associated with a system reusing a specific Nickname.=20 f) Section 7.4 (Nicknames in the Conference Event Package): Aren't you adding the attribute to the "user-type" attribute rather than the the "user" element? It would be helpful either way to show the new attribute as it would appear in the context of the schema for clarity Also, it might be nice to add an example Conference Event notification to one of the examples.=20 Minor issues (i.e., wbn to resolve or clarify prior to leaving WG): ------------------------------------------------------------------ 1) Section 3 (Requirements): REQ-10: I would suggest that you delete the "(and perhaps others)" from that requirement. It doesn't seem reasonable to have that as a core requirement since it's open ended, thus you can't be sure this solution would address the "others".=20 2) Section 5.2 - this section doesn't seem to mention how conference "unaware" participants are involved. Based on the 1st sentence of the second paragraph of the Requirements (section 3) I understood that they would be supported. If not, then that needs to be documented.=20 3) Section 6.1, second paragraph after the bulleted list, first sentence. I think the "Then" needs to be qualified, since this processing wouldn't occur unless the URI is valid. Thus, I would suggest to preface that sentence with "If the URI is valid, then" 4) Section 8, 2nd paragraph: How does the switch respond (to the sender) in the case of a message sent to a participant that does not support the functionality in this document? It would seem that the sender should be notified, so that Alice could be contacted via another mechanism or the chat room host might want to pick an alternate mechanism for communicating. =20 Nits/editorial comments (depending upon who does the gen-art review, you will likely see them again, so it's likely easier to address now):=20 ------------------------------------------------------------------------ ------- 1) Section 1 (Introduction): There's a bit of redundancy in this section. It would add clarity to move the 4th paragraph prior to the current 3rd and delete the first sentence in the current third paragraph as it's redundant with that in the 4th. The 2nd sentence of the third paragraph is really too detailed and would fit much better as an intro to the 5th paragraph. Thus, I would suggest the following changes: OLD (3rd P): Several such systems already exist in the Internet. Participants in a chat room can be identified with a pseudonym or nickname, and decide whether their real identity is disclosed to other participants. Participants can also use a rich set of features such as the ability to send private instant messages to other participants. They also allow combining instant messaging with other media components, such as voice, video, white boarding, screen sharing, and file transfer. OLD (4th P): Similar conferences are already available today with other technologies different than MSRP. For example, Internet Relay Chat (IRC) [RFC2810], Extensible Messaging and Presence Protocol [RFC3920] based chat rooms, and many other proprietary systems provide this kind of functionality. It makes sense to specify equivalent functionality for MSRP-based systems to both provide competitive features as well as enable interworking between the systems. OLD (5th P): =20 This document defines requirements, conventions, and extensions for providing private messages and nickname management in centralized conferences with MSRP. This document, however, does not specify functionality that can be used in conference with media different than MSRP. This memo uses the SIP Conferencing Framework [RFC4353] as a design basis. It also aims to be compatible with the Centralized Conferencing Framework [I-D.ietf-xcon-framework]. It is expected that future mechanisms will be developed for providing similar functionality in generic conferences, i.e., where the media is not only restricted to MSRP. The mechanisms described in this document provide a future compatible short-term solution for MSRP centralized conferences. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEW (with some minor = editorial changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEW (merging 4th paragraph with the 3rd): =20 Similar conferences supporting chat rooms are already available today supporting media other than MSRP. For example, Internet Relay Chat (IRC) [RFC2810], Extensible Messaging and Presence Protocol [RFC3920] based chat rooms, and many other proprietary systems provide chat room functionality. Specifying equivalent functionality for MSRP-based systems provides competitive features and enables interworking between the systems. =20 While existing systems combine instant messaging with other media components, such as voice, video, white boarding, screen sharing, and file transfer, this document does not specify functionality associated with media other than MSRP.=20 NEW (5th paragraph (with some 3rd paragraph text) becoming the 4th paragraph):=20 This document defines requirements, conventions, and extensions for providing private messages and nickname management in centralized conferences with MSRP. Participants in a chat room can be identified with a pseudonym or nickname, and decide whether their real identity is disclosed to other participants. Participants can also use a rich set of features such as the ability to send private instant messages to other participants. This memo uses the SIP Conferencing Framework [RFC4353] as a design basis. It also aims to be compatible with the Centralized Conferencing Framework [RFC5239]. It is expected that future mechanisms will be developed for providing similar functionality in generic conferences, i.e., where the media is not only restricted to MSRP. The mechanisms described in this document provide a future compatible short-term solution for MSRP centralized conferences. 2) Section 2 (Terminology): a) Private Instant Message - suggest the following change: OLD Private Instant Message: an instant message sent in a chat room whose intended to a single participant. A private IM is usually rendered distinctly from the rest of the IMs, as to indicate that the message was a private communication. NEW Private Instant Message: an instant message sent in a chat room intended for a single participant. A private IM is usually rendered distinctly from the rest of the IMs, indicating that the message was a private communication. b) Anonymous URI: "..in the a..." -> "...in the..." 2) Section 6.2 (Private Messages): a) 3rd paragraph, 1st sentence: It's not clear to me what is meant by "regular instant message". Is it referring to the "received" instant message which is to be sent to the specific participant.=20 b) 5th paragraph, 3rd sentence: "...cased by..." -> "...caused by...." 3) Section 7.1 (Nicknames) a) 1st paragraph: "as long as the participants is" -> "as long as the participantis" b) 1st paragraph: "other mechanisms may exists" -> "other mechanisms may exist"=20 4) Section 7.5 - "chat room do not allow" -> "chat room does not allow" 5) Section 8, 6th paragraph (the one right after the attribute syntax): i) "allows to use the procedures" -> "allows the use of the procedures" (2 occurences) 6) In addition to the nits listed above, the IDNITS identified below must be fixed prior to forwarding the document.=20 idnits 2.11.08=20 tmp/draft-ietf-simple-chat-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): =20 ------------------------------------------------------------------------ ---- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: =20 ------------------------------------------------------------------------ ---- No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: =20 ------------------------------------------------------------------------ ---- No issues found here. Miscellaneous warnings: =20 ------------------------------------------------------------------------ ---- =3D=3D Line 602 has weird spacing: '...ssaging and P...' =3D=3D Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). =20 Found 'MUST not' in this paragraph: =20 Then the MSRP switch MUST inspect the To header field of the Message/ CPIM wrapper. If the To header field of the Message/CPIM wrapper does not contain the chat room URI, it must check if it contains a participants URI associated with a participant. If the URI in the To header can not be resolved (e.g. cased by a mistyped URI or that the recipient has abandoned he chat room), and the Failure-Report header field of the SEND request was either not present in the original request, or had a value of "yes" or "partial", the MSRP switch MUST generate a REPORT request to the sender. The status header field MUST be set to 427. The new 427 status code indicates a failure to resolve the recipient URI in the To header field. If the recipient is valid, but the recipient does not support private messages, and the Failure-Report header field of the SEND request was either not present in the original request, or had a value of "yes" or "partial", the MSRP switch MUST send a REPORT request having the status code of 428. The new response 428 indicate that the recipient does not support private messages. In either case the REPORT request MUST include a Message/CPIM wrapper, with the original From header field included in the SEND request, and the To header field of the original message. The message MUST not be forwarded to the recipient if above conditions applies. The MSRP switch should search it's mapping table to find the MSRP session established towards the recipient. If a match is found the MSRP switch MUST create a SEND request and MUST copy the contents of the sender's message to it. Checking references for intended status: Proposed Standard =20 ------------------------------------------------------------------------ ---- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) =3D=3D Outdated reference: draft-ietf-xcon-framework has been = published as RFC 5239 Summary: 1 error (**), 3 warnings (=3D=3D), 0 comments (--). From Martin.Thomson@andrew.com Wed Apr 22 18:07:36 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F483A6D28 for ; Wed, 22 Apr 2009 18:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANRWJQBbXCHy for ; Wed, 22 Apr 2009 18:07:35 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6EF9E3A6C65 for ; Wed, 22 Apr 2009 18:07:35 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_22_20_29_28 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 22 Apr 2009 20:29:28 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 20:08:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 22 Apr 2009 20:08:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: common-policy/presence-policy/presence-policy expansive transformation Thread-Index: AcnDsA45YTaORHFmS++2vrZ5vjJQWQ== From: "Thomson, Martin" To: "Simple WG" X-OriginalArrivalTime: 23 Apr 2009 01:08:48.0931 (UTC) FILETIME=[0EF41F30:01C9C3B0] Subject: [Simple] common-policy/presence-policy/presence-policy expansive transformation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 01:07:36 -0000 QXMgZmFyIGFzIEkgY2FuIGRldGVybWluZSwgdHdvIHRoaW5ncyBhcmUgbm90IHBvc3NpYmxlIHdp dGggY29tbW9uLXBvbGljeSBhbmQgaXQncyBwcm9nZW55Og0KDQogLSBJdCdzIG5vdCBwb3NzaWJs ZSB0byByZW1vdmUgUElERiBlbGVtZW50czogYmFzaWMgc3RhdHVzLCB0dXBsZSwgdGltZXN0YW1w LCBhbmQgc28gb24uDQoNCiAtIEl0J3Mgbm90IHBvc3NpYmxlIHRvIHBlcm1pdCBhY2Nlc3MgdG8g cHJlc2VuY2Ugb2YgYW55IHR5cGUsIGVhY2ggdHlwZSBvZiBkYXRhIG11c3QgYmUgZXhwbGljaXRs eSBwZXJtaXR0ZWQuDQoNCk9mIGNvdXJzZSwgdGhpcyBpcyBhbGwgYmFzZWQgb24gdGhlIHRleHQg aW4gU2VjdGlvbiAzLjMuMiBvZiBSRkMgNTAyNSAtIHRoZSBvbmx5IHRleHQgb24gdGhlIHN1Ympl Y3QgdGhhdCBJIGNhbiBmaW5kIC0gYW5kIGEgbGl0dGxlIGluZmVyZW5jZS4NCg0KV2FzIHRoaXMg YSBjb25zY2lvdXMgZGVjaXNpb24gb3IganVzdCBhbiBvdmVyc2lnaHQ/IElmIHRoaXMgd2FzIGlu dGVudGlvbmFsLCB3aHk/DQoNCk9uIHRoZSBmaXJzdCwgdGhpcyBwcmV2ZW50cyB0aGUgdXNlIG9m IGEgZ2VuZXJpYyBwcmVzZW5jZSBhZ2VudCBmb3IgdGhlIGRpc3RyaWJ1dGlvbiBvZiBhIHNpbmds ZSB0eXBlIG9mIHByZXNlbmNlIGluZm9ybWF0aW9uLiAgSWYsIGZvciBzYWtlIG9mIGFyZ3VtZW50 LCBJIHdhbnQgdG8gZGlzdHJpYnV0ZSBteSBsb2NhdGlvbiBvbmx5LCBJIGNhbid0IHVzZSBhIFBB IHRoYXQga25vd3MgbXkgYmFzaWMgc3RhdHVzLCBiZWNhdXNlIGl0IHdpbGwgc2VuZCB0aGlzIHRv IHdhdGNoZXJzIHJlZ2FyZGxlc3Mgb2YgbXkgcG9saWN5Lg0KDQpPbiB0aGUgc2Vjb25kLCB0aGlz IHByZXZlbnRzIHRoZSB1c2Ugb2YgcHJlc2VuY2UgZXh0ZW5zaW9ucyB0aGF0IHRoZSBQQSBlaXRo ZXIgZG9lc24ndCB1bmRlcnN0YW5kIG9yIHdoZXJlIHRoZXJlIGFyZSBubyBtYXRjaGluZyA8cHJv dmlkZS0uLi4+IGVsZW1lbnRzIGRlZmluZWQuICBBcyBJIHVuZGVyc3RhbmQsIHRoZSBQQSBpcyBv YmxpZ2VkIHRvIHJlbW92ZSBleHRlbnNpb25zIGluIHRoaXMgY2FzZS4gIE9mIGNvdXJzZSwgSSBj YW4ndCBmaW5kIGFueXRoaW5nIHRoYXQgYWRkcmVzc2VzIHRoaXMgaXNzdWUgZGlyZWN0bHkuICAN CiANCihJJ3ZlIGNvbW1lbnRlZCBwcmV2aW91c2x5IGFib3V0IHRoZSBhc3NvY2lhdGVkIGNvc3Qg b2YgYnVpbGRpbmcgYSBzeXN0ZW0gdGhhdCByZWxpZXMgb24gZGVmaW5pbmcgY3VzdG9tIGVsZW1l bnRzIGxpa2UgdGhvc2UgcHJlc2VuY2UtcG9saWN5IGFuZCBwcmVzZW5jZS1jYXBhYmlsaXRpZXMg cmVseSB1cG9uLCB0aGlzIGlzIG9uZSBzdWNoIGNvc3QuKQ0KDQpXb3VsZCBpdCBiZSB1c2VmdWwg aWYgSSB3cm90ZSBhIGRyYWZ0IGV4cGxhaW5pbmcgdGhlIHByb2JsZW0gYW5kIGRlc2NyaWJpbmcg ZXh0ZW5zaW9ucyB0byBwcmVzZW5jZS1wb2xpY3kvY29tbW9uLXBvbGljeSB0aGF0IHJlbW92ZWQg dGhlIHJlc3RyaWN0aW9ucz8NCg0KLS1NYXJ0aW4NCg0KcC5zLiBPdXQgb2YgaW50ZXJlc3QncyBz YWtlIG1vcmUgdGhhbiBhbnl0aGluZywgYXJlIHRoZXJlIG1hbnkvYW55IGltcGxlbWVudGF0aW9u cyBvZiB0aGVzZSBzcGVjaWZpY2F0aW9ucz8NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBp ZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3Ro ZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUg dGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJv aGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0N Cg== From ben@nostrum.com Fri Apr 24 13:22:15 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E7A3A68D5 for ; Fri, 24 Apr 2009 13:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ8ZmBVzPZmS for ; Fri, 24 Apr 2009 13:22:13 -0700 (PDT) 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 4CD9628C111 for ; Fri, 24 Apr 2009 13:22:13 -0700 (PDT) Received: from dn3-213.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 n3OKNTPR007453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2009 15:23:29 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 15:23:29 -0500 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-simple-chat@tools.ietf.org Subject: [Simple] WGLC Review of draft-ietf-simple-chat-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 20:22:15 -0000 (as individual contributor) Summary: This is improving, but there are still some issues that need work. *** Major Issues: *** 1) This draft depends on the use of message/cpim envelopes to determine the final recipients of a message. The draft does not take into account that with large content, the overall message may be broken into chunks. Chunks subsequent to the initial one will not contain the CPIM headers. How does an MSRP conference switch figure out how to process a mid-message chunk? I can think of two choices off hand: a) The MSRP switch has to fully assemble each message prior to sending to final recipients. This will be a problem for large messages, and would only be remotely feasible with rather draconion message size policies. b) The MSRP switch must be "message-id stateful", so that once it processes an initial chunk, it knows to treat any future chunks with the same message-id the same way. Both of these require keeping more state than I like, but short of ditching the CPIM approach altogether, I think b) is the best we can do. Whichever route we go, this draft needs discussion and examples of switching chunked messages. 2) The draft still has inconsistencies and errors in the way it interacts with MSRP reporting complexities. I commented on this in a previous version, and the author added language in some sections, but other sections still assume a single reporting model. Also, the current language replicates a lot of normative text from RFC4975, which I think is a mistake. I think it would be better to treat status reporting abstractly, and have a separate section that talks about how this maps into MSRPs reporting models. For example, if the normative sections in this draft says things like "If condition FOO occurs, send an XXX response", it would be better to say "If condition FOO occurs, return an error code of XXX". Then in a separate section, point out that MSRP has multiple ways of reporting status (including simply not reporting it at all) , and that implementations must follow the those same mechanisms for any new error conditions described in this document. I think this would also help to reduce the dense, complex language that Mary commented on in her review. 3) The draft starts off saying that it does not address conferences including media types other than MSRP, yet it goes on to say that MSRP streams are likely to be part of mixed-media conferences. Req-2 even states this as a requirement. If we _do_ want this to cover mixed media conferences, then I will have to open old wounds around the sending of nickname reservations in MSRP rather than in the signaling channel, as I think otherwise you risk nicknames getting out of sync for the different media types. I think the best solution at this point is to simple search and destroy any text in the draft implying that this is for mixed-media conferencing. *** Minor Issues and Editorial Comments: *** -- Section 1, last paragraph: This paragraph needs some wordsmithing. It currently makes a number of otherwise unrelated assertions about the document. -- Section 2, paragraph 2: What do we mean by "tightly coupled"? Are there such things as "loosely coupled" conferences? -- Definition of Chat Room URI: Are we talking about SIP URIs or MSRP URIs? -- Definition of MSRP switch: Need to clarify that a switch is an MSRP endpoint, not a relay. -- Definition of Anonymous URI: Need reference for GRUU. Also, please expand the acronym on first mention. -- Section 3: Should the numbered requirements use RFC2119 normative language? -- Req-2: This seems to contradict previous statements that this draft does not enable mixed-media conferences. Do we not fulfill this requirement? -- Req-3: Does Req-8 contravene this requirement? -- Req-4: By "determine the recipient", do you mean a participant must be able to select the destination of a message it sends, or learn all the recipients of a received message? -- Req-9: I don't think the requirement is really that the switch can originate messages, but that the conference owner or administrator may send messages to the conference (possibly by using some automated agent.) As stated, the requirement has an architectural assumption that the switch is that agent. -- Req-10: Learn features supported by what? The switch? Other participants? Also, the "perhaps others" language adds vagueness. -- Section 4: Paragraph 1: Need more precision on whether you are talking about signaling, media, or both. I infer signaling from the UA and Focus terms, but it would be better to be explicit. -- Paragraph 1: "Each conference participant establishes an MSRP session with an MSRP switch,..." We're talking about the same switch, right? i.e. "the MSRP switch" rather than "an MSRP switch"? -- Figure 1: It would be nice to show or reference a picture showing how the MSRP switch relates to the conference focus. -- Last paragraph: Need more precision on SIP vs MSRP, i.e. sends a SIP BYE request, and disconnects the MSRP session. -- Section 5.2, paragraph 1: It's not always an "additional" message media type--we could have an MSRP only conference, right? -- Last paragraph: How can a participant not support receipt of private messages and otherwise support MSRP? What makes them different from any other MSRP message that the switch would send? -- Section 5.3: Regardless of policies on _when_ a chat-room gets deleted, what actually happens when an in-progress chatroom is deleted? -- First paragraph after bullet list: Second sentence is redundant with the bullet list. -- Paragraph 10: Do we need to think about IMDN? -- Last Paragraph: I think this is a cut/paste or other edit error, as it seems to be redundant with several previous statements. -- Section 6.2: The bulk of this section is identical to that for regular messages. Is the only difference that the private message contains a particular user in the CPIM To header, and the new error code? If so, you could just explain the difference, and say all the rest is as usual. -- Also, since the CPIM To header could contain several kinds of URLs, you need to say something more about identity matching according to the matching rules of the URL scheme. -- 2nd to last paragraph: Redundant paragraph--editing error? -- Section 7.5: Are there normative statements implied in this section? Also, 2nd sentence is a fragment. -- Section 8, 2nd paragraph: The question of whether an endpoint supports private messages makes me wonder if a generic MSRP endpoint is going to work with normal conference messages, where the CPIM To header does not match the recipient identity. -- Examples: We need an example of a multi-chunk message sent to a conference. Section 9.4: Need an example showing an error sending the private message to the final recipient. Section 9.5: This is entirely a gruu example--does it belong in this draft? From christer.holmberg@ericsson.com Sun Apr 26 23:40:31 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852653A6B6A for ; Sun, 26 Apr 2009 23:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.81 X-Spam-Level: X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ETB9mzWK0Mql for ; Sun, 26 Apr 2009 23:40:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 53B3A3A684D for ; Sun, 26 Apr 2009 23:40:30 -0700 (PDT) X-AuditID: c1b4fb3c-b7b64ae0000053f1-1a-49f553ad19bf Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 75.B3.21489.DA355F94; Mon, 27 Apr 2009 08:41:49 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 08:41:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 08:41:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP-ACM high level issues Thread-Index: Acm3Eykv0QDIicli2EaspoGXdu08cwH0QvCAAOsTyxABHEMM8A== References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> From: "Christer Holmberg" To: , , , X-OriginalArrivalTime: 27 Apr 2009 06:41:49.0040 (UTC) FILETIME=[3DADCF00:01C9C703] X-Brightmail-Tracker: AAAAAA== Cc: adam@nostrum.com, simple@ietf.org Subject: Re: [Simple] MSRP-ACM high level issues X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 06:40:31 -0000 Hi,=20 >Is it fair to say that MSRP-ACM draft currently has two main=20 >high level issues: >1. How it works with TLS >2. How it can interoperate when the other end is using an MSRP relay >=20 >Based on the discussion so far it seems that issue 1. can be=20 >technically solved, Yes. For example, nobody has objected to the usage of the fingerprint attribute. >while with issue 2. there is no clean solution unless we also assume updating the baseline MSRP specs (and implementations). Correct? Correct. >I see value in going forward with the MSRP-ACM spec if we can: >* address the TLS concern. >* make the solution such that it allows the endpoints to=20 >establish the TCP connection without any relays or=20 >middleboxes as long as one end can receive TCP connections=20 >(e.g., it has a public address and is not firewalled). >* make it possible for a B2BUA to manipulate the SDP in=20 >*MSRP-agnostic manner* (i.e., using the mechanisms they use=20 >for any TCP/TLS connections using comedia) so that two=20 >endpoints who are both behind NAT can establish connectivity=20 >through the B2BUA. >* make it possible to use ICE and TURN-TCP as yet another NAT=20 >traversal option for MSRP.=20 >* address the backwards compatibility issue by introducing a=20 >small update/extension to current MSRP RFCs (as long as there=20 >are no major deployments yet, I consider this still a=20 >reasonable requirement). >=20 >Do we have a consensus over this set of requirements/targets? I think they seem reasonable. Regarding manipulating the SDP in a "MSRP-agnostic manner": For non-MSRP media, the B2BUA can modify the c/m line, and the setup attribute, in order for both endpoints to establish TCP/TLS connections towards the B2BUA. But, again, for MSRP that is not enough, since the current endpoints will compare the path attributes with the MSRP Path headers. Therefor a change would be required to legacy MSRP. Regards, Christer From ben@estacado.net Tue Apr 28 13:47:58 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E56A28C1F9 for ; Tue, 28 Apr 2009 13:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyIbgaaiiJek for ; Tue, 28 Apr 2009 13:47:57 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 425E228C1F6 for ; Tue, 28 Apr 2009 13:47:56 -0700 (PDT) Received: from [10.0.1.196] (adsl-68-94-19-255.dsl.rcsntx.swbell.net [68.94.19.255]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n3SKn20g037235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Apr 2009 15:49:07 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <7EE2C057-4E1B-4055-8C3C-D258960DEE81@estacado.net> From: Ben Campbell To: Christer Holmberg 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 v930.3) Date: Tue, 28 Apr 2009 15:49:02 -0500 References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: simple@ietf.org, adam@nostrum.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM high level issues X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 20:47:58 -0000 (as individual) On Apr 27, 2009, at 1:41 AM, Christer Holmberg wrote: > Yes. For example, nobody has objected to the usage of the fingerprint > attribute. I think it's premature to say that. We really haven't seen a substantially complete proposal on how the fingerprint mechanism would work and what changes it might require to RFC4975 and 4976. I don't see how we can have a useful discussion without one. (I'm not saying the idea does not have merit, but we're still at the hand waving stage.) From hisham.khartabil@gmail.com Tue Apr 28 15:59:55 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A012E3A6BE9 for ; Tue, 28 Apr 2009 15:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9ePmta-nuXE for ; Tue, 28 Apr 2009 15:59:54 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id BC59D3A6BCA for ; Tue, 28 Apr 2009 15:59:54 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so897041yxb.49 for ; Tue, 28 Apr 2009 16:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=a34AKDkB3kk5LB5EvDL9vou3TM04AbEFGLST+MKsWdU=; b=sLLwhs0KYY3UK+7+D50tqygOhhfD+HQwg5oD2H0KHkLZJ1+T3KVvUCksBdPyq3S9K/ oUkDRc5xdgPs6aSpAk+/Q8YUkFo31buZalxWZdbnpJeVyDYC9+fQj+Tv/HMTQVeT66XB l0aLtu7VWrRNvu2Qux2LnkpRyQUaE1mbd2bqo= 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 :content-type:content-transfer-encoding; b=WKCHawA8wz5CZxZ4e1pdM/Ucuc0hIbusnEmP82WFQwsDnxRV+heEop6CbZleRWvzY4 p+EDJSydBJ0usAV017yKl/jk2fqRSTD+M48L9zcUSe4n8jqjGDyitU/KMfAf7ENtnM7G mkCv7FAL4XgTrRS+wPuqMBidLv2ZeJIKCJ+ds= MIME-Version: 1.0 Received: by 10.151.131.4 with SMTP id i4mr91248ybn.233.1240959676290; Tue, 28 Apr 2009 16:01:16 -0700 (PDT) In-Reply-To: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> Date: Wed, 29 Apr 2009 09:01:16 +1000 Message-ID: <66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> From: Hisham Khartabil To: Simple WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 22:59:55 -0000 Hi, 1) We seem to have consensus that it must be possible for MSRP devices using ACM to talk to devices using relays. We don't have consensus on how far we are willing to update RFC4975/4976 to accomplish this. We don't have consensus around any currently proposed mechanism to accomplish the requirement. 2) We seem to have consensus that the parts of the draft about using COMEDIA for negotiating the TCP connection direction is reasonable. Does anyone object to the concensus? Regards, Hisham 2009/4/1 Hisham Khartabil : > The MSRP-ACM draft has an open requirements question on backwards > compatibility with endpoints that use MSRP relays. In San Francisco > some 20 or so people raised their hands one way or another on this > question, yet only a much smaller number have engaged in the list > discussion. > > Please offer your opinions on the following questions. We'd appreciate > the reasoning behind your opinions, rather than just yes or no votes. > We'd really like to hear from every person who raised a hand in San > Francisco. If you stated an opinion at the microphone, please restate > it here. > > 1) Is there a requirement for an endpoint that uses the C-line > addressing mechanism in the MSRP-ACM draft to be able to talk to an > endpoint that uses an MSRP relay (RFC 4976). > > 2) If you said yes to 1), is it acceptable to update RFC 4975 and/or > RFC 4976 to achieve compatibility? =A0If so, how extensively? > > Much appreciated, > Hisham > From christer.holmberg@ericsson.com Tue Apr 28 22:57:49 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664703A689C for ; Tue, 28 Apr 2009 22:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.815 X-Spam-Level: X-Spam-Status: No, score=-5.815 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ZsN--yzj1QLB for ; Tue, 28 Apr 2009 22:57:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CBA923A67C0 for ; Tue, 28 Apr 2009 22:57:47 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-cc-49f7ecab7a66 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 8E.F9.27143.BACE7F94; Wed, 29 Apr 2009 07:59:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 07:59:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 07:59:12 +0200 Message-ID: In-Reply-To: <7EE2C057-4E1B-4055-8C3C-D258960DEE81@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP-ACM high level issues Thread-Index: AcnIQsxIBjtmg8bLSrOclvM6yPhpWgATK0QQ References: <8AF09821-62E4-46CE-B2B5-F554DFA7B9CF@estacado.net> <7EE2C057-4E1B-4055-8C3C-D258960DEE81@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 29 Apr 2009 05:59:07.0267 (UTC) FILETIME=[9B91C530:01C9C88F] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org, adam@nostrum.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com Subject: Re: [Simple] MSRP-ACM high level issues X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 05:57:49 -0000 Hi,=20 >>Yes. For example, nobody has objected to the usage of the fingerprint=20 >>attribute. >=20 >I think it's premature to say that. We really haven't seen a=20 >substantially complete proposal on how the fingerprint=20 >mechanism would work and what changes it might require to=20 >RFC4975 and 4976. I don't see how we can have a useful=20 >discussion without one. Fair enough. I guess I should have said that nobody has objected to CONSIDER the usage of the fingerprint mechanism :) But, I agree it is good to have something on paper, so I will put some text in the next version of the draft. Regards, Christer From christer.holmberg@ericsson.com Wed Apr 29 05:53:56 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE10828C11D for ; Wed, 29 Apr 2009 05:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.82 X-Spam-Level: X-Spam-Status: No, score=-5.82 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 NP5r+GnRieu2 for ; Wed, 29 Apr 2009 05:53:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E27F428C192 for ; Wed, 29 Apr 2009 05:53:54 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-53-49f84e336327 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B9.43.27143.33E48F94; Wed, 29 Apr 2009 14:55:16 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 14:55:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 14:55:21 +0200 Message-ID: In-Reply-To: <66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcnIVUA9LGGLUdM0TTilm88m3X0XXwAdBSwA References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> From: "Christer Holmberg" To: "Hisham Khartabil" , "Simple WG" X-OriginalArrivalTime: 29 Apr 2009 12:55:15.0909 (UTC) FILETIME=[BE0A2F50:01C9C8C9] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 12:53:56 -0000 Hi,=20 >1) We seem to have consensus that it must be possible for=20 >MSRP devices using ACM to talk to devices using relays. >=20 >We don't have consensus on how far we are willing to update >RFC4975/4976 to accomplish this. We don't have consensus=20 >around any currently proposed mechanism to accomplish the requirement. As far as I know, the only proposed mechanism is to change the session = mapping procedure, to only take the user part into account. But, that proposal is related to the TLS issue, so we we need to move = that forward before we can make a decission. Regards, Christer > 2009/4/1 Hisham Khartabil : > > The MSRP-ACM draft has an open requirements question on backwards=20 > > compatibility with endpoints that use MSRP relays. In San Francisco=20 > > some 20 or so people raised their hands one way or another on this=20 > > question, yet only a much smaller number have engaged in the list=20 > > discussion. > > > > Please offer your opinions on the following questions. We'd=20 > appreciate=20 > > the reasoning behind your opinions, rather than just yes or=20 > no votes. > > We'd really like to hear from every person who raised a hand in San=20 > > Francisco. If you stated an opinion at the microphone,=20 > please restate=20 > > it here. > > > > 1) Is there a requirement for an endpoint that uses the C-line=20 > > addressing mechanism in the MSRP-ACM draft to be able to talk to an=20 > > endpoint that uses an MSRP relay (RFC 4976). > > > > 2) If you said yes to 1), is it acceptable to update RFC=20 > 4975 and/or=20 > > RFC 4976 to achieve compatibility? =A0If so, how extensively? > > > > Much appreciated, > > Hisham > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Wed Apr 29 11:09:58 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC643A6E5D for ; Wed, 29 Apr 2009 11:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 8vXKXwf2OpGW for ; Wed, 29 Apr 2009 11:09:57 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 150FA3A6BBD for ; Wed, 29 Apr 2009 11:09:56 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-7a-49f898454d1e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7D.1B.27143.54898F94; Wed, 29 Apr 2009 20:11:17 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 20:11:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 20:11:17 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcnIVUA9LGGLUdM0TTilm88m3X0XXwAdBSwAAAsLH3A= References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Hisham Khartabil" , "Simple WG" X-OriginalArrivalTime: 29 Apr 2009 18:11:17.0799 (UTC) FILETIME=[E434FB70:01C9C8F5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:09:58 -0000 Hi, In fact, chapter 4.1.2 talks about TLS, and already says that RFC 4572 = (which defines the fingerprint attribute) shall be used. But, I guess we can add some additional text which describes what we = have been discussing. Regards, Christer=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Wednesday, April 29, 2009 3:55 PM To: Hisham Khartabil; Simple WG Subject: Re: [Simple] MSRP-ACM compatibility Hi,=20 >1) We seem to have consensus that it must be possible for MSRP devices=20 >using ACM to talk to devices using relays. >=20 >We don't have consensus on how far we are willing to update >RFC4975/4976 to accomplish this. We don't have consensus around any=20 >currently proposed mechanism to accomplish the requirement. As far as I know, the only proposed mechanism is to change the session = mapping procedure, to only take the user part into account. But, that proposal is related to the TLS issue, so we we need to move = that forward before we can make a decission. Regards, Christer > 2009/4/1 Hisham Khartabil : > > The MSRP-ACM draft has an open requirements question on backwards=20 > > compatibility with endpoints that use MSRP relays. In San Francisco=20 > > some 20 or so people raised their hands one way or another on this=20 > > question, yet only a much smaller number have engaged in the list=20 > > discussion. > > > > Please offer your opinions on the following questions. We'd > appreciate > > the reasoning behind your opinions, rather than just yes or > no votes. > > We'd really like to hear from every person who raised a hand in San=20 > > Francisco. If you stated an opinion at the microphone, > please restate > > it here. > > > > 1) Is there a requirement for an endpoint that uses the C-line=20 > > addressing mechanism in the MSRP-ACM draft to be able to talk to an=20 > > endpoint that uses an MSRP relay (RFC 4976). > > > > 2) If you said yes to 1), is it acceptable to update RFC > 4975 and/or > > RFC 4976 to achieve compatibility? =A0If so, how extensively? > > > > Much appreciated, > > Hisham > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Wed Apr 29 11:34:44 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C073A689C for ; Wed, 29 Apr 2009 11:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMnOs1aZW0Cv for ; Wed, 29 Apr 2009 11:34:43 -0700 (PDT) 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 9DAAB3A6A7D for ; Wed, 29 Apr 2009 11:34:42 -0700 (PDT) Received: from dn3-109.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 n3TIZx4i028759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Apr 2009 13:35:59 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: From: Ben Campbell To: "Christer Holmberg" 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 v930.3) Date: Wed, 29 Apr 2009 13:35:58 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:34:44 -0000 (as individual) On Apr 29, 2009, at 1:11 PM, Christer Holmberg wrote: > > Hi, > > In fact, chapter 4.1.2 talks about TLS, and already says that RFC > 4572 (which defines the fingerprint attribute) shall be used. > > But, I guess we can add some additional text which describes what we > have been discussing. > To make this interop with MSRP relays, we would need more work. Relays are not involved in the SIP signaling, so there's no opportunity for them to send a fingerprint. We would need some way for endpoints to get fingerprints from the relays, and include them in the signaling. There's also the fact that any fingerprint mechanism will require at least integrity protection of the fingerprint, which is showing itself to be controversial in the RFC4479 discussions in the other work groups. I think that to have a useful discussion about this, we will need a proposal covering this end-to-end. That doesn't necessarily mean it all ends up living in the final ACM draft, but we at least need to understand if we have a workable architecture. > Regards, > > Christer > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Wednesday, April 29, 2009 3:55 PM > To: Hisham Khartabil; Simple WG > Subject: Re: [Simple] MSRP-ACM compatibility > > > Hi, > >> 1) We seem to have consensus that it must be possible for MSRP >> devices >> using ACM to talk to devices using relays. >> >> We don't have consensus on how far we are willing to update >> RFC4975/4976 to accomplish this. We don't have consensus around any >> currently proposed mechanism to accomplish the requirement. > > As far as I know, the only proposed mechanism is to change the > session mapping procedure, to only take the user part into account. > > But, that proposal is related to the TLS issue, so we we need to > move that forward before we can make a decission. > > Regards, > > Christer > > > > >> 2009/4/1 Hisham Khartabil : >>> The MSRP-ACM draft has an open requirements question on backwards >>> compatibility with endpoints that use MSRP relays. In San Francisco >>> some 20 or so people raised their hands one way or another on this >>> question, yet only a much smaller number have engaged in the list >>> discussion. >>> >>> Please offer your opinions on the following questions. We'd >> appreciate >>> the reasoning behind your opinions, rather than just yes or >> no votes. >>> We'd really like to hear from every person who raised a hand in San >>> Francisco. If you stated an opinion at the microphone, >> please restate >>> it here. >>> >>> 1) Is there a requirement for an endpoint that uses the C-line >>> addressing mechanism in the MSRP-ACM draft to be able to talk to an >>> endpoint that uses an MSRP relay (RFC 4976). >>> >>> 2) If you said yes to 1), is it acceptable to update RFC >> 4975 and/or >>> RFC 4976 to achieve compatibility? If so, how extensively? >>> >>> Much appreciated, >>> Hisham >>> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Thu Apr 30 00:07:47 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F093A6B6A for ; Thu, 30 Apr 2009 00:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 iz0kaKQ5WSma for ; Thu, 30 Apr 2009 00:07:47 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7A4943A6C7D for ; Thu, 30 Apr 2009 00:07:46 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-2f-49f94e938d58 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id ED.89.04357.39E49F94; Thu, 30 Apr 2009 09:09:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 09:09:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 09:09:13 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcnI+VmPb/eN/y51QACEJJiO7/ov0wAaDTtw References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 30 Apr 2009 07:09:07.0492 (UTC) FILETIME=[8D82FE40:01C9C962] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:07:47 -0000 Hi Ben,=20 >>In fact, chapter 4.1.2 talks about TLS, and already says that RFC >>4572 (which defines the fingerprint attribute) shall be used. >> >>But, I guess we can add some additional text which describes what we=20 >>have been discussing. >> >=20 >To make this interop with MSRP relays, we would need more=20 >work. Relays are not involved in the SIP signaling, so there's no opportunity for =20 >them to send a fingerprint. We would need some way for endpoints to =20 >get fingerprints from the relays, and include them in the signaling. Just for my clarification: how is that related to routing based on c/m/a=3Dpath, and possibly having a B2BUA which may modify the address information of the ACM client's c/m/a=3Dpath? Regards, Christer >There's also the fact that any fingerprint mechanism will require at =20 >least integrity protection of the fingerprint, which is=20 >showing itself to be controversial in the RFC4479 discussions in the other=20 >work groups. >=20 >I think that to have a useful discussion about this, we will need a =20 >proposal covering this end-to-end. That doesn't necessarily mean it =20 >all ends up living in the final ACM draft, but we at least need to =20 >understand if we have a workable architecture. >=20 >=20 > > Regards, > > > > Christer > > > > -----Original Message----- > > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On =20 > > Behalf Of Christer Holmberg > > Sent: Wednesday, April 29, 2009 3:55 PM > > To: Hisham Khartabil; Simple WG > > Subject: Re: [Simple] MSRP-ACM compatibility > > > > > > Hi, > > > >> 1) We seem to have consensus that it must be possible for MSRP =20 > >> devices > >> using ACM to talk to devices using relays. > >> > >> We don't have consensus on how far we are willing to update > >> RFC4975/4976 to accomplish this. We don't have consensus around any > >> currently proposed mechanism to accomplish the requirement. > > > > As far as I know, the only proposed mechanism is to change the =20 > > session mapping procedure, to only take the user part into account. > > > > But, that proposal is related to the TLS issue, so we we need to =20 > > move that forward before we can make a decission. > > > > Regards, > > > > Christer > > > > > > > > > >> 2009/4/1 Hisham Khartabil : > >>> The MSRP-ACM draft has an open requirements question on backwards > >>> compatibility with endpoints that use MSRP relays. In San=20 > Francisco > >>> some 20 or so people raised their hands one way or another on this > >>> question, yet only a much smaller number have engaged in the list > >>> discussion. > >>> > >>> Please offer your opinions on the following questions. We'd > >> appreciate > >>> the reasoning behind your opinions, rather than just yes or > >> no votes. > >>> We'd really like to hear from every person who raised a=20 > hand in San > >>> Francisco. If you stated an opinion at the microphone, > >> please restate > >>> it here. > >>> > >>> 1) Is there a requirement for an endpoint that uses the C-line > >>> addressing mechanism in the MSRP-ACM draft to be able to=20 > talk to an > >>> endpoint that uses an MSRP relay (RFC 4976). > >>> > >>> 2) If you said yes to 1), is it acceptable to update RFC > >> 4975 and/or > >>> RFC 4976 to achieve compatibility? If so, how extensively? > >>> > >>> Much appreciated, > >>> Hisham > >>> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www.ietf.org/mailman/listinfo/simple > >> > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple >=20 >=20 From ag@ag-projects.com Thu Apr 30 02:00:15 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6994B3A6F40 for ; Thu, 30 Apr 2009 02:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 Xe9rSFGgEwSZ for ; Thu, 30 Apr 2009 02:00:14 -0700 (PDT) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 6B3CE3A6903 for ; Thu, 30 Apr 2009 02:00:13 -0700 (PDT) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68) (envelope-from ) id 1LzS2A-0008Ei-Vv for simple@ietf.org; Thu, 30 Apr 2009 10:54:25 +0200 Message-Id: From: Adrian Georgescu To: simple@ietf.org 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 v930.3) Date: Thu, 30 Apr 2009 11:01:26 +0200 References: X-Mailer: Apple Mail (2.930.3) X-SA-Exim-Connect-IP: 80.101.96.20 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Subject: Re: [Simple] WGLC Review: draft-ietf-simple-chat-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 09:00:15 -0000 > Date: Tue, 21 Apr 2009 18:26:19 -0500 > From: "Mary Barnes" > Subject: [Simple] WGLC Review: draft-ietf-simple-chat-04 > To: "Simple WG" > Cc: draft-ietf-simple-chat@tools.ietf.org > Message-ID: > <1ECE0EB50388174790F9694F77522CCF1D94512B@zrc2hxm0.corp.nortel.com> > Content-Type: text/plain; charset="us-ascii" > > Document: draft-ietf-simple-chat-04 > Reviewer: Mary Barnes > Review Date: April 21, 2009 > WGLC LC End Date: April 27, 2009 > > Summary: On the right track but needs a good bit more work prior to > progressing. > > General comments/questions/caveats: > ----------------------------------- > 1) Caveat and comments: I am not an MSRP expert and the doc really > needs > review by one prior to forwarding, in particular with regards to > ensuring normative protocol changes are correct. Obviously, if Ben is > the PROTO shepherd, that should cover it. However, my personal > opinion > is the doc needs a couple more detailed reviews, or at a minimum > feedback that folks believe the document is ready, since it is > standard's track. > > 2) General question: Does anyone have a implementation of MSRP chat? http://chatserver.ag-projects.com Adrian From ben@nostrum.com Thu Apr 30 06:12:14 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614703A6EC0 for ; Thu, 30 Apr 2009 06:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpv6vzE7J0Uj for ; Thu, 30 Apr 2009 06:12:13 -0700 (PDT) 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 69A063A6B3D for ; Thu, 30 Apr 2009 06:12:12 -0700 (PDT) Received: from [10.0.1.192] (adsl-68-94-31-238.dsl.rcsntx.swbell.net [68.94.31.238]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3UDDTrn009450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Apr 2009 08:13:29 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> From: Ben Campbell To: "Christer Holmberg" 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 v930.3) Date: Thu, 30 Apr 2009 08:13:29 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 68.94.31.238 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:12:14 -0000 On Apr 30, 2009, at 2:09 AM, Christer Holmberg wrote: > > Hi Ben, > >>> In fact, chapter 4.1.2 talks about TLS, and already says that RFC >>> 4572 (which defines the fingerprint attribute) shall be used. >>> >>> But, I guess we can add some additional text which describes what we >>> have been discussing. >>> >> >> To make this interop with MSRP relays, we would need more >> work. Relays are not involved in the SIP signaling, so there's no > opportunity for >> them to send a fingerprint. We would need some way for endpoints to >> get fingerprints from the relays, and include them in the signaling. > > Just for my clarification: how is that related to routing based on > c/m/a=path, and possibly having a B2BUA which may modify the address > information of the ACM client's c/m/a=path? It's specific to the idea of having TLS cert fingerprints sent in SIP for each relay. It's only needed in case where a middlebox modified the path attribute to modify the IP addresses or host names in the MSRP uris, creating the certificate mismatch we have discussed. > > > Regards, > > Christer > > > > > > > > > > > >> There's also the fact that any fingerprint mechanism will require at >> least integrity protection of the fingerprint, which is >> showing itself to be controversial in the RFC4479 discussions in the > other >> work groups. >> >> I think that to have a useful discussion about this, we will need a >> proposal covering this end-to-end. That doesn't necessarily mean it >> all ends up living in the final ACM draft, but we at least need to >> understand if we have a workable architecture. > > > > > > >> >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>> Behalf Of Christer Holmberg >>> Sent: Wednesday, April 29, 2009 3:55 PM >>> To: Hisham Khartabil; Simple WG >>> Subject: Re: [Simple] MSRP-ACM compatibility >>> >>> >>> Hi, >>> >>>> 1) We seem to have consensus that it must be possible for MSRP >>>> devices >>>> using ACM to talk to devices using relays. >>>> >>>> We don't have consensus on how far we are willing to update >>>> RFC4975/4976 to accomplish this. We don't have consensus around any >>>> currently proposed mechanism to accomplish the requirement. >>> >>> As far as I know, the only proposed mechanism is to change the >>> session mapping procedure, to only take the user part into account. >>> >>> But, that proposal is related to the TLS issue, so we we need to >>> move that forward before we can make a decission. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>>> 2009/4/1 Hisham Khartabil : >>>>> The MSRP-ACM draft has an open requirements question on backwards >>>>> compatibility with endpoints that use MSRP relays. In San >> Francisco >>>>> some 20 or so people raised their hands one way or another on this >>>>> question, yet only a much smaller number have engaged in the list >>>>> discussion. >>>>> >>>>> Please offer your opinions on the following questions. We'd >>>> appreciate >>>>> the reasoning behind your opinions, rather than just yes or >>>> no votes. >>>>> We'd really like to hear from every person who raised a >> hand in San >>>>> Francisco. If you stated an opinion at the microphone, >>>> please restate >>>>> it here. >>>>> >>>>> 1) Is there a requirement for an endpoint that uses the C-line >>>>> addressing mechanism in the MSRP-ACM draft to be able to >> talk to an >>>>> endpoint that uses an MSRP relay (RFC 4976). >>>>> >>>>> 2) If you said yes to 1), is it acceptable to update RFC >>>> 4975 and/or >>>>> RFC 4976 to achieve compatibility? If so, how extensively? >>>>> >>>>> Much appreciated, >>>>> Hisham >>>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >> >> From ben@nostrum.com Thu Apr 30 06:15:24 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB89528C320 for ; Thu, 30 Apr 2009 06:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqwJfsXpaJk8 for ; Thu, 30 Apr 2009 06:15:24 -0700 (PDT) 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 A69A13A6B3D for ; Thu, 30 Apr 2009 06:15:23 -0700 (PDT) Received: from [10.0.1.192] (adsl-68-94-31-238.dsl.rcsntx.swbell.net [68.94.31.238]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3UDGJZl009636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Apr 2009 08:16:19 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> From: Ben Campbell To: Christer Holmberg In-Reply-To: <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 08:16:19 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 68.94.31.238 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP-ACM compatibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:15:24 -0000 (as individual) On Apr 30, 2009, at 8:13 AM, Ben Campbell wrote: >>> To make this interop with MSRP relays, we would need more >>> work. Relays are not involved in the SIP signaling, so there's no >> opportunity for >>> them to send a fingerprint. We would need some way for endpoints to >>> get fingerprints from the relays, and include them in the signaling. >> >> Just for my clarification: how is that related to routing based on >> c/m/a=path, and possibly having a B2BUA which may modify the address >> information of the ACM client's c/m/a=path? > > It's specific to the idea of having TLS cert fingerprints sent in > SIP for each relay. It's only needed in case where a middlebox > modified the path attribute to modify the IP addresses or host names > in the MSRP uris, creating the certificate mismatch we have discussed. Also, don't get me wrong--I do not mean that to be a complete specification of the requirements, as much as evidence that if we were to introduce a fingerprints-for-relays solution, we have some engineering to do to make it useful. I don't think it's good enough to just call out the possibility of doing the work and calling it done. From mary.barnes@nortel.com Thu Apr 30 09:46:40 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1C8F28C306 for ; Thu, 30 Apr 2009 09:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 I30YSLKOy1P2 for ; Thu, 30 Apr 2009 09:46:40 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1286528C27E for ; Thu, 30 Apr 2009 09:45:38 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3UGkkV29410; Thu, 30 Apr 2009 16:46:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 11:49:32 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DBE57AC@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] WGLC Review: draft-ietf-simple-chat-04 Thread-Index: AcnJckzvGBHe00GTSZiNBtSi3EkrBgAQSD0w References: From: "Mary Barnes" To: "Adrian Georgescu" , Subject: Re: [Simple] WGLC Review: draft-ietf-simple-chat-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:46:41 -0000 Excellent - so do the call flows align with what you have in your implementation or do you see any potential gaps? =20 Thanks, Mary.=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Adrian Georgescu Sent: Thursday, April 30, 2009 4:01 AM To: simple@ietf.org Subject: Re: [Simple] WGLC Review: draft-ietf-simple-chat-04 > Date: Tue, 21 Apr 2009 18:26:19 -0500 > From: "Mary Barnes" > Subject: [Simple] WGLC Review: draft-ietf-simple-chat-04 > To: "Simple WG" > Cc: draft-ietf-simple-chat@tools.ietf.org > Message-ID: > <1ECE0EB50388174790F9694F77522CCF1D94512B@zrc2hxm0.corp.nortel.com> > Content-Type: text/plain; charset=3D"us-ascii" > > Document: draft-ietf-simple-chat-04 > Reviewer: Mary Barnes > Review Date: April 21, 2009 > WGLC LC End Date: April 27, 2009 > > Summary: On the right track but needs a good bit more work prior to=20 > progressing. > > General comments/questions/caveats: > ----------------------------------- > 1) Caveat and comments: I am not an MSRP expert and the doc really=20 > needs review by one prior to forwarding, in particular with regards to > ensuring normative protocol changes are correct. Obviously, if Ben is=20 > the PROTO shepherd, that should cover it. However, my personal=20 > opinion is the doc needs a couple more detailed reviews, or at a=20 > minimum feedback that folks believe the document is ready, since it=20 > is standard's track. > > 2) General question: Does anyone have a implementation of MSRP chat? http://chatserver.ag-projects.com Adrian _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple