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

From: Colin Perkins <[email-masked]>
Date: Mon, 5 Mar 2012 23:32:47 +0000

Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.

Colin

Begin forwarded message:
> From: [email-masked]
> Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
> Date: 5 March 2012 20:17:59 GMT
> To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : RTP Congestion Control: Circuit Breakers for Unicast Sessions
> 	Author(s)       : Colin Perkins
>                          Varun Singh
> 	Filename        : draft-perkins-avtcore-rtp-circuit-breakers-00.txt
> 	Pages           : 14
> 	Date            : 2012-03-05
> 
>   The Real-time Transport Protocol (RTP) is widely used for telephony,
>   video conferencing, and telepresence applications.  These
>   applications are often used over best-effort UDP/IP networks.  If
>   congestion control is not implemented then network congestion will
>   deteriorate the user's multimedia experience.  This document does not
>   propose a congestion control algorithm.  Instead, it specifies a
>   minimal set of "circuit-breakers".  Circuit-breakers are conditions
>   under which an RTP flow should cease to transmit media to protect the
>   network from excessive congestion.  It is expected that all RTP
>   applications running on best-effort networks will be able to run
>   without triggering these circuit breakers in normal operation.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt

-- 
Colin Perkins
http://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 06 Mar 2012 08:52:58 +0100

>> 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?
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.

Good stuff!

                      Harald

---

From: Varun Singh <[email-masked]>
Date: Tue, 6 Mar 2012 11:21:08 +0200

Hi Harald,

comments inline

On Tue, Mar 6, 2012 at 09:52, Harald Alvestrand <[email-masked]> wrote:

[snip!]

> 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
> 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/

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 06 Mar 2012 10:51:49 +0100

On 03/06/2012 10:21 AM, Varun Singh wrote:
> Hi Harald,
>
> comments inline
>
> On Tue, Mar 6, 2012 at 09:52, Harald Alvestrand<[email-masked]>  wrote:
>
> [snip!]
Thanks for the quick response!

[snip]
> early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
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.

---

From: Varun Singh <[email-masked]>
Date: Tue, 6 Mar 2012 15:26:47 +0200

Hi Harald,

Comment inline.

On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand <[email-masked]> wrote:
>>> implements
> 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.
>
> "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.

> defender; that allows the receiver to detect that the replays are replays,
> and discard them for that reason.

Yes.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 6 Mar 2012 22:22:49 +0000

On 6 Mar 2012, at 07:52, Harald Alvestrand wrote:
> do I cease transmission after packet 3 has arrived, or after packet 2 has arrived?
> 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".

We should clarify. My feeling is that either way would work, depending on how aggressive we want the circuit breaker to be. 

> 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.)

Sure, will clarify. 

> 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.

Yes.

> 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.

Agreed.

> Good stuff!
> 
>                      Harald
> 
> 
> 
>  
> 
> 
> _______________________________________________
> Rtp-congestion mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion

-- 
Colin Perkins
http://csperkins.org/

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Mar 2012 17:16:31 -0600

Colin

I'm curious about this RTP extension for the cases in which DiffServ 
is actually used, but there's more load than capacity to serve the DS node(s)?

What happens then?

Also, in the fairly rare case that reservations are used, many times 
RTCP feedback will be used to invoke or cause a source to reduce 
resolution or to otherwise change audio codecs, which can be planned 
for *without* the need for this circuit breaker mode of just cease 
transmitting.

Would you be relying on the application at each end to know the 
difference as to whether that endpoint is within a BE network, a DS 
network that's congested or a network that uses (say) reservations, 
but still experiences problems?

James

At 01:52 AM 3/6/2012, Harald Alvestrand wrote:
>>Here's our initial attempt at a "circuit breakers" draft for 
>>RTCWeb. Comments welcome - this is very much a straw-man for 
>>discussion, rather than a final solution.
>>
>>Colin
>>
>>
>>
>>Begin forwarded message:
>>>
>>>From: <mailto:[email-masked]>[email-masked]
>>>To: <mailto:[email-masked]>[email-masked]
>>>Reply-To: <mailto:[email-masked]>[email-masked]
>>>
>>>
>>><http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt>http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>>
>>
>Thanks for this work!
>
>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".
>
>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.
>
>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.
>Good stuff!
>
>                      Harald
>
>
>
>
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Mar 2012 10:22:08 +0100

On 03/06/2012 02:26 PM, Varun Singh wrote:
> Hi Harald,
>
> Comment inline.
>
> On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand<[email-masked]>  wrote:
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.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 7 Mar 2012 09:43:46 +0000

On 7 Mar 2012, at 09:22, Harald Alvestrand wrote:

> 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.

-- 
Colin Perkins
http://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Mar 2012 11:38:40 +0100

> 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...