[tram] STUN over DTLS

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJS9CoHAAoJECnERZXWan7EQfIQALbS2UhQ35zvd4RnvBWr0xvm
2fmNjPRbgMHoIjezUmY2C4qac9evPWqj4HiLhSRLhX0pnXHHK7uH671vCeUzmm1j
bo+x+kS6ohg/UIWTCgevdo3moggYtWDzYro4qtGDyUPbo6f7ZTPg6hcffGsxHKhU
xv/Dif9GwHVfHAfQitYYHeCgXS4rB7ejOhpvHksIU9vTnh+RcCMmkDB7puBNtuVs
cAR7oGeuicg8BGsgiriXlIBxzgWAPB/uK08Vp4uq0x6xTVn+sjWU+ICFLtOMeKQi
SluXJF656v08YweqpyrUB3FIH1qVm7r2vffP4Oiidgk660tKt6mNNvqf+4/E4pzx
w0JE5k6K9dLIrAAUxuG0DlY2RMPBaSYmhRyeq3ci+LlQbeBXEzKjFFc0tTEzQQH3
Hk8xbzh+wm4YOm6oCzIsVilnr3CvfiQxccAjqlpOxLjOsrl05WKKvmxt5qbzt+CA
otr+Zlm87dkp/FhVyyVRoqXcCfpVmiy2S9jVV/1DhLbMpFOWz6Z5hSo1IXGenKmH
XkzXyP3bWhpTdeNSLY95jtYbDBXYY88TfBDAkKcDrzQ5qtgBamMY/xYmNmgmYxC7
2tqhGl0PUJ15mJ4cJUaERAXQD8MHOxUDL/FbqrKVth1co3niWk6doxbpTZM8TG6A
BWiTZOq1/SUT63FdEwDS
=fzTX
-----END PGP SIGNATURE-----