Subject: [AVT] SSRC to DTLS-SRTP mapping

From: Eric Rescorla <[email-masked]>
Date: Sun, 17 Feb 2008 09:48:31 -0800

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!

Thanks,
-Ekr

5.1.2.  Reception

   When DTLS-SRTP is used to protect an RTP session, the RTP receiver
   needs to demultiplex packets that are arriving on the RTP port.
   Arriving packets may be of types RTP, DTLS, or STUN[13].  The type of
   a packet can be determined by looking at its first byte.

   The process for demultiplexing a packet is as follows.  The receiver
   looks at the first byte of the packet.  If the value of this byte is
   0 or 1, then the packet is STUN.  If the value is in between 128 and
   191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and
   RTP are being multiplexed over the same destination port).  If the
   value is between 20 and 63 (inclusive), the packet is DTLS.  This
   processes is summarized in Figure 7.

                   +----------------+
                   | 127 < B < 192 -+--> forward to RTP
                   |                |
       packet -->  |  19 < B < 64  -+--> forward to DTLS
                   |                |
                   |       B < 2   -+--> forward to STUN
                   +----------------+

         Figure 7: The DTLS-SRTP receiver's packet demultiplexing
   algorithm.  Here the field B denotes the leading byte of the packet.

   In some cases there will be multiple DTLS-SRTP associations for a
   given SRTP endpoint.  For instance, if Alice makes a call which is
   SIP forked to both Bob and Charlie, she will use the same local host/
   port pair for both of them, as shown in Figure 8.  (The SSRCs shown
   are the ones for data flowing to Alice).

                                          Bob (192.0.2.1:6666)
                                         /
                                        /
                                       / SSRC=1
                                      /  DTLS-SRTP=XXX
                                     /
                                    v
               Alice (192.0.2.0:5555)
                                    ^
                                     \
                                      \  SSRC=2
                                       \ DTLS-SRTP=YYY
                                        \
                                         \
                                          Charlie (192.0.2.1:6666)

                  Figure 8: RTP sessions with SIP forking

   Because DTLS operates on the host/port quartet, the DTLS association
   will still complete correctly, with the foreign host/port pair being
   used to distinguish the associations.  However, in RTP the source
   host/port is not used and sessions are identified by the destination
   host/port and the SSRC.  Thus, some mechanism is needed to determine
   which SSRCs correspond to which DTLS associations.  The following
   method SHOULD be used.

   For each local host/port pair, the DTLS-SRTP implementation maintains
   a table listing all the SSRCs it knows about and the DTLS-SRTP
   associations they correspond to.  Initially, this table is empty.
   When an SRTP packet is received, the following procedure is used:

   1.  If the SSRC is already known, then the corresponding DTLS-SRTP
       association and its keying material is used to decrypt the
       packet.
   2.  If the SSRC is not known, then the receiver tries to decrypt it
       with the keying material corresponding to each DTLS-SRTP
       association.
   3.  If the decryption succeeds (the authentication tag verifies) then
       an entry is placed in the table mapping the SSRC to that
       association.
   4.  If the decryption fails, then the packet is silently discarded.

   The average cost of this algorithm for a single SSRC is the
   decryption time of a single packet times the number valid DTLS-SRTP
   associations corresponding to a single receiving port on the host.
   In practice, this means the number of forks, so in the case shown in
   Figure 8, that would be two.  This cost is only incurred once for any
   given SSRC, since afterwards that SSRC is placed in the map table and
   looked up immediately.  As with normal RTP, this algorithm allows new
   SSRCs to be introduced by the source at any time.  They will
   automatically be mapped to the correct DTLS association.

   There are two error cases that should be considered.  First, if an
   SSRC collision occurs, then only the packets from the first source
   will be processed.  When the packets from the second source arrive,
   the DTLS association with the first source will be used for
   decryption, which will fail, and the packet will be discarded.  This
   is consistent with [3], which permits the receiver to keep the
   packets from one source and discard those from the other.

   Second, there may be cases where a malfunctioning source is sending
   corrupt packets which cannot be decrypted.  In this case, the SSRC
   will never be entered into the mapping table, because the decryption
   always fails.  Receivers MAY keep records of unmapped SSRCs which
   consistently fail decryption and abandon attempts to decrypt them
   once they reach some limit.  That limit MUST be large enough to
   account for the effects of transmission errors.

...

7.4.  Decryption Cost

   An attacker can impose computational costs on the receiver by sending
   superficially valid SRTP packets which do not decrypt correctly.  In
   general, encryption algorithms are so fast that this cost is
   extremely small compared to the bandwidth consumed.  The SSRC-DTLS
   mapping algorithm described in Section 5.1.2 gives the attacker a
   slight advantage here because he can force the receiver to do more
   then one decryption per packet.  However, this advantage is modest
   because the number of decryptions that the receiver does is limited
   by the number of associations he has corresponding to a given
   destination host/port, which is typically quite small.  For
   comparison, a single 1024-bit RSA private key operation (the typical
   minimum cost to establish a DTLS-SRTP association) is hundreds of
   times as expensive as decrypting an SRTP packet.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Feb 2008 23:33:43 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Sunday, February 17, 2008 9:49 AM
> To: [email-masked]
> Cc: [email-masked]; Roni Even; Tom Taylor
> Subject: [AVT] SSRC to DTLS-SRTP mapping
> 

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.

I realize that (1) requires modifying the DTLS-SRTP handshake, which
you have attempted to avoid as much as possible.  But (2) would
provide at least some protection from off-path attackers.

Would either of these approaches have a poor interaction with  RTP's
architecture?

-d

---

From: "John W. Floroiu" <[email-masked]>
Date: Tue, 19 Feb 2008 13:35:52 +0100

Hello,

regarding the first error case that you mention, which would translate 
for instance in both Bob and Charlie sending both of them media streams 
with SSRC=1, what would happen if the media stream from Bob arrives 
first (and triggers the SSRC mapping) but Alice's UA actually cancels 
the call with Bob (because for instance the 200 OK from Charlie arrived 
first)?

Regards,
John

 >    [...]
>    [...]  
>    [...]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Feb 2008 06:52:56 -0800

