Subject: [Simple] sessmatch: to be or not to be?

From: Adam Roach <[email-masked]>
Date: Wed, 25 May 2011 11:25:11 -0500

I'm somewhat sad that the experience of implementors (Adrian, Saúl) have 
borne out the warnings that Cullen and I attempted to sound back in 
2008. We pointed out how this mechanism fundamentally breaks the 
existing protocol. And, despite all the work that has gone into this, 
it's still broken. You can't just change the bits around the edges of 
the protocol and make it somehow more palatable: the actual thesis of 
the document *is* the problem.

Let's take a step back and address a few of the points that have come up.

On 5/25/11 6:29 AM, Christer Holmberg wrote:
> 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.

These networks tend to start out as islands, and eventually morph into 
something that desperately *wants* to be connected to the Internet. 
Think of how WAP/WML portals eventually gave way to actual HTTP access 
to web sites. It is the height or naïvité to believe any IP technology 
that starts as a walled garden stays a walled garden forever. Because of 
this, the Internet community as a whole has a stake in how things are 
done inside the walled gardens. We don't want architecturally unsound 
decisions to leak out into the Internet when the wall is breached.

On 5/25/11 8:51 AM, Christer Holmberg wrote:
> I think IETF nowadays realizes the fact that ALGs are out there, and if possible should be taken into consideration when specifying protocols.

Having been at this for almost 15 years, I'm sympathetic to some of the 
arguments about designing protocols that don't work in the face of NATs, 
firewalls, and similar intermediaries. I'm familiar with the pain of 
having to clean up the messes that result from designing protocols that 
actually don't work in real deployments.

This situation, however, isn't about not working. It's about not being 
*optimal* for the intermediaries. As everyone is aware, we already have 
two ways to skin this particular cat (MSRP relays, MSRP B2BUA SBCs). The 
proposed mechanism expands the set of solutions from "recommended" and 
"not recommended" to "recommended," "not recommended," and "actually 
breaks stuff."

That's actually a pretty big deal, and I don't think most people 
completely understand this.

What this draft proposes is a non-backwards-compatible change to an 
existing protocol to *OPTIMIZE* for an architecture that the IETF 
actively discourages. The only -- ONLY -- purpose of this draft is to 
enable devices designed to usurp informed consent to do so at a greater 
scale.

On 5/25/11 9:44 AM, Christer Holmberg wrote:
> RFC 4975 and 4976 does not work fine with ALGs.

That's the most hilarious tail-wagging-the-dog statement I've heard in a 
long, long time. Let me fix that for you. "ALGs that can't be bothered 
to implement some modicum of actual MSRP functionality don't work with 
MSRP." Now, *that* is true. But I don't see why we're even considering 
introducing backwards-compatibility problems to OPTIMIZE (not enable, 
but actually optimize) the job of these intermediaries. Especially when 
(1) the intermediaries operate without the consent of the end user, and 
(2) we already have a mechanism for NAT and policy enforcement point 
traversal that *does* acquire user consent.

I see no way a draft designed to optimize the network for behaviors that 
the IETF does not condone has any hope of passing IETF last call, much 
less the IESG.

/a

---

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

Hi Adam,

>I'm somewhat sad that the experience of implementors (Adrian, 
>Saúl) have borne out the warnings that Cullen and I attempted 
>to sound back in 2008. We pointed out how this mechanism 
>fundamentally breaks the existing protocol. And, despite all 
>the work that has gone into this, it's still broken. You 
>can't just change the bits around the edges of the protocol 
>and make it somehow more palatable: the actual thesis of the 
>document *is* the problem.
>  
>>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.
> 
>These networks tend to start out as islands, and eventually 
>morph into something that desperately *wants* to be connected 
>to the Internet. 
>Think of how WAP/WML portals eventually gave way to actual 
>HTTP access to web sites. It is the height or naïvité to 
>believe any IP technology that starts as a walled garden 
>stays a walled garden forever. Because of this, the Internet 
>community as a whole has a stake in how things are done 
>inside the walled gardens. We don't want architecturally 
>unsound decisions to leak out into the Internet when the wall 
>is breached.
>
>>I think IETF nowadays realizes the fact that ALGs are out 
>>there, and if possible should be taken into consideration 
>>when specifying protocols.
> 
>Having been at this for almost 15 years, I'm sympathetic to 
>some of the arguments about designing protocols that don't 
>work in the face of NATs, firewalls, and similar 
>intermediaries. I'm familiar with the pain of having to clean 
>up the messes that result from designing protocols that 
>*optimal* for the intermediaries. As everyone is aware, we 
>already have two ways to skin this particular cat (MSRP 
>relays, MSRP B2BUA SBCs). The proposed mechanism expands the 
>set of solutions from "recommended" and "not recommended" to 
>"recommended," "not recommended," and "actually breaks stuff."
> 
>That's actually a pretty big deal, and I don't think most 
>people completely understand this.
> 
>What this draft proposes is a non-backwards-compatible change 
>to an existing protocol to *OPTIMIZE* for an architecture 
>that the IETF actively discourages. The only -- ONLY -- 
>purpose of this draft is to enable devices designed to usurp 
>informed consent to do so at a greater scale.

What is non-backwards-compatible?
 
>That's the most hilarious tail-wagging-the-dog statement I've 
>heard in a long, long time. Let me fix that for you. "ALGs 
>that can't be bothered to implement some modicum of actual 
>MSRP functionality don't work with MSRP." 

I guess you could put it that way, but I don't agree with the "can't be bothered" statement. There are reasons (related to finance, resources etc) why they haven't done it.

If it was only about a piece of software I don't think there would be any issues.

>Now, *that* is true. But I don't see why we're even considering introducing 
>backwards-compatibility problems to OPTIMIZE (not enable, but 
>actually optimize) the job of these intermediaries. Especially when
>(2) we already have a mechanism for NAT and policy 
>enforcement point traversal that *does* acquire user consent.
> 
>I see no way a draft designed to optimize the network for 
>behaviors that the IETF does not condone has any hope of 
>passing IETF last call, much less the IESG.

Is that a general comment, or you objecting to the draft moving forward?

Regards,

Christer

---

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

> What is non-backwards-compatible?

An MSRP endpoint implementing this draft behind a MSRP-ALG cannot talk
with a MSRP endpoint not implementing it (RFC 4975 broken), neither
with a MSRP relay (RFC 4976 broken). TLS name based authentication (as
RFC 4975/4976 allows) broken.

Also, even in the abscense of an ALG, an MSRP entity implementing
sessmatch could decide to change the URI in a MSRP message by keeping
the session id fragment, so if the remote peer doesn't implement
sessionmatch the protocol would fail.

Is it not enough? Could we already agree that seematch breaks
backwards-compatibility? or not yet?

Yes, I do know that anyhow a MSRP-ALG (implementing sessionmatch or
not) will break MSRP (as you have argumented several times). But I
don't care such ALG boxes, neither I think IETF's business includes
standarizing those ALG's, even less when it involves breaking an
existing protocol and existing implementations.

> If it was only about a piece of software I don't think there would be any issues.

So IETF should product specifications taking into account vendors
finances, is it? And what about the finances and resources of the
implementors who have already implemented MSRP RFC 4975 and 4976 by
respecting the OSI/Internet layers and the existing specifications?

I know *no* SIP provider relying on SIP-ALG capable routers in
customer side. Most of the SIP providers fix NAT in server side
(rtp-proxies, Comedia mode) or encourage standard solutions as
STUN/ICE, but no one relies on SIP-ALG routers. As Adrian pointed out
before, nobody has demanded routers vendors to include SIP-ALG, but
they include it anyway, maybe for announcing a "SIP powered" label in
the box. Why would it be different for MSRP? why MSRP-ALG's are so
needed for vendors now? (the best reason is not enough to break a
protocol).

Regards.

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

---

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

Hi,

>An MSRP endpoint implementing this draft behind a MSRP-ALG 
>cannot talk with a MSRP endpoint not implementing it (RFC 
>4975 broken), neither with a MSRP relay (RFC 4976 broken). 
>TLS name based authentication (as RFC 4975/4976 allows) broken.

And, how is that different from an MSRP endpoint NOT implementing the draft behind a MSRP-ALG?

>Also, even in the abscense of an ALG, an MSRP entity 
>implementing sessmatch could decide to change the URI in a 
>MSRP message by keeping the session id fragment, so if the 
>remote peer doesn't implement sessionmatch the protocol would fail.

That can be fixed by explicitly forbidding it.

>backwards-compatibility? or not yet?

I can agree with the TLS name based authentication part.
 
>not) will break MSRP (as you have argumented several times). 

And I will keep repeating it.

>But I don't care such ALG boxes, neither I think IETF's 
>business includes standarizing those ALG's, even less when it 
>involves breaking an existing protocol and existing implementations.

Implementations in networks with these kind of ALGs are already broken.

>>I guess you could put it that way, but I don't agree with 
>>the "can't be bothered" statement. There are reasons (related 
>>to finance, resources etc) why they haven't done it.
>So IETF should product specifications taking into account 
>vendors finances, is it? And what about the finances and 
>resources of the implementors who have already implemented 
>MSRP RFC 4975 and 4976 by respecting the OSI/Internet layers 
>and the existing specifications?

If their deployments work fine, they don't need to bother. They will even work with sessmatch clients.

>I know *no* SIP provider relying on SIP-ALG capable routers 
>in customer side. Most of the SIP providers fix NAT in server 
>side (rtp-proxies, Comedia mode) or encourage standard 
>solutions as STUN/ICE, but no one relies on SIP-ALG routers. 

I can ensure you that is not true.

And, again, it's not only about NAT.

>As Adrian pointed out before, nobody has demanded routers 
>vendors to include SIP-ALG, but they include it anyway, maybe 
>for announcing a "SIP powered" label in the box.

That is Adrian's opinion.

And, if you think that customers are so stupid that they are going to pay for things they don't need, we for sure are not talking about the same customers...

>Why would it be different for MSRP? why MSRP-ALG's are so needed for 
>vendors now? (the best reason is not enough to break a protocol).

They are needed by vendors so that vendors can provide them to customers who require them.

Regards,

Christer

---

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

> And, how is that different from an MSRP endpoint NOT implementing the draft behind a MSRP-ALG?

MSRP would also be broken if two users not implementing the draft try
to talk through a MSRP-ALG so, where is the problem? In the MSRP-ALG.
The draft would solve nothing in this case, neither it's guilty of the
issue caused by the ALG but, why should a RFC legitimize these ALG's
and their wrong behaviour?

> And I will keep repeating it.

I know :)

> Implementations in networks with these kind of ALGs are already broken.

Yes, but now you want to document such aberrantion and make it a standard.

> If their deployments work fine, they don't need to bother. They will even work with sessmatch clients.

The difference is that they should be supposed to work in *any*
correct and standarized scenario. But now with ALG's and this draft
standarizing them, they will just work in same cases (when there is
not an ALG).

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 May 2011 13:19:36 -0500

> Is that a general comment, or you objecting to the draft moving forward?

I've never stopped objecting to the draft moving forward.

/a

---

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

Hi, 

>>>>cannot talk 
>>>>with a MSRP endpoint not implementing it (RFC
>>And, how is that different from an MSRP endpoint NOT 
>>implementing the draft behind a MSRP-ALG?
> 
>MSRP would also be broken if two users not implementing the 
>draft try to talk through a MSRP-ALG so, where is the 
>problem? In the MSRP-ALG.
>The draft would solve nothing in this case, neither it's 
>guilty of the issue caused by the ALG but,

So, the draft doesn't create that problem, nor does it claim to solve that problem.

>why should a RFC legitimize these ALG's and their wrong behaviour?

I think we look at this from completely different angles :)

You think that is legitimizes ALGs, while I think it raises the possibility for MSRP communication to work in environments where ALGs are going to be deployed anyway.

You think it makes life easier for ALGs, while I think it makes life easier for MSRP.

>> If their deployments work fine, they don't need to bother. 
>> They will even work with sessmatch clients.
> 
>The difference is that they should be supposed to work in 
>*any* correct and standarized scenario. But now with ALG's 
>and this draft standarizing them, they will just work in same 
>cases (when there is not an ALG).

I don't think the draft "standardizes" ALGs, but I am the first to admit that the reason for the draft are ALGs.

But, having said that, I don't think it really matters whether ALGs are "standardized" or not. They will be deployed if there is a requirement to deploy them.

Regards,

Christer

---

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

Hi, 

>>>behaviors that the IETF does not condone has any hope of passing IETF last 
>>>call, much less the IESG.

I guess I've missinterpreted the outcome of the off-line discussions in Prague, then, when I thought we agreed on a way forward...

Also, you did say that you saw fallback as a way forward. Or, did I missinterpret that also?

Regards,

Christer

---

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

> And, how is that different from an MSRP endpoint NOT implementing the draft behind a MSRP-ALG?

You claim that scenario is broken, yet you stated no proof. Can you please be explicit here? Lets assume Alice is NOT behind an ALG and Bob is. The ALG does NOT do sessmatch. Alice calls Bob. How is this broken and why in your opinion?

--
Saúl Ibarra Corretgé
AG Projects

---

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

>>> An MSRP endpoint implementing this draft behind a MSRP-ALG cannot 
>>> talk with a MSRP endpoint not implementing it (RFC
>You claim that scenario is broken, yet you stated no proof. 
>Can you please be explicit here? Lets assume Alice is NOT 
>behind an ALG and Bob is. The ALG does NOT do sessmatch. 
>Alice calls Bob. How is this broken and why in your opinion?

It is broken if:

- the media needs to be anchored (for whatever reason) by the ALG; and 
- the ALG does is not a MSRP B2BUA.

If the ALG is a MSRP B2BUA, there is no problem - which is also stated in the draft.

Regards,

Christer

---

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

> And, if you think that customers are so stupid that they are going to pay for things they don't need, we for sure are not talking about the same customers...

Sure, your clients are more important (I'm not joking).

So, must IETF product a specification to satisfy your clients even if
such specification is based on anything but what the IETF is supposed
to promote (producing high quality, relevant technical documents that
influence the way people design, use, and manage the Internet)?

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

---

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

2011/5/25 Christer Holmberg <[email-masked]>:
> It is broken if:
>
> - the media needs to be anchored (for whatever reason) by the ALG

Dont' forget to add "without asking permission to the user".

If the UA uses SIP over TLS the ALG has no way to anchor de media,
should the ALG then reject such SIP TLS attemp? does it need to anchor
the media or not? or "just" when it can?

> If the ALG is a MSRP B2BUA, there is no problem - which is also stated in the draft.

If the ALG is a MSRP B2BUA then it's not an ALG, so sessmatch is not
needed at all, neither this draft.

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

---

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

>>And, if you think that customers are so stupid that they 
>>are going to pay for things they don't need, we for sure are 
>>not talking about the same customers...
> 

I never said that.

>So, must IETF product a specification to satisfy your clients 
>even if such specification is based on anything but what the 
>IETF is supposed to promote (producing high quality, relevant 
>technical documents that influence the way people design, 
>use, and manage the Internet)?

We are not only satisfying my clients.

Regards,

Christer

---

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

Hi, 

>Dont' forget to add "without asking permission to the user".

Even if the user is asked for permission, if the ALG is not a MSRP B2BUA it won't work.

>If the UA uses SIP over TLS the ALG has no way to anchor de 
>media, should the ALG then reject such SIP TLS attemp? does 
>it need to anchor the media or not? or "just" when it can?

What the ALG does in such cases is outside the scope of sessmatch - or even MSRP.

Regards,

Christer

---

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

> If the ALG is a MSRP B2BUA, there is no problem - which is also stated in the draft.

I think you are mistaken here. If the media needs to be anchored the ALG MUST be a B2BUA (if we don't consider this draft). There is no other way to do it only with RFC4975 and 4976.

This draft is only trying to help ALGs, not MSRP as a protocol. The 'problem' that you are tying to solve was introduced by the ALG, if it were a B2BUA there would be no problem at all.

--
Saúl Ibarra Corretgé
AG Projects

---

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

Hi, 

>I think you are mistaken here. If the media needs to be 
>anchored the ALG MUST be a B2BUA (if we don't consider this 
>draft). There is no other way to do it only with RFC4975 and 4976.

I agree.

That's why I said that, unless the ALG is a MSRP B2BUA, things are broken.

>This draft is only trying to help ALGs, not MSRP as a 
>protocol.

Helping MSRP work easier with ALGs is also helping the protocol, in my opinion.

>The 'problem' that you are tying to solve was introduced by the ALG, if it were a B2BUA there would be no 
>problem at all.

I have not claimed otherwise.

Regards,

Christer

---

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

Hi,

> I have not claimed otherwise.

If the problem was introduced by the ALG, then the ALG is what needs to be fixed. Its as simple as that.

--
Saúl Ibarra Corretgé
AG Projects

---

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

Hi, 

>>> The 'problem' that you are tying to solve was introduced 
>>> by the ALG, if it were a B2BUA there would be no problem at all.
>> 
>If the problem was introduced by the ALG, then the ALG is 
>what needs to be fixed. Its as simple as that.

Yes, in the same way NATs need to be fixed in order to solve the problems they introduce...

Regards,

Christer

---

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

> Yes, in the same way NATs need to be fixed in order to solve the problems they introduce...

One wrong does not justify another.

--
Saúl Ibarra Corretgé
AG Projects

---

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

>One wrong does not justify another.

Wrong or not, it's reality.

Regards,

Christer

---

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

> Yes, in the same way NATs need to be fixed in order to solve the problems they introduce...

NAT is a need (due to IPv4 limitation and the lack of IPv6 adoption).
ALG's are not a need, not with currently available technology.

NAT introduces problems, but without NAT things would be just
impossible (no IPv4 for all the world).
ALG's introduce problems, but without ALG's things can work
(technology already provides solutions at application level).

I don't think ALG should be compared with NAT.

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

---

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

The arguments for continuing to pursue something completely broken by design like sess-match are so far:

1. There were other worse things done in the past (like NATs)
2. There is a precedent  with somebody having mentioned the word ALG in a previous IETF document
3. The OMA made a reference about this draft

By doing this draft we must all accept that:

The fact that TLS does not work anymore does not matter
The fact that it breaks compatibility with RFC 4975 and RFC 4976 does not matter
The fact that this can be implemented differently or poorly by incompetent vendors with implications that go beyond what the authors sees possible today does not matter
The fact that SIP ALGs break communications does not matter, and a similar model will become legitimate for MSRP protocol as well
The fact that there is no know implementations that work today does not matter
The fact that existing MSRP implementations work well today and will cease to work in the future as this draft becomes a standard does not matter

These should all be mentioned in the document before submitting it further so that the reviewers can give a better judgement about whether this should exist or not.

I believe that what IETF stands for is in complete opposition with the statements above.

The SIMPLE WG should drop this draft and pass the problem to their owner, OMA in this case.

Adrian

On May 25, 2011, at 10:38 PM, Christer Holmberg wrote:

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

---

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

> Wrong or not, it's reality.

Could you please explain who (names not needed, of course) is so
interested in MSRP-ALG's and why it's a so big requirement for them?

Also, could you please confirm me that those vendors don't want to
deploy MRSP full B2BUA's and instead prefer promoting MSRP-ALG boxes
(for example integrated within the IP/TCP routers)?

Thanks a lot.

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 May 2011 16:16:08 -0500

> Also, you did say that you saw fallback as a way forward. Or, did I missinterpret that also?

Since the inception of a draft that was explicitly incompatible with the 
existing MSRP architecture, I had two goals. The first is to stop it, 
preferably before we spend a lot of work on it. That's what I was trying 
to do in Dublin. The second is to work towards making it cause as little 
damage as possible, in case it does get published. The discussions in 
Prague, the comment about behavior fallback, and pretty much everything 
else I've said on the topic was an attempt to mitigate any damage that 
would be cause by publication.

/a

---

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

> The fact that it breaks compatibility with RFC 4975 and RFC 4976 does not matter

The author of the draft has already replied that your statement is
false, as "in the absence of an MSRP-ALG, alice (implementing
sessionmatch) and bob (not implementing it) can talk MSRP with no
problem". But arguing that is useless as that is the case in which
this draft does not take place at all.

The fact is that when an ALG implementing this draft takes place, MSRP
entities not implementing this draft (including MSRP relays) cannot
talk with other entities behind the ALG box. And it's unacceptable
that a RFC promotes something like this.

> The fact that SIP ALGs break communications does not matter, and a similar model will become legitimate for MSRP protocol as well

Even worse, as now vendors will have an IETF RFC specification
justifying their aberration.

It seems that the leasson learned after the proliferation of SIP-ALG
routers does not apply here. BTW: is the reason learned? does
people/vendors know about the big problems SIP-ALG routers have
caused?

Regards.

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

---

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

Hi, 

>The arguments for continuing to pursue something completely 
>broken by design like sess-match are so far:
> 

That is not an argument for continuing the work.

>word ALG in a previous IETF document

I am not aware of such argument.

>3. The OMA made a reference about this draft

That is ONE argument - and a very valid one, in my opinion.

>The fact that TLS does not work anymore does not matter

You can still use TLS.

>The fact that it breaks compatibility with RFC 4975 and RFC 4976 does not matter

It does not break compability with RFC 4975 and RFC 4976.

>The fact that this can be implemented differently or poorly by incompetent vendors
>with implications that go beyond what the authors sees possible today does not matter

If that were an argument I think we have to stop most of the IETF work...

(One reason why people deploy ALGs is to fix things that have been poorly implemented.)

>The fact that SIP ALGs break communications does not matter, and a similar model will 
>become legitimate for MSRP protocol as well The fact that there is no know implementations 
>that work today does not matter

I am not sure what kind of implementations you are talking about, but I can inform you that there are working sessmatch implementations.

>The fact that existing MSRP implementations work well 
>today and will cease to work in the future as this draft 
>becomes a standard does not matter

I don't think implementation that works today will cease to work because of sessmatch.

>These should all be mentioned in the document before 
>submitting it further so that the reviewers can give a better 
>judgement about whether this should exist or not.

I think I have addressed most issues (at least the ones people have agreed upon) in the draft.

>their owner, OMA in this case.

There are other owners too.

Regards,

Christer

---

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

>>> I guess I've missinterpreted the outcome of the off-line 
>>> discussions in Prague, then, when I thought we agreed on a 
>>> way forward...
>>
>Since the inception of a draft that was explicitly 
>incompatible with the existing MSRP architecture, I had two 
>goals. The first is to stop it, preferably before we spend a 
>lot of work on it. That's what I was trying to do in Dublin. 
>The second is to work towards making it cause as little 
>damage as possible, in case it does get published. The 
>discussions in Prague, the comment about behavior fallback, 
>and pretty much everything else I've said on the topic was an 
>attempt to mitigate any damage that would be cause by publication.

Thanks for the clarification.

Regards,

Christer

---

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

Hi, 

>The author of the draft has already replied that your 
>statement is false, as "in the absence of an MSRP-ALG, alice 
>(implementing sessionmatch) and bob (not implementing it) can talk MSRP 
>with no problem".

I couldn't have said it better myself :)

>But arguing that is useless as that is the case in which this draft 
>does not take place at all.
> 
>The fact is that when an ALG implementing this draft takes 
>place, MSRP entities not implementing this draft (including 
>MSRP relays) cannot talk with other entities behind the ALG 
>box. And it's unacceptable that a RFC promotes something like this.

Sessmatch promotes MSRP, by providing a mechanism that makes it easier to use in the presence of ALGs.

I am not sure it's useful to have this philsophical discussions about what promotes what, because we obviously have very different views, and it does not help in solving the technical issues.

>>The fact that SIP ALGs break communications does not matter, and a 
>>similar model will become legitimate for MSRP protocol as well
> 
>Even worse, as now vendors will have an IETF RFC 
>specification justifying their aberration.
> 
>It seems that the leasson learned after the proliferation of 
>SIP-ALG routers does not apply here. BTW: is the reason 
>learned? does people/vendors know about the big problems 
>SIP-ALG routers have caused?

Yes, and sessmatch is one outcome of those learnings :)

Regards,

Christer

---

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

Hi,

> It does not break compability with RFC 4975 and RFC 4976.

It does. You don't seem to care about what I write, but I have explained it several times already. It does break it.

> I am not sure what kind of implementations you are talking about, but I can inform you that there are working sessmatch implementations.

Have you seen them working together with non-sessmatch implementations. No.

> I don't think implementation that works today will cease to work because of sessmatch.

We implemented the whole stack and it will not work if we deal with endpoints behind sessmatch enabled ALGs that don't do fallback.

Again, the only way to avoid the damage this draft causes is to mandate the fallback mechanism.

--
Saúl Ibarra Corretgé
AG Projects

---

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

>>The fact that TLS does not work anymore does not matter

...without name based authentication.

> (One reason why people deploy ALGs is to fix things that have been poorly implemented.)

Definitely we live in different worlds.

> I don't think implementation that works today will cease to work because of sessmatch.

This has been explained 5-10 times today in different threads. Today's
implementations (those with no sessionmatch) will just work with other
today's implementations, but not with sessmatch aware MSRP entities in
presence of MSRP-ALG's.

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

---

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

> Again, the only way to avoid the damage this draft causes is to mandate the fallback mechanism.

Now let's laugh a bit:

1) Let's assume that vendors want to deploy MSRP-ALG boxes rather than
MSRP relays or MSRP B2BUA's (all the stuff in a single box and so,
cheaper, "simpler"...).

2) Let's assume that designing/building a MSRP-ALG router implementing
sessmatch is easy (just apply some regular expression and replace a
line in the SDP) and then brigde two TCP/TLS connections.

3) Let's assume that vendors capable of implementing point 2 are not
always capable of building a full MSRP B2BUA (this cannot be done in 4
hours as point 2).

And do we really expect that vendors will implement a "failover
mechanism" which means building a full MSRP B2BUA (point 3) which is
2000 times more difficult than point 1 ??? (laughing...)

This will not occur, neither if there is a MUST in the document. Take
into account that most of the current vendors have decided to
implement SIP-ALG in their routers (and there is no specification for
it).

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

---

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

Hi, 

>It does. You don't seem to care about what I write, but I 
>have explained it several times already. It does break it.

I do care. But, I have explained as many times why I think it doesn't break compability.

But, since we obviously can't agree on that point, let's stop arguing about it.

>>> similar model will become legitimate for MSRP protocol as well The 
>>> fact that there is no know implementations that work today does not 
>>> matter
>> 
>> I am not sure what kind of implementations you are talking 
>> about, but I can inform you that there are working sessmatch 
>> implementations.
>> 
> 

All I can say is that sessmatch works in cases where it is claimed to work.

>>>today and will cease to work in the future as this draft becomes a 
>>>standard does not matter
>> 
>We implemented the whole stack and it will not work if we 
>deal with endpoints behind sessmatch enabled ALGs that don't 
>do fallback.

If you are talking about non-sessmatch endpoints it will not work behind non-sessmatch ALGs either.
 
>to mandate the fallback mechanism.

So, let's focus our discussions on that then, and skip the stuff that won't take us anywhere.

Regards,

Christer

---

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

>> The fact that TLS does not work anymore does not matter

You seem to be ignorant of what TLS is or does by saying this.

Why would I want to use a TLS connection where the other end-point cannot be verified?

How could  I ever exchange securely files and chat messages over an MSRP connection using this draft? The protocol will become the laughing stock of everyone.

Would you do your banking transactions via an ALG that does insert itself in the middle of your TLS session?

IETF aims towards producing protocols with security properties not hacks that break the most fundamental concepts of the Internet.

sess-match is no match for this goal.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2011 00:00:42 +0200

Hi, 

>...without name based authentication.

If the ALG is a TLS B2BUA you can also use name based authentication.

But, if the ALG relays the TLS connection, I agree.

>>>The fact that existing MSRP implementations work well today 
>>>and will cease to work in the future as this draft becomes a 
>>>standard does not matter
>>
>This has been explained 5-10 times today in different 
>threads. Today's implementations (those with no sessionmatch) 
>will just work with other today's implementations, but not 
>with sessmatch aware MSRP entities in presence of MSRP-ALG's.

...and not with any other today's MSRP entities either.

I suggest that we stop to argue about this now. We DO see to agree on which scenarios will work, and which won't.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2011 00:09:15 +0200

Hi, 

>>is to mandate the fallback mechanism.

I stopped laughing many e-mails ago :)

>1) Let's assume that vendors want to deploy MSRP-ALG boxes 
>rather than MSRP relays or MSRP B2BUA's (all the stuff in a 
>single box and so, cheaper, "simpler"...).
> 
>2) Let's assume that designing/building a MSRP-ALG router 
>implementing sessmatch is easy (just apply some regular 
>expression and replace a line in the SDP) and then brigde two 
>TCP/TLS connections.
> 
>3) Let's assume that vendors capable of implementing point 2 
>are not always capable of building a full MSRP B2BUA (this 
>cannot be done in 4 hours as point 2).
>
>And do we really expect that vendors will implement a 
>"failover mechanism" which means building a full MSRP B2BUA 
>(point 3) which is 2000 times more difficult than point 1 ??? 
>(laughing...)
>
>This will not occur, neither if there is a MUST in the 
>document. Take into account that most of the current vendors 
>have decided to implement SIP-ALG in their routers (and there 
>is no specification for it).

That applies to any MUST in any document. There is nothing we can do about that.

All WE can do is justify and describe the importance of implementing the MUSTs.

Customer requirements will in the end always decide what is implemented.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2011 00:15:36 +0200

