[RTW] STUN and Offer/Answer for media authorization

[Matthew Kaufman]

I believe it is sufficient that the browser rate-limit the STUN connectivity checks.

That requirement was lost in editing.

Matthew Kaufman

(Sent from my iPhone)

On Feb 16, 2011, at 7:02 PM, Bernard Aboba <bernard_aboba at hotmail.com> wrote:

> The "Architectural Framework" document
> (http://tools.ietf.org/html/draft-rosenberg-rtcweb-framework) states in
> Section 4:
> 
>   To avoid this attack [voice hammer], a simple handshake can be utilized.
> The
>   browser should support a simple STUN-based [RFC5389] connection
>   handshake.  The exchange of the STUN transaction ID prior to
>   transmission of media prevents the attack.
> 
> While the exchange of the STUN transaction ID demonstrates that the target
> supports STUN, and therefore might be argued to be a necessary condition for
> transmission of media, is it sufficient condition?
> 
> For example, if the STUN transaction ID is all that is needed to authorize
> transmission of media (e.g. no offer/answer required), then couldn't
> malicious Javascript be used to DoS a STUN server?  If offer/answer is also
> required, how is this handled? 
> 
> The point has been made that the browser should be agnostic with respect to
> signaling protocols.  A corollary of this is that the browser is agnostic
> with respect to a particular offer/answer protocol mechanism (e.g. SIP with
> SDP exchange, Jingle, etc.).  However, Justin has made the point about the
> usefulness of a JSON format for expressing the offer/answer exchange.  
> 
> In addition to the STUN transaction ID, should the answer (e.g. in JSON
> format) be considered a pre-requisite for media authorization?
> 
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web