[AVT] SSRC to DTLS-SRTP mapping

[Eric Rescorla <[e-mail]>]

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
[e-mail]
http://www.ietf.org/mailman/listinfo/avt