[R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt

[Harald Alvestrand]

On 03/06/2012 02:26 PM, Varun Singh wrote:
> Hi Harald,
>
> Comment inline.
>
> On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand<harald at alvestrand.no>  wrote:
>> On 03/06/2012 10:21 AM, Varun Singh wrote:
>>>> Security considerations (missing section): For an end node that
>>>> implements
>>>> this specification, an active attacker can cut the transmission by faking
>>>> two RTCP packets that get accepted instead of the recipient's RTCP
>>>> packets.
>>>> This may be worthy of a note, and pointer to appropriate defenses.
>>> This is a valid attack. However, if we consider no early-feedback (the
>>> draft currently only follows RFC3550 timing rules) then the attacker's
>>> second fake report may be ignored by the sender because it is too
>>> early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
>>>
>>>
>>> Example:
>>> SR               |                          |
>>>          |                      I
>>>
>>> ----------------------------------------------------------------------------------------------------------->
>>> time
>>> RR   |                   F          |              F          |
>>>     F              F      |
>>>
>>> | are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP
>>> report). So, instead of waiting for 3 RTCP reports to arrive the
>>> sender MUST wait two RTCP intervals?
>> Yes, I think stating that the sender waits two RTCP intervals before drawing
>> a conclusion is a reasonable defense against this version of the attack.
>>
>> Another interesting version is what happens if the attacker bumps up the
>> "highest sequence number received" - the security considerations may want to
>> say that RRs with a "highest sequence number received" larger than the
>> highest sequence number sent MAY be part of an attack, so SHOULD be
>> disregarded.
> I am not sure if an endpoint reporting a HSN_received larger than the
> HSN_sent trips any circuit breaker, but if the endpoint doesn't ignore
> the report then the endpoint may reset its timeout counter.
What could happen is this:

Victim receiver:RTCP, HSN(low)
Attacker: RTCP, HSN(high)
Victim sender: OK, HSN is (high)
Victim receiver:RTCP,  HSN(low+some)
Victim sender: Oops, HSN did not increase
Victim receiver:RTCP, HSN(low+some+some)
Victim sener: Oops, HSN did not increase for two RTCP intervals. Shut down.

One-packet denial of service.

If HSN is always verified against last-sent, and the report is discarded 
as erroneous if it is higher than last-sent, this attack cannot occur.

>
> A plan for action for the Security considerations can be to list the
> values in the fake RTCP report that can trip a circuit breakers and
> then see how the endpoint can detect or protect against that kind of
> attack.
>
>> But of course, using SRTP on the RTCP channel is also an option for the
>> defender; that allows the receiver to detect that the replays are replays,
>> and discard them for that reason.
> Yes.
>