From ben@estacado.net Thu Sep 1 15:43:27 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E545021F9777 for ; Thu, 1 Sep 2011 15:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NivhsJ0jKMM4 for ; Thu, 1 Sep 2011 15:43:27 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDFE21F9764 for ; Thu, 1 Sep 2011 15:43:26 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p81MilsZ031514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Sep 2011 17:44:54 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <1E36555C-B8C6-4795-8827-36EF88F09DC2@nostrum.com> Date: Thu, 1 Sep 2011 17:44:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <83A1F8C7-45A3-4E20-A283-2CEB0A6196B7@estacado.net> References: <1E36555C-B8C6-4795-8827-36EF88F09DC2@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1244.3) Cc: Simple WG Subject: Re: [Simple] Chair note on CEMA TLS discussion thread X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 22:43:28 -0000 (as chair) Given that the 01 version of the draft dropped the MUST use TLS = provision, and that, if I count correctly, the majority of commenters = were not in favor of that provision, I don't see a reason for a formal = consensus call on the subject. Please contact the chairs ASAP if you = feel otherwise. Since the new version came out 3 days ago, I plan to give people another = few days to digest it, then issue a WGLC if that still seems = appropriate. I invite people to read that version carefully, and by no = means wait for a formal WGLC to comment. Thanks! Ben. On Aug 26, 2011, at 9:36 AM, Ben Campbell wrote: > (as chair) >=20 > The recent TLS thread on use of TLS in CEMA includes some posts = suggesting that CEMA is now more about security than about middleboxes. = Please keep in mind that we are not currently chartered to work on MSRP = security improvements, however desirably they might be. That doesn't = mean that the CEMA work can't have side effects that improve security, = just that if that becomes an explicit goal of the work, we may need to = take another look at where the work occurs. That doesn't mean such work = absolutely can't happen in SIMPLE, but it would require rechartering. = (Our charter is pretty explicit about new work.) >=20 > That being said, in my opinion, the question of whether CEMA has = evolved into a security draft of not depends a lot on the ongoing thread = about whether TLS should be MUST use vs MUST implement. Therefore, we = encourage that discussion to continue, and will likely make a consensus = call on the subject once people have had a few days to read the latest = draft version (published this morning as = draft-ietf-simple-msrp-cema-00). >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Thu Sep 1 16:17:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B36021F9531 for ; Thu, 1 Sep 2011 16:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SerCbJptsZYF for ; Thu, 1 Sep 2011 16:17:00 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AB74521F94F9 for ; Thu, 1 Sep 2011 16:16:49 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p81NIG4J050648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Sep 2011 18:18:18 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Sep 2011 18:18:25 -0500 Message-Id: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> To: Simple WG , draft-ietf-simple-msrp-cema.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Subject: [Simple] Comments on draft-ietf-simple-msrp-cema-01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 23:17:01 -0000 (As Individual) Here are my detailed comments on draft-ietf-simple-msrp-cema-01: Substantive: -- section 1, 3rd paragraph:" In addition, the MSRP message needs to be = exposed in clear text to the MSRP B2BUA, which violates the end-to-end principle [RFC3724] ." While it would be nice to do better, I must point out that the clear = text requirement is no different than for SIP proxies. Content can still = be theoretically protected end to end via S/mime, etc. (not that anyone = does that.) -- section 2, definition of "middle box": " A SIP network device that = modifies SDP media address:port information in order to steer or anchor = media flows described in the SDP, including TCP and TLS connections used = for MSRP communication, through a media proxy function controlled by the = SIP endpoint. " Thats the usual definition of an SBC. Seems like we are using the term = middlebox only for SBCs. Maybe we should just call it an SBC? There are = many types of middleboxes for which CEMA will not apply. -- section 4.1, list of use cases where CEMA does not apply: These need elaboration. Why does CEMA not apply? Also, I would add = "middle box used to provide topology hiding on the media channel, = provide lawful intercept or other monitoring of content, or enforce = content-related policy". to the list. -- 4.2, 7th paragraph (numbered item "1") This needs elaboration to explain the c and a line difference is assumed = to indicate a middlebox. -- 4.2, paragraph 10: " The MSRP endpoint MAY choose to terminate the = session establishment if it can detect that a Middlebox acting as a MSRP B2BUA is not the desired remote endpoint." How can it detect that? -- 4.3, general (and 4.2 to some degree): With all these heuristics to work around situations where a peer does = not signal cema support, I'm not sure why we need the tag. Is it just to = signal the middlebox? -- 4.3, paragraph 5 (list item 4) What does scenario 4 indicate, assuming the middlebox would act as a = B2BUA if it didn't see the cema tag in the offer? -- 4.3, paragraph 9 (list item 3): "In addition, it MUST include an SDP = a=3Dsetup: passive attribute in the MSRP media description of the SDP answer." Is this true if the peer signals msrp-cema? -- 5.1: I still have a fundamental problem here. This entire work is predicated = on an assumption about SBC behavior. It's not standardized, and we can't = normatively require it. The best we can hope for is that all SBC = implementors read this spec and do the right thing. I think that, in practice, many will not, and even if they do, carriers = will implement policies to prevent interop with peers not implementing = CEMA. Basically, this assumption promotes walled gardens. -- 5.2 :" The Middlebox enables that functionality in cases where the remote endpoint does not support the CEMA extension." Really just the offerer, right? -- 5.3: It's worth pointing out that in the fairly common 2 SBC case, this may = mean a separate connection between them for each session. --5.5, paragraph 1: "Middleboxes relay MSRP media packets at the transport layer." That should be a top level assumption in itself. -- same paragraph: "The TLS handshake and resulting security association (SA) are established peer-to-peer between the MSRP endpoints."=20 s/are/"can be" -- 5.5, 2nd paragraph: "Middleboxes can inspect and modify the MSRP message content." Let's not imply that they can only inspect content when the UAs fall = back to 4975. They can act as B2buas whenever they like, and the = endpoints can't really tell when it is happening unless the signaling = channel is integrity protected. -- 6.1: "It does not however make it easier for a MiTM to monitor TLS protected MSRP" I think that needs elaboration. -- 6.2, 2nd paragraph: "If a Middlebox acts as a TLS B2BUA, MSRP = endpoints will be able to use fingerprint based authentication for TLS, no matter if they support the CEMA extension or not. " Isn't this also true for name-based authentication? -- 6.2, 2nd to last paragraph: "If something like SIPS protects the SIP = signaling" I suggest you describe the properties you have in mind explicitly, = rather than just comparing to SIPS -- 6.2, 1st paragraph: "However, while CEMA provides a prerequisite for end-to-end integrity," Only true if the endpoints can't talk p2p, or use some other thing like = SOCKS, TURN-TCP, etc. -- 6.2, paragraph 4: Do the relevant specs recommend using mutually authenticated TLS (or = DTLS or SRTP) between peers?=20 -- 6.2, last paragraph: "=85 validating that one or more SIP Proxies in = the proxy chain are not, in fact, malicious." What, no HMAC over the evil bit? :-) Editorial: -- section 1, 2nd paragraph: "=20 MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], cannot = anchor through Middleboxes. " How is an MSRP relay not a middle box? -- "=20 Middleboxes must read the message to change the routing information. " s/read/modify -- " Also the matching will fail if Middleboxes modify the address = information in the MSRP URI of the SDP a=3Dpath attribute. " Redundant sentence? -- 4.2, paragraph 5: " offered MSRP media if the port number of the = MSRP media description is not zero. " This seems to say that the offerer infers that the answerer supports = CEMA if the port in the answer is non-zero. Is that the intent? -- 4.2, paragraph 9: (note) Shouldn't this go in the assumptions section? -- 4.2, last paragraph: The overall structure of this section is confusing. It's not obvious = what the scope of "all other cases" really means. -- 5.5, 2nd paragraph: "TLS B2BUAs" Probably should add this to definitions -- 6.2, paragraph 8: "Unless the MSRP endpoints are able to use = name-based authentication, and they support a common authentication mechanism, they MUST use that mechanism." Confusing sentence -- 6.2, last paragraph: " establish an MSRP connection in the likely scenario of intercepted, altered," Incomplete sentence. Also, should explicitly say "unprotected MSRP" From christer.holmberg@ericsson.com Fri Sep 2 15:10:44 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079E621F8CBC for ; Fri, 2 Sep 2011 15:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naCnEVXf7bzl for ; Fri, 2 Sep 2011 15:10:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9427221F8CB0 for ; Fri, 2 Sep 2011 15:10:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-48-4e6154c1c0b2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 95.F6.20773.1C4516E4; Sat, 3 Sep 2011 00:12:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 3 Sep 2011 00:12:17 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG , "draft-ietf-simple-msrp-cema.all@tools.ietf.org" Date: Sat, 3 Sep 2011 00:12:15 +0200 Thread-Topic: Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments Thread-Index: Acxo/XXEBUyHDBDxR2Gncv6m6T8AMgAumVEA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233DD1251@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> In-Reply-To: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2011 22:10:44 -0000 Hi Ben,=20 In this reply I'll address your editorial comments, and your comment on the= Middlebox terminology. --------------- >-- section 2, definition of "middle box": " A SIP network=20 >device that modifies SDP media address:port information in=20 >order to steer or anchor media flows described in the SDP,=20 >including TCP and TLS connections used for MSRP=20 >communication, through a media proxy function controlled by=20 >the SIP endpoint. " >=20 >Thats the usual definition of an SBC. Seems like we are using=20 >the term middlebox only for SBCs. Maybe we should just call=20 >it an SBC? There are many types of middleboxes for which CEMA=20 >will not apply. First, it is not only SBCs. Application Servers can also be affected. Second, we had a loooong discussion about the terminology, and Middlebox wa= s a compromise that people could live with, so I really wouldn't like to ha= ve that discussion again.... It is true that there are many types of middleboxes for which CEMA will not= apply, and that is why we have text talking about what is the scope of a M= iddlebox in the draft. If you don't think that text is good enough, I'd rat= her try to improve it rather than changing the terminology. --------------- =20 =20 >-- section 1, 2nd paragraph: "=20 >MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976=20 >[RFC4976], cannot anchor through Middleboxes. " >=20 >How is an MSRP relay not a middle box? It is not a Middelbox as defined by the draft. --------------- >-- "=20 >Middleboxes must read the message to change the routing >information. >" >=20 >s/read/modify Ok. --------------- >-- " Also the matching will fail if Middleboxes modify the=20 >address information in the MSRP URI of the SDP a=3Dpath attribute. " >=20 >Redundant sentence? Yes. I'll remove it. --------------- =20 >-- 4.2, paragraph 5: " offered MSRP media if the port number=20 >of the MSRP media description is not zero. " >=20 >This seems to say that the offerer infers that the answerer=20 >supports CEMA if the port in the answer is non-zero. Is that=20 >the intent? No, it only indicates that the answerer accepts the MSRP media (with or wit= hout CEMA). If you want, I can add a note, saying: "NOTE: A zero port value is not an indication that the remote MSRP entity = does not support the CEMA extension." --------------- >-- 4.2, paragraph 9: (note) >=20 >Shouldn't this go in the assumptions section? I think it is good to have the note here, but I could modify the beginning,= so that is says: "NOTE: As described in section 5, in the absence of..." --------------- >-- 4.2, last paragraph: >=20 >The overall structure of this section is confusing. It's not=20 >obvious what the scope of "all other cases" really means. I suggest modifying the paragraph to: "In other cases, where none of the criteria above is met, and where the MS= RP endpoint becomes "active", it MUST use the SDP c/m-line for establishing the MSRP TCP connection. If th= e MSRP endpoint becomes "passive",=20 it will wait for the remote MSRP endpoint to establish the TCP conne= ction, according to the procedures in RFC 4975." --------------- >-- 5.5, 2nd paragraph: "TLS B2BUAs" >=20 >Probably should add this to definitions Will do. --------------- >-- 6.2, paragraph 8: "Unless the MSRP endpoints are able to=20 >use name-based authentication, and they support a common authentication me= chanism,=20 >they MUST use that mechanism." >=20 >Confusing sentence I am not sure what is confusing, but is the following more clear? "Unless the MSRP endpoints are able to use name-based authentication, but they support another common authentication mechanism, they MUST = use that authentication mechanism. --------------- >-- 6.2, last paragraph: " establish an MSRP connection >in the likely scenario of intercepted, altered," >=20 >Incomplete sentence. Also, should explicitly say "unprotected MSRP" I would suggest moving back to the -12 text, and add some explicit text: "NOTE: As defined in RFC 4975, if TLS authentication fails, the user need to be able to decide whether to try to anyway establish a connection with unprotected MSRP media." --------------- Regards, Christer From eburger@standardstrack.com Sun Sep 4 11:47:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACB921F86DD for ; Sun, 4 Sep 2011 11:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.331 X-Spam-Level: X-Spam-Status: No, score=-102.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucB4KCob8fqf for ; Sun, 4 Sep 2011 11:47:59 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 530FB21F86AF for ; Sun, 4 Sep 2011 11:47:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=jmU2qyTESjk/PX+JWrx9mXTmxR8Rjhz4Tq4tQIBztAtT3SLLEAG4b0RDKhm/73QD/kCas/aeHBe4uGhw+7eyU0KPNsiZn1ZnjzTlNKWiqPt+DhGP62xL3UvXPFJmJzye; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R0HlA-0002HA-2Y; Sun, 04 Sep 2011 11:49:36 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-3--299950116; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233DD1251@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 4 Sep 2011 14:49:42 -0400 Message-Id: <24A36843-8CB4-4F66-90BA-84235F73C748@standardstrack.com> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233DD1251@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg , Campbell Ben X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 04 Sep 2011 18:48:00 -0000 --Apple-Mail-3--299950116 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii How about: If TLS authentication fails, the user needs to decide whether to = establish a connection over an unprotected MSRP stream. At the very = least, there should be an indication to the user they are communicating = over an insecure session. On Sep 2, 2011, at 6:12 PM, Christer Holmberg wrote: >> -- 6.2, last paragraph: " establish an MSRP connection >> in the likely scenario of intercepted, altered," >>=20 >> Incomplete sentence. Also, should explicitly say "unprotected MSRP" >=20 > I would suggest moving back to the -12 text, and add some explicit = text: >=20 > "NOTE: As defined in RFC 4975, if TLS authentication fails, the = user > need to be able to decide whether to try to anyway establish a > connection with unprotected MSRP media." --Apple-Mail-3--299950116 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA5MDQxODQ5NDJaMCMGCSqGSIb3DQEJ BDEWBBSChXiJN+/5cU+i7z7hC9a6rq8EmTCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBADKqxAZqWxEVRNbujTD3/Oo++ChQ3epWFidcjZn+VyDXbRlw 30aTiIrmptJ2kFdit0qxaSb9QdZ2SX/En4v+KD8JWX/A/tccjJFRNjq+YNphZAShybdeyuyjd2Vm YVqC9ZUNuiPxmUfRKcYwXaU4YyCRGAfRqHKlGdkTj+0PwpwhEUvGQaW27iAefYypqRUCfQsN+7EP QrZku7Ur4weao8fTW7/O1Lp79XSaRZuhL5CPqzcLO7kleiqztB1CB58qcHWCYUCZLVxFZ7EdnXuC eUqvB5+yzeVYL/PanG5+83eg46ck/04/JCGhj/8hN6MiJhlHt6PS47/SHX2danGb6QYAAAAAAAA= --Apple-Mail-3--299950116-- From raphael.bossek@estos.de Tue Sep 6 06:49:05 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C278621F8804 for ; Tue, 6 Sep 2011 06:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=1.915, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGiSE6OL8h7i for ; Tue, 6 Sep 2011 06:49:05 -0700 (PDT) Received: from mail.estos.de (ns1.estos24.de [62.245.228.210]) by ietfa.amsl.com (Postfix) with ESMTP id 1862F21F87D9 for ; Tue, 6 Sep 2011 06:49:05 -0700 (PDT) Received: from hermelin.estos.de ([fe80::250:56ff:fe87:23]) by hermelin.estos.de ([fe80::250:56ff:fe87:23%4]) with mapi; Tue, 6 Sep 2011 15:50:48 +0200 From: Raphael Bossek To: "Simple@ietf.org" Date: Tue, 6 Sep 2011 15:50:49 +0200 Thread-Topic: Missing support for RFC 5688 app-subtype in RFC 5196 Thread-Index: Acxsm3vOBZX0bPwdQs2KgWQmEwjREQ== Message-ID: <9B7CB52192C7EA4C931088F28A51177C011DAE3C4D98@hermelin.estos.de> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE x-pp-processed: __PP2__3d782474-723b-4e9b-a051-a45da57f7129 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Simple] Missing support for RFC 5688 app-subtype in RFC 5196 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2011 13:49:05 -0000 Dear Simple list, I'm studding the -- RFC 3840: Indicating User Agent Capabilities in SIP ---- Introduces lot of new "media feature tags" using RFC2506: Media Featur= e Tag Registration Procedure -- RFC 4569: IANA Registration of the Message Media Feature Tag ---- Introduces the "message" (sip.message) "media feature tags" using RFC = 2506: Media Feature Tag Registration Procedure -- RFC 5196: SIP User Agent Capability Extension to PIDF ---- It's a XML representation of RFC 3840 + RFC 4569 -- RFC 5688: SIP Media Feature Tag for 'Application' Media types ---- Introduces the "app-subtype" (sip.app-subtype) "media feature tags" us= ing RFC 2506: Media Feature Tag Registration Procedure My intention is to use the "app-subtype" media feature tag in RFC 5196 as X= ML tag but I could not find a RFC that allows that. Is a new RFC required that define the missing link between RFC 5196 and RFC= 5688? If so, where should I start? Greetings, Raphael Bossek From raphael.bossek@estos.de Tue Sep 6 06:49:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EDC21F87FA for ; Tue, 6 Sep 2011 06:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 tagged_above=-999 required=5 tests=[AWL=0.931, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1VDCGMLudun for ; Tue, 6 Sep 2011 06:49:56 -0700 (PDT) Received: from mail.estos.de (ns1.estos24.de [62.245.228.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5FA21F87D9 for ; Tue, 6 Sep 2011 06:49:55 -0700 (PDT) Received: from hermelin.estos.de ([fe80::250:56ff:fe87:23]) by hermelin.estos.de ([fe80::250:56ff:fe87:23%4]) with mapi; Tue, 6 Sep 2011 15:51:38 +0200 From: Raphael Bossek To: "Simple@ietf.org" Date: Tue, 6 Sep 2011 15:51:39 +0200 Thread-Topic: SIP SIMPLE: "do not disturb" interoperability Thread-Index: AcxsnBCcHZpNnm7vSp+7zR+Q95hisg== Message-ID: <9B7CB52192C7EA4C931088F28A51177C011DAE3C4D99@hermelin.estos.de> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE x-pp-processed: __PP2__3d782474-723b-4e9b-a051-a45da57f7129 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Simple] SIP SIMPLE: "do not disturb" interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2011 13:49:56 -0000 Dear IETF Simple list, Just one sentence about me and ESTOS GmbH (http://www.estos.com) , the comp= any I'm working for. I'm looking for a standard compliant solution for inst= ant messaging exchange the "do not disturb"/DND presence information betwee= n clients - if possible without introduction of new tags or values. ESTOS G= mbH is a software manufacturer for unified communication and collaboration = products and depends heavily on standards for interoperability with PBX and= phone manufactures. I've studied the RFC 4479 (http://tools.ietf.org/html/rfc4479#page-13 ) cha= pter "Reach Information" at page 13: "It is also possible for a presence do= cument to contain a service that has no reach information at all. In such = a case, the presentity is indicating that the service exists, but is electi= ng not to offer the watcher the opportunity to connect to it." The example from RFC 4480 (http://tools.ietf.org/html/rfc4480#page-19 ) cha= pter "Example" at page 13 describe a "do not disturb" case: "im:someone@mobile.example.net" As conclusion we could say that "do not disturb" is set if * Contact address for a is missing (refer to RFC 4479) or * The priority for the contact address within a service is less than 1.0 (r= efer to RFC 4480) What do you thing about this interpretation? I would like to fixating that officially but I'm not confirm with the IEFT = process. Should this discussion be continued at https://lists.cs.columbia.e= du/pipermail/sip-implementors/2008-April/018968.html ? At the end I would like to make a publication at http://stackoverflow.com/q= uestions/6057830/sip-simple-pidf-convention-for-do-not-disturb-dnd-presence= -extension and some open source projects about the way to do. I have also c= ontact to SEN OpenStage phone people. Maybe they will join this discussion. Greetings, Raphael Bossek From christer.holmberg@ericsson.com Wed Sep 7 04:39:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE36221F8BCB for ; Wed, 7 Sep 2011 04:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXWgRl7KsIhk for ; Wed, 7 Sep 2011 04:39:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4D83C21F85C4 for ; Wed, 7 Sep 2011 04:39:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-39-4e675854bc88 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6E.D1.20773.458576E4; Wed, 7 Sep 2011 13:41:08 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 7 Sep 2011 13:41:08 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG , "draft-ietf-simple-msrp-cema.all@tools.ietf.org" Date: Wed, 7 Sep 2011 13:41:07 +0200 Thread-Topic: Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments Thread-Index: Acxo/XXEBUyHDBDxR2Gncv6m6T8AMgES3SCw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> In-Reply-To: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2011 11:39:22 -0000 Hi Ben, Some of your comments are related to the new security text provided by Eric= , so I will indicate where I expect him to comment. --------------- > -- section 1, 3rd paragraph:" In addition, the MSRP message needs to=20 > be exposed in clear text to the MSRP B2BUA, which violates > the end-to-end principle [RFC3724] ." >=20 > While it would be nice to do better, I must point out that the clear=20 > text requirement is no different than for SIP proxies. Content can=20 > still be theoretically protected end to end via S/mime, etc. (not that=20 > anyone does that.) I'll let Eric reply to this first. --------------- =20 > -- section 4.1, list of use cases where CEMA does not apply: >=20 > These need elaboration. Why does CEMA not apply? Also, I would add=20 > "middle box used to provide topology hiding on the media channel,=20 > provide lawful intercept or other monitoring of content, or enforce=20 > content-related policy". to the list. Yes, my intention was to provide more elaboration, but forgot due to the mi= ssunderstandings associated with the submitting of the -00 version. So, the text would say something like: "- A non-CEMA-enabled MSRP endpoint becomes "active", as the endpoint wi= ll always establish the TCP or TLS connection using the SDP a=3Dpath attrib= ute, which contains the address the remote MSRP endpoing, instead of the SD= P c/m-line which contains the address information of the Middlebox." ...and similar for the other cases. --------------- > -- 4.2, 7th paragraph (numbered item "1") >=20 > This needs elaboration to explain the c and a line difference is=20 > assumed to indicate a middlebox. Yes. --------------- > -- 4.2, paragraph 10: " The MSRP endpoint MAY choose to terminate the=20 >session establishment if it can detect that a Middlebox acting as a=20 >MSRP B2BUA is not the desired remote endpoint." >=20 > How can it detect that? I'll let Eric reply to this first. (Personally I am not sure how the endpoint would be able to detect). --------------- > -- 4.3, general (and 4.2 to some degree): >=20 > With all these heuristics to work around situations where a peer does=20 > not signal cema support, I'm not sure why we need the tag. Is it just=20 > to signal the middlebox? No, there are enpoint procedures which depend on the presence of the tag. F= or example, when the offerer receives an answer, it uses the tag in the pro= cedure to determine whether a fallback to 4975 behavior is needed. --------------- =20 > -- 4.3, paragraph 5 (list item 4) >=20 > What does scenario 4 indicate, assuming the middlebox would act as a=20 > B2BUA if it didn't see the cema tag in the offer? This is actually an error case, where the Middlebox has modified the c/m-li= ne even if the a=3Dmsrp-cema attribute wasn't present in the SDP offer, and= there is really nothing the answerer can do to fix that.=20 (Note that this error case is not CEMA specific) So, my suggestion would be to instead send a 488 (Not Acceptable Here) erro= r response in this case. --------------- > -- 4.3, paragraph 9 (list item 3): "In addition, it MUST include an=20 >SDP a=3Dsetup: passive attribute in the MSRP media description of the SDP= =20 >answer." >=20 > Is this true if the peer signals msrp-cema? Yes. --------------- =20 > -- 5.1: >=20 > I still have a fundamental problem here. This entire work is=20 > predicated on an assumption about SBC behavior. It's not standardized,=20 > and we can't normatively require it. The best we can hope for is that=20 > all SBC implementors read this spec and do the right thing. >=20 > I think that, in practice, many will not, and even if they do,=20 > carriers will implement policies to prevent interop with peers not=20 > implementing CEMA. Basically, this assumption promotes walled gardens. First, if carriers will prevent interop with peers not implementing CEMA (w= e can of course not prevent that), it is very likely that they already toda= y prevent MSRP traffic. Second, at least I am aware of customer requirements of interop with non-CE= MA peers, and products that support it. --------------- > -- 5.2 :" The Middlebox enables that functionality in cases > where the remote endpoint does not support the CEMA extension." >=20 > Really just the offerer, right? Yes. --------------- > -- 5.3: >=20 > It's worth pointing out that in the fairly common 2 SBC case, this may=20 > mean a separate connection between them for each session. I suggest the following text: "Instead, in order to associate an MSRP message with a specific session, t= he=20 Middlebox often assigns a unique local address:port combination for each M= SRP session. Due to this, between two Middleboxes there might be a separate connection = for each MSRP session." --------------- > --5.5, paragraph 1: "Middleboxes relay MSRP media packets > at the transport layer." >=20 > That should be a top level assumption in itself. Do you mean the text belongs somewhere else? =20 > -- same paragraph: "The TLS handshake and resulting security > association (SA) are established peer-to-peer between the MSRP > endpoints."=20 >=20 > s/are/"can be" Ok. --------------- =20 > -- 5.5, 2nd paragraph: "Middleboxes can inspect > and modify the MSRP message content." >=20 > Let's not imply that they can only inspect content when the UAs fall=20 > back to 4975. They can act as B2buas whenever they like, and the=20 > endpoints can't really tell when it is happening unless the signaling=20 > channel is integrity protected. I suggest the following text: "The Middlebox decrypts MSRP media packets received from one MSRP endpoint= , and=20 then re-encrypts them before sending them toward the other MSRP endpoint.= =20 Middleboxes can inspect and modify the MSRP message content. As CEMA does= not require a Middlebox to modify the MSRP content, this can be prevented if T= LS is=20 used for the MSRP communication, assuming that the SIP signalling channel = is=20 integrity protected." --------------- > -- 6.1: "It does not however make it easier for a MiTM to > monitor TLS protected MSRP" >=20 > I think that needs elaboration. The end of the setence does say: ", since that would require the MiTM to implement MSRP B2BUA functionality= , no=20 matter if UAs support the CEMA extension or not." --------------- > -- 6.2, 2nd paragraph: "If a Middlebox acts as a TLS B2BUA, MSRP=20 >endpoints will be able to use fingerprint based authentication for TLS,=20 >no matter if they support the CEMA extension or not. " >=20 >Isn't this also true for name-based authentication? Yes, but the specific text focuses on fingerprint. But, I can modify the text to also mention name-based: "If a Middlebox acts as a TLS B2BUA, MSRP endpoints will be able to use fingerprint based authentication and name-based authentication for= =20 TLS, no matter if they support the CEMA extension or not. In such cases,=20 as the Middlebox acts as TLS endpoints, MSRP endpoints might be given an=20 incorrect impression that there is an end-to-end security association (SA) between the MSRP endpoints." --------------- =20 > -- 6.2, 2nd to last paragraph: "If something like SIPS protects the=20 > SIP signaling" >=20 > I suggest you describe the properties you have in mind explicitly,=20 > rather than just comparing to SIPS =20 I suggest to modify bullet 2, where SIPS is mentioned: "2. If SIP signalling to/from the endpoint is integrity protected, typical= ly through=20 use of IPsec or TLS transport, then an endpoint can depending on local pol= icy chose to trust the netwwork endpoints in the signalling path for SDP integ= rity and=20 accept fingerprint based TLS authentication without requiring end-to-end S= DP integrity." --------------- =20 > -- 6.2, 1st paragraph: "However, while CEMA provides a > prerequisite for end-to-end integrity," >=20 > Only true if the endpoints can't talk p2p, or use some other thing=20 > like SOCKS, TURN-TCP, etc. I'll let Eric reply to this first. --------------- > -- 6.2, paragraph 4: >=20 > Do the relevant specs recommend using mutually authenticated TLS (or=20 > DTLS or SRTP) between peers? I am not sure which specs you refer to. For SRTP end-to-end connections, 3GPP has specified the use of either SDES = or MIKEY-TICKET. The former can be allowed=20 by the network operator if the SIP signalling is protected, while the latte= r does not require such protection since=20 keys are sent encrypted and managed by an external key management service. = With SDES there is no authentication=20 performed - the IMS network is trusted - it is just the negotiation of cryp= to keys for the media connection that=20 SDES is used for. With MIKEY-TICKET, however, the SDP offerer also indirectly authenticates t= he remote SRTP connection endpoint. In neither case is there mutual authentication, since in IMS this is done d= uring user registration and then one normally=20 uses transport layer security associations in order not to have to re-authe= ntcate as long as these are ok.=20 --------------- =20 >-- 6.2, last paragraph: "... validating that one or more SIP Proxies in=20 >the proxy chain are not, in fact, malicious." >=20 > What, no HMAC over the evil bit? :-) I'll let Eric reply to this first. --------------- Regards, Christer From christer.holmberg@ericsson.com Wed Sep 7 04:54:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B53421F8B0B for ; Wed, 7 Sep 2011 04:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjEM+Ve6JabH for ; Wed, 7 Sep 2011 04:54:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 440F721F8A58 for ; Wed, 7 Sep 2011 04:54:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-ba-4e675bdb676b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EC.6D.02839.BDB576E4; Wed, 7 Sep 2011 13:56:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 7 Sep 2011 13:56:11 +0200 From: Christer Holmberg To: Simple WG , "draft-ietf-simple-msrp-cema.all@tools.ietf.org" Date: Wed, 7 Sep 2011 13:56:10 +0200 Thread-Topic: CEMA: A couple of additional changes Thread-Index: Acxo/XXEBUyHDBDxR2Gncv6m6T8AMgEVctkQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233E3ADED@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> In-Reply-To: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] CEMA: A couple of additional changes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2011 11:54:25 -0000 =20 Hi, When replying to Ben's comments, I find a couple of issues for which I woul= d like to suggest some changes. Section 4.2 ----------- Bullet 3 currently says: "3. If the MSRP endpoint is using a relay for MSRP communication, it MUST include the address information of the relay (the MSRP URI of the topmost SDP a=3Dpath attribute), rather than the address information of itself, in the SDP c/m-line associated with the MSRP media description. In addition, it MUST include an SDP a=3Dsetup: actpass attribute in the MSRP media description of the SDP offer." I suggest to remove the last sentence, about the a=3Dsetup attribute, and a= dd it to bullet 2. So, the new text would be: "2. The MSRP endpoint MUST include an SDP a=3Dsetup attribute in the SDP = offer. If the MSRP endpoint is using a relay for MSRP communication, it MUST set= the=20 value of a=3Dsetup to "actpass". If the MSRP endpoint is not using a rela= y for MSRP=20 communication, it MUST the value of a=3Dsetup in accordance with RFC6135 = [RFC6135]. 3. If the MSRP endpoint is using a relay for MSRP communication, it MUST = =20 include the address information of the relay (the MSRP URI of the topmost= SDP a=3Dpath=20 attribute) in the c/m-line associated with the MSRP media description." Section 6.2 ----------- Bullet 2 on TLS-PSK suggests the usage of with MICKEY-TICKET. I think it would be good to make it a little more flexible, by not mandatin= g MICKET-TICKET, but simply mention it as an example. "2. TLS-PSK. For example, 3GPP has specified the use of SDES (when SIP tr= ansport is integrity protected) and MIKEY-TICKET for IMS." Regards, Christer= From raphael.bossek@estos.de Wed Sep 7 06:06:52 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB45221F8B37 for ; Wed, 7 Sep 2011 06:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.73 X-Spam-Level: * X-Spam-Status: No, score=1.73 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_40=-0.185, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akejc67rYK5b for ; Wed, 7 Sep 2011 06:06:52 -0700 (PDT) Received: from mail.estos.de (mail.estos24.de [62.245.228.210]) by ietfa.amsl.com (Postfix) with ESMTP id 879F521F8B35 for ; Wed, 7 Sep 2011 06:06:51 -0700 (PDT) Received: from hermelin.estos.de ([fe80::250:56ff:fe87:23]) by hermelin.estos.de ([fe80::250:56ff:fe87:23%4]) with mapi; Wed, 7 Sep 2011 15:08:32 +0200 From: Raphael Bossek To: "Simple@ietf.org" Date: Wed, 7 Sep 2011 15:08:36 +0200 Thread-Topic: RFC 4480: Inconstency in XML schema registration Thread-Index: AcxtXjNWcQxqvkJ+RXCUuxAmnbPQ3Q== Message-ID: <9B7CB52192C7EA4C931088F28A51177C011DAE3C4F04@hermelin.estos.de> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE x-pp-processed: __PP2__3d782474-723b-4e9b-a051-a45da57f7129 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Simple] RFC 4480: Inconstency in XML schema registration X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2011 13:06:53 -0000 Dear SIMPLE list, reading RFC 4480 I've found a inconstancy in section 7.2. Schema Registrat= ion for Schema 'urn:ietf:params:xml:ns:pidf:status:rpid'. The name of the schema should be 'urn:ietf:params:xml:schema:pidf:status:rp= id' as defined by RFC 3688: The IETF XML Registry; Syntax for XML schema su= b-namespace is "urn:ietf:params:xml:schema:". The IANA maintained registry at http://www.iana.org/assignments/xml-registr= y/schema.html uses the 'urn:ietf:params:xml:schema:pidf:status:rpid' for RF= C 4480 either so did I missed an errata for RFC 4480? At the time of writing this there is only errata ID 1001 (http://www.rfc-ed= itor.org/errata_search.php?rfc=3D4480). Greetings, Raphael Bossek i.A. Raphael Bossek Software Architect ESTOS GmbH Petersbrunner Str. 3a 82319 Starnberg, Germany Phone: +49 (8151) 36856-153 Fax: +49 (8151) 36856-853 Mobile: +49 (151) 59177535 Email: raphael.bossek@estos.de Web: http://www.estos.de // Webinar: Facebook Killer Federation? 29. Sept 2011 um 10.00 Uhr. Jetzt anmelden! http://www.estos.de/partner/webinare/webinar-facebook-killer-federation.htm= l // W?hlen Sie ProCall! Sie finden ProCall ein tolles Produkt? Stimmen Sie jetzt bei der gro?en Funkschau-Leserwahl f?r ESTOS. Hier geht?s zum Voting... http://www.funkschau.de/specials/itk2011/fragebogen/ --- ESTOS GmbH Registered office: Starnberg, Germany Commercial registry Munich, HRB 133 670 Managing Directors: Dipl.-Phys. Stephan Eckbauer, Dipl.-Ing. Stefan Hobrats= chk, Ing. Christoph L?sch, Florian Bock From ben@nostrum.com Wed Sep 7 07:17:28 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198F821F8B32 for ; Wed, 7 Sep 2011 07:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2T4aIr7nxvK for ; Wed, 7 Sep 2011 07:17:27 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8808821F8B2C for ; Wed, 7 Sep 2011 07:17:27 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p87EJFce016127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 7 Sep 2011 09:19:16 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2011 09:19:23 -0500 Message-Id: <143C52F6-A9AA-46A2-B85F-B4F13DCC0E50@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Subject: [Simple] Taipei IETF Meeting X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2011 14:17:28 -0000 Hi, The IETF is in the process of planning work group meetings for IETF82 in = Taipei this November. The chairs are of the opinion that we do not need a formal SIMPLE = meeting this time around. The only significant work remaining is the = CEMA draft, and we believe that work can progress without a formal face = to face meeting. Does anyone feel differently? If so, please let us know as soon as = possible. The cutoff for us to request a meeting if we need one is = September 26, but if we know we are not going to meet, we should inform = the secretariat as soon as possible. Thanks! Ben.= From wwwrun@rfc-editor.org Wed Sep 7 11:29:51 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EAC21F8C5F for ; Wed, 7 Sep 2011 11:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TYw6Lapp+He for ; Wed, 7 Sep 2011 11:29:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BE5E821F8B27 for ; Wed, 7 Sep 2011 11:29:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2A54B98C25B; Wed, 7 Sep 2011 11:31:40 -0700 (PDT) To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20110907183140.2A54B98C25B@rfc-editor.org> Date: Wed, 7 Sep 2011 11:31:40 -0700 (PDT) X-Mailman-Approved-At: Wed, 07 Sep 2011 11:33:06 -0700 Cc: raphael.bossek@googlemail.com, simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] [Technical Errata Reported] RFC4480 (2959) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2011 18:29:51 -0000 The following errata report has been submitted for RFC4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=2959 -------------------------------------- Type: Technical Reported by: Raphael Bossek Section: 3.2. Original Text ------------- Activities such as , , , , , , , , , or can often be derived from calendar information. ----on the next page---- lunch: The person is eating his or her midday meal. Corrected Text -------------- Activities such as , , , , , , , , or can often be derived from calendar information. ----on the next page---- (delete this line) Notes ----- The activity is not allowed because not defined by the XML Schema in section in section 5.1. Because the XML Schema is immutable the documentation should be corrected. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4480 (draft-ietf-simple-rpid-10) -------------------------------------- Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Publication Date : July 2006 Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From christer.holmberg@ericsson.com Wed Sep 7 11:36:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6055F21F8A55 for ; Wed, 7 Sep 2011 11:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTGUrGwABK33 for ; Wed, 7 Sep 2011 11:36:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 943E021F88B7 for ; Wed, 7 Sep 2011 11:36:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-76-4e67ba2720d6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5D.6E.02839.72AB76E4; Wed, 7 Sep 2011 20:38:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 7 Sep 2011 20:38:31 +0200 From: Christer Holmberg To: 'Ben Campbell' , Simple WG Date: Wed, 7 Sep 2011 20:38:30 +0200 Thread-Topic: [Simple] Taipei IETF Meeting Thread-Index: AcxtaSMxz+OgNbf2TW6p6HOf1+1DPwAI+8bg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45F92@ESESSCMS0356.eemea.ericsson.se> References: <143C52F6-A9AA-46A2-B85F-B4F13DCC0E50@nostrum.com> In-Reply-To: <143C52F6-A9AA-46A2-B85F-B4F13DCC0E50@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] Taipei IETF Meeting X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2011 18:36:43 -0000 Hi,=20 >The IETF is in the process of planning work group meetings for IETF82 in T= aipei this November. > >The chairs are of the opinion that we do not need a formal SIMPLE meeting = this time around. The only significant work remaining is the CEMA draft, an= d we believe that work can progress without a formal face to face meeting. And, that is based on the assumption that we will NOT mandate the usage of = TLS - which is also reflected in the -01 version. If someone still thinks that usage of TLS shall be mandated, please speak u= p now :) Regards, Christer From wwwrun@rfc-editor.org Thu Sep 8 00:28:48 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD93E21F8B70 for ; Thu, 8 Sep 2011 00:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwgwj0Cim7QG for ; Thu, 8 Sep 2011 00:28:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1B90321F8B6E for ; Thu, 8 Sep 2011 00:28:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B0FB398C261; Thu, 8 Sep 2011 00:30:39 -0700 (PDT) To: jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20110908073039.B0FB398C261@rfc-editor.org> Date: Thu, 8 Sep 2011 00:30:39 -0700 (PDT) Cc: raphael.bossek@googlemail.com, simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] [Technical Errata Reported] RFC4479 (2963) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 07:28:48 -0000 The following errata report has been submitted for RFC4479, "A Data Model for Presence". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4479&eid=2963 -------------------------------------- Type: Technical Reported by: Raphael Bossek Section: 7.1. Original Text ------------- mac:8asd7d7d70 ... mac:8asd7d7d70 Corrected Text -------------- Replace both with urn:uuid:698137d0-b395-11e0-aff2-0800200c9a66 Notes ----- As mentioned in Errata ID 2131 and 2962 a valid URN as defined in RFC3406: Uniform Resource Names (URN) Namespace Definition Mechanisms should be used for . This is not the case for this example. RFC 4479 in section 3.4. Device RECOMMENDS version 1 UUIDs for the element: "For devices with a MAC address, version 1 UUIDs are RECOMMENDED, as they result in a time-based identifier that makes use of the MAC address." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4479 (draft-ietf-simple-presence-data-model-07) -------------------------------------- Title : A Data Model for Presence Publication Date : July 2006 Author(s) : J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Sep 7 11:42:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8E521F8C79 for ; Wed, 7 Sep 2011 11:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQOebm+JLu81 for ; Wed, 7 Sep 2011 11:42:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9F021F8C63 for ; Wed, 7 Sep 2011 11:42:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4A51098C25C; Wed, 7 Sep 2011 11:44:11 -0700 (PDT) To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20110907184411.4A51098C25C@rfc-editor.org> Date: Wed, 7 Sep 2011 11:44:11 -0700 (PDT) X-Mailman-Approved-At: Thu, 08 Sep 2011 06:38:40 -0700 Cc: raphael.bossek@googlemail.com, simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] [Technical Errata Reported] RFC4480 (2960) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2011 18:42:22 -0000 The following errata report has been submitted for RFC4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=2960 -------------------------------------- Type: Technical Reported by: Raphael Bossek Section: 7.2. Original Text ------------- 7.2. Schema Registration for Schema ............................32 'urn:ietf:params:xml:ns:pidf:status:rpid' ----on the page 32---- 7.2. Schema Registration for Schema 'urn:ietf:params:xml:ns:pidf:status:rpid' URI: urn:ietf:params:xml:ns:pidf:status:rpid Corrected Text -------------- 7.2. Schema Registration for Schema ............................32 'urn:ietf:params:xml:schema:pidf:status:rpid' ----on the page 32---- 7.2. Schema Registration for Schema 'urn:ietf:params:xml:schema:pidf:status:rpid' URI: urn:ietf:params:xml:schema:pidf:status:rpid Notes ----- The XML Schema sub-namespace is 'urn:ietf:params:xml:schema:pidf:status:rpid' (instead of 'urn:ietf:params:xml:ns:pidf:status:rpid') as registered in the IANA maintained registry at http://www.iana.org/assignments/xml-registry/schema.html RFC 3688: The IETF XML Registry; Syntax for XML schema sub-namespace define the XML Schema namespace syntax as "urn:ietf:params:xml:schema:". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4480 (draft-ietf-simple-rpid-10) -------------------------------------- Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Publication Date : July 2006 Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Sep 7 23:52:00 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7866521F8C90 for ; Wed, 7 Sep 2011 23:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmUn+ONYkG07 for ; Wed, 7 Sep 2011 23:51:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D4AA321F8C95 for ; Wed, 7 Sep 2011 23:51:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 61C1B98C266; Wed, 7 Sep 2011 23:53:51 -0700 (PDT) To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20110908065351.61C1B98C266@rfc-editor.org> Date: Wed, 7 Sep 2011 23:53:51 -0700 (PDT) X-Mailman-Approved-At: Thu, 08 Sep 2011 06:38:40 -0700 Cc: raphael.bossek@googlemail.com, simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] [Technical Errata Reported] RFC4480 (2961) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 06:52:00 -0000 The following errata report has been submitted for RFC4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=2961 -------------------------------------- Type: Technical Reported by: Raphael Bossek Section: 4. Original Text ------------- bowling league Corrected Text -------------- Notes ----- The content type is 'element-only'; it's not valid to use tokens. It's possible to use XML elements from other XML namespace (e.g. ) or choose one of the following: , , Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4480 (draft-ietf-simple-rpid-10) -------------------------------------- Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Publication Date : July 2006 Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Sep 8 00:18:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A9921F8B54 for ; Thu, 8 Sep 2011 00:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QloLu5Cj80BV for ; Thu, 8 Sep 2011 00:18:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id F2ACA21F8744 for ; Thu, 8 Sep 2011 00:17:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 304F898C261; Thu, 8 Sep 2011 00:19:50 -0700 (PDT) To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20110908071950.304F898C261@rfc-editor.org> Date: Thu, 8 Sep 2011 00:19:50 -0700 (PDT) X-Mailman-Approved-At: Thu, 08 Sep 2011 06:38:40 -0700 Cc: raphael.bossek@googlemail.com, simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] [Technical Errata Reported] RFC4480 (2962) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 07:18:02 -0000 The following errata report has been submitted for RFC4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=2962 -------------------------------------- Type: Technical Reported by: Raphael Bossek Section: 4. Original Text ------------- urn:device:0003ba4811e3 ... urn:x-mac:0003ba4811e3 ... urn:device:0003ba4811e3 Corrected Text -------------- Replace all three with urn:uuid:698137d0-b395-11e0-aff2-0800200c9a66 Notes ----- "urn:device" is a not registered URN namespace as defined by RFC3406: Uniform Resource Names (URN) Namespace Definition Mechanisms. "urn:x-mac" is an experimental URN namespace. All address point to the same device. RFC 4479 in section 3.4. Device RECOMMENDS version 1 UUIDs for the element: "For devices with a MAC address, version 1 UUIDs are RECOMMENDED, as they result in a time-based identifier that makes use of the MAC address." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4480 (draft-ietf-simple-rpid-10) -------------------------------------- Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Publication Date : July 2006 Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From dean.willis@softarmor.com Thu Sep 8 15:07:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E897B21F8BB3 for ; Thu, 8 Sep 2011 15:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-EAot8Xb3ng for ; Thu, 8 Sep 2011 15:07:21 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB5C21F8BAC for ; Thu, 8 Sep 2011 15:07:21 -0700 (PDT) Received: by qyk34 with SMTP id 34so797341qyk.10 for ; Thu, 08 Sep 2011 15:09:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.106.197 with SMTP id y5mr1041553qao.361.1315519753847; Thu, 08 Sep 2011 15:09:13 -0700 (PDT) Received: by 10.224.10.195 with HTTP; Thu, 8 Sep 2011 15:09:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Sep 2011 17:09:13 -0500 Message-ID: From: Dean Willis To: Eric Burger Content-Type: multipart/alternative; boundary=20cf3074b0149f839604ac754f36 Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 22:07:22 -0000 --20cf3074b0149f839604ac754f36 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 22, 2011 at 11:37 AM, Eric Burger wrote: > > Because the purpose of CEMA is enabling end-to-end encryption, there has > been some debate as to whether, when two CEMA-endpoints are negotiating, TLS > is mandatory or optional. > > Given the security disasters we've recently witnessed with interception of search engine traffic and the current push to "https everywhere" (see: https://www.eff.org/https-everywhere) I think doing anything short of MUST USE TLS would be reprehensible. While TLS is no absolute guarantee (see the recent spate of attacks on CAs resulting in the issuance of bogus certs), it's by far the best thing we have going now. Scaling is a non-issue. All my Google traffic is now TLS (or something much like it, depending on what you think about SPDY) and they don't seem to be complaining much. But without it being mandatory in the spec, we can be sure people are going to defer doing it until it's too late to matter. Just do it. Save a few lives, feel good about yourselves, tell your kids you helped make the world a better place today. -- Dean --20cf3074b0149f839604ac754f36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 22, 2011 at 11:37 AM, Eric B= urger <e= burger@standardstrack.com> wrote:

Because the purpose of CEMA is enabling end-to-end encryption, there has be= en some debate as to whether, when two CEMA-endpoints are negotiating, TLS = is mandatory or optional.


Given the security disasters we've= recently witnessed with interception of search engine traffic and the curr= ent push to "https everywhere" (see:=A0https://www.eff.org/https-everywhere) I think do= ing anything short of MUST USE TLS would be reprehensible.

While TLS is no absolute guarantee (see the recent spat= e of attacks on CAs resulting in the issuance of bogus certs), it's by = far the best thing we have going now.

Scaling is a= non-issue. All my Google traffic is now TLS (or something much like it, de= pending on what you think about SPDY) and they don't seem to be complai= ning much.

But without it being mandatory in the spec, we can be s= ure people are going to defer doing it until it's too late to matter.

Just do it. Save a few lives, feel good about yours= elves, tell your kids you helped make the world a better place today.

--
Dean


--20cf3074b0149f839604ac754f36-- From dean.willis@softarmor.com Thu Sep 8 15:09:53 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B761E21F8BBB for ; Thu, 8 Sep 2011 15:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GBiSha9ppMX for ; Thu, 8 Sep 2011 15:09:52 -0700 (PDT) Received: from mail-qy0-f170.google.com (mail-qy0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4981821F8BBF for ; Thu, 8 Sep 2011 15:09:51 -0700 (PDT) Received: by qyl38 with SMTP id 38so656379qyl.15 for ; Thu, 08 Sep 2011 15:11:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.203.7 with SMTP id fg7mr913586qab.311.1315519902761; Thu, 08 Sep 2011 15:11:42 -0700 (PDT) Received: by 10.224.10.195 with HTTP; Thu, 8 Sep 2011 15:11:42 -0700 (PDT) In-Reply-To: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> <9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com> <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> Date: Thu, 8 Sep 2011 17:11:42 -0500 Message-ID: From: Dean Willis To: Cullen Jennings Content-Type: multipart/alternative; boundary=20cf300fb3e57fc35204ac75588c Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 22:09:53 -0000 --20cf300fb3e57fc35204ac75588c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 26, 2011 at 9:10 AM, Cullen Jennings wrote: > > Are you seriously saying no one would ever use MSRP in an enterprise > network? > > Given that most security threats are inside the enterprise, you really ought to be using TLS even inside your enterprise network. I'm still trying to get TLS on my HP JetDirect printer ... -- Dean --20cf300fb3e57fc35204ac75588c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 26, 2011 at 9:10 AM, Cullen = Jennings <fluffy@c= isco.com> wrote:

Are you seriously saying no one would ever use MSRP in an enterprise networ= k?


Given that mos= t security threats are inside the enterprise, you really ought to be using = TLS even inside your enterprise network.

I'm s= till trying to get TLS on my HP JetDirect printer ...

--
Dean
=A0
--20cf300fb3e57fc35204ac75588c-- From ben@nostrum.com Thu Sep 8 15:35:40 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC3221F8C09 for ; Thu, 8 Sep 2011 15:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFpLeKVUpVGN for ; Thu, 8 Sep 2011 15:35:39 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 83E0921F8C08 for ; Thu, 8 Sep 2011 15:35:39 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p88MbRi6067706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Sep 2011 17:37:29 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233DD1251@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 8 Sep 2011 17:37:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <53C3835E-CDE0-452D-90AE-26D77CC7E6CE@nostrum.com> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233DD1251@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 22:35:40 -0000 On Sep 2, 2011, at 5:12 PM, Christer Holmberg wrote: >=20 > Hi Ben,=20 >=20 > In this reply I'll address your editorial comments, and your comment = on the Middlebox terminology. >=20 >=20 > --------------- >=20 >=20 >> -- section 2, definition of "middle box": " A SIP network=20 >> device that modifies SDP media address:port information in=20 >> order to steer or anchor media flows described in the SDP,=20 >> including TCP and TLS connections used for MSRP=20 >> communication, through a media proxy function controlled by=20 >> the SIP endpoint. " >>=20 >> Thats the usual definition of an SBC. Seems like we are using=20 >> the term middlebox only for SBCs. Maybe we should just call=20 >> it an SBC? There are many types of middleboxes for which CEMA=20 >> will not apply. >=20 > First, it is not only SBCs. Application Servers can also be affected. >=20 > Second, we had a loooong discussion about the terminology, and = Middlebox was a compromise that people could live with, so I really = wouldn't like to have that discussion again.... >=20 > It is true that there are many types of middleboxes for which CEMA = will not apply, and that is why we have text talking about what is the = scope of a Middlebox in the draft. If you don't think that text is good = enough, I'd rather try to improve it rather than changing the = terminology. I can live with middlebox, I guess--but I think we either need some = qualifier to make it clear from the beginning that we are not using the = term in its usual sense (e.g CEMA middlebox), or we need text up front = defining what we mean. As it is, I can think of no generally used = definition of middlebox that isn't much greater in scope (i.e. anything = that relays packets) or much lower in scope (transport level policy = boxes such as NATs and firewalls) Currently, the term appears many time in the introduction, and even the = abstract, prior to getting any definition of scope. I think many readers = are going to read that and think to themselves "No, this is false--many = middleboxes can work just fine without CEMA".=20 >=20 >=20 > --------------- >=20 >=20 >> -- section 1, 2nd paragraph: "=20 >> MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976=20 >> [RFC4976], cannot anchor through Middleboxes. " >>=20 >> How is an MSRP relay not a middle box? >=20 > It is not a Middelbox as defined by the draft. see previous comment. [=85] >=20 >=20 >> -- 4.2, paragraph 5: " offered MSRP media if the port number=20 >> of the MSRP media description is not zero. " >>=20 >> This seems to say that the offerer infers that the answerer=20 >> supports CEMA if the port in the answer is non-zero. Is that=20 >> the intent? >=20 > No, it only indicates that the answerer accepts the MSRP media (with = or without CEMA). >=20 > If you want, I can add a note, saying: >=20 > "NOTE: A zero port value is not an indication that the remote = MSRP entity does not support the CEMA extension." Actually, I misread it. But now I wonder why the draft needs to say it = at all, since it's a normal part of the offer/answer model that seems = unaffected by CEMA. >=20 >=20 > --------------- >=20 >=20 >> -- 4.2, paragraph 9: (note) >>=20 >> Shouldn't this go in the assumptions section? >=20 > I think it is good to have the note here, but I could modify the = beginning, so that is says: >=20 > "NOTE: As described in section 5, in the absence of=85" Okay >=20 >=20 > --------------- >=20 >=20 >> -- 4.2, last paragraph: >>=20 >> The overall structure of this section is confusing. It's not=20 >> obvious what the scope of "all other cases" really means. >=20 > I suggest modifying the paragraph to: >=20 > "In other cases, where none of the criteria above is met, and = where the MSRP endpoint becomes "active", it MUST > use the SDP c/m-line for establishing the MSRP TCP connection. = If the MSRP endpoint becomes "passive",=20 > it will wait for the remote MSRP endpoint to establish the TCP = connection, according to the procedures > in RFC 4975." >=20 I think that helps. [=85] >=20 >> -- 6.2, paragraph 8: "Unless the MSRP endpoints are able to=20 >> use name-based authentication, and they support a common = authentication mechanism,=20 >> they MUST use that mechanism." >>=20 >> Confusing sentence >=20 > I am not sure what is confusing, but is the following more clear? >=20 > "Unless the MSRP endpoints are able to use name-based = authentication, > but they support another common authentication mechanism, they = MUST use > that authentication mechanism. That helps, but I think it needs some elaboration to explain what you = mean. The "unless=85but" construct still confuses me. Do you mean to say = "endpoints MUST use some authentication mechanism if they support it?" = Are you saying name-based authentication is preferred? As worded, it = seems like if I _support_ name-based authentication, I can get away with = using no authentication at all, but if I don't support name-based, I = have to use something. >=20 >=20 > --------------- >=20 >=20 >> -- 6.2, last paragraph: " establish an MSRP connection >> in the likely scenario of intercepted, altered," >>=20 >> Incomplete sentence. Also, should explicitly say "unprotected MSRP" >=20 > I would suggest moving back to the -12 text, and add some explicit = text: >=20 > "NOTE: As defined in RFC 4975, if TLS authentication fails, the = user > need to be able to decide whether to try to anyway establish a > connection with unprotected MSRP media." >=20 I suspect the new text meant to go on to make sure the user was clearly = informed of the risks. The old text is fine with me if such a = qualification is added. >=20 > --------------- >=20 >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Thu Sep 8 15:45:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DAC21F8BE4 for ; Thu, 8 Sep 2011 15:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.928 X-Spam-Level: X-Spam-Status: No, score=-101.928 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfRm77nqP1Pl for ; Thu, 8 Sep 2011 15:45:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CAF3D21F8BB3 for ; Thu, 8 Sep 2011 15:45:07 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p88MkvCd068935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Sep 2011 17:46:58 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E3ADED@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 8 Sep 2011 17:47:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADED@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] CEMA: A couple of additional changes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 22:45:08 -0000 On Sep 7, 2011, at 6:56 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > When replying to Ben's comments, I find a couple of issues for which I = would like to suggest some changes. >=20 >=20 > Section 4.2 > ----------- >=20 > Bullet 3 currently says: >=20 > "3. If the MSRP endpoint is using a relay for MSRP = communication, it > MUST include the address information of the relay (the = MSRP URI of > the topmost SDP a=3Dpath attribute), rather than the = address > information of itself, in the SDP c/m-line associated = with the MSRP > media description. In addition, it MUST include an SDP = a=3Dsetup: > actpass attribute in the MSRP media description of the = SDP offer." >=20 > I suggest to remove the last sentence, about the a=3Dsetup attribute, = and add it to bullet 2. >=20 > So, the new text would be: >=20 > "2. The MSRP endpoint MUST include an SDP a=3Dsetup = attribute in the SDP offer. > If the MSRP endpoint is using a relay for MSRP = communication, it MUST set the=20 > value of a=3Dsetup to "actpass". If the MSRP endpoint is = not using a relay for MSRP=20 > communication, it MUST the value of a=3Dsetup in = accordance with RFC6135 [RFC6135]. >=20 > 3. If the MSRP endpoint is using a relay for MSRP = communication, it MUST =20 > include the address information of the relay (the MSRP = URI of the topmost SDP a=3Dpath=20 > attribute) in the c/m-line associated with the MSRP = media description." I agree that is an improvement. >=20 >=20 > Section 6.2 > ----------- >=20 > Bullet 2 on TLS-PSK suggests the usage of with MICKEY-TICKET. >=20 > I think it would be good to make it a little more flexible, by not = mandating MICKET-TICKET, but simply mention it as an example. >=20 > "2. TLS-PSK. For example, 3GPP has specified the use of = SDES (when SIP transport is integrity protected) and MIKEY-TICKET for = IMS." If I recall, one of the big reasons for mentioning MIKEY-TICKET was that = we believed it did not depend on e2e protection of the SDP. If we remove = the mandate for MIKEY-TICKET, we might consider saying something to the = effect of "TLS-PSK with a key-exchange mechanism that does not depend on = end-to-end protection of the SDP. For example=85" >=20 >=20 > Regards, >=20 > Christer From ben@nostrum.com Thu Sep 8 16:18:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A1021F8B3A for ; Thu, 8 Sep 2011 16:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.204 X-Spam-Level: X-Spam-Status: No, score=-102.204 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HghYME3mTue for ; Thu, 8 Sep 2011 16:18:07 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A33121F8B1A for ; Thu, 8 Sep 2011 16:18:07 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p88NJd06072957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Sep 2011 18:19:41 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 8 Sep 2011 18:19:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 23:18:08 -0000 Hi, see imbedded. I removed sections that I think are agreed upon, and = also the sections where you requested Eric respond. (Eric?) Thanks! Ben. On Sep 7, 2011, at 6:41 AM, Christer Holmberg wrote: > Hi Ben, >=20 > Some of your comments are related to the new security text provided by = Eric, so I will indicate where I expect him to comment. >=20 [=85] >=20 >> -- section 4.1, list of use cases where CEMA does not apply: >>=20 >> These need elaboration. Why does CEMA not apply? Also, I would add=20 >> "middle box used to provide topology hiding on the media channel,=20 >> provide lawful intercept or other monitoring of content, or enforce=20= >> content-related policy". to the list. >=20 > Yes, my intention was to provide more elaboration, but forgot due to = the missunderstandings associated with the submitting of the -00 = version. >=20 > So, the text would say something like: >=20 > "- A non-CEMA-enabled MSRP endpoint becomes "active", as the = endpoint will always establish the TCP or TLS connection using the SDP = a=3Dpath attribute, which contains the address the remote MSRP endpoing, = instead of the SDP c/m-line which contains the address information of = the Middlebox." >=20 > ...and similar for the other cases. >=20 >=20 That helps, thanks! [=85] >=20 >=20 >> -- 4.3, general (and 4.2 to some degree): >>=20 >> With all these heuristics to work around situations where a peer does=20= >> not signal cema support, I'm not sure why we need the tag. Is it just=20= >> to signal the middlebox? >=20 > No, there are enpoint procedures which depend on the presence of the = tag. For example, when the offerer receives an answer, it uses the tag = in the procedure to determine whether a fallback to 4975 behavior is = needed. But only as a short cut, right? That is, of the answer does not contain = the msrp-cema tag, then the offerer has to check a lot of other stuff to = see if it's still okay to use CEMA. We could almost have just said check = all that stuff in the first place. >=20 >=20 > --------------- >=20 >=20 >> -- 4.3, paragraph 5 (list item 4) >>=20 >> What does scenario 4 indicate, assuming the middlebox would act as a=20= >> B2BUA if it didn't see the cema tag in the offer? >=20 > This is actually an error case, where the Middlebox has modified the = c/m-line even if the a=3Dmsrp-cema attribute wasn't present in the SDP = offer, and there is really nothing the answerer can do to fix that.=20 >=20 > (Note that this error case is not CEMA specific) >=20 > So, my suggestion would be to instead send a 488 (Not Acceptable Here) = error response in this case. >=20 Okay >=20 > --------------- >=20 >=20 >> -- 4.3, paragraph 9 (list item 3): "In addition, it MUST include an=20= >> SDP a=3Dsetup: passive attribute in the MSRP media description of the = SDP=20 >> answer." >>=20 >> Is this true if the peer signals msrp-cema? >=20 > Yes. Nevermind, I think I misread something. >=20 >=20 > --------------- >=20 >=20 >> -- 5.1: >>=20 >> I still have a fundamental problem here. This entire work is=20 >> predicated on an assumption about SBC behavior. It's not = standardized,=20 >> and we can't normatively require it. The best we can hope for is that=20= >> all SBC implementors read this spec and do the right thing. >>=20 >> I think that, in practice, many will not, and even if they do,=20 >> carriers will implement policies to prevent interop with peers not=20 >> implementing CEMA. Basically, this assumption promotes walled = gardens. >=20 >=20 > First, if carriers will prevent interop with peers not implementing = CEMA (we can of course not prevent that), it is very likely that they = already today prevent MSRP traffic. >=20 > Second, at least I am aware of customer requirements of interop with = non-CEMA peers, and products that support it. That sort of address my second comment. But saying we are aware of = middleboxes that follow these assumptions is not the same as saying all = do, or even most do. I think what we are trying to do, in a round about = way, is say "if you build your middlebox like this, it will work with = CEMA endpoints." It seems like we are trying to define middlebox = behavior in a nudge-nudge sort of way without actually "officially" = doing anything. I think I could live with this if we add a bit more to the applicability = statement, along the lines of "This document assumes certain middlebox = behaviors as described in section 5. These behaviors are not = standardized, and CEMA may not function properly with middleboxes that = violate these assumptions. Implementors and operators should consider = whether middleboxes in their networks are likely to behave according to = these assumptions before deploying CEMA." >=20 >=20 > --------------- >=20 >=20 >> -- 5.2 :" The Middlebox enables that functionality in cases >> where the remote endpoint does not support the CEMA extension." >>=20 >> Really just the offerer, right? >=20 > Yes. >=20 okay >=20 > --------------- >=20 >=20 >> -- 5.3: >>=20 >> It's worth pointing out that in the fairly common 2 SBC case, this = may=20 >> mean a separate connection between them for each session. >=20 > I suggest the following text: >=20 > "Instead, in order to associate an MSRP message with a specific = session, the=20 > Middlebox often assigns a unique local address:port combination = for each MSRP session. > Due to this, between two Middleboxes there might be a separate = connection for > each MSRP session." WFM >=20 >=20 > --------------- >=20 >=20 >> --5.5, paragraph 1: "Middleboxes relay MSRP media packets >> at the transport layer." >>=20 >> That should be a top level assumption in itself. >=20 > Do you mean the text belongs somewhere else? Not so much that as stating it as an assumption rather than a fact. i.e. = "This document assumes that middleboxes relay=85" [=85] > --------------- >=20 >=20 >> -- 5.5, 2nd paragraph: "Middleboxes can inspect >> and modify the MSRP message content." >>=20 >> Let's not imply that they can only inspect content when the UAs fall=20= >> back to 4975. They can act as B2buas whenever they like, and the=20 >> endpoints can't really tell when it is happening unless the signaling=20= >> channel is integrity protected. >=20 > I suggest the following text: >=20 > "The Middlebox decrypts MSRP media packets received from one = MSRP endpoint, and=20 > then re-encrypts them before sending them toward the other MSRP = endpoint.=20 > Middleboxes can inspect and modify the MSRP message content. As = CEMA does not > require a Middlebox to modify the MSRP content, this can be = prevented if TLS is=20 > used for the MSRP communication, assuming that the SIP = signalling channel is=20 > integrity protected." >=20 >=20 WFM, but it should say "=85 the SIP signaling channel is end-to-end = integrity protected" That is, SIPS doesn't cut it. > --------------- >=20 >=20 >> -- 6.1: "It does not however make it easier for a MiTM to >> monitor TLS protected MSRP" >>=20 >> I think that needs elaboration. >=20 > The end of the setence does say: >=20 > ", since that would require the MiTM to implement MSRP B2BUA = functionality, no=20 > matter if UAs support the CEMA extension or not." WFM >=20 >=20 > --------------- >=20 >=20 >> -- 6.2, 2nd paragraph: "If a Middlebox acts as a TLS B2BUA, MSRP=20 >> endpoints will be able to use fingerprint based authentication for = TLS,=20 >> no matter if they support the CEMA extension or not. " >>=20 >> Isn't this also true for name-based authentication? >=20 > Yes, but the specific text focuses on fingerprint. >=20 > But, I can modify the text to also mention name-based: >=20 > "If a Middlebox acts as a TLS B2BUA, MSRP endpoints will be able = to > use fingerprint based authentication and name-based = authentication for=20 > TLS, no matter if they support the CEMA extension or not. In = such cases,=20 > as the Middlebox acts as TLS endpoints, MSRP endpoints might be = given an=20 > incorrect impression that there is an end-to-end security = association (SA) > between the MSRP endpoints." Your "Yes, but.." sentence answer my question, but I like the proposed = text better anyway :-) >=20 >=20 > --------------- >=20 >=20 >> -- 6.2, 2nd to last paragraph: "If something like SIPS protects the=20= >> SIP signaling" >>=20 >> I suggest you describe the properties you have in mind explicitly,=20 >> rather than just comparing to SIPS >=20 > I suggest to modify bullet 2, where SIPS is mentioned: >=20 > "2. If SIP signalling to/from the endpoint is integrity = protected, typically through=20 > use of IPsec or TLS transport, then an endpoint can depending on = local policy > chose to trust the netwwork endpoints in the signalling path for = SDP integrity and=20 > accept fingerprint based TLS authentication without requiring = end-to-end SDP integrity." I was looking for something like "If the SIP signaling is integrity = protected between the endpoint and network elements on a hop-by-hop = basis, typically.." [=85] >=20 >=20 >> -- 6.2, paragraph 4: >>=20 >> Do the relevant specs recommend using mutually authenticated TLS (or=20= >> DTLS or SRTP) between peers? >=20 > I am not sure which specs you refer to. Good question. I'm not sure what I meant. I may have have messed up the = section reference. If I remember I will bring it back up :-) >=20 > For SRTP end-to-end connections, 3GPP has specified the use of either = SDES or MIKEY-TICKET. The former can be allowed=20 > by the network operator if the SIP signalling is protected, while the = latter does not require such protection since=20 > keys are sent encrypted and managed by an external key management = service. With SDES there is no authentication=20 > performed - the IMS network is trusted - it is just the negotiation of = crypto keys for the media connection that=20 > SDES is used for. >=20 > With MIKEY-TICKET, however, the SDP offerer also indirectly = authenticates the remote SRTP connection endpoint. >=20 > In neither case is there mutual authentication, since in IMS this is = done during user registration and then one normally=20 > uses transport layer security associations in order not to have to = re-authentcate as long as these are ok.=20 >=20 [=85]= From eburger@standardstrack.com Thu Sep 8 20:08:53 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D5821F8B06 for ; Thu, 8 Sep 2011 20:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEYFEW36T7iI for ; Thu, 8 Sep 2011 20:08:48 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7CD21F8B04 for ; Thu, 8 Sep 2011 20:08:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=wAB++Mx/66oPgSRGZf3jKGBgw/7/MFgdzO1qBNwpXKMWEMiQJyzGNOZ73gTFWSFIvCht1XgEHeV5L7FNe28Wup4VYlwPDdF6fad9DreAdqj/OTZ6/pNnrc+Z/zZHgPnm; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R1rU9-0002Fb-VC; Thu, 08 Sep 2011 20:10:34 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-36-75700214; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: Date: Thu, 8 Sep 2011 23:10:32 -0400 Message-Id: <97022582-CB35-4576-BC70-58C9B26F9FB8@standardstrack.com> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> To: Ben Campbell X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2011 03:08:53 -0000 --Apple-Mail-36-75700214 Content-Type: multipart/alternative; boundary=Apple-Mail-35-75700161 --Apple-Mail-35-75700161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 WFM, too. On Sep 8, 2011, at 7:19 PM, Ben Campbell wrote: >>> -- 5.5, 2nd paragraph: "Middleboxes can inspect >>> and modify the MSRP message content." >>>=20 >>> Let's not imply that they can only inspect content when the UAs fall=20= >>> back to 4975. They can act as B2buas whenever they like, and the=20 >>> endpoints can't really tell when it is happening unless the = signaling=20 >>> channel is integrity protected. >>=20 >> I suggest the following text: >>=20 >> "The Middlebox decrypts MSRP media packets received from one = MSRP endpoint, and=20 >> then re-encrypts them before sending them toward the other MSRP = endpoint.=20 >> Middleboxes can inspect and modify the MSRP message content. As = CEMA does not >> require a Middlebox to modify the MSRP content, this can be = prevented if TLS is=20 >> used for the MSRP communication, assuming that the SIP = signalling channel is=20 >> integrity protected." >>=20 >>=20 >=20 > WFM, but it should say "=85 the SIP signaling channel is end-to-end = integrity protected" That is, SIPS doesn't cut it. >=20 --Apple-Mail-35-75700161 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 WFM, = too.

On Sep 8, 2011, at 7:19 PM, Ben Campbell = wrote:

-- 5.5, 2nd = paragraph: "Middleboxes can = inspect
 and modify the MSRP message = content."

Let's not imply that they can = only inspect content when the UAs fall 
back to 4975. They = can act as B2buas whenever they like, and the 
endpoints can't = really tell when it is happening unless the signaling 
channel is = integrity protected.

I suggest the = following text:

"The = Middlebox decrypts MSRP media packets received from one MSRP endpoint, = and 
 
require a = Middlebox to modify the MSRP content, this can be prevented if TLS = is 
 



WFM, but it should say "=85 the SIP = signaling channel is end-to-end integrity protected" That is, SIPS = doesn't cut = it.


= --Apple-Mail-35-75700161-- --Apple-Mail-36-75700214 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTA5MDMxMDMzWjAjBgkqhkiG9w0BCQQxFgQU Pyus9NvlM4ZPZ2AD4QzoEOtq76UwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAQmcgeDJeWSjdGSJEVFs09q44QD0M9dgahh/EWPUzZdcI6nF0dodH Cnh4oxr0QvuqIyLRg/GTMhd6Y8FgpUNVjNNzqOG/BJjETY0EhrK2RO18FSyWWzh1R1dQtUVvnW9r PHEAOzzPqQDLQeCcHfOjJlKzRh+lfZeDrAygYFWeGn2+xQ2YhrOZ1YnOLfGZIdo6eMCWWaB0Oi/d 8nISN3Wsqn6CS93zga6kpFqE8hZXTuacktUpusmhWUQDkLzzMH/rfnfOLXFT9+rNlXY474DtRGjX KPhH7yHGPSF5rhVpE0+jg15KqBhdd93aUZJhcUkpjX51dOBcAsa9fVMXy8wh2AAAAAAAAA== --Apple-Mail-36-75700214-- From eburger@standardstrack.com Thu Sep 8 20:14:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4F121F8BBC for ; Thu, 8 Sep 2011 20:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdW3ixF2-Wb0 for ; Thu, 8 Sep 2011 20:14:19 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id D984921F86D0 for ; Thu, 8 Sep 2011 20:14:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=gojkki1F659587nMBHAGH6BHO2xYrhKHd+J/GIwIaQxn9CON4WXF5aWxZytRBYsW7m0BJ5PUmpBEqirgKHVMuh1Dsa7qilWV8OGIW+sf1eHP1tloKv0DUIJCAG9u2zLF; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R1rZX-00086a-Qp; Thu, 08 Sep 2011 20:16:08 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-37-76034149; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 8 Sep 2011 23:16:06 -0400 Message-Id: <45AE0688-C764-485E-A0F5-1C41D29C2C94@standardstrack.com> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg , Campbell Ben X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2011 03:14:20 -0000 --Apple-Mail-37-76034149 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii inline On Sep 7, 2011, at 7:41 AM, Christer Holmberg wrote: > Hi Ben, >=20 > Some of your comments are related to the new security text provided by = Eric, so I will indicate where I expect him to comment. >=20 > --------------- >=20 >> -- section 1, 3rd paragraph:" In addition, the MSRP message needs to=20= >> be exposed in clear text to the MSRP B2BUA, which violates >> the end-to-end principle [RFC3724] ." >>=20 >> While it would be nice to do better, I must point out that the clear=20= >> text requirement is no different than for SIP proxies. Content can=20 >> still be theoretically protected end to end via S/mime, etc. (not = that=20 >> anyone does that.) >=20 > I'll let Eric reply to this first. It is different. SIP Proxies are never supposed to see RTP in clear = text. Remember MSRP is like RTP, not SIP. [snip] >> -- 4.2, paragraph 10: " The MSRP endpoint MAY choose to terminate = the=20 >> session establishment if it can detect that a Middlebox acting as a=20= >> MSRP B2BUA is not the desired remote endpoint." >>=20 >> How can it detect that? >=20 > I'll let Eric reply to this first. >=20 > (Personally I am not sure how the endpoint would be able to detect). The key here (hats off to Russ) is if the "endpoint" does not have a = trusted X.509 certificate with a trusted root, then the MSRP endpoint = should really let the user know that even if things look secure, they = may not be. [snip] >> -- 6.2, 1st paragraph: "However, while CEMA provides a >> prerequisite for end-to-end integrity," >>=20 >> Only true if the endpoints can't talk p2p, or use some other thing=20 >> like SOCKS, TURN-TCP, etc. >=20 > I'll let Eric reply to this first. If they could talk p2p, they would not be using CEMA in the first place, = right? [snip] >> -- 6.2, last paragraph: "... validating that one or more SIP Proxies = in=20 >> the proxy chain are not, in fact, malicious." >>=20 >> What, no HMAC over the evil bit? :-) >=20 > I'll let Eric reply to this first. Precisely :-) Nothing to say: [...] the endpoints have no cryptographic way of validating that one or more SIP Proxies in the proxy chain are not, in fact, malicious. --Apple-Mail-37-76034149 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTA5MDMxNjA3WjAjBgkqhkiG9w0BCQQxFgQU vkeqpupYkuXc2OWUNYpJPehqvTUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAQGn0DiXlYWgobQhE1BGWsHefF8HNvouKPrLkbhrTDnS+RYZHSYFe pHbB5gr4GxF7xXzprNPZ3Yi/XDyMnDzAkYCnvC/+UsvuSy3EFPiJIvYCroXNBieazXJjBHHZOm76 r1x1JxxRm/wnMeSVsnFcY+bun6ATRsSz3dQgJbqD9peM8O1qvvcA+ifguLGnDZm2c0F1ctcCfWCA 3RDmQT1Y63HmzB4w02Ck8YadCAw6qQkB/nee/9wtqwrWOreqpf/o5e8/dQgmbhMU6OIKsgX3BJef dETJqQE8XQghYKTcdZY5OWQg95Z5DLa1q47/xDl2N7NoJfEW9Dl7oz3oXMld9wAAAAAAAA== --Apple-Mail-37-76034149-- From ben@nostrum.com Thu Sep 8 21:05:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7017E21F8B33 for ; Thu, 8 Sep 2011 21:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaXgmj1SZbpE for ; Thu, 8 Sep 2011 21:05:40 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CAEB021F8B29 for ; Thu, 8 Sep 2011 21:05:40 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8947QEt007979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Sep 2011 23:07:30 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <45AE0688-C764-485E-A0F5-1C41D29C2C94@standardstrack.com> Date: Thu, 8 Sep 2011 23:07:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <287CCFFF-03BF-4CCF-81F8-BC599968E580@nostrum.com> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <45AE0688-C764-485E-A0F5-1C41D29C2C94@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2011 04:05:41 -0000 On Sep 8, 2011, at 10:16 PM, Eric Burger wrote: > inline >=20 > On Sep 7, 2011, at 7:41 AM, Christer Holmberg wrote: >=20 >> Hi Ben, >>=20 >> Some of your comments are related to the new security text provided = by Eric, so I will indicate where I expect him to comment. >>=20 >> --------------- >>=20 >>> -- section 1, 3rd paragraph:" In addition, the MSRP message needs to=20= >>> be exposed in clear text to the MSRP B2BUA, which violates >>> the end-to-end principle [RFC3724] ." >>>=20 >>> While it would be nice to do better, I must point out that the clear=20= >>> text requirement is no different than for SIP proxies. Content can=20= >>> still be theoretically protected end to end via S/mime, etc. (not = that=20 >>> anyone does that.) >>=20 >> I'll let Eric reply to this first. >=20 > It is different. SIP Proxies are never supposed to see RTP in clear = text. Remember MSRP is like RTP, not SIP. Aha, the whole pen register vs content argument. But I take your point, = and withdraw mine. >=20 > [snip] >=20 >>> -- 4.2, paragraph 10: " The MSRP endpoint MAY choose to terminate = the=20 >>> session establishment if it can detect that a Middlebox acting as a=20= >>> MSRP B2BUA is not the desired remote endpoint." >>>=20 >>> How can it detect that? >>=20 >> I'll let Eric reply to this first. >>=20 >> (Personally I am not sure how the endpoint would be able to detect). >=20 > The key here (hats off to Russ) is if the "endpoint" does not have a = trusted X.509 certificate with a trusted root, then the MSRP endpoint = should really let the user know that even if things look secure, they = may not be. That makes sense. Maybe a "For example=85" would be helpful. >=20 > [snip] >=20 >>> -- 6.2, 1st paragraph: "However, while CEMA provides a >>> prerequisite for end-to-end integrity," >>>=20 >>> Only true if the endpoints can't talk p2p, or use some other thing=20= >>> like SOCKS, TURN-TCP, etc. >>=20 >> I'll let Eric reply to this first. >=20 > If they could talk p2p, they would not be using CEMA in the first = place, right? There's some circular logic in there somewhere. The text says "CEMA = provides a prerequisite for e2e integrity". That means to me, you can't = have e2e integrity without CEMA, which is not true on its face. Or maybe = it means you can't have it without the prerequisite that CEMA provides, = but you could get it other ways too? If the second, a bit of elaboration = about what the provided prereq really is would be useful. BTW, assuming we can agree on the rest of it, could this say "=85 for = end to end integrity and _confidentiality_"? >=20 > [snip] >=20 >>> -- 6.2, last paragraph: "... validating that one or more SIP Proxies = in=20 >>> the proxy chain are not, in fact, malicious." >>>=20 >>> What, no HMAC over the evil bit? :-) >>=20 >> I'll let Eric reply to this first. >=20 > Precisely :-) Nothing to say: > [...] the endpoints have no > cryptographic way of validating that one or more SIP Proxies in the > proxy chain are not, in fact, malicious. :-D >=20 >=20 >=20 From christer.holmberg@ericsson.com Fri Sep 9 00:35:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DF421F8B94 for ; Fri, 9 Sep 2011 00:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxjKvgt33sa6 for ; Fri, 9 Sep 2011 00:35:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D93AD21F8B8A for ; Fri, 9 Sep 2011 00:35:58 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-9f-4e69c24f1086 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 87.8D.20773.F42C96E4; Fri, 9 Sep 2011 09:37:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 9 Sep 2011 09:37:51 +0200 From: Christer Holmberg To: Ben Campbell Date: Fri, 9 Sep 2011 09:37:50 +0200 Thread-Topic: CEMA: A couple of additional changes Thread-Index: AcxueTjO4zlghOi/RtGg5dOho1SHNwASVi3Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233E85BC6@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADED@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] CEMA: A couple of additional changes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2011 07:35:59 -0000 Hi Ben,=20 >>Section 6.2 >>----------- >>=20 >>Bullet 2 on TLS-PSK suggests the usage of with MICKEY-TICKET. >>=20 >>I think it would be good to make it a little more flexible,=20 >>by not mandating MICKET-TICKET, but simply mention it as an example. >>=20 >> "2. TLS-PSK. For example, 3GPP has specified=20 >>the use of SDES (when SIP transport is integrity protected)=20 >>and MIKEY-TICKET for IMS." >=20 >If I recall, one of the big reasons for mentioning=20 >MIKEY-TICKET was that we believed it did not depend on e2e=20 >protection of the SDP. If we remove the mandate for=20 >MIKEY-TICKET, we might consider saying something to the=20 >effect of "TLS-PSK with a key-exchange mechanism that does=20 >not depend on end-to-end protection of the SDP. For example..." The text before the bullets does talk about using a mechanism that does not= rely on peer-to-peer SDP integrity. But, I have nothing against adding the text you suggest. Regards, Christer From christer.holmberg@ericsson.com Fri Sep 9 01:25:36 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E7A21F8B15 for ; Fri, 9 Sep 2011 01:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3NpnNGxX8Bn for ; Fri, 9 Sep 2011 01:25:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 24DEA21F8AD8 for ; Fri, 9 Sep 2011 01:25:34 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-cd-4e69cdf0a865 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D7.D5.20773.0FDC96E4; Fri, 9 Sep 2011 10:27:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 9 Sep 2011 10:27:28 +0200 From: Christer Holmberg To: Ben Campbell Date: Fri, 9 Sep 2011 10:27:27 +0200 Thread-Topic: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments Thread-Index: Acxud+X/erzXGg3uS0mInvo1Iel5tAATzxSg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233E85C44@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233DD1251@ESESSCMS0356.eemea.ericsson.se> <53C3835E-CDE0-452D-90AE-26D77CC7E6CE@nostrum.com> In-Reply-To: <53C3835E-CDE0-452D-90AE-26D77CC7E6CE@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2011 08:25:36 -0000 Hi,=20 >>> -- section 2, definition of "middle box": " A SIP network=20 >>> device that=20 >>> modifies SDP media address:port information in order to steer or=20 >>> anchor media flows described in the SDP, including TCP and TLS=20 >>> connections used for MSRP communication, through a media proxy=20 >>> function controlled by the SIP endpoint. " >>>=20 >>> Thats the usual definition of an SBC. Seems like we are using the=20 >>> term middlebox only for SBCs. Maybe we should just call it an SBC?=20 >>> There are many types of middleboxes for which CEMA will not apply. >>=20 >> First, it is not only SBCs. Application Servers can also be=20 >> affected. >>=20 >> Second, we had a loooong discussion about the terminology,=20 >> and Middlebox was a compromise that people could live with,=20 >> so I really wouldn't like to have that discussion again.... >>=20 >> It is true that there are many types of middleboxes for=20 >> which CEMA will not apply, and that is why we have text=20 >> talking about what is the scope of a Middlebox in the draft.=20 >> If you don't think that text is good enough, I'd rather try=20 >> to improve it rather than changing the terminology. >=20 > I can live with middlebox, I guess--but I think we either=20 > need some qualifier to make it clear from the beginning that=20 > we are not using the term in its usual sense (e.g CEMA=20 > middlebox), or we need text up front defining what we mean.=20 > As it is, I can think of no generally used definition of=20 > middlebox that isn't much greater in scope (i.e. anything=20 > that relays packets) or much lower in scope (transport level=20 > policy boxes such as NATs and firewalls) >=20 > Currently, the term appears many time in the introduction,=20 > and even the abstract, prior to getting any definition of=20 > scope. I think many readers are going to read that and think=20 > to themselves "No, this is false--many middleboxes can work=20 > just fine without CEMA".=20 The text in the introduction talk about middleboxes in general (we should u= se "m" instead of "M"). Maybe we could use "CEMA Middlebox" elsewhere in the document, to make it m= ore clear that we are talking about an entity that acts as described in the= Assumptions section. --------------- >>> -- 4.2, paragraph 5: " offered MSRP media if the port=20 >>> number of the MSRP media description is not zero. " >>>=20 >>> This seems to say that the offerer infers that the=20 >>> answerer supports CEMA if the port in the answer is non-zero. Is that t= he intent? >>=20 > No, it only indicates that the answerer accepts the MSRP=20 > media (with or without CEMA). >>=20 >>If you want, I can add a note, saying: >>=20 >> "NOTE: A zero port value is not an indication that the=20 >> remote MSRP entity does not support the CEMA extension." >=20 >Actually, I misread it. But now I wonder why the draft needs=20 >to say it at all, since it's a normal part of the=20 >offer/answer model that seems unaffected by CEMA. I can remove the text. --------------- >>> -- 6.2, paragraph 8: "Unless the MSRP endpoints are able to use=20 >>> name-based authentication, and they support a common=20 >>> authentication mechanism, they MUST use that mechanism." >>>=20 >>> Confusing sentence >>=20 >> I am not sure what is confusing, but is the following more clear? >>=20 >> "Unless the MSRP endpoints are able to use name-based=20 >> authentication, but they support another common authentication=20 >> mechanism, they MUST use that authentication mechanism. >=20 >That helps, but I think it needs some elaboration to explain=20 >what you mean. The "unless...but" construct still confuses me.=20 >Do you mean to say "endpoints MUST use some authentication=20 >mechanism if they support it?" Are you saying name-based=20 >authentication is preferred? As worded, it seems like if I=20 >_support_ name-based authentication, I can get away with=20 >using no authentication at all, but if I don't support=20 >name-based, I have to use something. Ok, I understand. The intention is to say that name-based authentication is used, if possible= . Is the following more clear? "If possible, MSRP endpoints MUST use name-based authentication. If not possible, if the MSRP endpoints support a common authentication=20 mechanism, they MUST use that mechanism. If the MSRP endpoints do not=20 support such common authentication mechanism, they MUST try fingerprint-ba= sed authentication, which will succeed if there are no Middleboxes present. If that also fails, the MSRP endpoints MUST either:" --------------- Thanks! Regards, Christer From christer.holmberg@ericsson.com Fri Sep 9 05:15:17 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B9121F8AD6 for ; Fri, 9 Sep 2011 05:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYRoZLhQg99A for ; Fri, 9 Sep 2011 05:15:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 440C621F8ACA for ; Fri, 9 Sep 2011 05:15:16 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d6-4e6a03c64ee9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4C.0B.20773.6C30A6E4; Fri, 9 Sep 2011 14:17:10 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 9 Sep 2011 14:17:10 +0200 From: Christer Holmberg To: Ben Campbell Date: Fri, 9 Sep 2011 14:17:08 +0200 Thread-Topic: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments Thread-Index: AcxufdLFNHIxf8C8TWWbygg1Af+vLAAUJGTg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2011 12:15:17 -0000 Hi,=20 >>> -- 4.3, general (and 4.2 to some degree): >>>=20 >>> With all these heuristics to work around situations where=20 >>> a peer does not signal cema support, I'm not sure why we need the tag.= =20 >>> Is it just to signal the middlebox? >>=20 >> No, there are enpoint procedures which depend on the=20 >> presence of the tag. For example, when the offerer receives=20 >> an answer, it uses the tag in the procedure to determine=20 >> whether a fallback to 4975 behavior is needed. >=20 > But only as a short cut, right? That is, of the answer does=20 > not contain the msrp-cema tag, then the offerer has to check=20 > a lot of other stuff to see if it's still okay to use CEMA.=20 > We could almost have just said check all that stuff in the=20 > first place. --------------- >>> -- 5.1: >>>=20 >>> I still have a fundamental problem here. This entire work is=20 >>> predicated on an assumption about SBC behavior. It's not=20 >>> standardized, and we can't normatively require it. The best we can=20 >>> hope for is that all SBC implementors read this spec and=20 >>> the right thing. >>>=20 >>> I think that, in practice, many will not, and even if they do,=20 >>> carriers will implement policies to prevent interop with peers not=20 >>> implementing CEMA. Basically, this assumption promotes=20 >>> walled gardens. >>=20 >>=20 >> First, if carriers will prevent interop with peers not=20 >> implementing CEMA (we can of course not prevent that), it is=20 >> very likely that they already today prevent MSRP traffic. >>=20 >> Second, at least I am aware of customer requirements of=20 >> interop with non-CEMA peers, and products that support it. >=20 > That sort of address my second comment. But saying we are=20 > aware of middleboxes that follow these assumptions is not the=20 > same as saying all do, or even most do. I think what we are=20 > trying to do, in a round about way, is say "if you build your=20 > middlebox like this, it will work with CEMA endpoints." It=20 > seems like we are trying to define middlebox behavior in a=20 > nudge-nudge sort of way without actually "officially" doing anything. >=20 > I think I could live with this if we add a bit more to the=20 > applicability statement, along the lines of "This document=20 > assumes certain middlebox behaviors as described in section=20 > 5. These behaviors are not standardized, and CEMA may not=20 > function properly with middleboxes that violate these=20 > assumptions. Implementors and operators should consider=20 > whether middleboxes in their networks are likely to behave=20 > according to these assumptions before deploying CEMA." A middlebox can either implement the CEMA assumptions, or it doesn't. If it= doesn't, in order for MSRP to work, it needs to always enable MSRP B2BUA f= unctionality. >From a CEMA perspective both cases are fine, as CEMA defines a fallback pro= cedure. So, I don't think we should give a picture that, in order for MSRP = to work, middleboxes must implement CEMA. If they don't, the CEMA extension= won't of course be enabled, but things will still work. (If a middlebox does SOMETHING ELSE, MSRP won't work - with or without CEMA= - and I don't think we need to, or even can, say anything about that.) So, maybe something like: "In order for MSRP endpoints to use the CEMA extension, this document assum= es certain middlebox behaviors, as described in section 5. However, the doc= ument also defines a fallback mechanism in case a middlebox does not suppor= t CEMA, and always enables MSRP B2BUA functionality for MSRP calls." --------------- >>> --5.5, paragraph 1: "Middleboxes relay MSRP media packets >>> at the transport layer." >>>=20 >>> That should be a top level assumption in itself. >>=20 >> Do you mean the text belongs somewhere else? >=20 >Not so much that as stating it as an assumption rather than a=20 >fact. i.e. "This document assumes that middleboxes relay..." Sure, but where do you want that text? --------------- >>> -- 5.5, 2nd paragraph: "Middleboxes can inspect >>> and modify the MSRP message content." >>>=20 >>> Let's not imply that they can only inspect content when=20 >>> the UAs fall back to 4975. They can act as B2buas whenever they like, a= nd the=20 >>> endpoints can't really tell when it is happening unless=20 >>> the signaling channel is integrity protected. >>=20 >> I suggest the following text: >>=20 >> "The Middlebox decrypts MSRP media packets received=20 >> from one MSRP endpoint, and then re-encrypts them before sending them= toward the=20 >> other MSRP endpoint. Middleboxes can inspect and modify the MSRP mess= age=20 >> content. As CEMA does not require a Middlebox to modify the MSRP cont= ent, this=20 >> can be prevented if TLS is used for the MSRP communication, assuming = that the SIP=20 >> signalling channel is integrity protected." >>=20 >=20 >WFM, but it should say "... the SIP signaling channel is=20 >end-to-end integrity protected" That is, SIPS doesn't cut it. Ok. --------------- >>> -- 6.2, 2nd to last paragraph: "If something like SIPS=20 >>> protects the=20 >>> SIP signaling" >>>=20 >>> I suggest you describe the properties you have in mind explicitly,=20 >>> rather than just comparing to SIPS >>=20 >> I suggest to modify bullet 2, where SIPS is mentioned: >>=20 >> "2. If SIP signalling to/from the endpoint is integrity=20 >> protected, typically through=20 >> use of IPsec or TLS transport, then an endpoint can=20 >> depending on local policy >> chose to trust the netwwork endpoints in the signalling=20 >> path for SDP integrity and=20 >> accept fingerprint based TLS authentication without=20 >> requiring end-to-end SDP integrity." >=20 > I was looking for something like "If the SIP signaling is=20 > integrity protected between the endpoint and network elements=20 > on a hop-by-hop basis, typically.." Ok. --------------- >>> -- 6.2, paragraph 4: >>>=20 >>> Do the relevant specs recommend using mutually=20 >>> authenticated TLS (or=20 >>> DTLS or SRTP) between peers? >>=20 >> I am not sure which specs you refer to. >=20 > Good question. I'm not sure what I meant. I may have have=20 > messed up the section reference. If I remember I will bring=20 > it back up :-) Ok :) --------------- Thanks! Regards, Christer From christer.holmberg@ericsson.com Fri Sep 9 05:22:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8621F8AD6 for ; Fri, 9 Sep 2011 05:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpUznjJP7h0U for ; Fri, 9 Sep 2011 05:22:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 524F721F889A for ; Fri, 9 Sep 2011 05:22:32 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-20-4e6a057a589d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 93.2C.20773.A750A6E4; Fri, 9 Sep 2011 14:24:26 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 9 Sep 2011 14:24:26 +0200 From: Christer Holmberg To: Christer Holmberg , Ben Campbell Date: Fri, 9 Sep 2011 14:24:25 +0200 Thread-Topic: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments Thread-Index: AcxufdLFNHIxf8C8TWWbygg1Af+vLAAUJGTgAAcHMXA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233E85E8A@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2011 12:22:33 -0000 Hi, I noted that I forgot to reply to one of your comments :) >>>> -- 4.3, general (and 4.2 to some degree): >>>>=20 >>>> With all these heuristics to work around situations where a peer=20 >>>> does not signal cema support, I'm not sure why we need the tag. >>>> Is it just to signal the middlebox? >>>=20 >>> No, there are enpoint procedures which depend on the=20 >>> presence of the=20 >>> tag. For example, when the offerer receives an answer, it uses the=20 >>> tag in the procedure to determine whether a fallback to=20 >>> 4975 behavior is needed. >>=20 >> But only as a short cut, right? That is, of the answer does not=20 >> contain the msrp-cema tag, then the offerer has to check a lot of=20 >> other stuff to see if it's still okay to use CEMA. >> We could almost have just said check all that stuff in the first=20 >> place. =20 The offerer has to check things, but the anwserer also does things dependin= g on whether the offer contains the tag or not.=20 An example is the error case change I suggested earlier (related to your co= mment on bullet 4) in section 4.3), where a 488 response would be sent. --------------- Regards, Christer From eburger@standardstrack.com Fri Sep 9 14:29:05 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A90E21F8715 for ; Fri, 9 Sep 2011 14:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41Tp3Iro8cmv for ; Fri, 9 Sep 2011 14:29:04 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id C55F621F8A62 for ; Fri, 9 Sep 2011 14:29:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=VArtqXrPoxszKuascx9bdCbHnOuCrggJMM2snvVVJYDk51w1a+jGLgII7VJjBJBpvBUFFv/12e+Rhz/oqOBvSSefYeX8bRGUkxa172sUxHVr1lJaeieF2wuwc2n4+Pzg; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R28f0-0005WA-Ta; Fri, 09 Sep 2011 14:30:55 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-75-141720105; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <287CCFFF-03BF-4CCF-81F8-BC599968E580@nostrum.com> Date: Fri, 9 Sep 2011 17:30:52 -0400 Message-Id: References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <45AE0688-C764-485E-A0F5-1C41D29C2C94@standardstrack.com> <287CCFFF-03BF-4CCF-81F8-BC599968E580@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2011 21:29:05 -0000 --Apple-Mail-75-141720105 Content-Type: multipart/alternative; boundary=Apple-Mail-74-141720046 --Apple-Mail-74-141720046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Shrapnel from when CEMA mandated TLS. If you had CEMA and the remote = endpoint advertised CEMA, you knew a'priori you would get a TLS = connection. Since we decided to wimp out, the statement no longer holds. On Sep 9, 2011, at 12:07 AM, Ben Campbell wrote: >>>> -- 6.2, 1st paragraph: "However, while CEMA provides a >>>> prerequisite for end-to-end integrity," >>>>=20 >>>> Only true if the endpoints can't talk p2p, or use some other thing=20= >>>> like SOCKS, TURN-TCP, etc. >>>=20 >>> I'll let Eric reply to this first. >>=20 >> If they could talk p2p, they would not be using CEMA in the first = place, right? >=20 > There's some circular logic in there somewhere. The text says "CEMA = provides a prerequisite for e2e integrity". That means to me, you can't = have e2e integrity without CEMA, which is not true on its face. Or maybe = it means you can't have it without the prerequisite that CEMA provides, = but you could get it other ways too? If the second, a bit of elaboration = about what the provided prereq really is would be useful. >=20 > BTW, assuming we can agree on the rest of it, could this say "=85 for = end to end integrity and _confidentiality_"? --Apple-Mail-74-141720046 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
-- 6.2, 1st paragraph: "However, while CEMA provides = a
prerequisite for end-to-end = integrity,"

Only = true if the endpoints can't talk p2p, or use some other thing 
like SOCKS, TURN-TCP, = etc.

I'll let Eric reply to this = first.

If they could = talk p2p, they would not be using CEMA in the first place, = right?

There's some circular logic in there = somewhere. The text says "CEMA provides a prerequisite for e2e = integrity". That means to me, you can't have e2e integrity without CEMA, = which is not true on its face. Or maybe it means you can't have it = without the prerequisite that CEMA provides, but you could get it other = ways too? If the second, a bit of elaboration about what the provided = prereq really is would be useful.

BTW, assuming we can agree on = the rest of it, could this say "=85 for end to end integrity and = _confidentiality_"?

= --Apple-Mail-74-141720046-- --Apple-Mail-75-141720105 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTA5MjEzMDUzWjAjBgkqhkiG9w0BCQQxFgQU qsK49CPsvuXRSml8VDWjsn6ZXqswgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAVTy4EYIH1brEN0jovoJtuGuNLaACoZfTLh4tJX7Mf/4WwPEczV06 9GloxZfI0YogZaNgKlc+kLIK+//UXdYQ5KuruSsctljtPiOAuf5ADmhmuBuAUJNPF8u/wFcLR7iy xBFiP+Ui7yRdxR38GZWltlfLcWxEd1iBtgHLfPGMWTRh3UFHKbI5bKCCPPBq5+8yo4QxKGd6PeNj c9JO4Cvzl1ijoAe703E2x/HgjzhKEyLnHjRKigXSo0zR1yHCuUArwJ6RY53+pl2gL4nIdkZZ8393 ZtapTA1o178K7KEJOzlT1D5aJK7vbJzvVWSfZsGhiaE/L2cDoKwDXmH+lO9rqgAAAAAAAA== --Apple-Mail-75-141720105-- From prasun.bheri@gmail.com Mon Sep 12 03:19:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB7821F8591 for ; Mon, 12 Sep 2011 03:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkayZxkPLgJ2 for ; Mon, 12 Sep 2011 03:19:00 -0700 (PDT) Received: from mail-gw0-f52.google.com (mail-gw0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 99EFC21F8500 for ; Mon, 12 Sep 2011 03:19:00 -0700 (PDT) Received: by gwj15 with SMTP id 15so3408383gwj.39 for ; Mon, 12 Sep 2011 03:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=XCzE8rQvPTTie8fmdD1HXK8+4nNUttRR50TzaRJm6tw=; b=IsBCEw8zpFfWug8mJcclRpUP9ig/nZhE3vRARUX0Ngym9JLToea37h7ckw9Vwrz+LN yaQs3e5SXo51Od7ndZQVZ2XEUy6OkgGEukvt/1SWpd+DTfGfWNl+c+FJHji7jtL6cC7Y BjWCwmTW8+jNisrBGzx70176uMiyAQC8CcsWo= Received: by 10.236.155.198 with SMTP id j46mr25045956yhk.23.1315822861088; Mon, 12 Sep 2011 03:21:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.199.106 with HTTP; Mon, 12 Sep 2011 03:20:20 -0700 (PDT) From: prasun bheri Date: Mon, 12 Sep 2011 15:50:20 +0530 Message-ID: To: Simple@ietf.org Content-Type: multipart/alternative; boundary=20cf302d4c0438f64004acbbe26a Subject: [Simple] Query on connection sharing. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2011 10:19:01 -0000 --20cf302d4c0438f64004acbbe26a Content-Type: text/plain; charset=ISO-8859-1 Hi, I have a scenario where my MSRP implementation is used by multiple applications simultaneously, so it supports multiple AOR's (Address of Records). in this case can two applications share the same tcp connection when appropriate? lets say My app facilitates two AOR's A & B which are using same MSRP module. now A is connected to client C (C is located in another system) and later B wants to connect to C, in this case can MSRP module share the existing tcp connection or should it create a new tcp connection between B and C? [Assuming all three clients are using simple TCP connection with out any security] Thanks in advance Prasun --20cf302d4c0438f64004acbbe26a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

I have a scenario where my MSRP implementation is used b= y multiple applications simultaneously,

so it supports multiple AOR's (Address of Records).=A0


in this case can two applications share the same tcp con= nection when appropriate?


lets say

My app facilitates two AOR's A= & B which are using same MSRP module.=A0

now A is connected to client C (C is located in another = system) and later B wants to connect to C,=A0

in this case can MSRP=A0module share the e= xisting tcp connection or should it create a new tcp=A0

connection between B and C?


[Assuming all three clients are using simple TCP connection with out any se= curity]


Thanks in advance

Prasun


--20cf302d4c0438f64004acbbe26a-- From christer.holmberg@ericsson.com Mon Sep 12 03:37:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DAF21F8511 for ; Mon, 12 Sep 2011 03:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIm4pSl9-pLg for ; Mon, 12 Sep 2011 03:37:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C466A21F84D6 for ; Mon, 12 Sep 2011 03:37:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-f5-4e6de14bbb0d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C5.9F.02839.B41ED6E4; Mon, 12 Sep 2011 12:39:07 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 12 Sep 2011 12:39:06 +0200 From: Christer Holmberg To: Eric Burger , Ben Campbell Date: Mon, 12 Sep 2011 12:39:04 +0200 Thread-Topic: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments Thread-Index: AcxvN8UpynDtysvNTYqTri8WYK7+uACAFsag Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDA53F@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <45AE0688-C764-485E-A0F5-1C41D29C2C94@standardstrack.com> <287CCFFF-03BF-4CCF-81F8-BC599968E580@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852233EDA53FESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2011 10:37:07 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852233EDA53FESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, So, should the statement be removed? Regards, Christer _____ From: Eric Burger [mailto:eburger@standardstrack.com] Sent: 10. syyskuuta 2011 0:31 To: Ben Campbell Cc: Christer Holmberg; Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's = Substantive Comments Shrapnel from when CEMA mandated TLS. If you had CEMA and the remote endpoi= nt advertised CEMA, you knew a'priori you would get a TLS connection. Since= we decided to wimp out, the statement no longer holds. On Sep 9, 2011, at 12:07 AM, Ben Campbell wrote: -- 6.2, 1st paragraph: "However, while CEMA provides a prerequisite for end-to-end integrity," Only true if the endpoints can't talk p2p, or use some other thing like SOCKS, TURN-TCP, etc. I'll let Eric reply to this first. If they could talk p2p, they would not be using CEMA in the first place, ri= ght? There's some circular logic in there somewhere. The text says "CEMA provide= s a prerequisite for e2e integrity". That means to me, you can't have e2e i= ntegrity without CEMA, which is not true on its face. Or maybe it means you= can't have it without the prerequisite that CEMA provides, but you could g= et it other ways too? If the second, a bit of elaboration about what the pr= ovided prereq really is would be useful. BTW, assuming we can agree on the rest of it, could this say "... for end t= o end integrity and _confidentiality_"? --_000_7F2072F1E0DE894DA4B517B93C6A05852233EDA53FESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
So, should the statement be remov= ed?
 
Regards,
 
Christer
 

From: Eric Burger [mailto:eburger@s= tandardstrack.com]
Sent: 10. syyskuuta 2011 0:31
To: Ben Campbell
Cc: Christer Holmberg; Simple WG
Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - -= Ben's Substantive Comments

Shrapnel from when CEMA mandated TLS. If you had CEMA and the remote endpoi= nt advertised CEMA, you knew a'priori you would get a TLS connection. Since= we decided to wimp out, the statement no longer holds.

On Sep 9, 2011, at 12:07 AM, Ben Campbell wrote:

-- 6.2, 1st paragraph: "However, while CEMA = provides a
prerequisite for end-to-end integrity,"

Only true if the endpoints can't talk p2p, or use= some other thing 
like SOCKS, TURN-TCP, etc.

I'll let Eric reply to this first.

If they could talk p2p, they would not be using C= EMA in the first place, right?

There's some circular logic in there somewhere. The text says "CEMA pr= ovides a prerequisite for e2e integrity". That means to me, you can't = have e2e integrity without CEMA, which is not true on its face. Or maybe it= means you can't have it without the prerequisite that CEMA provides, but you could get it other ways too? If the second, a = bit of elaboration about what the provided prereq really is would be useful= .

BTW, assuming we can agree on the rest of it, could this say "… = for end to end integrity and _confidentiality_"?

--_000_7F2072F1E0DE894DA4B517B93C6A05852233EDA53FESESSCMS0356e_-- From eburger@standardstrack.com Mon Sep 12 03:46:15 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA8321F8A70 for ; Mon, 12 Sep 2011 03:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx+4fvbsNgnS for ; Mon, 12 Sep 2011 03:46:15 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 283B921F8ABB for ; Mon, 12 Sep 2011 03:46:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=qkix/8Zsz+vonXtbqIxVMJNlM7/frP6nTrxflZAMZBzECkZpkBCs7Q3e+vurMxC4E6tcZPYcbZJmQqmXk3wQdndPiUfLCxnOUZsJU9C8aibmFhw02K/c6r62zbg6PnCK; Received: from [64.134.158.133] (helo=[192.168.6.162]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R343l-0006JO-AT; Mon, 12 Sep 2011 03:48:17 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-5-362364074; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDA53F@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 12 Sep 2011 05:48:16 -0500 Message-Id: <5840F5ED-B7D7-4D59-BD7B-CF95C910E00B@standardstrack.com> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <45AE0688-C764-485E-A0F5-1C41D29C2C94@standardstrack.com> <287CCFFF-03BF-4CCF-81F8-BC599968E580@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDA53F@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2011 10:46:15 -0000 --Apple-Mail-5-362364074 Content-Type: multipart/alternative; boundary=Apple-Mail-4-362364026 --Apple-Mail-4-362364026 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Affirmative. On Sep 12, 2011, at 5:39 AM, Christer Holmberg wrote: > Hi, > =20 > So, should the statement be removed? > =20 > Regards, > =20 > Christer > =20 >=20 > From: Eric Burger [mailto:eburger@standardstrack.com]=20 > Sent: 10. syyskuuta 2011 0:31 > To: Ben Campbell > Cc: Christer Holmberg; Simple WG > Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - = Ben's Substantive Comments >=20 > Shrapnel from when CEMA mandated TLS. If you had CEMA and the remote = endpoint advertised CEMA, you knew a'priori you would get a TLS = connection. Since we decided to wimp out, the statement no longer holds. >=20 > On Sep 9, 2011, at 12:07 AM, Ben Campbell wrote: >=20 >>>>> -- 6.2, 1st paragraph: "However, while CEMA provides a >>>>> prerequisite for end-to-end integrity," >>>>>=20 >>>>> Only true if the endpoints can't talk p2p, or use some other thing=20= >>>>> like SOCKS, TURN-TCP, etc. >>>>=20 >>>> I'll let Eric reply to this first. >>>=20 >>> If they could talk p2p, they would not be using CEMA in the first = place, right? >>=20 >> There's some circular logic in there somewhere. The text says "CEMA = provides a prerequisite for e2e integrity". That means to me, you can't = have e2e integrity without CEMA, which is not true on its face. Or maybe = it means you can't have it without the prerequisite that CEMA provides, = but you could get it other ways too? If the second, a bit of elaboration = about what the provided prereq really is would be useful. >>=20 >> BTW, assuming we can agree on the rest of it, could this say "=85 for = end to end integrity and _confidentiality_"? >=20 --Apple-Mail-4-362364026 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi,
 
So, should the statement = be removed?
 
Regards,
=
 
Christer
=
 

From: Eric Burger = [mailto:eburger@standardstrack.com]
Sent: 10. syyskuuta 2011 0:31
To: Ben Campbell
Cc: Christer Holmberg; Simple WG
Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 = - - Ben's Substantive Comments

Shrapnel from when CEMA mandated TLS. If you had CEMA and the remote = endpoint advertised CEMA, you knew a'priori you would get a TLS = connection. Since we decided to wimp out, the statement no longer holds.

On Sep 9, 2011, at 12:07 AM, Ben Campbell wrote:

-- 6.2, 1st paragraph: "However, while CEMA = provides a
prerequisite for end-to-end integrity,"

Only true if the endpoints can't talk p2p, or = use some other thing 
like SOCKS, TURN-TCP, etc.

I'll let Eric reply to this first.

If they could talk p2p, they would not be = using CEMA in the first place, right?

There's some circular logic in there somewhere. The text says "CEMA = provides a prerequisite for e2e integrity". That means to me, you can't = have e2e integrity without CEMA, which is not true on its face. Or maybe = it means you can't have it without the prerequisite that CEMA provides, but you could get it other ways too? If the second, = a bit of elaboration about what the provided prereq really is would be = useful.

BTW, assuming we can agree on the rest of it, could this say "=85 for = end to end integrity and _confidentiality_"?


= --Apple-Mail-4-362364026-- --Apple-Mail-5-362364074 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTEyMTA0ODE3WjAjBgkqhkiG9w0BCQQxFgQU qV2KFOBWlWmTPmuIV7CQeaEuJ1IwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAfPWE8j+9O+fEGlE+fTG1tWd09k+Enbipgm2ALMJsK9L1H81xZeTE w+XrFeZBeJSNuSAM26YGY1d6ig3BjphgA7+3TC3yBGfne3BgS0Io3pwUElswIRgmjFBcWotEwNpA 2nuU7msvbeeAX/Glkk75Xtn4pRUc2LufTjdAfXmJaMS21uK3+ze3GYutOUlfwnmr+VegK43NRsW7 D9Ph6VMM470AV/2vaqBGCrkp6eEJCqDCmGNAybui0NF2O5Q58bC5SS0sAL+al6CKH5aRyJMdFaep 14MUo1aolXQ/fkzcBI+qU+/RK0v05C8BG0WzN8Fs3vNkXgMqlxIpOs5jZqi90AAAAAAAAA== --Apple-Mail-5-362364074-- From ben@nostrum.com Mon Sep 12 14:12:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58BC21F8E26 for ; Mon, 12 Sep 2011 14:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGtMPN7fqMLv for ; Mon, 12 Sep 2011 14:12:22 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6C321F8D0C for ; Mon, 12 Sep 2011 14:12:21 -0700 (PDT) Received: from dn3-227.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 p8CLEMiu001415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Sep 2011 16:14:23 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E85BC6@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 12 Sep 2011 16:14:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <291EC2AA-8CA6-44D4-B3B1-8077A4C8C014@nostrum.com> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADED@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85BC6@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] CEMA: A couple of additional changes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2011 21:12:22 -0000 On Sep 9, 2011, at 2:37 AM, Christer Holmberg wrote: >=20 > Hi Ben,=20 >=20 >>> Section 6.2 >>> ----------- >>>=20 >>> Bullet 2 on TLS-PSK suggests the usage of with MICKEY-TICKET. >>>=20 >>> I think it would be good to make it a little more flexible,=20 >>> by not mandating MICKET-TICKET, but simply mention it as an example. >>>=20 >>> "2. TLS-PSK. For example, 3GPP has specified=20 >>> the use of SDES (when SIP transport is integrity protected)=20 >>> and MIKEY-TICKET for IMS." >>=20 >> If I recall, one of the big reasons for mentioning=20 >> MIKEY-TICKET was that we believed it did not depend on e2e=20 >> protection of the SDP. If we remove the mandate for=20 >> MIKEY-TICKET, we might consider saying something to the=20 >> effect of "TLS-PSK with a key-exchange mechanism that does=20 >> not depend on end-to-end protection of the SDP. For example..." >=20 > The text before the bullets does talk about using a mechanism that = does not rely on peer-to-peer SDP integrity. >=20 > But, I have nothing against adding the text you suggest. >=20 Sorry, I guess I was reading statelessly. But, is the intent to say we = RECOMMEND one of these two approaches, or we RECOMMEND anything that = doesn't need e2e integrity? It seems like both at the moment, which is a = little redundant. > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Mon Sep 12 14:17:10 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D61D21F8D0F for ; Mon, 12 Sep 2011 14:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju0LP2XHcwnk for ; Mon, 12 Sep 2011 14:17:09 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E24F21F8C67 for ; Mon, 12 Sep 2011 14:17:09 -0700 (PDT) Received: from dn3-227.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 p8CLJAxK002034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Sep 2011 16:19:11 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E85C44@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 12 Sep 2011 16:19:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233DD1251@ESESSCMS0356.eemea.ericsson.se> <53C3835E-CDE0-452D-90AE-26D77CC7E6CE@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E85C44@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2011 21:17:10 -0000 On Sep 9, 2011, at 3:27 AM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >>>> -- section 2, definition of "middle box": " A SIP network=20 >>>> device that=20 >>>> modifies SDP media address:port information in order to steer or=20 >>>> anchor media flows described in the SDP, including TCP and TLS=20 >>>> connections used for MSRP communication, through a media proxy=20 >>>> function controlled by the SIP endpoint. " >>>>=20 >>>> Thats the usual definition of an SBC. Seems like we are using the=20= >>>> term middlebox only for SBCs. Maybe we should just call it an SBC?=20= >>>> There are many types of middleboxes for which CEMA will not apply. >>>=20 >>> First, it is not only SBCs. Application Servers can also be=20 >>> affected. >>>=20 >>> Second, we had a loooong discussion about the terminology,=20 >>> and Middlebox was a compromise that people could live with,=20 >>> so I really wouldn't like to have that discussion again.... >>>=20 >>> It is true that there are many types of middleboxes for=20 >>> which CEMA will not apply, and that is why we have text=20 >>> talking about what is the scope of a Middlebox in the draft.=20 >>> If you don't think that text is good enough, I'd rather try=20 >>> to improve it rather than changing the terminology. >>=20 >> I can live with middlebox, I guess--but I think we either=20 >> need some qualifier to make it clear from the beginning that=20 >> we are not using the term in its usual sense (e.g CEMA=20 >> middlebox), or we need text up front defining what we mean.=20 >> As it is, I can think of no generally used definition of=20 >> middlebox that isn't much greater in scope (i.e. anything=20 >> that relays packets) or much lower in scope (transport level=20 >> policy boxes such as NATs and firewalls) >>=20 >> Currently, the term appears many time in the introduction,=20 >> and even the abstract, prior to getting any definition of=20 >> scope. I think many readers are going to read that and think=20 >> to themselves "No, this is false--many middleboxes can work=20 >> just fine without CEMA".=20 >=20 > The text in the introduction talk about middleboxes in general (we = should use "m" instead of "M"). The second paragraph of the intro is pretty much talking about = Middleboxes as defined in this draft, not middleboxes in general. I = think many readers are going to trip over this, as you have not yet said = "In this draft, we use the term middlebox for something specific, and = possibly different from what you've heard before" before we start = talking about how Middleboxes work. >=20 > Maybe we could use "CEMA Middlebox" elsewhere in the document, to make = it more clear that we are talking about an entity that acts as described = in the Assumptions section. On reflection, I'm not sure CEMA middleboxes is the right choice, unless = that's only used to mean SBC-like middleboxes that follow the = assumptions in [assumption section]. >=20 >=20 > --------------- >=20 >=20 >>>> -- 4.2, paragraph 5: " offered MSRP media if the port=20 >>>> number of the MSRP media description is not zero. " >>>>=20 >>>> This seems to say that the offerer infers that the=20 >>>> answerer supports CEMA if the port in the answer is non-zero. Is = that the intent? >>>=20 >> No, it only indicates that the answerer accepts the MSRP=20 >> media (with or without CEMA). >>>=20 >>> If you want, I can add a note, saying: >>>=20 >>> "NOTE: A zero port value is not an indication that the=20 >>> remote MSRP entity does not support the CEMA extension." >>=20 >> Actually, I misread it. But now I wonder why the draft needs=20 >> to say it at all, since it's a normal part of the=20 >> offer/answer model that seems unaffected by CEMA. >=20 > I can remove the text. >=20 >=20 > --------------- >=20 >=20 >>>> -- 6.2, paragraph 8: "Unless the MSRP endpoints are able to use=20 >>>> name-based authentication, and they support a common=20 >>>> authentication mechanism, they MUST use that mechanism." >>>>=20 >>>> Confusing sentence >>>=20 >>> I am not sure what is confusing, but is the following more clear? >>>=20 >>> "Unless the MSRP endpoints are able to use name-based=20 >>> authentication, but they support another common authentication=20 >>> mechanism, they MUST use that authentication mechanism. >>=20 >> That helps, but I think it needs some elaboration to explain=20 >> what you mean. The "unless...but" construct still confuses me.=20 >> Do you mean to say "endpoints MUST use some authentication=20 >> mechanism if they support it?" Are you saying name-based=20 >> authentication is preferred? As worded, it seems like if I=20 >> _support_ name-based authentication, I can get away with=20 >> using no authentication at all, but if I don't support=20 >> name-based, I have to use something. >=20 > Ok, I understand. >=20 > The intention is to say that name-based authentication is used, if = possible. >=20 > Is the following more clear? >=20 > "If possible, MSRP endpoints MUST use name-based authentication. > If not possible, if the MSRP endpoints support a common = authentication=20 > mechanism, they MUST use that mechanism. If the MSRP endpoints = do not=20 > support such common authentication mechanism, they MUST try = fingerprint-based > authentication, which will succeed if there are no Middleboxes > present. If that also fails, the MSRP endpoints MUST either:" >=20 >=20 > --------------- >=20 > Thanks! >=20 > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Mon Sep 12 14:35:36 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1D221F8E22 for ; Mon, 12 Sep 2011 14:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jx6HEGceFAv for ; Mon, 12 Sep 2011 14:35:36 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0348821F8D2C for ; Mon, 12 Sep 2011 14:35:32 -0700 (PDT) Received: from dn3-227.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 p8CLbX99004540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Sep 2011 16:37:34 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 12 Sep 2011 16:37:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2011 21:35:36 -0000 On Sep 9, 2011, at 7:17 AM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >>>> -- 4.3, general (and 4.2 to some degree): >>>>=20 >>>> With all these heuristics to work around situations where=20 >>>> a peer does not signal cema support, I'm not sure why we need the = tag.=20 >>>> Is it just to signal the middlebox? >>>=20 >>> No, there are enpoint procedures which depend on the=20 >>> presence of the tag. For example, when the offerer receives=20 >>> an answer, it uses the tag in the procedure to determine=20 >>> whether a fallback to 4975 behavior is needed. >>=20 >> But only as a short cut, right? That is, of the answer does=20 >> not contain the msrp-cema tag, then the offerer has to check=20 >> a lot of other stuff to see if it's still okay to use CEMA.=20 >> We could almost have just said check all that stuff in the=20 >> first place. >=20 You quoted this but didn't comment--did you mean to ? >=20 > --------------- >=20 >=20 >>>> -- 5.1: >>>>=20 >>>> I still have a fundamental problem here. This entire work is=20 >>>> predicated on an assumption about SBC behavior. It's not=20 >>>> standardized, and we can't normatively require it. The best we can=20= >>>> hope for is that all SBC implementors read this spec and=20 >>>> the right thing. >>>>=20 >>>> I think that, in practice, many will not, and even if they do,=20 >>>> carriers will implement policies to prevent interop with peers not=20= >>>> implementing CEMA. Basically, this assumption promotes=20 >>>> walled gardens. >>>=20 >>>=20 >>> First, if carriers will prevent interop with peers not=20 >>> implementing CEMA (we can of course not prevent that), it is=20 >>> very likely that they already today prevent MSRP traffic. >>>=20 >>> Second, at least I am aware of customer requirements of=20 >>> interop with non-CEMA peers, and products that support it. >>=20 >> That sort of address my second comment. But saying we are=20 >> aware of middleboxes that follow these assumptions is not the=20 >> same as saying all do, or even most do. I think what we are=20 >> trying to do, in a round about way, is say "if you build your=20 >> middlebox like this, it will work with CEMA endpoints." It=20 >> seems like we are trying to define middlebox behavior in a=20 >> nudge-nudge sort of way without actually "officially" doing anything. >>=20 >> I think I could live with this if we add a bit more to the=20 >> applicability statement, along the lines of "This document=20 >> assumes certain middlebox behaviors as described in section=20 >> 5. These behaviors are not standardized, and CEMA may not=20 >> function properly with middleboxes that violate these=20 >> assumptions. Implementors and operators should consider=20 >> whether middleboxes in their networks are likely to behave=20 >> according to these assumptions before deploying CEMA." >=20 >=20 > A middlebox can either implement the CEMA assumptions, or it doesn't. = If it doesn't, in order for MSRP to work, it needs to always enable MSRP = B2BUA functionality. >=20 > =46rom a CEMA perspective both cases are fine, as CEMA defines a = fallback procedure. So, I don't think we should give a picture that, in = order for MSRP to work, middleboxes must implement CEMA. If they don't, = the CEMA extension won't of course be enabled, but things will still = work. >=20 > (If a middlebox does SOMETHING ELSE, MSRP won't work - with or without = CEMA - and I don't think we need to, or even can, say anything about = that.) >=20 > So, maybe something like: >=20 > "In order for MSRP endpoints to use the CEMA extension, this document = assumes certain middlebox behaviors, as described in section 5. However, = the document also defines a fallback mechanism in case a middlebox does = not support CEMA, and always enables MSRP B2BUA functionality for MSRP = calls." >=20 Except it really doesn't define a fallback mechanism in Middlebox = behavior, because it doesn't define _any_ middlebox behavior. There is a = subtle but critical distinction between "assuming" a behavior and = "defining" a behavior. We've been down this path before--for example, = the problems around defining STUN based on assumptions about NAT = behavior. I'd like to see something, probably in the applicability statement, to = the following effect: "This document assumes certain behaviors on the part of Middleboxes, as = described in section [XXX]. These behaviors are not standardized. If = Middleboxes do not behave as assumed, then the CEMA procedures are = likely to fail, or to add no value over base MSRP behavior." > --------------- >=20 >=20 >>>> --5.5, paragraph 1: "Middleboxes relay MSRP media packets >>>> at the transport layer." >>>>=20 >>>> That should be a top level assumption in itself. >>>=20 >>> Do you mean the text belongs somewhere else? >>=20 >> Not so much that as stating it as an assumption rather than a=20 >> fact. i.e. "This document assumes that middleboxes relay..." >=20 > Sure, but where do you want that text? Right where it is is fine. [=85] Thanks! Ben.= From ben@nostrum.com Mon Sep 12 14:36:45 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D8621F8E56 for ; Mon, 12 Sep 2011 14:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z90JAoz4ufBO for ; Mon, 12 Sep 2011 14:36:44 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6827721F8D65 for ; Mon, 12 Sep 2011 14:36:44 -0700 (PDT) Received: from dn3-227.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 p8CLcjgq004640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Sep 2011 16:38:46 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E85E8A@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 12 Sep 2011 16:38:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <84A5C34D-A75E-4331-8AF4-6FBBB09B98AC@nostrum.com> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85E8A@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2011 21:36:45 -0000 On Sep 9, 2011, at 7:24 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > I noted that I forgot to reply to one of your comments :) >=20 >>>>> -- 4.3, general (and 4.2 to some degree): >>>>>=20 >>>>> With all these heuristics to work around situations where a peer=20= >>>>> does not signal cema support, I'm not sure why we need the tag. >>>>> Is it just to signal the middlebox? >>>>=20 >>>> No, there are enpoint procedures which depend on the=20 >>>> presence of the=20 >>>> tag. For example, when the offerer receives an answer, it uses the=20= >>>> tag in the procedure to determine whether a fallback to=20 >>>> 4975 behavior is needed. >>>=20 >>> But only as a short cut, right? That is, of the answer does not=20 >>> contain the msrp-cema tag, then the offerer has to check a lot of=20 >>> other stuff to see if it's still okay to use CEMA. >>> We could almost have just said check all that stuff in the first=20 >>> place. >=20 > The offerer has to check things, but the anwserer also does things = depending on whether the offer contains the tag or not.=20 >=20 > An example is the error case change I suggested earlier (related to = your comment on bullet 4) in section 4.3), where a 488 response would be = sent. >=20 (Ah, that's the one I noticed was quoted but not commented on in the = other email.) Okay. >=20 > --------------- >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Mon Sep 12 15:18:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D13D21F8CFC for ; Mon, 12 Sep 2011 15:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXLA241RZ587 for ; Mon, 12 Sep 2011 15:18:48 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 37C6821F8564 for ; Mon, 12 Sep 2011 15:18:47 -0700 (PDT) Received: from dn3-227.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 p8CMKmIM010051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Sep 2011 17:20:51 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_A57C3C87-8082-411D-B747-597524688281" From: Ben Campbell In-Reply-To: Date: Mon, 12 Sep 2011 17:20:57 -0500 Message-Id: References: To: prasun bheri X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple@ietf.org Subject: Re: [Simple] Query on connection sharing. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2011 22:18:49 -0000 --Apple-Mail=_A57C3C87-8082-411D-B747-597524688281 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Prasun, See RFC4975, section 5.4, paragraph 1. If a second peer MSRP URI has the = same scheme, and resolves to the same IP address and port, as for an = existing session, then a user agent SHOULD reuse the the TCP connection = for the second session. Hope this helps! Ben. On Sep 12, 2011, at 5:20 AM, prasun bheri wrote: > Hi, >=20 > =20 > I have a scenario where my MSRP implementation is used by multiple = applications simultaneously, >=20 > so it supports multiple AOR's (Address of Records).=20 >=20 >=20 >=20 > in this case can two applications share the same tcp connection when = appropriate? >=20 >=20 >=20 > lets say >=20 > My app facilitates two AOR's A & B which are using same MSRP module.=20= >=20 > now A is connected to client C (C is located in another system) and = later B wants to connect to C,=20 >=20 > in this case can MSRP module share the existing tcp connection or = should it create a new tcp=20 >=20 > connection between B and C? >=20 >=20 >=20 > [Assuming all three clients are using simple TCP connection with out = any security] >=20 >=20 >=20 > Thanks in advance >=20 > Prasun >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_A57C3C87-8082-411D-B747-597524688281 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Hi Prasun,

See RFC4975, section 5.4, paragraph 1. If a second peer MSRP URI has the same scheme, and resolves to the same IP address and port, as for an existing session, then a user agent SHOULD reuse the the TCP connection for the second session.

Hope this helps!

Ben.

On Sep 12, 2011, at 5:20 AM, prasun bheri wrote:

Hi,

 

I have a scenario where my MSRP implementation is used by multiple applications simultaneously,

so it supports multiple AOR's (Address of Records). 


in this case can two applications share the same tcp connection when appropriate?


lets say

My app facilitates two AOR's A & B which are using same MSRP module. 

now A is connected to client C (C is located in another system) and later B wants to connect to C, 

in this case can MSRP module share the existing tcp connection or should it create a new tcp 

connection between B and C?


[Assuming all three clients are using simple TCP connection with out any security]


Thanks in advance

Prasun


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

--Apple-Mail=_A57C3C87-8082-411D-B747-597524688281-- From christer.holmberg@ericsson.com Tue Sep 13 00:07:53 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DCE21F899D for ; Tue, 13 Sep 2011 00:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcl2chJOkJk0 for ; Tue, 13 Sep 2011 00:07:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E746D21F884C for ; Tue, 13 Sep 2011 00:07:51 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-73-4e6f01c3803f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E1.81.02839.3C10F6E4; Tue, 13 Sep 2011 09:09:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 13 Sep 2011 09:09:55 +0200 From: Christer Holmberg To: Ben Campbell Date: Tue, 13 Sep 2011 09:09:54 +0200 Thread-Topic: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments Thread-Index: AcxxlDCOUjKSfey7ST+HYDlE6fRD3wATuIpw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDA9F0@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 07:07:53 -0000 Hi,=20 >>>>> -- 5.1: >>>>>=20 >>>>> I still have a fundamental problem here. This entire work is=20 >>>>> predicated on an assumption about SBC behavior. It's not=20 >>>>> standardized, and we can't normatively require it. The=20 >best we can=20 >>>>> hope for is that all SBC implementors read this spec and=20 >>>>> the right thing. >>>>>=20 >>>>> I think that, in practice, many will not, and even if they do,=20 >>>>> carriers will implement policies to prevent interop with=20 >>>>> peers not=20 >>>>> implementing CEMA. Basically, this assumption promotes=20 >>>>> walled gardens. >>>>=20 >>>>=20 >>>> First, if carriers will prevent interop with peers not=20 >>>> implementing CEMA (we can of course not prevent that), it is=20 >>>> very likely that they already today prevent MSRP traffic. >>>>=20 >>>> Second, at least I am aware of customer requirements of=20 >>>> interop with non-CEMA peers, and products that support it. >>>=20 >>> That sort of address my second comment. But saying we are=20 >>> aware of middleboxes that follow these assumptions is not the=20 >>> same as saying all do, or even most do. I think what we are=20 >>> trying to do, in a round about way, is say "if you build your=20 >>> middlebox like this, it will work with CEMA endpoints." It=20 >>> seems like we are trying to define middlebox behavior in a=20 >>> nudge-nudge sort of way without actually "officially"=20 >>> doing anything. >>>=20 >>> I think I could live with this if we add a bit more to the=20 >>> applicability statement, along the lines of "This document=20 >>> assumes certain middlebox behaviors as described in section=20 >>> 5. These behaviors are not standardized, and CEMA may not=20 >>> function properly with middleboxes that violate these=20 >>> assumptions. Implementors and operators should consider=20 >>> whether middleboxes in their networks are likely to behave=20 >>> according to these assumptions before deploying CEMA." >>=20 >>=20 >> A middlebox can either implement the CEMA assumptions, or=20 >> it doesn't. If it doesn't, in order for MSRP to work, it=20 >> needs to always enable MSRP B2BUA functionality. >>=20 >> From a CEMA perspective both cases are fine, as CEMA=20 >> defines a fallback procedure. So, I don't think we should=20 >> give a picture that, in order for MSRP to work, middleboxes=20 >> must implement CEMA. If they don't, the CEMA extension won't=20 >> of course be enabled, but things will still work. >>=20 >> (If a middlebox does SOMETHING ELSE, MSRP won't work - with=20 >> or without CEMA - and I don't think we need to, or even can,=20 >> say anything about that.) >>=20 >> So, maybe something like: >>=20 >> "In order for MSRP endpoints to use the CEMA extension,=20 >> this document assumes certain middlebox behaviors, as=20 >> described in section 5. However, the document also defines a=20 >> fallback mechanism in case a middlebox does not support CEMA,=20 >> and always enables MSRP B2BUA functionality for MSRP calls." >>=20 >=20 > Except it really doesn't define a fallback mechanism in=20 > Middlebox behavior, because it doesn't define _any_ middlebox=20 > behavior. There is a subtle but critical distinction between=20 > "assuming" a behavior and "defining" a behavior. We've been=20 > down this path before--for example, the problems around=20 > defining STUN based on assumptions about NAT behavior. >=20 > I'd like to see something, probably in the applicability=20 > statement, to the following effect: >=20 > "This document assumes certain behaviors on the part of=20 > Middleboxes, as described in section [XXX]. These behaviors=20 > are not standardized. If Middleboxes do not behave as=20 > assumed, then the CEMA procedures are likely to fail, or to=20 > add no value over base MSRP behavior." I don't like the "fail", wording, so what about: "This document assumes certain behaviors on the part of Middleboxes, as de= scribed in section [XXX].=20 These behaviors are not standardized. If Middleboxes do not behave as assu= med, then the CEMA extension does not add any value over base MSRP behavior. MSRP endpoints that suppor= t CEMA are required to use RFC 4975 behavior in cases where they detect that the CEMA extension c= annot be enabled."=20 Regards, Christer From christer.holmberg@ericsson.com Tue Sep 13 00:59:26 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C920021F8B86 for ; Tue, 13 Sep 2011 00:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hZPdvMh2XK3 for ; Tue, 13 Sep 2011 00:59:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A768621F8634 for ; Tue, 13 Sep 2011 00:59:25 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-27-4e6f0ddaec1d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 93.AB.02839.ADD0F6E4; Tue, 13 Sep 2011 10:01:30 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 13 Sep 2011 10:01:29 +0200 From: Christer Holmberg To: Ben Campbell Date: Tue, 13 Sep 2011 10:01:28 +0200 Thread-Topic: [Simple] CEMA: A couple of additional changes Thread-Index: AcxxkPOk06OWmAOiSX+W20C9YR1A4QAWbo/g Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDAA7F@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADED@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85BC6@ESESSCMS0356.eemea.ericsson.se> <291EC2AA-8CA6-44D4-B3B1-8077A4C8C014@nostrum.com> In-Reply-To: <291EC2AA-8CA6-44D4-B3B1-8077A4C8C014@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] CEMA: A couple of additional changes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 07:59:26 -0000 Hi,=20 >>>> Section 6.2 >>>> ----------- >>>>=20 >>>> Bullet 2 on TLS-PSK suggests the usage of with MICKEY-TICKET. >>>>=20 >>>> I think it would be good to make it a little more=20 >>>> flexible, by not=20 >>>> mandating MICKET-TICKET, but simply mention it as an example. >>>>=20 >>>> "2. TLS-PSK. For example, 3GPP has specified=20 >>>> the use of SDES (when=20 >>>> SIP transport is integrity protected) and MIKEY-TICKET for IMS." >>>=20 >>> If I recall, one of the big reasons for mentioning=20 >>> MIKEY-TICKET was=20 >>> that we believed it did not depend on e2e protection of=20 >>> the SDP. If we remove the mandate for MIKEY-TICKET, we might consider s= aying=20 >>> something to the effect of "TLS-PSK with a key-exchange mechanism=20 >>> that does not depend on end-to-end protection of the SDP. For=20 >>> example..." >>=20 >> The text before the bullets does talk about using a=20 >> mechanism that does not rely on peer-to-peer SDP integrity. >>=20 >> But, I have nothing against adding the text you suggest. >>=20 >=20 >Sorry, I guess I was reading statelessly. But, is the intent=20 >to say we RECOMMEND one of these two approaches, or we=20 >RECOMMEND anything that doesn't need e2e integrity? It seems=20 >like both at the moment, which is a little redundant. Personally I think it is better to recommend specific mechanisms, rather th= an some mechanism, so I would suggest the following, where one of the RECOM= MEND is removed: "If a Middlebox does not act as a TLS B2BUA, fingerprint based authentication will not work, as the "SIP Identity" based integrity protection of SDP will break. Therefore, in addition to the =09 authentication mechanisms defined in RFC 4975, it is RECOMMENDED=20 that a CEMA-enabled MSRP endpoint also supports one of the following authentication mechanisms, that do not rely on peer-to-peer SDP integri= ty: 1. TLS certificates together with support of interacting with a Certificate Management Service..." But, if you think it is better to simply recommend *A* mechanism that does = not rely on peer-to-peer SDP integrity, I can also modify the text accordin= gly. =20 Regards, Christer From christer.holmberg@ericsson.com Tue Sep 13 01:18:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E73521F8B6C for ; Tue, 13 Sep 2011 01:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHJrVrS0NHFI for ; Tue, 13 Sep 2011 01:18:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 23E3321F8802 for ; Tue, 13 Sep 2011 01:18:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-24-4e6f12521354 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D1.9F.02839.2521F6E4; Tue, 13 Sep 2011 10:20:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 13 Sep 2011 10:20:34 +0200 From: Christer Holmberg To: Ben Campbell Date: Tue, 13 Sep 2011 10:20:32 +0200 Thread-Topic: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments Thread-Index: AcxxkZ8JlbsNR0oCS3+vB7oQv93qHwAXAi7Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDAAB6@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233DD1251@ESESSCMS0356.eemea.ericsson.se> <53C3835E-CDE0-452D-90AE-26D77CC7E6CE@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E85C44@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 08:18:34 -0000 Hi,=20 > >>>> -- section 2, definition of "middle box": " A SIP network device=20 > >>>> that modifies SDP media address:port information in=20 > order to steer=20 > >>>> or anchor media flows described in the SDP, including=20 > TCP and TLS=20 > >>>> connections used for MSRP communication, through a media proxy=20 > >>>> function controlled by the SIP endpoint. " > >>>>=20 > >>>> Thats the usual definition of an SBC. Seems like we are=20 > using the=20 > >>>> term middlebox only for SBCs. Maybe we should just call=20 > it an SBC? > >>>> There are many types of middleboxes for which CEMA will=20 > not apply. > >>>=20 > >>> First, it is not only SBCs. Application Servers can also be=20 > >>> affected. > >>>=20 > >>> Second, we had a loooong discussion about the terminology, and=20 > >>> Middlebox was a compromise that people could live with,=20 > so I really=20 > >>> wouldn't like to have that discussion again.... > >>>=20 > >>> It is true that there are many types of middleboxes for=20 > which CEMA=20 > >>> will not apply, and that is why we have text talking=20 > about what is=20 > >>> the scope of a Middlebox in the draft. > >>> If you don't think that text is good enough, I'd rather try to=20 > >>> improve it rather than changing the terminology. > >>=20 > >> I can live with middlebox, I guess--but I think we either=20 > need some=20 > >> qualifier to make it clear from the beginning that we are=20 > not using=20 > >> the term in its usual sense (e.g CEMA middlebox), or we=20 > need text up=20 > >> front defining what we mean. > >> As it is, I can think of no generally used definition of middlebox=20 > >> that isn't much greater in scope (i.e. anything that=20 > relays packets)=20 > >> or much lower in scope (transport level policy boxes such=20 > as NATs and=20 > >> firewalls) > >>=20 > >> Currently, the term appears many time in the introduction,=20 > and even=20 > >> the abstract, prior to getting any definition of scope. I=20 > think many=20 > >> readers are going to read that and think to themselves=20 > "No, this is=20 > >> false--many middleboxes can work just fine without CEMA". > >=20 >> The text in the introduction talk about middleboxes in=20 >> general (we should use "m" instead of "M"). >=20 > The second paragraph of the intro is pretty much talking=20 > about Middleboxes as defined in this draft, not middleboxes=20 > in general. I think many readers are going to trip over this,=20 > as you have not yet said "In this draft, we use the term=20 > middlebox for something specific, and possibly different from=20 > what you've heard before" before we start talking about how=20 > Middleboxes work. In my opinion, the 2nd paragraph still talks about middleboxes in general, = and what they currently have to do in order to support MSRP. What about adding a "as defind in section XX [definitions section]" to the = last paragraph of the chapter: "This specification defines an MSRP extension, Connection Establishment = for Media=20 Anchoring (CEMA). CEMA in most cases allows MSRP endpoints to communicat= e through=20 middleboxes, as defined in section XX, without a need for the middleboxe= s to be a=20 MSRP B2BUA. In such cases, middleboxes, that want to anchor the MSRP con= nection simply=20 modify the SDP c/m-line address information, similar to what it does for= non-MSRP media=20 types. MSRP endpoints that support the CEMA extension will use the SDP c= /m-line address=20 information for establishing the TCP or TLS connection for sending and r= eceiving MSRP messages." >> Maybe we could use "CEMA Middlebox" elsewhere in the=20 >> document, to make it more clear that we are talking about an=20 >> entity that acts as described in the Assumptions section. >=20 >On reflection, I'm not sure CEMA middleboxes is the right=20 >choice, unless that's only used to mean SBC-like middleboxes=20 >that follow the assumptions in [assumption section]. My suggestion is to use "m" in the introduction chapter, and "M" where we r= efer to the Middlebox as defined in the draft. Regards, Christer From christer.holmberg@ericsson.com Tue Sep 13 03:43:06 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B5121F87D9 for ; Tue, 13 Sep 2011 03:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjgQR+1JDC-h for ; Tue, 13 Sep 2011 03:43:05 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEBA21F8551 for ; Tue, 13 Sep 2011 03:43:05 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-23-4e6f343627b1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 82.35.20773.6343F6E4; Tue, 13 Sep 2011 12:45:10 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 13 Sep 2011 12:45:10 +0200 From: Christer Holmberg To: Ben Campbell Date: Tue, 13 Sep 2011 12:45:08 +0200 Thread-Topic: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments Thread-Index: AcxufdLFNHIxf8C8TWWbygg1Af+vLADg+0kw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDAC33@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 10:43:06 -0000 Hi,=20 >>> -- section 4.1, list of use cases where CEMA does not apply: >>>=20 >>> These need elaboration. Why does CEMA not apply? Also, I would add=20 >>> "middle box used to provide topology hiding on the media channel,=20 >>> provide lawful intercept or other monitoring of content,=20 >>> or enforce content-related policy". to the list. >>=20 >> Yes, my intention was to provide more elaboration, but=20 >> forgot due to the missunderstandings associated with the=20 >> submitting of the -00 version. >>=20 >> So, the text would say something like: >>=20 >> "- A non-CEMA-enabled MSRP endpoint becomes "active", as=20 >> the endpoint will always establish the TCP or TLS connection=20 >> using the SDP a=3Dpath attribute, which contains the address=20 >> the remote MSRP endpoing, instead of the SDP c/m-line which=20 >> contains the address information of the Middlebox." >>=20 >> ...and similar for the other cases. >>=20 >>=20 >=20 >That helps, thanks! I suggest the following text: "In the following cases, where there is a Middlebox in the network, the= =20 CEMA extension can not be used, and there will be a fallback to the MSRP connection establishment procedures defined in RFC 4975 and=20 RFC 4976: - A non-CEMA-enabled MSRP endpoint becomes "active" (no matter whether = it uses a relay for its MSRP communication or not), as it will always establish= =20 the MSRP connection using the SDP a=3Dpath attribute, which contains th= e address=20 information of the remote MSRP endpoint, instead of using the SDP c/m-l= ine which contains=20 the address information of the Middlebox. - A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP commu= nication becomes "passive", as it can not be assumed that the MSRP endpoint inserts the = address=20 information of the relay in the SDP c/m-line. - A CEMA-enabled MSRP endpoint that uses a relay for its MSRP communica= tion becomes "active", since if it adds the received SDP c/m-line address information to the ToPath = header field of the MSRP message (in order for the relay to establish the MSRP connection towards the Middlebox), = the session matching performed by the remote=20 MSRP endpoint will fail." Regards, Christer From ben@nostrum.com Tue Sep 13 06:49:11 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1536621F8ADE for ; Tue, 13 Sep 2011 06:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-y1YeLTOh6J for ; Tue, 13 Sep 2011 06:49:10 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C87A21F8AE1 for ; Tue, 13 Sep 2011 06:49:09 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8DDpB84031258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Sep 2011 08:51:13 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDAA7F@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 13 Sep 2011 08:51:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADED@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85BC6@ESESSCMS0356.eemea.ericsson.se> <291EC2AA-8CA6-44D4-B3B1-8077A4C8C014@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDAA7F@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] CEMA: A couple of additional changes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 13:49:11 -0000 On Sep 13, 2011, at 3:01 AM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >>>>> Section 6.2 >>>>> ----------- >>>>>=20 >>>>> Bullet 2 on TLS-PSK suggests the usage of with MICKEY-TICKET. >>>>>=20 >>>>> I think it would be good to make it a little more=20 >>>>> flexible, by not=20 >>>>> mandating MICKET-TICKET, but simply mention it as an example. >>>>>=20 >>>>> "2. TLS-PSK. For example, 3GPP has specified=20 >>>>> the use of SDES (when=20 >>>>> SIP transport is integrity protected) and MIKEY-TICKET for IMS." >>>>=20 >>>> If I recall, one of the big reasons for mentioning=20 >>>> MIKEY-TICKET was=20 >>>> that we believed it did not depend on e2e protection of=20 >>>> the SDP. If we remove the mandate for MIKEY-TICKET, we might = consider saying=20 >>>> something to the effect of "TLS-PSK with a key-exchange mechanism=20= >>>> that does not depend on end-to-end protection of the SDP. For=20 >>>> example..." >>>=20 >>> The text before the bullets does talk about using a=20 >>> mechanism that does not rely on peer-to-peer SDP integrity. >>>=20 >>> But, I have nothing against adding the text you suggest. >>>=20 >>=20 >> Sorry, I guess I was reading statelessly. But, is the intent=20 >> to say we RECOMMEND one of these two approaches, or we=20 >> RECOMMEND anything that doesn't need e2e integrity? It seems=20 >> like both at the moment, which is a little redundant. >=20 > Personally I think it is better to recommend specific mechanisms, = rather than some mechanism, so I would suggest the following, where one = of the RECOMMEND is removed: >=20 > "If a Middlebox does not act as a TLS = B2BUA, fingerprint based > authentication will not work, as the = "SIP Identity" based integrity > protection of SDP will break. Therefore, = in addition to the =09 > authentication mechanisms defined in RFC = 4975, it is RECOMMENDED=20 > that a CEMA-enabled MSRP endpoint also = supports one of the following > authentication mechanisms, that do not = rely on peer-to-peer SDP integrity: >=20 > 1. TLS certificates together with = support of interacting with a > Certificate Management Service..." >=20 >=20 > But, if you think it is better to simply recommend *A* mechanism that = does not rely on peer-to-peer SDP integrity, I can also modify the text = accordingly. I'm okay either way, as long as it is consistent. >=20 > Regards, >=20 > Christer From ben@nostrum.com Tue Sep 13 10:19:17 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D0521F8C8E for ; Tue, 13 Sep 2011 10:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEjQ9QDvo--m for ; Tue, 13 Sep 2011 10:19:17 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 08C2E21F8C86 for ; Tue, 13 Sep 2011 10:19:16 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8DHLHb6058194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Sep 2011 12:21:21 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDA9F0@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 13 Sep 2011 12:21:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDA9F0@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 17:19:17 -0000 On Sep 13, 2011, at 2:09 AM, Christer Holmberg wrote: >> Except it really doesn't define a fallback mechanism in=20 >> Middlebox behavior, because it doesn't define _any_ middlebox=20 >> behavior. There is a subtle but critical distinction between=20 >> "assuming" a behavior and "defining" a behavior. We've been=20 >> down this path before--for example, the problems around=20 >> defining STUN based on assumptions about NAT behavior. >>=20 >> I'd like to see something, probably in the applicability=20 >> statement, to the following effect: >>=20 >> "This document assumes certain behaviors on the part of=20 >> Middleboxes, as described in section [XXX]. These behaviors=20 >> are not standardized. If Middleboxes do not behave as=20 >> assumed, then the CEMA procedures are likely to fail, or to=20 >> add no value over base MSRP behavior." >=20 > I don't like the "fail", wording, so what about: >=20 > "This document assumes certain behaviors on the part of = Middleboxes, as described in section [XXX].=20 > These behaviors are not standardized. If Middleboxes do not = behave as assumed, then the CEMA extension > does not add any value over base MSRP behavior. MSRP endpoints = that support CEMA are required to > use RFC 4975 behavior in cases where they detect that the CEMA = extension cannot be enabled."=20 I _think_ I'm okay with that. The question is, have we covered all the = cases where a middlebox assumption might be violated? It might be worth = adding some text sections 5.X about what happens if each assumption is = violated. I don't mean detail--just a sentence or two. Thinking of that also got me thinking about connection sharing issues. = We've got text indicating that a middlebox probably shouldn't try to = share connections. But we probably need some text somewhere (maybe = section 4) indicating that a CEMA endpoint that is not trying to use an = MSRP relay probably shouldn't try to share connections. Or maybe we just = need more precision around the section 5 connection sharing discussion. = This comes down to whether a middlebox would ever reuse the same IP = address and port for more than one session. Or whether the middlebox = identifies a flow by the full 5-tuple vs just it's own address and port. = If it uses the full 5 tuple, that depends on the endpoint using a = different port per session, or you might end up with two sessions = getting conflated at the middlebox. Along those lines, what happens if a non-CEMA peer tries to reuse a = connection? From christer.holmberg@ericsson.com Tue Sep 13 12:14:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AC621F8B81 for ; Tue, 13 Sep 2011 12:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMaeFlwsOhqq for ; Tue, 13 Sep 2011 12:14:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCC321F8B64 for ; Tue, 13 Sep 2011 12:14:34 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-39-4e6fac189c5d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7E.76.20773.81CAF6E4; Tue, 13 Sep 2011 21:16:40 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 13 Sep 2011 21:16:40 +0200 From: Christer Holmberg To: 'Ben Campbell' Date: Tue, 13 Sep 2011 21:16:38 +0200 Thread-Topic: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments Thread-Index: AcxyOY/A2VYFFstxRWiMxsEHX/+39QAD10iA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45F9C@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDA9F0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 19:14:35 -0000 Hi,=20 >>> Except it really doesn't define a fallback mechanism in Middlebox=20 >>> behavior, because it doesn't define _any_ middlebox behavior. There=20 >>> is a subtle but critical distinction between "assuming" a behavior=20 >>> and "defining" a behavior. We've been down this path before--for=20 >>> example, the problems around defining STUN based on assumptions about=20 >>> NAT behavior. >>>=20 >>> I'd like to see something, probably in the applicability statement,=20 >>> to the following effect: >>>=20 >>> "This document assumes certain behaviors on the part of Middleboxes,=20 >>> as described in section [XXX]. These behaviors are not standardized.=20 >>> If Middleboxes do not behave as assumed, then the CEMA procedures are=20 >>> likely to fail, or to add no value over base MSRP behavior." >>=20 >> I don't like the "fail", wording, so what about: >>=20 >> "This document assumes certain behaviors on the part of Middleboxes, as= described in section [XXX].=20 >> These behaviors are not standardized. If Middleboxes do not behave as a= ssumed, then the CEMA extension >> does not add any value over base MSRP behavior. MSRP endpoints that sup= port CEMA are required to >> use RFC 4975 behavior in cases where they detect that the CEMA extensio= n cannot be enabled."=20 > >I _think_ I'm okay with that. The question is, have we covered all the cas= es where a middlebox assumption might be violated? It might be worth adding= some text sections 5.X about what happens if each assumption is violated. = I don't=20 >mean detail--just a sentence or two. Well, I am not really sure what to write. The assumption sections already s= ay WHY the assumptions need to be done. >Thinking of that also got me thinking about connection sharing issues. We'= ve got text indicating that a middlebox probably shouldn't try to share con= nections. But we probably need some text somewhere (maybe section 4) indica= ting that=20 >a CEMA endpoint that is not trying to use an MSRP relay probably shouldn't= try to share connections. Or maybe we just need more precision around the = section 5 connection sharing discussion. This comes down to whether a middl= ebox=20 >would ever reuse the same IP address and port for more than one session. O= r whether the middlebox identifies a flow by the full 5-tuple vs just it's = own address and port. If it uses the full 5 tuple, that depends on the endp= oint=20 >using a different port per session, or you might end up with two sessions = getting conflated at the middlebox. > >Along those lines, what happens if a non-CEMA peer tries to reuse a connec= tion? I am not sure I follow. If the Middlebox assigns a unique address:port combination for each session= (which is an assumption), it won't happen. Regards, Christer From ben@nostrum.com Tue Sep 13 12:30:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB0821F8BEB for ; Tue, 13 Sep 2011 12:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbmXeSXv5Cma for ; Tue, 13 Sep 2011 12:30:01 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED621F8BDE for ; Tue, 13 Sep 2011 12:30:01 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8DJW47O074938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Sep 2011 14:32:05 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45F9C@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 13 Sep 2011 14:32:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <53955680-77B3-4E3E-8BA1-C26B5F0A8EA4@nostrum.com> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDA9F0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233D45F9C@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 19:30:02 -0000 On Sep 13, 2011, at 2:16 PM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >>>> Except it really doesn't define a fallback mechanism in Middlebox=20= >>>> behavior, because it doesn't define _any_ middlebox behavior. There=20= >>>> is a subtle but critical distinction between "assuming" a behavior=20= >>>> and "defining" a behavior. We've been down this path before--for=20 >>>> example, the problems around defining STUN based on assumptions = about=20 >>>> NAT behavior. >>>>=20 >>>> I'd like to see something, probably in the applicability statement,=20= >>>> to the following effect: >>>>=20 >>>> "This document assumes certain behaviors on the part of = Middleboxes,=20 >>>> as described in section [XXX]. These behaviors are not = standardized.=20 >>>> If Middleboxes do not behave as assumed, then the CEMA procedures = are=20 >>>> likely to fail, or to add no value over base MSRP behavior." >>>=20 >>> I don't like the "fail", wording, so what about: >>>=20 >>> "This document assumes certain behaviors on the part of = Middleboxes, as described in section [XXX].=20 >>> These behaviors are not standardized. If Middleboxes do not = behave as assumed, then the CEMA extension >>> does not add any value over base MSRP behavior. MSRP endpoints = that support CEMA are required to >>> use RFC 4975 behavior in cases where they detect that the CEMA = extension cannot be enabled."=20 >>=20 >> I _think_ I'm okay with that. The question is, have we covered all = the cases where a middlebox assumption might be violated? It might be = worth adding some text sections 5.X about what happens if each = assumption is violated. I don't=20 >> mean detail--just a sentence or two. >=20 > Well, I am not really sure what to write. The assumption sections = already say WHY the assumptions need to be done. For example: -- in 5.2: If the middlebox does not implement the MSRP b2bua function, = or does not fall back to it when no msrp-cema tag is present, CEMA = endpoints will is some cases be unable to interoperate with non-CEMA = endpoints across the middlebox. -- 5.3: If the middlebox does not assign a unique address and port = combination to each session, and does not parse MSRP messages, it may = forward messages to the wrong destination. -- 5.4 If the middlebox is unable to modify SDP payloads due to = end-to-end integrity protection, the middlebox will be either unable to = anchor media for MSRP sessions, or the SIP signaling may fail due to = integrity violations. =20 (I think 5.5 is covered in the security considerations)=20 >=20 >> Thinking of that also got me thinking about connection sharing = issues. We've got text indicating that a middlebox probably shouldn't = try to share connections. But we probably need some text somewhere = (maybe section 4) indicating that=20 >> a CEMA endpoint that is not trying to use an MSRP relay probably = shouldn't try to share connections. Or maybe we just need more precision = around the section 5 connection sharing discussion. This comes down to = whether a middlebox=20 >> would ever reuse the same IP address and port for more than one = session. Or whether the middlebox identifies a flow by the full 5-tuple = vs just it's own address and port. If it uses the full 5 tuple, that = depends on the endpoint=20 >> using a different port per session, or you might end up with two = sessions getting conflated at the middlebox. >>=20 >> Along those lines, what happens if a non-CEMA peer tries to reuse a = connection? >=20 > I am not sure I follow. >=20 > If the Middlebox assigns a unique address:port combination for each = session (which is an assumption), it won't happen. Sorry, you are correct. I incorrectly remembered the section talking = only about not sharing connections, but you are correct it explicitly = talks about unique address-port combos. >=20 > Regards, >=20 > Christer >=20 >=20 From christer.holmberg@ericsson.com Tue Sep 13 12:39:28 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F214111E80AD for ; Tue, 13 Sep 2011 12:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gfAzWLEZbmI for ; Tue, 13 Sep 2011 12:39:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9521F8C60 for ; Tue, 13 Sep 2011 12:39:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-75-4e6fb1ed46e3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F5.E7.20773.DE1BF6E4; Tue, 13 Sep 2011 21:41:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 13 Sep 2011 21:41:33 +0200 From: Christer Holmberg To: 'Ben Campbell' Date: Tue, 13 Sep 2011 21:41:32 +0200 Thread-Topic: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments Thread-Index: AcxyS9NowTivmAsqTHyyB8kfPuPyTAAALh9g Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45F9E@ESESSCMS0356.eemea.ericsson.se> References: <2DB5C7EF-90C5-4018-8D8F-4493E8977F7E@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233E3ADC6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233E85E79@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDA9F0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233D45F9C@ESESSCMS0356.eemea.ericsson.se> <53955680-77B3-4E3E-8BA1-C26B5F0A8EA4@nostrum.com> In-Reply-To: <53955680-77B3-4E3E-8BA1-C26B5F0A8EA4@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 19:39:29 -0000 Hi,=20 >>> I _think_ I'm okay with that. The question is, have we covered all=20 >>> the cases where a middlebox assumption might be violated? It might be w= orth adding some text sections >>> 5.X about what happens if each assumption is violated. I don't mean det= ail--just a sentence or two. >>=20 >> Well, I am not really sure what to write. The assumption sections alread= y say WHY the assumptions need to be done. > >For example: > >-- in 5.2: If the middlebox does not implement the MSRP b2bua function, or= does not fall back to it when no msrp-cema=20 >tag is present, CEMA endpoints will is some cases be unable to interoperat= e with non-CEMA endpoints across the middlebox. > >-- 5.3: If the middlebox does not assign a unique address and port combina= tion to each session, and does not parse=20 >MSRP messages, it may forward messages to the wrong destination. > >-- 5.4 If the middlebox is unable to modify SDP payloads due to end-to-end= integrity protection, the middlebox will be=20 >either unable to anchor media for MSRP sessions, or the SIP signaling may = fail due to integrity violations. > >(I think 5.5 is covered in the security considerations)=20 Ok, now I understand. I can add such text. Regards, Christer From internet-drafts@ietf.org Tue Sep 13 22:32:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B87F21F8C68; Tue, 13 Sep 2011 22:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52pbmt+ZMofJ; Tue, 13 Sep 2011 22:32:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189EB21F8B6E; Tue, 13 Sep 2011 22:32:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914053233.18590.88676.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 22:32:33 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-msrp-cema-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 05:32:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Connection Establishment for Media Anchoring (CEMA) for = the Message Session Relay Protocol (MSRP) Author(s) : Christer Holmberg Staffan Blau Eric Burger Filename : draft-ietf-simple-msrp-cema-02.txt Pages : 17 Date : 2011-09-13 This document defines an Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is optional. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages, and thus also enables a secure end-to-end MSRP communication in networks where such middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, a=3Dmsrp-cema, that MSRP endpoints use to indicate support of the CEMA extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-02.txt From christer.holmberg@ericsson.com Tue Sep 13 22:33:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBFD21F8C68 for ; Tue, 13 Sep 2011 22:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+wE-VBxvh-5 for ; Tue, 13 Sep 2011 22:33:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2621F8C6B for ; Tue, 13 Sep 2011 22:33:22 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e2-4e703d20c815 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 53.3C.20773.02D307E4; Wed, 14 Sep 2011 07:35:28 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 14 Sep 2011 07:35:28 +0200 From: Christer Holmberg To: Simple WG Date: Wed, 14 Sep 2011 07:35:27 +0200 Thread-Topic: Draft new version: draft-ietf-simple-msrp-cema-02 Thread-Index: AcxyoBujDUBxskD6RRGZssszUQrXaA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDAFE4@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852233EDAFE4ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Draft new version: draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 05:33:23 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852233EDAFE4ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on Ben's comments, I've submitted a new version (-02) of the CEMA dra= ft. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852233EDAFE4ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Based on Ben's comments, I've submitted a new version= (-02) of the CEMA draft.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852233EDAFE4ESESSCMS0356e_-- From ben@nostrum.com Wed Sep 14 14:20:26 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9E21F8CCB for ; Wed, 14 Sep 2011 14:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7OzfLbuB6Sy for ; Wed, 14 Sep 2011 14:20:25 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B9FB821F8CC4 for ; Wed, 14 Sep 2011 14:20:23 -0700 (PDT) Received: from dn3-227.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 p8ELMJpI073762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Sep 2011 16:22:32 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Sep 2011 16:22:24 -0500 Message-Id: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org Subject: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 21:20:26 -0000 This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 The WGLC will conclude on 29 September 2011. Please send your comments, = including nits and "this is ready to go" type comments, to the authors = and the working group mail list. Thanks! Ben. From internet-drafts@ietf.org Tue Sep 20 01:46:45 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30E221F84FB; Tue, 20 Sep 2011 01:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZfPrxYr9uSB; Tue, 20 Sep 2011 01:46:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928F121F845B; Tue, 20 Sep 2011 01:46:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110920084640.30884.68827.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2011 01:46:40 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-chat-10.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2011 08:46:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Multi-party Chat Using the Message Session Relay Protoco= l (MSRP) Author(s) : Aki Niemi Miguel A. Garcia-Martin Geir A. Sandbakken Filename : draft-ietf-simple-chat-10.txt Pages : 32 Date : 2011-09-20 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-chat-10.txt From miguel.a.garcia@ericsson.com Tue Sep 20 03:31:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1700821F8BBF for ; Tue, 20 Sep 2011 03:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWAJjK16dG6W for ; Tue, 20 Sep 2011 03:31:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 433AC21F8B8B for ; Tue, 20 Sep 2011 03:31:34 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-7b-4e786c17b702 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 53.D3.20773.71C687E4; Tue, 20 Sep 2011 12:33:59 +0200 (CEST) Received: from [159.107.24.242] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 12:33:58 +0200 Message-ID: <4E786C16.9050901@ericsson.com> Date: Tue, 20 Sep 2011 12:33:58 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Simple] New version of draft-ietf-simple-chat-10.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2011 10:31:35 -0000 Hi, We have submitted a new version of the MSRP chat draft. The only change is due to an update of the reference to XMPP (now RFC 6120). http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ag@ag-projects.com Tue Sep 20 03:37:00 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625BD21F8562 for ; Tue, 20 Sep 2011 03:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc7Gfd9-XVRd for ; Tue, 20 Sep 2011 03:36:59 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCB821F8558 for ; Tue, 20 Sep 2011 03:36:59 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 80F95B01B6; Tue, 20 Sep 2011 12:39:24 +0200 (CEST) Received: from [192.168.1.6] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id B1217B0057; Tue, 20 Sep 2011 12:39:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <4E786C16.9050901@ericsson.com> Date: Tue, 20 Sep 2011 12:39:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F540D6E-DF9B-4499-9DF7-DDEB16A248C5@ag-projects.com> References: <4E786C16.9050901@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] New version of draft-ietf-simple-chat-10.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2011 10:37:00 -0000 Hi Miquel, Functionality from this draft has been implemented in SylkServer under = an open source license=20 http://sylkserver.com/ We will be present at SIPIT 29 in Monaco, should anyone on this list be = interested to test. Regards, Adrian On Sep 20, 2011, at 12:33 PM, Miguel A. Garcia wrote: > Hi, >=20 > We have submitted a new version of the MSRP chat draft. The only = change is due to an update of the reference to XMPP (now RFC 6120). >=20 > http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ >=20 > /Miguel > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ben@nostrum.com Tue Sep 20 06:42:24 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578D121F8BF8 for ; Tue, 20 Sep 2011 06:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibVV1w95eOS1 for ; Tue, 20 Sep 2011 06:42:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B1C6921F8BBF for ; Tue, 20 Sep 2011 06:42:23 -0700 (PDT) Received: from [10.0.1.19] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8KDikuT049142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Sep 2011 08:44:47 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4E786C16.9050901@ericsson.com> Date: Tue, 20 Sep 2011 08:44:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF36F26-B364-44FF-BF03-69F1DCFBD471@nostrum.com> References: <4E786C16.9050901@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] New version of draft-ietf-simple-chat-10.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2011 13:42:24 -0000 Thanks, Miguel. This is the version we will pubreq. On Sep 20, 2011, at 5:33 AM, Miguel A. Garcia wrote: > Hi, >=20 > We have submitted a new version of the MSRP chat draft. The only = change is due to an update of the reference to XMPP (now RFC 6120). >=20 > http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ >=20 > /Miguel > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Tue Sep 20 07:01:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9586C21F8C2B for ; Tue, 20 Sep 2011 07:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3daTnT4Lird for ; Tue, 20 Sep 2011 07:01:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2576421F8BF3 for ; Tue, 20 Sep 2011 07:01:33 -0700 (PDT) Received: from [10.0.1.19] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8KE3xdM051665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Sep 2011 09:03:59 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <2DF36F26-B364-44FF-BF03-69F1DCFBD471@nostrum.com> Date: Tue, 20 Sep 2011 09:04:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9CD0664B-A625-4141-AADD-FA540F67433E@nostrum.com> References: <4E786C16.9050901@ericsson.com> <2DF36F26-B364-44FF-BF03-69F1DCFBD471@nostrum.com> To: Simple WG X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: draft-ietf-simple-chat.all@tools.ietf.org Subject: Re: [Simple] New version of draft-ietf-simple-chat-10.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2011 14:01:34 -0000 Okay, I spoke too soon. _Hopefully_ this is the version we will pubreq. = But since it contains an SDP extension, we are requesting an SDP review = from MMUSIC prior to requesting publication. Thanks! Bne. On Sep 20, 2011, at 8:44 AM, Ben Campbell wrote: > Thanks, Miguel. This is the version we will pubreq. >=20 > On Sep 20, 2011, at 5:33 AM, Miguel A. Garcia wrote: >=20 >> Hi, >>=20 >> We have submitted a new version of the MSRP chat draft. The only = change is due to an update of the reference to XMPP (now RFC 6120). >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ >>=20 >> /Miguel >> --=20 >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 From HKaplan@acmepacket.com Tue Sep 20 13:27:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDB611E80D0 for ; Tue, 20 Sep 2011 13:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZFn6tg9z0P3 for ; Tue, 20 Sep 2011 13:27:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9411E80C2 for ; Tue, 20 Sep 2011 13:27:25 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Sep 2011 16:29:51 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 16:29:51 -0400 From: Hadriel Kaplan To: Ben Campbell Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 Thread-Index: AQHMd9QLBG5SDAr0QrmE+whIuf8L7A== Date: Tue, 20 Sep 2011 20:29:50 +0000 Message-ID: References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> In-Reply-To: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <42CF95FD3840F9438656E4D586964A1A@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2011 20:27:26 -0000 This is ready to go. -hadriel On Sep 14, 2011, at 5:22 PM, Ben Campbell wrote: > This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >=20 > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >=20 > The WGLC will conclude on 29 September 2011. Please send your comments, i= ncluding nits and "this is ready to go" type comments, to the authors and t= he working group mail list. >=20 > Thanks! >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From md3135@att.com Tue Sep 20 13:32:04 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4711F0C7F for ; Tue, 20 Sep 2011 13:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2o-bfnhJtIR for ; Tue, 20 Sep 2011 13:32:03 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8AF1F0C5D for ; Tue, 20 Sep 2011 13:32:02 -0700 (PDT) X-Env-Sender: md3135@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1316550867!39273249!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1029 invoked from network); 20 Sep 2011 20:34:28 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2011 20:34:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8KKYsdC008234; Tue, 20 Sep 2011 16:34:54 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8KKYkTP008101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Sep 2011 16:34:47 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.142]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0289.001; Tue, 20 Sep 2011 16:34:19 -0400 From: "DOLLY, MARTIN C" To: "'HKaplan@acmepacket.com'" , "'ben@nostrum.com'" Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 Thread-Index: AQHMd9QLBG5SDAr0QrmE+whIuf8L7JVWubBD Date: Tue, 20 Sep 2011 20:34:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.151.223.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'draft-ietf-simple-msrp-cema.all@tools.ietf.org'" , "'simple@ietf.org'" Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2011 20:32:04 -0000 +1 Martin C. Dolly Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink = Possible. +1.609.903.3360 ----- Original Message ----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Tuesday, September 20, 2011 04:29 PM=0A= To: Ben Campbell Cc: ; Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 This is ready to go. -hadriel On Sep 14, 2011, at 5:22 PM, Ben Campbell wrote: > This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >=20 > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >=20 > The WGLC will conclude on 29 September 2011. Please send your comments, i= ncluding nits and "this is ready to go" type comments, to the authors and t= he working group mail list. >=20 > Thanks! >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From nancy.greene@ericsson.com Tue Sep 20 13:35:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812551F0C82 for ; Tue, 20 Sep 2011 13:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKZPpX6Emhib for ; Tue, 20 Sep 2011 13:35:25 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id ED0EA1F0C5D for ; Tue, 20 Sep 2011 13:35:24 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8KKbUiu012097; Tue, 20 Sep 2011 15:37:46 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 20 Sep 2011 16:37:37 -0400 From: Nancy Greene To: Simple WG , Christer Holmberg Date: Tue, 20 Sep 2011 16:37:36 -0400 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 Thread-Index: AcxzJHaT3RKE8RSnS3iQD5RjFOTAuAEqkdmQ Message-ID: References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> In-Reply-To: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2011 20:35:25 -0000 This version looks good and ready to go. Just a few editorial comments: - section 4.1 2nd paragraph, s/can not/cannot - section 4.4, 2nd sentence, s/a MSRP/an MSRP/=20 - section 5.5, 2nd paragraph, s/When UAs fallback/When UAs fall back/ - section 6.2, 3rd paragraph, use of subjunctive means it should be also su= pport, not also supports: s/RECOMMENDED that a CEMA-enabled MSRP endpoint a= lso supports one/RECOMMENDED that a CEMA-enabled MSRP endpoint also support= one/=20 - section 6.2, in the paragraph before the NOTE at the end of the section, = s/depending on local policy chose/depending on local policy choose/ - section 6.2 in the NOTE just before section 6.3: s/the user need to be ab= le/the user needs to be able/ - section 6.2 in the NOTE just before section 6.3: s/try to anyway establis= h/try anyway to establish/ Nancy -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Ben Campbell Sent: September-14-11 5:22 PM To: Simple WG Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org Subject: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 The WGLC will conclude on 29 September 2011. Please send your comments, inc= luding nits and "this is ready to go" type comments, to the authors and the= working group mail list. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue Sep 20 22:51:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A2D21F8CB3 for ; Tue, 20 Sep 2011 22:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzYbcWXDcmeQ for ; Tue, 20 Sep 2011 22:51:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 67FAC21F8CB2 for ; Tue, 20 Sep 2011 22:51:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-17-4e797beebee5 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 52.77.02839.EEB797E4; Wed, 21 Sep 2011 07:53:50 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 21 Sep 2011 07:53:50 +0200 From: Christer Holmberg To: Nancy Greene , Simple WG Date: Wed, 21 Sep 2011 07:53:45 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 Thread-Index: AcxzJHaT3RKE8RSnS3iQD5RjFOTAuAEqkdmQABT8WjA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F6F4CD@ESESSCMS0356.eemea.ericsson.se> References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2011 05:51:25 -0000 Hi Nancy, Thanks for your comments! I'll modify the text according to your suggestion= s. Regards, Christer=20 > -----Original Message----- > From: Nancy Greene=20 > Sent: 20. syyskuuta 2011 23:38 > To: Simple WG; Christer Holmberg > Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org; Ben Campbell > Subject: RE: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 >=20 >=20 > This version looks good and ready to go. >=20 > Just a few editorial comments: > - section 4.1 2nd paragraph, s/can not/cannot > - section 4.4, 2nd sentence, s/a MSRP/an MSRP/ > - section 5.5, 2nd paragraph, s/When UAs fallback/When UAs fall back/ > - section 6.2, 3rd paragraph, use of subjunctive means it=20 > should be also support, not also supports: s/RECOMMENDED that=20 > a CEMA-enabled MSRP endpoint also supports one/RECOMMENDED=20 > that a CEMA-enabled MSRP endpoint also support one/ > - section 6.2, in the paragraph before the NOTE at the end of=20 > the section, s/depending on local policy chose/depending on=20 > local policy choose/ > - section 6.2 in the NOTE just before section 6.3: s/the user=20 > need to be able/the user needs to be able/ > - section 6.2 in the NOTE just before section 6.3: s/try to=20 > anyway establish/try anyway to establish/ >=20 > Nancy >=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: September-14-11 5:22 PM > To: Simple WG > Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org > Subject: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 >=20 > This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >=20 > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >=20 > The WGLC will conclude on 29 September 2011. Please send your=20 > comments, including nits and "this is ready to go" type=20 > comments, to the authors and the working group mail list. >=20 > Thanks! >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = From saul@ag-projects.com Wed Sep 21 00:27:11 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BAF21F8B72 for ; Wed, 21 Sep 2011 00:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBcG5HN-+yKK for ; Wed, 21 Sep 2011 00:27:10 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5181F21F8AB8 for ; Wed, 21 Sep 2011 00:27:10 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 0438BB01B6; Wed, 21 Sep 2011 09:29:37 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 40D1AB019A; Wed, 21 Sep 2011 09:29:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> Date: Wed, 21 Sep 2011 09:29:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90C36F01-608F-40DA-899C-A5723CDED292@ag-projects.com> References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org, Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2011 07:27:11 -0000 Hi, On Sep 14, 2011, at 11:22 PM, Ben Campbell wrote: > This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >=20 > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >=20 > The WGLC will conclude on 29 September 2011. Please send your = comments, including nits and "this is ready to go" type comments, to the = authors and the working group mail list. >=20 Section 5.2: s/will is some cases/will in some cases/ This last version looks fine to me. The only concern I have is the fact = that the MSRP B2BUA functionality is not strictly mandated. Section 5.2 = says that "CEMA-enabled MSRP endpoints will is some cases be unable to = interoperate with non-CEMA-enabled endpoints across the Middlebox.". = which I find too optimistic. Chances of that connection working are = close to none IIRC. I know that we are making some assumptions in what Middleboxes may or = may not do, but can we say that "if a Middlebox needs to anchor MSRP = media it MUST implement B2BUA functionality" ? Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed Sep 21 01:29:47 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659BF21F8C4A for ; Wed, 21 Sep 2011 01:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuI9SaXF0xhC for ; Wed, 21 Sep 2011 01:29:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBFC21F8C1A for ; Wed, 21 Sep 2011 01:29:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-30-4e79a10d6682 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6A.B3.02839.D01A97E4; Wed, 21 Sep 2011 10:32:14 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 21 Sep 2011 10:32:14 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , Ben Campbell Date: Wed, 21 Sep 2011 10:32:12 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 Thread-Index: Acx4MDrmukr99N/7TKCzivj6l34qnwAB+H/w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F6F662@ESESSCMS0356.eemea.ericsson.se> References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> <90C36F01-608F-40DA-899C-A5723CDED292@ag-projects.com> In-Reply-To: <90C36F01-608F-40DA-899C-A5723CDED292@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2011 08:29:47 -0000 Hi Saul,=20 >> This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >>=20 >> http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >>=20 >> The WGLC will conclude on 29 September 2011. Please send=20 >> your comments, including nits and "this is ready to go" type=20 >> comments, to the authors and the working group mail list. >>=20 >=20 > Section 5.2: s/will is some cases/will in some cases/ I'll fix that as suggested. >This last version looks fine to me. The only concern I have=20 >is the fact that the MSRP B2BUA functionality is not strictly=20 >mandated. Section 5.2 says that "CEMA-enabled MSRP endpoints=20 >will is some cases be unable to interoperate with=20 >non-CEMA-enabled endpoints across the Middlebox.". which I=20 >find too optimistic. Chances of that connection working are=20 >close to none IIRC. >=20 >I know that we are making some assumptions in what=20 >Middleboxes may or may not do, but can we say that "if a=20 >Middlebox needs to anchor MSRP media it MUST implement B2BUA=20 >functionality" ? I personally would have no problem with that, but we have a decision that w= e cannot mandate Middlebox behavior - only make "assumptions" - and I would= not like to re-open that discussion. Section 5.2 does say: "In order to support interoperability between UAs that support the CEMA extension and UAs that do not support the extension, the Middlebox is MSRP aware. This means that it implements MSRP B2BUA functionality." And, whatever MUSTs we would add, at the end of the day the vendor and cust= omer will decide what is implemented and deployed. And, as I've said before= , from my experience customers DO require interoperability with non-CEMA cl= ients, and the products I am aware of DO support MSRP B2BUA functionality. Regards, Christer From christian.1.schmidt@nsn.com Thu Sep 22 01:44:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A96621F8593 for ; Thu, 22 Sep 2011 01:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.976 X-Spam-Level: X-Spam-Status: No, score=-4.976 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGabVwWld+Mt for ; Thu, 22 Sep 2011 01:44:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 144D521F8548 for ; Thu, 22 Sep 2011 01:44:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8M8kTLt028498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 10:46:29 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8M8kMpL018355; Thu, 22 Sep 2011 10:46:29 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Sep 2011 10:46:28 +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, 22 Sep 2011 10:46:27 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 Thread-Index: AQHMd9QLBG5SDAr0QrmE+whIuf8L7JVZAaWQ References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "Ben Campbell" , "ext Christer Holmberg" X-OriginalArrivalTime: 22 Sep 2011 08:46:28.0242 (UTC) FILETIME=[1E51F720:01CC7904] Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org, Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2011 08:44:02 -0000 After some minor clarifications and improvements, this ID is ready to go forward. Servus Christian 4.2 MSRP Offer Procedures 3. If the MSRP endpoint is using a relay for MSRP communication, it MUST include the address information of the relay (the MSRP URI of the topmost SDP a=3Dpath attribute), rather than the address information of itself, in the SDP c/m-line associated with the MSRP media description.... =20 This description is a bit unclear to me. It looks like that only m/c line Would be modified. What about the following proposal: 3. If the MSRP endpoint is using a relay for MSRP communication, it MUST add the address information of the relay to the a=3Dpath attributes=20 (the MSRP URI of the topmost SDP a=3Dpath attribute) and use the address Information of the relay (instead of the own address information)=20 in the SDP c/m-line associated with the MSRP media description.... Same proposal for 4.3 MRSP Answerer Procedures 3. If the MSRP endpoint is using a relay for MSRP communication, it MUST include the address information on the relay (the MSRP URI of the topmost SDP a=3Dpath attribute), rather than the address information of itself, in the SDP c/m-line associated with the MSRP media description... New Version: 3. If the MSRP endpoint is using a relay for MSRP communication, it MUST add the address information of the relay to the a=3Dpath attributes=20 (the MSRP URI of the topmost SDP a=3Dpath attribute) and use the address Information of the relay (instead of the own address information)=20 in the SDP c/m-line associated with the MSRP media description.... General Remark: Especially Section 4 is a bit difficult to read. In 4.2 MSRP Offer Procedures the MSRP endpoint is the MSRP offerer and the remote MSRP endpoint is the MSRP answerer. In 4.3 MSRP Answer Procedures the MSRP endpoint is the MSRP answerer and the remote MSRP endpoint is the MSRP offerer. That confusing for the reader. Why not replace MSRP endpoint and MSRP remote endpoint with MSRP offerer and MSRP answerer in all reasonable cases? 4.2 MSRP Offer Procedures NOTE: As described in section 5, in the absence of the SDP a=3Dmsrp- cema attribute in the new offer, it is assumed that a Middlebox will act as an MSRP B2BUA in order to anchor MSRP media. Does this mean, a Middlebox would have to remove the SDP a=3Dmsrp-cema attribute from an offer, if it provides MSRP B2BUA function? At lease this description is missing in section 5. The MSRP endpoint MAY choose to terminate the session establishment if it can detect that a Middlebox acting as a MSRP B2BUA is not the desired remote endpoint. How is this related or relevant for CEMA?=20 The MSRP endpoint can send the new offer within the existing early dialog [RFC3261], or it can terminate the early dialog and establish a new dialog by sending the new offer in a new initial INVITE request. If this are the possible reactions on the detection of a Middlebox, the two Paragraphs should be combined. 1. Introduction Since the active MSRP UA establishes the MSRP TCP or TLS connection based on the MSRP URI of the SDP a=3Dpath attribute, this means that the MSRP connection will not, unless the middlebox also modifies the MSRP URI of the topmost SDP a=3Dpath attribute, be routed through the middlebox. The sentence look a bit strange. What about the following proposal: An active MSRP UA establishes the MSRP TCP or TLS connection based on the MSRP URI of the SDP a=3Dpath attribute. This means that the = MSRP connection will not be routed through the middlebox, unless the middlebox also modifies the MSRP URI of the topmost SDP a=3Dpath attribute. -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Hadriel Kaplan Sent: Dienstag, 20. September 2011 22:30 To: Ben Campbell Cc: ; Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 This is ready to go. -hadriel On Sep 14, 2011, at 5:22 PM, Ben Campbell wrote: > This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >=20 > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >=20 > The WGLC will conclude on 29 September 2011. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group mail list. >=20 > Thanks! >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Thu Sep 22 05:33:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CC721F8BAC for ; Thu, 22 Sep 2011 05:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h2zduvf-xAx for ; Thu, 22 Sep 2011 05:33:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 89EF821F8B6D for ; Thu, 22 Sep 2011 05:33:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-13-4e7b2bcc503c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4E.9C.20773.CCB2B7E4; Thu, 22 Sep 2011 14:36:28 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 22 Sep 2011 14:36:28 +0200 From: Christer Holmberg To: "Schmidt, Christian 1. (NSN - DE/Munich)" , Ben Campbell Date: Thu, 22 Sep 2011 14:36:26 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 - Christian's comments Thread-Index: AQHMd9QLBG5SDAr0QrmE+whIuf8L7JVZAaWQgABGb3A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233FB695B@ESESSCMS0356.eemea.ericsson.se> References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 - Christian's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2011 12:33:58 -0000 Hi Christian, Comments inline.=20 >4.2 MSRP Offer Procedures >=20 > 3. If the MSRP endpoint is using a relay for MSRP=20 > communication, it > MUST include the address information of the relay (the MSRP URI of > the topmost SDP a=3Dpath attribute), rather than the address > information of itself, in the SDP c/m-line associated with the MSRP > media description.... =20 >=20 > This description is a bit unclear to me. It looks like that=20 > only m/c line Would be modified. What about the following proposal: >=20 > 3. If the MSRP endpoint is using a relay for MSRP=20 > communication, it > MUST add the address information of the relay to the=20 > a=3Dpath attributes=20 > (the MSRP URI of the topmost SDP a=3Dpath attribute) and use=20 > the address > Information of the relay (instead of the own address information)=20 > in the SDP c/m-line associated with the MSRP media description.... >=20 > Same proposal for 4.3 MRSP Answerer Procedures >=20 > 3. If the MSRP endpoint is using a relay for MSRP=20 > communication, it > MUST include the address information on the relay (the MSRP URI of > the topmost SDP a=3Dpath attribute), rather than the address > information of itself, in the SDP c/m-line associated with the MSRP > media description... >=20 > New Version: >=20 > 3. If the MSRP endpoint is using a relay for MSRP=20 > communication, it > MUST add the address information of the relay to the=20 > a=3Dpath attributes=20 > (the MSRP URI of the topmost SDP a=3Dpath attribute) and use=20 > the address > Information of the relay (instead of the own address information)=20 > in the SDP c/m-line associated with the MSRP media description.... Your suggestion looks good. ------------- =20 > General Remark: > Especially Section 4 is a bit difficult to read. > In 4.2 MSRP Offer Procedures the MSRP endpoint is the MSRP=20 > offerer and the remote MSRP endpoint is the MSRP answerer. > In 4.3 MSRP Answer Procedures the MSRP endpoint is the MSRP=20 > answerer and the remote MSRP endpoint is the MSRP offerer. > That confusing for the reader. Why not replace MSRP endpoint=20 > and MSRP remote endpoint with MSRP offerer and MSRP answerer=20 > in all reasonable cases? Unless people object, I can try to do that. ------------- > 4.2 MSRP Offer Procedures >=20 > NOTE: As described in section 5, in the absence of the SDP a=3Dmsrp- > cema attribute in the new offer, it is assumed that a=20 > Middlebox will act as an MSRP B2BUA in order to anchor MSRP media. >=20 > Does this mean, a Middlebox would have to remove the SDP=20 > a=3Dmsrp-cema attribute from an offer, if it provides MSRP=20 > B2BUA function? > At lease this description is missing in section 5. I will add some text about that. ------------- > "The MSRP endpoint MAY choose to terminate the session establishment > if it can detect that a Middlebox acting as a MSRP B2BUA is not the > desired remote endpoint." >=20 > How is this related or relevant for CEMA?=20 Since the main usage of CEMA is in environments where middleboxes are used,= it was considered good from a security perspective to add this text. ------------- > "The MSRP endpoint can send the new offer within the existing early > dialog [RFC3261], or it can terminate the early dialog and=20 > establish a new dialog by sending the new offer in a new initial=20 > INVITE request." >=20 > If this are the possible reactions on the detection of a=20 > Middlebox, the two Paragraphs should be combined. It's not really the same thing. One paragraph talks about the procedure whe= n a new offer is sent, and the other paragraph talks about when the user ch= ooses to terminate the session establishment and not send a new offer. However, I do suggest to switch location of the two paragraphs, as the seco= nd one is related to the procedures above in the section. ------------- =20 > 1. Introduction >=20 > Since the active MSRP UA establishes > the MSRP TCP or TLS connection based on the MSRP URI of the SDP > a=3Dpath attribute, this means that the MSRP connection will not, > unless the middlebox also modifies the MSRP URI of the topmost SDP > a=3Dpath attribute, be routed through the middlebox. >=20 > The sentence look a bit strange. What about the following proposal: >=20 > An active MSRP UA establishes the MSRP TCP or TLS connection based > on the MSRP URI of the SDP a=3Dpath attribute. This means=20 > that the MSRP connection will not be routed through the middlebox,=20 > unless the middlebox also modifies the MSRP URI of the topmost SDP=20 > a=3Dpath attribute. Your suggestion looks good. ------------- Thanks for your comments! Regards, Christer From saul@ag-projects.com Thu Sep 22 08:15:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E142D21F8C34 for ; Thu, 22 Sep 2011 08:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnqCfTE2VmG6 for ; Thu, 22 Sep 2011 08:15:06 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 574BF21F8C1F for ; Thu, 22 Sep 2011 08:15:06 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 47BFAB01BB; Thu, 22 Sep 2011 17:17:35 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 99D76B01A1; Thu, 22 Sep 2011 17:17:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F6F662@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 22 Sep 2011 17:17:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> <90C36F01-608F-40DA-899C-A5723CDED292@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F662@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2011 15:15:07 -0000 Christer, >=20 > I personally would have no problem with that, but we have a decision = that we cannot mandate Middlebox behavior - only make "assumptions" - = and I would not like to re-open that discussion. >=20 > Section 5.2 does say: >=20 > "In order to support interoperability between UAs that support = the > CEMA extension and UAs that do not support the extension, the > Middlebox is MSRP aware. This means that it implements MSRP = B2BUA > functionality." >=20 >=20 > And, whatever MUSTs we would add, at the end of the day the vendor and = customer will decide what is implemented and deployed. And, as I've said = before, from my experience customers DO require interoperability with = non-CEMA clients, and the products I am aware of DO support MSRP B2BUA = functionality. >=20 It was not my intention to re-popen the discussion. I'd be happier to = see that, but if it was agreed that we can't do that, it's ok. +1 from me. -- Sa=FAl Ibarra Corretg=E9 AG Projects From atle.monrad@ericsson.com Mon Sep 26 00:52:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5272E21F86F6 for ; Mon, 26 Sep 2011 00:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYA5iGwYX9Ia for ; Mon, 26 Sep 2011 00:52:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 210A221F86EE for ; Mon, 26 Sep 2011 00:52:19 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-52-4e802fd57cef Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.C6.20773.5DF208E4; Mon, 26 Sep 2011 09:55:01 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.187]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 26 Sep 2011 09:54:49 +0200 From: Atle Monrad To: Christer Holmberg , "Schmidt, Christian 1. (NSN - DE/Munich)" , Ben Campbell Date: Mon, 26 Sep 2011 09:54:48 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 - Christian's comments Thread-Index: AQHMd9QLBG5SDAr0QrmE+whIuf8L7JVZAaWQgABGb3CABgpkoA== Message-ID: <7A051DFAA46D0246A82293C7CEF621E9056D539ABE@ESESSCMS0352.eemea.ericsson.se> References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852233FB695B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233FB695B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 - Christian's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 07:52:21 -0000 Hi Christer has worked long and hard and answered the questions and concerns o= n this draft. With the latest additions, I'm happy to bring the draft forwards. 1+ from me aswell. thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 22. september 2011 14:36 To: Schmidt, Christian 1. (NSN - DE/Munich); Ben Campbell Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org; Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 - Christian's = comments Hi Christian, Comments inline.=20 >4.2 MSRP Offer Procedures >=20 > 3. If the MSRP endpoint is using a relay for MSRP=20 > communication, it > MUST include the address information of the relay (the MSRP URI of > the topmost SDP a=3Dpath attribute), rather than the address > information of itself, in the SDP c/m-line associated with the MSRP > media description.... =20 >=20 > This description is a bit unclear to me. It looks like that only m/c=20 > line Would be modified. What about the following proposal: >=20 > 3. If the MSRP endpoint is using a relay for MSRP=20 > communication, it > MUST add the address information of the relay to the=20 > a=3Dpath attributes=20 > (the MSRP URI of the topmost SDP a=3Dpath attribute) and use=20 > the address > Information of the relay (instead of the own address information)=20 > in the SDP c/m-line associated with the MSRP media description.... >=20 > Same proposal for 4.3 MRSP Answerer Procedures >=20 > 3. If the MSRP endpoint is using a relay for MSRP=20 > communication, it > MUST include the address information on the relay (the MSRP URI of > the topmost SDP a=3Dpath attribute), rather than the address > information of itself, in the SDP c/m-line associated with the MSRP > media description... >=20 > New Version: >=20 > 3. If the MSRP endpoint is using a relay for MSRP=20 > communication, it > MUST add the address information of the relay to the=20 > a=3Dpath attributes=20 > (the MSRP URI of the topmost SDP a=3Dpath attribute) and use=20 > the address > Information of the relay (instead of the own address information)=20 > in the SDP c/m-line associated with the MSRP media description.... Your suggestion looks good. ------------- =20 > General Remark: > Especially Section 4 is a bit difficult to read. > In 4.2 MSRP Offer Procedures the MSRP endpoint is the MSRP offerer and=20 > the remote MSRP endpoint is the MSRP answerer. > In 4.3 MSRP Answer Procedures the MSRP endpoint is the MSRP answerer=20 > and the remote MSRP endpoint is the MSRP offerer. > That confusing for the reader. Why not replace MSRP endpoint and MSRP=20 > remote endpoint with MSRP offerer and MSRP answerer in all reasonable=20 > cases? Unless people object, I can try to do that. ------------- > 4.2 MSRP Offer Procedures >=20 > NOTE: As described in section 5, in the absence of the SDP a=3Dmsrp- > cema attribute in the new offer, it is assumed that a=20 > Middlebox will act as an MSRP B2BUA in order to anchor MSRP media. >=20 > Does this mean, a Middlebox would have to remove the SDP a=3Dmsrp-cema=20 > attribute from an offer, if it provides MSRP B2BUA function? > At lease this description is missing in section 5. I will add some text about that. ------------- > "The MSRP endpoint MAY choose to terminate the session establishment > if it can detect that a Middlebox acting as a MSRP B2BUA is not the > desired remote endpoint." >=20 > How is this related or relevant for CEMA?=20 Since the main usage of CEMA is in environments where middleboxes are used,= it was considered good from a security perspective to add this text. ------------- > "The MSRP endpoint can send the new offer within the existing early > dialog [RFC3261], or it can terminate the early dialog and=20 > establish a new dialog by sending the new offer in a new initial=20 > INVITE request." >=20 > If this are the possible reactions on the detection of a Middlebox,=20 > the two Paragraphs should be combined. It's not really the same thing. One paragraph talks about the procedure whe= n a new offer is sent, and the other paragraph talks about when the user ch= ooses to terminate the session establishment and not send a new offer. However, I do suggest to switch location of the two paragraphs, as the seco= nd one is related to the procedures above in the section. ------------- =20 > 1. Introduction >=20 > Since the active MSRP UA establishes > the MSRP TCP or TLS connection based on the MSRP URI of the SDP > a=3Dpath attribute, this means that the MSRP connection will not, > unless the middlebox also modifies the MSRP URI of the topmost SDP > a=3Dpath attribute, be routed through the middlebox. >=20 > The sentence look a bit strange. What about the following proposal: >=20 > An active MSRP UA establishes the MSRP TCP or TLS connection based > on the MSRP URI of the SDP a=3Dpath attribute. This means=20 > that the MSRP connection will not be routed through the middlebox,=20 > unless the middlebox also modifies the MSRP URI of the topmost SDP=20 > a=3Dpath attribute. Your suggestion looks good. ------------- Thanks for your comments! Regards, Christer _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From nancy.greene@ericsson.com Tue Sep 27 09:34:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08EE21F8ED4 for ; Tue, 27 Sep 2011 09:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1j6tvyVXnf7 for ; Tue, 27 Sep 2011 09:34:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C23221F8ED6 for ; Tue, 27 Sep 2011 09:34:10 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8RGanrp005868 for ; Tue, 27 Sep 2011 11:36:56 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 27 Sep 2011 12:36:52 -0400 From: Nancy Greene To: Simple WG Date: Tue, 27 Sep 2011 12:36:52 -0400 Thread-Topic: Errata? Was RE: [Sip-implementors] RFC 5438 - blank lines missing? Thread-Index: Acx6LH7x5c133my0RPOvr2NQgYc4ugAAhpYQAACSA/AAkPqToAAvqtSw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Simple] FW: Errata? Was RE: [Sip-implementors] RFC 5438 - blank lines missing? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2011 16:34:12 -0000 ...trying for answers from this list. Nancy -----Original Message----- From: Nancy Greene=20 Sent: September-26-11 2:03 PM To: Pavesi, Valdemar (NSN - US/Irving); sip-implementors@lists.cs.columbia.= edu; hisham.khartabil@gmail.com; eburger@standardstrack.com Cc: Nancy Greene Subject: Errata? Was RE: [Sip-implementors] RFC 5438 - blank lines missing? The RFC 3862 definition of an "encapsulated MIME message-body" seems to sta= te that there is a blank line separating it from the message-metadata-heade= rs and that would mean there is a blank line before the Content-Type header= of the encapsulated MIME message-body, meaning the examples in RFC 5438 ar= e wrong - is this the case or not?=20 So it seems that either RFC 5438 is wrong, or RFC 5438 defines an alternati= ve to the CPIM Message Format that now needs to be supported for IMDNs. In = any case, some kind of errata or clarification to RFC 5438 would seem to be= needed. Nancy=20 -----Original Message----- From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-implemento= rs-bounces@lists.cs.columbia.edu] On Behalf Of Nancy Greene Sent: September-23-11 4:41 PM To: Pavesi, Valdemar (NSN - US/Irving); sip-implementors@lists.cs.columbia.= edu; hisham.khartabil@gmail.com; eburger@standardstrack.com Subject: Re: [Sip-implementors] RFC 5438 - blank lines missing? But, I see this in RFC 3862: 2. Overall Message Structure ... A complete message looks something like this: m: Content-type: Message/CPIM s: h: (message-metadata-headers) s: e: (encapsulated MIME message-body) ... 2.4. Message Content The final section of a Message/CPIM is the MIME-encapsulated message content, which follows standard MIME formatting rules [1][2]. The MIME content headers MUST include at least a Content-Type header. The content may be any MIME type. Example: e: Content-Type: text/plain; charset=3Dutf-8 e: Content-ID: <1234567890@foo.com> e: e: This is my encapsulated text message content=20 Nancy -----Original Message----- From: Pavesi, Valdemar (NSN - US/Irving) [mailto:valdemar.pavesi@nsn.com] Sent: September-23-11 4:24 PM To: Nancy Greene; sip-implementors@lists.cs.columbia.edu; hisham.khartabil@= gmail.com; eburger@standardstrack.com Subject: RE: [Sip-implementors] RFC 5438 - blank lines missing? Nancy, No , the blank line must be only before the content, in your case "Hello W= orld". Regards! Valdemar -----Original Message----- From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of ext Na= ncy Greene Sent: Friday, September 23, 2011 3:08 PM To: sip-implementors@lists.cs.columbia.edu; hisham.khartabil@gmail.com; ebu= rger@standardstrack.com Subject: [Sip-implementors] RFC 5438 - blank lines missing? Hi, I have seen this on the list before but can't find it.=20 =20 Is it agreed that the RFC 5438 examples are all missing a blank line betwee= n the CPIM headers and the Content-type for the message body? =20 >From RFC 5438 section 7.1.1.3 (same thing is also in sections 7.2.1.1, 7.2.1.2,8.1 and 8.3) ... Section 10 describes the formal syntax for the Disposition- Notification header field. The following is an example CPIM body of an IM where the IM Sender requests positive and negative delivery notifications, but not display notification or processing notifications: From: Alice To: Bob NS: imdn imdn.Message-ID: 34jk324j DateTime: 2006-04-04T12:16:49-05:00 imdn.Disposition-Notification: positive-delivery, negative-delivery Content-type: text/plain <=3D=3D=3D=3D=3D=3D according to RFC 3862, ther= e is supposed to be a blank line before this line, right? Content-length: 12 Hello World ... =20 Nancy _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors From prasun.bheri@gmail.com Fri Sep 30 02:57:47 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D4521F8B82 for ; Fri, 30 Sep 2011 02:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjR1BnAG4UNw for ; Fri, 30 Sep 2011 02:57:47 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1C7921F8AB9 for ; Fri, 30 Sep 2011 02:57:46 -0700 (PDT) Received: by ggnk3 with SMTP id k3so172643ggn.31 for ; Fri, 30 Sep 2011 03:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IzsH2HICggejUBz3e45+uHapIqfkz97YaQwWZDqty/U=; b=HGdPMeHgXnNOs7MCxaYq7D/vvu3f9QijeF0sggY0OGyv3RpEefuctNdEMATuaPh6DJ eEGtm51S8GsNnd953y20z8CRO0rBmKGVl8+LSP0Me3yU/76G11M7fRVhzmpPXbE1pmaw i9eVlKnoMk/7EeMq+HCsvckygsKkFN86iRFvI= Received: by 10.236.175.98 with SMTP id y62mr33710875yhl.78.1317376840116; Fri, 30 Sep 2011 03:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.156.8 with HTTP; Fri, 30 Sep 2011 03:00:00 -0700 (PDT) In-Reply-To: <9AF73DDF1D71944E8B2A94C48743BDF402CD999B@DEMUEXC035.nsn-intra.net> References: <1314596416.94588.YahooMailNeo@web161614.mail.bf1.yahoo.com> <58DB2CE4-76BE-46BE-B38B-633A0C5AA7A2@nostrum.com> <9AF73DDF1D71944E8B2A94C48743BDF402CD999B@DEMUEXC035.nsn-intra.net> From: prasun bheri Date: Fri, 30 Sep 2011 15:30:00 +0530 Message-ID: To: "Rohnert, Hans (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=20cf305640e99729cf04ae25b2da Cc: Simple@ietf.org Subject: Re: [Simple] are you aware of any documentation to implement MMSusing MSRP? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2011 09:57:47 -0000 --20cf305640e99729cf04ae25b2da Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Hans and group, i have tried searching CPM specs but haven't found anything close enough, may be i am looking in the wrong direction altogether. so ill explain the exact scenario and perhaps you guys can guide me towards the right direction. my task at hand is to deliver mms payload to mmsc (gateway) using msrp protocol. mms architecture defines mm1 interface protocol to transfer mms from user agent to mmsc gateway so i am guessing that some where with in or in parallel to mm1 protocol i have to use msrp to transfer mms payload to gateway. i am not finding any supporting document that speaks about transferring mms to mmsc gateway using msrp. what is it that i am missing? any help is greatly appreciated. thanks & regards -prasun On Tue, Aug 30, 2011 at 5:13 AM, Rohnert, Hans (NSN - DE/Munich) < hans.rohnert@nsn.com> wrote: > OMA CPM and GSMA RCS do not do exactly =93implement MMS using MSRP=94. Ra= ther > the following:**** > > ** ** > > GSMA RCS uses MMS as is for messaging needs (however, there are multiple > GSMA RCS versions differing in their respective messaging capabilities an= d > means, and you would need to take a closer look here before making generi= c > statements about GSMA RCS). **** > > ** ** > > OMA CPM is its own messaging enabler, leveraging on different IETF > facilities (e.g. SIP MESSAGE and MSRP) for constructing and sending =93CP= M > messages=94. Also, CPM defines an interworking between CPM messages and M= MS > messages. There, it is described how one kind of message can be translate= d > into the other.**** > > ** ** > > Hope this helps,**** > > Hans Rohnert**** > > ** ** > > *From:* simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] *On > Behalf Of *ext Ben Campbell > *Sent:* Monday, August 29, 2011 5:54 AM > *To:* gonther rik > *Cc:* Simple@ietf.org > > *Subject:* Re: [Simple] are you aware of any documentation to implement > MMSusing MSRP?**** > > ** ** > > I am not aware of any such document from the IETF. You might take a look = at > the OMA CPM or GSMA RCS specs to see if they have anything that meets you= r > needs.**** > > ** ** > > On Aug 29, 2011, at 12:40 AM, gonther rik wrote:**** > > > > **** > > Hello Group,**** > > could you please guide me to an rfc or some documentation mentioning how = to > implement MMS using MSRP**** > > ** ** > > Thanks & Regards**** > > -Rik**** > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple**** > > ** ** > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > --20cf305640e99729cf04ae25b2da Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Hans and group,

i have tried searching CPM specs b= ut haven't found anything close enough,=A0
may be i am lookin= g in the wrong direction altogether. so ill explain the exact scenario and= =A0
perhaps you guys can guide me towards the right direction.=A0

my task at hand is to deliver mms payload to mmsc (gateway= ) using msrp protocol.=A0
mms architecture defines mm1 interface = protocol to transfer mms from user agent to=A0
mmsc gateway so i am=A0guessing that some where with in or in parallel= to mm1 protocol=A0
i have to use msrp to transfer mms payload to= gateway.=A0

i am not finding any supporting docum= ent that speaks about transferring mms to mmsc
gateway using msrp. what is it that i am missing?=A0

any help is greatly=A0appreciated.=A0

than= ks & regards
-prasun=A0


=A0
=A0


On Tue, Aug 30, 2011 = at 5:13 AM, Rohnert, Hans (NSN - DE/Munich) <hans.rohnert@nsn.com> wrote:=

OMA CPM and GSMA RCS do not do exactly =93implement MMS = using MSRP=94. Rather the following:

=A0

GSMA RCS uses MMS as is for= messaging needs (however, there are multiple GSMA RCS versions differing i= n their respective messaging capabilities and means, and you would need to = take a closer look here before making generic statements about GSMA RCS). <= u>

=A0

OMA CPM is its own messagin= g enabler, leveraging on different IETF facilities (e.g. SIP MESSAGE and MS= RP) for constructing and sending =93CPM messages=94. Also, CPM defines an i= nterworking between CPM messages and MMS messages. There, it is described h= ow one kind of message can be translated into the other.

=A0

Hope this helps,<= /u>

Hans Rohnert

=A0<= /span>

From: simple-boun= ces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Ben Campbe= ll
Sent: Monday, August 29, 2011 5:54 AM
To: gonther rik
<= b>Cc: Simple@ietf.= org


Subject: Re: [Simple] are yo= u aware of any documentation to implement MMSusing MSRP?

=A0

I am not aware of any such document from the IETF. You migh= t take a look at the OMA CPM or GSMA RCS specs to see if they have anything= that meets your needs.

=A0

On Aug 29, 2011, at 12:40 AM, gon= ther rik wrote:



Hello Group,

could you please guide me to an = rfc or some documentation mentioning how to implement MMS using MSRP=

=A0

Thanks & Regards

-Rik

_______________________________________________
Simple mailing list
<= a href=3D"mailto:Simple@ietf.org" target=3D"_blank">Simple@ietf.org
= = https://www.ietf.org/mailman/listinfo/simple

=A0

<= br>_______________________________________________
Simple mailing list
Simple@ietf.org
= https://www.ietf.org/mailman/listinfo/simple


--20cf305640e99729cf04ae25b2da--