Subject: [MMUSIC] RE: Draft -04 of Comedia over TLS submitted. Ready for WGLC?

From: lazzaro <[email-masked]>
Date: Thu, 7 Jul 2005 09:39:54 -0700

On Jul 7, 2005, at 9:06 AM, Jonathan Lennox wrote:
> I've just submitted draft -04 of draft-ietf-mmusic-comedia-tls,
> "Connection-Oriented Media Transport over the Transport Layer  
> Security (TLS)
> Protocol in the Session Description Protocol (SDP)".

[...]

> I believe the technical work on this is complete, and it's ready  
> for working
> group last call.

 From this I-D:

    This document does not define any mechanism for securely  
transporting
    RTP and RTCP packets over a connection-oriented channel.  There was
    no consensus in the working group as to whether it would be  
better to
    send Secure RTP packets [22] over a connection-oriented transport
    [23], or whether it would be better to send standard unsecured RTP
    packets over TLS using the mechanisms described in this document.
    The group consensus was to wait until a use-case requiring secure
    connection-oriented RTP was presented.

---

I agree this accurately represents the discussion that went on in the
working groups.

But, I thought it would be good to excerpt it and post it, to remind
everyone that this is the decision that was made.  Given the lead time
of the IETF process, it's a decision we'll all be living with for the  
next
few years (at least).  If there's a group change of heart on the issue
that is about to happen, having it happen now saves the community
one cycle through the standards process.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 7 Jul 2005 14:47:37 -0400

On Thursday, July 7 2005, "lazzaro" wrote to "[email-masked]" saying:

>  From this I-D:
> 
>     This document does not define any mechanism for securely transporting
>     no consensus in the working group as to whether it would be better to
> of the IETF process, it's a decision we'll all be living with for the next

I agree it's worth considering.

I also noticed that the recent AVT recharter contained the bullet point:

  - to provide a framing mechanism for RTP over TCP and TLS

Was inserting TLS just someone's "this seems like a good idea" as part of
describing draft-ietf-avt-rtp-framing-contrans for the charter, or did was
this decision actually made at some point?

My own implementation of TCP/TLS (developed alongside the draft) actually
implements TCP/TLS/RTP/AVP, so I'd certainly be inclined to lean that way.

-- 
Jonathan Lennox
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 08 Jul 2005 09:12:09 +0200

Hi Jonathan,

Can you please remind where and when the decision was taken to not 
define TCP/TLS/RTP/AVP? All I find is some loose discussion without 
conclusion about the topic, but nothing I can interpret as an WG 
consensus on this.

I am in favor of defining both TCP/TLS/RTP/AVP and TCP/TLS/RTP/AVPF. I 
would also consider if TCP/TLS/RTP/SAVP is a good idea or not. I would 
consider TCP/TLS/RTP/SAVP a possibility in cases that requires a secure 
TCP/TLS connection, for example due to end point authentication, which 
however is a gateway to an SRTP session. If that is relevant or not is 
another matter.

I also agree with Lazzaro that with the current IETF lead time the only 
reasonable way of providing for future use cases the market wants to 
select it to have it ready. I don't want to be the part blocking actual 
deployment of security. Thus I think we should consider both 
TCP/RTP/SAVP and TCP/TLS/RTP/AVP.

As I see it TCP/RTP/SAVP and TCP/TLS/RTP/AVP have somewhat different 
security properties. TLS provides a secured transport channel with 
possibility to end-point authentication. The SRTP based solution 
provides instead group security and can be done without a trusted 
gateway. So they definitely are applicable in different use cases.

> this decision actually made at some point?

Again doing some searching in the archives I find that this formulation 
was part of the proposed charter update I sent out 2003-09-02. It is 
probably something we who wrote it felt was an good idea and reflected 
our understanding of what was going to happen.

I would interpret such that we are allowed and expected to do what the 
charter says. However if we do have motivation why we wouldn't, we 
probably can get away without doing the work.

My conclusion is that we need to discuss this topic again.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 8 Jul 2005 10:06:04 -0400

> conclusion about the topic, but nothing I can interpret as an WG 

It was at the MMusic meeting in San Diego (August 2004), following my
initial presentation of comedia-tls.  Here's the relevant paragraph from the
minutes:

    An open issue is that this defines only TCP/TLS, not TCP/TLS/RTP/AVP.
    Similarly, nothing defines TCP/RTP/SAVP. What should be the preferred
    way of doing secure connection-oriented RTP? Steve Casner suggested
    that it might be appropriate to wait until there is a use case for
    SRTP over connection oriented media, rather than trying to specify it
    now.

As I recall, Steve's comment got a rough nodding of heads.  So I wouldn't
say that a decision was explicitly taken not to define this, so much as that
no decision was taken *to* define it.

> I am in favor of defining both TCP/TLS/RTP/AVP and TCP/TLS/RTP/AVPF.

TCP/TLS/RTP/AVP, yes.  I'm not sure what the use-case is for
TCP/TLS/RTP/AVPF -- I thought most of the motivation for AVPF was for
bandwidth adaptation and improved delivery reliablity, both of which seem to
be redundant for something transmitted over TCP.

> I would also consider if TCP/TLS/RTP/SAVP is a good idea or not. I would

I'm dubious about sending Secure RTP over TLS -- I think it would need to be
pretty strongly motivated with real use-cases.

For both these cases, their motivations are significantly stronger if you're
envisioning implementing a UDP<->TCP<->UDP tunnel scenario.  Is that what
you're thinking of?

> TCP/RTP/SAVP and TCP/TLS/RTP/AVP.

Fair enough.

> gateway. So they definitely are applicable in different use cases.

I'm not sure what you mean by a "trusted gateway", and I'm not sure how
useful group security is for a point-to-point connection-oriented protocol,
again unless you're envisioning tunneling.

(Would it be worthwhile to restrict this discussion just to the avt list?)

-- 
Jonathan Lennox
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Sun, 10 Jul 2005 11:09:52 +0100

[avt list bcc'd -- discussion on mmusic]

On 8 Jul 2005, at 15:06, Jonathan Lennox wrote:
> On Friday, July 8 2005, "Magnus Westerlund" wrote:

As an additional factor in the discussion, I note that the comedia- 
tls draft is normatively referenced by the MRCPv2 spec, which is  
nearing completion. I don't want to prevent useful additions to the  
comedia-tls draft, but we shouldn't add features with only  
theoretical usefulness if doing so will significantly delay a draft  
with present needs.

Colin

---

From: Jonathan Lennox <[email-masked]>
Date: Sun, 10 Jul 2005 10:08:40 -0400

> [avt list bcc'd -- discussion on mmusic]

(And again, since I'm discussing a draft that would presumably be handled in
avt.)

> theoretical usefulness if doing so will significantly delay a draft  

Oh, yes, definitely -- a definition of 'TCP/TLS/RTP/AVP' should be in a
separate draft from 'TCP/TLS', just as 'TCP/RTP/AVP' is separate from
'TCP'.

I imagine that AVT would probably be a better home for this latter draft,
since a) it's extending draft-ietf-avt-rtp-framing-contrans, and b) it's in
the avt charter.

-- 
Jonathan Lennox
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Jul 2005 11:45:17 +0200

> be redundant for something transmitted over TCP.

There are definitely motivation why also AVPF should be included. First 
of all AVPF provides a generic mechanism that can be used for sending 
feedback messages. In certain cases these feedback messages have nothing 
to do with either delivery reliability or bandwidth adaptation. This 
will definitely become evident when the new draft 
(draft-wenger-avt-avpf-ccm-00.txt) on codec commands becomes available. 
This draft contains feedback that are related to usage of video mixers 
(MCUs) as an example.

The other motivation are these use cases that contains mixers or media 
focus performing replication to form a multiparty conference. There 
several independent unicast connection are connected. In these scenario 
it is not unlikely that some could use TCP/TLS while others uses UDP. 
Thus the need to have the same profile but with different transports.

> pretty strongly motivated with real use-cases.

Again I think the motivation are gateways or other type of bridging 
between different transport formats while still there is a need to use 
the same profile in both transport domains.

However it might be that for this use case TCP/RTP/SAVP is more useful. 
Including TLS would only provide end-point authentication.

> envisioning implementing a UDP<->TCP<->UDP tunnel scenario.  Is that what

Yes, but primarily the case of mixer translators between a UDP domain 
and some users connected using TCP.

> again unless you're envisioning tunneling.

IF you are having a UDP multicast session and you like to connect but 
can only use TCP then you need a translator. That translator will be 
required to be trusted if it is going to perform the following operation:
IP/UDP/RTP/SAVP -> IP/TCP/TLS/AVP
In addition to be trusted to receive, decrypt and handle the media it 
must also be trusted to correctly authenticate the end-point connecting 
over TLS.

If you instead performed a TCP encapsulation operation the translator 
could be untrusted.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Jul 2005 13:54:27 +0200

Hi,

Yes, we shouldn't create undue delays for other specifications. However 
we shouldn't create unnecissarily many drafts either. However it might 
be best if someone could write a new draft on registering the RTP 
related ones.

TCP/RTP/AVPF
TCP/RTP/SAVP
TCP/RTP/SAVPF
TCP/TLS/RTP/AVP
TCP/TLS/RTP/AVPF

I think all of these should be useful. I will not press my case when it 
comes to TCP/TLS/RTP/SAVP(F).

cheers

Magnus

-- 

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Jul 2005 10:55:31 +0100

Hi,

On 11 Jul 2005, at 12:54, Magnus Westerlund wrote:
> Yes, we shouldn't create undue delays for other specifications.  
> However we shouldn't create unnecissarily many drafts either.  
> However it might be best if someone could write a new draft on  
> registering the RTP related ones.
>
> TCP/RTP/AVPF
> TCP/RTP/SAVP
> TCP/RTP/SAVPF
> TCP/TLS/RTP/AVP
> TCP/TLS/RTP/AVPF
>
> I think all of these should be useful. I will not press my case  
> when it comes to TCP/TLS/RTP/SAVP(F).

I agree that it might be useful to define these formats in a new  
draft. Are you volunteering to do the work?

In the meantime, I don't see any need to delay the current comedia- 
tls draft.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Jul 2005 12:58:58 +0200

> draft. Are you volunteering to do the work?
No, I am not. At least not now.

Cheers

Magnus Westerlund

---

From: David R Oran <[email-masked]>
Date: Mon, 11 Jul 2005 10:29:05 -0400

> when it comes to TCP/TLS/RTP/SAVP(F).
Emphatic agreement. We can sort out the edge cases like TCP/TLS/RTP/ 
SAVP(F) later.

> cheers
>
> Magnus
>
>
> Jonathan Lennox wrote:
>
>> On Sunday, July 10 2005, "Colin Perkins" wrote to "Jonathan  
>> Lennox, Magnus Westerlund, IETF MMUSIC working group, lazzaro  
>> Lazzaro" saying:
>>
>>> As an additional factor in the discussion, I note that the  
>>> comedia- tls draft is normatively referenced by the MRCPv2 spec,  
>>> which is  nearing completion. I don't want to prevent useful  
>>> additions to the  comedia-tls draft, but we shouldn't add  
>>> features with only  theoretical usefulness if doing so will  
>>> significantly delay a draft  with present needs.
>>>
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

---

From: Mark Baugher <[email-masked]>
Date: Tue, 12 Jul 2005 07:32:52 -0700

I know of RTP applications being encapsulated in IPsec.  I am curious 
why TLS is favored over IPsec, which has always supported TCP, UDP and 
other transports.

Mark
On Jul 10, 2005, at 7:08 AM, Jonathan Lennox wrote:

> On Sunday, July 10 2005, "Colin Perkins" wrote to "Jonathan Lennox, 
> Magnus Westerlund, IETF MMUSIC working group, lazzaro Lazzaro" saying:
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Jul 2005 21:01:05 +0100

> No, I am not. At least not now.

In which case, I suggest we proceed with the current draft, and leave  
definition of new formats until there is someone both sees a need and  
is able to do the work.

Colin