Subject: Re: [Simple] MSRP-ACM compatibility

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 1 May 2009 16:01:41 +0200

Hi, 

>>> To make this interop with MSRP relays, we would need more work. 
>>> Relays are not involved in the SIP signaling, so there's no
>> opportunity for
>>> them to send a fingerprint. We would need some way for endpoints to 
>>> get fingerprints from the relays, and include them in the signaling.
>>
>> Just for my clarification: how is that related to routing based on 
>> c/m/a=path, and possibly having a B2BUA which may modify the address 
>> information of the ACM client's c/m/a=path?
>
> It's specific to the idea of having TLS cert fingerprints sent in SIP 
> for each relay. It's only needed in case where a middlebox modified 
> the path attribute to modify the IP addresses or host names in the 
> MSRP uris, creating the certificate mismatch we have discussed.

A few questions:

FIRST, RFC4572 already defines the usage of the fingerprint attribute,
so wouldn't your issue also apply if you ONLY use COMEDIA, with relays?

SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the IP
address/ports are not used for the certificate. So, as long as both the
ACM client/SBC belong to foobar.dom, and the MSRP client/relay belong to
anotherfoobar.com, the SBC and relay can have the same certificate as
the client behind them. Or?

THIRD, if a fingerprint is to be provided to/from the relay when an MSRP
message is sent, I guess it could be sent as a To/From-path URI
parameter. Getting the fingerprint to/from the relay BEFORE an MSRP
message is sent is of course more tricky.

Hadriel's e-mail (fri 17th april):
==================================

If I understand your comment, the property you believe is important is
that when a MSRP client is given an MSRPS next-hop to connect to, that
it be able to verify at the MSRP TLS connection level that it is in fact
talking to that next-hop.  Correct?  I agree with that being a very good
property.  

Luckily TLS relies on Certificate CNs/SANs, not IP Addresses/ports, for
identity. (unlike some other identity mechanisms we've been discussing
lately ;) 

If I am told to talk to foobar.com, it does not matter what IP/port at
layer-3 I am talking to, so long as it has foobar.com's Cert.  

So I think what we need in ACM is to provide a way to indicate what (1)
the IP/port to connect to is, vs. (2) what Cert identity to be verified
is.  Comedia-tls (rfc4572) does that with a fingerprint attribute, but
we have been discussing on this list what the appropriate way to do that
for the ACM case is.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 8 May 2009 16:04:39 -0500

(as individual)

> so wouldn't your issue also apply if you ONLY use COMEDIA, with  

If you use COMEDIA-TLS, yes. Not if just use RFC4145, or follow _just_  
the connection-direction parts of the ACM draft.

> the client behind them. Or?

As far as Hadriel's comment, it depends on what one puts _in_ the  
subjectAltName field. You _could_ put just an IP address in there,  
although I submit that would be a bad idea.

But to put your statement more generally: If the, sbc, or other  
intermediary has a subjectAltName entry that matches the authority  
part of a client's adjacent MSRP device (i.e. the next hop in the  
a=path attribute), then we're fine.

The problem is, the SBC is not likely to be in the same domain as  
_both_ endpoints. So from at least one endpoint's perspective, there's  
likely to be a mismatch.

> message is sent is of course more tricky.

A URI parameter would seem to be the least syntactically invasive  
approach.

(Reminder--I'm writing as an individual, not as chair)

By the way, please do not take my replies to indicate that I support  
the idea that the simple WG specifying how to use fingerprints with  
relays. I don't necessarily oppose it either, but the work group will  
need to decide if the value of the c-line addressing part of the ACM  
draft is sufficient to make it worth the additional work and complexity.

In particular, I am skeptical about doing non-trivial changes to make  
MSRP work better across proprietary intermediaries without some better  
description of what will and will not work in the general case (i.e.  
not just what will work with one vendor.)

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 18 May 2009 12:23:13 +0200

Hi, 

Chapter 4.1.2, which belongs to the comedia part of the ACM draft, does
refer to RFC4572, so my assumption so far has been that "using the
comedia part" would also include RFC4572 for TLS.

So, when talking about comedia, I guess we need to separate between
"using the comedia part" (which, for TLS, includes the fingerprint
attribute) and "using just the connection-direction parts of comedia".

And, even without the fingerprint, you still have the TLS collision
issue if both endpoints are "active".

>>SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the  
>>IP address/ports are not used for the certificate. So, as long 
>>as both the ACM client/SBC belong to foobar.dom, and the MSRP
client/relay  
>>belong to anotherfoobar.com, the SBC and relay can have the same 
>>certificate as the client behind them. Or?
> 

>likely to be a mismatch.

Why doesn't the relay need to get the certificate information in legacy
MSRP then? I don't think we can assume that the relay belongs to the
same domain as both endpoints, can we?

I have a feeling that I am missing some piece of the puzzle here, and I
appologise for that, but I am still trying to figure out this is
specific to ACM :)

>>THIRD, if a fingerprint is to be provided to/from the relay when an  
>>MSRP message is sent, I guess it could be sent as a To/From-path URI
>relays.

I think people should be allowed to participate in discussions and idea
brainstorming without automatically being "accused" of supporting
specific solutions :)

>I don't necessarily oppose it either, but the work 
>group will need to decide if the value of the c-line addressing part of
the ACM  
>In particular, I am skeptical about doing non-trivial changes 
>to make MSRP work better across proprietary intermediaries without 
>some better description of what will and will not work in the general
case (i.e.  
>not just what will work with one vendor.)

As said before, I don't think this is about "one vendor".

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 May 2009 17:05:11 -0500

(As individual)

> issue if both endpoints are "active".

Ah, I see what you mean. I agree, the issue with using fingerprints  
for relay certificates is true just for the COMEDIA use currently  
defined in the ACM draft.

> same domain as both endpoints, can we?

I'm not sure I understand your question-The assumption in RFC4576 is  
that an MSRP Relay will have a certificate that is signed by a well- 
known certificate authority.  I agree that we can't assume a relay  
belongs to the same domain as both endpoints, but RFC4976 does not  
require that. It's only when the device that terminates the TCP  
connection is not the same device that terminates the TLS handshake  
that we have a problem. That doesn't happen in RFC4976 natively--only  
when a middlebox changes the path attribute.

> appologise for that, but I am still trying to figure out this is

It's specific to having a middlebox modify the SDP path property. Let  
me try an example:

Alice is behind an SBC. That SBC acts as a TCP relay, but  
transparently tunnels TLS rather than terminating it. (much in the way  
an HTTPS proxy tunnels TLS). Alice sends an offer to Bob. Her path  
attribute looks like:

a=path: msrps;//alice.atlanta.com:1234/fieru;tcp

The SBC modifies the authority part of the URI to point to itself, and  
creates a binding so that all traffic to its port forwards to alice:

a=path: msrps;//sbc.atlanta.com:88039/fieru;tcp

Bob uses a relay.  His answer contains:

a=path:msrps://relay.biloxi.com:84930/asfieu;tcp msrps;// 
bob.biloxi.com:1234/bzerts;tcp

Alice's SBC modified the answer to also point to itself, and completes  
the binding

a=path:msrps://sbc.atlanta.com:88040/asfieu;tcp msrps;//bob.biloxi.com: 
1234/bzerts;tcp

Alice now opens a TCP connection to sbc.atlanta.com:88040, and  
initiates a TLS handshake. This is forwarded transparently to  
relay.biloxi.com, which provides its TLS server certificate containing  
"relay.biloxi.com" in its subjectAltName field.

Alice's UA checks the certificate for the name "sbc.atlanta.com",  
since that was the name it saw in the SDP. The cert provided by  
relay.biloxi.com does not contain that name, so the TLS server  
authentication fails.

> As said before, I don't think this is about "one vendor".

So what _is_ it about? To my knowledge, We've had only  one vendor  
stand up and say "this stuff will work across our SBCs".

You are trying to work around the behavior of proprietary middle  
boxes. They may behave similarly in some ways, but not others. For  
example, if other vendors don't have support for TCP media, then  
there's not much value in this for them. Without some standard  
behavior, or some survey of behavior like BEHAVE did with NATs, we're  
just sort of hoping things will work most of the time. That may be  
good enough to write product requirements around, but it's probably  
not good enough to write standards around.

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 19 May 2009 07:40:56 +0200

Hi,

>>>some better description of what will and will not work in 
>>>the general case (i.e. not just what will work with one vendor.)
>>
>behavior, or some survey of behavior like BEHAVE did with 
>NATs, we're just sort of hoping things will work most of the time. That
may be  
>not good enough to write standards around.

What it is about is to allow these middle boxes to treat MSRP more or
less like any other type of TCP media, without having to modify the MSRP
messages etc.

Of course, some intermediates may not support TCP in the first place,
but that's normal. We don't expect everyone to support everything we do.

But, OMA PoC uses MSRP, so compliant intermediates will have to support
TCP. 3GPP IMS uses MSRP, so compliant intermediates will have to support
TCP. Intermediates also DO exist in other SIP networks, so in order for
MSRP to work they will have to support TCP. That is what I meant by the
statement that it's not only about one vendor.

So, in my opinion, intermediates can be expected to support TCP. The
issue is with supporting legacy MSRP, and that is what ACM is trying to
solve.

I do agree that these intermediates aren't standardized, but when it
comes to sending the media through them they all behave in the same way:
by modifying the SDP.

Of course, If we also for ACM would still use the a=path attribute for
routing, rather than the c/,- line, the intermeidates will of course
have to be able to modify the a=path attribute. But, no matter whather
that can be done using configuration (I guess that is what Hadirel
indicated for his product) or whether it requires a software patch, it's
a relatively small thing compared to having to modify MSRP messages.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 19 May 2009 10:41:19 +0200

Hi,

>>Chapter 4.1.2, which belongs to the comedia part of the ACM draft, 
>>does refer to RFC4572, so my assumption so far has been that "using 
>>the comedia part" would also include RFC4572 for TLS.
>>
>Ah, I see what you mean. I agree, the issue with using 
>fingerprints for relay certificates is true just for the 
>COMEDIA use currently defined in the ACM draft.

There are actually a number of comedia issues, but it seems like I have
mixed them. I'll try to separate them:

FIRST, if we don't use the fingerprint attribute when the MSRP clients
use self-signed signatures, we are not compliant with RFC4572. Do we
want to go that way? Do we have the mandate to go that way? Will the
security people have issues with that? 

Without relays I guess there would be no issue with using the
fingerprint attribute (again, I am only talking about pure comedia here
- not SBC impacts etc). But, even with relays, I guess it would be
possible to provide the fingerprint of the remote client to the relay
e.g. using the AUTH method. 

SECOND, the handshake collision occurs when both endpoints are "active".
AFAIK, that has nothing to do with whether the fingerprint is used or
not.

THIRD (new), I assume an MSRP entity behind a relay would always be
"active". I am not sure whether that is an issue, but it should probably
be mentioned in the draft.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 19 May 2009 11:37:34 +0200

Hi,

Thanks for the information! I think I can see the missing puzzle piece
now :) 

>>>>IP address/ports are not used for the certificate. So, as long as 
>>>>both the ACM client/SBC belong to foobar.dom, and the MSRP
client/relay
>>>_both_ endpoints. So from at least one endpoint's perspective, 
>>>there's likely to be a mismatch.
>>
>>Why doesn't the relay need to get the certificate information in 
>>legacy MSRP then? I don't think we can assume that the relay belongs 
>>to the same domain as both endpoints, can we?
> 
>I'm not sure I understand your question-The assumption in 
>RFC4576 is that an MSRP Relay will have a certificate that is 
>signed by a well- known certificate authority.  I agree that 
>we can't assume a relay belongs to the same domain as both 
>endpoints, but RFC4976 does not require that. It's only when 
>the device that terminates the TCP connection is not the same 
>device that terminates the TLS handshake that we have a 
>problem. That doesn't happen in RFC4976 natively--only when a 
>middlebox changes the path attribute.
> 
>>I have a feeling that I am missing some piece of the puzzle here, and 
>>I appologise for that, but I am still trying to figure out this is 
>>specific to ACM :)
>
> 
me try an example:
>transparently tunnels TLS rather than terminating it. (much 
>in the way an HTTPS proxy tunnels TLS). Alice sends an offer 
>to Bob. Her path attribute looks like:
> 
>The SBC modifies the authority part of the URI to point to 
>itself, and creates a binding so that all traffic to its port 
>forwards to alice:
> 
>Alice's SBC modified the answer to also point to itself, and 
>completes the binding
> 
>Alice now opens a TCP connection to sbc.atlanta.com:88040, 
>and initiates a TLS handshake. This is forwarded 
>transparently to relay.biloxi.com, which provides its TLS 
>server certificate containing "relay.biloxi.com" in its 
>subjectAltName field.
> 
>Alice's UA checks the certificate for the name 
>"sbc.atlanta.com", since that was the name it saw in the SDP. 
>The cert provided by relay.biloxi.com does not contain that 
>name, so the TLS server authentication fails.

Ok.

<brainstorming>

One way of dealing with this is, as we have discussed, to include
sertificate information in the signalling. In the example above, Alice
would be told to check for the name "relay.biloxi.com", instead of
"sbc.atlanta.com".

Another way of dealing with this is of course to say that the
intermeidate MUST terminate TLS in this case. If BOTH Alice and Bob open
TCP connections (since Bob is behind a relay, I assume he would ALWAYS
be "active"), the intermeidate may need to terminate TLS anyway, in
order to avoid the handshake collision?

Now, one could claim that it is difficult to know what intermediates
will do, since they are not standardized. Jon also asked whether we
would need to specify a new kind of TLS intermediate.

If we want to specify something, I am not sure we need to talk
specifically about intermeidates. I think we can be more generic, and
e.g. talking about "entities which generate SDP for MSRP". That would
then apply to any type of entity.

