RE: Question to DTLS-SRTP

Hi David,

thanks for the comments. I added some more inline.
 
> thanks for your comments.  The motivation for having multiple 
> DTLS sessions is to maintain the TLS convention that there is 
> a 1:1 mapping between TLS connections and the ports that they 
> are protecting.  Eric can speak to this better than I.
[stf] Hm, I'm not sure if I agree. At first I was thinking on session
resumption, as you can resume a session to a different port than the
original one (if the server allows this), so the binding of the inital
(complete) handshake to the port opened for TLS in the first place is
enhanced later on with the second port. But here TLS is still used to
protect the data traffic. In the DTLS-SRTP case, only the key material
is negotiated and the TLS record layer is not used. Moreover,
draft-rescorla-tls-extractor-00.txt allows for using the key management
of (D)TLS in a more general way, not just for SRTP. 
Does this ease the convention? 
The reasoning for asking is that one hand the handshake phase needs
additional roundtrips to be performed (okay, SRTCP may not be subject to
the same kind of real-time requirements as SRTP). On the other hand, the
SRTP module expects a masterkey for deriving both SRTP and SRTCP related
key material. So using the approach of having two distinct master keys
for SRTP and SRTCP may increase the internal handling of media and key
associations in the key establishment phase (keeping more key
information an states in the internal database of the SRTP module).

> Fortunately, when RTP and RTCP use a single port, only one 
> single TLS  
> connection is needed.   Since that's appealing for NAT traversal  
> reasons, in addition to being efficient, I expect that it is 
> reasonable to make that the preferred mode for TLS-SRTP.  The 
> first version of the document didn't describe that property, 
> and it looks to me that you've found a place where the 
> document needs more editing.
[stf] If both use the same port it certainly eases the burden of
firewall traversal and also removes the question for a second DTLS
handshake. 

Regards
        Steffen

> 
> best regards,
> 
> David
> 
> On Apr 2, 2007, at 4:35 AM, Fries, Steffen wrote:
> 
> >
> > Hi,
> >
> > I've got a question to the current draft of DTLS-SRTP 
> > (draft-mcgrew-tls-srtp-02.txt).
> >
> > The current draft states in section 3.1 Usage Model
> >    If both RTCP and RTP use the same source and destination 
> ports [7],
> >    then the both the RTCP packets and the RTP packets are 
> protected by 
> > a
> >    single DTLS-SRTP session.  Otherwise, each RTCP flow is 
> protected 
> > by
> >    a separate DTLS-SRTP session that is independent from 
> the DTLS-SRTP
> >    session that protects the RTP packet flow.
> >
> > Moreover, appendix A states:
> >    Another alternative is to take advantage of the fact 
> that an (S)RTP
> >    channel is intended to be paired with an (S)RTCP 
> channel.  The DTLS
> >    handshake could be performed on just one of those 
> channels and the
> >    same keys used for both the RTP and RTCP channels.  This 
> > alternative
> >    is defined in Appendix B for study and discussion.
> >
> > Why is the latter case stated for further study, as I would 
> expect the 
> > key management to provide a master key, which can be used 
> with the PRF 
> > defined in RFC3711 to derive keys for both, SRTP and SRTCP. 
> In fact, 
> > this is what current key management approaches do like MIKEY or 
> > sdescription by providing a master key for SRTP. I'm not sure if I 
> > understand the intention for putting the concept of two 
> distinct DTLS 
> > sessions in the first place as opposed two a single DTLS session 
> > providing the key material for both, SRTP and SRTCP.
> >
> > Ciao
> >     Steffen
> >
> 
>