Subject: Re: [tram] ALPN identifiers for STUN and TURN

From: Brandon Williams <[email-masked]>
Date: Fri, 01 Aug 2014 09:17:37 -0400

I can see a potential benefit in allowing the server to avoid DTLS 
handshake overhead in the case where it doesn't consent to engage in 
TURN. I have a hard time seeing how this might come into play though. If 
it's not a TURN server, why was the client sent to that address in the 
first place? If it's illegitimate traffic, the bad actor can circumvent 
the advantage for the server by not sending ALPN at all, right? That 
leaves the case where it is a TURN server but it's already in a resource 
exhausted state. If it can't handle more allocations, knowing that the 
client will be asking for one could allow the server to minimize 
unnecessary DTLS overhead for a session that it can't support anyway.

--Brandon

On 07/31/2014 03:42 PM, Martin Thomson wrote:
> On 31 July 2014 12:02, Justin Uberti <[email-masked]> wrote:
>> 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.
>
>
> 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.
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Brandon Williams <[email-masked]>
Date: Fri, 01 Aug 2014 09:38:32 -0400

I've got a small concern about allowing STUN over DTLS, since it 
challenges some elements of the STUN security analysis from the RFC. In 
particular, there is the assumption that "STUN requests can be processed 
statelessly by a server, making such attacks hard to launch." If STUN is 
sent over DTLS, then the DTLS processing itself is stateful on the 
server side, and so STUN implementers probably need to take that into 
account when implementing STUN-over-DTLS. RFC5389 is a bit inconsistent 
in this regard, IMO, since it includes both the above statement about 
stateless processing and the suggestion that some attacks can be 
mitigated through the use of TLS.

This concern isn't directly related to the ALPN discussion, though, 
since ALPN doesn't make it either better or worse.

--Brandon

On 07/31/2014 03:02 PM, Justin Uberti wrote:
> 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.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 4 Aug 2014 12:43:06 +0000

Right, the intent was that it could be useful for a firewall to identify a (D)TLS flow as TURN traffic, especially when sent over 443.

-Prashanth

From: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 1, 2014 12:32 AM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: Prashanth Patil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] ALPN identifiers for STUN and TURN

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: Mon, 4 Aug 2014 11:36:01 -0700

On 4 August 2014 05:43, Prashanth Patil (praspati) <[email-masked]> wrote:
> Right, the intent was that it could be useful for a firewall to identify a
> (D)TLS flow as TURN traffic, especially when sent over 443.

Note however that this is nearly information-free.  A TURN binding can
be used for literally anything.