Subject: [Simple] MSRP-ACM: C-line vs COMEDIA

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

(as an individual)

 From the list discussions and the meeting in San Francisco, we seem  
to have consensus around the COMEDIA provisions in the MSRP-ACM draft.  
All the controversy has been around the C-line vs path attribute  
changes.

Furthermore, if I understand correctly, the COMEDIA portions and the C- 
Line portions are effectively separate extensions, i.e. you can use  
either one without the other.

Does it make sense then to separate them into separate drafts? If we  
did so, we could go ahead and progress the COMEDIA part instead of  
blocking it on the discussions concerning the C-line part.

---

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

Ben Campbell wrote:
> (as an individual)
>
> From the list discussions and the meeting in San Francisco, we seem to 
> have consensus around the COMEDIA provisions in the MSRP-ACM draft. 
> All the controversy has been around the C-line vs path attribute changes.
>
> Furthermore, if I understand correctly, the COMEDIA portions and the 
> C-Line portions are effectively separate extensions, i.e. you can use 

I think it very much does make sense to separate these two mechanisms.

The comedia changes -- which require no updates to 4975, if my 
understanding is correct -- should be quick, easy, and largely 
uncontroversial. They're also 100% backwards compatible with everything 
defined so far. We don't need to worry about Hisham's questions 
regarding backwards compatibility, since the only impacts are at the 
SIP/SDP level (where proper negotiation can take place), with zero 
impact on the MSRP behavior.

On the other hand, the c= line changes are going to require a bit more 
consensus building (around backwards compatibility, mostly); and, 
depending on the outcome of those conversations, a bit more engineering 
(probably including normative updates to MSRP). I don't see why we need 
to wait on the outcome of this work before the comedia usage can be 
finalized and published.

/a

---

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

Hi,

You can use the extensions separately, but if you support the c/m-line
part I see no reason why you shouldn't also support COMEDIA. It is
helpful e.g. if both clients are behind NATs, and SBC based NAT
traversal mechanisms are used.

The COMEDIA part can be used with legacy MSRP.

I think we should keep the extensions in a single draft for now, and try
to close the interoperability issue asap. Otherwise we will just cause
delay and confusion.

So far nobody has objected to the proposed solution. We are aware of the
issues (TLS etc), and nobody has proposed an alternative solution, so I
really think we should aim for it.

I have noticed increased interest (I get questions about the status
almost every day) in MSRP due to ACM, so I really think people who don't
like the proposed interoperability solution, and want something else,
should say so NOW. We have discussed this for a while already, so
everyone should have had time to think about it.

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, April 02, 2009 8:47 PM
To: Simple WG
Cc: Christer Holmberg
Subject: MSRP-ACM: C-line vs COMEDIA

(as an individual)

Does it make sense then to separate them into separate drafts? If we did
so, we could go ahead and progress the COMEDIA part instead of blocking
it on the discussions concerning the C-line part.

---

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

I really hope we will get an outcome before COMEDIA is finsihed and
published...

We have discussed this on the list before the meeting, at the meeting,
and now after the meeting. We have ONE proposed interoperability
solution. We have discussed issues associated with it. 

Let's go for it.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Thursday, April 02, 2009 9:13 PM
To: Ben Campbell
Cc: Simple WG
Subject: Re: [Simple] MSRP-ACM: C-line vs COMEDIA

changes.

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

---

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

(as an individual)

> everyone should have had time to think about it.

In case I have not been clear on this point: I object to the currently  
proposed solution, unless we also come up with a way to fix or avoid  
the TLS name matching issue. Otherwise we lose any hope of using TLS  
to authenticate MSRP server devices such as msrp relays, conference  
switches, off-line message storage servers, etc.

> C-
> did

---

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

> I really hope we will get an outcome before COMEDIA is finsihed and

I'm confused. Are you claiming you think you can get the whole draft -- 
with the uncontroversial comedia part and the controversial c= part -- 
published faster than we could get the uncontroversial part published?

> solution. We have discussed issues associated with it. 

The measure of discussion does not determine consensus. We do not (or, 
at least, are not supposed to) publish documents as RFCs simply because 
they have aged sufficiently. We publish them when they represent the 
consensus of the working group. I don't think what we have now does that.

I think the largest part of it -- the comedia part -- already has 
consensus. It's not clear that the part designed to allow intermediaries 
to change media paths without informed client consent does. And I'm 
fairly sure that we haven't shaken the rough edges out of this second 
part anyway (cf. the TLS certificate issues).

/a

---

From: Ben Campbell <[email-masked]>
Date: Thu, 2 Apr 2009 15:46:32 -0500

On Apr 2, 2009, at 3:26 PM, Ben Campbell wrote:

> In case I have not been clear on this point: I object to the  
> currently proposed solution, unless we also come up with a way to  
> fix or avoid the TLS name matching issue. Otherwise we lose any hope  
> of using TLS to authenticate MSRP server devices such as msrp  
> relays, conference switches, off-line message storage servers, etc

Actually, let me elaborate on that a bit more. The change to match  
sessions by only the session-ID part of the MSRP URI does not break  
TLS per se. But the whole _point_ of that proposal was to allow an  
endpoint using a relay to talk with an endpoint using an SBC. Since  
the current proposal doesn't offer a way to do that that does not  
prevent the use of TLS at the relay, I do not believe that it solves  
the problem.

---

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

Hi, 

published...
>I'm confused. Are you claiming you think you can get the whole draft --
with the uncontroversial comedia part and the 
>controversial c= part -- published faster than we could get the
uncontroversial part published?

I don't claim so, but I hope so :)

>The measure of discussion does not determine consensus. We do not (or,
at least, are not supposed to) publish documents 
>as RFCs simply because they have aged sufficiently. We publish them
when they represent the consensus of the working 
>group. 

I agree. But, nobody has objected to what we have proposed so far. Yes,
we have some work with the TLS stuff, so let's focus on trying to solve
that. Then, if we figure out that we don't get anywhere, we can start to
discuss splitting of documents.

>I don't think what we have now does that.

That is why I ask people to speak up, and give opinions and proposals on
how to solve things.

>I think the largest part of it -- the comedia part -- already has
consensus.

Yes.

>It's not clear that the part designed to allow intermediaries to change
media paths without informed client consent does. 
>And I'm fairly sure that we haven't shaken the rough edges out of this
second part anyway (cf. the TLS certificate 
>issues).

Nobody has objected to the principle of c/m, but there are some TLS
issues we need to deal with. However, as was said at the meeting, some
of those are not MSRP specific.

Regards,

Christer

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 02 Apr 2009 17:36:44 -0500

Christer Holmberg wrote:
> Nobody has objected to the principle of c/m

That's not true -- Ben has been objecting, repeatedly, to this portion 
of the document for some time now, and I objected at the microphone in 
Dublin. It's currently optional in the draft, which makes it imminently 
separable from the comedia portion.

This is the only portion of the document that requires normative changes 
to MSRP.

This is the portion of the document that raises very real security 
issues about TLS authentication.

This is also the portion of the document that isn't particularly well 
motivated. It cites four purposes:

   1. performance monitoring
   2. lawful intercept
   3. address domain bridging
   4. interconnect SLA policy enforcement

It's hard to see how #1 relates to MSRP -- it's not realtime media in 
the conventional sense, so monitoring things like jitter and latency are 
basically meaningless. The only metric that really makes any sense is 
throughput, and that's more sensibly measured at routers (especially 
since you can get cross-service metrics there, instead of having to 
intercept and process every service being used by the susbcriber).

Number 2 is explicitly out of scope for making IETF protocol decisions 
-- RFC 1984 is still in effect until the IAB and IESG issue an 
obsoleting policy document.

Number 3 is best served via client-controlled mechanisms, such as MSRP 
relays, TURN relays, SOCKS proxies, and ICE techniques.

Number 4, like number 1, is best suited by a general cross-domain policy 
enforcement -- otherwise, you're upgrading the core of the network for 
every new deployed client service. That simply doesn't scale.

The document also points out that, *if* someone is hellbent on doing 
things with the architecture you describe, then there is a perfectly 
valid solution for performing these activities (make the B2BUA in 
question have at least a tiny bit of understanding about MSRP) -- so the 
c/m stuff can, at best, be considered an optimization.

Top this off with the TLS issues (which you apparently understand so 
poorly that you need Ben to explain it on your behalf), and I think you 
have plenty of controversy around the c/m changes.

/a

---

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

I'm confused.  In an earlier email you said "I believe this is a strong requirement for the C-Line part of the ACM draft to move forward." And below you're talking about the "COMEDIA provisions".  Which parts of COMEDIA are you referring to - the setup and connection attributes, or using the c-line for addressing?

-hadriel

> Of Ben Campbell
> Sent: Thursday, April 02, 2009 3:47 PM
> To: Simple WG
> Subject: [Simple] MSRP-ACM: C-line vs COMEDIA
> 
> (as an individual)
>

---

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

> issues about TLS authentication.

The issue it raises is not really one that didn't exist before, though slightly different.  In the 4976-relay approach, you already had to trust the MSRP Relays to not lie to you, and also to do cert matching correctly.  It was not end-to-end UA-to-UA TLS to begin with.  What we're proposing to do for ACM is to use the Comedia-TLS model, using a fingerprint attribute in SDP.  You'll have to trust the SIP layer not to lie, just as you would have had to trust the MSRP Relay not to lie.  The only difference is the UA was knowingly using a Relay. (which is important, but not an actual guarantee)

Interestingly having an IP/TCP-layer relay (e.g., an SBC) actually provides an opportunity to do end-end TLS.  In fact it's probably the most common thing to do in comedia-tls usage today for SBC's - let TLS go end-to-end.  But SBC's also terminate it sometimes, when they're offloading TLS work from a server, though they then have the cert with the CN/SAN of the server.

But anyway that's a separate thread topic, so I'll split it out in a separate email.

> motivated. It cites four purposes:

The main motivation is undoubtedly supporting currently deployed networks.  I would honestly think that's pretty compelling, even if I didn't build an SBC. 

-hadriel

---

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

> The main motivation is undoubtedly supporting currently deployed networks.  I would honestly think that's pretty compelling, even if I didn't build an SBC. 

Are you claiming that anything more than a trivial minority of currently 
deployed SBCs in live networks understand comedia and support TLS/TCP 
transit for media streams?

It seems highly unlikely, since the only obvious use cases (given the 
state of SIP deployment in large networks) inherently involve MSRP -- 
and if they support MSRP, then they support MSRP. What am I missing? 
What would have driven comedia and TLS/TCP support into _currently_ 
_deployed_ SBCs?

/a

---

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

> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, April 02, 2009 9:55 PM
> To: Hadriel Kaplan
> 

I can't speak for them all, but every one of ours does or can.  It may be administratively disabled on some or a majority of them for all I know, but someone made us implement support for it 2+ years ago which means by now most if not all systems have been upgraded to at least be able to do it; and it can be turned on with one config command, for free.  And we're not the only game in town so I assume others have done it by now too.

> What would have driven comedia and TLS/TCP support into _currently_

The first application we saw using it was BFCP, but someone's doing RFC 4571 for RTP too (or at least it's been in RFI/RFP's, who knows if it's in use).

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 3 Apr 2009 08:13:38 +0200

Hi, 

>That's not true -- Ben has been objecting, repeatedly, to this portion
of the document for some time now,

I guess Ben can speak for himself, but in my undrstanding Ben has not
objected to the principle, but wants to deal with the TLS impacts of it.

>and I objected at the microphone in Dublin. It's currently optional in
the draft, which makes it imminently separable 
>from the comedia portion.

True, but that doesn't mean it can't be in the same draft. And, as
Hadriel said, most people will probably use both comedia and c/m anyway.

>This is the only portion of the document that requires normative
changes to MSRP.
>It's hard to see how #1 relates to MSRP -- it's not realtime media in
the conventional sense, so monitoring things like 
>jitter and latency are basically meaningless. The only metric that
really makes any sense is throughput, and that's more 
>sensibly measured at routers (especially since you can get
cross-service metrics there, instead of having to intercept 
>and process every service being used by the susbcriber).
>
>->- RFC 1984 is still in effect until the IAB and IESG issue an
>Number 3 is best served via client-controlled mechanisms, such as MSRP
relays, TURN relays, SOCKS proxies, and ICE 
>techniques.
>
>Number 4, like number 1, is best suited by a general cross-domain
policy enforcement -- otherwise, you're upgrading the 
>core of the network for every new deployed client service. That simply
doesn't scale.
>The document also points out that, *if* someone is hellbent on doing
things with the architecture you describe, then 
>there is a perfectly valid solution for performing these activities
(make the B2BUA in question have at least a tiny bit 
>of understanding about MSRP) -- so the c/m stuff can, at best, be
considered an optimization.

The motivation is to make MSRP work with SBCs. In the real world that is
a very good motivation.

>Top this off with the TLS issues (which you apparently understand so
poorly that you need Ben to explain it on your 
>behalf), and I think you have plenty of controversy around the c/m
changes.

I do have an understanding of the TLS issue. But, we had off-line
discussions about it in SFO, and I thought we had agreed on some
assumptions and ways forward. Those are the ones I asked Ben to explain.

Regards,

Christer

---

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

Hi, 

>and I think you have plenty of controversy around the c/m changes.

I am not sure what you mean by plenty of convroversy.

As far as I know, the issue is regarding interoperability between ACM
and MSRP relay, and how to deal with TLS in that case, but not about c/m
as such.

But, let's focus on how/if we can solve the TLS issue :)

Regards,

Christer

---

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

> and MSRP relay, and how to deal with TLS in that case, but not about  

In my opinion, interoperability is a central (and open) issue for ACM  
in general. I don't think you can separate the two; controversy over  
ACM interoperability is still controversy over ACM.

---

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

On Apr 2, 2009, at 8:05 PM, Hadriel Kaplan wrote:

>
> I'm confused.  In an earlier email you said "I believe this is a  
> strong requirement for the C-Line part of the ACM draft to move  
> forward." And below you're talking about the "COMEDIA provisions".   
> Which parts of COMEDIA are you referring to - the setup and  
> connection attributes, or using the c-line for addressing?

By "COMEDIA" part, I was referring to the ACM draft section 4.1, which  
describes the use of the COMEDIA setup attribute in SDP to determine  
which peer is is the active party for the TCP connection.

By "C-Line" part, I was referring to the ACM draft section 4.2,  
entitled "Transport connection addressing", which describes using the  
SDP C-line to determine the destination address for the TCP connection.