[RTW] STUN and Offer/Answer for media authorization

Bernard Aboba bernard_aboba at hotmail.com
Wed Feb 16 18:02:07 CET 2011


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?



More information about the RTC-Web mailing list