Hi, 
		
>Why would I want to use a TLS connection where the other end-point cannot be verified?

The draft does talk about a case where you have an end-to-end MSRP TLS connection.

Regards,

Christer

>How could  I ever exchange securely files and chat messages over an MSRP connection 
>using this draft? The protocol will become the laughing stock of everyone.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 25 May 2011 20:09:33 -0600

> Is that a general comment, or you objecting to the draft moving forward?

Just as a summary of where I see things ... you have some people that want to use this draft more or less as is. They feel it will meet the needs of an OMA like deployment. You also have some people that are not convinced that this does not have backwards compatible problems or security problems when used on the internet. The exact details of this are complex enough that it is not easy for most the people who have commented on this draft at one point or another to even decide if there agree there are problems or not. The list of people that believe there are problems are not some random casual bystanders - some of them have deep understanding of the protocol and includes people who implemented MSRP and some of the authors. 

Pretty hard to claim you have consensus in a situation like that. People are worn down by this conversation and just giving up.

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Wed, 25 May 2011 22:23:47 -0400

Cullen,

Carriers, at least AT&T, supports the points that Christer has been
making in this marathon email thread today.

Simply put, your open internet points, do not meet industry needs.

This sounds like an issue for 3GPP/IETF coordination.

Regards,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Services, Inc.
[email-masked]
+1-609-903-3360

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cullen Jennings
Sent: Wednesday, May 25, 2011 10:10 PM
To: Christer Holmberg
Cc: Adam Roach; SIMPLE (SIP for Instant Messaging and Presence
Leveraging Extensions) WG
Subject: Re: [Simple] sessmatch: to be or not to be?

> Is that a general comment, or you objecting to the draft moving
forward?

Just as a summary of where I see things ... you have some people that
want to use this draft more or less as is. They feel it will meet the
needs of an OMA like deployment. You also have some people that are not
convinced that this does not have backwards compatible problems or
security problems when used on the internet. The exact details of this
are complex enough that it is not easy for most the people who have
commented on this draft at one point or another to even decide if there
agree there are problems or not. The list of people that believe there
are problems are not some random casual bystanders - some of them have
deep understanding of the protocol and includes people who implemented
MSRP and some of the authors. 

Pretty hard to claim you have consensus in a situation like that. People
are worn down by this conversation and just giving up. 
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2011 08:50:16 +0200

Hi Cullen, 

>The list of people that believe there are problems are not some random 
>casual bystanders - some of them have deep understanding of 
>the protocol and includes people who implemented MSRP and 
>some of the authors. 

I have great respect for those people (please let me know if I have ever claimed anything else). That is why I have spent lots of time, also involving my own security experts and implementors, trying to understand and address the comments and issues given by them. I am also extremely thankful that most of those people also spend much of their own on this, by replying back fast etc.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 26 May 2011 09:50:25 +0200

> making in this marathon email thread today.

Finally I know who "the customers" are, and they seem important :)

> Simply put, your open internet points, do not meet industry needs.

IETF is supposed to worry about Internet ("The goal of the IETF is to
make the Internet work better") rather than satisfy the industry by
breaking basic OSI/Internet layers and already working protocolos just
in favour of the some very big vendors, no matter how big they are.

This specifications breaks things (working things) in favour of an
"anomaly" (SIP ALG's) just because some vendors don't want to adopt
the solutions already standarized by the IETF (i.e. MSRP relays). This
specifications helps ALG boxes intercepting users's traffic without
their consent.
This specification is against the basic principles IETF publications
are supposed to promote.

If this was a famous movie, who would be "the Bad"?

> This sounds like an issue for 3GPP/IETF coordination.

IMHO the specification discussed here makes no sense in IETF, maybe
that is the issue (just my opinion).

Regards.

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

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 26 May 2011 10:03:05 +0200

Hello Martin,

I do not believe that being AT& T entitles you to help create an IETF  standard that breaks every other MSRP deployment on the Internet.

What you ask for is agains the Internet principles and hurts a lot of people and their investment so far in an Internet protocol that works just fine today and will not anymore once this document is adopted.

sess-match  does not belong to IETF, it may belongs to RFPs for your suppliers that build your wall garden, nobody else needs such specification except you and your vendors.

This specifications has  nothing to do with improving the Internet but the opposite, by breaking it.

Adrian