"An entity which inserts its authority part in the URI of the a=path
header needs to ensure that a matching certificate is provided to other
entities which connect to it. This can be achieved by terminating TLS
connections (instead of being TLS transparent) or by providing correct
certificate information in the signalling to other entities which
connect to it."

...or something like that. I think that applies to all kind of MSRP
entities - including intermediates.

</brainstorming>

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 May 2009 17:07:19 -0500

> security people have issues with that?

That's a very good question. I originally missed out on the fact that  
use of the fingerprint was a requirement in RFC4572 rather than an  
option. (It surprises me, as it only seems to apply when using self- 
signed certs _and_ when you have a protected signaling channel.) It  
doesn't seem necessary in the case where you have relays  with certs  
that are signed by well-known CAs. I don't think this was a scenario  
envisioned by COMEDIA-TLS, which only talks about direct connections  
between endpoints.

OTOH, I am not particularly inclined to countermand normative  
requirements in 4572 without a really strong consensus to do so.  
Hopefully everyone reading this realized now that this affects the use  
of COMEDIA even without the c-line and/or path attribute modification,  
so even if we split sections 4.1 (comedia) and 4.2 (c-line/path attr)   
into separate docs we would have to deal with this in the draft  
resulting from 4.1.

> e.g. using the AUTH method.

I think it is technically possible to do so, if we have consensus to  
update 4975 and 4976 to support it.

> AFAIK, that has nothing to do with whether the fingerprint is used or

I'm a little confused on this one--I didn't think RFC4145 allowed the  
active/active case.

> be mentioned in the draft.

I don't think that's necessarily the case--very likely it will be  
"passive". I don't think the COMEDIA negotiation affects how an  
endpoint connects to its own relay. It's really about connection  
between the edge-device operating on behalf on one endpoint and the  
edge-device operating on behalf of the other endpoint.

For example, imagine Alice has a relay, and Bob does not. Alice will  
always connect to her relay. The COMEDIA negotiation will control  
whether Bob connects to the relay, or the relay connects to Bob.

(I'm starting to feel the need for some example call flows)

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 May 2009 17:15:36 -0500

On May 19, 2009, at 4:37 AM, Christer Holmberg wrote:

[...]

> would be told to check for the name "relay.biloxi.com", instead of

I think that's effectively similar to sending the fingerprint; it's  
just a different thing to match on.

> entities - including intermediates.

As I mentioned in SF, I think we should be careful to avoid suggesting  
that intermediaries lead an endpoint to believe it has end-to-end TLS  
protection when it does really doesn't. One of the reasons for the  
path attribute in the first place was to make it clear to endpoints  
that there were relays in the path. SBCs/ALGs are generally  not that  
open about their presence.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 May 2009 17:22:22 -0500

See my rant at the end, in response to Christer's email. I haven't  
sent it to the list yet.

Am I grasping at too abstract a concept? I.e., ignoring the basic  
repugnancy of SBCs, is it reasonable to argue that we shouldn't  
_in_general_ modify protocol to work with proprietary devices without  
documenting our assumptions about said device behavior and how the  
protocol modification works with these assumptions?

------------------------------------

(as individual)

> statement that it's not only about one vendor.

Forgive my ignorance, but does PoC specify intermediary behavior?

> a relatively small thing compared to having to modify MSRP messages.

Do we expect this draft to specify the actual middlebox behavior that  
is enabled by changing the treatment of the path attribute URIs?

The point I am struggling with is, this part of the ACM draft does not  
add value in itself. Rather, it sets out to relax an MSRP requirement  
to enable another middlebox to add value. But the behavior of that  
middlebox is not standardized, and we haven't really analyzed the  
requirements for the middlebox to get its job done. And we know full  
well that there are security implications both in this new behavior we  
propose for the middlebox (i.e. rewriting path attributes) as well as  
the presence of the middlebox in the first place.

This is pretty much the same argument that has been popping up in all  
of RAI concerning the collision between SBCs and the SIP architecture  
as defined by the IETF.

If we are going to change MSRP to enable SBCs or any other sort of  
middlebox, I'd really like to see more documentation on how that  
middlebox is expected to behave in context, and how the whole  
architecture works when said middlebox is present. I'm not necessarily  
talking about normative specification.This is the point I was trying  
to get across in previous reviews when I suggested we needed some use  
case analysis and possibly call flows to describe the requirements  
that section 4.2 sets out to solve.

We spun up a whole working group (BEHAVE) to do this for NATs, and  
subsequently learned that many of or generally held assumptions were  
wrong.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 May 2009 19:01:46 -0500

Well, crud. The top part of that was a private email that I  
accidentally copied. Please ignore anything anything above the "as  
individual" comment.

Clearly I am not qualified to work this new-fangled Internet thing.

On May 19, 2009, at 5:22 PM, Ben Campbell <[email-masked]> wrote:

> _in_general_ modify protocol to work with proprietary devices  
> without documenting our assumptions about said device behavior and  
> how the protocol modification works with these assumptions?
>
> Do we expect this draft to specify the actual middlebox behavior  
> that is enabled by changing the treatment of the path attribute URIs?
>
> The point I am struggling with is, this part of the ACM draft does  
> not add value in itself. Rather, it sets out to relax an MSRP  
> requirement to enable another middlebox to add value. But the  
> behavior of that middlebox is not standardized, and we haven't  
> really analyzed the requirements for the middlebox to get its job  
> done. And we know full well that there are security implications  
> both in this new behavior we propose for the middlebox (i.e.  
> rewriting path attributes) as well as the presence of the middlebox  
> in the first place.
>
> This is pretty much the same argument that has been popping up in  
> all of RAI concerning the collision between SBCs and the SIP  
> architecture as defined by the IETF.
>
> architecture works when said middlebox is present. I'm not  
> necessarily talking about normative specification.This is the point  
> I was trying to get across in previous reviews when I suggested we  
> needed some use case analysis and possibly call flows to describe  
> the requirements that section 4.2 sets out to solve.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 20 May 2009 09:11:45 +0200

Hi, 

>That's a very good question. I originally missed out on the 
>fact that use of the fingerprint was a requirement in RFC4572 
>rather than an option. (It surprises me, as it only seems to 
>apply when using self- signed certs _and_ when you have a 
>protected signaling channel.) It doesn't seem necessary in 
>the case where you have relays  with certs that are signed by 
>well-known CAs. I don't think this was a scenario envisioned 
>by COMEDIA-TLS, which only talks about direct connections 
>between endpoints.

We need to look into that.

But, without relays you could of course have direct connections also
between MSRP endpoints.

>Hopefully everyone reading this realized now that this 
>affects the use of COMEDIA even without the c-line and/or 
>path attribute modification, so even if we split sections 4.1 (comedia)
and 4.2 
>(c-line/path attr) into separate docs we would have to deal with this
in the 
>draft resulting from 4.1.

Yes. I haven't commented your summary yet, but I think we need to make
clear that there are still comedia issues that we need to look into.

---------

>>fingerprint attribute (again, I am only talking about pure comedia 
>>here - not SBC impacts etc). But, even with relays, I guess it would
be 
>I think it is technically possible to do so, if we have 
>consensus to update 4975 and 4976 to support it.

Would we need to update 4975 and 4976 for that? Wouldn't it be part of
the ACM comedia extension? The draft would define a new URI parameter.

Of course, there could be a case where the client supports comedia, and
the relay doesn't, and then I guess the relay would discard the
fingerprint in the AUTH.

---------

active/active case.

I think it's one of the new use-cases that Adam indicated would now be
supported.

But, maybe RFC4145 doesn't support "direct" active/active between the
endpoints, so you would need to have an intermeidate in between in that
case.

---------

>edge-device operating on behalf of the other endpoint.

Well, comedia doesn't distinguish between relays, edge-devices and
endpoints, does it? It only talks about establishing a TCP connection
towards a remote location.

But, I guess we need to think a little more about that.

---------

>whether Bob connects to the relay, or the relay connects to Bob.

The relay is not aware of the comedia negotiation, so it will only
connect to Bob if Alice sends a SEND and a TCP connection doesn't exist.
But, based on the discussion we had Alice would send a SEND if she is
"active", so it would work.

---------
 
>(I'm starting to feel the need for some example call flows)

Yes.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 20 May 2009 14:17:07 +0200

Hi, 

>I think that's effectively similar to sending the 
>fingerprint; it's just a different thing to match on.

Correct. I used the domain names in order to be able to correlate to
your example :)

>>intermeidate MUST terminate TLS in this case. If BOTH Alice and Bob  
>>open TCP connections (since Bob is behind a relay, I assume he 
>>would ALWAYS be "active"), the intermeidate may need to terminate TLS
anyway, in
>>e.g. talking about "entities which generate SDP for MSRP". 
>>That would then apply to any type of entity.
>>
>>header needs to ensure that a matching certificate is provided to  
>>other entities which connect to it. This can be achieved by 
>>terminating TLS connections (instead of being TLS transparent) or by 
>>providing correct certificate information in the signalling to other
entities which
>As I mentioned in SF, I think we should be careful to avoid 
>suggesting that intermediaries lead an endpoint to believe it has 
>end-to-end TLS protection when it does really doesn't.

Even with legacy MSRP it IS possible to insert intermediates (eventhough
they would have to modify the MSRP messages), so you already have the
problem - as you have with any other type of media.

But, in some cases the clients can at least make some assumptions by
comparing the certificate domains with the path attribute domains.

So, in your example above, no matter if the TLS is terminated by the SBC
or the relay, Alice would detect that it's not end-to-end. If terminated
by the SBC, Alice could also detect that it's not even terminated in the
beloxi.com domain.

>One of the reasons for the path attribute in the first place was to
make it clear to endpoints that there were relays in the path. SBCs/ALGs
are generally not that open about their presence.

Sure, but do we really expect the user to really make different
decissions based on that knowledge? Will the user even be informed about
whether there are relays in the path or not? 

If I want to establish an MSRP session with you, I probably wouldn't
care whether you are behind a relay or not. I would trust that the
operator(s) make sure my stuff doesn't end up in the wrong hands.

And, if I have something very very very sensitive to send you, I may
encrypt the payload myself, and not rely on the MSRP provided encryption
- because even if I start looking at the path attributes etc I can still
not be 100% that there is no intermediate somewhere.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 20 May 2009 14:54:47 +0200

Hi, 

>>>>>>In particular, I am skeptical about doing non-trivial changes to 
>>>>>>make MSRP work better across proprietary intermediaries without 
>>>>>>some better description of what will and will not work in the 
>>>>>>general case (i.e. not just what will work with one vendor.)
>>>>>
>>>>behavior, or some survey of behavior like BEHAVE did with NATs, 
>>>>we're just sort of hoping things will work most of the time.
>>>>That may be good enough to write product requirements around, but 
>>>>it's probably not good enough to write standards around.
>>>

>>>less like any other type of TCP media, without having to modify the 
>>>MSRP messages etc.
>>>

>>>But, OMA PoC uses MSRP, so compliant intermediates will have to 
>>>support TCP. 3GPP IMS uses MSRP, so compliant intermediates will have

>>>to support TCP. Intermediates also DO exist in other SIP networks, so

>>>in order for MSRP to work they will have to support TCP. 
>>>That is what I meant by the statement that it's not only about one
vendor.
>>Forgive my ignorance, but does PoC specify intermediary behavior?

I would have to double check exactly what it specifies. PoC does use
c/m- based MSRP routing, though.

>>>issue is with supporting legacy MSRP, and that is what ACM is trying 
>>>to solve.
>>>
>>>comes to sending the media through them they all behave in the same
>>>way: by modifying the SDP.
>>>
>>>
>>>Of course, If we also for ACM would still use the a=path attribute 
>>>for routing, rather than the c/,- line, the intermeidates will of 
>>>course have to be able to modify the a=path attribute. 
>>>But, no matter whather that can be done using configuration (I guess
that is what 
>>>Hadirel indicated for his product) or whether it requires 
>>>a software patch, it's a relatively small thing compared to having to
modify 
>>>MSRP messages.

We could specify the intermediate assumptions we make.

But, I don't think we need to specify middlebox behavior.

We have a generic specification which says that path is used to
esatblish the MSRP route, and the fingerprint (if used) is used to
provide the certificate information to use.

Any intermediate would then need to act according to that - in a similar
way as they act according to c/m routing rules for other media - if they
want to support MSRP.

If one does not want to support MSRP he/she can prevent MSRP from
working no matter what we specify...

>>The point I am struggling with is, this part of the ACM draft does not
add value in itself.

It makes it possible to easier deploy MSRP in a large number of network
(no matter if we like the architecture of those networks or not), which
I think adds value.

People are not going to remove their intermediates just in order to make
legacy MSRP to work - at least not until they have other mechanisms to
do whatever functions those intermediates are performing.

>>Rather, it sets out to relax an MSRP requirement to enable another
middlebox to add value. But the behavior of that 
>>necessarily talking about normative specification.This is the point I
was trying to get across in previous reviews when I suggested we 
>>needed some use case analysis and possibly call flows to describe the
requirements that section 4.2 sets out to solve.

As far as MSRP is concerned, the intermediate would need to modify the
path attribute, and if fingerprint is used it would need to ensure that
is correct (assuming it terminates TLS).

I think that is covered by the generic text I proposed, but of course we
can explicitly write down those assumptions on intermediates.

We can also document the security issues which intermediates bring, but
I don't think those are specific to MSRP.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 May 2009 09:53:12 -0500

> subsequently learned that many of or generally held assumptions were 

I agree wholeheartedly with Ben's sentiment regarding the assumptions 
we're making about SBC behavior, and I think the comparison to NATs is 
quite appropriate. Saying that SBCs operate "by modifying the SDP"[1] is 
as useful as saying that NATs operate "by changing IP addresses." You 
can make certain assumptions about what these changes look like, but 
they're just assumptions. And right now, they're not even documented 
assumptions.

We've been down this road before. For example, we spent a lot of work to 
develop a protocol to characterize NATs based on untested assumptions 
about NAT behavior. It was only after we actually spun up BEHAVE and did 
the work documented in draft-jennings-behave-test-results that we 
realized we had wasted vast man-years of engineering resources for 
naught. RFC 3489 stands as a tombstone to our hubris and carelessness.

I am certain that we have relevant lessons to learn from BEHAVE, and 
that many of them fall in the category of "trying to engineer protocols 
around an undefined entity is folly."

/a

[1] http://www.ietf.org/mail-archive/web/simple/current/msg08392.html

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 May 2009 10:00:13 -0500

> is correct (assuming it terminates TLS).

I think we have a disconnect here. One of the key arguments, as far as I 
understand it, for making the changes proposed in MSRP-ACM has to do 
with working through existing SBCs.

Because, let's face it, if SBCs need to go mucking with more than just 
the c= and m= lines, then they may as well understand the MSRP-specific 
syntax anyway. If this is true, then backwards compatibility with 
deployed SBCs is not a design consideration.

And here we have Christer saying that the intermediary would need to 
modify the a= lines in a MSRP-specific way.

If that's the case, why are we chasing a requirement to relax the URI 
matching rules?

/a

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 May 2009 10:30:34 -0500

On May 20, 2009, at 10:00 AM, Adam Roach wrote:
>
> I think we have a disconnect here. One of the key arguments, as far  
> as I understand it, for making the changes proposed in MSRP-ACM has  
> to do with working through existing SBCs.
>
> Because, let's face it, if SBCs need to go mucking with more than  
> just the c= and m= lines, then they may as well understand the MSRP- 
> specific syntax anyway. If this is true, then backwards  
> compatibility with deployed SBCs is not a design consideration.
>
> If that's the case, why are we chasing a requirement to relax the  
> URI matching rules?

< history review>

Christer's original proposal was to have MSRP-ACM compliant devices  
use the c-line addressing rather than the "a=path" line, in order to  
be more friendly to existing SBCs. This would not work with MSRP  
relays, except  in a pure "fall back to 4975 behavior model". The  
working group stated a requirement to support the scenario where an  
endpoint is behind an SBC, and it's peer is behind a relay.

The a=path modification, and the relaxation of URI rules were an  
attempt to make ACM work with relays. We've since run into TLS cert  
matching complications with that approach.

</history review.

But to Adam's point, I think we've got some conflicting requirements.  
The requirement to interoperate between existing unmodified SBCs  
(without behavior modification)  and RFC4976 relays cannot be achieved.

The path attribute discussion contains an implicit assumption that we  
can modify SBCs a little (e.g. MSRP specific treatment of SDP), but  
not a lot (e.g. making them process the to-path and from-path header  
fields in MSRP SEND requests.) That is an assumption worth explicit  
discussion.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 May 2009 14:02:20 -0400

> whether there are relays in the path or not? 

This is really about the infamous "lock icon".
In the case of MSRP it is a quite a bit simpler problem than with 
phones. Most of the ground has already been broken for https.

I surely do make different sage decisions based on the lock icon in a 
web browser. I think people would quickly do so with a lock icon in an 
IM session window too, if it was properly socialized.

> operator(s) make sure my stuff doesn't end up in the wrong hands.

Right!
They have such a good track record of keeping stuff private.

> not be 100% that there is no intermediate somewhere.

How would you do that in a way that is usable by anyone except a 
programmer? Most users are dependent on the available tools.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 20 May 2009 23:29:03 +0200

Hi, 

>>They have such a good track record of keeping stuff private.

But still we keep using them.

>>- because even if I start looking at the path attributes etc I can 
>>still not be 100% that there is no intermediate somewhere.
>>

My MSRP client may have a built-in option which allows me to encrypt the
data.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 May 2009 17:53:56 -0400

> But still we keep using them.

We are stuck using whatever it takes to talk to who we want to talk to.
We don't have the level of open interop and competition we do with web apps.

> My MSRP client may have a built-in option which allows me to encrypt the

That of course assumes that the person on the other end has the same.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 21 May 2009 00:02:09 +0200

Hi, 

>>>>>If I want to establish an MSRP session with you, I probably 
>>>>>wouldn't care whether you are behind a relay or not. I would trust 
>>>>>that the operator(s) make sure my stuff doesn't end up in the wrong
hands.
>We don't have the level of open interop and competition we do with web
apps.

Maybe not, but I am not really sure how that relates to MSRP ACM.

>>>>encrypt the payload myself, and not rely on the MSRP provided 
>>>>encryption - because even if I start looking at the path attributes
etc I can 
>> 
>>My MSRP client may have a built-in option which allows me to encrypt
the data.
>That of course assumes that the person on the other end has the same.

Sure, but that is true for whatever security mechanism, on whatever
level.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 21 May 2009 00:19:24 +0200

Hi, 

we're making about SBC behavior, and I think the comparison to NATs is
quite appropriate. Saying that SBCs operate "by modifying the 
>SDP"[1] is as useful as saying that NATs operate "by changing IP
addresses." You can make certain assumptions about what these changes
look like, but they're just assumptions. And right now, they're not 
>even documented assumptions.

ACM is not standardized yet, so we don't need to make any assumptions
regarding how existing intermediates modify the path attribute etc. If
they DO modify the path attribute, legacy MSRP won't work, and it
doesn't matter what we do.

What we need to do is to describe how ACM routing etc work. People will
then have to make sure that intermediates who are supposed to support
ACM will act according to that - as for any other meida (we haven't
specified how intermediates shall modify the c-line for audio etc).

>We've been down this road before. For example, we spent a lot of work
to develop a protocol to characterize NATs based on untested assumptions
about NAT behavior.

Unlike NAT behavior, there is no existing ACM behavior, so we don't need
to make assumptions on how intermediates work regarding ACM.

Personally I also think that the NAT behavior issue is far more
complicated than intermediate behavior for MSRP ACM.

Having said that, I have no problem to document how an intermediate
which is to support ACM is expected to behave when it comes to modifying
the SDP etc, if we think that is useful. But, we don't need to make
assumptions about existing ACM support in intermediates.

Regards,

Christer

>It was only after we actually spun up BEHAVE and did the work
documented in draft-jennings-behave-test-results that we realized we had
wasted vast man-years of engineering resources for naught. RFC 3489 
>stands as a tombstone to our hubris and carelessness.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 21 May 2009 00:29:03 +0200

Hi, 

>I think we have a disconnect here. One of the key arguments, as far as 
>I understand it, for making the changes proposed in MSRP-ACM has to do 
>the c= and m= lines, then they may as well understand the MSRP- 
>specific syntax anyway. If this is true, then backwards compatibility 
>with deployed SBCs is not a design consideration.
>
matching rules?

Below Ben indicates why it was proposed to change that - and I also
think also You asked why we couldn't use the path attribute instead.

But, the question is not whether an intermediate CAN understand the MSRP
specific syntax - the question is the COST the intermediate having to
modify every MSRP message. Most sessions contain only a single
offer/answer exchange, but most MSRP sessions are probably going to
contain more than a single MSRP message exchange.

>< history review>
>
>Christer's original proposal was to have MSRP-ACM compliant devices use
the c-line addressing rather than the "a=path" line, in order to be more
friendly to existing SBCs. This would not work with MSRP 

Correct (we are discussing a solution proposal for that, though).

And, as we have been discussing, there may be some cert issues related
to the comedia part, if there are relay cases where the fingerprint
attribute must be included.

>The path attribute discussion contains an implicit assumption that we
can modify SBCs a little (e.g. MSRP specific treatment of SDP), but not
a lot (e.g. making them process the to-path and from-path 
>header fields in MSRP SEND requests.) That is an assumption worth
explicit discussion.

Instead of "modify SBCs" I guess we should say "add MSRP specific
treatment of SDP to SBCs". MSRP ACM is currently not standardized, so
there is nothing existing MSRP ACM related which needs to be modified :)

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 May 2009 17:45:28 -0500

Christer Holmberg wrote:
> treatment of SDP to SBCs".

No, I don't think that's completely correct.

The TLS-related issues may well force SBCs to handle the media 
differently than they handle other kinds of connections. I don't think 
it's reasonable to restrict the solution space to "only those things 
that can be achieved through SDP handling alone."

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 21 May 2009 11:37:42 +0200

Hi, 

>that can be achieved through SDP handling alone."

It is true that there are TLS related issues, but they may not be
specific to the ACM path modification part. We seem to have TLS issues
also for the pure comedia part.

Also, I am not sure they are even specific to MSRP. A user using TLS, no
matter for what media or signalling, must always have the correct
information regarding which certificate to use.

But, for ACM, as we have discussed, it is rather clear what the SBC
could do in order to make it work. It needs to make sure the user has
the correct certification information, both when the SBC terminates TLS
and when it treats TLS transparently.

I proposed some generic MSRP text about that, so SBCs which are to
support MSRP TLS would simply have to follow that also. Otherwise things
simply wouldn't work. 

Regards,

Christer