Subject: Re: [Simple] MSRP-ACM compatibility

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 1 Apr 2009 19:49:02 +0200

Hi,

Regarding 2), for those of you who were not in SFO, the proposed
backwards compability solution was to change the session mapping
function for legacy MSRP, so that only the user part is used when
comparing the SDP a=path attribute with the URI carried in the MSRP
message.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hisham Khartabil
Sent: Tuesday, March 31, 2009 11:58 PM
To: Simple WG
Subject: [Simple] MSRP-ACM compatibility

The MSRP-ACM draft has an open requirements question on backwards
compatibility with endpoints that use MSRP relays. In San Francisco some
20 or so people raised their hands one way or another on this question,
yet only a much smaller number have engaged in the list discussion.

Please offer your opinions on the following questions. We'd appreciate
the reasoning behind your opinions, rather than just yes or no votes.
We'd really like to hear from every person who raised a hand in San
Francisco. If you stated an opinion at the microphone, please restate it
here.

1) Is there a requirement for an endpoint that uses the C-line
addressing mechanism in the MSRP-ACM draft to be able to talk to an
endpoint that uses an MSRP relay (RFC 4976).

2) If you said yes to 1), is it acceptable to update RFC 4975 and/or RFC
4976 to achieve compatibility?  If so, how extensively?

Much appreciated,
Hisham
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: <[email-masked]>
Date: Thu, 2 Apr 2009 15:31:45 +0200

Hi,

1) I think that would be desirable, even though I haven't still heard of other MSRP relay deployments or plans other than what Adrian Georgescu has brought up. (In reality SIP interconnect is still not that common, especially for other media than voice, so even if there were deployments of both 4975 and ACM, they would probably still be isolated anyway.)

2) To my understanding there is no way to achieve compatibility without updating at least 4975. It would be good if we could keep 4976 unchanged, so the existing relay implementations would not be affected. I'd also expect that 4975bis endpoint could talk to legacy 4975 endpoint. So, those would be my main constraints for revising MSRP.

I guess we would then be (in theory) in a situation where we have three types of endpoints in the field: 4975, 4975bis and 4975+ACM. Others could talk to each other except 4975 and 4975+ACM. 

Question: If we do go and update 4975, would it then actually make sense to fold the acm draft content in the revision? 

Markus

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Hisham Khartabil
>Sent: 01 April, 2009 01:58
>To: Simple WG
>The MSRP-ACM draft has an open requirements question on 
>backwards compatibility with endpoints that use MSRP relays. 
>In San Francisco some 20 or so people raised their hands one 
>way or another on this question, yet only a much smaller 
>number have engaged in the list discussion.
>
>Please offer your opinions on the following questions. We'd 
>appreciate the reasoning behind your opinions, rather than 
>just yes or no votes.
>We'd really like to hear from every person who raised a hand 
>in San Francisco. If you stated an opinion at the microphone, 
>please restate it here.
>
>addressing mechanism in the MSRP-ACM draft to be able to talk 
>to an endpoint that uses an MSRP relay (RFC 4976).
>
>2) If you said yes to 1), is it acceptable to update RFC 4975 
>and/or RFC 4976 to achieve compatibility?  If so, how extensively?
>
>Much appreciated,
>Hisham

---

From: <[email-masked]>
Date: Thu, 2 Apr 2009 15:33:51 +0200

Hi Christer,

Two questions on your proposal:

* I assume no changes to relays would be required.
* I assume upgared MSRP endpoint could establish a session with a legacy MSRP endpoint.

If this is correct, I'm fine with this approach.

Markus

>On Behalf Of ext Christer Holmberg
>Sent: 01 April, 2009 20:49
>To: Hisham Khartabil; Simple WG
>Subject: Re: [Simple] MSRP-ACM compatibility
>
>
>Hi,
>
>Regarding 2), for those of you who were not in SFO, the 
>proposed backwards compability solution was to change the 
>session mapping function for legacy MSRP, so that only the 
>user part is used when comparing the SDP a=path attribute with 
>the URI carried in the MSRP message.
>
>Regards,
>
>Christer
>
> 
>
>On Behalf Of Hisham Khartabil
>and/or RFC

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 16:44:03 +0200

Hi Markus,

4975 and 4975bis endpoints would be able to talk to each other, as
today.

4975 and 4975+ACM endpoints would also able to talk to each other, as
long as there is no intemediate which modifies the a=path attributes.

You are right that, in theory, we could have 3 different types of
endpoints. But, I think that would change, because new endpoints would
be at least 4975bis.

I think we should keep 4975bis and ACM separated. The reason is that I
think a single document would be rather messy, since we would describe
two different routing mechanisms. But I'm happy to hear what others
think.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, April 02, 2009 2:32 PM
To: [email-masked]; [email-masked]
Subject: Re: [Simple] MSRP-ACM compatibility

Hi,

1) I think that would be desirable, even though I haven't still heard of
other MSRP relay deployments or plans other than what Adrian Georgescu
has brought up. (In reality SIP interconnect is still not that common,
especially for other media than voice, so even if there were deployments
of both 4975 and ACM, they would probably still be isolated anyway.)

2) To my understanding there is no way to achieve compatibility without
updating at least 4975. It would be good if we could keep 4976
unchanged, so the existing relay implementations would not be affected.
I'd also expect that 4975bis endpoint could talk to legacy 4975
endpoint. So, those would be my main constraints for revising MSRP.

I guess we would then be (in theory) in a situation where we have three
types of endpoints in the field: 4975, 4975bis and 4975+ACM. Others
could talk to each other except 4975 and 4975+ACM. 

Question: If we do go and update 4975, would it then actually make sense
to fold the acm draft content in the revision? 

Markus

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Hisham Khartabil
>compatibility with endpoints that use MSRP relays.
>In San Francisco some 20 or so people raised their hands one way or 
>another on this question, yet only a much smaller number have engaged 
>in the list discussion.
>
>Francisco. If you stated an opinion at the microphone, please restate 
>it here.
>
>2) If you said yes to 1), is it acceptable to update RFC 4975 and/or 
>RFC 4976 to achieve compatibility?  If so, how extensively?
>
>Much appreciated,
>Hisham

---

From: Ben Campbell <[email-masked]>
Date: Thu, 2 Apr 2009 14:36:08 -0500

(as an individual contributor)

On Mar 31, 2009, at 5:57 PM, Hisham Khartabil wrote:

> compatibility with endpoints that use MSRP relays. In San Francisco
> some 20 or so people raised their hands one way or another on this
> question, yet only a much smaller number have engaged in the list
> discussion.
>

I believe this is a strong requirement for the C-Line part of the ACM  
draft to move forward. As I've mentioned, I do not want to see us  
create separate "camps" of MSRP implementations that are unable to  
communicate with each other.

> RFC 4976 to achieve compatibility?  If so, how extensively?

I think minor updates to 4975 and/or 4976 are acceptable. By _minor_,  
I mean updates that do not remove significant features of the  
protocol, or dilute the security properties of the protocol, or  
require highly "invasive" changes to the architecture or current  
implementations.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 2 Apr 2009 14:39:21 -0500

> comparing the SDP a=path attribute with the URI carried in the MSRP

We also discussed the fact that this proposal may interfere with TLS  
certificate name matching, when one endpoint of the TLS association  
has a cert that is bound to an address or domain name.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Thu, 2 Apr 2009 14:41:25 -0500

A general comment: I don't think an update to 4975 or 4976 necessarily  
implies a bis draft. It's possible to do focused updates without  
revising the entire spec. For example, the SIP essential correction  
drafts.

On Apr 2, 2009, at 8:31 AM, <[email-masked]> <[email-masked] 
 > wrote:

> Hi,
>
> 1) I think that would be desirable, even though I haven't still  
> heard of other MSRP relay deployments or plans other than what  
> Adrian Georgescu has brought up. (In reality SIP interconnect is  
> still not that common, especially for other media than voice, so  
> even if there were deployments of both 4975 and ACM, they would  
> probably still be isolated anyway.)
>
> 2) To my understanding there is no way to achieve compatibility  
> without updating at least 4975. It would be good if we could keep  
> 4976 unchanged, so the existing relay implementations would not be  
> affected. I'd also expect that 4975bis endpoint could talk to legacy  
> 4975 endpoint. So, those would be my main constraints for revising  
> MSRP.
>
> I guess we would then be (in theory) in a situation where we have  
> three types of endpoints in the field: 4975, 4975bis and 4975+ACM.  
> Others could talk to each other except 4975 and 4975+ACM.
>
> Question: If we do go and update 4975, would it then actually make  
> sense to fold the acm draft content in the revision?
>
> Markus
>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 21:44:32 +0200

Correct. As shown in SFO, the actual impacts (assuming we'll go for the
presented solution) on 4975 are rather minor.

Regards,

Christer  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Campbell
Sent: Thursday, April 02, 2009 8:41 PM
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Simple] MSRP-ACM compatibility

On Apr 2, 2009, at 8:31 AM, <[email-masked]>
<[email-masked]  > wrote:

> Hi,
>
> 1) I think that would be desirable, even though I haven't still heard 
> of other MSRP relay deployments or plans other than what Adrian 
> Georgescu has brought up. (In reality SIP interconnect is still not 
> that common, especially for other media than voice, so even if there 
> were deployments of both 4975 and ACM, they would probably still be 
> isolated anyway.)
>

>> appreciate the reasoning behind your opinions, rather than just yes 
>> or no votes.

---

From: Adam Roach <[email-masked]>
Date: Thu, 02 Apr 2009 15:32:20 -0500

> endpoint that uses an MSRP relay (RFC 4976).

Yes.

Unless we're going to fully deprecate relays, I think this is a hard 
requirement -- otherwise, you're effectively defining two mutually 
incompatible MSRP "profiles." That is not the recipe for protocol 
interoperation.

> RFC 4976 to achieve compatibility?  If so, how extensively?

I have no objection to normatively updating MSRP so that the machine 
portion is no longer considered in matching message sessions. Anything 
more extensive than that would probably give me significant cause for 
concern.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 23:37:37 +0200

Hi, 

>Unless we're going to fully deprecate relays, I think this is a hard
requirement -- otherwise, you're effectively 
>defining two mutually incompatible MSRP "profiles." That is not the
recipe for protocol interoperation.

I think most of us agree that the deployments of relays is relatively
limited, so we need to keep that in mind when discussing something which
I strongly believe is going to be much more deployed. That doesn't mean
we shouldn't care, but maybe we will have to live with some limitations.

We did have some off-line discussions regarding the TLS issue in SFO.
Maybe Ben could say a few words about what was discussed?

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Apr 2009 20:57:39 -0400

My opinion is yes to both.
My reasoning is since half the people said they wanted it to be backward compatible as much as possible, and the other half said they didn't care about backwards compatibility, I think the only path to reach consensus is to make whatever changes we need to, to make it backward compatible.  That way a majority of the people should be satisfied.
I personally don't care about backwards compatibility, but I do care that we reach consensus and move forward with a solution.

-hadriel

> Sent: Tuesday, March 31, 2009 6:58 PM
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Apr 2009 21:02:22 -0400

> communicate with each other.

While I agree it is obviously possible to separate some parts of the ACM draft, I don't see how that wouldn't still end up with separate "camps" of MSRP implementations.  ISTM that we either solve it all in one go, or not at all.  The fewer final separate RFC docs there are, the better, imo - and the only people I've seen interested in using the comedia aspects are the same ones who want the ACM aspects in general. (though that could just be a false impression on my part)

-hadriel

---

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Apr 2009 15:18:22 -0500

> we shouldn't care, but maybe we will have to live with some  

Limited compared to what? The deployment of _MSRP_ is fairly limited.  
Does anyone have an actively functioning deployment of MSRP that uses  
firewall traversal techniques other than MSRP relays?

> Maybe Ben could say a few words about what was discussed?

A summary of what I recall:

When an MSRP endpoint uses TLS to connect to a peer, it needs to  
verify that the certificate presented by the peer does in fact belong  
to the party it wants to talk to, by making sure the SubjectAltName of  
the peer certificate matches the host name or IP address in the  
associated MSRP URI. The proposal we discussed in the work group  
meeting was designed to allow a middlebox to rewrite the host part of  
MSRP URIs inside the path attribute in the SDP.  If they do this,  
there are scenarios where the certificate SubjectAltName will no  
longer match the URI.

For example, assume A uses an MSRP Relay, and B uses an SBC, following  
the discussed proposal. A sends an SDP "path" attribute that looks  
something like the following. Furthermore, assume the SBC supports TCP  
media,and transparently relays the TLS handshake.

a=path:MSRPS://A/823497w, MSRPS://relay/28g9345ikas

But when the SBC changes this to look like

a=path:MSRPS://A/823497w, MSRPS://sbc/28g9345ikas.

