External Review of draft-ietf-simple-msrp-sessmatch-11

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.

_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: Consensus Call on sessmatch-13

Hi,

>>I see no need for changing what RFC6135 says. What about something like: "MSRP endpoints supporting
>>this specification MUST become active upon receiving an offer with 'actpass' " Would that be
reasonable >>for you?
>
>This should be the way to go.

Sounds good.

Regards,

Christer

Re: Consensus Call on sessmatch-13

Hi Atle,

By "constructive proposal", do you mean the consensus call itself, or did you mean to concur with my comment
about wanting to understand the scenarios better?

Thanks!

Ben.

On Jun 28, 2011, at 6:00 AM, Atle Monrad wrote:

> +1 from me aswell
> 
> Thanks to Ben for a constructive proposal !
> 
> /atle
> 
> 
> ________________________________ 
> 
> 
> Atle Monrad
> 3GPP CT Chairman
> Standardization and Regulation,
> Group Function Technology and Portfolio Management 
> Ericsson
> 
> 
> 
> 

Re: External Review of draft-ietf-simple-msrp-sessmatch-11

(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:

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

Re: External Review of draft-ietf-simple-msrp-sessmatch-11

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: simple-bounces <at> ietf.org [simple-bounces <at> ietf.org] On Behalf Of Ben Campbell [ben <at> estacado.net]
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)

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:

> I was asked by the SIMPLE Work Group Chair to review the Internet Draft, Session Matching Update for the

Re: Consensus Call on sessmatch-13

Hi,

In general, fallback is still needed in middlebox cases where a legacy entity establishes the MSRP TCP
connection, or where the UA is behind a relay.

(If there are no middleboxes, procedures are according to 4975).

Regards,

Christer

________________________________________
From: simple-bounces <at> ietf.org [simple-bounces <at> ietf.org] On Behalf Of Ben Campbell [ben <at> estacado.net]
Sent: Monday, July 11, 2011 10:58 PM
To: Atle Monrad
Cc: simple <at> ietf.org
Subject: Re: [Simple] Consensus Call on sessmatch-13

Hi Atle,

By "constructive proposal", do you mean the consensus call itself, or did you mean to concur with my comment
about wanting to understand the scenarios better?

Thanks!

Ben.

On Jun 28, 2011, at 6:00 AM, Atle Monrad wrote:

> +1 from me aswell

Re: External Review of draft-ietf-simple-msrp-sessmatch-11

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.

On Jul 11, 2011, at 3:22 PM, Christer Holmberg wrote:

> 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: simple-bounces <at> ietf.org [simple-bounces <at> ietf.org] On Behalf Of Ben Campbell [ben <at> estacado.net]

Re: Consensus Call on sessmatch-13

(as chair)

I read the resulting thread as rough consensus to follow the general direction of the CEMA approach in
sessmatch-13. We've seen some comments on details, and some requests for more analysis of scenarios.
We've also seen comments questioning the general applicability of the work in a separate thread. Please
continue with those conversations.

While we have agenda time for this in Quebec City, it would be even better to get as much work done as possible
before the face to face meeting 

Thanks!

Ben.

On Jun 24, 2011, at 1:45 PM, Ben Campbell wrote:

> (as chair)
> 
> Hi,
> 
> The latest version of the sessmatch draft ( draft-ietf-simple-msrp-sessmatch-13) is a significant
change of direction from older version. The essential difference is that the new version involves
compliant endpoints using the SDP m and c lines to establish TCP connections, rather than the previous
approach of making clients more resilient to a middlebox changing an MSRP URI in the a=path attribute. The
draft refers to this new approach as CEMA.
> 
> Do people thinks this is the right direction to take this work? I'm not asking if the draft is perfect and
ready to go--we certainly expect discussion and potential changes in the details. The point is to decide
if we should move forward with the CEMA approach instead of the previous sessmatch approach.
> 

Re: External Review of draft-ietf-simple-msrp-sessmatch-11

Hi Eric,

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

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. 

Re: External Review of draft-ietf-simple-msrp-sessmatch-11

2011/7/12 Christer Holmberg <christer.holmberg <at> ericsson.com>:
> 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
<ibc <at> aliax.net>
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple