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

[Harald Alvestrand <[e-mail]>]

On 03/07/2012 10:43 AM, Colin Perkins wrote:
> On 7 Mar 2012, at 09:22, Harald Alvestrand wrote:
>
>> On 03/06/2012 02:26 PM, Varun Singh wrote:
>>> 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.
>> 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.
>
> Sure - the Extended Highest Sequence Number received needs to be compared with the sequence numbers being sent. This is also why you can get away with only using two RTCP packets to determine if there's persistent loss: you don't just check that the highest sequence numbers in the packets are non-increasing in isolation, you check that they don't increase to match the sequence number you send.
>
> Maybe the draft need clarifying on this.
Or just make it explicit that this is obvious sense, but not made 
explicit elsewhere.
It's kind of a clarification to RFC 3550 section A.2 - the checks there 
seem to have been written at a time when you did not consider the 
possibility that someone was out to get you...