[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Comments on "SRTP Not Mandatory" (draft-perkins-avt-srtp-not-mandatory-01.txt)
Dan,
[Coming back to this very late...]
On 28 Jul 2008, at 21:31, Dan York wrote:
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?
Yes - this has actually been very problematic when trying to get
drafts approved by the IESG.
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.
Agreed. The main point, though, is that the answer for media security
is not "just use SRTP", it's "use SRTP, unless...", and this draft is
trying to explain that the "unless" will always exist.
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.
Those protocols are very closely tied to unicast telephony and
conferencing, whereas this draft is considering the full range of RTP
use case. I'd prefer this draft to simply point out that there are a
range of keying protocols, and not recommend any of them. I'll try to
clarify in the coming revision.
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?
There are likely still users of the basic encryption specified in RFC
1889. I'm not aware of any other proposals.
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 working draft now states "SRTP is a preferred solution for the
protection of the RTP traffic in those use cases where it is
applicable. It is out of scope for this memo to recommend a
preferred key management solution."
Cheers,
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt