From ag@ag-projects.com Fri May 1 05:13: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 6D02B28E5F2 for ; Fri, 1 May 2009 05:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=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 m8vTqSmk+pM1 for ; Fri, 1 May 2009 05:13:10 -0700 (PDT) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 0C9C42936CF for ; Fri, 1 May 2009 05:04:34 -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 1LzrO6-0003Er-3y; Fri, 01 May 2009 13:58:44 +0200 Message-Id: <8C47EE33-93F9-47C8-9BD7-1FAB98B4D358@ag-projects.com> From: Adrian Georgescu To: Mary Barnes In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DBE57AC@zrc2hxm0.corp.nortel.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4-879342339 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 14:05:47 +0200 References: <1ECE0EB50388174790F9694F77522CCF1DBE57AC@zrc2hxm0.corp.nortel.com> 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) Cc: simple@ietf.org 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: Fri, 01 May 2009 12:13:23 -0000 --Apple-Mail-4-879342339 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Mary, The implementation we have developed so far acts like a simple MSRP mixer where all parties connect to without authorization. I am not able to confirm other call flows yet but our internal review did not show any show stoppers for implementing the other features described in the draft. For me they personally they all make sense and are achievable. I do plan to implement the features described int he draft, yet I have no estimation for when it will be finished. Regards, Adrian On Apr 30, 2009, at 6:49 PM, Mary Barnes wrote: > Excellent - so do the call flows align with what you have in your > implementation or do you see any potential gaps? > > Thanks, > Mary. > > -----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="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 > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-4-879342339 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Hi = Mary,

The implementation we have developed so = far acts like a simple MSRP mixer where all parties connect to without = authorization. I am not able to confirm other call flows yet but our = internal review did not show any show stoppers for implementing the = other features described in the draft. For me they personally they all = make sense and are achievable.

I do plan to = implement the features described int he draft, yet I have no estimation = for when it will be = finished.

Regards,
Adrian

On Apr 30, 2009, at 6:49 PM, Mary Barnes = wrote:

Excellent - so do the call flows align with what you = have in your
implementation or do you see any potential gaps? =  

Thanks,
Mary.

-----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" = <mary.barnes@nortel.com>
Subject: [Simple] WGLC Review: =  draft-ietf-simple-chat-04
To: "Simple WG" <simple@ietf.org>
Cc: draft-ietf-simple-ch= at@tools.ietf.org
Message-ID:

<1ECE0EB50388174790F9694F77522CCF1D94512B@zrc2hxm0.corp.nortel.com<= /a>>
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 =
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.c= om

Adrian

______________________________________________= _
Simple mailing list
Simple@ietf.org
https://www.ietf.or= g/mailman/listinfo/simple

= --Apple-Mail-4-879342339-- From christer.holmberg@ericsson.com Fri May 1 07:00: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 212CD28C1A7 for ; Fri, 1 May 2009 07:00:22 -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_63=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 pvGRunsfXELB for ; Fri, 1 May 2009 07:00:21 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3BD3E28C17D for ; Fri, 1 May 2009 07:00:20 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-4f-49fb00c65e2f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 27.3A.19078.6C00BF94; Fri, 1 May 2009 16:01:42 +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, 1 May 2009 16:01:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 16:01:41 +0200 Message-ID: In-Reply-To: <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcnJlekqbsoovmnHRemZQiJfgi3taAAzIqew References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 01 May 2009 14:01:42.0296 (UTC) FILETIME=[5AF01180:01C9CA65] 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: Fri, 01 May 2009 14:00:22 -0000 Hi,=20 >>> To make this interop with MSRP relays, we would need more work.=20 >>> 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=20 >>> get fingerprints from the relays, and include them in the signaling. >> >> Just for my clarification: how is that related to routing based on=20 >> c/m/a=3Dpath, and possibly having a B2BUA which may modify the = address=20 >> information of the ACM client's c/m/a=3Dpath? > > It's specific to the idea of having TLS cert fingerprints sent in SIP=20 > for each relay. It's only needed in case where a middlebox modified=20 > the path attribute to modify the IP addresses or host names in the=20 > MSRP uris, creating the certificate mismatch we have discussed. A few questions: FIRST, RFC4572 already defines the usage of the fingerprint attribute, so wouldn't your issue also apply if you ONLY use COMEDIA, with relays? SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the IP address/ports are not used for the certificate. So, as long as both the ACM client/SBC belong to foobar.dom, and the MSRP client/relay belong to anotherfoobar.com, the SBC and relay can have the same certificate as the client behind them. Or? THIRD, if a fingerprint is to be provided to/from the relay when an MSRP message is sent, I guess it could be sent as a To/From-path URI parameter. Getting the fingerprint to/from the relay BEFORE an MSRP message is sent is of course more tricky. Hadriel's e-mail (fri 17th april): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D 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 able 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 identity. (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 layer-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. Comedia-tls (rfc4572) does that with a fingerprint attribute, but we have been discussing on this list what the appropriate way to do that for the ACM case is. Regards, Christer From ben@nostrum.com Fri May 8 14:03: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 5CFAA3A6A47 for ; Fri, 8 May 2009 14:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_63=0.6, 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 D3Yac-wnLC9b for ; Fri, 8 May 2009 14:03: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 290C23A69DD for ; Fri, 8 May 2009 14:03:14 -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 n48L4dBA090004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 May 2009 16:04:39 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <70DC2003-9C4D-46A7-A06C-07F296DAB000@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: Fri, 8 May 2009 16:04:39 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.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: Fri, 08 May 2009 21:03:16 -0000 (as individual) On May 1, 2009, at 9:01 AM, Christer Holmberg wrote: > > Hi, > >>>> 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. > > A few questions: > > > FIRST, RFC4572 already defines the usage of the fingerprint attribute, > so wouldn't your issue also apply if you ONLY use COMEDIA, with > relays? If you use COMEDIA-TLS, yes. Not if just use RFC4145, or follow _just_ the connection-direction parts of the ACM draft. > > > > SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the > IP > address/ports are not used for the certificate. So, as long as both > the > ACM client/SBC belong to foobar.dom, and the MSRP client/relay > belong to > anotherfoobar.com, the SBC and relay can have the same certificate as > the client behind them. Or? As far as Hadriel's comment, it depends on what one puts _in_ the subjectAltName field. You _could_ put just an IP address in there, although I submit that would be a bad idea. But to put your statement more generally: If the, sbc, or other intermediary has a subjectAltName entry that matches the authority part of a client's adjacent MSRP device (i.e. the next hop in the a=path attribute), then we're fine. The problem is, the SBC is not likely to be in the same domain as _both_ endpoints. So from at least one endpoint's perspective, there's likely to be a mismatch. > > > > THIRD, if a fingerprint is to be provided to/from the relay when an > MSRP > message is sent, I guess it could be sent as a To/From-path URI > parameter. Getting the fingerprint to/from the relay BEFORE an MSRP > message is sent is of course more tricky. A URI parameter would seem to be the least syntactically invasive approach. (Reminder--I'm writing as an individual, not as chair) By the way, please do not take my replies to indicate that I support the idea that the simple WG specifying how to use fingerprints with relays. I don't necessarily oppose it either, but the work group will need to decide if the value of the c-line addressing part of the ACM draft is sufficient to make it worth the additional work and complexity. In particular, I am skeptical about doing non-trivial changes to make MSRP work better across proprietary intermediaries without some better description of what will and will not work in the general case (i.e. not just what will work with one vendor.) From christer.holmberg@ericsson.com Mon May 18 03: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 94DB03A6F64 for ; Mon, 18 May 2009 03:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.568 X-Spam-Level: X-Spam-Status: No, score=-5.568 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_63=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 dQtela9MSmo9 for ; Mon, 18 May 2009 03:22:07 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 268763A7013 for ; Mon, 18 May 2009 03:22:06 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-25-4a11372bb4a5 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 64.3B.02531.B27311A4; Mon, 18 May 2009 12:23:39 +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, 18 May 2009 12:23:14 +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, 18 May 2009 12:23:13 +0200 Message-ID: In-Reply-To: <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM compatibility Thread-Index: AcnQIJw+V5jIwCoqT8GtKEaRwy1b9wHfJuiw References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 18 May 2009 10:23:14.0392 (UTC) FILETIME=[A70A6580:01C9D7A2] 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: Mon, 18 May 2009 10:22:08 -0000 Hi,=20 >>FIRST, RFC4572 already defines the usage of the fingerprint attribute, >>so wouldn't your issue also apply if you ONLY use COMEDIA, with=20 >>relays? >=20 >If you use COMEDIA-TLS, yes. Not if just use RFC4145, or follow _just_ the connection-direction parts of the ACM draft. Chapter 4.1.2, which belongs to the comedia part of the ACM draft, does refer to RFC4572, so my assumption so far has been that "using the comedia part" would also include RFC4572 for TLS. So, when talking about comedia, I guess we need to separate between "using the comedia part" (which, for TLS, includes the fingerprint attribute) and "using just the connection-direction parts of comedia". And, even without the fingerprint, you still have the TLS collision issue if both endpoints are "active". >>SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the =20 >>IP address/ports are not used for the certificate. So, as long=20 >>as both the ACM client/SBC belong to foobar.dom, and the MSRP client/relay =20 >>belong to anotherfoobar.com, the SBC and relay can have the same=20 >>certificate as the client behind them. Or? >=20 >As far as Hadriel's comment, it depends on what one puts _in_ the =20 >subjectAltName field. You _could_ put just an IP address in there, =20 >although I submit that would be a bad idea. >=20 >But to put your statement more generally: If the, sbc, or other =20 >intermediary has a subjectAltName entry that matches the authority =20 >part of a client's adjacent MSRP device (i.e. the next hop in the =20 >a=3Dpath attribute), then we're fine. >=20 >The problem is, the SBC is not likely to be in the same domain as =20 >_both_ endpoints. So from at least one endpoint's perspective, there's >likely to be a mismatch. Why doesn't the relay need to get the certificate information in legacy MSRP then? I don't think we can assume that the relay belongs to the same domain as both endpoints, can we? I have a feeling that I am missing some piece of the puzzle here, and I appologise for that, but I am still trying to figure out this is specific to ACM :) >>THIRD, if a fingerprint is to be provided to/from the relay when an =20 >>MSRP message is sent, I guess it could be sent as a To/From-path URI >>parameter. Getting the fingerprint to/from the relay BEFORE an MSRP >>message is sent is of course more tricky. >=20 >A URI parameter would seem to be the least syntactically invasive =20 >approach. >=20 >(Reminder--I'm writing as an individual, not as chair) >=20 >By the way, please do not take my replies to indicate that I support =20 >the idea that the simple WG specifying how to use fingerprints with =20 >relays. I think people should be allowed to participate in discussions and idea brainstorming without automatically being "accused" of supporting specific solutions :) >I don't necessarily oppose it either, but the work=20 >group will need to decide if the value of the c-line addressing part of the ACM =20 >draft is sufficient to make it worth the additional work and=20 >complexity. >=20 >In particular, I am skeptical about doing non-trivial changes=20 >to make MSRP work better across proprietary intermediaries without=20 >some better description of what will and will not work in the general case (i.e. =20 >not just what will work with one vendor.) As said before, I don't think this is about "one vendor". Regards, Christer From ben@nostrum.com Mon May 18 14:10: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 CF3C13A6E2A for ; Mon, 18 May 2009 14:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.281, 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 heQqU7AAorIy for ; Mon, 18 May 2009 14:10:22 -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 86A353A6DF9 for ; Mon, 18 May 2009 14:10:21 -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 n4ILBtAe010145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 18 May 2009 16:11:55 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <59ED1195-D1B7-4DA6-9579-33E6E57418C1@nostrum.com> 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 v935.3) Date: Mon, 18 May 2009 16:11:55 -0500 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] MSRP-ACM Discussion Summary 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, 18 May 2009 21:10:22 -0000 (As individual) The discussion thread on MSRP-ACM seems to be dying out, and I don't think we've reached closure on most of it. In order to jump start it, I am going to attempt to summarize the issues that I think are still open. I will start separate threads for each issue. Please reply to _this_ message to comment on whether I have offered a fair summary, or mischaracterized or omitted anything material. Please reply to the specific issue threads to discuss the issues themselves. 1) We have consensus that the transport address connection parts (section 4.2 of draft-ietf-simple-msrp-acm-00) must allow backwards compatibility with a peer that uses an RFC4976 MSRP relay. We have had one proposal on how to accomplish this, which involved updating 4975 to allow a middlebox to modify the authority part of an MSRP(S) URI in the SDP "a=path" property. We further determined that this proposal may interfere with the use of MSRPS URIs (i.e. TLS) in the case where said middlebox is transparent to TLS. It modified an MSRPS URI to point to itself, but transparently relays the TLS handshake to a relay (or other MSRP device that uses a TLS server cert.). The modified URI no longer matches the server cert, so things break. We've had some discussion about using the comedia-TLS fingerprint mechanism for certificate matching rather than SubjectAltName matching to get around this issue. This discussion is far from "baked". We've also had some objection (primarily from Jon) to doing work around a new class of MSRP TLS intermediary without better describing that intermediary, as well as concerns (primarily from Ben ) about standardizing MSRP mechanisms to work with non-standardized middleboxes without a better understanding of them. 2) We have little or no objection to the usage of the comedia "setup" attribute (section 4.1 of draft-ietf-simple-msrp-acm-00. ) Is this a fair summary? Have I mischaracterized or missed anything? From ben@nostrum.com Mon May 18 15:03: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 B2EA33A705A for ; Mon, 18 May 2009 15:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_63=0.6, 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 R4avP2qTUO0O for ; Mon, 18 May 2009 15:03:41 -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 D52A03A6FC2 for ; Mon, 18 May 2009 15:03:40 -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 n4IM5BEa014306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 May 2009 17:05:12 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <5BBE0395-8FF3-4D1D-B360-467979A811E1@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 v935.3) Date: Mon, 18 May 2009 17:05:11 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> X-Mailer: Apple Mail (2.935.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: Mon, 18 May 2009 22:03:42 -0000 (As individual) On May 18, 2009, at 5:23 AM, Christer Holmberg wrote: > > Hi, > >>> FIRST, RFC4572 already defines the usage of the fingerprint >>> attribute, > >>> so wouldn't your issue also apply if you ONLY use COMEDIA, with >>> relays? >> >> If you use COMEDIA-TLS, yes. Not if just use RFC4145, or follow >> _just_ > the connection-direction parts of the ACM draft. > > Chapter 4.1.2, which belongs to the comedia part of the ACM draft, > does > refer to RFC4572, so my assumption so far has been that "using the > comedia part" would also include RFC4572 for TLS. > > So, when talking about comedia, I guess we need to separate between > "using the comedia part" (which, for TLS, includes the fingerprint > attribute) and "using just the connection-direction parts of comedia". > > And, even without the fingerprint, you still have the TLS collision > issue if both endpoints are "active". Ah, I see what you mean. I agree, the issue with using fingerprints for relay certificates is true just for the COMEDIA use currently defined in the ACM draft. > > >>> SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the >>> IP address/ports are not used for the certificate. So, as long >>> as both the ACM client/SBC belong to foobar.dom, and the MSRP > client/relay >>> belong to anotherfoobar.com, the SBC and relay can have the same >>> certificate as the client behind them. Or? >> >> As far as Hadriel's comment, it depends on what one puts _in_ the >> subjectAltName field. You _could_ put just an IP address in there, >> although I submit that would be a bad idea. >> >> But to put your statement more generally: If the, sbc, or other >> intermediary has a subjectAltName entry that matches the authority >> part of a client's adjacent MSRP device (i.e. the next hop in the >> a=path attribute), then we're fine. >> >> The problem is, the SBC is not likely to be in the same domain as >> _both_ endpoints. So from at least one endpoint's perspective, >> there's > >> likely to be a mismatch. > > Why doesn't the relay need to get the certificate information in > legacy > MSRP then? I don't think we can assume that the relay belongs to the > same domain as both endpoints, can we? I'm not sure I understand your question-The assumption in RFC4576 is that an MSRP Relay will have a certificate that is signed by a well- known certificate authority. I agree that we can't assume a relay belongs to the same domain as both endpoints, but RFC4976 does not require that. It's only when the device that terminates the TCP connection is not the same device that terminates the TLS handshake that we have a problem. That doesn't happen in RFC4976 natively--only when a middlebox changes the path attribute. > > > I have a feeling that I am missing some piece of the puzzle here, > and I > appologise for that, but I am still trying to figure out this is > specific to ACM :) > It's specific to having a middlebox modify the SDP path property. Let me try an example: Alice is behind an SBC. That SBC acts as a TCP relay, but transparently tunnels TLS rather than terminating it. (much in the way an HTTPS proxy tunnels TLS). Alice sends an offer to Bob. Her path attribute looks like: a=path: msrps;//alice.atlanta.com:1234/fieru;tcp The SBC modifies the authority part of the URI to point to itself, and creates a binding so that all traffic to its port forwards to alice: a=path: msrps;//sbc.atlanta.com:88039/fieru;tcp Bob uses a relay. His answer contains: a=path:msrps://relay.biloxi.com:84930/asfieu;tcp msrps;// bob.biloxi.com:1234/bzerts;tcp Alice's SBC modified the answer to also point to itself, and completes the binding a=path:msrps://sbc.atlanta.com:88040/asfieu;tcp msrps;//bob.biloxi.com: 1234/bzerts;tcp Alice now opens a TCP connection to sbc.atlanta.com:88040, and initiates a TLS handshake. This is forwarded transparently to relay.biloxi.com, which provides its TLS server certificate containing "relay.biloxi.com" in its subjectAltName field. Alice's UA checks the certificate for the name "sbc.atlanta.com", since that was the name it saw in the SDP. The cert provided by relay.biloxi.com does not contain that name, so the TLS server authentication fails. > >>> THIRD, if a fingerprint is to be provided to/from the relay when an >>> MSRP message is sent, I guess it could be sent as a To/From-path URI >>> parameter. Getting the fingerprint to/from the relay BEFORE an MSRP >>> message is sent is of course more tricky. >> >> A URI parameter would seem to be the least syntactically invasive >> approach. >> >> (Reminder--I'm writing as an individual, not as chair) >> >> By the way, please do not take my replies to indicate that I support >> the idea that the simple WG specifying how to use fingerprints with >> relays. > > I think people should be allowed to participate in discussions and > idea > brainstorming without automatically being "accused" of supporting > specific solutions :) > > >> I don't necessarily oppose it either, but the work >> group will need to decide if the value of the c-line addressing >> part of > the ACM >> draft is sufficient to make it worth the additional work and >> complexity. >> >> In particular, I am skeptical about doing non-trivial changes >> to make MSRP work better across proprietary intermediaries without >> some better description of what will and will not work in the general > case (i.e. >> not just what will work with one vendor.) > > As said before, I don't think this is about "one vendor". So what _is_ it about? To my knowledge, We've had only one vendor stand up and say "this stuff will work across our SBCs". You are trying to work around the behavior of proprietary middle boxes. They may behave similarly in some ways, but not others. For example, if other vendors don't have support for TCP media, then there's not much value in this for them. Without some standard behavior, or some survey of behavior like BEHAVE did with NATs, we're just sort of hoping things will work most of the time. That may be good enough to write product requirements around, but it's probably not good enough to write standards around. > > > Regards, > > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Mon May 18 22:39: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 BCD053A68B4 for ; Mon, 18 May 2009 22:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.566 X-Spam-Level: X-Spam-Status: No, score=-5.566 tagged_above=-999 required=5 tests=[AWL=0.083, 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 o2BJJSf12zyO for ; Mon, 18 May 2009 22:39:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6DBD93A6804 for ; Mon, 18 May 2009 22:39:23 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-74-4a124669f4f5 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 15.94.02531.966421A4; Tue, 19 May 2009 07:40: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, 19 May 2009 07:40: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, 19 May 2009 07:40:56 +0200 Message-ID: In-Reply-To: <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What ACM is all about [was: RE: [Simple] MSRP-ACM compatibility] Thread-Index: AcnYBLkZQah8vU2bQQC/5Bie64mPVAAPBckA References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 19 May 2009 05:40:57.0434 (UTC) FILETIME=[623D73A0:01C9D844] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: [Simple] What ACM is all about [was: RE: 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, 19 May 2009 05:39:24 -0000 =20 Hi, >>>In particular, I am skeptical about doing non-trivial changes >>>to make MSRP work better across proprietary intermediaries without >>>some better description of what will and will not work in=20 >>>the general case (i.e. not just what will work with one vendor.) >> >>As said before, I don't think this is about "one vendor". >=20 >So what _is_ it about? To my knowledge, We've had only one vendor =20 >stand up and say "this stuff will work across our SBCs". >=20 >You are trying to work around the behavior of proprietary middle =20 >boxes. They may behave similarly in some ways, but not others. For =20 >example, if other vendors don't have support for TCP media, then =20 >there's not much value in this for them. Without some standard =20 >behavior, or some survey of behavior like BEHAVE did with=20 >NATs, we're just sort of hoping things will work most of the time. That may be =20 >good enough to write product requirements around, but it's probably =20 >not good enough to write standards around. What it is about is to allow these middle boxes to treat MSRP more or less like any other type of TCP media, without having to modify the MSRP messages etc. Of course, some intermediates may not support TCP in the first place, but that's normal. We don't expect everyone to support everything we do. But, OMA PoC uses MSRP, so compliant intermediates will have to support TCP. 3GPP IMS uses MSRP, so compliant intermediates will have to support TCP. Intermediates also DO exist in other SIP networks, so in order for MSRP to work they will have to support TCP. That is what I meant by the statement that it's not only about one vendor. So, in my opinion, intermediates can be expected to support TCP. The issue is with supporting legacy MSRP, and that is what ACM is trying to solve. I do agree that these intermediates aren't standardized, but when it comes to sending the media through them they all behave in the same way: by modifying the SDP. Of course, If we also for ACM would still use the a=3Dpath attribute for routing, rather than the c/,- line, the intermeidates will of course have to be able to modify the a=3Dpath attribute. But, no matter whather that can be done using configuration (I guess that is what Hadirel indicated for his product) or whether it requires a software patch, it's a relatively small thing compared to having to modify MSRP messages. Regards, Christer From christer.holmberg@ericsson.com Tue May 19 01:39: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 4B9E73A69A4 for ; Tue, 19 May 2009 01:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=0.382, 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 j4xJUCSp1eaP for ; Tue, 19 May 2009 01:39:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 141E03A6B13 for ; Tue, 19 May 2009 01:39:45 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-b1-4a1270b09977 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 10.7D.02531.0B0721A4; Tue, 19 May 2009 10:41:20 +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, 19 May 2009 10:41: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: Tue, 19 May 2009 10:41:19 +0200 Message-ID: In-Reply-To: <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACM and comedia [was RE: [Simple] MSRP-ACM compatibility] Thread-Index: AcnYBLkZQah8vU2bQQC/5Bie64mPVAAU66Cw References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 19 May 2009 08:41:20.0529 (UTC) FILETIME=[954EB010:01C9D85D] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: [Simple] ACM and comedia [was RE: 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, 19 May 2009 08:39:47 -0000 =20 Hi, >>>>FIRST, RFC4572 already defines the usage of the fingerprint attribute, >>>>so wouldn't your issue also apply if you ONLY use COMEDIA, with relays? >>> >>>If you use COMEDIA-TLS, yes. Not if just use RFC4145, or follow _just_ >>>the connection-direction parts of the ACM draft. >> >>Chapter 4.1.2, which belongs to the comedia part of the ACM draft,=20 >>does refer to RFC4572, so my assumption so far has been that "using=20 >>the comedia part" would also include RFC4572 for TLS. >> >>So, when talking about comedia, I guess we need to separate between=20 >>"using the comedia part" (which, for TLS, includes the fingerprint >>attribute) and "using just the connection-direction parts of comedia". >> >>And, even without the fingerprint, you still have the TLS collision=20 >>issue if both endpoints are "active". >=20 >Ah, I see what you mean. I agree, the issue with using=20 >fingerprints for relay certificates is true just for the=20 >COMEDIA use currently defined in the ACM draft. There are actually a number of comedia issues, but it seems like I have mixed them. I'll try to separate them: FIRST, if we don't use the fingerprint attribute when the MSRP clients use self-signed signatures, we are not compliant with RFC4572. Do we want to go that way? Do we have the mandate to go that way? Will the security people have issues with that?=20 Without relays I guess there would be no issue with using the fingerprint attribute (again, I am only talking about pure comedia here - not SBC impacts etc). But, even with relays, I guess it would be possible to provide the fingerprint of the remote client to the relay e.g. using the AUTH method.=20 SECOND, the handshake collision occurs when both endpoints are "active". AFAIK, that has nothing to do with whether the fingerprint is used or not. THIRD (new), I assume an MSRP entity behind a relay would always be "active". I am not sure whether that is an issue, but it should probably be mentioned in the draft. Regards, Christer From christer.holmberg@ericsson.com Tue May 19 02:36: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 2B5513A6C13 for ; Tue, 19 May 2009 02:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.268 X-Spam-Level: X-Spam-Status: No, score=-5.268 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_63=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 v1eQ-1jTiUiR for ; Tue, 19 May 2009 02:36:14 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1E7433A6FF1 for ; Tue, 19 May 2009 02:36:00 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-86-4a127de056f1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 67.36.02531.0ED721A4; Tue, 19 May 2009 11:37:36 +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, 19 May 2009 11:37:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 May 2009 11:37:34 +0200 Message-ID: In-Reply-To: <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACM SBC TLS issue [was RE: [Simple] MSRP-ACM compatibility] Thread-Index: AcnYBLkZQah8vU2bQQC/5Bie64mPVAAP7KVA References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 19 May 2009 09:37:35.0947 (UTC) FILETIME=[713699B0:01C9D865] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: [Simple] ACM SBC TLS issue [was RE: 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, 19 May 2009 09:36:16 -0000 Hi, Thanks for the information! I think I can see the missing puzzle piece now :)=20 >>>>SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the >>>>IP address/ports are not used for the certificate. So, as long as=20 >>>>both the ACM client/SBC belong to foobar.dom, and the MSRP client/relay >>>>belong to anotherfoobar.com, the SBC and relay can have the same=20 >>>>certificate as the client behind them. Or? >>> >>>As far as Hadriel's comment, it depends on what one puts _in_ the=20 >>>subjectAltName field. You _could_ put just an IP address in there,=20 >>>although I submit that would be a bad idea. >>> >>>But to put your statement more generally: If the, sbc, or other=20 >>>intermediary has a subjectAltName entry that matches the authority=20 >>>part of a client's adjacent MSRP device (i.e. the next hop in the=20 >>>a=3Dpath attribute), then we're fine. >>> >>>The problem is, the SBC is not likely to be in the same domain as=20 >>>_both_ endpoints. So from at least one endpoint's perspective,=20 >>>there's likely to be a mismatch. >> >>Why doesn't the relay need to get the certificate information in=20 >>legacy MSRP then? I don't think we can assume that the relay belongs=20 >>to the same domain as both endpoints, can we? >=20 >I'm not sure I understand your question-The assumption in=20 >RFC4576 is that an MSRP Relay will have a certificate that is=20 >signed by a well- known certificate authority. I agree that=20 >we can't assume a relay belongs to the same domain as both=20 >endpoints, but RFC4976 does not require that. It's only when=20 >the device that terminates the TCP connection is not the same=20 >device that terminates the TLS handshake that we have a=20 >problem. That doesn't happen in RFC4976 natively--only when a=20 >middlebox changes the path attribute. >=20 >>I have a feeling that I am missing some piece of the puzzle here, and=20 >>I appologise for that, but I am still trying to figure out this is=20 >>specific to ACM :) > >=20 >It's specific to having a middlebox modify the SDP path property. Let me try an example: >=20 >Alice is behind an SBC. That SBC acts as a TCP relay, but=20 >transparently tunnels TLS rather than terminating it. (much=20 >in the way an HTTPS proxy tunnels TLS). Alice sends an offer=20 >to Bob. Her path attribute looks like: >=20 >a=3Dpath: msrps;//alice.atlanta.com:1234/fieru;tcp >=20 >The SBC modifies the authority part of the URI to point to=20 >itself, and creates a binding so that all traffic to its port=20 >forwards to alice: >=20 >a=3Dpath: msrps;//sbc.atlanta.com:88039/fieru;tcp >=20 >Bob uses a relay. His answer contains: >=20 >a=3Dpath:msrps://relay.biloxi.com:84930/asfieu;tcp msrps;//=20 >bob.biloxi.com:1234/bzerts;tcp >=20 >Alice's SBC modified the answer to also point to itself, and=20 >completes the binding >=20 >a=3Dpath:msrps://sbc.atlanta.com:88040/asfieu;tcp=20 >msrps;//bob.biloxi.com:=20 >1234/bzerts;tcp >=20 >Alice now opens a TCP connection to sbc.atlanta.com:88040,=20 >and initiates a TLS handshake. This is forwarded=20 >transparently to relay.biloxi.com, which provides its TLS=20 >server certificate containing "relay.biloxi.com" in its=20 >subjectAltName field. >=20 >Alice's UA checks the certificate for the name=20 >"sbc.atlanta.com", since that was the name it saw in the SDP.=20 >The cert provided by relay.biloxi.com does not contain that=20 >name, so the TLS server authentication fails. Ok. One way of dealing with this is, as we have discussed, to include sertificate information in the signalling. In the example above, Alice would be told to check for the name "relay.biloxi.com", instead of "sbc.atlanta.com". Another way of dealing with this is of course to say that the intermeidate MUST terminate TLS in this case. If BOTH Alice and Bob open TCP connections (since Bob is behind a relay, I assume he would ALWAYS be "active"), the intermeidate may need to terminate TLS anyway, in order to avoid the handshake collision? Now, one could claim that it is difficult to know what intermediates will do, since they are not standardized. Jon also asked whether we would need to specify a new kind of TLS intermediate. If we want to specify something, I am not sure we need to talk specifically about intermeidates. I think we can be more generic, and e.g. talking about "entities which generate SDP for MSRP". That would then apply to any type of entity. "An entity which inserts its authority part in the URI of the a=3Dpath header needs to ensure that a matching certificate is provided to other entities which connect to it. This can be achieved by terminating TLS connections (instead of being TLS transparent) or by providing correct certificate information in the signalling to other entities which connect to it." ...or something like that. I think that applies to all kind of MSRP entities - including intermediates. Regards, Christer From ben@nostrum.com Tue May 19 14:38: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 0783D3A6C66 for ; Tue, 19 May 2009 14:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.285, 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 ianKyXlDQFZD for ; Tue, 19 May 2009 14:38:14 -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 C963F3A6B8A for ; Tue, 19 May 2009 14:38: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 n4JLdiIJ076905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 May 2009 16:39:48 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <90B727F7-964C-4840-828C-7B35A677A39A@nostrum.com> From: Ben Campbell To: Simple WG In-Reply-To: <59ED1195-D1B7-4DA6-9579-33E6E57418C1@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 19 May 2009 16:39:42 -0500 References: <59ED1195-D1B7-4DA6-9579-33E6E57418C1@nostrum.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [Simple] MSRP-ACM Discussion Summary 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, 19 May 2009 21:38:15 -0000 (as individual) On May 18, 2009, at 4:11 PM, Ben Campbell wrote: > The discussion thread on MSRP-ACM seems to be dying out, and I don't > think we've reached closure on most of it. In order to jump start > it, I am going to attempt to summarize the issues that I think are > still open. I will start separate threads for each issue. Please > reply to _this_ message to comment on whether I have offered a fair > summary, or mischaracterized or omitted anything material. Please > reply to the specific issue threads to discuss the issues themselves. Since Christer split the ongoing thread along pretty much the same lines that I intended, I will not start redundant threads as I threatened to do above :-) Thanks! Ben. From ben@nostrum.com Tue May 19 15:07: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 EE8C828C38B for ; Tue, 19 May 2009 15:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.257, 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 Sn8HIol39iM6 for ; Tue, 19 May 2009 15:07: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 DC6953A6C28 for ; Tue, 19 May 2009 15:05:47 -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 n4JM7Jhd078995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 17:07:20 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <0EF333C2-8CB2-44DA-B412-7F0FB709D822@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 v935.3) Date: Tue, 19 May 2009 17:07:19 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] ACM and comedia [was RE: 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, 19 May 2009 22:07:45 -0000 On May 19, 2009, at 3:41 AM, Christer Holmberg wrote: > > Hi, > >>>>> FIRST, RFC4572 already defines the usage of the fingerprint > attribute, >>>>> so wouldn't your issue also apply if you ONLY use COMEDIA, with > relays? >>>> >>>> If you use COMEDIA-TLS, yes. Not if just use RFC4145, or follow > _just_ >>>> the connection-direction parts of the ACM draft. >>> >>> Chapter 4.1.2, which belongs to the comedia part of the ACM draft, >>> does refer to RFC4572, so my assumption so far has been that "using >>> the comedia part" would also include RFC4572 for TLS. >>> >>> So, when talking about comedia, I guess we need to separate between >>> "using the comedia part" (which, for TLS, includes the fingerprint >>> attribute) and "using just the connection-direction parts of >>> comedia". >>> >>> And, even without the fingerprint, you still have the TLS collision >>> issue if both endpoints are "active". >> >> Ah, I see what you mean. I agree, the issue with using >> fingerprints for relay certificates is true just for the >> COMEDIA use currently defined in the ACM draft. > > There are actually a number of comedia issues, but it seems like I > have > mixed them. I'll try to separate them: > > FIRST, if we don't use the fingerprint attribute when the MSRP clients > use self-signed signatures, we are not compliant with RFC4572. Do we > want to go that way? Do we have the mandate to go that way? Will the > security people have issues with that? That's a very good question. I originally missed out on the fact that use of the fingerprint was a requirement in RFC4572 rather than an option. (It surprises me, as it only seems to apply when using self- signed certs _and_ when you have a protected signaling channel.) It doesn't seem necessary in the case where you have relays with certs that are signed by well-known CAs. I don't think this was a scenario envisioned by COMEDIA-TLS, which only talks about direct connections between endpoints. OTOH, I am not particularly inclined to countermand normative requirements in 4572 without a really strong consensus to do so. Hopefully everyone reading this realized now that this affects the use of COMEDIA even without the c-line and/or path attribute modification, so even if we split sections 4.1 (comedia) and 4.2 (c-line/path attr) into separate docs we would have to deal with this in the draft resulting from 4.1. > > > Without relays I guess there would be no issue with using the > fingerprint attribute (again, I am only talking about pure comedia > here > - not SBC impacts etc). But, even with relays, I guess it would be > possible to provide the fingerprint of the remote client to the relay > e.g. using the AUTH method. I think it is technically possible to do so, if we have consensus to update 4975 and 4976 to support it. > > > > SECOND, the handshake collision occurs when both endpoints are > "active". > AFAIK, that has nothing to do with whether the fingerprint is used or > not. I'm a little confused on this one--I didn't think RFC4145 allowed the active/active case. > > > > THIRD (new), I assume an MSRP entity behind a relay would always be > "active". I am not sure whether that is an issue, but it should > probably > be mentioned in the draft. I don't think that's necessarily the case--very likely it will be "passive". I don't think the COMEDIA negotiation affects how an endpoint connects to its own relay. It's really about connection between the edge-device operating on behalf on one endpoint and the edge-device operating on behalf of the other endpoint. For example, imagine Alice has a relay, and Bob does not. Alice will always connect to her relay. The COMEDIA negotiation will control whether Bob connects to the relay, or the relay connects to Bob. (I'm starting to feel the need for some example call flows) > > > > Regards, > > Christer > > > From ben@nostrum.com Tue May 19 15:14: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 E5FDB3A6872 for ; Tue, 19 May 2009 15:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 IMW6RiDzBavn for ; Tue, 19 May 2009 15:14:06 -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 A703828C31B for ; Tue, 19 May 2009 15:14:03 -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 n4JMFaSQ079656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 17:15:36 -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 v935.3) Date: Tue, 19 May 2009 17:15:36 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] ACM SBC TLS issue [was RE: 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, 19 May 2009 22:14:07 -0000 On May 19, 2009, at 4:37 AM, Christer Holmberg wrote: [...] > > > One way of dealing with this is, as we have discussed, to include > sertificate information in the signalling. In the example above, Alice > would be told to check for the name "relay.biloxi.com", instead of > "sbc.atlanta.com". > I think that's effectively similar to sending the fingerprint; it's just a different thing to match on. > > Another way of dealing with this is of course to say that the > intermeidate MUST terminate TLS in this case. If BOTH Alice and Bob > open > TCP connections (since Bob is behind a relay, I assume he would ALWAYS > be "active"), the intermeidate may need to terminate TLS anyway, in > order to avoid the handshake collision? > > > Now, one could claim that it is difficult to know what intermediates > will do, since they are not standardized. Jon also asked whether we > would need to specify a new kind of TLS intermediate. > > If we want to specify something, I am not sure we need to talk > specifically about intermeidates. I think we can be more generic, and > e.g. talking about "entities which generate SDP for MSRP". That would > then apply to any type of entity. > > "An entity which inserts its authority part in the URI of the a=path > header needs to ensure that a matching certificate is provided to > other > entities which connect to it. This can be achieved by terminating TLS > connections (instead of being TLS transparent) or by providing correct > certificate information in the signalling to other entities which > connect to it." > > ...or something like that. I think that applies to all kind of MSRP > entities - including intermediates. As I mentioned in SF, I think we should be careful to avoid suggesting that intermediaries lead an endpoint to believe it has end-to-end TLS protection when it does really doesn't. One of the reasons for the path attribute in the first place was to make it clear to endpoints that there were relays in the path. SBCs/ALGs are generally not that open about their presence. > > > > > Regards, > > Christer > From ben@estacado.net Tue May 19 15:21: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 B3B523A6A1F for ; Tue, 19 May 2009 15:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=-0.163, 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 wu5hC58thh6Z for ; Tue, 19 May 2009 15:21: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 2DCBC3A6889 for ; Tue, 19 May 2009 15:20:50 -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 n4JMMMc0009442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 17:22:22 -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 v935.3) Date: Tue, 19 May 2009 17:22:22 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> X-Mailer: Apple Mail (2.935.3) Cc: Simple WG Subject: Re: [Simple] What ACM is all about [was: RE: 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, 19 May 2009 22:21:28 -0000 See my rant at the end, in response to Christer's email. I haven't sent it to the list yet. Am I grasping at too abstract a concept? I.e., ignoring the basic repugnancy of SBCs, is it reasonable to argue that we shouldn't _in_general_ modify protocol to work with proprietary devices without documenting our assumptions about said device behavior and how the protocol modification works with these assumptions? ------------------------------------ (as individual) On May 19, 2009, at 12:40 AM, Christer Holmberg wrote: > > Hi, > >>>> In particular, I am skeptical about doing non-trivial changes >>>> to make MSRP work better across proprietary intermediaries without >>>> some better description of what will and will not work in >>>> the general case (i.e. not just what will work with one vendor.) >>> >>> As said before, I don't think this is about "one vendor". >> >> So what _is_ it about? To my knowledge, We've had only one vendor >> stand up and say "this stuff will work across our SBCs". >> >> You are trying to work around the behavior of proprietary middle >> boxes. They may behave similarly in some ways, but not others. For >> example, if other vendors don't have support for TCP media, then >> there's not much value in this for them. Without some standard >> behavior, or some survey of behavior like BEHAVE did with >> NATs, we're just sort of hoping things will work most of the time. >> That > may be >> good enough to write product requirements around, but it's probably >> not good enough to write standards around. > > What it is about is to allow these middle boxes to treat MSRP more or > less like any other type of TCP media, without having to modify the > MSRP > messages etc. > > Of course, some intermediates may not support TCP in the first place, > but that's normal. We don't expect everyone to support everything we > do. > > But, OMA PoC uses MSRP, so compliant intermediates will have to > support > TCP. 3GPP IMS uses MSRP, so compliant intermediates will have to > support > TCP. Intermediates also DO exist in other SIP networks, so in order > for > MSRP to work they will have to support TCP. That is what I meant by > the > statement that it's not only about one vendor. Forgive my ignorance, but does PoC specify intermediary behavior? > > > So, in my opinion, intermediates can be expected to support TCP. The > issue is with supporting legacy MSRP, and that is what ACM is trying > to > solve. > > I do agree that these intermediates aren't standardized, but when it > comes to sending the media through them they all behave in the same > way: > by modifying the SDP. > > > Of course, If we also for ACM would still use the a=path attribute for > routing, rather than the c/,- line, the intermeidates will of course > have to be able to modify the a=path attribute. But, no matter whather > that can be done using configuration (I guess that is what Hadirel > indicated for his product) or whether it requires a software patch, > it's > a relatively small thing compared to having to modify MSRP messages. > Do we expect this draft to specify the actual middlebox behavior that is enabled by changing the treatment of the path attribute URIs? The point I am struggling with is, this part of the ACM draft does not add value in itself. Rather, it sets out to relax an MSRP requirement to enable another middlebox to add value. But the behavior of that middlebox is not standardized, and we haven't really analyzed the requirements for the middlebox to get its job done. And we know full well that there are security implications both in this new behavior we propose for the middlebox (i.e. rewriting path attributes) as well as the presence of the middlebox in the first place. This is pretty much the same argument that has been popping up in all of RAI concerning the collision between SBCs and the SIP architecture as defined by the IETF. If we are going to change MSRP to enable SBCs or any other sort of middlebox, I'd really like to see more documentation on how that middlebox is expected to behave in context, and how the whole architecture works when said middlebox is present. I'm not necessarily talking about normative specification.This is the point I was trying to get across in previous reviews when I suggested we needed some use case analysis and possibly call flows to describe the requirements that section 4.2 sets out to solve. We spun up a whole working group (BEHAVE) to do this for NATs, and subsequently learned that many of or generally held assumptions were wrong. From ben@nostrum.com Tue May 19 17:00:37 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 4793F3A6B88 for ; Tue, 19 May 2009 17:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 oOdYH8Z65fms for ; Tue, 19 May 2009 17:00:36 -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 DDE9D3A6D4B for ; Tue, 19 May 2009 17:00:35 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-44-120.dsl.rcsntx.swbell.net [68.94.44.120]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n4K01n8L087271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 19:01:50 -0500 (CDT) (envelope-from ben@nostrum.com) References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> Message-Id: <76B44E1B-FF23-41A8-B35D-2F5C49BF6ED8@nostrum.com> From: Ben Campbell To: Ben Campbell In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (5H11) Mime-Version: 1.0 (iPhone Mail 5H11) Date: Tue, 19 May 2009 19:01:46 -0500 Received-SPF: pass (nostrum.com: 68.94.44.120 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] What ACM is all about [was: RE: 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, 20 May 2009 00:00:37 -0000 Well, crud. The top part of that was a private email that I accidentally copied. Please ignore anything anything above the "as individual" comment. Clearly I am not qualified to work this new-fangled Internet thing. On May 19, 2009, at 5:22 PM, Ben Campbell wrote: > See my rant at the end, in response to Christer's email. I haven't > sent it to the list yet. > > Am I grasping at too abstract a concept? I.e., ignoring the basic > repugnancy of SBCs, is it reasonable to argue that we shouldn't > _in_general_ modify protocol to work with proprietary devices > without documenting our assumptions about said device behavior and > how the protocol modification works with these assumptions? > > ------------------------------------ > > (as individual) > > On May 19, 2009, at 12:40 AM, Christer Holmberg wrote: > >> >> Hi, >> >>>>> In particular, I am skeptical about doing non-trivial changes >>>>> to make MSRP work better across proprietary intermediaries without >>>>> some better description of what will and will not work in >>>>> the general case (i.e. not just what will work with one vendor.) >>>> >>>> As said before, I don't think this is about "one vendor". >>> >>> So what _is_ it about? To my knowledge, We've had only one vendor >>> stand up and say "this stuff will work across our SBCs". >>> >>> You are trying to work around the behavior of proprietary middle >>> boxes. They may behave similarly in some ways, but not others. For >>> example, if other vendors don't have support for TCP media, then >>> there's not much value in this for them. Without some standard >>> behavior, or some survey of behavior like BEHAVE did with >>> NATs, we're just sort of hoping things will work most of the time. >>> That >> may be >>> good enough to write product requirements around, but it's probably >>> not good enough to write standards around. >> >> What it is about is to allow these middle boxes to treat MSRP more or >> less like any other type of TCP media, without having to modify the >> MSRP >> messages etc. >> >> Of course, some intermediates may not support TCP in the first place, >> but that's normal. We don't expect everyone to support everything >> we do. >> >> But, OMA PoC uses MSRP, so compliant intermediates will have to >> support >> TCP. 3GPP IMS uses MSRP, so compliant intermediates will have to >> support >> TCP. Intermediates also DO exist in other SIP networks, so in order >> for >> MSRP to work they will have to support TCP. That is what I meant by >> the >> statement that it's not only about one vendor. > > Forgive my ignorance, but does PoC specify intermediary behavior? > >> >> >> So, in my opinion, intermediates can be expected to support TCP. The >> issue is with supporting legacy MSRP, and that is what ACM is >> trying to >> solve. >> >> I do agree that these intermediates aren't standardized, but when it >> comes to sending the media through them they all behave in the same >> way: >> by modifying the SDP. >> >> >> Of course, If we also for ACM would still use the a=path attribute >> for >> routing, rather than the c/,- line, the intermeidates will of course >> have to be able to modify the a=path attribute. But, no matter >> whather >> that can be done using configuration (I guess that is what Hadirel >> indicated for his product) or whether it requires a software patch, >> it's >> a relatively small thing compared to having to modify MSRP messages. >> > > Do we expect this draft to specify the actual middlebox behavior > that is enabled by changing the treatment of the path attribute URIs? > > The point I am struggling with is, this part of the ACM draft does > not add value in itself. Rather, it sets out to relax an MSRP > requirement to enable another middlebox to add value. But the > behavior of that middlebox is not standardized, and we haven't > really analyzed the requirements for the middlebox to get its job > done. And we know full well that there are security implications > both in this new behavior we propose for the middlebox (i.e. > rewriting path attributes) as well as the presence of the middlebox > in the first place. > > This is pretty much the same argument that has been popping up in > all of RAI concerning the collision between SBCs and the SIP > architecture as defined by the IETF. > > If we are going to change MSRP to enable SBCs or any other sort of > middlebox, I'd really like to see more documentation on how that > middlebox is expected to behave in context, and how the whole > architecture works when said middlebox is present. I'm not > necessarily talking about normative specification.This is the point > I was trying to get across in previous reviews when I suggested we > needed some use case analysis and possibly call flows to describe > the requirements that section 4.2 sets out to solve. > > We spun up a whole working group (BEHAVE) to do this for NATs, and > subsequently learned that many of or generally held assumptions were > wrong. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue May 19 22: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 57B2028C137 for ; Tue, 19 May 2009 22:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=0.380, 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 st2s3mhFXmYM for ; Tue, 19 May 2009 22:06:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3AD5F3A68AF for ; Tue, 19 May 2009 22:06:17 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-fa-4a1390280ebb Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7C.F2.02531.820931A4; Wed, 20 May 2009 07:07:52 +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, 20 May 2009 07:07:52 +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, 20 May 2009 07:07:51 +0200 Message-ID: In-Reply-To: <90B727F7-964C-4840-828C-7B35A677A39A@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-ACM Discussion Summary Thread-Index: AcnYylqX1gayDFUxTaWfRHCU8CTxlgAPnj7Q References: <59ED1195-D1B7-4DA6-9579-33E6E57418C1@nostrum.com> <90B727F7-964C-4840-828C-7B35A677A39A@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" , "Simple WG" X-OriginalArrivalTime: 20 May 2009 05:07:52.0347 (UTC) FILETIME=[ED72F6B0:01C9D908] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] MSRP-ACM Discussion Summary 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, 20 May 2009 05:06:24 -0000 Hi,=20 >>The discussion thread on MSRP-ACM seems to be dying out, and I don't=20 >>think we've reached closure on most of it. In order to jump start it,=20 >>I am going to attempt to summarize the issues that I think are still=20 >>open. I will start separate threads for each issue. Please reply to=20 >>_this_ message to comment on whether I have offered a fair summary, or >>mischaracterized or omitted anything material. Please reply to the=20 >>specific issue threads to discuss the issues themselves. >=20 >Since Christer split the ongoing thread along pretty much the=20 >same lines that I intended, I will not start redundant=20 >threads as I threatened to do above :-) I did the split before I realized that you intented to do the same. Sorry for that :) Regards, Christer From christer.holmberg@ericsson.com Wed May 20 00:10: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 4DABF3A6B6C for ; Wed, 20 May 2009 00:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.379, 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 N6ZIG2Duvseb for ; Wed, 20 May 2009 00:10:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D9CC428C0F9 for ; Wed, 20 May 2009 00:10:11 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-ed-4a13ad33a3cd Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 36.2F.02531.33DA31A4; Wed, 20 May 2009 09:11:47 +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, 20 May 2009 09:11:47 +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, 20 May 2009 09:11:45 +0200 Message-ID: In-Reply-To: <0EF333C2-8CB2-44DA-B412-7F0FB709D822@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACM and comedia [was RE: [Simple] MSRP-ACM compatibility] Thread-Index: AcnYzi/vIaBZEtsQRcOEgcrpYIXvVwAQ5RlA References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <0EF333C2-8CB2-44DA-B412-7F0FB709D822@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 20 May 2009 07:11:47.0009 (UTC) FILETIME=[3CDA5B10:01C9D91A] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] ACM and comedia [was RE: 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, 20 May 2009 07:10:13 -0000 Hi,=20 >>FIRST, if we don't use the fingerprint attribute when the MSRP clients >>use self-signed signatures, we are not compliant with RFC4572. Do we=20 >>want to go that way? Do we have the mandate to go that way? Will the=20 >>security people have issues with that? >=20 >That's a very good question. I originally missed out on the=20 >fact that use of the fingerprint was a requirement in RFC4572=20 >rather than an option. (It surprises me, as it only seems to=20 >apply when using self- signed certs _and_ when you have a=20 >protected signaling channel.) It doesn't seem necessary in=20 >the case where you have relays with certs that are signed by=20 >well-known CAs. I don't think this was a scenario envisioned=20 >by COMEDIA-TLS, which only talks about direct connections=20 >between endpoints. We need to look into that. But, without relays you could of course have direct connections also between MSRP endpoints. >OTOH, I am not particularly inclined to countermand normative=20 >requirements in 4572 without a really strong consensus to do so. =20 >Hopefully everyone reading this realized now that this=20 >affects the use of COMEDIA even without the c-line and/or=20 >path attribute modification, so even if we split sections 4.1 (comedia) and 4.2=20 >(c-line/path attr) into separate docs we would have to deal with this in the=20 >draft resulting from 4.1. Yes. I haven't commented your summary yet, but I think we need to make clear that there are still comedia issues that we need to look into. --------- >>Without relays I guess there would be no issue with using the=20 >>fingerprint attribute (again, I am only talking about pure comedia=20 >>here - not SBC impacts etc). But, even with relays, I guess it would be=20 >>possible to provide the fingerprint of the remote client to the relay=20 >>e.g. using the AUTH method. >=20 >I think it is technically possible to do so, if we have=20 >consensus to update 4975 and 4976 to support it. Would we need to update 4975 and 4976 for that? Wouldn't it be part of the ACM comedia extension? The draft would define a new URI parameter. Of course, there could be a case where the client supports comedia, and the relay doesn't, and then I guess the relay would discard the fingerprint in the AUTH. --------- >>SECOND, the handshake collision occurs when both endpoints are "active". >>AFAIK, that has nothing to do with whether the fingerprint is used or >>not. >=20 >I'm a little confused on this one--I didn't think RFC4145 allowed the active/active case. I think it's one of the new use-cases that Adam indicated would now be supported. But, maybe RFC4145 doesn't support "direct" active/active between the endpoints, so you would need to have an intermeidate in between in that case. --------- >>THIRD (new), I assume an MSRP entity behind a relay would always be >>"active". I am not sure whether that is an issue, but it should probably >>be mentioned in the draft. >=20 >I don't think that's necessarily the case--very likely it will be =20 >"passive". I don't think the COMEDIA negotiation affects how an =20 >endpoint connects to its own relay. It's really about connection =20 >between the edge-device operating on behalf on one endpoint and the =20 >edge-device operating on behalf of the other endpoint. Well, comedia doesn't distinguish between relays, edge-devices and endpoints, does it? It only talks about establishing a TCP connection towards a remote location. But, I guess we need to think a little more about that. --------- >For example, imagine Alice has a relay, and Bob does not. Alice will =20 >always connect to her relay. The COMEDIA negotiation will control =20 >whether Bob connects to the relay, or the relay connects to Bob. The relay is not aware of the comedia negotiation, so it will only connect to Bob if Alice sends a SEND and a TCP connection doesn't exist. But, based on the discussion we had Alice would send a SEND if she is "active", so it would work. --------- =20 >(I'm starting to feel the need for some example call flows) Yes. Regards, Christer From christer.holmberg@ericsson.com Wed May 20 05:15:39 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 D1BE328C38B for ; Wed, 20 May 2009 05:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=0.077, 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 BHG2y2zuc8BU for ; Wed, 20 May 2009 05:15:38 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3055D3A6BB2 for ; Wed, 20 May 2009 05:15:33 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-f5-4a13f4c5ed0f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D1.C2.02630.5C4F31A4; Wed, 20 May 2009 14:17:09 +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, 20 May 2009 14:17: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: Wed, 20 May 2009 14:17:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACM SBC TLS issue [was RE: [Simple] MSRP-ACM compatibility] Thread-Index: AcnYz1woDCrmOslIRiSLNikuyIdbFgASzj2Q References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 20 May 2009 12:17:09.0042 (UTC) FILETIME=[E5A2B920:01C9D944] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] ACM SBC TLS issue [was RE: 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, 20 May 2009 12:15:39 -0000 Hi,=20 >> >> >>One way of dealing with this is, as we have discussed, to include=20 >>sertificate information in the signalling. In the example above, Alice >>would be told to check for the name "relay.biloxi.com", instead of=20 >>"sbc.atlanta.com". >> >=20 >I think that's effectively similar to sending the=20 >fingerprint; it's just a different thing to match on. Correct. I used the domain names in order to be able to correlate to your example :) >>Another way of dealing with this is of course to say that the >>intermeidate MUST terminate TLS in this case. If BOTH Alice and Bob =20 >>open TCP connections (since Bob is behind a relay, I assume he=20 >>would ALWAYS be "active"), the intermeidate may need to terminate TLS anyway, in >>order to avoid the handshake collision? >> >> >>Now, one could claim that it is difficult to know what intermediates >>will do, since they are not standardized. Jon also asked whether we >>would need to specify a new kind of TLS intermediate. >> >>If we want to specify something, I am not sure we need to talk >>specifically about intermeidates. I think we can be more generic, and >>e.g. talking about "entities which generate SDP for MSRP".=20 >>That would then apply to any type of entity. >> >>"An entity which inserts its authority part in the URI of the a=3Dpath >>header needs to ensure that a matching certificate is provided to =20 >>other entities which connect to it. This can be achieved by=20 >>terminating TLS connections (instead of being TLS transparent) or by=20 >>providing correct certificate information in the signalling to other entities which >>connect to it." >> >>...or something like that. I think that applies to all kind of MSRP >>entities - including intermediates. >=20 >As I mentioned in SF, I think we should be careful to avoid=20 >suggesting that intermediaries lead an endpoint to believe it has=20 >end-to-end TLS protection when it does really doesn't. Even with legacy MSRP it IS possible to insert intermediates (eventhough they would have to modify the MSRP messages), so you already have the problem - as you have with any other type of media. But, in some cases the clients can at least make some assumptions by comparing the certificate domains with the path attribute domains. So, in your example above, no matter if the TLS is terminated by the SBC or the relay, Alice would detect that it's not end-to-end. If terminated by the SBC, Alice could also detect that it's not even terminated in the beloxi.com domain. >One of the reasons for the path attribute in the first place was to make it clear to endpoints that there were relays in the path. SBCs/ALGs are generally not that open about their presence. Sure, but do we really expect the user to really make different decissions based on that knowledge? Will the user even be informed about whether there are relays in the path or not?=20 If I want to establish an MSRP session with you, I probably wouldn't care whether you are behind a relay or not. I would trust that the operator(s) make sure my stuff doesn't end up in the wrong hands. And, if I have something very very very sensitive to send you, I may encrypt the payload myself, and not rely on the MSRP provided encryption - because even if I start looking at the path attributes etc I can still not be 100% that there is no intermediate somewhere. > Regards, Christer From christer.holmberg@ericsson.com Wed May 20 05:53: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 73BC73A69B0 for ; Wed, 20 May 2009 05:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=0.077, 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 wmXAaltAqmgm for ; Wed, 20 May 2009 05:53:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C64A73A6930 for ; Wed, 20 May 2009 05:53:14 -0700 (PDT) X-AuditID: c1b4fb3c-b7b87ae000000ec5-7b-4a13fd99b247 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 67.AC.03781.A9DF31A4; Wed, 20 May 2009 14:54:50 +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, 20 May 2009 14:54:48 +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, 20 May 2009 14:54:47 +0200 Message-ID: In-Reply-To: <76B44E1B-FF23-41A8-B35D-2F5C49BF6ED8@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] What ACM is all about [was: RE: MSRP-ACM compatibility Thread-Index: AcnY3i7jXzBBRs5nQey5P/U8gFm6SAAaWDqQ References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <76B44E1B-FF23-41A8-B35D-2F5C49BF6ED8@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" , "Ben Campbell" X-OriginalArrivalTime: 20 May 2009 12:54:48.0844 (UTC) FILETIME=[289524C0:01C9D94A] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] What ACM is all about [was: RE: 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, 20 May 2009 12:53:16 -0000 Hi,=20 >>>>>>In particular, I am skeptical about doing non-trivial changes to=20 >>>>>>make MSRP work better across proprietary intermediaries without=20 >>>>>>some better description of what will and will not work in the=20 >>>>>>general case (i.e. not just what will work with one vendor.) >>>>> >>>>>As said before, I don't think this is about "one vendor". >>>> >>>>So what _is_ it about? To my knowledge, We've had only one vendor=20 >>>>stand up and say "this stuff will work across our SBCs". >>>> >>>>You are trying to work around the behavior of proprietary middle=20 >>>>boxes. They may behave similarly in some ways, but not others. For=20 >>>>example, if other vendors don't have support for TCP media, then=20 >>>>there's not much value in this for them. Without some standard=20 >>>>behavior, or some survey of behavior like BEHAVE did with NATs,=20 >>>>we're just sort of hoping things will work most of the time. >>>>That may be good enough to write product requirements around, but=20 >>>>it's probably not good enough to write standards around. >>> >>>What it is about is to allow these middle boxes to treat MSRP more or >>>less like any other type of TCP media, without having to modify the=20 >>>MSRP messages etc. >>> >>>Of course, some intermediates may not support TCP in the first place, >>>but that's normal. We don't expect everyone to support everything we=20 >>>do. >>> >>>But, OMA PoC uses MSRP, so compliant intermediates will have to=20 >>>support TCP. 3GPP IMS uses MSRP, so compliant intermediates will have >>>to support TCP. Intermediates also DO exist in other SIP networks, so >>>in order for MSRP to work they will have to support TCP.=20 >>>That is what I meant by the statement that it's not only about one vendor. >> >>Forgive my ignorance, but does PoC specify intermediary behavior? I would have to double check exactly what it specifies. PoC does use c/m- based MSRP routing, though. >>>So, in my opinion, intermediates can be expected to support TCP. The=20 >>>issue is with supporting legacy MSRP, and that is what ACM is trying=20 >>>to solve. >>> >>>I do agree that these intermediates aren't standardized, but when it=20 >>>comes to sending the media through them they all behave in the same >>>way: by modifying the SDP. >>> >>> >>>Of course, If we also for ACM would still use the a=3Dpath attribute=20 >>>for routing, rather than the c/,- line, the intermeidates will of=20 >>>course have to be able to modify the a=3Dpath attribute.=20 >>>But, no matter whather that can be done using configuration (I guess that is what=20 >>>Hadirel indicated for his product) or whether it requires=20 >>>a software patch, it's a relatively small thing compared to having to modify=20 >>>MSRP messages. >>> >> >>Do we expect this draft to specify the actual middlebox behavior that=20 >>is enabled by changing the treatment of the path attribute URIs? We could specify the intermediate assumptions we make. But, I don't think we need to specify middlebox behavior. We have a generic specification which says that path is used to esatblish the MSRP route, and the fingerprint (if used) is used to provide the certificate information to use. Any intermediate would then need to act according to that - in a similar way as they act according to c/m routing rules for other media - if they want to support MSRP. If one does not want to support MSRP he/she can prevent MSRP from working no matter what we specify... >>The point I am struggling with is, this part of the ACM draft does not add value in itself. It makes it possible to easier deploy MSRP in a large number of network (no matter if we like the architecture of those networks or not), which I think adds value. People are not going to remove their intermediates just in order to make legacy MSRP to work - at least not until they have other mechanisms to do whatever functions those intermediates are performing. >>Rather, it sets out to relax an MSRP requirement to enable another middlebox to add value. But the behavior of that=20 >>middlebox is not standardized, and we haven't really analyzed the requirements for the middlebox to get its job done. And we know full=20 >>well that there are security implications both in this new behavior we propose for the middlebox (i.e. rewriting path attributes) as well as=20 >>the presence of the middlebox in the first place. >> >>This is pretty much the same argument that has been popping up in all of RAI concerning the collision between SBCs and the SIP architecture=20 >>as defined by the IETF. >> >>If we are going to change MSRP to enable SBCs or any other sort of middlebox, I'd really like to see more documentation on how that=20 >>middlebox is expected to behave in context, and how the whole architecture works when said middlebox is present. I'm not=20 >>necessarily talking about normative specification.This is the point I was trying to get across in previous reviews when I suggested we=20 >>needed some use case analysis and possibly call flows to describe the requirements that section 4.2 sets out to solve. As far as MSRP is concerned, the intermediate would need to modify the path attribute, and if fingerprint is used it would need to ensure that is correct (assuming it terminates TLS). I think that is covered by the generic text I proposed, but of course we can explicitly write down those assumptions on intermediates. We can also document the security issues which intermediates bring, but I don't think those are specific to MSRP. Regards, Christer From adam@nostrum.com Wed May 20 07:51: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 1EB453A6C49 for ; Wed, 20 May 2009 07:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 7lYNzyoRrXSy for ; Wed, 20 May 2009 07:51: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 EBEAD3A6B51 for ; Wed, 20 May 2009 07:51:55 -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 n4KErCVj054790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2009 09:53:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A141958.3010308@nostrum.com> Date: Wed, 20 May 2009 09:53:12 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ben Campbell References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@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] What ACM is all about [was: RE: 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, 20 May 2009 14:51:57 -0000 Ben Campbell wrote: > If we are going to change MSRP to enable SBCs or any other sort of > middlebox, I'd really like to see more documentation on how that > middlebox is expected to behave in context, and how the whole > architecture works when said middlebox is present. I'm not necessarily > talking about normative specification.This is the point I was trying > to get across in previous reviews when I suggested we needed some use > case analysis and possibly call flows to describe the requirements > that section 4.2 sets out to solve. > > We spun up a whole working group (BEHAVE) to do this for NATs, and > subsequently learned that many of or generally held assumptions were > wrong. I agree wholeheartedly with Ben's sentiment regarding the assumptions we're making about SBC behavior, and I think the comparison to NATs is quite appropriate. Saying that SBCs operate "by modifying the SDP"[1] is as useful as saying that NATs operate "by changing IP addresses." You can make certain assumptions about what these changes look like, but they're just assumptions. And right now, they're not even documented assumptions. We've been down this road before. For example, we spent a lot of work to develop a protocol to characterize NATs based on untested assumptions about NAT behavior. It was only after we actually spun up BEHAVE and did the work documented in draft-jennings-behave-test-results that we realized we had wasted vast man-years of engineering resources for naught. RFC 3489 stands as a tombstone to our hubris and carelessness. I am certain that we have relevant lessons to learn from BEHAVE, and that many of them fall in the category of "trying to engineer protocols around an undefined entity is folly." /a [1] http://www.ietf.org/mail-archive/web/simple/current/msg08392.html From adam@nostrum.com Wed May 20 07:58: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 096983A6801 for ; Wed, 20 May 2009 07:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 C6N0VIqh01MH for ; Wed, 20 May 2009 07:58:58 -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 DA29F3A67EF for ; Wed, 20 May 2009 07:58:57 -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 n4KF0DZD055336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2009 10:00:13 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A141AFD.7030109@nostrum.com> Date: Wed, 20 May 2009 10:00:13 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <76B44E1B-FF23-41A8-B35D-2F5C49BF6ED8@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] What ACM is all about [was: RE: 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, 20 May 2009 14:58:59 -0000 Christer Holmberg wrote: > As far as MSRP is concerned, the intermediate would need to modify the > path attribute, and if fingerprint is used it would need to ensure that > is correct (assuming it terminates TLS). > I think we have a disconnect here. One of the key arguments, as far as I understand it, for making the changes proposed in MSRP-ACM has to do with working through existing SBCs. Because, let's face it, if SBCs need to go mucking with more than just the c= and m= lines, then they may as well understand the MSRP-specific syntax anyway. If this is true, then backwards compatibility with deployed SBCs is not a design consideration. And here we have Christer saying that the intermediary would need to modify the a= lines in a MSRP-specific way. If that's the case, why are we chasing a requirement to relax the URI matching rules? /a From ben@nostrum.com Wed May 20 08:29: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 644513A6C3F for ; Wed, 20 May 2009 08:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 z0T5ZdYFKwKS for ; Wed, 20 May 2009 08:29:03 -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 3DFD23A69DF for ; Wed, 20 May 2009 08:29:03 -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 n4KFUY5x057530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 May 2009 10:30:34 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: From: Ben Campbell To: Adam Roach In-Reply-To: <4A141AFD.7030109@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 20 May 2009 10:30:34 -0500 References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <76B44E1B-FF23-41A8-B35D-2F5C49BF6ED8@nostrum.com> <4A141AFD.7030109@nostrum.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: [Simple] MSRP-ACM vs existing SBCs (was Re: What ACM is all about [was: RE: 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, 20 May 2009 15:29:04 -0000 On May 20, 2009, at 10:00 AM, Adam Roach wrote: > > I think we have a disconnect here. One of the key arguments, as far > as I understand it, for making the changes proposed in MSRP-ACM has > to do with working through existing SBCs. > > Because, let's face it, if SBCs need to go mucking with more than > just the c= and m= lines, then they may as well understand the MSRP- > specific syntax anyway. If this is true, then backwards > compatibility with deployed SBCs is not a design consideration. > > And here we have Christer saying that the intermediary would need to > modify the a= lines in a MSRP-specific way. > > If that's the case, why are we chasing a requirement to relax the > URI matching rules? < history review> Christer's original proposal was to have MSRP-ACM compliant devices use the c-line addressing rather than the "a=path" line, in order to be more friendly to existing SBCs. This would not work with MSRP relays, except in a pure "fall back to 4975 behavior model". The working group stated a requirement to support the scenario where an endpoint is behind an SBC, and it's peer is behind a relay. The a=path modification, and the relaxation of URI rules were an attempt to make ACM work with relays. We've since run into TLS cert matching complications with that approach. > > /a From pkyzivat@cisco.com Wed May 20 11:01: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 BC20D3A68F4 for ; Wed, 20 May 2009 11:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.398, 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 zkhxS82lk4Mk for ; Wed, 20 May 2009 11:01:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DE1993A6E1F for ; Wed, 20 May 2009 11:00:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,222,1241395200"; d="scan'208";a="167583849" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 20 May 2009 18:02:22 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4KI2LGB025140; Wed, 20 May 2009 14:02:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4KI2LB6027043; Wed, 20 May 2009 18:02:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 14:02:21 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 14:02:21 -0400 Message-ID: <4A1445AC.3070102@cisco.com> Date: Wed, 20 May 2009 14:02:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2009 18:02:21.0340 (UTC) FILETIME=[1F2095C0:01C9D975] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1729; t=1242842541; x=1243706541; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20ACM=20SBC=20TLS=20issue=20[w as=20RE=3A=20=20MSRP-ACM=20compatibility] |Sender:=20 |To:=20Christer=20Holmberg=20; bh=BFwbtqwHNc0iWoxrCVE8nadDpnZHS18Jhv0yAtAH4so=; b=H2TXPqfRxXOAEMdcEv03PY1dWbsu7+FTD87qFnyBYCRY2TJu3P5TojYHX6 wuKRXYR6PoPtR8+UO7+FFdr7fRLZRfk1TFwnsgz8zW/RWqEF6Lhww96Fq/rZ AN/w80r5lA; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Simple WG Subject: Re: [Simple] ACM SBC TLS issue [was RE: 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, 20 May 2009 18:01:14 -0000 Christer Holmberg wrote: >> One of the reasons for the path attribute in the first place was to > make it clear to endpoints that there were relays in the path. SBCs/ALGs > are generally not that open about their presence. > > Sure, but do we really expect the user to really make different > decissions based on that knowledge? Will the user even be informed about > whether there are relays in the path or not? This is really about the infamous "lock icon". In the case of MSRP it is a quite a bit simpler problem than with phones. Most of the ground has already been broken for https. I surely do make different sage decisions based on the lock icon in a web browser. I think people would quickly do so with a lock icon in an IM session window too, if it was properly socialized. > If I want to establish an MSRP session with you, I probably wouldn't > care whether you are behind a relay or not. I would trust that the > operator(s) make sure my stuff doesn't end up in the wrong hands. Right! They have such a good track record of keeping stuff private. > And, if I have something very very very sensitive to send you, I may > encrypt the payload myself, and not rely on the MSRP provided encryption > - because even if I start looking at the path attributes etc I can still > not be 100% that there is no intermediate somewhere. How would you do that in a way that is usable by anyone except a programmer? Most users are dependent on the available tools. Thanks, Paul >> > > Regards, > > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From christer.holmberg@ericsson.com Wed May 20 14:27: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 909FE3A6A15 for ; Wed, 20 May 2009 14:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.377, 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 exo9H4U6xWyY for ; Wed, 20 May 2009 14:27:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 638423A6A2D for ; Wed, 20 May 2009 14:27:28 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-c7-4a147620d1c1 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 60.26.02630.026741A4; Wed, 20 May 2009 23:29:04 +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, 20 May 2009 23:29: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, 20 May 2009 23:29:03 +0200 Message-ID: In-Reply-To: <4A1445AC.3070102@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] ACM SBC TLS issue [was RE: MSRP-ACM compatibility] Thread-Index: AcnZeW8e9SRjPhi6RiqNW48Jlq7AxQAF2vkQ References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <4A1445AC.3070102@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 20 May 2009 21:29:03.0974 (UTC) FILETIME=[FFAC5860:01C9D991] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] ACM SBC TLS issue [was RE: 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, 20 May 2009 21:27:29 -0000 Hi,=20 >>>If I want to establish an MSRP session with you, I probably wouldn't=20 >>>care whether you are behind a relay or not. I would trust that the >>>operator(s) make sure my stuff doesn't end up in the wrong hands. >> >>Right! >>They have such a good track record of keeping stuff private. But still we keep using them. >>And, if I have something very very very sensitive to send you, I may=20 >>encrypt the payload myself, and not rely on the MSRP provided=20 >>encryption >>- because even if I start looking at the path attributes etc I can=20 >>still not be 100% that there is no intermediate somewhere. >> >How would you do that in a way that is usable by anyone except a programmer? Most users are dependent on the available tools. My MSRP client may have a built-in option which allows me to encrypt the data. Regards, Christer From pkyzivat@cisco.com Wed May 20 14:52: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 512CF3A6B7A for ; Wed, 20 May 2009 14:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 Qonh4LT67y0d for ; Wed, 20 May 2009 14:52:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 698553A6A99 for ; Wed, 20 May 2009 14:52:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,223,1241395200"; d="scan'208";a="167674451" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 20 May 2009 21:54:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4KLs0DK021972; Wed, 20 May 2009 17:54:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4KLs0PR029814; Wed, 20 May 2009 21:54:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 17:54:00 -0400 Received: from [161.44.182.99] ([161.44.182.99]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 17:53:59 -0400 Message-ID: <4A147BF4.9030707@cisco.com> Date: Wed, 20 May 2009 17:53:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <4A1445AC.3070102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2009 21:53:59.0970 (UTC) FILETIME=[7B5B3820:01C9D995] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1176; t=1242856440; x=1243720440; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20ACM=20SBC=20TLS=20issue=20[w as=20RE=3A=20=20MSRP-ACM=20compatibility] |Sender:=20 |To:=20Christer=20Holmberg=20; bh=fHGSEcFGSfn8VPNYiNZF+UDDKxokR8NibZQ4/ewDDHQ=; b=yb0XVeD853/TQDpMIVjsk++GKOZ9tb7g+roDcSv5gyybeaUuPKm/mUzq3K H7lqrQn3ciaHcYmE4eilmsEblb8lZwBBn6QAJ8NRmddhsuJ+YbBuRDlCjjKe 3XsUd7P/Ha; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Simple WG Subject: Re: [Simple] ACM SBC TLS issue [was RE: 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, 20 May 2009 21:52:25 -0000 Christer Holmberg wrote: > Hi, > >>>> If I want to establish an MSRP session with you, I probably wouldn't >>>> care whether you are behind a relay or not. I would trust that the >>>> operator(s) make sure my stuff doesn't end up in the wrong hands. >>> Right! >>> They have such a good track record of keeping stuff private. > > But still we keep using them. We are stuck using whatever it takes to talk to who we want to talk to. We don't have the level of open interop and competition we do with web apps. >>> And, if I have something very very very sensitive to send you, I may >>> encrypt the payload myself, and not rely on the MSRP provided >>> encryption >>> - because even if I start looking at the path attributes etc I can >>> still not be 100% that there is no intermediate somewhere. >>> >> How would you do that in a way that is usable by anyone except a > programmer? Most users are dependent on the available tools. > > My MSRP client may have a built-in option which allows me to encrypt the > data. That of course assumes that the person on the other end has the same. Paul > Regards, > > Christer > > From christer.holmberg@ericsson.com Wed May 20 15:00: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 27DDB3A6CB3 for ; Wed, 20 May 2009 15:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.375, 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 RZX6yXhlKAOb for ; Wed, 20 May 2009 15:00:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C09493A69C9 for ; Wed, 20 May 2009 15:00:33 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-19-4a147de11d95 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 73.F6.02630.1ED741A4; Thu, 21 May 2009 00:02:10 +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, 21 May 2009 00:02: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: Thu, 21 May 2009 00:02:09 +0200 Message-ID: In-Reply-To: <4A147BF4.9030707@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] ACM SBC TLS issue [was RE: MSRP-ACM compatibility] Thread-Index: AcnZlX2ZbJix5ywKQf6xPJY5qJeXsAAALDBg References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <4A1445AC.3070102@cisco.com> <4A147 BF4.9030 707@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 20 May 2009 22:02:09.0669 (UTC) FILETIME=[9F3D5B50:01C9D996] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] ACM SBC TLS issue [was RE: 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, 20 May 2009 22:00:35 -0000 Hi,=20 >>>>>If I want to establish an MSRP session with you, I probably=20 >>>>>wouldn't care whether you are behind a relay or not. I would trust=20 >>>>>that the operator(s) make sure my stuff doesn't end up in the wrong hands. >>>>Right! >>>>They have such a good track record of keeping stuff private. >>=20 >>But still we keep using them. > >We are stuck using whatever it takes to talk to who we want to talk to. >We don't have the level of open interop and competition we do with web apps. Maybe not, but I am not really sure how that relates to MSRP ACM. >>>>And, if I have something very very very sensitive to send you, I may >>>>encrypt the payload myself, and not rely on the MSRP provided=20 >>>>encryption - because even if I start looking at the path attributes etc I can=20 >>>>still not be 100% that there is no intermediate somewhere. >>>> >>>How would you do that in a way that is usable by anyone except a programmer? Most users are dependent on the available tools. >>=20 >>My MSRP client may have a built-in option which allows me to encrypt the data. > >That of course assumes that the person on the other end has the same. Sure, but that is true for whatever security mechanism, on whatever level. Regards, Christer From christer.holmberg@ericsson.com Wed May 20 15:17:51 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 6EA7D3A6CF3 for ; Wed, 20 May 2009 15:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.875 X-Spam-Level: X-Spam-Status: No, score=-5.875 tagged_above=-999 required=5 tests=[AWL=0.374, 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 fmzk15x62HW9 for ; Wed, 20 May 2009 15:17:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1AFFB3A68B3 for ; Wed, 20 May 2009 15:17:49 -0700 (PDT) X-AuditID: c1b4fb3c-b7b87ae000000ec5-a7-4a1481ed6305 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id FF.A9.03781.DE1841A4; Thu, 21 May 2009 00:19:25 +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, 21 May 2009 00:19:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 May 2009 00:19:24 +0200 Message-ID: In-Reply-To: <4A141958.3010308@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] What ACM is all about [was: RE: MSRP-ACM compatibility] Thread-Index: AcnZZ7U5n0ha87tWRlCtE+pr60PhJQALvaYg References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <4A141958.3010308@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "Ben Campbell" X-OriginalArrivalTime: 20 May 2009 22:19:24.0996 (UTC) FILETIME=[0857B840:01C9D999] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] What ACM is all about [was: RE: 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, 20 May 2009 22:17:51 -0000 Hi,=20 >If we are going to change MSRP to enable SBCs or any other sort of=20 >middlebox, I'd really like to see more documentation on how that=20 >middlebox is expected to behave in context, and how the whole=20 >architecture works when said middlebox is present. I'm not necessarily=20 >talking about normative specification.This is the point I was trying=20 >to get across in previous reviews when I suggested we needed some use=20 >case analysis and possibly call flows to describe the requirements=20 >that section 4.2 sets out to solve. > >We spun up a whole working group (BEHAVE) to do this for NATs, and=20 >subsequently learned that many of or generally held assumptions were=20 >wrong. > >I agree wholeheartedly with Ben's sentiment regarding the assumptions we're making about SBC behavior, and I think the comparison to NATs is quite appropriate. Saying that SBCs operate "by modifying the=20 >SDP"[1] is as useful as saying that NATs operate "by changing IP addresses." You can make certain assumptions about what these changes look like, but they're just assumptions. And right now, they're not=20 >even documented assumptions. ACM is not standardized yet, so we don't need to make any assumptions regarding how existing intermediates modify the path attribute etc. If they DO modify the path attribute, legacy MSRP won't work, and it doesn't matter what we do. What we need to do is to describe how ACM routing etc work. People will then have to make sure that intermediates who are supposed to support ACM will act according to that - as for any other meida (we haven't specified how intermediates shall modify the c-line for audio etc). >We've been down this road before. For example, we spent a lot of work to develop a protocol to characterize NATs based on untested assumptions about NAT behavior. Unlike NAT behavior, there is no existing ACM behavior, so we don't need to make assumptions on how intermediates work regarding ACM. Personally I also think that the NAT behavior issue is far more complicated than intermediate behavior for MSRP ACM. Having said that, I have no problem to document how an intermediate which is to support ACM is expected to behave when it comes to modifying the SDP etc, if we think that is useful. But, we don't need to make assumptions about existing ACM support in intermediates. Regards, Christer >It was only after we actually spun up BEHAVE and did the work documented in draft-jennings-behave-test-results that we realized we had wasted vast man-years of engineering resources for naught. RFC 3489=20 >stands as a tombstone to our hubris and carelessness. > >I am certain that we have relevant lessons to learn from BEHAVE, and that many of them fall in the category of "trying to engineer protocols around an undefined entity is folly." From christer.holmberg@ericsson.com Wed May 20 15:27: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 04EDC3A6C0E for ; Wed, 20 May 2009 15:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=0.072, 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 YpgZe-CfyYnc for ; Wed, 20 May 2009 15:27:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8FAC33A68E3 for ; Wed, 20 May 2009 15:27:28 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-0e-4a148430e1cb Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1F.87.02630.034841A4; Thu, 21 May 2009 00:29: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, 21 May 2009 00:29: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, 21 May 2009 00:29:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP-ACM vs existing SBCs (was Re: [Simple] What ACM is all about [was: RE: MSRP-ACM compatibility) Thread-Index: AcnZaIn09kIYOQxWRLKWhQK6yF1jygAKZRPg References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com><66cd252f0904281601q18402163p1e715d709b92f22b@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <76B44E1B-FF23-41A8-B35D-2F5C49BF6ED8@nostrum.com> <4A141AFD .7030109@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" , "Adam Roach" X-OriginalArrivalTime: 20 May 2009 22:29:04.0349 (UTC) FILETIME=[61A9F8D0:01C9D99A] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] MSRP-ACM vs existing SBCs (was Re: What ACM is all about [was: RE: 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, 20 May 2009 22:27:30 -0000 Hi,=20 >I think we have a disconnect here. One of the key arguments, as far as=20 >I understand it, for making the changes proposed in MSRP-ACM has to do=20 >with working through existing SBCs. > >Because, let's face it, if SBCs need to go mucking with more than just=20 >the c=3D and m=3D lines, then they may as well understand the MSRP-=20 >specific syntax anyway. If this is true, then backwards compatibility=20 >with deployed SBCs is not a design consideration. > >And here we have Christer saying that the intermediary would need to=20 >modify the a=3D lines in a MSRP-specific way. > >If that's the case, why are we chasing a requirement to relax the URI matching rules? Below Ben indicates why it was proposed to change that - and I also think also You asked why we couldn't use the path attribute instead. But, the question is not whether an intermediate CAN understand the MSRP specific syntax - the question is the COST the intermediate having to modify every MSRP message. Most sessions contain only a single offer/answer exchange, but most MSRP sessions are probably going to contain more than a single MSRP message exchange. >< history review> > >Christer's original proposal was to have MSRP-ACM compliant devices use the c-line addressing rather than the "a=3Dpath" line, in order to be = more friendly to existing SBCs. This would not work with MSRP=20 >relays, except in a pure "fall back to 4975 behavior model". The working group stated a requirement to support the scenario where an endpoint is behind an SBC, and it's peer is behind a relay. > >The a=3Dpath modification, and the relaxation of URI rules were an attempt to make ACM work with relays. We've since run into TLS cert matching complications with that approach. Correct (we are discussing a solution proposal for that, though). And, as we have been discussing, there may be some cert issues related to the comedia part, if there are relay cases where the fingerprint attribute must be included. > >But to Adam's point, I think we've got some conflicting requirements. =20 >The requirement to interoperate between existing unmodified SBCs (without behavior modification) and RFC4976 relays cannot be achieved. > >The path attribute discussion contains an implicit assumption that we can modify SBCs a little (e.g. MSRP specific treatment of SDP), but not a lot (e.g. making them process the to-path and from-path=20 >header fields in MSRP SEND requests.) That is an assumption worth explicit discussion. Instead of "modify SBCs" I guess we should say "add MSRP specific treatment of SDP to SBCs". MSRP ACM is currently not standardized, so there is nothing existing MSRP ACM related which needs to be modified :) Regards, Christer From adam@nostrum.com Wed May 20 15:43: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 A4C993A6C6C for ; Wed, 20 May 2009 15:43:56 -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.032, 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 BBO5JqTD+zpf for ; Wed, 20 May 2009 15:43: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 7F8213A696F for ; Wed, 20 May 2009 15:43:55 -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 n4KMjSLq099165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2009 17:45:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A148808.9000709@nostrum.com> Date: Wed, 20 May 2009 17:45:28 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <76B44E1B-FF23-41A8-B35D-2F5C49BF6ED8@nostrum.com> <4A141AFD .7030109@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 vs existing SBCs (was Re: What ACM is all about [was: RE: 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, 20 May 2009 22:43:56 -0000 Christer Holmberg wrote: > Instead of "modify SBCs" I guess we should say "add MSRP specific > treatment of SDP to SBCs". No, I don't think that's completely correct. The TLS-related issues may well force SBCs to handle the media differently than they handle other kinds of connections. I don't think it's reasonable to restrict the solution space to "only those things that can be achieved through SDP handling alone." /a From christer.holmberg@ericsson.com Thu May 21 02:36: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 295613A6F6E for ; Thu, 21 May 2009 02:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.372, 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 ajZJYa4HP84o for ; Thu, 21 May 2009 02:36:17 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CE3393A6F6B for ; Thu, 21 May 2009 02:36:09 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-1f-4a1520e9c2be Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 4D.9C.02630.9E0251A4; Thu, 21 May 2009 11:37: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); Thu, 21 May 2009 11:37: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: Thu, 21 May 2009 11:37:42 +0200 Message-ID: In-Reply-To: <4A148808.9000709@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP-ACM vs existing SBCs (was Re: [Simple] What ACM is all about [was: RE: MSRP-ACM compatibility) Thread-Index: AcnZneY+CoOnqdkrSRuEqXERwEqpwwAV9WHQ References: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> <49503123-011D-4825-8B2B-7F11A86C550A@nostrum.com> <949A60EB-D082-4DED-AE6C-0FFC515574BC@nostrum.com> <70DC2003-9C4D-46A7-A06C-07F296DAB000@nostrum.com> <5BBE0395-8FF3-4D1D-B360-467979A811E1@nostrum.com> <76B44E1B-FF23-41A8-B35D-2F5C49BF6ED8@nostrum.com> <4A141AFD .7030109@nostrum.com> <4A148808.9000709@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 21 May 2009 09:37:43.0589 (UTC) FILETIME=[CA982D50:01C9D9F7] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] MSRP-ACM vs existing SBCs (was Re: What ACM is all about [was: RE: 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, 21 May 2009 09:36:24 -0000 Hi,=20 >>Instead of "modify SBCs" I guess we should say "add MSRP specific treatment of SDP to SBCs". > >No, I don't think that's completely correct. > >The TLS-related issues may well force SBCs to handle the media differently than they handle other kinds of connections. I don't think it's reasonable to restrict the solution space to "only those things=20 >that can be achieved through SDP handling alone." It is true that there are TLS related issues, but they may not be specific to the ACM path modification part. We seem to have TLS issues also for the pure comedia part. Also, I am not sure they are even specific to MSRP. A user using TLS, no matter for what media or signalling, must always have the correct information regarding which certificate to use. But, for ACM, as we have discussed, it is rather clear what the SBC could do in order to make it work. It needs to make sure the user has the correct certification information, both when the SBC terminates TLS and when it treats TLS transparently. I proposed some generic MSRP text about that, so SBCs which are to support MSRP TLS would simply have to follow that also. Otherwise things simply wouldn't work.=20 Regards, Christer From ben@nostrum.com Fri May 22 11:22: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 7091B3A6C46 for ; Fri, 22 May 2009 11:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.244, 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 K0SZWJvLuAHP for ; Fri, 22 May 2009 11:22: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 3B60D3A6BBA for ; Fri, 22 May 2009 11:22:30 -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 n4MIO6Mr012778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 22 May 2009 13:24:07 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <1F4DAC47-E3C4-4944-8A38-A7326DC0E35F@nostrum.com> 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 v935.3) Date: Fri, 22 May 2009 13:24:07 -0500 References: <2D153199-502F-4996-92C5-ED282ABF6F5E@cisco.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] Fwd: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP 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, 22 May 2009 18:22:31 -0000 (As Chair) Please see Cullen's comments below. The draft is in IETF last call, so this is your (last) chance to comment. Thanks! Ben. Begin forwarded message: > From: Cullen Jennings > Date: May 22, 2009 10:52:38 AM CDT > To: Working Group Chairs > Subject: Fwd: Last Call: draft-ietf-opsawg-operations-and-management > (Guidelines for Considering Operations and Management of New > Protocols and Protocol Extensions) to BCP > > > Hi All, > > I'm not sure many people are aware of this BCP for adding a new > Manageability Considerations Sections to drafts but I suspect it > will impact nearly all of our new protocol work so you might want to > make folks in your WG aware of it. It has some good pointers about > things to think about. It's in LC so now would be a good time for > people to read it. > > Cullen > > > > Begin forwarded message: > >> From: The IESG >> Date: May 19, 2009 7:39:36 AM MDT (CA) >> To: IETF-Announce >> Cc: opsawg@ietf.org >> Subject: Last Call: draft-ietf-opsawg-operations-and-management >> (Guidelines for Considering Operations and Management of New >> Protocols and Protocol Extensions) to BCP >> Reply-To: ietf@ietf.org >> >> The IESG has received a request from the Operations and Management >> Area >> Working Group WG (opsawg) to consider the following document: >> >> - 'Guidelines for Considering Operations and Management of New >> Protocols >> and Protocol Extensions ' >> as a BCP >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to >> the >> ietf@ietf.org mailing lists by 2009-06-02. Exceptionally, >> comments may be sent to iesg@ietf.org instead. In either case, please >> retain the beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-opsawg-operations-and-management-07.txt >> >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16452&rfc_flag=0 >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > From christer.holmberg@ericsson.com Wed May 27 05:47: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 899953A70C1 for ; Wed, 27 May 2009 05:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.367, 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 KcBQekH6N9aq for ; Wed, 27 May 2009 05:47:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 66F723A6A98 for ; Wed, 27 May 2009 05:47:08 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-e0-4a1d363f4d9b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 66.F7.30868.F363D1A4; Wed, 27 May 2009 14:46:55 +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, 27 May 2009 14:46:55 +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, 27 May 2009 14:46:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP URI fingerprint parameter syntax Thread-Index: AcneyTbxv2SQujIRS0+ima9xriC3Gg== From: "Christer Holmberg" To: "Simple WG" X-OriginalArrivalTime: 27 May 2009 12:46:55.0584 (UTC) FILETIME=[3763A600:01C9DEC9] X-Brightmail-Tracker: AAAAAA== Subject: [Simple] MSRP URI fingerprint parameter syntax 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, 27 May 2009 12:47:29 -0000 Hi, IF we would extend the MSRP URI, in order to allow the transport of the fingerprint value, below is some thinking about the syntax. Note, that currently the proposal is not to replace the fingerprint attribute with this parameter in the SDP. The idea is to be able to provide the fingerprint to MSRP relays by using the parameter in the MSRP AUTH message. *ABNF in RFC4975* =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MSRP-URI =3D msrp-scheme "://" authority ["/" session-id] ";" transport *( ";" URI-parameter) ;authority as defined in RFC3986=20 msrp-scheme =3D "msrp" / "msrps" session-id =3D 1*( unreserved / "+" / "=3D" / "/" ) ;unreserved as defined in RFC3986=20 transport =3D "tcp" / 1*ALPHANUM=20 URI-parameter =3D token ["=3D" token]=20 token =3D 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) *New ABNF for fingerprint uri parameter (based on ABNF in RFC 4572)* =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The easiest way would of course be to re-use the attribute syntax: URI-parameter =3D fingerprint fingerprint =3D "fingerprint" ":" hash-func SP fingerprint hash-func =3D "sha-1" / "sha-224" / "sha-256" / "sha-384" / "sha-512" / "md5" / "md2" / token ;Additional hash functions can only come from updates to RFC 3279 fingerprint =3D 2UHEX *(":" 2UHEX) ;Each byte in upper-case hex, separated by colons. UHEX =3D DIGIT / %x41-46 ;A-F uppercase However, token does now allow the usage of ":" and SP, so it doesn't work. So, another proposal, which is also more parameter-type, would be to either use *two different uri parameters*: URI-parameter =3D fingerprint-hash / fingerprint-value fingerprint-hash =3D "sha-1" / "sha-224" / "sha-256" / "sha-384" / "sha-512" / "md5" / "md2" / token ;Additional hash functions can only come from updates to RFC 3279 Fingerprint-value =3D 2UHEX *(":" 2UHEX) ;Each byte in upper-case hex, separated by colons. UHEX =3D DIGIT / %x41-46 ;A-F uppercase Regards, Christer From pankaj.munjal@gmail.com Sun May 31 21:52: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 E554B3A690B for ; Sun, 31 May 2009 21:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_34=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 Mrei1BxhIFV5 for ; Sun, 31 May 2009 21:52:47 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 14DCA3A68AD for ; Sun, 31 May 2009 21:52:47 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so7383571yxb.49 for ; Sun, 31 May 2009 21:52:45 -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=IX9xN6Pk+Fds97AUBQ7AB5qAF+3fGUrZWeSm5mfuJ+E=; b=YTkj9Eac12C08827oLGmNx0I9KSYhdL7OE+lhrI1Pbe2+cEnDCBw9kLWibl/hbPU5S E/NkUd5f3JJNeMa32bZESdEBtyZiG5a5M3ajlv3JAE6gUzmgFjiTaBIAcxfTlROpg9A6 kA50X0C9/vdp5vTDirLWoCpUytha+/ri4vjkY= 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=YK5O6Mn6346JuPO2Dz/Jz+tNS7ni8G4WFhcImYy4lMd5dm+lR4sZuOiq8FFS7gLUP1 ZLgocR2/l/v2FMmjKDc+apndDmggRN62SFXY0tNAkUMULBqhK2BQQrJsQTx2Ah8jXKb/ ZvYV9OPld9gG6RBWurrIIbyCNzebTRp7jPtnc= MIME-Version: 1.0 Received: by 10.100.139.6 with SMTP id m6mr6466891and.81.1243831965019; Sun, 31 May 2009 21:52:45 -0700 (PDT) In-Reply-To: <4C607BEA097DF048BEA625B974A36618A6324F@306900ANEX2.global.avaya.com> References: <4C607BEA097DF048BEA625B974A36618A6324F@306900ANEX2.global.avaya.com> Date: Mon, 1 Jun 2009 10:22:44 +0530 Message-ID: From: Pankaj Munjal To: "Smyth, Colm (Colm)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: simple Subject: Re: [Simple] Partial Publication of elements with more than oneinstance possible 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, 01 Jun 2009 04:52:48 -0000 Hello Colm, Thanks for the clarification. For and xml:lang can be used. But how about element? According to RFC 4481, Section 3: "More than one such element MAY appear within a PIDF element." In this case, what shall be the unique identifier for any instance of "timed-status"? Regards, Pankaj On 3/12/09, Smyth, Colm (Colm) wrote: > Hi Panjaj, > > Each instance of and is distinguished by a locale > (xml:lang). > > All the best, > Colm Smyth > Lead/Architect - Avaya Communication Manager Presence Server | > Unified Communications > AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843) > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Pankaj Munjal > Sent: 12 March 2009 06:15 > To: simple > Subject: [Simple] Partial Publication of elements with more than > oneinstance possible > > Hello all, > > According to the Presence RFCs, there can be a few elements like , > - that can have multiple entries. > However, they don't have ids associated with them to identify the > instances. > > If my client is using partial publish to change values of one of such > instances, then which instance shall be updated on the Server? > (Assuming that my initial PUBLISH had more than one instance for such > field) > > Is this scenario documented in some RFC/draft? > > Kindly suggest! > > Regards, > Pankaj > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > -- All the desirable things in life are either illegal, expensive, fattening, or married to someone else!!