Subject: [Simple] Sessmatch - an alternative approach

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 May 2011 21:40:25 +0200

Hi,
 
Based on the issues that have been raised on sessmatch, I would like to present a modified version, that solves some of the raised issues related to security, backward compability, usage of the Require header filed, and specifying of ALG behavior. It has the following advantages over the current sessmatch mechanism:
 
1. Except for one case, that still requires MSRP B2BUA, it works with "legacy" SIP-ALGs (that only modify the SDP c/m line, but not the a=path) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA;
 
2. It works with name based authentication;
 
3. It works when a 4975 UA is behind a relay;

4. It works without a need for the offerer, or for the SIP-ALG, to use the Require header field; and
 
5. It atually REMOVES the need to update the session matching procedure in the first place :)

The idea is based on the very original sessmatch proposal, where a sessmatch UA sends the TCP SYN for the MSRP connection based on the SDP c/m-line, rather than the a=path.

BUT, the sessmatch UA still inserts the a=path MSRP URI into the MSRP message, use it for name based authentication, and use if for session matching - all according to existing RFC 4975 procedures.

Let's look at how it works.

Peer-to-peer (no SIP-ALG)
-----------------------------

As in the current sessmatch proposal, there is still full backward compability. As the a=path and SDP c/m-line values will be identical, it doesn't matter which the sessmatch UA uses for sending the TCP SYN. 

(In fact, we could even specify that the sessmatch UA uses the a=path in case it is identical to the SDP c/m-line, and everything would be identical to RFC 4975.)

SIP-ALG in the path
---------------------

1. A sessmatch UA sends a request that offers MSRP, and includes a sessmatch support indication (option-tag, SDP attribute, or whatever we choose).

2. The SIP-ALG modifies the SDP c/m-line of the offer, and the corresponding answer, in order to anchor the MSRP media. The a=path is NOT modified.

3. The sessmatch UA receives the answer from the remote UA.

4a. If the remote UA supports sessmatch, everthing is fine. Whoever is "active" sends the TCP SYN according to the SDP c/m line (which points to the ALG).

4b. If the remote UA does NOT support sessmatch, BUT is "passive" (default if it does not support MSRP ACM), everything is fine. The sessmatch sends the TCP SYN according to the SDP c/m line (which points to the ALG).

4c. If the remote UA does NOT support sessmatch, AND is "active", things will NOT work (unless SIP-ALG bypass is allowed), as the remote UA will try to send the TCP SYN according to a=path (which points to the sessmatch UA, rather than to the ALG).

5. In case of 4c, the sessmatch UA does a "fallback" to 4975, by sending a new offer where it does NOT include a sessmatch support indication. The SIP-ALG, in order to support MSRP, will now have to enable MSRP B2BUA functionality.

It works the same in the other direction, where the 4975 UA sends the offer. If the 4975 UA becomes "active", the sessmatch UA will have to send an offer without sessmatch indication.

Regards,
 
Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 30 May 2011 22:52:05 +0200

> Peer-to-peer (no SIP-ALG)

This is an useful way not to "corrupt" the original and already
standardized specification :)

But in this case, I suggest that a sessmatch UA MUST use a separate
"c" line for the MSRP connection. If not and if the UA also offers
audio/video RTP, the ALG would force all the sessions to go through
the ALG. Am I wrong?

> 4b. If the remote UA does NOT support sessmatch, BUT is "passive" (default if it does not support MSRP ACM), everything is fine. The sessmatch sends the TCP SYN according to the SDP c/m line (which…

In this case, it would occur that the remote (not supporting
sessmatch) would receive the MSRP connection from an IP different than
the indicated in the a=path. Could that suppose a problem? Just
wondering.

> 4c. If the remote UA does NOT support sessmatch, AND is "active", things will NOT work (unless SIP-ALG bypass is allowed), as the remote UA will try to send the TCP SYN according to a=path (which p…

In fact, this could always work (correct me if I'm wrong) if the ALG
MUST allow bypass, so it could not (in this case) stay into the MSRP
path. I see no other issues, are there?

> 5. In case of 4c, the sessmatch UA does a "fallback" to 4975, by sending a new offer where it does NOT include a sessmatch support indication. The SIP-ALG, in order to support MSRP, will now have t…

I'm still afraid of this fallback mechanism. Probably Ericsson SBC
would implement it correctly, but I expect that other ALG boxes (let's
say Chin-Chon-Xu Technologies, CheapBoxForever-Pro,
Amateur-Xiun-Dragon-IPTech routers) will not implement it (or not
correctly). So, wouldn't be better just to mandate ALG boxes to allow
ALG-bypass? In fact, how is supposed an ALG could NOT allow bypass?
how could it deny that an UA tries to connect to the URI in the
a=path?

Anyhow I don't understant point 5:

a) How does sessmatch UA realize that the remote UA does not support sessmatch?

b) Let's suppose there is a good reply for a) (sure it's but I miss it
now). Then sessamtch UA terminates the dialog (is it?) and sends a new
INVITE not indicating sessmatch support. In this case the ALG could do
just nothing (bypass as said above) and things would work. Of course,
if due to NAT things cannot work (and there is no MSRP relay set for
the remote UA) the ALG should become a MSRP B2BUA in order to make it
to work.

Please correct em if I'm wrong.

> It works the same in the other direction, where the 4975 UA sends the offer. If the 4975 UA becomes "active", the sessmatch UA will have to send an offer without sessmatch indication.

IMHO you are in the correct way now ;)

Thanks a lot for your re-worked work.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 31 May 2011 08:15:54 +0200

Hi, 

>>As in the current sessmatch proposal, there is still full 
>>backward compability. As the a=path and SDP c/m-line values 
>>will be identical, it doesn't matter which the sessmatch UA 
>>uses for sending the TCP SYN.
>> 
>This is an useful way not to "corrupt" the original and 
>already standardized specification :)
> 
>But in this case, I suggest that a sessmatch UA MUST use a 
>separate "c" line for the MSRP connection. If not and if the 
>UA also offers audio/video RTP, the ALG would force all the 
>sessions to go through the ALG. Am I wrong?

Yes, I think so :)

If the ALG only wants to anchor only SOME of the media streams, it can itself "split" the session level "c" line into separate media level "c" lines.

(From my personal expereince, though, if an ALG decides to anchor media, it normally anchors ALL media.)

>>SIP-ALG in the path
>>---------------------
>>
>>
>> 1. A sessmatch UA sends a request that offers MSRP, and 
>> includes a sessmatch support indication (option-tag, SDP 
>> attribute, or whatever we choose).
>> 
>> 
>> 2. The SIP-ALG modifies the SDP c/m-line of the offer, and 
>> the corresponding answer, in order to anchor the MSRP media. 
>> The a=path is NOT modified.
>> 
>> 
>> 4a. If the remote UA supports sessmatch, everthing is fine. 
>> Whoever is "active" sends the TCP SYN according to the SDP 
>> c/m line (which points to the ALG).
>> 
>> 
>> 4b. If the remote UA does NOT support sessmatch, BUT is 
>> "passive" (default if it does not support MSRP ACM), 
>> everything is fine. The sessmatch sends the TCP SYN according 
>> to the SDP c/m line (which points to the ALG).
> 
>sessmatch) would receive the MSRP connection from an IP 
>different than the indicated in the a=path. Could that 
>suppose a problem? Just wondering.

I was thinking the same, but could not find any text saying that. According to 4975 the a=path is used for sending TCP SYN, performing session matching and performing TLS name based authentication.

So, the remote UA accepts the TCP connection, and then use authentication etc to verify the sender etc.

(Also remember that, in SDP, the received IP address does not tell from where a connection is supposed to come.)

>> 4c. If the remote UA does NOT support sessmatch, AND is 
>> "active", things will NOT work (unless SIP-ALG bypass is 
>> allowed), as the remote UA will try to send the TCP SYN 
>> according to a=path (which points to the sessmatch UA, rather 
>> than to the ALG).
> 
>In fact, this could always work (correct me if I'm wrong) if 
>the ALG MUST allow bypass, so it could not (in this case) 
>stay into the MSRP path.

Yes. But, we cannot mandate bypass. There are reasons, whether we like them or not, why ALGs anchor media, and we cannot change that fact. See more on this at the end of the reply.

Having said that, we can of course add some text saying that IF bypass is allowed and possible, there is no problem :)

>>I see no other issues, are there?
>>
>>
>> 5. In case of 4c, the sessmatch UA does a "fallback" to 
>> 4975, by sending a new offer where it does NOT include a 
>> sessmatch support indication. The SIP-ALG, in order to 
>> support MSRP, will now have to enable MSRP B2BUA functionality.
> 
> I'm still afraid of this fallback mechanism. Probably 
> Ericsson SBC would implement it correctly, but I expect that 
> other ALG boxes (let's say Chin-Chon-Xu Technologies, 
> CheapBoxForever-Pro, Amateur-Xiun-Dragon-IPTech routers) will 
> not implement it (or not correctly). So, wouldn't be better 
> just to mandate ALG boxes to allow ALG-bypass? In fact, how 
> is supposed an ALG could NOT allow bypass?
> how could it deny that an UA tries to connect to the URI in 
> the a=path?

The ALG may never even see the TCP SYN, as the a=path points towards the sessmatch UA.

Of course, if bypass is allowed, the sessmatch UA might get the TCP SYN, and everything works, but if bypass is not allowed there will probably be e.g. some firewall somewhere that only passes traffic addressed towards the ALG.

In general, why would a provider buy an ALG that suddenly prevents customers to use a service - MSRP in this case? It is very easy for customers to change provider nowadays, so I think the market and competition will ensure that things that are supposed to work will work. 

Of course, if a provider does not want to allow MSRP in the first place, it does not really matter what we specify :)

Also, sometimes things wouldn't work if bypass was allowed, if the ALG performs e.g functions related to NAT traversal, IP version interworking, and/or signalling compression/encryption (e.g. the IMS P-CSCF).

>a) How does sessmatch UA realize that the remote UA does not 

There is no indicator (option-tag, SDP attribute, etc) in the response. 

I guess I forgot to write that, in case of 4a, the remote UA inserts a sessmatch support indicator in the response.

>b) Let's suppose there is a good reply for a) (sure it's but 
>I miss it now). Then sessamtch UA terminates the dialog (is 
>it?) and sends a new INVITE not indicating sessmatch support. 
>In this case the ALG could do just nothing (bypass as said 
>above) and things would work. Of course, if due to NAT things 
>cannot work (and there is no MSRP relay set for the remote 
>UA) the ALG should become a MSRP B2BUA in order to make it to work.
> 

I don't think you're wrong.

However, the sessmatch UA does not necessarily have to terminate the dialog. It could send the new offer in a re-INVITE/UPDATE within the existing dialog, and the SIP-ALG would enable MSRP B2BUA. It is fully possible for an ALG to do that mid-dialog. And, at least in cases where preconditions are used, this would not even cause any additional signalling.

But, we can of course let the sessmatch UA decide for himself whether he terminates the dialog or not. The important thing is that it sends a new offer without sessmatch support indication.

>>It works the same in the other direction, where the 4975 UA 
>>sends the offer. If the 4975 UA becomes "active", the 
>>sessmatch UA will have to send an offer without sessmatch indication.
> 

Thank You for your comments :)

I realize it is not 100% perfect, as there is one case where MSRP B2BUA is still needed. But, I'm afraid this is the best I can offer :)

I do think, however, that this would be a big step forward, as it does solve a number of issues that have previsouly been raised.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 31 May 2011 12:28:29 +0200

> (From my personal expereince, though, if an ALG decides to anchor media, it normally anchors ALL media.)

Sure, but in case of just wanting to anchor MSRP media, I expect it
would be much easier the UA to set a separate "c" line for MSRP rather
than the AGL rewriting the SDP by adding a specific "c" line within
MSRP section :)

That's why I suggest "the seesmatch UA SHOULD set a separate "c" line
for its offered MSRP media" in the specification. But maybe this is
not so important.

> I was thinking the same, but could not find any text saying that. According to 4975 the a=path is used for sending TCP SYN, performing session matching and performing TLS name based authentication.

Neither I'm aware of a text stating that it could be an issue.

> (Also remember that, in SDP, the received IP address does not tell from where a connection is supposed to come.)

100% right, so forget my objection.

> Yes. But, we cannot mandate bypass. There are reasons, whether we like them or not, why ALGs anchor media, and we cannot change that fact. See more on this at the end of the reply.

Yes, network topology could "denny by itself" the bypass. I just meant
that the ALG box is not supposed to "deny" it.

> Having said that, we can of course add some text saying that IF bypass is allowed and possible, there is no problem :)

It would be nice. And in case the ALG is aware that without sessmatch
things would not work, it could decide to behave as a MSRP B2BUA and
so. But mandating (MUST) that the ALG becomes a MSRP B2BUA is a bit
utopian IMHO.

So with new changes in this spec, an ALG B2BUA doesn't break anymore
MSRP relayes. In case of doble NAT scenarios where there is no MSRP
relays and both UA's don't support sessmatch, then I suggest let
things not work (ALG just does bypass and MSRP connection would just
fail). It obvious that this scenario would also not work if the router
is not an ALG so, why to mandate the ALG to become a MSRP B2BUA by
specs? I don't think an ALG should be specifiied to make "magic" :)

In the previous version of this draft, it could make sense (becoming a
MSRP B2BUA) as the ALG did break normal MSRP scenarios, but now I see
no reason for that.

> Of course, if bypass is allowed, the sessmatch UA might get the TCP SYN, and everything works, but if bypass is not allowed there will probably be e.g. some firewall somewhere that only passes traf…

So same as above. In such scenario MSRP would not work even if the
router is not an ALG. Why to mandate that, in case the router is an
ALG, it must become a MSRP B2BUA?

> I guess I forgot to write that, in case of 4a, the remote UA inserts a sessmatch support indicator in the response.

Ok.

> But, we can of course let the sessmatch UA decide for himself whether he terminates the dialog or not. The important thing is that it sends a new offer without sessmatch support indication.

Ok.

> I realize it is not 100% perfect, as there is one case where MSRP B2BUA is still needed. But, I'm afraid this is the best I can offer :)

Correct me if I'm wrong. I'm saying same as above again:

In the case you mean MSRP just would work if the ALG would become a
MSRP B2BUA, am I right? would MSRP work if the router is not an ALG?
If not, I see no reason to mandate the ALG becoming a exotic MSRP B2BUA.

Honestly I feel much more comfortable with this spec not breaking the
existing world rather than trying to solve all the problems of the
world :)

> I do think, however, that this would be a big step forward, as it does solve a number of issues that have previsouly been raised.

Sure :)

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 31 May 2011 19:49:58 +0200

Hi,

>than the AGL rewriting the SDP by adding a specific "c" line within

Sure, but that applies to all types of media.

>for its offered MSRP media" in the specification. But maybe this is

I personally think such a statement would be more useful e.g. in a general offer/answer document.

>so. But mandating (MUST) that the ALG becomes a MSRP B2BUA is a bit

It all depends whether the ALG needs (based on operator policy and/or pure technical reasons) to anchor the media or not.

>specs? I don't think an ALG should be specifiied to make "magic" :)

Routers don't modify SIP messages, or anchor media - they normally only forwards IP packages, so they would not need to become MSPR B2BUAs.

>MSRP B2BUA) as the ALG did break normal MSRP scenarios, but now I see

The reason is the same (eventhough due to different technical reasons): in order to be able to provide an MSRP service (in cases where media anchoring is needed).

>ALG, it must become a MSRP B2BUA?

IF the ALG needs to anchor media, and IF the ALG wants to support MSRP.

>MSRP B2BUA, am I right?

IF the ALG needs to anchor media, and does NOT allow (for whatever reasons) bypass, yes.

>would MSRP work if the router is not an ALG?

As I said earlier, routers don't need to become MSRP B2BUAs. Only ALGs that need to anchor MSRP will need to support MSRP B2BUA - as is the case already today, with or without sessmatch :)

>existing world rather than trying to solve all the problems of the

I'll wait and see if someone else has a different opinion, before updating the draft. It will require quite much re-wording.

Also, we may have to change name of the mechanism, as we aren't really talking about session matching anymore :)

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 31 May 2011 16:32:40 -0500

Hi,

How does this work when the peer is behind an MSRP Relay? Keep in mind that, in this case, the c/m lines will refer to the endpoint itself, not to the relay.

Thanks!

Ben.

On May 30, 2011, at 2:40 PM, Christer Holmberg wrote:

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

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Wed, 1 Jun 2011 08:14:58 +0200

Hi,

> It all depends whether the ALG needs (based on operator policy and/or pure technical reasons) to anchor the media or not.

Lets take the following case: Alice is NOT behind a MSRP ALG and is NOT sessmatch capable. Bob is sessmatch enabled and he is behind one of these ALGs. If Alice tries to establish a MSRP session towards Bob (Alice being the active party) the ALG will know that it can't anchor the media unless it falls back to B2BUA mode, right?

So, assuming the answer to the previous question is 'yes', will the fallback to B2BUA mode be mandatory for ALGs?

> I'll wait and see if someone else has a different opinion, before updating the draft. It will require quite much re-wording.

I also feel better about the new approach. Looks like a way forward, good work :-)

> Also, we may have to change name of the mechanism, as we aren't really talking about session matching anymore :)

Definitely, sessmatch does not really apply as a name anymore :-)

Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 1 Jun 2011 08:16:23 +0200

2011/5/31 Christer Holmberg <[email-masked]>:
> Routers don't modify SIP messages, or anchor media - they normally only forwards IP packages

Unfortunatelly routers do modify SIP messages as lot of them come with
SIP ALG enabled by default:

  http://www.voip-info.org/wiki/view/Routers+SIP+ALG

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2011 08:22:52 +0200

Hi, 

>Unfortunatelly routers do modify SIP messages as lot of them 
>come with SIP ALG enabled by default:
> 

Sure, but then they aren't "plain" routers anymore. My point was that you don't need to add SIP-ALG functionality to your plain routers because of this.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 1 Jun 2011 08:23:40 +0200

> Also, we may have to change name of the mechanism, as we aren't really talking about session matching anymore :)

As a suggestion, correct me if I'm wrong but I'm pretty sure that this
new specification provides no added value to existing
scenarios/implementations in which there are not ALG boxes. So this
specification is just useful for the case in which there is a
MSRP-aware ALG box within the network (and such box wants to anchor
the media).

So I suggest including the word "ALG" somewhere in the draft title
just for clarifications (i.e. "A technique for anchoring MSRP streams
in ALG boxes").

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 1 Jun 2011 08:32:33 +0200

> How does this work when the peer is behind an MSRP Relay? Keep in mind that, in this case, the c/m lines will refer to the endpoint itself, not to the relay.

I would add another scenario:

- Alice (not sessmatch UA) uses an outbount MSRP relay and wants to
establish a MSRP session with Bob who is behind an ALG.

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

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Wed, 1 Jun 2011 08:36:43 +0200

Hi,

> establish a MSRP session with Bob who is behind an ALG.

I might be missing something, but does it really affect the fact that Alice is using an outbound relay? It looks to me that it doesn't (alice being NOT sessmatch capable).

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2011 08:49:17 +0200

Hi, 

>Lets take the following case: Alice is NOT behind a MSRP ALG 
>and is NOT sessmatch capable. Bob is sessmatch enabled and he 
>is behind one of these ALGs. If Alice tries to establish a 
>MSRP session towards Bob (Alice being the active party) the 
>ALG will know that it can't anchor the media unless it falls 
>back to B2BUA mode, right?

It depends on whether Alice becomes "active" or "passive".

If Alice becomes "passive", Bob will send the TCP SYN according to c-line (which points to the ALG), and in that case there is no need for B2BUA mode.

If Alice becomes "active", she will try to send the TCP SYN according to the a=path (which points to Bob - not the ALG), which often will fail. So, the idea is that Bob sends a new offer, without the sessmatch indicator, in order to trigger fallback to 4975. In that case, the ALG will have to enable B2BUA mode.

>So, assuming the answer to the previous question is 'yes', 
>will the fallback to B2BUA mode be mandatory for ALGs?

Yes, it is still mandatory, for the case when the 4975 UA is "active". The difference is that the cases where B2BUA mode is needed has decreased, which is good because of the negative performance impacts it brings.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 1 Jun 2011 08:53:02 +0200

> I might be missing something, but does it really affect the fact that Alice is using an outbound relay? It looks to me that it doesn't (alice being NOT sessmatch capable).

I just wonder whether the ALG could make something wrong when
manipulating or inspecting the a=path line with various entries. I
expect there is no problem, just wondering.

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

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Wed, 1 Jun 2011 08:56:42 +0200

Hi,

Ok.

> Yes, it is still mandatory, for the case when the 4975 UA is "active". The difference is that the cases where B2BUA mode is needed has decreased, which is good because of the negative performance i…

Great! I really like that we have this as a must, it means we have no breakage when users behind an ALG and users not behind an ALG interact with each other :-)

Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2011 08:58:31 +0200

Hi Ben, 

>How does this work when the peer is behind an MSRP Relay? 
>Keep in mind that, in this case, the c/m lines will refer to 
>the endpoint itself, not to the relay.

You are probably right. If the 4975 UA is behind a relay, the sessmatch UA needs to trigger a fallback to 4975 (in a similar way as when the 4975 UA is "active"). The sessmatch UA can do if it detects that the remote SDP contains multiple a=path attributes, indicating that there is relay(s) in the path.

The reason is that the 4975 UA has inserted its own address in the SDP c-line (at least I can't find text in RFC 4976 which says otherwise), so the ALG would try to connect to the 4975 UA rather than the relay.

Good point!

Regards,

Christer

> > Based on the issues that have been raised on sessmatch, I 
> would like to present a modified version, that solves some of 
> the raised issues related to security, backward compability, 
> usage of the Require header filed, and specifying of ALG 
> behavior. It has the following advantages over the current 
> sessmatch mechanism:
> > 
> > 1. Except for one case, that still requires MSRP B2BUA, it 
> works with 
> > "legacy" SIP-ALGs (that only modify the SDP c/m line, but not the 
> > a=path) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA;
> > 
> > 4. It works without a need for the offerer, or for the 
> SIP-ALG, to use 
> > the Require header field; and
> > 
> > The idea is based on the very original sessmatch proposal, 
> where a sessmatch UA sends the TCP SYN for the MSRP 
> connection based on the SDP c/m-line, rather than the a=path.
> > 
> > BUT, the sessmatch UA still inserts the a=path MSRP URI 
> into the MSRP message, use it for name based authentication, 
> and use if for session matching - all according to existing 
> RFC 4975 procedures.
> > 
> > 
> > (In fact, we could even specify that the sessmatch UA uses 
> the a=path 
> > in case it is identical to the SDP c/m-line, and everything 
> would be 
> > identical to RFC 4975.)
> > 
> > 
> > SIP-ALG in the path
> > ---------------------
> > 
> >