Subject: [MMUSIC] ice: stun over tls or not?

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 6 Dec 2007 15:48:49 -0800

I'm concerned about what may be a conflict or possibly just a
significant point of confusion over the relationship between STUN and
(D)TLS when used with ICE.  Basically, do you run STUN over (D)TLS or
is it run over the raw (UDP/TCP) transport before (D)TLS handshaking
is begun.

- 3489bis-13 7.2.2 for TLS/TCP requires that TLS be established before
sending a stun message that is encoded on the TLS connection
- ice-19 does not say anything about DTLS/UDP
- ice-tcp-05 sec 2 and 5.1.1 say that when doing ICE for TLS/TCP or
DTLS/TCP use 4571 to frame stun outside the (D)TLS connection.  The
4571 shim is explicitly specified as being used regardless of whether
the application is rtp media or something else entirely.

I think there is some question as to whether these are in actual
conflict or merely confusing, but my concerns are:
- 3489bis shouldn't specify a MUST that is overridden by a stun usage
- it makes no sense to require non-media/rtp applications to implement
the 4571 shim

I would like to propose the following:
- change 3489bis 7.2.2 (and possibly at a higher level) to specify
MUST "unless the particular STUN usage specifies a different layering"
- change ice-tcp to specify that the 4571 shim MUST be used for
media/rtp, and that other protocols MUST specify an equivalent method
for demultiplexing or specify how the application is demultiplexed
from STUN messages if no shim is required.
- I don't see a strong motivation in other applications using ICE to
require that stun be layered beside (D)TLS rather than on top of it.
Maybe I'm missing something, but if you don't need that type of
construct already (such as DTLS-SRTP over TCP needs it), it seems to
add a lot of complexity.  I would like applications to be able to
specify that STUN is running on top of (D)TLS.

I really wish that DTLS/UDP could be addressed somewhere, but I don't
know if any of the current drafts are appropriate.  If the material
currently in draft-bryan-p2psip-reload-02 is going to be pulled out
into a separate draft, maybe it could go there?

Bruce

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic