[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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!
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