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

From: Ben Campbell <[email-masked]>
Date: Mon, 23 May 2011 10:51:11 -0500

This is a Working Group Last Call of draft-ietf-simple-msrp-sessmatch-11:

http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11

Please note that this draft contains substantial new text since version 10, primarily concerning the use of an option tag. Even if you were happy with version 10, please review this version.

The WGLC will conclude on 6 June 2011. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group list.

Thanks!

Ben.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 25 May 2011 14:02:55 +0300

Hi,

given that the backwards compatibility properties of this extension have
caused some concern, the draft needs to do a better job describing them.
Being explicit about them is important. The last paragraph of Section 1
should be edited so that it captures the different scenarios that have
been discussed on this list. The authors may even consider having a
brief section about backwards compatibility, which would also include
the comments about having to implement regular MRSP procedures as the
fall-back mechanism at a MUST or a SHOULD level (whatever the WG decides).

Also, within that paragraph, the following sentence is confusing:

>  MSRP entities that do not implement the sessmatch extension, and
>    communicate with ALGs that do not implement MSRP B2BUA functionality,
>    can normally not establish MSRP sessions, since the session matching
>    will fail in case the address information of the SDP a=path attribute
>    has been modified by the ALGs.

That is not a standard scenario because before this extension was
defined, ALGs needed to implement MSRP B2BUA functionality. The draft
can say that this extension enables that scenario, but the draft should
not talk about non-standard behavior in the context of backwards
compatibility because things can get quite confusing.

Thanks,

Gonzalo

On 23/05/2011 6:51 PM, Ben Campbell wrote:
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

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

Hi, 

>given that the backwards compatibility properties of this extension have caused some concern, the draft needs to do a better job describing them.
>Being explicit about them is important. The last paragraph of Section 1 should be edited so that it captures the different scenarios that have been 
>discussed on this list. The authors may even consider having a brief section about backwards compatibility, which would also include the comments about 
>having to implement regular MRSP procedures as the fall-back mechanism at a MUST or a SHOULD level (whatever the WG decides).

Based on Ben's WGLC comments, the current proposal is to have a fallback mechanism as a STRONGLY RECOMMENDED. I don't mind having it even stronger than that, but there ARE networks (e.g. defined by OMA) where fallback will never be used, so for that reason I don't think we should make it a MUST. 

But, that's just my personal opinion. At the end of the day I will of course go with whatever the WG decides...

>That is not a standard scenario because before this extension was defined, ALGs needed to implement MSRP B2BUA functionality. The draft can say that this >extension enables that scenario, but the draft should not talk about non-standard behavior in the context of backwards compatibility because things can 
>get quite confusing.

Ok.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 13:39:56 +0200

> Based on Ben's WGLC comments, the current proposal is to have a fallback mechanism as a STRONGLY RECOMMENDED. I don't mind having it even stronger than that, but there ARE networks (e.g. defined by…

Outside OMA/IMS world, there are millons of local or public (Internet)
SIP networks, and usually commercial IP/TCP routers (those provided by
the Internet Provider) come with builtin SIP ALG enabled by default.
If these vendors also include MSRP ALG and the fallback mechanism is
not a MUST, they wont implement such mechanism, so bye bye MSRP in
"open" networks.

Anyhow, there are dozens of specifications in OMA/RCS/IMS that take
IETF RFC's and incorporate custom additions. Such a specification
could take place in OMA world (stating that the "fallback mechanism"
is not a MUST) so the rest of the world is not bothered.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 14:08:33 +0200

Hi, 

>>Based on Ben's WGLC comments, the current proposal is to have a fallback mechanism as a STRONGLY RECOMMENDED. I don't mind having it even stronger than 
>>that, but there ARE networks (e.g. defined by OMA) where fallback will never be used, so for that reason I don't think we should make it a MUST.
>
>Outside OMA/IMS world, there are millons of local or public (Internet) SIP networks, and usually commercial IP/TCP routers (those provided by the 
>Internet Provider) come with builtin SIP ALG enabled by default.
>If these vendors also include MSRP ALG and the fallback mechanism is not a MUST, they wont implement such mechanism, so bye bye MSRP in "open" networks.

So, how do these SIP ALGs behave today when it comes to MSRP?

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 14:44:02 +0200

> So, how do these SIP ALGs behave today when it comes to MSRP?

I don't know, I just hate SIP ALG's. I would like SIP ALG's not no
exist anymore as I don't want my router to inspect and modify my
application layer data.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 15:03:41 +0200

Hi, 

>>>>Based on Ben's WGLC comments, the current proposal is to have a 
>>>>fallback mechanism as a STRONGLY RECOMMENDED. I don't mind having it even stronger than that, but there ARE networks (e.g. defined by OMA) where 
>>>>fallback will never be used, so for that reason I don't think we should make it a MUST.
>>>
>>>SIP networks, and usually commercial IP/TCP routers (those provided by the Internet Provider) come with builtin SIP ALG enabled by default.
>I don't know, I just hate SIP ALG's. 

I thought you knew how 99% of the ALGs work... ;)

>I would like SIP ALG's not no exist anymore as I don't want my router to inspect and modify my application layer data.

Sessmatch is not going to either increase or decrease the number of ALGs, and thinking so is naive in my personal opinon. 

ALGs are deployed for many reasons (we can argue whether they are valid or not, but that's another discussion) - reasons that in most cases have bigger priority than allowing MSRP traffic.

Also note that sessmatch allows end-to-end TLS for MSRP, in which case the ALG will not be able to inspect your data. Without sessmatch you don't have that possibility, as an ALG must modify MSRP (without breaking it).

The main reason for sessmatch is *not* to allow inspection of your data, but rather to AVOID having to inspect and modify your data, and just treat it as any other media.

Most SIP ALGs today modify the SDP c/m-line, so MSRP is already broken. Not even sessmatch will work with such ALGs. 

Now, updating an ALG to modify the a=path attribute for MSRP is a relatively easy task, compared to forcing them to be updated in order to process MSRP media. It's not only about software, since some nodes may not even have resources to do that.

So, sessmatch provides a better chance of being able to do MSRP in networks where ALGs are deployed. Sure, there are limitations, but sessmatch doesn't "break" anything that isn't already broken.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 15:11:19 +0200

Hi Gonzallo,

I am wondering. If the only applicability of sess-match is for deploying a service behind an OMA style walled garden, why does it have to be an IETF document about it?  It can be an OMA or 3GPP specification, that is fine. Is architecture in the end,  how to use (or miss-use) existing protocols for achieving some purpose, not a protocol specification.

Why an IETF one that explicitly breaks what has already been created so far? Creating a standard for how to insert intermediaries in a working protocol? Leaving a door open for all possible problems that will emerge out of this?

This is not rhetorical, I just try to understand why a non-interoperable standard with execrable security and integrity properties which has nothing to do with public Internet is developed within the IETF? Isn't it possible to just pass the ball away to where it belongs? OMA, 3GPP or other organization that cares about it.

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 15:36:53 +0200

> So, sessmatch provides a better chance of being able to do MSRP in networks where ALGs are deployed. Sure, there are limitations, but sessmatch doesn't "break" anything that isn't already broken.

Hi Christer, I understand your point at 100%. To summarize:

1) SIP ALG's are a pain and should not exist.

2) But SIP ALG's do exist and we cannot change that, even less when
router manufactures add it as a "feature" (by hiring an ignorant
developer for 4 hours to make a regular expression if the destination
port is 5060).

3) Routers with SIP ALG "could" work (just talking about signalling
and RTP) as the specifications do not prevent it. But they fail in 99%
of cases.

4) Routers with SIP-MSRP ALG *breaks* (yes or yes) the MSRP specification.

5) Anyhow router vendors wants to offer these ALG's.

6) IETF SIMPLE WG gets in action to save the world and publishes a
specification to make such ALG's to work. The fact that the draft
talks about "sessmatch" (instead of full URI matching) is just an
anecdota as the mechanism is just needed when a non SIP/MSRP node (ALG
box) wants to manipulate application layer data (SIP). If just pure
SIP/MSRP nodes speak SIP and MSRP, "sessmatch" is not needed at all.

7) Such new specification breaks existing MSRP (as known in RFC 4975
and 4976). It makes router vendors happy, but corrupts the world.

Given point 7, point 6 should not take place IMHO. I don't think
IETF's business includes making happy to ignorant vendors.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 15:49:23 +0200

> This is not rhetorical, I just try to understand why a non-interoperable standard with execrable security and integrity properties which has nothing to do with public Internet is developed within t…

100% agreed.

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 25 May 2011 19:54:05 -0600

Most IETF specs are held to the standard of being usable on the internet. I'm trying to figure out a pragmatic way forward. In other cases like this we have sometimes published an historic RFC with a title along the lines of "OMA's Session Matching Optimization for MSRP" and clearly outline that is applicable for networks where all clients are known to implement it. 

One thing I don't think we should do is publish a spec that breaks backwards compatibility with existing MSRP clients. I know Christer has worked hard to try and make there be a reasonable fallback mechanisms and I am please to hear that some vendors would implement it. I think the key thing is look at the trade off of how much performance gain this optimization provides vs the breakage it can cause when used outside the context of a 3GPP or OMA environment. I think it is pretty clear that most ALGs will not fall back to B2BUA mode. If they had the code to do that they would act as B2BUA based SBC in the first place and never even bother with all the nightmares of being an ALG.