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

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

I have read the previous draft and had no issues with the previous draft but 
I have re-reviewed the draft once again and below are my comments. 

 I only have minor comments and I think the document is ready to proceed.

 Minor concern/clarification

 1. SIP-identity is used here and there, is it the RFC4744 or something else?
   If it is RFC4744, I don't know why it can't be used. If the ALG is behind the 
   authentication server defined in RFC4744 then SIP-identity should be able 
   to function. 

 2. There is a mention of option-tag usage in Require in response but 
  there is no mentioning of its use in Require in request. I have no strong 
  opinion against this, but if it is feasible to use it in response, I don't see 
  why it wouldn't be the case for request. 

 Nits: 
 
1. Abstract
  remove "of MSRP entities"

2. Abstract
  add '' to sessmatch after "option-tag, ". 

3. Introduction
  OLD : "in order to match an MSRP message to an MSRP session. That requires consistency between"

 NEW :"in order to match an MSRP message to an MSRP session, which requires consistency between"

4. Introduction
  OLD : "The reason is that the matching of an MSRP message to an ongoing session will not fail"

 NEW : "The reason is that the matching of an MSRP message to an ongoing session will not fail because there is no entity modifying the SDP."

5. Introduction
 OLD : "MSRP B2BUA functionality, can normally not establish MSRP sessions"

 NEW : "MSRP B2BUA functionality, can not normally establish MSRP sessions"

 6. Applicability Statement
 OLD : "where ALGs that might modify the address information of the SDP a=path attribute, but do not implement MSRP B2BUA functionality, are present."

 NEW : "where ALGs are present that might modify the address information of the SDP a=path attribute, but do not implement MSRP B2BUA functionality."

7. Session Matching
  OLD : "and the one defined in this specification for the sessmatch extension,"
 
  NEW : "and the one defined in this specification,"

8. Session Matching
  OLD : "while the mechanism in RFC 4975 uses the MSRP URI comparison rules for "

  NEW : "while the mechanism in RFC 4975 uses the entire MSRP URI comparison rules for 

9. Session Matchin
  OLD : "If a match exists, the entity MUST assume that the host that formed the connection is the host to which this URI was given."
  
  NEW : "If a match exists, the entity MUST assume that the host that formed the connection to, is the host to which this URI was given."

10. Session Matching
  OLD : "The entity MUST also check to make sure the session is not already "

 NEW : "The entity MUST also check to make sure the session-id is not already "

11. Usage of ’sessmatch’ option-tag
  OLD : "INVITE request contains the ’sessmatch’ option-tag in the Supported header field of the response,"

  NEW : "INVITE request contains the ’sessmatch’ option-tag in the Supported header field,"

12. Usage of ’sessmatch’ option-tag
  OLD : "in order to anchor and forward MSRP traffic, but will not be able to perform"

  NEW : "in order to anchor and forward MSRP traffic, but unable to perform"

13. Usage of ’sessmatch’ option-tag
  OLD : "and therfore sends a 420 (Not Supported) response to the INVITE request, is outside the scope of this specification."

  NEW : "and sending a 420 (Not Supported) response to the INVITE request, is outside the scope of this specification."

 14. MSRP awareness
  The MSRP communication. Is this supposed to be MSRP session? 
   * I forgot the difference between MSRP session and MSRP communication.. The terminology 
  is used interchangeably throughout the draft. I guess I can look at the RFC4975 and remind myself of the difference.. 

 15. TCP connection reuse
  OLD : "MSRP payload might not enable re-usage of TCP connections"

  NEW : "MSRP payload might not enable reuse of TCP connections"

  16. Is the Relay extension a Normative reference, shouldn't it be Informative? Also if the 
   SIP Identity based SDP protection refers to "RFC4474" then I think it should be added 
   to the reference as well. 

 Regards
  Shida

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 19:07:30 +0200

Hi Shida,

>I have read the previous draft and had no issues with the 
>previous draft but I have re-reviewed the draft once again 
>and below are my comments. 
> 

----------
 
>     If it is RFC4744, I don't know why it can't be used. If 
>     the ALG is behind the authentication server defined in RFC4744 then SIP-identity 
>     should be able to function. 

Yes, when the draft mentions "SIP Identity" it refers to RFC4474. We can be more clear about that. 

It is true as you say that SIP identity based SDP integrity protection will work for cases where the ALG is located between MSRP UA and the authentication proxy. While this then works for ALGs that are built into firewalls, it is however not the case for the type of ALGs used by SIP network providers to handle policy control, intercept, QoS monitoring, address domain bridging, transcoding, etc. These are often located on the other side of the authenticating proxy and in these networks SIP Identity is commonly not supported at all. 

One suggestion woudl be to remove this issue conmpletely, by changing the draft to say that if TLS authentication using pre-shared key is not possible, then the UAs shall use the RFC4975 specified authentication. Ie, we will completely remove the text regarding concern of useage of fingerprint without integrity protection. 

----------

>     there is no mentioning of its use in Require in request. I 
>     have no strong opinion against this, but if it is feasible to use it in 
>     response, I don't see why it wouldn't be the case for request. 

I don't think that the requester should ever insert Require:sessmatch, since it can not know on beforehand whether it will be needed.

----------

>   OLD : "in order to match an MSRP message to an MSRP 
> session. That requires consistency between"
> 
>  NEW : "The reason is that the matching of an MSRP message to 
> an ongoing session will not fail because there is no entity 
> modifying the SDP."
> 
> 5. Introduction
>  OLD : "where ALGs that might modify the address information 
> of the SDP a=path attribute, but do not implement MSRP B2BUA 
> functionality, are present."
> 
>  NEW : "where ALGs are present that might modify the address 
> information of the SDP a=path attribute, but do not implement 
> MSRP B2BUA functionality."
> 
> 7. Session Matching
>   OLD : "If a match exists, the entity MUST assume that the 
> host that formed the connection is the host to which this URI 
> was given."
>   
>   NEW : "If a match exists, the entity MUST assume that the 
> host that formed the connection to, is the host to which this 
> URI was given."
> 
> 10. Session Matching
> 11. Usage of 'sessmatch' option-tag
>   OLD : "INVITE request contains the 'sessmatch' option-tag 
> in the Supported header field of the response,"
> 
>   NEW : "INVITE request contains the 'sessmatch' option-tag 
> in the Supported header field,"
> 
> 12. Usage of 'sessmatch' option-tag
> 13. Usage of 'sessmatch' option-tag
>   OLD : "and therfore sends a 420 (Not Supported) response to 
> the INVITE request, is outside the scope of this specification."
> 
>   NEW : "and sending a 420 (Not Supported) response to the 
> INVITE request, is outside the scope of this specification."
> 
>  14. MSRP awareness
>   is used interchangeably throughout the draft. I guess I can 
> look at the RFC4975 and remind myself of the difference.. 
> 
>  15. TCP connection reuse

I'll take a closer look at your nits comments later, but after a first look they seem fine.

Thanks!

Best regards,

Christer