At Tue, 19 Feb 2008 13:35:52 +0100,
> the call with Bob (because for instance the 200 OK from Charlie arrived 

Good point. I hadn't thought of that issue. 

However, since you know which DTLS-SRTP associations are bound to
which fork, you can simply remove the entry from the table and
then when Charlie's next packet comes in it will automatically
get mapped into the table. Obviously, this means that you'll
start by playing Bob's voice and then Charlie's but that's
inherent in this RTP-level SSRC collision strategy, I think.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Feb 2008 07:10:28 -0800

At Mon, 18 Feb 2008 23:33:43 -0800,
>     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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Feb 2008 09:21:50 -0800

> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Tuesday, February 19, 2008 7:10 AM
> To: Dan Wing
> Cc: 'Eric Rescorla'; [email-masked]; 
> [email-masked]; 'Roni Even'; 'Tom Taylor'
> Subject: Re: [AVT] SSRC to DTLS-SRTP mapping
> 
> > bogus packets, or DTLS's protection from bogus packets 
> > during the DTLS handshake:
> >
> 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
> 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

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?

> instance, Alice would now know her SSRC at the time of the DTLS

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

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

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Feb 2008 22:48:52 +0000

On 19 Feb 2008, at 17:21, Dan Wing wrote:
...
> 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.
>

I see the concern, but I think this has to work in the general case,  
without signalling support (except the DTLS handshake). I have no  
problem with there being optimisations possible in those cases where  
the SSRC to host/port pair mapping can be signalled out of band  
though, since there will certainly be scenarios where that's possible.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Feb 2008 22:51:44 +0000

Ekr,

I think this is fine, however it might be worth explicitly calling  
out the case where you're talking to an RTP translator, which is  
sending two SSRCs from the same address/port pair, as an example.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Feb 2008 15:03:23 -0800

> though, since there will certainly be scenarios where that's possible.

Would dropping a DTLS packet on the floor if its source IP address and 
port are different from the DTLS handshake be acceptable?

-d

---

From: Colin Perkins <[email-masked]>
Date: Thu, 21 Feb 2008 15:44:40 +0000

> port are different from the DTLS handshake be acceptable?

Yes, I think so. Why do you think it might not be?

-- 
Colin Perkins
http://csperkins.org/

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Feb 2008 08:24:24 -0800

At Thu, 21 Feb 2008 15:44:40 +0000,
> Yes, I think so. Why do you think it might not be?

Dan, do you really mean "DTLS packet" or do you mean "SRTP Packet"?

Because I think the answer is different for DTLS is "yes" but
SRTP is "no"--again, unless I've badly misunderstood RTP,
which is totally possible.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Feb 2008 09:28:18 -0800

> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Thursday, February 21, 2008 7:45 AM
> To: Dan Wing
> Cc: [email-masked]; 'Roni Even'; 'Tom Taylor'; 
> [email-masked]

Because it is my understanding RTP does not allow similar filtering.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Feb 2008 09:35:56 -0800

> Dan, do you really mean "DTLS packet" or do you mean "SRTP Packet"?

Thanks for catching that.

Yes, I meant:  would it be acceptable to drop an SRTP packet on the 
floor if its source IP address and port are different from the 
DTLS handshake.

> which is totally possible.

What I am trying to understand if a single DTLS-SRTP handshake
between two hosts is really supposed to be able to provide the key 
for any ol' SRTP packet that might happen to arrive on that host's
IP address and port.  I agree RTP works that way.

I find it risky to have SRTP work that way, because no other
security protocol has the receiver run a MAC without first 
doing a simple comparison on some other field (IPsec SPI, source
address of the packet, TCP sequence number, etc....).  

It is a new risk for SRTP to do this.

-d

---

From: "Bino George" <[email-masked]>
Date: Fri, 22 Feb 2008 09:14:13 +0530

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Rescorla
Sent: Thursday, February 21, 2008 9:54 PM
To: Colin Perkins
Cc: [email-masked]; 'Roni Even'; 'Tom Taylor'; Dan Wing;
[email-masked]
Subject: Re: [AVT] SSRC to DTLS-SRTP mapping

-Ekr

---

From: Prayas Arora <[email-masked]>
Date: Sun, 24 Feb 2008 22:15:23 -0500

----- Original Message -----
From: Dan Wing <[email-masked]>
Date: Tuesday, February 19, 2008 12:22 pm
Subject: Re: [AVT] SSRC to DTLS-SRTP mapping
To: 'Eric Rescorla' <[email-masked]>
Cc: [email-masked], 'Roni Even' 
<[email-masked]>, [email-masked], 'Tom Taylor' 
<[email-masked]>

> > > 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
> > > I worry that this design is weaker than IPsec ESP's protection 
> from> > bogus packets, or DTLS's protection from bogus packets 
> I agree it's fast.  On our low end boxes SHA1 takes about 6000 CPU 
> cycleswhich is about 30 microseconds with our clock speed.
> 
> that we are leaving SRTP vulnerable to this attack when design 
> consensusprotected other protocols from this same attack.  CPUs 
> are faster now, yes.
> 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
> > 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
> > where multiple forks are valid. Given the short window and the 
> modest> amount of amplification, I'm not concerned.
> 
> 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
> 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).
> 
> Yes, I agree that is the RTP model.  In Security Descriptions 
> [RFC4568]we followed that model and allow packets from anywhere to 
> arrive, and
> > architecture. But again, I'm no RTP expert, so if I've 
> misunderstood,> I hope people will correct me.
> 
> DTLS exchange (handshake or separate message), and/or use source 
> addressverification to help protect devices from such an attack.
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 25 Feb 2008 12:27:19 +0000

On 21 Feb 2008, at 17:28, Dan Wing wrote:
...
>>> Would dropping a DTLS packet on the floor if its source IP  
>>> address and port are different from the DTLS handshake be  
>>> acceptable?
>>

RTP is certainly used in scenarios where such filtering is  
inappropriate, but I don't think an end-point is prohibited from  
filtering based on the source address.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Feb 2008 17:22:23 -0800

> filtering based on the source address.

Ok.

-d

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