Re: [MMUSIC] The floodgates are open

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.

On Oct 12, 2012, at 16:25, "Ted Hardie" <ted.ietf@gmail.com> 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
> <martin.thomson@gmail.com> 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
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic