Subject: [Simple] External Review of draft-ietf-simple-msrp-sessmatch-11

From: Eric Burger <[email-masked]>
Date: Fri, 1 Jul 2011 18:33:27 -0400

I was asked by the SIMPLE Work Group Chair to review the Internet Draft, Session Matching Update for the Message Session Relay Protocol (MSRP).

This document describes the behavior of a half-way kind of new network element, the half-application layer gateway (ALG).  I call this a half-ALG because a real ALG, in the SIP world, is a back-to-back user agent, or B2BUA.

In short, this draft is an advertisement for XMPP.  The draft proposes a quasi-but-not-at-all end-to-end protocol to enable middle boxes to relay an MSRP stream by hacking the signaling to the point there really is a new session.  In fact, there is a new session, but the draft is proposing a session to correlate the first session on one side of the half-ALG with the other side. I would offer the applicability statement, saying that this draft addresses the situation where there is deliberate network impairment and partition, due to the presence of these half-ALGs, immediately indicates that we are not talking about an Internet topology, but some proprietary topology that happens to use the IP for transport.

I suppose this extension would be acceptable if the half-ALG is required to cryptographically identify itself and either end point can opt out. However, if opting out means no message goes through, then by definition we are not in the Internet, and such an extension would be out of scope for the IETF.

There are a host of nits, like the document's abbreviation being MSRP and bizarre formatting of section 7.1, but given the issues above, are true nits.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 11 Jul 2011 15:10:29 -0500

(as chair)

Would anyone care to respond to Eric's review? These are not comments we can easily ignore. Do the changes in version 13 make a difference here?

Thanks!

Ben.

On Jul 1, 2011, at 5:33 PM, Eric Burger wrote:

> There are a host of nits, like the document's abbreviation being MSRP and bizarre formatting of section 7.1, but given the issues above, are true nits._______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jul 2011 22:22:59 +0200

Hi,

If I understand Eric's comments, they are not technical, so I *assume* there is not much difference between -13 and earlier versions from that perspective.

However, Eric does seem to imply that we could cover this by adding some text to the applicability statement.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ben Campbell [[email-masked]]
Sent: Monday, July 11, 2011 11:10 PM
To: Simple WG
Cc: Eric Burger
Subject: Re: [Simple] External Review of draft-ietf-simple-msrp-sessmatch-11

(as chair)

Thanks!

Ben.

> https://www.ietf.org/mailman/listinfo/simple

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

---

From: Eric Burger <[email-masked]>
Date: Mon, 11 Jul 2011 16:19:52 -0500

We seem to be a bit closer with this draft.  However, two things puzzle me.

The first is that the draft does not mandate TLS.  Without mandatory TLS, let us call the draft what it is: "Lawful intercept (LI) Capability for the Message Session Relay Protocol (MSRP)."  Then the discussion of man-in-the-middle attacks can move from an unfortunate side-effect to a design decision.  I would suggest mandating TLS and forcing a connection drop if it is not available.

The second puzzle brings me back to the question of what we are trying to accomplish. This draft mandates the middlebox must be able to perform as a B2BUA. That tells me such a middlebox will have the thousands of lines of code required to implement a B2BUA.  Moreover, the middlebox will have a few thousand lines of code to implement the draft behavior.  Given the relationship between code complexity and latent defects, I would expect the Security Considerations section to point out that implementing this draft, in addition to the B2BUA functionality, which the network element must implement anyway, reduces the practical security of the device, any networks it is supposed to protect, and Internet stability in general.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Jul 2011 22:57:22 +0200

Hi Eric,

>The first is that the draft does not mandate TLS.  Without mandatory TLS, let us call the draft what it is: "Lawful intercept (LI) Capability for the Message Session Relay Protocol (MSRP)."  Then the discussion of man-in-the-middle attacks can move from an unfortunate 
>side-effect to a design decision.  I would suggest mandating TLS and forcing a connection drop if it is not available.

LI is not the only reason why middleboxes are used, and certainly not the main reason for CEMA. If one wants to do LI, it will be done with or without CEMA :)

The main reasons for CEMA are related to actions and procedures that take place for every (or, at least a major part) of calls, where having to enable B2BUA for every call will cause huge resource impact (see more below).

Having said that, if needed we can add more text and guidance regarding the usage of TLS.

>The second puzzle brings me back to the question of what we are trying to accomplish. This draft mandates the middlebox must be able to perform as a B2BUA. That tells me such a middlebox will have the thousands of lines of code required to implement a B2BUA.  
>Moreover, the middlebox will have a few thousand lines of code to implement the draft behavior.  Given the relationship between code complexity and latent defects, I would expect the Security Considerations section to point out that implementing this draft, in addition to 
>the B2BUA functionality, which the network element must implement anyway, reduces the practical security of the device, any networks it is supposed to protect, and Internet stability in general.

As I've said before, the main issue is not (at least not from my own experience with vendors and customers) the code it takes to implement B2BUA functionality - it is the resource consumption when having to enable it. CEMA helps, as middleboxes now do not have to enable B2BUA in all cases, at that has lead (again, from my own experience) to major increase of interest in supporting MSRP. 

For the non-B2BUA behavior, very little new code will be required for the middlebox, since it will modify the SDP c/m line in the same way as it already does for other media types.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 13 Jul 2011 15:18:22 +0200

> For the non-B2BUA behavior, very little new code will be required for the middlebox, since it will modify the SDP c/m line in the same way as it already does for other media types.

This is the first spec allowing an intermediary node to modify an SDP,
am I right? well, if the middelbox acts as a real/full SIP B2BUA
(UAS+UAC) then it's perfectly valid for it to reuse, modify or
re-create the SDP. AFAIR the current spec mandates the middlebox to be
a real/full SIP B2BUA; am I right?

-- 
Iñaki Baz Castillo
<[email-masked]>