Subject: [Simple] Sessmatch "breaking" legacy MSRP

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 10 Jun 2011 13:07:16 -0400

Howdy,
several people have raised arguments that the Sessmatch extension is bad because it doesn't interoperate with legacy MSRP.
Ignoring the fact that there's very little deployed legacy MSRP to be broken, I'm not sure it's a valid argument anyway.  We've extended SIP numerous times with mechanisms that require both ends to support them to work - for example, PRACK.  The option-tag mechanism is there to handle that for SIP, and anytime an option-tag is put in a Requires header, the far-end has to support it for the request to succeed.

More importantly, MSRP is indicated in SDP, and SDP's raison d'être is to indicate not only addressing information but also capabilities... possibly incompatible capabilities.  No one argue G.729 should not be allowed because a device only supporting G.729 does not interop with one supporting only G.711.  Nor does a device only support SRTP interop with one only support cleartext RTP.  Nor does one only supporting RTP over UDP interop with one supporting only RTP over TCP.  Etc., etc.

Sessmatch is an extension, and one that both sides must support to do sessmatch.  That isn't a new concept to grasp.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Jun 2011 19:48:50 +0200

> Sessmatch is an extension, and one that both sides must support to do sessmatch.  That isn't a new concept to grasp.

Hadriel, don't take me wrong but it seems you have missed all the
threads about this topic in which lot of arguments were given. Just to
summarize:

> Ignoring the fact that there's very little deployed legacy MSRP to be broken.

This can NEVER be a reason to break an existing protocol. And there
*are* existing MSRP implementations outside legacy boring walled
gardens. I mean: "Internet".

> We've extended SIP numerous times with mechanisms that require both ends to support them to work - for example, PRACK.  The option-tag mechanism is there to handle that for SIP, and anytime an option-tag is put in a Requires header, the far-end has to support it for the request to succeed.
> No one argue G.729 should not be allowed because a device only supporting G.729 does not interop with one supporting only G.711.  Nor does a device only support SRTP interop with one only support cleartext RTP.

The critical difference here is that PRACK is useful for Internet and
provides a real added value to the SIP protocol (no matter it was
originally designed by an IMS requirement).

In the other side, sessmatch is just useful for corrupted networks in
which ALG's boxes break OSI/Internet layers because vendors want to
anchor MSRP media by requiring *unencrypted* SIP sessions (SIP over
TLS avoids media anchoring).

In short, this document does not specify a new feature (it's not a
codec or a new media transport). This document wants to standarize an
aberration against Internet design just in favour of big vendors.

If the new draft does not break existing MSRP scenarios, it's ok, you
are strong enough to force IETF to approve such an aberration. At
least it will not disturb people in the real Internet as me and much
others. We can just ignore it and hope IETF will never publish a
document like this.

But if the new draft does still break today's working scenarios (those
in which RFC 4975/4976 work), and you still promote the draft in IETF,
then congratulations for your great contributtion to the world.

Regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 10 Jun 2011 14:53:00 -0400

On Jun 10, 2011, at 1:48 PM, Iñaki Baz Castillo wrote:
> threads about this topic in which lot of arguments were given.

I tried to catch up, but there are so many it's impractical, so I did random selection. :)

> Just to
> This can NEVER be a reason to break an existing protocol.

Sure it can.  You can change the status of a previous RFC to Historic, for example.  But that's not what's being proposed.  What's being proposed isn't to "break" MSRP - it's to create an extension.

> TLS avoids media anchoring).

No, I really don't think that's the goal of sessmatch.  I know the draft says "ALG", but it's misleading/wrong.  The use-case they have in mind is essentially a SIP B2BUA.  It is the target of your SIP request.  SIP _can_ use TLS. 

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Jun 2011 21:03:05 +0200

> Sure it can.  You can change the status of a previous RFC to Historic, for example.  But that's not what's being proposed.  What's being proposed isn't to "break" MSRP - it's to create an extension.

...an extension that, at least until previous draft version, *did*
break the existing MSRP protocol. Don't name it "extension" please.
Breaking a protocol without adding a real value can never be called an
"extension".

> No, I really don't think that's the goal of sessmatch.  I know the draft says "ALG", but it's misleading/wrong.  The use-case they have in mind is essentially a SIP B2BUA.  It is the target of your…

After 100-200 mails about this topic, I'm pettry sure the document
mainly means "ALG" devices (those which mangle/inspect SIP at
transport layer level, so they are not B2BUA). If we were speaking
about SIP and MSRP B2BUA's, then sessmatch was no reason to exist. Am
I wrong?

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