Review of draft-tschofenig-avt-rtp-dtls-00 (Re: [AVT] Media over DTLS)

[Lakshminath Dondeti <[e-mail]>]

Hi Eric,

As promised in my other email, here is a review of the avt-rtp-dtls 
I-D (I'll follow-up with reviews on some of the others tomorrow).

1. Needs a motivation section.  I realize there is one in 
sipping-media-dtls, but I would like to see one here as well 
explaining why RTP over DTLS is needed or makes sense.

2. I have questions about DTLS-short and its equivalency to DTLS, but 
that's another draft and I will ask comments in the relevant forum 
(would it be TLS?).

3.  On the text in the last paragraph of Section 4:

"With these extensions negotiated, RTP over DTLS packets look
    identical to SRTP records with a 10-byte MAC value.  In fact, they
    cannot be distinguished without access to the DTLS or SRTP keying
    material.  In addition, since the RTP header is in the clear, header
    compression and debugging both work.  Note that DTLS running in SRTP
    compatibility mode has the same security properties as ordinary DTLS
    (with the truncated MAC); there is a reduction between the two
    protocols."

a) I am curious about how DTLS or SRTP packets are distinguished in 
the first place.  In case of SRTP, the destination, port ID and SSRC 
identifies the crypto context.  Why not talk about things in those 
terms and make it more concrete.

Why the need to be identical to SRTP packets?

b) There is no concept of SRTP records!

c) Is there a paper on the reduction between DTLS and DTLS-short?  Is 
DTLS-short an independent protocol or DTLS in SRTP compatibility mode?

4. Would like to see more on the subject of Section 5.  Can I 
conclude that there will be (2 * number of sources) DTLS 
sessions?  How many DTLS handshakes would that be? (Or is there a 
possibility of optimization?)

5. Section 6 has some fundamental errors regarding RFC 3711.  The 
statement that "SRTP uses a 4 byte MAC" is incorrect!  That entire 
section goes on to make comparisons based on that assertion, and that 
should be corrected.

I don't understand how the entire epoch and sequence number can be 
deleted in DTLS-short, but I will ask that in a separate email.

I reached the end of the draft, but have the question of the purpose 
of the draft itself.  I didn't see it specifying anything.  Is it an 
informational draft or is it just to specify:

"
In order to use DTLS/RTP in SRTP compatibility mode, implementations
    SHOULD negotiate:
    o  The TLS partial encryption extension with an InitialPlaintext
       value equal to the length of the RTP header.
    o  The DTLS implicit application data header.
    o  The TLS MAC truncation extension.
"

Shouldn't counter mode part of the list?

Anyway, I'll look forward to your clarifications.  Thanks in advance.

regards,
Lakshminath



At 03:59 PM 3/2/2006, Eric Rescorla wrote:
>Hi,
>
>AVT working group members may be interested in the following suite
>of drafts, which define a method for securing multimedia (especially)
>RTP traffic using DTLS:
>
>http://www.ietf.org/internet-drafts/draft-fischl-sipping-media-dtls-00.txt
>http://www.ietf.org/internet-drafts/draft-tschofenig-avt-rtp-dtls-00.txt
>http://www.ietf.org/internet-drafts/draft-fischl-mmusic-sdp-dtls-00.txt
>http://www.ietf.org/internet-drafts/draft-modadugu-dtls-short-00.txt
>http://www.ietf.org/internet-drafts/draft-rescorla-tls-partial-00.txt
>http://www.ietf.org/internet-drafts/draft-ietf-tls-ctr-00.txt
>
>Why is this interesting? SIP does not have a scheme for key negotiation
>of media encryption that works with early media and forking. This set of
>drafts addresses these issues. Instead of inventing a new key
>negotiation protocol, it uses DTLS for key establishment and algorithm
>negotiation while having the same on-the-wire packet format as SRTP.
>
>HTML versions can be found at:
>
>http://scm.sipfoundry.org/rep/ietf-drafts/ekr/{draft}.html
>
>The draft of most interest to this WG is probably
>draft-tschofenig-avt-rtp-dtls-00 but you may find it helpful to read
>draft-fischl-sipping-media-dtls-00 first for background.
>
>-Ekr
>
>
>
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/avt


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