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

[Varun Singh <[e-mail]>]

Hi Harald,

Comment inline.

On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand <[e-mail]> 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.

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.

-- 
http://www.netlab.tkk.fi/~varun/