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

[Jonathan Lennox <lennox at cs.columbia.edu>]

On Friday, July 8 2005, "Magnus Westerlund" wrote to "Jonathan Lennox, lazzaro, mmusic at ietf.org, avt at ietf.org" saying:

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

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

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

Fair enough.

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

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
lennox at cs.columbia.edu

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt