Subject: [MMUSIC] The floodgates are open

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Oct 2012 14:59:36 -0700

The consent that ICE provides is strictly Boolean.

There is no way to distinguish between consent to receive 4kbps audio
and 5Mbps video.  This creates an exposure for services and endpoints
that support receipt of media, in particular contact centres and other
services that are necessarily open to incoming sessions by default.

This working group has an analogous problem.  The consent to entertain
modifications to ICE did not stipulate any constraints on volume.
Looking to exploit that shortcoming, Bernard and I have submitted a
draft that addresses the protocol shortcoming:

http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00

---

From: Olivier Crête <[email-masked]>
Date: Fri, 12 Oct 2012 18:15:15 -0400

> http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00

I really think you're trying to put this in the wrong layer. SDP already
has b= lines. And WebRTC should also include a congestion control
mechanism which you can probably also use to control/share bandwidth
more dynamically.

-- 
Olivier Crête
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Oct 2012 16:18:41 -0700

On 12 October 2012 15:15, Olivier Crête <[email-masked]> wrote:
> has b= lines.

b= lines are under the direct control of a web-based attacker, the
exact person we trust least in this scenario.

> And WebRTC should also include a congestion control

That would be nice, in theory.  After the RMCAT BoF and reading all
the papers from the IAB workshop on the subject, I did not come away
with a warm fuzzy feeling.  There are methods that are proven to work
for some definition of "work" but all of these assume that the
receiver is at a minimum willing to receive the packets that are being
sent.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Oct 2012 16:25:55 -0700

So, possibly I am completely misunderstanding the state of play here,
but I thought that we had come to the understanding that ICE gave you
a boolean consent *for the length of the consent freshness*  (and that
we could (n theory, at least alter the length of the consent freshness
to handle the risk of voice-hammer style attacks).  In other words,
that boolean exposes you to risk only for the time of the consent
freshness, not for all time, and this mitigated the risk sufficiently.

What have I missed?

Ted

On Fri, Oct 12, 2012 at 2:59 PM, Martin Thomson
<[email-masked]> wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Oct 2012 17:44:25 -0700

A receiver can stop responding to STUN binding requests. However, this will take a while to take effect and it is all or nothing.  With a sender-based congestion control scheme there may not be a way for the receiver to indicate a limit, and even in a receiver-based scheme TMMBR messages aren't acknowledged.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Oct 2012 13:32:58 +0200

> A receiver can stop responding to STUN binding requests. However, this will take a while to take effect and it is all or nothing.  With a sender-based congestion control scheme there may not be a w…
For TMMBR, that's wrong - TMMBR messages are supposed to result in a 
TMMBN being sent, even if the TMMBN shows a bandwidth that is not 
affected by the TMMBR.

RFC 5104 section 4.2.2.2:

    A TMMBN message SHALL be scheduled for transmission after the
    reception of a TMMBR message with an FCI entry identifying this media
    sender.  Only a single TMMBN SHALL be sent, even if more than one
    TMMBR message is received between the scheduling of the transmission
    and the actual transmission of the TMMBN message.  The TMMBN message
    indicates the bounding tuples and their owners at the time of
    transmitting the message.

But I'm not sure it matters in the scenario we're discussing.
Remember that the theory for voice hammer is that we're dealing with an adversary's Javascript running
in the sender's browser, but we're NOT dealing with a compromised browser (or the attacker could just send the
packets without bothering with any of this permission stuff).

If it's needed, it does show a requirement that we might want to carry through to RMCAT (that the recipient
will want to get an ack that the sender has agreed to abide by a certain bandwidth limit).

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Oct 2012 09:25:54 -0700

On 15 October 2012 04:32, Harald Alvestrand <[email-masked]> wrote:
> For TMMBR, that's wrong - TMMBR messages are supposed to result in a TMMBN
> being sent, even if the TMMBN shows a bandwidth that is not affected by the
> TMMBR.

I'm glad that the TMMBR issue was raised.  I considered putting it in
the draft, but decided to keep my layers discrete.

An attacker does not need significant bandwidth in order to have the
RTCP sent to them.  Doubly true if they make it appear as though there
are lots of receivers in the RTP session.

(You might consider this further support for moving to DTLS-SRTP.)

> If it's needed, it does show a requirement that we might want to carry through to
> RMCAT (that the recipient will want to get an ack that the sender has agreed to
> abide by a certain bandwidth limit).

This specific issue was one raised in EKR's submission to the IAB
workshop.  It's a good requirement.  I don't know how realistic it is,
but it's definitely an important thing to try to address.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Oct 2012 09:33:54 -0700

On 12 October 2012 17:44, Bernard Aboba <[email-masked]> wrote:
> A receiver can stop responding to STUN binding requests. However, this will take a while to take effect and it is all or nothing.

With the current timing recommendations, the time between initial
consent and expiration of that consent is greater than 30 seconds
(consent expiration + ICE timers is approximately 35 seconds).  That
may be sufficient time to carry out an attack.