[RTW] STUN and Offer/Answer for media authorization
Matthew Kaufman
matthew.kaufman at skype.net
Wed Feb 16 18:05:46 CET 2011
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
More information about the RTC-Web
mailing list