Subject: [AVT] draft-mcgrew-dtls-srtp-00

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Mar 2006 09:36:15 -0800

Folks,

Here's a pointer to the draft by David McGrew and myself that Jason
Fischl mentioned in today's AVT meeting. It uses DTLS for key
establishment and algorithm/parameter negotiation and SRTP for carrying
the media.

http://scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-mcgrew-dtls-srtp.html
http://scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-mcgrew-dtls-srtp.txt

-Ekr

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

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 21 Mar 2006 15:22:55 -0500

I took a quick read through the document and a few high-level issues 
came to mind. One important piece that is missing from this draft is how 
you couple it with higher layer signaling and a treatment of the issues 
that may arise as a result of that. Experience with other efforts in 
this area have shown that you cannot treat these problems independently 
if you want to come up with a good solution, so I'd ask for some 
material in this area (neither of the referenced solutions in the draft, 
i.e. sdescriptions or SDP indicators for DTLS seem to apply to this 
proposal as-is). Some of the topics I'd like to understand better in 
particular are:

- Parameter negotiation. With offer/answer, at the time we accept an 
offer, we know that the offerer and answerer have parameters in common 
that will enable them to setup a media stream (under normal 
circumstances). The proposal here seeems to move part of the negotiation 
to the DTLS layer instead, and hence after completion of offer/answer, 
which is quite a change. In order to get back to the desired semantics, 
you would need to use security preconditions, however we know that 
people don't like that. Have you considered how to retain the existing 
offer/answer properties here ?
- Handling of SSRCs. It's unclear how a DTLS exchange relates to an SRTP 
crypto context and in particular how you associate an SSRC with a 
particular DTLS exchange. Is there one per SSRC, i.e. DTLS needs to 
create a crypto context for an SSRC before it can be used ? If so, we 
can't just start using new SSRCs when we want to, but instead will have 
to perform the necessary DTLS exchange first.
- Draft states that "DTLS-SRTP is defined for point-to-point media 
sessions, in which there are exactly two participants". Clearly, that 
puts multicast out-of-scope, however what about SIP forking - is that 
out of scope too ? If not, how is SIP forking handled ? Issues to 
consider here include associating DTLS exchanges with SSRCs, correlating 
answers with DTLS exchanges, SSRC collision detection and resolution in 
DTLS, etc.
- Concerns around varying network resource usage. It seems DTLS 
exchanges can occour mid-stream as on the SRTP transport address. For 
networks using QoS reservations, and in particular with fixed size 
time-slots based on negotiated payloads, this can be quite an issue. 
Could probably be addressed by moving this to the SRTCP port instead 
though.

I'm sure there are plenty more things to consider (have some detailed 
comments as well which are probably not worthwhile getting into at this 
point), however the above at least is a starting point.

-- Flemming