Subject: [Simple] Comments on draft-ietf-simple-msrp-cema-01

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Sep 2011 18:18:25 -0500

(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=setup:
   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." 

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? 

-- 6.2, last paragraph: "… 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: " 
MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], cannot anchor through Middleboxes. "

How is an MSRP relay not a middle box?

-- " 
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=path 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 <[email-masked]>
Date: Sat, 3 Sep 2011 00:12:15 +0200

Hi Ben, 

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 
>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.

First, it is not only SBCs. Application Servers can also be affected.

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....

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.

---------------

>MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 
>[RFC4976], cannot anchor through Middleboxes. "
> 

It is not a Middelbox as defined by the draft.

---------------

>Middleboxes must read the message to change the routing

Ok.

---------------

>-- " Also the matching will fail if Middleboxes modify the 
>address information in the MSRP URI of the SDP a=path attribute. "
> 
>Redundant sentence?

Yes. I'll remove it.

---------------

>-- 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?

No, it only indicates that the answerer accepts the MSRP media (with or without 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."

---------------

>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:
> 
>The overall structure of this section is confusing. It's not 
>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 MSRP endpoint becomes "active", it MUST
       use the SDP c/m-line for establishing the MSRP TCP connection. If the MSRP endpoint becomes "passive", 
       it will wait for the remote MSRP endpoint to establish the TCP connection, according to the procedures
       in RFC 4975."

---------------

>Probably should add this to definitions

Will do.

---------------

>-- 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

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.

---------------

>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: Eric Burger <[email-masked]>
Date: Sun, 4 Sep 2011 14:49:42 -0400

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.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Sep 2011 13:41:07 +0200

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 
> be exposed in clear text to the MSRP B2BUA, which violates
> 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.)

I'll let Eric reply to this first.

---------------

> 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.

Yes, my intention was to provide more elaboration, but forgot due to the missunderstandings 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 will always establish the TCP or TLS connection using the SDP a=path attribute, which contains the address the remote MSRP endpoing, instead of the SDP c/m-line which contains the address information of the Middlebox."

...and similar for the other cases.

---------------

> assumed to indicate a middlebox.

Yes.

---------------

> -- 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?

I'll let Eric reply to this first.

(Personally I am not sure how the endpoint would be able to detect).

---------------

> 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?

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.

---------------

> What does scenario 4 indicate, assuming the middlebox would act as a 
> 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-line even if the a=msrp-cema attribute wasn't present in the SDP offer, and there is really nothing the answerer can do to fix that. 

(Note that this error case is not CEMA specific)

So, my suggestion would be to instead send a 488 (Not Acceptable Here) error response in this case.

---------------

> -- 4.3, paragraph 9 (list item 3): "In addition, it MUST include an 
>SDP a=setup: passive attribute in the MSRP media description of the SDP 
>answer."
> 

Yes.

---------------

> -- 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.

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.

Second, at least I am aware of customer requirements of interop with non-CEMA peers, and products that support it.

---------------

> Really just the offerer, right?

Yes.

---------------

> -- 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.

I suggest the following text:

	"Instead, in order to associate an MSRP message with a specific session, the 
	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."

---------------

> That should be a top level assumption in itself.

Do you mean the text belongs somewhere else?

Ok.

---------------

> 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 
 	then re-encrypts them before sending them toward the other MSRP endpoint. 
 	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 
	used for the MSRP communication, assuming that the SIP signalling channel is 
	integrity protected."

---------------

> I think that needs elaboration.

The end of the setence does say:

	", since that would require the MiTM to implement MSRP B2BUA functionality, no 
	matter if UAs support the CEMA extension or not."

---------------

> -- 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. "
> 

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 
	TLS, no matter if they support the CEMA extension or not. In such cases, 
	as the Middlebox acts as TLS endpoints, MSRP endpoints might be given an 
	incorrect impression that there is an end-to-end security association (SA)
   	between the MSRP endpoints."

---------------

> rather than just comparing to SIPS
 
I suggest to modify bullet 2, where SIPS is mentioned:

	"2. If SIP signalling to/from the endpoint is integrity protected, typically through 
	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 
	accept fingerprint based TLS authentication without requiring end-to-end SDP integrity."

---------------

> like SOCKS, TURN-TCP, etc.

I'll let Eric reply to this first.

---------------

> 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 
by the network operator if the SIP signalling is protected, while the latter does not require such protection since 
keys are sent encrypted and managed by an external key management service. With SDES there is no authentication 
performed - the IMS network is trusted - it is just the negotiation of crypto keys for the media connection that 
SDES is used for.

With MIKEY-TICKET, however, the SDP offerer also indirectly authenticates the remote SRTP connection endpoint.

In neither case is there mutual authentication, since in IMS this is done during user registration and then one normally 
uses transport layer security associations in order not to have to re-authentcate as long as these are ok. 

---------------

>-- 6.2, last paragraph: "... validating that one or more SIP Proxies in 
>the proxy chain are not, in fact, malicious."
> 

I'll let Eric reply to this first.

---------------

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Sep 2011 13:56:10 +0200

Hi,

When replying to Ben's comments, I find a couple of issues for which I would 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=path 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=setup:
   		actpass attribute in the MSRP media description of the SDP offer."

I suggest to remove the last sentence, about the a=setup attribute, and add it to bullet 2.

So, the new text would be:

		"2. The MSRP endpoint MUST include an SDP a=setup attribute in the SDP offer.
		If the MSRP endpoint is using a relay for MSRP communication, it MUST set the 
		value of a=setup to "actpass". If the MSRP endpoint is not using a relay for MSRP 
		communication, it MUST the value of a=setup in accordance with RFC6135 [RFC6135].

		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=path 
		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 mandating MICKET-TICKET, but simply mention it as an example.

		"2. TLS-PSK. For example, 3GPP has specified the use of SDES (when SIP transport is integrity protected) and MIKEY-TICKET for IMS."

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 8 Sep 2011 17:37:43 -0500

> In this reply I'll address your editorial comments, and your comment on the Middlebox 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". 

see previous comment.
[…]

> 	"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.

> 	"NOTE: As described in section 5, in the absence of…"

Okay

I think that helps.

[…]

>       that authentication mechanism.

That helps, but I think it needs some elaboration to explain what you mean. The "unless…but" 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.

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.

> 
> ---------------
> 
> 
> Regards,
> 
> Christer
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Thu, 8 Sep 2011 17:47:12 -0500

> When replying to Ben's comments, I find a couple of issues for which I would like to suggest some changes.

I agree that is an improvement.

> Section 6.2

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…"

---

From: Ben Campbell <[email-masked]>
Date: Thu, 8 Sep 2011 18:19:55 -0500

Hi, see imbedded. I removed sections that I think are agreed upon, and also the sections where you requested Eric respond. (Eric?)

Thanks!

Ben.

[…]

> ...and similar for the other cases.

That helps, thanks!

[…]

> 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…

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.

Okay

Nevermind, I think I misread something.

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."

okay

WFM

Not so much that as stating it as an assumption rather than a fact. i.e. "This document assumes that middleboxes relay…"

[…]

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

WFM

Your "Yes, but.." sentence answer my question, but I like the proposed text better anyway :-)

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.."

[…]

> 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 :-)

[…]

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Sep 2011 23:10:32 -0400

WFM, too.

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Sep 2011 23:16:06 -0400

inline

> Some of your comments are related to the new security text provided by Eric, so I will indicate where I expect him to comment.

It is different. SIP Proxies are never supposed to see RTP in clear text. Remember MSRP is like RTP, not SIP.

[snip]

> (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]

> 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]

> 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.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 8 Sep 2011 23:07:43 -0500

> 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.

> 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 s…

That makes sense. Maybe a "For example…" would be helpful.

> 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 "… for end to end integrity and _confidentiality_"?

>   proxy chain are not, in fact, malicious.

:-D

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Sep 2011 09:37:50 +0200

Hi Ben, 

>>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.
>> 
>> 		"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..."

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 <[email-masked]>
Date: Fri, 9 Sep 2011 10:27:27 +0200

Hi, 

>>> 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.
>> 
>> 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....
>> 
>> 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". 

The text in the introduction talk about middleboxes in general (we should use "m" instead of "M").

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.

---------------

>>> -- 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?
>> 
>>	"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.

I can remove the text.

---------------

>>> -- 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
>> 
>> 	"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...but" 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.

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 
	mechanism, they MUST use that mechanism. If the MSRP endpoints do not 
	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:"

---------------

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Sep 2011 14:17:08 +0200

Hi, 

>>> 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?
>> 
>> 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.

---------------

>>> 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 
>>> the right thing.
>>> 
>> 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.
>> 
>> 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."

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.

>From 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.

(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 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."

---------------

>Not so much that as stating it as an assumption rather than a 
>fact. i.e. "This document assumes that middleboxes relay..."

Sure, but where do you want that text?

---------------

>>> 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.
>> 
>> 	"The Middlebox decrypts MSRP media packets received 
>>    from one MSRP endpoint, and then re-encrypts them before sending them toward the 
>>    other MSRP endpoint. 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 used for the MSRP communication, assuming that the SIP 
>>    signalling channel is integrity protected."
>> 
> 
>WFM, but it should say "... the SIP signaling channel is 
>end-to-end integrity protected" That is, SIPS doesn't cut it.

Ok.

---------------

>>> -- 6.2, 2nd to last paragraph: "If something like SIPS 
>>> protects the 
>>> SIP signaling"
>>> 
> 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.."

Ok.

---------------

>>> -- 6.2, paragraph 4:
>>> 
>>> Do the relevant specs recommend using mutually 
>>> authenticated TLS (or 
>>> DTLS or SRTP) between peers?
>> 
> 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 :-)

Ok :)

---------------

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Sep 2011 14:24:25 +0200

Hi,

I noted that I forgot to reply to one of your comments :)

>>>> 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.
>>> 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.
 
The offerer has to check things, but the anwserer also does things depending on whether the offer contains the tag or not. 

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.

---------------

Regards,

Christer

---

From: Eric Burger <[email-masked]>
Date: Fri, 9 Sep 2011 17:30:52 -0400

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.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Sep 2011 12:39:04 +0200

Hi,

So, should the statement be removed?

Regards,

Christer

  _____

From: Eric Burger [mailto:[email-masked]]
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

Only true if the endpoints can't talk p2p, or use some other thing

like SOCKS, TURN-TCP, etc.

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

---

From: Eric Burger <[email-masked]>
Date: Mon, 12 Sep 2011 05:48:16 -0500

Affirmative.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 12 Sep 2011 16:14:31 -0500

> But, I have nothing against adding the text you suggest.

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.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 12 Sep 2011 16:19:19 -0500

> 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.

> 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].

---

From: Ben Campbell <[email-masked]>
Date: Mon, 12 Sep 2011 16:37:42 -0500

>> We could almost have just said check all that stuff in the 

You quoted this but didn't comment--did you mean to ?

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."

Right where it is is fine.

[…]

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 12 Sep 2011 16:38:54 -0500

> 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.

(Ah, that's the one I noticed was quoted but not commented on in the other email.)

Okay.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Sep 2011 09:09:54 +0200

Hi, 

>> 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.
>> 
>> From 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.
>> 
>> (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.)
>> 
>> "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."
>> 
> 
> 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.
> 
> "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."

I don't like the "fail", wording, so what about:

	"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 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." 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Sep 2011 10:01:28 +0200

Hi, 

>>>> 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.
>>>> 
>>>> the use of SDES (when 
>>>> SIP transport is integrity protected) and MIKEY-TICKET for IMS."
>>> 
>>> 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..."
>> 
>> The text before the bullets does talk about using a 
>> mechanism that does not rely on peer-to-peer SDP integrity.
>> 
>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.

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:

				"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		
				authentication mechanisms defined in RFC 4975, it is RECOMMENDED 
				that a CEMA-enabled MSRP endpoint also supports one of the following
				authentication mechanisms, that do not rely on peer-to-peer SDP integrity:

				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 accordingly.
 
Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Sep 2011 10:20:32 +0200

Hi, 

> >>>> -- 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 
> >>> 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....
> >>> 
> 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.
> >> 
> 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)
> >> 
> 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".
> > 

>> 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.

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 
			Anchoring (CEMA). CEMA in most cases allows MSRP endpoints to communicate through 
			middleboxes, as defined in section XX, without a need for the middleboxes to be a 
			MSRP B2BUA. In such cases, middleboxes, that want to anchor the MSRP connection simply 
			modify the SDP c/m-line address information, similar to what it does for non-MSRP media 
			types. MSRP endpoints that support the CEMA extension will use the SDP c/m-line address 
			information for establishing the TCP or TLS connection for sending and receiving MSRP messages."

>> 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].

My suggestion is to use "m" in the introduction chapter, and "M" where we refer to the Middlebox as defined in the draft.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Sep 2011 12:45:08 +0200

Hi, 

>>> provide lawful intercept or other monitoring of content, 
>>> or enforce content-related policy". to the list.
>> 
>> Yes, my intention was to provide more elaboration, but 
>> forgot due to the missunderstandings associated with the 
>> submitting of the -00 version.
>> 
>>   "- A non-CEMA-enabled MSRP endpoint becomes "active", as 
>>   the endpoint will always establish the TCP or TLS connection 
>>   using the SDP a=path attribute, which contains the address 
>>   the remote MSRP endpoing, instead of the SDP c/m-line which 
>>   contains the address information of the Middlebox."
>> 

				"In the following cases, where there is a Middlebox in the network, the 
				CEMA extension can not be used, and there will be a fallback to
				the MSRP connection establishment procedures defined in RFC 4975 and 
				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 
				the MSRP connection using the SDP a=path attribute, which contains the address 
				information of the remote MSRP endpoint, instead of using the SDP c/m-line which contains 
				the address information of the Middlebox.

				- A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication becomes
				"passive", as it can not be assumed that the MSRP endpoint inserts the address 
				information of the relay in the SDP c/m-line.

				- A CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication 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 
				MSRP endpoint will fail."

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Sep 2011 08:51:25 -0500

> 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.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Sep 2011 12:21:17 -0500

> 	use RFC 4975 behavior in cases where they detect that the CEMA extension cannot be enabled." 

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 <[email-masked]>
Date: Tue, 13 Sep 2011 21:16:38 +0200

Hi, 

>>> 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.
>>> 
>>> "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."
>> 

Well, I am not really sure what to write. The assumption sections already say 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 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.
>

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 Campbell <[email-masked]>
Date: Tue, 13 Sep 2011 14:32:04 -0500

> 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.
 
(I think 5.5 is covered in the security considerations) 

> 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.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Sep 2011 21:41:32 +0200

Hi, 

>>> 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.
>> 
>-- 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.
>

Ok, now I understand. I can add such text.

Regards,

Christer