Re: [rtcweb] STUN for keep-alive

[Magnus Westerlund <[e-mail]>]

Hi,

As an individual I like to provide some analyze of the entropy in
RTP/RTCP. Please consider, comment and provide opinion about the number
of bits.

On 2011-09-16 20:30, Eric Rescorla wrote:

>> The RTCP receiver reports should be adequate for 'consent freshness', no?
>> If I still like receiving the traffic, I'll report that I'm receiving it.
>> If I have crashed or disconnected or am not listening on that port, I won't.
> 
> I believe so, though I'd have to make sure there's enough entropy. And of course
> some implementations may not do RTCP...
> 

So one case of attack is the one when the webserver S uses the connected
clients to attack target T by instructing client C to send to target T.
So the Server or some server controlled entity A needs to send RTCP to C
that makes C believe T is responding, i.e. spoofed source address that
are T's plus the content of the RTCP RR. Please note that SRTP will not
provide any protection if the webserver knows the key. Thus if security
description is allowed, which appear reasonable if supporting legacy is
the goal, which is the reason for this whole proposal.

Then lets analyze the entropy provided by RTP/RTCP.

RTP header:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


So this is what is sent from C to T in a sequence.

Lets go through the fields in order:

V: fixed field
P: Indicator bit for padding. Not reported
X: Extension header indicator. Not reported
CC: CSRC Count: Normally 0. Not reported
M: Defined by payload type. Not reported
PT: Payload type, defined in signalling know by server
Sequence number: Hopefully random initial offset. Monotonically
incremented. Reported
Timestamp: Random offset, Not reported
SSRC: Random drawn. Likely signalled as it needs to be mapped to media
streams in current API. Reported

Lets then look at the fields present in an RR or SR
RTCP Report block

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


SSRC_1: Assumed to be known by webserver

Fraction lost: can be selected 0 or low value

cumulative number of packets lost: Can be selected, just needs to
increase at some interval if fraction lost isn't 0.

Extended highest sequence number: Top 16 bit will be 0 when starting up.
Now only the lowest 16 needs to be guessed. How difficult depends on the
packet rate, higher packet rate makes it easier as the range that C will
find the report valid for is larger. To make this robust any RTCP
reporting that contains a extended sequence number matching what was
sent the last few seconds (3-5) probably needs to be excepted. So actual
bits of entropy may be as few as 8. Here a bad implementation case exist
where the stack start at 0 and work its way up when it is close to 0 bits.

Interarrival jitter: can't be checked and a reasonable low value can be
selected.

last SR: This one contains the middle 32-bits out of the SR's NTP that C
sends. So this is likely based on the system clock. But if the system is
synchronized with an NTP server, then the general range can be guessed.
However, without intercepting the SR packet the time of transmitting the
latest SR is unknown. For a time synchronized sender that transmits only
regular SR reports using AVPF the trr-int will make the attacker aware
of how often new SRs will be transmitted. And initially this field may
be set to 0. So the first few intervals (3-5 * 3-5s = 9-25s) this field
provide 0 protection. After that if one require the SR field to be
correctly filled this field likely contains around 12 bits of entropy
for a known clock base.

DLSR can be set freely by attacker.

The SDES packet provide no protection and it the only other mandated
RTCP packet in a compound.

Thus my estimate is that RTCP in the first 10 seconds, which appears to
be the time interval we are interested can only provide the protection
to the level of difficulty it is to guess the sequence number field
within the range that has been sent the last 5 seconds, which I guess is
in the range of 8-12 bits of entropy.

If you mandate that the Last SR field is non-zero, which may delay the
the verification, allowing for more forward packets (attack packet) to
be sent, then we appear to get 20-24 bits.

I would claim this is to little randomness. It might be okay if one has
a paranoid implementation that clamps down on a stream that gets any
non-consistent RTCP packet. However, I would consider such behavior a
risk for being target of a denial of service attack against a media
stream that has a valid counter part.

I rather have more bits of entropy and continuing to allow a flow as
long as there are reports that are consistent often enough. That makes
the attacker spend resources without any major impact. Thus very little
more amplification than what a straight overload attack causes.

An attacker can also use multiple SSRCs to send its faked receiver
reports with. Thus making it difficult to determine if the one matching
the report is a valid feedback or a series of spoofed packets. Thus it
can also generate a number of guesses against C without invalidating
each sequence of guesses necessary to unlock high rate mode.

What is missing in this analyze is what impact on off-path attackers the
congestion control mechanism and its reports have. However, as they are
likely based on sequence numbers the reporting does not get
substantially more difficult, maybe only the range needed to be hit gets
slightly more compact.


Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------