Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - - Ben's Substantive Comments

[Ben Campbell <[e-mail]>]

On Sep 13, 2011, at 2:09 AM, Christer Holmberg wrote:

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

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?