[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Comments on "SRTP Not Mandatory" (draft-perkins-avt-srtp-not-mandatory-01.txt)
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 dyork at voxeo.com
Phone: +1-407-455-5859 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
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt