[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] SSRC to DTLS-SRTP mapping
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
On 17 Feb 2008, at 17:48, Eric Rescorla wrote:
> 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
> avt at ietf.org
> http://www.ietf.org/mailman/listinfo/avt
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt