Re: [AVT] SSRC to DTLS-SRTP mapping

["Dan Wing" <dwing at cisco.com>]

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr at networkresonance.com] 
> Sent: Tuesday, February 19, 2008 7:10 AM
> To: Dan Wing
> Cc: 'Eric Rescorla'; avt at ietf.org; 
> magnus.westerlund at ericsson.se; 'Roni Even'; 'Tom Taylor'
> Subject: Re: [AVT] SSRC to DTLS-SRTP mapping
> 
> 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.

Yes.

> I'm not overly
> concerned by that because MAC verification is extremely fast,

I agree it's fast.  On our low end boxes SHA1 takes about 6000 CPU cycles
which is about 30 microseconds with our clock speed.

Yet, other deployed protocols protect themselves from such attacks.  I worry
that we are leaving SRTP vulnerable to this attack when design consensus
protected other protocols from this same attack.  CPUs are faster now, yes.
But the next generation MAC (whatever will replace SHA1) is probably going to
consume more CPU cycles (not less), making up for future improvements in CPU
speed.

I am surprised to see this SRTP design offers less protection than other
deployed protocols.  IPsec, DTLS's handshake, and TCP MD5 all employ
mechanisms to avoid running a MAC by first requiring a match of a 32-bit
identifier (IPsec's SPI), return routability (DTLS handshake), or source
address (TCP MD5).  We can design something similar for SRTP.  Afterall, we
cannot successfully receive an SRTP packet until a DTLS-SRTP handshake has
completed.  A source address verification check seems, at minimum, a level of
protection we should be able to achieve without breaking RTP's architecture.

> 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.

Yes, that is the RTP model.

However, with DTLS-SRTP, we are not able to decrypt an SRTP packet
at all until DTLS-SRTP completes anyway and (unless we are willing
to accept RTP and SRTP at the same time) we cannot play out an RTP
packet at all.  So, in that sense, the RTP model is already broken:  
we cannot fit the model because we can not play out an arbitrary
packet.  We first need to do a DTLS-SRTP handshake.  

> (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 today's SIP applications, it is true that forking is most often
short lived.

Is it reasonable to require tomorrow's SIP applications to also 
have short-lived forking, or else risk (with longer-lived forking) the
SRTP receivers will endure a longer winder where they can suffer a more
severe SRTP attack?

> 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.

Could Alice send a DTLS message containing her new SSRC?  This could
be sent in a new DTLS handshake (if an SSRC field were added to it), or 
sent in a newly-defined DTLS content-type (similar to how I am proposing
SSRC is communicated in draft-wing-avt-dtls-srtp-key-transport-01).

> 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.

Yes, I agree that is the RTP model.  In Security Descriptions [RFC4568]
we followed that model and allow packets from anywhere to arrive, and
authenticate them using the "late binding" (Section 6.4.1 of [RFC4568]).

With DTLS-SRTP, there is a DTLS handshake with a specific remote IP
address, and then SRTP packets are sent.  Because this handshake is
necessary to establish the cryptographic context (for successful
authentication, decryption, and encryption), it seems beneficial to
use the same source IP adddress and port as the DTLS-SRTP handshake
to 

> 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.

I am not claiming to be an RTP expert.

However, I am worried about an attack flooding a device and causing the device
to perform SHA1 operations, when it seems we could communicate the SSRC in the
DTLS exchange (handshake or separate message), and/or use source address
verification to help protect devices from such an attack.

If it's only me that has this concern, I will sit back down in my chair.

-d

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