Subject: [Simple] About draft-ietf-simple-sessmatch

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 24 May 2011 21:48:11 +0200

Hi, I'm trying to understand motivation and rationale for this draft.
Please let me know if the following points (those I've understood by
reading the text) are correct:

1) This draft is just useful for vendors manufacturing MSRP entities
behaving as ALG devices (even if the concept of "ALG" is vaguely
defined for SIP) instead of behaving as full B2BUA. These devices
(probably IP routers) just want to change/replace some line in the SDP
and expect that TCP would do the rest.

2) MSRP mandates TLS (which is good) but this draft breaks TLS name
based authentication (and suggests implementing other specifications,
some of them still drafts, as alternative).

3) The mechanism proposed in this draft is already adopted by OMA in
their specifications for SIP/MSRP over mobile networks.

About point 1)

Let's suppose I want to build a SIP client implementing MSRP (with
support for MSRP protocol and MSRP relays). It should be enough as
MSRP relays are supposed to fix NAT issues. But now big vendors arrive
and decide that they want to control/monitor/manage all the MSRP
sessions. Also they don't want to build MSRP relays (as the clients
could avoid them), neither full B2BUA (which are complex/expensive),
but just want to force such MSRP inspection at IP/TCP level, so voila:
they impose routers with ALG.

So now, if I want my SIP UA to interoperate with those ALG devices, I
need to implement this draft. Yes, the draft says something about
these ALG devices becoming a B2BUA in case they connect with a client
not supporting this specification, but let's be honest: do we really
expect a MSRP ALG device will become a SIP/MSRP full B2BUA just for
these cases? It's easier to force the clients to buy "certificated"
SIP/MSRP clients.

About point 2)

A problem in most of the SIP related specifications is the abuse of
MAY and COULD words, so finally each implementor gets his own
interpretation. MSRP RFC, however, mandates (SHOULD) the usage of TLS
(TCP is for debugging purposes). This is good, very good. But now this
draft makes it difficult, just to satisfy vendors of intermediary MSRP
entities. Is it a good standardization decision?

In conclusion (just my conclusion):

Advantages of this draft
----------------------------------

- For big vendors:
  - ALG routers are cheaper than full MSRP relays or full B2BUA (for
SIP and MSRP).
  - They can control/monitor/inspect users's MSRP traffic (as it's
done at IP/TCP level)
    and UA's cannot avoid them.

- For SIP&MSRP UA's developers:
  - No advantages.

- For final users:
  - No advantages.

Disadvantages of this draft
---------------------------------------

- For big vendors:
  - No disadvantage.

- For SIP&MSRP UA's developers:
  - Must implement this draft to interoperate with vendors implementing it.
  - Broken TLS name authentication (or invest long time and resources
implementing
    supposed alternatives).

- For final users:
  - Must buy/get a UA supporting this specification.

Honestly I cannot understand how this draft exists. SIP and MSRP work
on top of the transport layer so if a vendor wants to play with my
MSRP traffic it should at least work at SIP/MSRP level (this is: build
a full SIP/MSRP B2BUA and don't bother the rest of SIP/MSRP devices
and implementors).

Just my opinion. Best regards.

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

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 00:17:06 +0200

Hello,

My comment about this draft is:

This drafts describes a horrible hack for how to render an otherwise well designed protocol useless. It is an absolute shame to make a standard out of it.

By letting this draft become a standard, the interoperability of SIP applications beyond VoIP will be completely broken as developers will not be able to navigate through the exceptions and broken assumptions implied by the proposed mechanism. All security and integrity properties of MSRP protocol become useless by doing it just because some clueless people mentioned it in the past in an OMA document which is full of broken assumptions, this one included. This "thing" should not have never been an MSRP related document at all, it should have described a complete different protocol all together so that people do not get confused by it.

I have implemented all SIMPLE WG related MSRP specifications to date and everything made sense until this draft showed up. This does not make sense.

This is a horrible way for SIMPLE WG to complete its agenda after having produced an excellent suite of MSRP standards.

Best regards,
Adrian

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 May 2011 18:29:52 -0600

I had promised myself not to spend more time on this whole topic but reading your Adrian's comments made me laugh so hard that I that once again I will make the mistake of replying. I predict the text that is being added to allow for this to interoperate with MSRP endpoint or to mitigate the security breakage will be ignored by 100% of people that implement the draft. The gains over just doing and SBC seem shockingly small given the breakage introduced. 

On May 24, 2011, at 1:48 PM, Iñaki Baz Castillo wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 09:04:46 +0200

Cullen,

I am deeply sorry for having to interupt your laughing, but if you could take a few moments to read the following.

First, the text is very much based on the discussions we had in Prague - discussions that you yourself were part of, and which outcome and way forward I had the impresstion that your were ok with. If you don't think the text reflects those discussions, I would be very happy with text proposals on how to correct that.

Second, I can inform you that there is at least one (that I am aware of) vendor that plans to implement a "fallback mechanism", for interoperability purpose.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]
Sent: Wednesday, May 25, 2011 3:29 AM
To: Iñaki Baz Castillo
Cc: Simple WG
Subject: Re: [Simple] About draft-ietf-simple-sessmatch

---

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

Hi,

>and expect that TCP would do the rest.

Correct.

In addition, for NAT traversal purpose, people want to re-use infrastructure used also for other types of media, rather than having to deploy MSRP relays.

>their specifications for SIP/MSRP over mobile networks.

It is also adopted by 3GPP, and I know that people want to use it also in non-IMS/OMA networks.

>these cases? It's easier to force the clients to buy "certificated"

I don't know what customers you have, if you can "easily force" them to buy things...

But, at the end of the day, no matter what functionality we talk about, customers put requirements on what is going to be implemented.

And, as I also indicated to Cullen, at least one vendor is planning to implement a "fallback mechanism", in order to support interoperability.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 10:43:22 +0200

Hi,

> Second, I can inform you that there is at least one (that I am aware of) vendor that plans to implement a "fallback mechanism", for interoperability purpose.

Unless everyone does that there no certainty that endpoints doing MSRP today will continue to interoperate. Moreover, we are doing MSRP *today*: relay support, ACM (started the implementation when in draft state, and updated it when RFC was published) and even this sessmatch (draft 10 implemented), we don't plan to support anything, we already do. We implemented all standards available, yet unless we support this draft there could be serious interoperability issues, something doesn't feel right.

And those are my two cents.

Regards,

Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 11:08:30 +0200

> In addition, for NAT traversal purpose, people want to re-use infrastructure used also for other types of media, rather than having to deploy MSRP relays.

Ok. Perhaps authors of MSRP could take those so important "real-life"
requeriments into account *before* designing MSRP protocol (RFC 4975
and 4976)?
Basically current draft destroys compatibility with clients/servers
implementing MSRP and MSRP relays, so we have two islands that cannot
talk one to each other. The draft talks about "MSRP" but IMHO it
should become a new protocol.

> at least one vendor is planning to implement a "fallback mechanism", in order to support interoperability.

Most of the today's SIP ALG routers break, in some way, the SIP signalling:
  http://www.voip-info.org/wiki/view/Routers+SIP+ALG

I mean 99.99% of SIP ALG routers I've tested (even most expensives).
And do you expect me to believe that a SIP+MSRP ALG/SBC which
magically becomes a full B2BUA ("fallback mechanism") will work ok?
Sorry but I can't, too much bad experiences with SIP ALG routers ;)

SIP and MSRP works on top of the transport layer. Writting a
specification for application level inspection within IP/TCP routers
makes no sense IMHO.

BTW: Why does not this draft state that a MSRP relay should also
understand "sessmatch"? are there other issues that prevent a MSRP
relay to communicate with a ALG/SBC implementing this draft? (I
already know about the TLS name based authentication
limitation/problem).

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

---

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

2011/5/25 Saúl Ibarra Corretgé <[email-masked]>:
> yet unless we support this draft there could be serious interoperability issues, something doesn't feel right.

Vendors of ALG/SBC will be happy. It seems important enough to break a
protocol. Sad.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 11:22:01 +0200

Hi,

>>First, the text is very much based on the discussions we had in Prague - discussions that you yourself were part of, and which outcome and way forward I had the impresstion that your were ok with. If 
>>you don't think the text reflects those discussions, I would be very happy with text proposals on how to correct that.
>>
>Unless everyone does that there no certainty that endpoints doing MSRP today will continue to interoperate.

What will be implemented is, as for ANY technology, eventually based on customer requirements, and what type of entities they need to serve.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 11:31:23 +0200

Hi,

>requeriments into account *before* designing MSRP protocol (RFC 4975

As Cher would put it: If I could turn back time...

>Sorry but I can't, too much bad experiences with SIP ALG routers ;)

I expect that SIP ALGs will do whatever customers require them to do...

...and if they don't, the customers will most likely go somewhere else.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 11:44:08 +0200

> What will be implemented is, as for ANY technology, eventually based on customer requirements, and what type of entities they need to serve.

So, we can potentially break interoperability because vendor X wants a simple approach (sessmatch) instead of implementing a proper MSRP B2BUA. Personally I would only agree on going further with sessmatch if the fallback mechanism was specified as a MUST.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 12:02:20 +0200

Hi, 

>>>>First, the text is very much based on the discussions we had in 
>>>>Prague - discussions that you yourself were part of, and which outcome and way forward I had the impresstion that your were ok with. If you don't 
>>>>think the text reflects those discussions, I would be very happy with text proposals on how to correct that.
>>>> 
>So, we can potentially break interoperability because vendor X wants a simple approach (sessmatch) instead of implementing a proper MSRP B2BUA. 

Because customer X wants a simple approach in order to deploy standard MSRP in the first place.

>Personally I would only agree on going further with sessmatch if the fallback mechanism was specified as a MUST.

Ok.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 12:24:47 +0200

> Because customer X wants a simple approach in order to deploy standard MSRP in the first place.

Standard MSRP?

Let's say MSRP is defined in 3 documents A, B and C (being C this
draft). C breaks A and B. Which kind of standard is it? Maybe C is the
only "standard" customer/vendor X cares about?

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 12:38:01 +0200

What I meant with "standard" is something that's been published as an RFC by IETF. 

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: 25. toukokuuta 2011 13:25
To: Christer Holmberg
Cc: Saúl Ibarra Corretgé; Cullen Jennings; Simple WG
Subject: Re: [Simple] About draft-ietf-simple-sessmatch

Standard MSRP?

Let's say MSRP is defined in 3 documents A, B and C (being C this draft). C breaks A and B. Which kind of standard is it? Maybe C is the only "standard" customer/vendor X cares about?

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

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 12:42:12 +0200

Hello Christer,

In very simple words, your draft simply breaks apart everything MSRP as defined per in RFC 4975 and RFC 4976 stand for.  

You created a complete new protocol with its own behavior that does not interoperate with anything else and you call it MSRP.

This is unacceptable!

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 12:42:19 +0200

> What I meant with "standard" is something that's been published as an RFC by IETF.

...regardless of how many other standards it breaks or corrupts.

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 25 May 2011 12:56:17 +0200

The problem with comments like this, and this is repeating a past comment in the same vein, is that it completely fails to back up the statement with specifics.

Previous arguments seem to have centred round your previous implementation no longer words so the specification must be technical incorrect, but again have not been backed up with specifics, or even any precise statements about which version of the RFC you have actually implemented.

Please make specific technical arguments so we can make our own decision. Which bits of the protocol break and why?

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Georgescu
> Sent: 25 May 2011 11:42
> To: Christer Holmberg
> Cc: Cullen Jennings; Simple WG
> In very simple words, your draft simply breaks apart everything MSRP as
> defined per in RFC 4975 and RFC 4976 stand for.
> 
> You created a complete new protocol with its own behavior that does not
> interoperate with anything else and you call it MSRP.
> 
> This is unacceptable!
> 
> Adrian
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 13:06:22 +0200

> Please make specific technical arguments so we can make our own decision. Which bits of the protocol break and why?

Take the following case: Alice does not support sessmatch but Bob does, and Bob is using a MSRP-sessmatch-enabled ALG/SBC. Whith the current state of the draft, they will not be able to talk to each other unless the ALG falls back to B2BUA mode. This fallback, however is not mandated by the sessmatch draft.

--
Saúl Ibarra Corretgé
AG Projects

---

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

> Please make specific technical arguments so we can make our own decision. Which bits of the protocol break and why?

I think it's very clear. This draft introduces:

- Incompatibility with MSRP endpoints not implementing this draft
(please don't assume that all the vendors will implement a
magic/exotic "fallback mechanism" as it will not occur) => bit reaks
RFC 4975.

- Incompatibility with MSRP relays => it breaks RFC 4976.

- TLS name based authentication broken => it breaks RFC's 4975 and 4976 (again).

So this draft is in detrimental of existing full implementations of
MSRP protocol, and its purpose is just to satisfy vendors of AGL
boxes.

IMHO it's *very* clear that this draft breaks things.

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

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 13:17:52 +0200

Dear Keith,

By saying this you take the innocent approach that this draft is correct and the rest of us concerned has to prove otherwise. The concerns about this draft have been iterated countless of times and are ignored systematically or responded to by further filling up the document with a convoluted workaround logic that departs so much from the reality.

By implementing this draft an implementation will signal and use:

- Different SDP media description
- Different connection model
- Original security properties compromised

This is a different protocol all together, it MUST not be called MSRP just because it uses chunks and some similar headers in some of its  payloads. 

How about taking a different approach? The exiting MSRP implementations are working just fine and the MSRP standards are right, this is confirmed by live deployments.

This draft MUST prove that it interoperates with the existing MSRP standards and MSRP implementations in place. Not the other way around. Otherwise call it something else that does not contain the MSRP in the name.
 
Which approach is more reasonable for you?

Adrian

---

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

Hi, 

>- Different SDP media description

Please explain.

>- Different connection model

Please explain.

The only technical (not taking the security issues into considerations) difference between sessmatch and 4975 is the way it matches MSRP messages to a session.

>How about taking a different approach? The exiting MSRP implementations are working just fine and the MSRP standards are right, this is confirmed by live 

In certain deployments, with certain characteristics, I am sure existing MSRP implementations work just fine. I have never claimed, or seen anyone else claiming, anything else.

The draft tries to explain the scenarios where sessmatch bring value. If you don't think it's clear enough I am happy to add text.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 13:42:21 +0200

> The draft tries to explain the scenarios where sessmatch bring value. If you don't think it's clear enough I am happy to add text.

You must use the word MUST only:

MUST become a full SIP/MSRP ALG to maintain compatibility with the original MSRP specifications.

Adrian

---

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

> In certain deployments, with certain characteristics, I am sure existing MSRP implementations work just fine. I have never claimed, or seen anyone else claiming, anything else.

By specification is clear enough that this draft breaks compatibility
with MSRP entities "just" implementing RFC 4975 and 4976. Who cares
"certain deployments with certain characteristics"? how can that be an
argument? We are talking about a standard.

> The draft tries to explain the scenarios where sessmatch bring value. If you don't think it's clear enough I am happy to add text.

Sessmatch adds no value as it would be never needed if MSRP is not
handled by IP/TCP level boxes. The correct behavior would be MSRP
B2BUA's so sessmatch is just a hack to allow these ALG boxes to work.
sessmatch is not needed at all when handling SIP and MSRP on top of
the transport layer (as it should always be).

Anyhow describing the scenarios in which things work and things don't
work is not enough. A specification based on XXX protocol should not
break XXX protocol itself.

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

---

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

> MUST become a full SIP/MSRP ALG to maintain compatibility with the original MSRP specifications.

Hi Adrian, I think you mean "MUST become a full SIP/MSRP B2BUA" ;)

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

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 13:55:50 +0200

Yes you are right, my mind was cleansed by the ALG poison, so it must read:

"MUST become a full SIP/MSRP B2BUA"

Adrian

---

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

Hi,

How do SIP ALGs work today, when it comes to MSRP?

Regards,

Christer

-----Original Message-----
From: Adrian Georgescu [mailto:[email-masked]] 
Sent: 25. toukokuuta 2011 14:56
To: Iñaki Baz Castillo
Cc: Christer Holmberg; Cullen Jennings; DRAGE, Keith (Keith); Simple WG
Subject: Re: [Simple] About draft-ietf-simple-sessmatch

Adrian

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 14:52:46 +0200

Today SIP ALG breaks SIP most of the time. Actually I have never seen a single one that works and I deployed large SIP for 8 years now. They simply mangle SIP headers without understanding that there is a state machine behind.

This is possible and easy when SIP signaling travels in clear text over UDP, which is today most of the time as it was allowed unfortunately by the same people that care about sess-match today. If traffic was TLS the ALGs would have never existed today and SIP would just work today without the pains we have.

So typically a programmer is hired for 4 hours to implement 'the SIP ALG feature' that a competitor has. He will write 4 lines of code without understanding the state machine of any protocol involved by doing a regexp over clear text to replace strings in the sip packet. Then people crowd on wikipedia to explain how to turn off the feature that breaks SIP. Sad.

If you allow MSRP over TCP, same will happen all over again.

Your draft explicitly creates the possibility for breaking MSRP sessions to pieces by intermediates. It was not possible before, now suddenly it is. The experience shows that this will be abused simply by incompetence if nothing else to the extend that people will perceive that MSRP protocol does not work and is broken. Same like SIP is today.

Adrian

---

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

> Today SIP ALG breaks SIP most of the time. Actually I have never seen a single one that works and I deployed large SIP for 8 years now. They simply mangle SIP headers without understanding that the…

I started a wiki page about specific issues with SIP ALG routers:

Please Christer, take a look to it and later tell me what I should
expect about incoming MSRP-ALG routers.

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

---

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

Well Inaki,

You should already reserve a placeholder there:

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

<h2>Disaster in progress
<p>Stay tuned for updates...

Adrian

---

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

Hi, 

>Today SIP ALG breaks SIP most of the time. Actually I have never seen a single one that works and I deployed large SIP for 8 years now. They simply 
>mangle SIP headers without understanding that there is a state machine behind.
>
>This is possible and easy when SIP signaling travels in clear text over UDP, which is today most of the time as it was allowed unfortunately by the same 
>people that care about sess-match today. If traffic was TLS the ALGs would have never existed today and SIP would just work today without the pains we 
>have.
>
>So typically a programmer is hired for 4 hours to implement 'the SIP ALG feature' that a competitor has. He will write 4 lines of code without 
>understanding the state machine of any protocol involved by doing a regexp over clear text to replace strings in the sip packet. Then people crowd on 
>wikipedia to explain how to turn off the feature that breaks SIP. Sad.
>
>Your draft explicitly creates the possibility for breaking MSRP sessions to pieces by intermediates. It was not possible before, now suddenly it is. The 
>experience shows that this will be abused simply by incompetence if nothing else to the extend that people will perceive that MSRP protocol does not work 
>and is broken. Same like SIP is today.

I am not sure you answered my question, but I guess we can agree that most SIP ALGs today will break MSRP. They will only modify the SDP c/m-line, and they won't modify MSRP media content.

So, sessmatch doesn't break anything that isn't already broken.

On the other hand, sessmatch give a bigger chance of making MSRP to work in scenarios with ALGs, as the only change needed is to modify the SDP a=path attribute.

But, if you think that without sessmatch every ALG is going to implement MSRP B2BUA functionality I guess we have completely different views of the world.

The same if you think that without sessmatch people are going to remove their ALGs, just to make MSRP work.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 15:14:11 +0200

Hi,

> So, sessmatch doesn't break anything that isn't already broken.

Since MSRP does not care about the c and m lines, if the recipient uses a relay MSRP is not broken. Moreover, if the caller is not behind NAT and ACM is being used it would also work, even without a relay. 

Please explain what you mean by "already broken".

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

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

> On the other hand, sessmatch give a bigger chance of making MSRP to work in scenarios with ALGs, as the only change needed is to modify the SDP a=path attribute.

If an ALG modifies the SDP a=path attribute, it is because it wants to
"solve the problem of the NAT", so it will also perform an ugly regexp
over the SIP headers and break the signalling (in 99.99% of cases and
scenarios).

> The same if you think that without sessmatch people are going to remove their ALGs, just to make MSRP work.

Routers vendors are the evil due to their SIP ALG. But IETF SIMPLE WG
should not make a new specification to satisfy them when such new
specification breaks the protocol itself (RFC 4975 and 4976).

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

---

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

Hi, 

>Since MSRP does not care about the c and m lines, if the recipient uses a relay MSRP is not broken. Moreover, if the caller is not behind NAT and ACM is 
>being used it would also work, even without a relay. 

I am not sure I understand. Could you please clarify.

>Please explain what you mean by "already broken".

Unless it is possible to make media by-pass the ALG (which I would assume is prevented in many cases), all media must be anchored by the ALG. That's the reason the ALG modifies the c/m-line. But, as the a=path attribute is not modified, MSRP media won't be sent towards the ALG. 

Regards,

Christer

---

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

An MSRP ALG label will cause vendors to jump on the 'we support that too' train. This is why SIP ALGs don't work, nobody really needed those boxes, nobody asked for them. Both end-users and service providers have a NAT traversal solution in place, in their sip device.  Nobody asked the router manufacturers to build that feature. They did it because it was possible (cleartext UDP) and they thought it is a differentiating factor for their product. It was not, but now we all suffer because we allowed it to happen.

You created the same possibility for MSRP. If anyone can mangle the MSRP packets, they will and all manufacturers will want to 'MSRP ALG enabled' and will abuse this to the extend of rendering the original IETF protocol specifications useless.

Let me quote the mission of IETF:

The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.

sess-match does not fit the profile as a low quality hack and irrelevant for the Internet in general. It serves a narrow purpose for walled gardens outside of the Internet.

This draft should be somewhere else, not in IETF. 

Adrian

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 15:27:17 +0200

> I am not sure I understand. Could you please clarify.

Alice is not behind NAT and sends an INVITE to Bob who is behind NAT. With RFCs 4975 and 4976 this wouldn't work, but if the Alternate Connection Model (RFC 6135) is being used Bob will make the TCP connection to Alice, so no relay is needed at all.

> Unless it is possible to make media by-pass the ALG (which I would assume is prevented in many cases), all media must be anchored by the ALG. That's the reason the ALG modifies the c/m-line. But, a…

There is no standardized definition of what an ALG is nor what should *exactly* do. You are assuming that all media must traverse this ALG or else it will be blocked by a network element such as a firewall. That's assuming too much. MSRP media can flow between even if SIP ALGs are deployed only using already standardized techniques.

--
Saúl Ibarra Corretgé
AG Projects

---

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

Hi, 

>If an ALG modifies the SDP a=path attribute, it is because it wants to "solve the problem of the NAT", so it will also perform an ugly regexp over the 
>SIP headers and break the signalling (in 99.99% of cases and scenarios).

And what does any of that have to do with sessmatch????????????????????????

Sessmatch is not the reason the ALG is deployed, and whatever other things the ALG does it will do with or without sessmatch.

>Routers vendors are the evil due to their SIP ALG. But IETF SIMPLE WG should not make a new specification to satisfy them when such new specification 
>breaks the protocol itself (RFC 4975 and 4976).

I think IETF SIMPLE WG should make specifications that can work in real-life networks.

Regards,

Christer

---

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

Hi,

>An MSRP ALG label will cause vendors to jump on the 'we support that too' train. This is why SIP ALGs don't work, nobody really needed those boxes, 
>nobody asked for them. Both end-users and service providers have a NAT traversal solution in place, in their sip device.

ALGs are also used for many other reasons than NAT traversal.

>You created the same possibility for MSRP. If anyone can mangle the MSRP packets, they will and all manufacturers will want to 'MSRP ALG enabled' and 
>will abuse this to the extend of rendering the original IETF protocol specifications useless.

Sessmatch allows you to do end-to-end TLS, without anyone mangling with your MSRP packets.

And, IF someone really wants to mangle your packets, they can implement a dedicated MSRP B2BUA for that. But, that's not the main reason people want sessmatch.

Regards,

Christer

---

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

Hi, 

>>> Since MSRP does not care about the c and m lines, if the recipient 
>>> uses a relay MSRP is not broken. Moreover, if the caller is not behind NAT and ACM is being used it would also work, even without a relay.
>> 
>Alice is not behind NAT and sends an INVITE to Bob who is behind NAT. With RFCs 4975 and 4976 this wouldn't work, but if the Alternate Connection Model 
>(RFC 6135) is being used Bob will make the TCP connection to Alice, so no relay is needed at all.

And what does that have to do with ALGs? Do you assume that an ALG is not needed? If you assume that the ALG is only used for NAT traversal, that may be true, but I don't think that's very common. 

>>Unless it is possible to make media by-pass the ALG (which I would assume is prevented in many cases), all media must be anchored by the ALG. That's the 
>>reason the ALG modifies the c/m-line. But, as the a=path attribute is not modified, MSRP media won't be sent towards the ALG. 
> 
>There is no standardized definition of what an ALG is nor what should *exactly* do. You are assuming that all media must traverse this ALG or else it 
>will be blocked by a network element such as a firewall. That's assuming too much. MSRP media can flow between even if SIP ALGs are deployed only using 
>already standardized techniques.

I am making assumptions based on real-network experience.

IF you can by-pass the ALG, then you may not need to go via the ALG in the first place, and sessmatch doesn't cause any problems (sessmatch is compatible with 4975 when there are no ALGs between).

Regards,

Christer

---

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

> And what does any of that have to do with sessmatch????????????????????????

Nothing, I just meant that, anyhow, a SIP ALG router will break SIP.

> Sessmatch is not the reason the ALG is deployed.

But ALG is the reason Sessmath is specified.

> I think IETF SIMPLE WG should make specifications that can work in real-life networks.

I don't agree, not in this case.

IP, UDP, TCP, TLS, SIP and MSRP just work. ALG's are not needed at all
and break OSI/Internet layers. IETF should not product a specification
for these horrible and undesirable "intermediaries" which, by nature,
are invalid.

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

---

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

> And what does that have to do with ALGs? Do you assume that an ALG is not needed? If you assume that the ALG is only used for NAT traversal, that may be true, but I don't think that's very common.

Could you please detail other real usages of ALG (in SIP world). I've
seen thousands of SIP-ALG routers and their only purpose is to "solve"
the NAT issue (even if I don't need they to fix that).

> sessmatch is compatible with 4975 when there are no ALGs between.

That's a very cool way to say that sessmatch is not needed at all when
there are no ALGs between.

Regards.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 15:51:37 +0200

> And what does that have to do with ALGs? Do you assume that an ALG is not needed? If you assume that the ALG is only used for NAT traversal, that may be true, but I don't think that's very common. 

I was just pointing out that a current ALG without MSRP knowledge will not break MSRP.

> I am making assumptions based on real-network experience.

Me too. I've tested some of the techniques used by ALGs and without sessmatch nothing would work. I'm not assuming sessmatch will create problems, I know it.

> IF you can by-pass the ALG, then you may not need to go via the ALG in the first place, and sessmatch doesn't cause any problems (sessmatch is compatible with 4975 when there are no ALGs between).

Because ALGs are traditionally deployed on walled gardens this doesn't mean there is nothing outside. 

If I'm outside your walled garden but I want to talk to you I will only be able to do if I implement sessmatch myself or if your ALG supports falling back to B2BUA mode. Since sessmatch is still not published, forcing ALGs to fallback to B2BUA mode would solve all issues: users inside the walled garden would use sessmatch, and people outside may choose.

--
Saúl Ibarra Corretgé
AG Projects

---

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

Hi, 

>>>"solve the problem of the NAT", so it will also perform an ugly regexp over the SIP headers and break the signalling (in 99.99% of cases and 
>>>scenarios).
>>

Perhaps, but I think that discussion should take place elsewhere.

>But ALG is the reason Sessmath is specified.

True. 

But, ALGs are out there (whether we like it or not), and I am trying to make something that has a bigger chance to work in scenarios where ALGs are deployed.

>>>should not make a new specification to satisfy them when such new specification breaks the protocol itself (RFC 4975 and 4976).
>>
>IP, UDP, TCP, TLS, SIP and MSRP just work. ALG's are not needed at all and break OSI/Internet layers.

Well, there seem to be different opinions about that, but I don't think this is the forum to discuss that.

The FACT, which I base my work upon, is that the ALGs are out there, and from experience I know they won't go away any time soon. I hope we can agree on that :)

>IETF should not product a specification for these 
>horrible and undesirable "intermediaries" which, by nature, are invalid.

I think IETF nowadays realizes the fact that ALGs are out there, and if possible should be taken into consideration when specifying protocols.

Regards,

Christer

---

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

Hi,

>>And what does that have to do with ALGs? Do you assume that an ALG is not needed? If you assume that the ALG is only used for NAT traversal, that may be 
>>true, but I don't think that's very common.
>
>Could you please detail other real usages of ALG (in SIP world). I've seen thousands of SIP-ALG routers and their only purpose is to "solve"

RFC 5853 (http://tools.ietf.org/rfc/rfc5853.txt) provides some information.

There are also 3GPP documents. I can provide the links if you're interested, but I think most is covered in RFC 5853.

>That's a very cool way to say that sessmatch is not needed at all when there are no ALGs between.

Sure. Without ALGs, you don't need sessmatch. That's not Wikileaks material - it has been public information from the beginning :)

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 16:00:59 +0200

> I think IETF nowadays realizes the fact that ALGs are out there, and if possible should be taken into consideration when specifying protocols.

No, it does not .

There is no specification for what an ALG is or does. It is an anomaly. Is not a client, is not a server, is an intermediary that has no business being there. The fact that it is, does not make it a legitimate part of the picture.

The whole justification of the existence of this draft is flawed. The problem that it solves does not exit on the Internet. If implemented it will break what was built so far on the Internet.

Adrian

---

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

So, why did we specify RFC 4976? I thought NATs are evil also... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Georgescu
Sent: 25. toukokuuta 2011 17:01
To: Simple WG
Subject: Re: [Simple] About draft-ietf-simple-sessmatch

No, it does not .

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 16:11:31 +0200

> So, why did we specify RFC 4976? I thought NATs are evil also...

Right, but NAT exists for long time due to the not adoption of IPv6.
IPv4 also specifies the existence of private IP ranges. Within IPv4,
NAT is just an unavoidable reality and the specifications for IP
protocols should take it into account (as IPv4 was also specified by
IETF).

But even with NAT, ALG's are not needed, they are boxes with no place
in the whole picture and break OSI/Internet layers. In the case of
MSRP we already have RFC 4976 to deal with NAT by respecting the
existing specifications.

Also don't forget that sessmatch draft (assuming it's used with ALG's)
does break existing specifications. That is unnaceptable IMHO.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 16:21:26 +0200

Hi, 

>Also don't forget that sessmatch draft (assuming it's used with ALG's) does break existing specifications. That is unnaceptable IMHO.

As I've said, it has limitations, but it is not going to make anything that works today to not work.

Sessmatch provides a bigger chance of making MSRP work with ALG's.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 16:27:33 +0200

Bigger chance is a willing-full thought unsubstantiated by any measurements. While breaking everything else is guaranteed.

This does not form a good basis for improving how MSRP gets deployed. The opposite goal will be achieved. MSRP will work so-so and only in some walled garden places with certain solutions from certain vendors. On the public Internet it will be broken by arbitrary ALGs that will show up in the path without anyone being able to stop them.

Is this what you want to achieve?

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 May 2011 09:28:26 -0500

(as individual)

There's been a lot of conversation about how ALGs work (or don't work.)

For the sake of discussion, keep in mind that the ALGs contemplated by sessmatch are probably different than the ones that show up in every random residential gateway. Sessmatch is worried about ALGs that also perform media anchoring. The draft avoids the term SBC (probably to avoid all the controversies surrounding them), but I think what we are talking about is _exactly_ SBCs, and maybe the draft should acknowledge that.

I think in today's world, SBCs are as much about policy enforcement as NAT traversal.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 16:38:51 +0200

Hi, 

>Bigger chance is a willing-full thought unsubstantiated by any measurements. While breaking everything else is guaranteed.

Again, what does it break, that isn't already broken?

>This does not form a good basis for improving how MSRP gets deployed.

That's your opinion. 

In my expereince the customer interest in MSRP has gone up dramtically due to sessmatch, as not having to deploy MSRP specific relays, and/or ALG+MSRP B2BUA will generate big savings.

>The opposite goal will be achieved. MSRP will work so-so and only in some walled 
>garden places with certain solutions from certain vendors. On the public Internet it will be broken by arbitrary ALGs that will show up in the path 
>without anyone being able to stop them.

ALGs will show up with or without sessmatch. The question is how big the effort would be for them to support MSRP.

>Is this what you want to achieve?

I want to achieve MSRP becoming a success, by being deployed also in other networks than the ones you are referring to.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 16:43:43 +0200

The places where this can get deployed, do not need an IETF endorsement. Those bodies will make an internal note/document which becomes mandatory for their vendor supply chain. There are many changes already described in SIP, XCAP and other protocols in those walled gardens.

We do not need to pass an IETF document to break exiting well established MSRP protocols proven to be working fine for this.

OMA/3GPP can simply make a change to exiting MSRP protocol to have their walled gardens implemented. If they ever want to get out of their walled garden, their vendor must deploy a gateway to Internet. Is very simple stuff. No need to break the Internet. 

Adrian

---

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

> I think IETF SIMPLE WG should make specifications that can work in real-life networks.

They do. The NAT issue was one of the arguments for relays in MSRP in the first place. The IETF advice on ALG is in 

BCP 127
   REQ-10:  To eliminate interference with UNSAF NAT traversal
      mechanisms and allow integrity protection of UDP communications,
      NAT ALGs for UDP-based protocols SHOULD be turned off.  Future
      standards track specifications that define ALGs can update this to
      recommend the defaults for the ALGs that they define.

and from BCP 142 is 
   REQ-6:  If a NAT includes ALGs that affect TCP, it is RECOMMENDED
      that all of those ALGs (except for FTP]) be disabled by
      default.

The reasons why is basically protocols are not designed to work with random intermediaries changing bits. Protocols are designed for intermediaries that go by names such as relays, proxies, and B2BUA in the sip context. These are components of the system specifically designed such that they work - more importunity future extensions to the protocol are designed not to break them. 

Now I realize there are SIP ALGs out there - but they don't work very well. One of the biggest problems they have is adapting to future changes of the protocol.  I'm pretty shocked to see any other SDO  base an architecture on something as vaguely defined as the term ALG. But what other SDOs do is their concern not mind. Many of the real world scenarios I care about run SIP over TLS or DTLS (via the AnyConnnect VPN stuff) so that ALGs don't break things.