Re: [MMUSIC] The floodgates are open

[Harald Alvestrand <[e-mail]>]

On 10/13/2012 02:44 AM, Bernard Aboba 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 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.
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).

>
> On Oct 12, 2012, at 16:25, "Ted Hardie" <[e-mail]> wrote:
>
>> 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
>> <[e-mail]> wrote:
>>> 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
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic