[AVT] Comments on "SRTP Not Mandatory" (draft-perkins-avt-srtp-not-mandatory-01.txt)

[Dan York <[e-mail]>]

Colin,

A few comments on http://tools.ietf.org/id/draft-perkins-avt-srtp-not-mandatory-01.txt 
  . First, one caveat: I have not been (but am now) a subscriber to  
the AVT mailing list and so I did not see any of the previous  
discussion on this draft. The first I knew of it was the Dublin agenda  
and the discussion today.  Having said that, when I search the list  
archives (using Gmane.org) I can't seem to find any strong discussion  
on the list.

Comments:

1. It's not entirely clear to me WHY this draft is necessary.  I heard  
Cullen's comments today that this would make all of our lives easier  
as draft authors and have seen Colin's post here: http://article.gmane.org/gmane.ietf.avt/8084/ 
  Is the issue really that we essentially need a FAQ about SRTP/RTP?

2. The section on RTP Applications and Deployment Scenarios is nicely  
done.

3. In section 3 in the second paragraph, I would suggest a better  
example is necessary to demonstrate media security solutions other  
than SRTP than the example using a single TCP connection.  In that  
example, TLS is being used to encrypt the *entire* SIP and media  
connections.  Effectively creating a TLS tunnel and putting all the  
SIP and media traffic through it.  A similar example could be given  
with IPSec.  In both cases, though, I would argue that they are NOT  
doing something special with RTP... they are encrypting the entire  
channel and *nothing* is being done specific to RTP.

To put it another way, the example does NOT convince me that SRTP  
could not be mandatory *when a security solution is required for  
RTP*.  In this example of TLS encrypting the entire channel, RTP  
"security" could simply be turned off as there is no need for it.

4. Similarly, in the third paragraph of section 3, the example of the  
secure link layer does not convince me that SRTP could not be mandated  
as again, it is a situation where doing something to the RTP protocol  
is not required because the underlying transport mechanism is secure.

5. In section 4, "Implications for Key Management", I understand that  
you are trying to make the point that there are a wide range of  
options out there, but the reality that I am seeing out there in the  
market is that there is only really *one* SRTP key management protocol  
deployed in any meaningful way... "sdescriptions".  I've heard of a  
few pre-standard DTLS-SRTP efforts and there are certainly some ZRTP  
implementations in a few products, but beyond that I've not seen any  
serious usage of any of the other mechanisms listed.  (I'd love to  
hear otherwise from others on the list.)  We beat this whole issue up  
in a whole range of RTPSEC BOFs over the course of a number of IETF  
meetings.

I know you reference draft-ietf-sip-media-security-requirements (which  
is now up to -07) which defines the requirements for key exchange  
protocols, but I would suggest that this draft should reflect a bit  
more closely the actual SRTP usage out there and mention the  
convergence toward two primary protocols (sdescriptions and DTLS-SRTP)  
with another one (ZRTP) out in the market as well.

6. In section 5 and 6, I guess maybe I'm looking at this a bit  
differently.  The document indicates there are cases where SRTP makes  
sense to be used - and there are cases where NO modifications to RTP  
are necessary.  So it seems to me that you could break RTP encryption  
out into two cases:

   A. TRANSPORT PROTECTION EXISTS - Either through other encryption  
mechanisms like TLS or IPSec or physical mechanisms such as dedicated  
physical channels.  In this case, no special security is used for RTP  
and plain old RTP is sent across the protected transport.

   B. NO TRANSPORT PROTECTION EXISTS - Use SRTP.

I've not seen any other suggestions for security mechanisms that  
modify the RTP beyond SRTP.  Are there any others being proposed?

With this in mind, I would suggest that we could summarize it more as  
that you have two options for securing RTP: 1) using a security  
mechanism that protects the transport of the RTP and allows the RTP to  
pass unaltered; or 2) use SRTP if you can't (or don't want to) secure  
the underlying transport.

7. Based on what I said in my #5 above, I would disagree with the  
final sentence of section 6, the Conclusion: "Currently is is much  
harder to point out a preferred key-management solution."   As stated  
earlier, pretty much everyone I know of right now who is doing SRTP is  
using sdescriptions as the key management solution.  After pounding  
through 13+ proposals in the RTPSEC BOF, the direction of the IETF is  
very clearly on DTLS-SRTP as "the way forward".  I would suggest that  
this should be mentioned in some manner.

8. NITS - Two minor ones:

    a. Last sentence of last paragraph in section 5... "with an option  
of turining on" should obviously be "turning".

    b. First paragraph of section 6, second sentence... "In the  
absense..." should be "absence".


I'm not saying that we shouldn't have this draft. I understand that  
there is a need to explain why we just don't mandate SRTP everywhere.   
But I also think we should promote/recommend that SRTP be used  
wherever transport protection isn't available and should also promote/ 
recommend the paths that we see for the SRTP key exchange going forward.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [e-mail]
Phone: [phone]  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free





_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt