On 03/06/2012 10:21 AM, Varun Singh wrote:
Hi Harald,
comments inline
On Tue, Mar 6, 2012 at 09:52, Harald Alvestrand<harald@alvestrand.no> wrote:
[snip!] Thanks for the quick response!
[snip]
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. 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.