Subject: [Simple] msrp-acm: Using MSRP with SBCs/ALGs

From: Ben Campbell <[email-masked]>
Date: Fri, 20 Feb 2009 14:36:14 -0600

Hi,

I've been working through draft-ietf-simple-msrp-acm-00, and have a  
few new thoughts about it. I am breaking these up into separate  
emails, to try to avoid discussion thread confusion.

One of the motivations for the C-Line connection model in this draft  
is the use of SBCs/ALGs. I can accept that motivation, but I am  
troubled by the inability of an endpoint using this model to  
interoperate with a peer that needs to use an MSRP relay. The ability  
to fail back to standard MSRP behavior is not very satisfying, since I  
doubt network routing policy will _allow_ an endpoint to fall back to  
standard behavior when SBCs are involved. In my opinion, we should  
explore approaches where the SBC modifies the MSRP "path" attribute in  
the SDP, which I think can be made to work even when the peer uses one  
or more MSRP relays. I realize that this creates new work for SBCs-- 
but that might be worth it for a more interoperable solution.

This would, however, force MSRP endpoints to change how they match  
inbound messages to a session. For example, it might look just at the  
session-id part of the MSRP URI, and ignore changes to the host/domain  
part. We would need to think about the security properties of such a  
change.

Thanks!

Ben.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 22 Feb 2009 19:43:03 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ben Campbell
> Sent: Friday, February 20, 2009 3:36 PM
>
> is the use of SBCs/ALGs.

The real benefit of that is the SBCs/ALGs don't need to be upgraded at all.  For example, I can't speak for the other vendors, but we've tested the msrp-acm draft going back to some fairly old code of ours and it works, with a one line config change if any.  I am very sympathetic with Adam's concerns that it's the tail wagging the dog, but if we're going to do a change anyway, it might as well follow normal SDP.

> I can accept that motivation, but I am
> standard behavior when SBCs are involved.

I agree.  Odds are that if you're talking through an SBC-type provider, they won't support the "legacy" behavior.

I do wonder how much "legacy" MSRP really exists, though.  I know we all focus on different customers and users, but I'm really having a hard time believing we need to worry much about RFC 4976.  My company's test group had a hard time even finding any rfc4975 endpoints to test against, and we only found one rfc4976 Relay.  We know the endpoint support is coming, which is why we'd like to make this change now, asap.

> In my opinion, we should

I'm ok with that - but how could it work?  The real issue has always been the matching of MSRP messages to the session, where the binding of the path IP:port to the IP/TCP socket info was what killed it.  No?  I admit I don't fully grok the rfc4976 Relay approach, but I thought it was fundamentally incompatible with breaking that binding.

-hadriel

---

From: Ben Campbell <[email-masked]>
Date: Sun, 22 Feb 2009 20:13:40 -0600

On Feb 22, 2009, at 6:43 PM, Hadriel Kaplan wrote:

> The real benefit of that is the SBCs/ALGs don't need to be upgraded  
> at all.  For example, I can't speak for the other vendors, but we've  
> tested the msrp-acm draft going back to some fairly old code of ours  
> and it works, with a one line config change if any.  I am very  
> sympathetic with Adam's concerns that it's the tail wagging the dog,  
> but if we're going to do a change anyway, it might as well follow  
> normal SDP.

I assume your old code already handles TCP based media?

I certainly understand the desire to make this work with existing  
code. It's a question of whether making this interop with 4976 relays  
is worth the change (assuming my proposal actually works--it still  
needs more thought.) . At least it would be a smaller change than,  
say, implementing an MSRP relay in an SBC.

> I agree.  Odds are that if you're talking through an SBC-type  
> provider, they won't support the "legacy" behavior.
>
> I do wonder how much "legacy" MSRP really exists, though.  I know we  
> all focus on different customers and users, but I'm really having a  
> hard time believing we need to worry much about RFC 4976.  My  
> company's test group had a hard time even finding any rfc4975  
> endpoints to test against, and we only found one rfc4976 Relay.  We  
> know the endpoint support is coming, which is why we'd like to make  
> this change now, asap.

I seem to recall Robert mentioning some implementations at the last  
SIPit. I don't recall the details. Robert?
> I'm ok with that - but how could it work?  The real issue has always  
> been the matching of MSRP messages to the session, where the binding  
> of the path IP:port to the IP/TCP socket info was what killed it.   
> No?  I admit I don't fully grok the rfc4976 Relay approach, but I  
> thought it was fundamentally incompatible with breaking that binding.

You are correct, RFC 4975 currently says you match the entire MSRP URI  
to the session, which includes the address and port, or conceivably a  
host name and port. But if we updated that to only match on the  
Session ID (i.e. that part of the URL right of the "/", it _might_ be  
good enough. This would allow the session match to work even if the  
address:port gets changed in flight.

  We already say the session ID should be hard to guess. It seems to  
me that the security properties of a hard-to-guess session id is not  
very different than the same id concatenated with a fairly-easy-to- 
guess port and a pretty-much-public-knowledge address. But I would  
want input from our security experts to be sure.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Feb 2009 12:37:31 -0500

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Sunday, February 22, 2009 9:14 PM
>

Yup.  Many others' do as well.

> address:port gets changed in flight.

So now we're talking about changing the endpoints and the Relays, no?  So that doesn't jive with the idea of working with legacy RFC4975/6, does it? (or am I missing something?)

-hadriel

---

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Feb 2009 12:14:13 -0600

On Feb 23, 2009, at 11:37 AM, Hadriel Kaplan wrote:

> So now we're talking about changing the endpoints and the Relays,  
> no?  So that doesn't jive with the idea of working with legacy  
> RFC4975/6, does it? (or am I missing something?)

It would not work with RFC4975/6 devices without a change. But then  
again, neither would the msrp-acm draft.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Feb 2009 13:45:07 +0100

Hi,

Maybe we should just live with the fact that it doesn´t work with relays, and a receiving entity which wants to use relays should reject the msrp-acm offer. As Hadriel said, an SBC operator most likely requires all the traffic to pass the SBC, so legacy MSRP usage would not work anyway.

>From my experience, people asking for MSRP wants the acm solution, because they want it to work with their SBCs, in order to anchor the MSRP "media" (for whatever policy etc reasons). I haven't heard about anyone asking for MSRP relays.

And, since the number of deployed MSRP relays seems to be very small, it probably wouldn't cause any major real-life problems.

So, if we get this done, I think people will switch to msrp-acm.

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, February 23, 2009 8:14 PM
To: Hadriel Kaplan
Cc: Simple WG; Christer Holmberg
Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs

On Feb 23, 2009, at 11:37 AM, Hadriel Kaplan wrote:

>> You are correct, RFC 4975 currently says you match the entire MSRP 
>> URI to the session, which includes the address and port, or 
>> conceivably a host name and port. But if we updated that to only 
>> match on the Session ID (i.e. that part of the URL right of the "/", 
>> it _might_ be good enough. This would allow the session match to work 
>> even if the address:port gets changed in flight.
>
> So now we're talking about changing the endpoints and the Relays, no?  
> So that doesn't jive with the idea of working with legacy RFC4975/6, 
> does it? (or am I missing something?)

It would not work with RFC4975/6 devices without a change. But then again, neither would the msrp-acm draft.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 24 Feb 2009 08:34:31 -0600

On Feb 24, 2009, at 6:45 AM, Christer Holmberg wrote:

>
> Hi,
>
> Maybe we should just live with the fact that it doesn´t work with  
> relays, and a receiving entity which wants to use relays should  
> reject the msrp-acm offer. As Hadriel said, an SBC operator most  
> likely requires all the traffic to pass the SBC, so legacy MSRP  
> usage would not work anyway.

I'm not sure I agree. It seems like that takes us from "probably won't  
interoperate" to "definitely won't interoperate."

>
>
> From my experience, people asking for MSRP wants the acm solution,  
> because they want it to work with their SBCs, in order to anchor the  
> MSRP "media" (for whatever policy etc reasons). I haven't heard  
> about anyone asking for MSRP relays.
>
> And, since the number of deployed MSRP relays seems to be very  
> small, it probably wouldn't cause any major real-life problems.
>

This quickly returns to the "if we go down this path, we have  
effectively deprecated MSRP relays." situation.  If the community  
wants to do that, so be it. But I really don't want to split the  
standard so that we have two implementation choices that can't  
interoperate.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Feb 2009 22:58:25 +0100

Hi, 

>>relays, and a receiving entity which wants to use relays should reject 
>>the msrp-acm offer. As Hadriel said, an SBC operator most likely 
>>requires all the traffic to pass the SBC, so legacy MSRP usage would 
>>not work anyway.
>
>I'm not sure I agree. It seems like that takes us from "probably won't interoperate" to "definitely won't interoperate."
>

The question is still whether that will be a real-life problem. How often will it happen? Are the potential benefits bigger?

But, of course, if it can work with nodes behind relays that is of course not a bad thing.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Feb 2009 17:11:44 -0500

> Sent: Tuesday, February 24, 2009 9:35 AM
>

I don't think that's what we're saying.  We have a session-creating rendezvous protocol (SIP) with address advertisement and capability negotiation (SDP) which allows us to offer different media-layer connection schemes and attributes.  So we're saying let SIP and SDP do their job - let them advertise what each side supports.  That's what they do for codecs, srtp, audio/video, etc.  If the two sides each support incompatible choices, then sure it won't work - just like it won't if we don't have common media capabilities.

-hadriel