Subject: [tram] STUN over DTLS

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 06 Feb 2014 17:34:17 -0700

After discussion, we decided to more or less restart the draft from a STUN
point of view.  Please find below some thoughts about what we plan to do, so
we can gather comments until the new version of the draft is published
(probably tomorrow afternoon).

First of all, I realized that what I need for my RELOAD draft was STUN over
DTLS, not TURN over DTLS (the plan for the RELOAD draft is to have a STUN
usage to find a unicast address from an anycast address, although now that I
read RFC 7094, I am not so sure that using DTLS is the right choice - but
that's orthogonal to TRAM's work).

So we will rename the draft-petithuguenin-tram-stun-dtls, with probably the
following sections:

2. DTLS as Transport for STUN
3. STUN Usages
3.1 NAT Discovery Usage
3.1.1 DTLS Support in STUN URIs
3.2 Connectivity Check Usage
3.3 Media Keep-Alive Usage
3.4 SIP Keep-Alive Usage
3.5 NAT Behavior Discovery Usage
3.6 TURN Usage
3.6.1 DTLS Support in TURN URIs
3.6.2 Resolution Mechanism for TURN over DTLS

The idea is to go through each standardized STUN Usages and to provide some
guidance when using DTLS.  You'll find below some notes on each of them.

- - NAT Discovery (RFC 5389)

The only information that could be hidden is the XOR-MAPPED-ADDRESS in the
response, but a listener on the path of the request already knows this value
(this is the source IP/port of the request), so there is not much to hide
here.  Also RFC 5389 explicitly discourages authentication for this usage
because of the cost and DTLS is probably more costly than a long-term
authentication (although without having to maintain a password database).  The
only reason would be to be sure that this is the correct STUN server, in case
someone tries to inject STUN responses with an incorrect XOR-MAPPED-ADDRESS.
On the other hand TURN also offers NAT Discovery as part of an Allocation,
which requires authentication, and for the cases that interest us (WebRTC),
having a TURN allocation is pretty much mandatory, so I would say that the
case for DTLS for pure NAT discovery is pretty weak.

This is also one of the Usage that will use a STUN URI, so we may want to say
something about it, similar to what is said about TURN URI.

- - Connectivity check (ICE, RFC 5245)

Using DTLS would permit to hide the USERNAME, PRIORITY, USE-CANDIDATE,
ICE-CONTROLLED and ICE-CONTROLLING attributes.  Because the MESSAGE-INTEGRITY
protects the whole STUN response using a password that is known only by
looking at the SDP exchanged, it is not possible for an attacker to inject
incorrect XOR-MAPPED-ADDRESS (which would subsequently be used as peer
reflexive candidate).  The main issue would be that ICE is slow enough without
adding a DTLS handshake on top of it for each connectivity check.
Interestingly Martin Thomson proposed to use the DTLS handshake that is needed
for DTLS-SRTP to do the connectivity check (draft-thomson-rtcweb-ice-dtls),
but that just prove that, at least in the WebRTC case, we do not want yet
another handshake.

This usage has no need for a STUN URI.

- - Media Keep-alive (ICE, RFC 5245)

This keep-alive method uses Binding Indication, so there is really nothing to
hide or protect here.

This usage has no need for a STUN URI.

- - SIP Keep-alive (RFC 5626)

The keep-alive described in RFC 5626 is for SIP, so it is done in the
same flow (using Binding Requests, not Binding Indications).  If SIP is using
DTLS (draft-jennings-sip-dtls, which seems to never have been standardized),
then the STUN transactions are running inside DTLS, so no additional DTLS
layer is needed.  If SIP is using UDP, then the STUN transactions cannot use DTLS.

This usage has no need for a STUN URI.

- - NAT Behavior Discovery (RFC 5780)

There is probably some value in using DTLS here, like for the NAT Discovery
Usage, but this usage is experimental and AFAIK not deployed.

The STUN URI can be used to access the NAT discovery feature of a NAT Behavior
Discovery server, but accessing the full features would probably require to
define a "stun-behaviors:" URI, which is out of scope for this draft.

- - TURN (RFC 5766 - which is both a STUN Usage and because of the channel
mechanism, a STUN extension)

The reasons for doing this are already explained in the draft (HOL blocking,
latency).

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug