Subject: [Simple] AD review: draft-ietf-simple-msrp-sessmatch-05

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 11 May 2010 17:43:11 +0300

Hi,

I have received a publication request for the following draft:

https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/

I have a few comments on the draft. Adding a few words describing how
the path mechanism works would be useful. With such an explanation, it
would be easier for readers to understand what this extension is about.

The draft states that with this extension, ALGs in the path need to only
be SDP aware as opposed to MSRP aware. That text implies that an ALG
using standard MSRP can already introduce itself in the path (although
with a bit more of work). So, one could think that the security
properties of the protocol would not be affected much. However, the
security considerations are not very clear about this. The Security
Considerations Section should clear on what it is actually describing at
any given time. Clarifying which threats that section talks about would
make the text much easier to understand (e.g., does the
man-in-the-middle introduce itself in the path by modifying the SDP or
just modifies MSRP packets?).

Thanks,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 May 2010 19:50:58 +0200

Hi,

>would be easier for readers to understand what this extension is about.

My assumption was that the reader is familar with MSRP and the path attribute, but I can add some explanation words.

What about adding the following sentence to the 3rd paragraph of section 1:

"The SDP a=path attribute is used to establish the routeset for the MSRP messages associated with the session."

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

>with a bit more of work). 

The text is probably a little confusing, and mixes up things.

The main point is that, currently, the *media relay* of an ALGs needs to modify the MSRP messages, rather than just passing them as data (as it does for most other media types). 

The *signalling handler* of an ALG needs to be MSRP aware, in the sense that it needs to modify the a=path attribute rather than the c/m line.

So, maybe the following text is more clear:

"The SDP a=path attribute is used to establish the routeset for the MSRP messages associated with the session.
Due to the fact that MSRP UAs check consistency between address information in the MSRP messages and in the Session Description
Protocol (SDP) a=path attribute, when an ALG modifies the address information of the a=path attribute, it forces the media relay of the ALG to
act as an MSRP Back-To-Back User Agent (B2BUA) in order to perform the corresponding modifications in the MSRP messages, 
whereas for other media types the media relay only needs to modify the IP and transport headers."

Do you think that is more clear?

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

>So, one could think that the security properties of the protocol would not be affected much. However, the
>security considerations are not very clear about this. The Security Considerations Section should clear on what it is actually describing at
>any given time. Clarifying which threats that section talks about would make the text much easier to understand (e.g., does the
>man-in-the-middle introduce itself in the path by modifying the SDP or just modifies MSRP packets?).

Would the following be more clear:

"However, since a man-in-the-middle would in any case be able to modify the domain information in both the SDP and 
the MSRP messages, e.g in order to insert itself in the MSRP signalling path or to route MSRP messages to
non-intended entities, this does not  introduce any new security risk."

I also had a look at the remaining text in the security section.

If needed, to the end of the 3rd paragraph I could end the following:

"Based on this information, users can trigger some actions in order to check whether network entities work correctly, or whether
 a man-in-the-middle has modified the SDP a=path attribute, for the same reasons as described earlier."

The 2 last paragraphs I think are clear, because they describe how the TLS authentication mechanism can be affected.

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 31 May 2010 19:36:05 +0300

Hi Christer,

thanks for your answers. Please, revise the draft along the lines of
your answers below so that I can start its IETF LC.

Thanks,

Gonzalo