Subject: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11

From: Ben Campbell <[email-masked]>
Date: Mon, 23 May 2011 16:38:43 -0500

(as individual)

Here are my WGLC comments on sessmatch-11:

Major Issues:

-- This draft adds an option tag to address backwards compatibility issues. I am concerned, however, about the guidance to put the tag in a Requires header "if an entity is performing MSRP related procedures that require the remote MSRP entity to support the sessmatch extension in order to enable MSRP media" Putting "sessmatch" in an Requires header means you aren't willing to talk to someone who uses an RFC4976 relay. If we see that used heavily, then we have effectively split the community into camps that can't talk to each other. I don't think we want to encourage that. I'd at least like to see some text encouraging implementations to try to find some way to talk to each other, whether by putting ALGs into an MSRP b2bua mode, reissuing a request without the Require tag, invoking a relay, etc.

Minor Issues:

-- general: Keep in mind that RFC 4975 is technically not SIP specific. MSRP could conceivably be used with other signaling protocols. (Yes, I realize it probably _won't_). We probably out to mention somewhere (maybe in the applicability statement) that the option tag usage described here is specific to SIP, and that if sessmatch is to be used with any other signaling protocol, then the extension mechanism in that protocol should be used to indicate support. And that the specifics are out of scope for this draft.

-- section 4.2, last paragraph: "request with a 481 response. The entity MUST also check to make sure the session is not already in use on another connection. If the session is already in use, it MUST reject the request with a 506 response."

This is normal 4975 behavior. Is there a need to repeat it here?

-- section 4.3, 2nd paragraph: "...located behind an MSRP relay..."

We need to better define what "behind a relay" means. I think we a talking about when an endpoint explicitly authorizes with a relay and would ordinarily put the relay URI in the SDP path attribute, right?

-- same paragraph: "If at least one reliably sent successful response to the intial INVITE request contains the ’sessmatch’ option-tag in the Supported header..."

I'm not sure telling the UAS to put the tag in Supported is the right thing to do to indicate support. It seems like one would either put it in Required, or just not mention it. If we need the UAC behavior (and any ALG, etc) to change based on whether or not the UAS expresses support, then you probably want the UAS to put the tag in a Requires header, to indicate it plans to invoke the extension.

-- section 4.3, 2nd to last paragraph:

Do we need some similar text describing the behavior of the UAS if it requires sessmatch but got an invite without the sessmatch tag in Supported?

-- section 4.3, last paragraph:

This "note", combined with the previous paragraph, suggests that an intermediary MUST in certain circumstances add a tag to a Require header. How do we expect the UAC to react if it gets a 420 response due to a Require tag that it didn't actually insert? (i.e. an intermediary inserted it). 

-- section 6.3, 2nd to last paragraph (number 2)

This makes me nervous without recommending at least some protection of the SDP, such as SIPS.

Editorial Comments:

-- Section 1, 4th paragraph: "MSRP entities that support the sessmatch extension use a different mechanism for matching an MSRP message with an MSRP session, called session matching."

Really, you are matching sessions regardless of whether you follow RFC 4975 rules vs sessmatch rules. I'm not sure we have to put a "name" on this--I suggest simply deleting the phrase after the comma.

-- section 5.1: "This document does not specify ALG behavior."

It sort of does now, if you look at the last 2 paragraphs of 4.3.

-- section 5.4: "environments that require SIP identity based peer-to-peer SDP protection."

I would say "environments that use any mechanism for end-to-end integrity protection of SDP payloads, such as SIP Identity [RFC4474]."

-- section 5.5, 2nd paragraph: "ALG relays the MSRP media packages" and "encrypted MSRP media pacakges"

Do you mean packets?

-- section 7.1:

The formatting is weird in the IANA consideration section. The description text wraps around.

Also, it won't really see encrypted MSRP media packets so much as TLS packets. It can't tell if those packets actually contain MSRP.

-- section 6.2: "It does not however enable a MiTM to monitor TLS protected MSRP or to in any significant way modify the MSRP communication content."

Does the second clause also refer to TLS protected content?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2011 08:49:58 +0200

Hi Ben, 

In this e-mail I reply to your major issue. I will reply on your minor/editorial comments later.

>-- This draft adds an option tag to address backwards 
>compatibility issues. I am concerned, however, about the 
>guidance to put the tag in a Requires header "if an entity is 
>performing MSRP related procedures that require the remote 
>MSRP entity to support the sessmatch extension in order to 
>enable MSRP media" Putting "sessmatch" in an Requires header 
>means you aren't willing to talk to someone who uses an 
>RFC4976 relay. If we see that used heavily, then we have 
>effectively split the community into camps that can't talk to 
>each other. I don't think we want to encourage that. I'd at 
>least like to see some text encouraging implementations to 
>try to find some way to talk to each other, whether by 
>putting ALGs into an MSRP b2bua mode, reissuing a request 
>without the Require tag, invoking a relay, etc.

What about adding some text that STRONGLY RECOMMENDS entities to implement a mechanism that allows fallback (e.g. switching to MSRP B2BUA mode) to RFC4975 behavior in case the remote entity does not support (or, isn't able to use due to a relay) sessmatch, rather than using the Require header field?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2011 15:20:03 +0200

Hi Ben,

Inline are my replies to your minor/editorial comments.

----------

>Minor Issues:
> 
>-- general: Keep in mind that RFC 4975 is technically not SIP 
>specific. MSRP could conceivably be used with other signaling 
>protocols. (Yes, I realize it probably _won't_). We probably 
>out to mention somewhere (maybe in the applicability 
>statement) that the option tag usage described here is 
>specific to SIP, and that if sessmatch is to be used with any 
>other signaling protocol, then the extension mechanism in 
>that protocol should be used to indicate support. And that 
>the specifics are out of scope for this draft.

I suggest to add the following new paragraph (copy/pasted XML) to the Applicability statement section:

		"This document defines a SIP option-tag <xref target="RFC3261" pageno="false" format="default" />, which is used
		in SIP messages to indicate, or mandate, support of the sessmatch extension. The establishment of MSRP sessmatch
		extension sessions using other protocols than SIP is outside the scope of the specification."

----------

>-- section 4.2, last paragraph: "request with a 481 response. 
>The entity MUST also check to make sure the session is not 
>already in use on another connection. If the session is 
>already in use, it MUST reject the request with a 506 response."
> 

Well, the text describes the session matching procedure using the sessmatch extension, and the procedure you refer to happens to be the same as for 4975 based session matching.

So, personally I think it would be good to keep the text.

Of course, if you think it would become more clear, I could add the following to the beginning of the sentence:

	"Similar to the procedures defined in RFC 4975, if no match exist..."

----------

>We need to better define what "behind a relay" means. I think 
>we a talking about when an endpoint explicitly authorizes 
>with a relay and would ordinarily put the relay URI in the 
>SDP path attribute, right?

Yes.

Could we maybe instead say "...does not use an MSRP relay for MSRP communication..."?

	"An MSRP entity that supports the sessmatch extension, and does not use an MSRP 
	relay for MSRP communication, MUST insert the 'sessmatch' option-tag in the Supported 
	header field of the initial INVITE request for a session that contains MSRP media. "

----------

> -- same paragraph: "If at least one reliably sent successful 
> response to the intial INVITE request contains the 
> 'sessmatch' option-tag in the Supported header..."
> 
> I'm not sure telling the UAS to put the tag in Supported is 
> the right thing to do to indicate support. It seems like one 
> would either put it in Required, or just not mention it. If 
> we need the UAC behavior (and any ALG, etc) to change based 
> on whether or not the UAS expresses support, then you 
> probably want the UAS to put the tag in a Requires header, to 
> indicate it plans to invoke the extension.

I can change header field from Supported to Require:

	"If at least one reliably sent successful response to the intial INVITE request contains the
   	'sessmatch' option-tag in the Require header field of the response, the MSRP entity MUST 
	use the session matching procedures defined in this specification during the session."

----------

> Do we need some similar text describing the behavior of the 
> UAS if it requires sessmatch but got an invite without the 
> sessmatch tag in Supported?

I guess we could say the following:

	"If an MSRP entity that supports the sessmatch extension receives an
   	initial INVITE request that does not contain the 'sessmatch' option-tag in
   	the Supported or Require header field of the request, it MUST NOT insert 
	the 'sessmatch' option-tag in the Require header field of any response to the intial 
	INVITE request, and it MUST NOT use the session matching procedures defined in
   	this specification during the session"

----------

> This "note", combined with the previous paragraph, suggests 
> that an intermediary MUST in certain circumstances add a tag 
> to a Require header. How do we expect the UAC to react if it 
> gets a 420 response due to a Require tag that it didn't 
> actually insert? (i.e. an intermediary inserted it). 

I don't think that should be a problem, as this can happen only to an UAC that supports the sessmatch extension.

Also, based on my reply to your major comment, if we strongly recommend to not use the Require header field in the first place, this hopefully won't happen very often.

----------

>protection of the SDP, such as SIPS.

I suggest to modify, with some restructuring, the following paragraphs as follows:

   	If MSRP endpoints that support the sessmatch extension do not support a common TLS
   	authentication method based on a pre-shared secret, and neither MSRP
   	endpoint use an MSRP relay for MSRP communication, they SHALL perform 
	TLS authenctication as defined in RFC 4975, which will succeed if there 
	are no ALGs in the MSRP path.
   
   	If TLS authentication as defined in RFC 4975 fails, an MSRP 
	endpoint that supports the sessmatch extension SHALL either:
 
   	1) Consider the TLS autentication as failed, in accordance with RFC 4975, or

	2) If the SIP signalling between the endpoints is protected through e.g. 
   	   SIPS, and when support of the sessmatch extension is indicated in a request
   	   or response received from the other MSRP endpoint, use fingerprint
         based authentication without requiring SDP end-to-end integrity, and 
	   thus trust the network entities in the signaling path for SDP integrity.

   	NOTE: As defined in RFC 4975, if TLS autentication fails, the user need to be
   	able to decide whether to try to establish an MSRP connection without TLS protection.

----------

> Editorial Comments:
> 
> -- Section 1, 4th paragraph: "MSRP entities that support the 
> sessmatch extension use a different mechanism for matching an 
> MSRP message with an MSRP session, called session matching."
> 
> Really, you are matching sessions regardless of whether you 
> follow RFC 4975 rules vs sessmatch rules. I'm not sure we 
> have to put a "name" on this--I suggest simply deleting the 
> phrase after the comma.

Will do.

----------

>It sort of does now, if you look at the last 2 paragraphs of 4.3.

Well, it's not explicit ALG behavior, eventhough I agree it will be enabled by ALGs.

Maybe we could say something like:

	"This document does not specify explicit ALG behavior, eventhough some of the 
	procedures will be enabled by ALGs. However, as the main reason behind the 
	sessmatch extension is to allow MSRP entities to communicate in networks where 
	ALGs are present, this document makes certain assumptions regarding to how such 
	ALGs behave."

----------

> I would say "environments that use any mechanism for 
> end-to-end integrity protection of SDP payloads, such as SIP 
> Identity [RFC4474]."

Ok.

----------

> -- section 5.5, 2nd paragraph: "ALG relays the MSRP media 
> packages" and "encrypted MSRP media pacakges"
> 
> Do you mean packets?

Yes. I will change to "packets".

----------

> The description text wraps around.

I am not sure I understand. It looks fine to me :)

However, based on other comments, I think we have to change the last sentence of the Description:

	"When present in a Require header field, it indicates that the reciving UA MUST support the session matching mechanism."

----------

>Also, it won't really see encrypted MSRP media packets so 
>much as TLS packets. It can't tell if those packets actually 
>contain MSRP.

I assume this is a follow up comment on your comment on section 6.2 (below)?

I will address this in my suggested text below.

----------

> -- section 6.2: "It does not however enable a MiTM to monitor 
> TLS protected MSRP or to in any significant way modify the 
> MSRP communication content."
> 

Yes. I suggest the following modified sentence:

	"It does not however enable a MiTM to monitor TLS
   	protected MSRP, in any significant way modify TLS 
	protected MSRP content or even find out that the
	packets contain MSRP messages."

----------

Thank You very much for Your comments!

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 24 May 2011 08:50:04 -0500

> What about adding some text that STRONGLY RECOMMENDS entities to implement a mechanism that allows fallback (e.g. switching to MSRP B2BUA mode) to RFC4975 behavior in case the remote entity does no…

That would help. 

Some of the text in RFC 3261 concerning the 421 response code might be a good example, as it recommends against its use for similar reasons. (I'm rather surprised that 3261 didn't have similar language around the Require header, since it has similar properties).

---

From: Adam Roach <[email-masked]>
Date: Tue, 24 May 2011 10:10:21 -0500

On 5/24/11 01:49, May 24, Christer Holmberg wrote:
> What about adding some text that STRONGLY RECOMMENDS entities to 
> implement a mechanism that allows fallback (e.g. switching to MSRP 
> B2BUA mode) to RFC4975 behavior in case the remote entity does not 
> support (or, isn't able to use due to a relay) sessmatch, rather than 
> using the Require header field?

So, to be clear, you're proposing that these intermediaries would not 
insert a Require header field at all, and  instead fall back to being an 
MSRP B2BUA if the INVITE or its response doesn't indicate support? That 
seems a reasonable path forward.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2011 17:44:43 +0200

Hi, 

>>support (or, isn't able to use due to a relay) sessmatch, 
>>rather than using the Require header field?
> 
>So, to be clear, you're proposing that these intermediaries 
>would not insert a Require header field at all, and  instead 
>fall back to being an MSRP B2BUA if the INVITE or its 
>response doesn't indicate support? That seems a reasonable 
>path forward.

Yes. 

That is just an example, though. I don't think we should mandate it.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 24 May 2011 14:42:25 -0500

> Inline are my replies to your minor/editorial comments.

Works for me.

Works for me.

I think this mostly works. My only question is whether we want to say anything about how an endpoint that does not use an MSRP relay will only put one URI in the path attribute--or more strongly, an endpoint using the sessmatch extension MUST NOT insert more than one URI in the path attribute.

WFM

I was thinking more around the scenario where you have a UAS that can only communicate using sessmatch, but the UAC doesn't support it. Would you send a 421? (This would need to be subject to the same caveat about a UAC putting sessmatch in Require, of course)

Okay. We might need to be more explicit that the intermediary would only do this if it was already in Supported.

I think that helps. (I do expect this section to get a lot of AD scrutiny, BTW)

[...]

> 	ALGs are present, this document makes certain assumptions regarding to how such 

Okay

[...]

> I am not sure I understand. It looks fine to me :)

In the PDF version, they wrap around. In the plain text and HTML versions, the lines are just too long. (idnits complains about the line length)

> 	"When present in a Require header field, it indicates that the reciving UA MUST support the session matching mechanism."

Okay.

Yes, sorry.

> I will address this in my suggested text below.

WFM

---

From: Shida Schubert <[email-masked]>
Date: Wed, 25 May 2011 14:28:12 +0900

My comments inline.

>> 	use the session matching procedures defined in this specification during the session."

 I think UAS sending the option-tag in Supported is fine, I don't 
know why we should only set it to Require header. Is this for 
when UAS is aware of ALG being on the path which mocks with 
the SDP, mandating the use of sessmatch? If so I think we should 
be explicit about that.  

 Whether the scenario exists or not, there well can be a scenario 
where ALG which mocks with the SDP doesn't exists. Making it 
unnecessary to use sessmatch. Furthermore, if we go ahead 
with always setting the sessmatch in Require in response from UAS, 
if UAC doesn't support it but ALG is not present, MSRP session that 
COULD have been established will not establish.  

> I was thinking more around the scenario where you have a UAS that can only communicate using sessmatch, but the UAC doesn't support it. Would you send a 421? (This would need to be subject to the s…

 I think we should say that UA supporting the specification 
MUST always insert the "sessmatch" option tag whether it is 
behind the MSRP relay or not. It takes out the guesswork by 
the UAS.

 I think putting sessmatch in Require should only be encouraged 
when UAC or UAS is aware of ALG(s) that mocks with SDP and 
it knows there is no MSRP relays that it can use, mandating the 
use of sessmatch for successfully establishing MSRP session. 

 If there is no ALG and no MSRP relay, MSRP should work just 
fine right? So why fail it with 421 when one doesn't support the 
mechanism that may not be necessary in some situation?

 Regards
  Shida

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 08:45:43 +0200

Hi Ben,

Inline are my replies on the issues where you did not indicate "WFM" :)

----------

>I think this mostly works. My only question is whether we want to say anything about how an endpoint that 
>does not use an MSRP relay will only put one URI in the path attribute--or more strongly, an endpoint using the 
>sessmatch extension MUST NOT insert more than one URI in the path attribute.

So, something like:

       "An MSRP entity that supports the sessmatch extension MUST NOT insert more than one URI in the SDP a=path
        attribute, as it could make other entities to assume that the entity uses an MSRP relay for MSRP communication."

----------

>I was thinking more around the scenario where you have a UAS that can only communicate using sessmatch, but the UAC 
>doesn't support it. Would you send a 421? (This would need to be subject to the same caveat about a UAC putting 
>sessmatch in Require, of course)

Ok, I understand.

I don't think the UAS should behave in that way in the first place. As sessmatch is an extension to RFC 4975, it means that the UAS must also support RFC 4975. I can add some wording about that, if needed.

But, if the UAS (for whatever reason) doesn't want to use MSRP without sessmatch it can either reject the request (e.g. using 421 or 415), or only reject the MSRP part by setting the port to zero.

----------

>Okay. We might need to be more explicit that the intermediary would only do this if it was already in Supported.

That has been my intention, but it may need to be more clear. I'll look into it.

----------

>I think that helps. (I do expect this section to get a lot of AD scrutiny, BTW)

I guess so. But, I've done my best to cover the security, and there it not much more I can do.

----------

>In the PDF version, they wrap around. In the plain text and HTML versions, the lines are just too long. (idnits complains about the line length)

Ok, I'll double check it.

Once again, thanks for your comments! They were very constructive!

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 May 2011 14:53:28 -0500

(as individual)

On May 24, 2011, at 10:10 AM, Adam Roach wrote:

> So, to be clear, you're proposing that these intermediaries would not insert a Require header field at all, and  instead fall back to being an MSRP B2BUA if the INVITE or its response doesn't indicate support? That seems a reasonable path forward.
> 

On reflection, and even though I initially supported this as a good way to resolve my concern about falling back to standard behavior, I have some reservations about this approach.

The surface issue is that we had, so far, said we weren't defining how an intermediary (be it an ALG, SBC, or whatever) works. We can't really place normative requirements on them unless we decide to go ahead and specify at least part of their behavior. I'm not sure we want to take that on in this working group. One potential way out would be to just give guidance against the use of sessmatch in a Require header in an INVITE, as well as the use of 421 responses. That would take away at last part of the opportunity for intermediaries to force the use of sessmatch (short of the current mechanism of just not working.)

But the deeper issue is the question of what are we signaling with this option tag in the first place. Negotiating the use of sessmatch doesn't mean much for a UAC or a UAS. The draft says that without it, UAs must fall back to RFC4975 matching rules--but it doesn't matter if they don't. Anything that matches according to 4975 will also match according to session match. It's the intermediaries that have to change behavior, not the endpoints. So, in effect, we are using this option tag to signal an extra-standard device that it can engage in behavior that is not normatively specified anywhere. That seems to violate the spirit, if not the letter, of the rule that an option tag must be specified in a standards track RFC.

This is more than a philosophical issue--it creates some practical architectural issues. For example, if Alice supports sessmatch, but Bob uses an MSRP relay, what happens? Can Bob simply not reflect the sessmatch back in his response, and go ahead and use a relay? What if an SBC had already munged the path header before Bob even saw Alice's offer? Should Bob forgo the use of the relay, and just assume Alice's SBC will fix everything? If so, then that gives Supported: sessmatch almost the force of Require:sessmatch.

I'm not sure we're on the right path here. An alternative might be to signal sessmatch in the SDP, instead of in a SIP options tag. This would avoid the issue of making a SIP only solution. But it would still involve signaling a non-standardized device that it can invoke non-standardized behavior.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 22:28:43 +0200

Hi Ben, 

>>>What about adding some text that STRONGLY RECOMMENDS 
>>>entities to implement a mechanism that allows fallback (e.g. 
>>>switching to MSRP B2BUA mode) to RFC4975 behavior in case the 
>>>remote entity does not support (or, isn't able to use due to 
>>>a relay) sessmatch, rather than using the Require header field?
>> 
>On reflection, and even though I initially supported this as 
>a good way to resolve my concern about falling back to 
>standard behavior, I have some reservations about this approach.

Welcome to the club :)

>The surface issue is that we had, so far, said we weren't 
>defining how an intermediary (be it an ALG, SBC, or whatever) 
>works. We can't really place normative requirements on them 
>unless we decide to go ahead and specify at least part of 
>their behavior. I'm not sure we want to take that on in this 
>working group.
>
>One potential way out would be to just give guidance against the use of sessmatch 
>in a Require header in an INVITE, as well as the use of 421 responses. That would 
>take away at last part of the opportunity for intermediaries to force the use of 
>sessmatch (short of the current mechanism of just not working.)

I have no problem to remove the Require part.

(And, as discussed below, I have no problem to use SDP instead)

>But the deeper issue is the question of what are we signaling 
>with this option tag in the first place. Negotiating the use 
>of sessmatch doesn't mean much for a UAC or a UAS. The draft 
>says that without it, UAs must fall back to RFC4975 matching 
>rules--but it doesn't matter if they don't. Anything that 
>matches according to 4975 will also match according to 
>session match. It's the intermediaries that have to change 
>behavior, not the endpoints. So, in effect, we are using this 
>option tag to signal an extra-standard device that it can 
>engage in behavior that is not normatively specified 
>anywhere. That seems to violate the spirit, if not the 
>letter, of the rule that an option tag must be specified in a 
>standards track RFC.
>
>This is more than a philosophical issue--it creates some 
>practical architectural issues. For example, if Alice 
>supports sessmatch, but Bob uses an MSRP relay, what happens? 
>Can Bob simply not reflect the sessmatch back in his 
>response, and go ahead and use a relay?
>What if an SBC had already munged the path header before Bob even saw Alice's 
>offer? Should Bob forgo the use of the relay, and just assume 
>Alice's SBC will fix everything? If so, then that gives 
>Supported: sessmatch almost the force of Require:sessmatch.

I don't think Bob should be forced to forgo the relay. There are reasons 
why Bob is using a relay (in the same way there are reasons others use 
an ALG), and other entities should not be allowed to change that policy. 

IF Bob does something, it's based on his own policies and decissions. Others 
must not be able to force changes.

>I'm not sure we're on the right path here. An alternative 
>might be to signal sessmatch in the SDP, instead of in a SIP 
>options tag. This would avoid the issue of making a SIP only 
>solution. But it would still involve signaling a 
>non-standardized device that it can invoke non-standardized behavior.

I have no problem to use SDP instead. In the early phase of the work there was an a=msrp-acm attribute, so I guess we could use something similar. 

Regards,

Christer