If they actually In the case of two humans communicating over client- 
class devices, this is not likely to be an issue.

B then opens a TCP connection to "sbc", and starts a TLS handshake. It  
expects to get a certificate matching "sbc". But since the SBC  
transparently relays the handshake to the MSRP relay, B instead gets a  
certificate for "relay". B interprets this as a TLS authentication  
failure.

This may not be a problem for some scenarios with no MSRP relays,  
where the TLS association is peer to peer between the MSRP devices.  
First, TLS is not likely used in this case, due to client-certificate  
issues. If it _is_ used, it's probably with self-signed certs and cert  
fingerprints passed in the SDP. However, if one of the endpoints  
actually has a certificate bound to its host name or IP address, we  
still have the problem. For example, assume one of the peers is a MSRP  
conference server with a conventional server certificate.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 3 Apr 2009 23:30:16 +0200

Hi, 

>> limited, so we need to keep that in mind when discussing something 
>> which I strongly believe is going to be much more deployed. That 
>> doesn't mean we shouldn't care, but maybe we will have to live with 
>> some limitations.
>
firewall traversal techniques other than MSRP 
>relays?

OMA has their own profile of MSRP, which in fact is similar to ACM
(however, our intention has been to suggest that OMA adopts ACM, when/if
it's done).

But, apart from OMA I don't think there are many MSRP deployments using
firewall traversal techniques in the first place - no matter what
technique is used. The main reason is that people don't want to have
MSRP specific solutions. They want to use solutions that they use for
other types of media - which ACM is all about.

I strongly (based on requests and feedback I've received) believe that
ACM would increase MSRP deployments also in networks with SBCs etc, and
there are quite a few of those networks :)

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 4 Apr 2009 02:08:56 -0400

> Of Christer Holmberg

I don't track the market of it myself, but personally I find that a big driver for MSRP is coming from the 3GPP/IMS-type of cases, and I count OMA as being one in that line.  I believe it's being marketed under the "Rich Communication Suite" initiative.

I don't see MSRP being asked for much by anyone else for IM/file-transfer/video-share, because afaict, with few notable exceptions, most others use XMPP if they use a standard protocol to begin with. (and I believe XMPP tries to use SOCKS for file transfer relay, before falling back to XMPP app-layer relay)

-hadriel

---

From: Jon Peterson <[email-masked]>
Date: Mon, 06 Apr 2009 16:55:28 -0700

I think what's missing in the discussion of the TLS component of MSRP-ACM is
a glance back at 9.3 of RFC4976 - that is, a question of what we're hoping
to prevent with TLS in this case. TLS serves a number of purposes in the
MSRP relay architecture, but the salient one here is to allow the client the
opportunity to authenticate the next hop to which its traffic will not be
confidential. The mandate of TLS usage by MSRP relays is supposed to ensure
message confidentiality to the hop identified by the MSRPS URI. There's no
point in keeping something encrypted on the wire only to hand it over to
someone you can't identify - why bother to have kept it confidential at all?

Even setting aside my predictable objections to a Standards Track document
endorsing SBCs modifying the c, m and a= lines of SDP in SIP messages, I
would be cautious about the approach under discussion. From the perspective
of the client on the side with the SBC, when it sees an MSRPS URI in the
path it locks in that hostname as the one it is trying to reach, and if a
certificate with some other hostname is presented when it contacts that
host, it should certainly view this as a security failure. That client
really has no way to know what relay is supposed to be trusted unless the
path attribute in SDP tells it so. Again, if you don't know who you're
supposed to reveal the messages to, then you're forced to reveal it just
anyone who presents a cert, and if you're revealing it to just anyone, in
what sense is it confidential and why are you bothering to use TLS at all?

Furthermore, into the details of the proposal a bit, I think I understand
what you do when the offerer has a relay and the answerer has an SBC, and
the SBC needs to modify the offerer's c/m and a=path:, but I'm a bit hazier
on how you modify the answerer's SDP in this case in such a way that the
offerer's relay will send MSRP to the SBC on it's way to the client. What
does that case look like?

Incidentally, the comedia stuff in the MRSP-ACM draft seems fine, and I'd
have no problem with that going forward independently.

Jon Peterson
NeuStar, Inc.

On 4/3/09 1:18 PM, "Ben Campbell" <[email-masked]> wrote:
[snip]

---

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Apr 2009 20:19:00 -0500

This is an excellent summary of the concerns that, with considerably  
less eloquence, I have been trying to express.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Apr 2009 20:29:31 -0500

On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote:

> would be cautious about the approach under discussion.

John's comment above inspired me to put words to another concern that  
has been bothering me.

Nothing in the ACM draft says that an SBC or ALG SHOULD modify  
anything. But, the ACM draft (excepting the COMEDIA part) solves no  
problem unless they do so. Or maybe that should be rephrased, the  
draft not solve anything on it's own, but enable SBCs and ALGs to  
solve the problem.

However, SBCs and ALGs are not very predictable in their behavior.  
There's not much in the way of standards there. I do not dispute  
Hadriel that this may work with his company's SBCs--but I have no  
reason to believe it will work with someone else's. Without some  
BEHAVE like effort to at least categorize and suggest best practices  
for these sorts of behaviors, I am skeptical of any standards effort  
to modify protocols to work around them.

---

From: <[email-masked]>
Date: Tue, 7 Apr 2009 08:38:16 +0200

Hi,

One of the main purposes of MSRP-ACM is to allow an SBC/ALG to modify SDP in such a way that User Agents behind NATs will open outbound TCP connections to that SBC/ALG and this way enabling them to communicate. The reason why the draft does not explictly talk about this scenario is that the IETF has not been fond of such things, so they must remain as "public secrets". But, I think it is better to bring it all in the open and in the draft explain how it works and even specify what the SBC/ALG SHOULD do, to make it predicatable. 

Markus

>On Behalf Of ext Ben Campbell
>Sent: 07 April, 2009 04:30
>To: Jon Peterson
>Cc: Adam Roach; Simpletons
>> Even setting aside my predictable objections to a Standards Track 
>> document endorsing SBCs modifying the c, m and a= lines of 
>SDP in SIP 
>> messages, I would be cautious about the approach under discussion.
>
>John's comment above inspired me to put words to another 
>concern that has been bothering me.
>
>anything. But, the ACM draft (excepting the COMEDIA part) 
>solves no problem unless they do so. Or maybe that should be 
>rephrased, the draft not solve anything on it's own, but 
>enable SBCs and ALGs to solve the problem.
>
>There's not much in the way of standards there. I do not 
>dispute Hadriel that this may work with his company's 
>SBCs--but I have no reason to believe it will work with 
>someone else's. Without some BEHAVE like effort to at least 
>categorize and suggest best practices for these sorts of 
>behaviors, I am skeptical of any standards effort to modify 
>protocols to work around them.
>
>
>

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 7 Apr 2009 17:07:30 +1000

(as an individual)

In my opinion, what we need to do is standardise the comedia part
(a=setup), figure out a way to interoperate with legacy MSRP when one
side is using the c/m line to carry destination address, and that's
it. Why are we talking about an intermediary that will modify messages
and break security? We know those boxes exist in the world, but we
don't standarise their behaviour. Why do we want to do that now? If an
SBC vendor wants to work with MSRP-acm, then they can do that in their
own proprietary way. They will break security, but that's new?

Relating to interoperability, can we have the the acm-compliant client
populate both path attribute and c/m lines in the offer?

Hisham

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 09:48:16 +0200

Hi, 

>it. Why are we talking about an intermediary that will modify messages
and break security? We know those boxes exist in the world, but we don't
standarise their behaviour. Why do we want to do that now? 
>If an SBC vendor wants to work with MSRP-acm, then they can do that in
their own proprietary way. They will break security, but that's new?

Yes, in order for the fallback mechanism to work.

Regards,

Christer

Hisham

2009/4/7  <[email-masked]>:
> Hi,
>
> One of the main purposes of MSRP-ACM is to allow an SBC/ALG to modify
SDP in such a way that User Agents behind NATs will open outbound TCP
connections to that SBC/ALG and this way enabling them to communicate.
The reason why the draft does not explictly talk about this scenario is
that the IETF has not been fond of such things, so they must remain as
"public secrets". But, I think it is better to bring it all in the open
and in the draft explain how it works and even specify what the SBC/ALG
SHOULD do, to make it predicatable.
>>Behalf Of ext Ben Campbell

---

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

Hi,

We don't say much about SGCs and ALGs - and that is the whole idea of
ACM! :)

The purpose is to allow SBC/ALG/B2BUA to treat MSRP in the same way they
treat other media. 

Yes, for MSRP they also may have to modify the a=path attribute, in
order to be backward compatible, but the main point is to allow the SBC
to anchor MSRP as any other media, without the media processing part
having to be MSRP aware, and modify MSRP messages.

And, that is not only Hadirel's SBC - it is every SBC I've ever seen.

In addition, this is not something which only SBC vendors want - it is
something the MARKET wants.

Also, I don't really see the benfit in only moving forward with the
comedia part. What would we gain by doing that? What problems would we
solve?

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, April 07, 2009 4:30 AM
To: Jon Peterson
Cc: Christer Holmberg; Adam Roach; Simpletons
Subject: Re: [Simple] MSRP-ACM compatibility

On Apr 6, 2009, at 6:55 PM, Jon Peterson wrote:

> document endorsing SBCs modifying the c, m and a= lines of SDP in SIP 

Nothing in the ACM draft says that an SBC or ALG SHOULD modify anything.
But, the ACM draft (excepting the COMEDIA part) solves no problem unless
they do so. Or maybe that should be rephrased, the draft not solve
anything on it's own, but enable SBCs and ALGs to solve the problem.

However, SBCs and ALGs are not very predictable in their behavior.  
There's not much in the way of standards there. I do not dispute Hadriel
that this may work with his company's SBCs--but I have no reason to
believe it will work with someone else's. Without some BEHAVE like
effort to at least categorize and suggest best practices for these sorts
of behaviors, I am skeptical of any standards effort to modify protocols
to work around them.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 10:23:47 +0200

Hi, 

messages,

I don't think we are "endorsing" - we are taking real life networks into
consideration :)

>Furthermore, into the details of the proposal a bit, I think I
understand what you do when the offerer has a relay and the answerer has
an SBC, and the SBC needs to modify the offerer's c/m and a=path:, 
>but I'm a bit hazier on how you modify the answerer's SDP in this case
in such a way that the offerer's relay will send MSRP to the SBC on it's
way to the client. What does that case look like?

The SBC would modify the path attribute of the answerer, so that it
points towards the SBC - in the same way as it modifies the path
attribute in the offer if the client behind the SBC acts as offerer.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 10:30:48 +0200

Hi, 

(a=setup), figure out a way to interoperate with legacy MSRP when one
side is using the c/m line to carry destination address,
>and that's it.

Just to clarify: the draft already provides a fallback mechanism when
only one side is using the c/m line. But, that only works when there is
no SBC in the path, so that's what we need to solve.

>From a pure MSRP perspective, the proposal to solve that has been to
update the session mapping procedure in 4975. 

What we are have now been discussing is the TLS part, and I believe
that's where we see the main issues that still need to be sorted out.

Regards,

Christer

---

From: <[email-masked]>
Date: Tue, 7 Apr 2009 13:28:18 +0200

Hi,

It's true we haven't standardized or even recommended how B2BUAs work. But hasn't that exactly led us to the problems we have with e2e security and e2e identifiers. I understand that having BEHAVE define recommendations on NATs does not guarantee that every NAT box will follow them. The same would go for anything the IETF says about B2BUAs. But in this MSRP case it would be still valuable to explain how the B2BUA will act wrt. MSRP-ACM, just for reference if nothing more. 

But for me this is not the main thing about this draft. The main thing would be to get the draft forward, as we clearly have a need for it. There are some mobile operators who seem to have serious plans for MSRP deployment so User Agent developers have to solve the problem in some way in the next few months. Those customers won't care about TLS issues or backwards compatibility too much, but it is of course nice if we can solve them.  

Markus

>From: ext Hisham Khartabil [mailto:[email-masked]] 
>Sent: 07 April, 2009 10:08
>To: Isomaki Markus (Nokia-CIC/Espoo)
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>In my opinion, what we need to do is standardise the comedia 
>part (a=setup), figure out a way to interoperate with legacy 
>MSRP when one side is using the c/m line to carry destination 
>address, and that's it. Why are we talking about an 
>intermediary that will modify messages and break security? We 
>know those boxes exist in the world, but we don't standarise 
>their behaviour. Why do we want to do that now? If an SBC 
>vendor wants to work with MSRP-acm, then they can do that in 
>Relating to interoperability, can we have the the 
>acm-compliant client populate both path attribute and c/m 
>lines in the offer?
>
>Hisham
>
>> One of the main purposes of MSRP-ACM is to allow an SBC/ALG 
>to modify SDP in such a way that User Agents behind NATs will 
>open outbound TCP connections to that SBC/ALG and this way 
>enabling them to communicate. The reason why the draft does 
>not explictly talk about this scenario is that the IETF has 
>not been fond of such things, so they must remain as "public 
>secrets". But, I think it is better to bring it all in the 
>open and in the draft explain how it works and even specify 
>what the SBC/ALG SHOULD do, to make it predicatable.
>>
>> Markus
>>
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 13:43:04 +0200

Hi,

I agree that we should describe how the B2BUA should modify the path
attribute in order to be backward compatible. It's then up to the
operators to decided whether they want that functionality or not.

Some people I've talked to do wish to have interoperability with legacy
MSRP, some don't, but none of the ones I've talk to care about MSRP
relays. It's too expensive and "clumsy", since it requires knowledge
about all relays in the path. So, I again think it would be sad if we
stop the work on something people DO want just because of some potential
issues with something which many people DO NOT want...

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, April 07, 2009 2:28 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Simple] MSRP-ACM compatibility

Hi,

It's true we haven't standardized or even recommended how B2BUAs work.
But hasn't that exactly led us to the problems we have with e2e security
and e2e identifiers. I understand that having BEHAVE define
recommendations on NATs does not guarantee that every NAT box will
follow them. The same would go for anything the IETF says about B2BUAs.
But in this MSRP case it would be still valuable to explain how the
B2BUA will act wrt. MSRP-ACM, just for reference if nothing more. 

But for me this is not the main thing about this draft. The main thing
would be to get the draft forward, as we clearly have a need for it.
There are some mobile operators who seem to have serious plans for MSRP
deployment so User Agent developers have to solve the problem in some
way in the next few months. Those customers won't care about TLS issues
or backwards compatibility too much, but it is of course nice if we can
solve them.  

Markus

>Cc: [email-masked]; [email-masked]; [email-masked]; 
>[email-masked]
>side is using the c/m line to carry destination address, and that's it.

>Why are we talking about an intermediary that will modify messages and 
>break security? We know those boxes exist in the world, but we don't 
>standarise their behaviour. Why do we want to do that now? If an SBC 
>vendor wants to work with MSRP-acm, then they can do that in their own 
>proprietary way. They will break security, but that's new?
>
>to modify SDP in such a way that User Agents behind NATs will open 
>outbound TCP connections to that SBC/ALG and this way enabling them to 
>communicate. The reason why the draft does not explictly talk about 
>this scenario is that the IETF has not been fond of such things, so 
>they must remain as "public secrets". But, I think it is better to 
>bring it all in the open and in the draft explain how it works and even

>specify what the SBC/ALG SHOULD do, to make it predicatable.
>>
>> Markus
>>
>>

---

From: Adam Roach <[email-masked]>
Date: Tue, 07 Apr 2009 09:31:01 -0500

> own proprietary way. They will break security, but that's new?

Your suggestion confuses me. What, in *your* view, is the purpose of 
using c/m lines for carrying addressing information? The MSRP URL does a 
fine job of that.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 07 Apr 2009 09:44:02 -0500

> comedia part. What would we gain by doing that? What problems would we

Right now, in MSRP, the offerer always makes the MSRP connection. This 
works in the following cases:

   1. Neither party is behind a NAT (no relays)
   2. Offerer is behind a NAT, answerer is not (no relays)
   3. Both parties are behind NATs, answerer has a relay

With comedia, the direction of the outbound MSRP connection is 
negotiated between the parties. This works in the following cases:

   1. Neither party is behind a NAT (no relays)
   2. Offerer is behind a NAT, answerer is not (no relays)
   3. Offerer is not behind a NAT, answerer is (no relays)
   4. Both parties are behind NATs, answerer has a relay
   5. Both parties are behind NATs, offerer has a relay

In other words, comedia significantly expands the scenarios in which 
MSRP works.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 07 Apr 2009 09:46:18 -0500

> attribute in the offer if the client behind the SBC acts as offerer.

If an SBC can operate by modifying the path, then why is there any 
discussion of c= and m= lines at all?

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 07 Apr 2009 09:55:10 -0500

Christer Holmberg wrote:
> relays.

Hi. My name is Adam Roach, and I'm glad to meet you for the first time. 
Have you met my associate Ben Campbell? I'm sure he'd be glad to meet 
you as well.

While I'm at it, I'd like to introduce you to a gentleman by the name of 
Ruud Klaver; you can check out his work at http://msrprelay.org/.

Or, if that's too academic for you, perhaps you'd be better off making 
the acquaintance of Adrian Georgescu, who actually sells realtime 
infrastructure equipment to service providers across Europe, after 
having worked at a significant number of service providers himself.

There. You now have the chance to go from "none" to "four" in a very 
short period of time.

/a

---

From: Bob Penfield <[email-masked]>
Date: Tue, 7 Apr 2009 11:11:08 -0400

If the SBC modifies the path, then it must parse and process all the MSRP messages in order to set it back the original one from the original SDP. The desire is to simply relay the MSRP in the same manner as RTP.

cheers,
(-:bob 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, April 07, 2009 10:46 AM
To: Christer Holmberg
Cc: Simpletons; Jon Peterson
Subject: Re: [Simple] MSRP-ACM compatibility

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 07 Apr 2009 14:12:32 -0500

Do you mean the SDP path lines?

   a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp

Or the MSRP path lines?

   From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp

I think we're talking about the SDP path lines in this thread, but your 
response sounds like you might be talking about the MSRP path lines.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 21:27:36 +0200

With "people" I was referring to customers. I guess I should have made
that more clear.

Also, Adrian already earlier informed us about his relay stuff, which
was one reason we decided to move forward with the relay depracation. I
am sure you saw that also.

Regards,

Christer

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, April 07, 2009 5:55 PM
To: Christer Holmberg
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Simple] MSRP-ACM compatibility

Christer Holmberg wrote:
> Some people I've talked to do wish to have interoperability with 
> legacy MSRP, some don't, but none of the ones I've talk to care about 
> MSRP relays.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 21:41:49 +0200

Hi,

Maybe it would work also by only chaning the a=path attribute. I haven't
thought about that very much, since this new
modify-the-path-in-order-to-work-with-relays issue is rather new.

One small issue with that solution is that it would also require B2BUAs
which are not communicating directly with endpoints (they only
communicate with other B2BUAs) to also modify the path attribute,
eventhough it would be enough for them to only modify the c/m line and
leave the path attribute unchanged. 

But, I don't think only modifying the path attribute would solve the TLS
issue.

Regards,

Christer

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, April 07, 2009 10:13 PM
To: Bob Penfield
Cc: Christer Holmberg; Simpletons; Jon Peterson
Subject: Re: [Simple] MSRP-ACM compatibility

Or the MSRP path lines?

/a

Bob Penfield wrote:
> If the SBC modifies the path, then it must parse and process all the
MSRP messages in order to set it back the original one from the original
SDP. The desire is to simply relay the MSRP in the same manner as RTP.
> Behalf Of Adam Roach

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 21:43:05 +0200

Which was one reason we decided to NOT move forward with the relay
deprecation, that is. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg
Sent: Tuesday, April 07, 2009 10:28 PM
To: Adam Roach
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Simple] MSRP-ACM compatibility

Regards,

Christer

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Tuesday, April 07, 2009 5:55 PM
To: Christer Holmberg
Cc: [email-masked]; [email-masked];

/a

---

From: Bob Penfield <[email-masked]>
Date: Tue, 7 Apr 2009 16:18:25 -0400

If the SDP path is changed, the MSRP Path will not match what the UA expects unless the MSRP message is also changed. For example,

A sends SDP with:
	a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp
It gets changed to 
	a=path:msrp://b2bua.example.com:7654/jshA7weztas;tcp
And is sent to B

When A sends an MSRP message to B, A sends:
      From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
But B expects:
	From-Path: msrp://b2bua.example.com:7654/jshA7weztas;tcp

If the MSRP message is not changed, then B should reject the message since it does not match what it is expecting.

If the m/c line was used for the connection, there is no need to change the path attribute in the SDP, and the intermediary does not need to modify MSRP messages.

cheers,
(-:bob

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, April 07, 2009 3:13 PM
To: Bob Penfield
Cc: Christer Holmberg; Simpletons; Jon Peterson
Subject: Re: [Simple] MSRP-ACM compatibility

Or the MSRP path lines?

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 22:34:35 +0200

Hi, 

>With comedia, the direction of the outbound MSRP connection is
negotiated between the parties. This works in the 
>following cases:

Regarding the new cases (3 and 5), the entities behind NATs (no relays)
still need to know whether they are behind NATs or not, in order to set
the approriate setup value? 

Regarding 3, do the TLS issues that Remi raised apply? Many stacks also
have issues with TCP simultaneous open.

MSRP works.

I was assuming that parties behind NATs would always use relays.

But, if comedia allows legacy MSRP clients to do NAT traversal without
relays, I guess they don't need relays anymore - at least not for NAT
traversal purpose.

Regards,

Christer

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 8 Apr 2009 09:49:18 +1000

> no SBC in the path, so that's what we need to solve.

Then we're done.

> that's where we see the main issues that still need to be sorted out.

Those TLS issues are there because we are making the assumption that
SBCs will modify the message. I'm suggesting that SBCs not get
considered.

Hisham

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 8 Apr 2009 09:51:43 +1000

2009/4/8 Adam Roach <[email-masked]>:
> Your suggestion confuses me. What, in *your* view, is the purpose of using
> c/m lines for carrying addressing information? The MSRP URL does a fine job
> of that.

I agree, but it is clear that some people in the wg want this method
of addressing.

Hisham

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Apr 2009 07:58:31 +0200

Hi, 

>>>(a=setup), figure out a way to interoperate with legacy 
address, 
>>>and that's it. Why are we talking about an intermediary that will
modify 
>>>messages and break security? We know those boxes exist in the world, 
>>>but we don't standarise their behaviour. Why do we want to do that 
>>>now? If an SBC vendor wants to work with MSRP-acm, then they can do 
>>>that in their own proprietary way. They will break security, but
that's new?
>>using c/m lines for carrying addressing information? The MSRP URL does

>>a fine job of that.
> 
>I agree, but it is clear that some people in the wg want this method of
addressing.

The main requirement is to allow routing of MSRP media via
intermeidates, without them having to modify the MSRP messages. If the
mechanism works by the intermdiates only modifying the a=path attribute
we can discuss that option also. However, if the session contains other
media than MSRP, the intermeidate would modify the c/m line anyway.

But, I'm not religious - I'm probably too unacademic for that... :)

Regards,

Christer

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 8 Apr 2009 16:31:58 +1000

Hi,

2009/4/7  <[email-masked]>:
> Hi,
>
> It's true we haven't standardized or even recommended how B2BUAs work. But hasn't that exactly led us to the problems we have with e2e security and e2e identifiers. I understand that having
> BEHAVE define recommendations on NATs does not guarantee that every NAT box will follow them. The same would go for anything the IETF says about B2BUAs. But in this MSRP case it would
> be still valuable to explain how the B2BUA will act wrt. MSRP-ACM, just for reference if nothing more.

Maybe someone can write a whitepaper for the sip or other forum. I
don't think we need to recommend how to break the protocol and its
security in an RFC.

Hisham

>
> But for me this is not the main thing about this draft. The main thing would be to get the draft forward, as we clearly have a need for it. There are some mobile operators who seem to have serious
> plans for MSRP deployment so User Agent developers have to solve the problem in some way in the next few months. Those customers won't care about TLS issues or backwards compatibility too
> much, but it is of course nice if we can solve them.
>
> Markus
>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Apr 2009 08:57:24 +0200

Hi,

If we would go for the solution where only the a=path attribute is
modified, then I guess we wouldn't need that part of the ACM draft in
the first place (the draft would only contain the comedia part). The
only thing we would need to do is to modify the session mapping
procedures in RFC 4975, as we are discussed.

Then we would basically only have one single IETF MSRP profile, which
would of course be great.

Would people be ok with that?

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 8. huhtikuuta 2009 8:59
> To: Hisham Khartabil; Adam Roach
> MSRP when one 
> intermeidates, without them having to modify the MSRP 
> messages. If the mechanism works by the intermdiates only 
> modifying the a=path attribute we can discuss that option 
> also. However, if the session contains other media than MSRP, 
> the intermeidate would modify the c/m line anyway.
>

---

From: Jon Peterson <[email-masked]>
Date: Wed, 08 Apr 2009 12:42:22 -0700

Since the TLS problems that have been identified in this thread arise
exclusively when the a=path attribute is modified and are completely
irrespective of the status of the c/m lines, I fail to see how removing the
bit about the c/m lines gets us any closer. If a design goal here is truly
to prevent the SBCs from having the modify MSRP signaling, Bob's mail seems
to suggest that even restricting the modifications to just the a=path
attribute doesn't help anyway.

For my part, I simply disagree with the underlying use case here. I do not
believe we need to solve the problem of figuring out how a helpful
intermediary can interpose itself in the middle of a TLS connection.
Although the discussion has been largely about allowing that intermediary to
proxy at the TCP layer (thus TLS could effectively be tunneled through it),
I am a bit dubious, given that the motivation in the draft is logging and
lawful interception, that tunneling TLS in this manner would really achieve
the stated goal.

To put it more concretely, if I attempt to contact an e-commerce website,
and my browser throws me a warning about an unexpected certificate, I am
rightly skeptical about divulging private information. This is exactly the
exception that would arise from modifying the a=path element in the proposed
manner, and a wise user in this instance has to assume the worst. In the web
model, when you need a helpful intermediary you can elect to invoke it, and
in so doing you will trigger no security exception. Our problem here, as
usual, is the interposition of intermediaries that surprise the user, and
which invoke themselves even when they are not necessary to realize the
user's intention. 

At the risk of proposing a way forward, I would suggest that the interested
parties define a new proposed intermediary function in the MSRP
architecture. Talk of SBCs and B2BUAs and modifying SDP, in my opinion,
merely salts wounds and guarantees that the discussion will go nowhere.
Hiding behind all of this is a latent proposal of a new MSRP intermediary
that instantiates a more lightweight set of features than a traditional
relay, but one that is still useful in certain architectures (and presumably
this function would be a role that SBCs might play). Before we worry about
how this entity gets involved in an MSRP session, we need a consensus that
it is sufficiently different from the MSRP relay function and worth
incorporating into the MSRP architecture.

If it proves prohibitive difficult to nail down what this proposed
intermediary function does, then it probably isn't a good target for
standardization. If we can define its behavior and arrive at a consensus
that adding it to the architecture would be a good thing, though, then I
think we can start figuring out how to introduce it into MSRP sessions in a
way that will not startle MSRP's security mechanisms. The discussion right
now, in my opinion, puts the cart way before the horse.

Jon Peterson
NeuStar, Inc.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 12:22:03 +0200

Hi,

>Since the TLS problems that have been identified in this thread arise
exclusively when the a=path attribute is modified 
>and are completely irrespective of the status of the c/m lines, I fail
to see how removing the bit about the c/m lines 
>gets us any closer. If a design goal here is truly to prevent the SBCs
from having the modify MSRP signaling, Bob's mail 
>seems to suggest that even restricting the modifications to just the
a=path attribute doesn't help anyway.
>
>For my part, I simply disagree with the underlying use case here. I do
not believe we need to solve the problem of 
>figuring out how a helpful intermediary can interpose itself in the
middle of a TLS connection.
>Although the discussion has been largely about allowing that
intermediary to proxy at the TCP layer (thus TLS could 
>effectively be tunneled through it), I am a bit dubious, given that the
motivation in the draft is logging and lawful 
>interception, that tunneling TLS in this manner would really achieve
the stated goal.
>
>To put it more concretely, if I attempt to contact an e-commerce
website, and my browser throws me a warning about an 
>unexpected certificate, I am rightly skeptical about divulging private
information. This is exactly the exception that 
>would arise from modifying the a=path element in the proposed manner,
and a wise user in this instance has to assume the 
>worst. In the web model, when you need a helpful intermediary you can
elect to invoke it, and in so doing you will 
>trigger no security exception. Our problem here, as usual, is the
interposition of intermediaries that surprise the user, 
>and which invoke themselves even when they are not necessary to realize
the user's intention. 
> 
>At the risk of proposing a way forward, I would suggest that the
interested parties define a new proposed intermediary 
>function in the MSRP architecture. Talk of SBCs and B2BUAs and
modifying SDP, in my opinion, merely salts wounds and 
>guarantees that the discussion will go nowhere.
>
>Hiding behind all of this is a latent proposal of a new MSRP
intermediary that instantiates a more lightweight set of 
>features than a traditional relay, but one that is still useful in
certain architectures (and presumably this function 
>would be a role that SBCs might play). Before we worry about how this
entity gets involved in an MSRP session, we need a 
>consensus that it is sufficiently different from the MSRP relay
function and worth incorporating into the MSRP 
>architecture.
intermediary function does, then it probably isn't a 
>good target for standardization. If we can define its behavior and
arrive at a consensus that adding it to the 
>architecture would be a good thing, though, then I think we can start
figuring out how to introduce it into MSRP sessions 
>in a way that will not startle MSRP's security mechanisms. The
discussion right now, in my opinion, puts the cart way 
>before the horse.

If we want to give the intermediate a specific name, instead of talking
about "some SBC doing something", that's fine. It would allow us to
describe how it behaves.

But, as far as the actual procedures of that entity are concerned, I
really don't see how we could do things in a different way than what we
have discussed.

The media routing path for MSRP - and other types of media - is
established using SDP, so the SBC modifies the SDP in order to insert
itself in the media path.

Regards,

Christer

>> intermeidates, without them having to modify the MSRP messages. If 
>> the mechanism works by the intermdiates only modifying the a=path 
>> attribute we can discuss that option also. However, if the session 
>> contains other media than MSRP, the intermeidate would modify the c/m

>> line anyway.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 16 Apr 2009 19:08:11 -0400

> Of Jon Peterson
> Sent: Monday, April 06, 2009 7:55 PM
> 
> 
> confidential. 

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.

> The mandate of TLS usage by MSRP relays is supposed to
> ensure

The proposal has not been to hand it over to someone you can't identify.  

> does that case look like?

The current draft-acm does not consider working with rfc4976 Relays.  One of the discussions on the list has been about how to go about doing that, with as few changes as possible to Relays.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 20 Apr 2009 10:09:44 +0200

Hi, 

>>I think what's missing in the discussion of the TLS component of 
>>MSRP-ACM is a glance back at 9.3 of RFC4976 - that is, a question of 
>>what we're hoping to prevent with TLS in this case. TLS serves a 
>>number of purposes in the MSRP relay architecture, but the salient one

>>here is to allow the client the opportunity to authenticate the next 
>>hop to which its traffic will not be confidential.
>
>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.

During the off-line discussions in SFO we also discussed the usage of
such fingerprint attribue for ACM.

Regards,

Christer

---

From: <[email-masked]>
Date: Tue, 21 Apr 2009 17:09:19 +0200

Hi,

Is it fair to say that MSRP-ACM draft currently has two main high level issues:
1. How it works with TLS
2. How it can interoperate when the other end is using an MSRP relay

Based on the discussion so far it seems that issue 1. can be technically solved, while with issue 2. there is no clean solution unless we also assume updating the baseline MSRP specs (and implementations). Correct?

I see value in going forward with the MSRP-ACM spec if we can:
* address the TLS concern.
* make the solution such that it allows the endpoints to establish the TCP connection without any relays or middleboxes as long as one end can receive TCP connections (e.g., it has a public address and is not firewalled).
* make it possible for a B2BUA to manipulate the SDP in *MSRP-agnostic manner* (i.e., using the mechanisms they use for any TCP/TLS connections using comedia) so that two endpoints who are both behind NAT can establish connectivity through the B2BUA.
* make it possible to use ICE and TURN-TCP as yet another NAT traversal option for MSRP. 
* address the backwards compatibility issue by introducing a small update/extension to current MSRP RFCs (as long as there are no major deployments yet, I consider this still a reasonable requirement).

Do we have a consensus over this set of requirements/targets?

Markus

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Apr 2009 08:41:54 +0200

Hi, 

>Based on the discussion so far it seems that issue 1. can be 
>technically solved,

Yes. For example, nobody has objected to the usage of the fingerprint
attribute.

>while with issue 2. there is no clean solution unless we also assume
updating the baseline MSRP specs (and implementations). Correct?

Correct.

>* make the solution such that it allows the endpoints to 
>establish the TCP connection without any relays or 
>middleboxes as long as one end can receive TCP connections 
>(e.g., it has a public address and is not firewalled).
>* make it possible for a B2BUA to manipulate the SDP in 
>*MSRP-agnostic manner* (i.e., using the mechanisms they use 
>for any TCP/TLS connections using comedia) so that two 
>endpoints who are both behind NAT can establish connectivity 
>through the B2BUA.
>* address the backwards compatibility issue by introducing a 
>small update/extension to current MSRP RFCs (as long as there 
>are no major deployments yet, I consider this still a 
>reasonable requirement).
> 

I think they seem reasonable.

Regarding manipulating the SDP in a "MSRP-agnostic manner":

For non-MSRP media, the B2BUA can modify the c/m line, and the setup
attribute, in order for both endpoints to establish TCP/TLS connections
towards the B2BUA.

But, again, for MSRP that is not enough, since the current endpoints
will compare the path attributes with the MSRP Path headers. Therefor a
change would be required to legacy MSRP.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 28 Apr 2009 15:49:02 -0500

(as individual)

> Yes. For example, nobody has objected to the usage of the fingerprint

I think it's premature to say that. We really haven't seen a  
substantially complete proposal on how the fingerprint mechanism would  
work and what changes it might require to RFC4975 and 4976. I don't  
see how we can have a useful discussion without one.

(I'm not saying the idea does not have merit, but we're still at the  
hand waving stage.)

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 29 Apr 2009 09:01:16 +1000

Hi,

1) We seem to have consensus that it must be possible for MSRP devices
using ACM to talk to devices using relays.

We don't have consensus on how far we are willing to update
RFC4975/4976 to accomplish this. We don't have consensus around any
currently proposed mechanism to accomplish the requirement.

2) We seem to have consensus that the parts of the draft about using
COMEDIA for negotiating the TCP connection direction is reasonable.

Does anyone object to the concensus?

Regards,
Hisham

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 29 Apr 2009 07:59:12 +0200

Hi, 

>substantially complete proposal on how the fingerprint 
>mechanism would work and what changes it might require to 
>RFC4975 and 4976. I don't see how we can have a useful 
>discussion without one.

Fair enough. I guess I should have said that nobody has objected to
CONSIDER the usage of the fingerprint mechanism :)

But, I agree it is good to have something on paper, so I will put some
text in the next version of the draft.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 29 Apr 2009 14:55:21 +0200

Hi, 

>1) We seem to have consensus that it must be possible for 
>MSRP devices using ACM to talk to devices using relays.
> 
>RFC4975/4976 to accomplish this. We don't have consensus 
>around any currently proposed mechanism to accomplish the requirement.

As far as I know, the only proposed mechanism is to change the session mapping procedure, to only take the user part into account.

But, that proposal is related to the TLS issue, so we we need to move that forward before we can make a decission.

Regards,

Christer

> appreciate

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 29 Apr 2009 20:11:17 +0200

Hi,

In fact, chapter 4.1.2 talks about TLS, and already says that RFC 4572 (which defines the fingerprint attribute) shall be used.

But, I guess we can add some additional text which describes what we have been discussing.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, April 29, 2009 3:55 PM
To: Hisham Khartabil; Simple WG
Subject: Re: [Simple] MSRP-ACM compatibility

Hi, 

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Apr 2009 13:35:58 -0500

(as individual)

On Apr 29, 2009, at 1:11 PM, Christer Holmberg wrote:

>
> Hi,
>
> In fact, chapter 4.1.2 talks about TLS, and already says that RFC  
> 4572 (which defines the fingerprint attribute) shall be used.
>

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.

There's also the fact that any fingerprint mechanism will require at  
least integrity protection of the fingerprint, which is showing itself  
to be controversial in the RFC4479 discussions in the other work groups.

I think that to have a useful discussion about this, we will need a  
proposal covering this end-to-end. That doesn't necessarily mean it  
all ends up living in the final ACM draft, but we at least need to  
understand if we have a workable architecture.

> Behalf Of Christer Holmberg
> As far as I know, the only proposed mechanism is to change the  
> session mapping procedure, to only take the user part into account.
>
> But, that proposal is related to the TLS issue, so we we need to  
> move that forward before we can make a decission.
>
> Regards,
>
> Christer
>
>
>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 30 Apr 2009 09:09:13 +0200

Hi Ben, 

>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  
>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?

Regards,

Christer

>least integrity protection of the fingerprint, which is 
>showing itself to be controversial in the RFC4479 discussions in the
other 
>work groups.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 Apr 2009 08:13:29 -0500

> 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.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 Apr 2009 08:16:19 -0500

(as individual)

On Apr 30, 2009, at 8:13 AM, Ben Campbell wrote:

> 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.

Also, don't get me wrong--I do not mean that to be a complete  
specification of the requirements, as much as evidence that if we were  
to introduce a fingerprints-for-relays solution, we have some  
engineering to do to make it useful. I don't think it's good enough to  
just call out the possibility of doing the work and calling it done.