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

[Varun Singh]

Hi Harald,

comments inline

On Tue, Mar 6, 2012 at 09:52, Harald Alvestrand <harald at alvestrand.no> wrote:

[snip!]

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>
> Thanks for this work!
>
> A few questions (to make sure I get them noted down):
>
> Section 4.1:
>
>    Accordingly, if a
>    sender of RTP data packets receives two or more consecutive RTCP RR
>    packets from the same receiver that correspond to its transmission
>    and have a non-increasing extended highest sequence number received
>    field, then that sender SHOULD cease transmission.
>
> If I see RTCP packets with
>
> 1: highest sequence number = 2
> 2: highest sequence number = 2
> 3: highest sequence number = 2
>
> do I cease transmission after packet 3 has arrived, or after packet 2 has
> arrived?

After 3. The idea is for the sender to wait for two RTCP intervals
(which corresponds to two additional reports).
for the reported HSN to increase.

Example:
SR               |                              |
        |                     X
      ----------------------------------------------------------------------------------------------------------->
time
RR   |                              N                              N
                           N

The N are RTCP RRs that carry the same HSN value. X means terminate session.

We could clarify this in the next iteration.

> I *think* the logical time is after packet 3 has arrived, but I'm a little
> unsure that the words are
> unambiguously saying that; it's not 100% clear to me whether packet 1 is
> considered included in the set of "non-increasing highest sequence number".
>
> Section 4.2: Is it reasonable to replace, for the purposes of this
> calculation, "an order of magnitude" with "a factor of ten"? (for those who
> don't have a physics background, putting text somewhere that says that an
> order of magnitude is "somewhere around a factor of ten" might be
> appropriate.)
>
> We might also want to add the words about doing a dramatically reduced rate
> if we can from section 4.1 here, factor it out as a general statement, or
> say that it is not appropriate here if it's not.
>
> 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?


Cheers,
Varun

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