Re: [tram] ALPN identifiers for STUN and TURN

[Justin Uberti <[e-mail]>]

On Thu, Jul 31, 2014 at 11:26 AM, Martin Thomson <[e-mail]>
wrote:

> 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.
>

Agreed. While one could certainly do STUN over DTLS, it's not clear why one
would want to do so. That said, it should work, and so I don't have an
issue with defining an ALPN for STUN.

>
> 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.
>
> Clearly the local proxy cares to distinguish between 'http' and 'webrtc',
but that is handled by the HTTP CONNECT ALPN, and not any DTLS ALPN.

It's not clear to me that a DTLS ALPN would be that useful for at the TURN
server - it already knows it is getting TURN traffic. The primary advantage
of a DTLS ALPN would seem to be for local DPI firewalls to understand that
the DTLS flow is in fact carrying TURN traffic.