[AVT] Unsubscribe - SSRC to DTLS-SRTP mapping

[Prayas Arora <prayas.arora at case.edu>]

----- Original Message -----
From: Dan Wing <dwing at cisco.com>
Date: Tuesday, February 19, 2008 12:22 pm
Subject: Re: [AVT] SSRC to DTLS-SRTP mapping
To: 'Eric Rescorla' <ekr at networkresonance.com>
Cc: magnus.westerlund at ericsson.se, 'Roni Even' 
<roni.even at polycom.co.il>, avt at ietf.org, 'Tom Taylor' 
<tom.taylor at rogers.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 
> cycleswhich 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 
> consensusprotected 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 
> otherdeployed protocols.  IPsec, DTLS's handshake, and TCP MD5 all 
> employmechanisms to avoid running a MAC by first requiring a match 
> of a 32-bit
> identifier (IPsec's SPI), return routability (DTLS handshake), or 
> sourceaddress (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 
> moresevere 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 
> proposingSSRC 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 
> addressverification 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
> 
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt