Subject: [tram] ALPN identifiers for STUN and TURN

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 31 Jul 2014 17:57:07 +0000

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.

Thoughts?

draft-ietf-tram-alpn-00 currently defines both identifiers.

-Prashanth

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 31 Jul 2014 11:26:19 -0700

I am not sure that having separate ALPNs for STUN and TURN is a very good idea. Both are using the same binary protocol, and both are used in similar situations and the boundary between them is rather artificial. 

Oleg

On Jul 31, 2014, at 10:57 AM, Prashanth Patil (praspati) <[email-masked]> wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jul 2014 11:26:40 -0700

On 31 July 2014 10:57, Prashanth Patil (praspati) <[email-masked]> 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.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 31 Jul 2014 12:02:46 -0700

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

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jul 2014 12:42:02 -0700

> the DTLS flow is in fact carrying TURN traffic.

The only advantage I can think of, and it's probably only theoretical
at best, is to provide the client with a positive indication that the
server consents to engage in TURN.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2014 16:32:33 -0400

> "You are establishing a tunnel to a relay, great, what for?"

I'll also argue that WebRTC is not an application.
It too is just a tunnel (or, if you preferr, transport).

Applications ride on top of it. I guess Meetecho or Webex++ or Skype++ 
would be plausible applications.

Of course this is a constantly changing game. We keep adding layers to 
the stack, and each time we do what used to be an application becomes 
just a transport for the next layer.

But AFAIK WebRTC is *never* an application in its own right.

ISTM that it would be more appropriate if the application identifier 
identified the complete protocol stack that is riding on top of the 
layer that is carrying the identifier.

	Thanks,
	Paul