[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] SSRC to DTLS-SRTP mapping
> -----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.
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
> 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
> 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