Re: [AVT] SSRC to DTLS-SRTP mapping

[Eric Rescorla <ekr at networkresonance.com>]

At Mon, 18 Feb 2008 23:33:43 -0800,
Dan Wing wrote:
> 
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> > Behalf Of Eric Rescorla
> > Sent: Sunday, February 17, 2008 9:49 AM
> > To: avt at ietf.org
> > Cc: magnus.westerlund at ericsson.se; Roni Even; Tom Taylor
> > Subject: [AVT] SSRC to DTLS-SRTP mapping
> > 
> > After the last IETF, Magnus and Colin raised an issue about cases in
> > DTLS-SRTP where there are multiple sessions to the same endpoint, as
> > in SIP forking, and how the current draft didn't handle them right.
> > 
> > Magnus and I chatted about this on the phone last week and came to a
> > resolution which I've attempted to transcribe. I've attached the
> > revise sections below. If AVT members could take a look and let me
> > know if it's screwed up, I'd appreciate it. I plan to submit
> > this next weekend, so if people can send any comments before
> > COB Friday, that would be best!
> 
> This design means that when receiving an SRTP packet with a
> never-before-seen SSRC, the receiver has to attempt to authenticate
> that received packet against all of its DTLS-SRTP security
> associations for that local socket.  This will be at least one SHA1
> for that received packet (if no forking) or more SHA1s (if there has
> been forking).
>
> I worry that this design is weaker than IPsec ESP's protection from
> bogus packets, or DTLS's protection from bogus packets during the DTLS
> handshake:
>
> 1.  IPsec ESP only attempts to authenticate a packet if the SPI is
>     already known (reference Section 3.4.2 of RFC2406); We could
>     achieve something similar by communicating the SSRC in the
>     DTLS-SRTP handshake.
> 
> 2.  DTLS supports using a cookie to test return routability before
>     incurring the computational expense of a DTLS handshake. We could
>     achieve something similar by only attempting to perform the
>     procedures you describe if the SRTP packet arrived from the same
>     transport address as the DTLS-SRTP handshake itself.


You don't state what attack you're concerned with, but I'm assuming
that it's resource consumption on the receiver. I'm not overly
concerned by that because MAC verification is extremely fast, so it's
not clear that this is more serious than the bandwidth
consequences. Note that the DoS protection in the DTLS handshake (and
the IKE) handshake is concerned with avoiding unnecessary asymmetric
key operations, which are far more expensive.

1. As I understand things from my conversations with Magnus and Colin,
being willing to decrypt an RTP packet with an arbitrary SSRC sent to
your local host/port pair is inherent in the RTP model, since new
SSRCs can appear at any time. Thus, no matter what keying mechanism
you are using for SRTP, the attacker can force you to do a single
verification operation for each packet he sends you. (I'm ignoring
source address verification for the moment.)


2. The difference with the algorithm I suggested is that it allows a
very modest amplification, namely that the attacker can force you to
compute this operation once for each fork during the (short) window
where multiple forks are valid. Given the short window and the modest
amount of amplification, I'm not concerned.

With regard to the first avenue you suggest, my understanding is that
communicating the SSRCs in the DTLS handshake is a problem because
they may not be known at that time and new SSRCs can appear later, so
this breaks the RTP model. For instance, as I understand S 8.2 of RFC
3550, if Alice and Bob are communicating and have an SSRC collision,
Alice MUST send an RTCP BYE and choose a new SSRC. So, in this
instance, Alice would now know her SSRC at the time of the DTLS
handshake.

With regard to the second avenue you suggest, the original algorithm
we had was to use the source IP and port as the disambiguator.  The
algorithm I just posted comes from having Magnus and Colin point out
to me that in RTP a session was defined by the destination address,
destination port, and SSRC and that you were not supposed to look at
the host port. Clearly, if you can look at the source host/port pair,
then no map table is needed.

So, my understanding is that both of these suggestions break the RTP
architecture. But again, I'm no RTP expert, so if I've misunderstood,
I hope people will correct me.

-Ekr
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt