Re: [tram] ALPN identifiers for STUN and TURN

[Martin Thomson <[e-mail]>]

On 31 July 2014 10:57, Prashanth Patil (praspati) <[e-mail]> wrote:
> There was some discussion on the need for separate STUN and TURN identifiers
> during the TRAM session. Separate identifiers could be useful when middle
> boxes such as a firewall want protocol identification e.g as described in
> http://tools.ietf.org/html/draft-hutton-httpbis-connect-protocol-00#section-1.

I raised this concern previously, and it has been bothering me
somewhat.  I'll try to make this a little clearer, and apologies for
the rambling post.

The application that you are using is what matters in this context.
That's why we have ALPN identifiers for WebRTC.

Identifying as TURN or STUN isn't as useful, particularly when it
comes to enforcing policy, because they are effectively blank cheques.
"You are establishing a tunnel to a relay, great, what for?"

For the server that terminates TURN over DTLS identifying TURN is
useful.  It means that the TURN server doesn't have to know about
"webrtc" and all the other potential uses of TURN in order to
determine that this is a client that wants to talk TURN (and not some
other strange protocol).  After all, when you talk TURN over DTLS, the
server you talk to is talking TURN.

TURN in the clear with DTLS inside is a no brainer, you always
identify that as something other than TURN at the DTLS layer.

STUN on the other hand, when used in the peer-to-peer sense, doesn't
work that way.  You know about "webrtc" or whatever other application
protocol you might be using.  You can identify the actual application
protocol.  I don't think that we need an identifier for STUN at all.

The only question I have then is what you do for TURN over DTLS.  In
the draft-hutton- sense, as well as in the DTLS ClientHello.  I've
been saying now for a while that these two points should include the
same information, but it might make sense to have the real usage
(e.g., "webrtc") visible to both proxy and TURN server.

Or, we could consider the case of TURN over DTLS as a measure that
intentionally protects the usage from intermediaries, and explicitly
not include information about what might be carried inside of this
tunnel.  After all, the primary security advantage provided by TURN
over DTLS is protection of meta information about what tunnels are
being created to where.