On Sun, Sep 27, 2009 at 1:13 PM, jc <[email protected]> wrote: > > On Sep 27, 2009, at 12:26 PM, Eric Rescorla wrote: > > Every time you perform an Attach in RELOAD it uses either DTLS or TLS with > STUN to perform ICE connectivity checks(done by TLS/DTLS hand-hake in > ice-lite) towards the remote candidates. Is this fact or fiction? > > It's fact but you're confusing two meanings of the word "with". In this case > tls/dtls is multiplexed with stun over tcp/udp, therefore there is no need > to define stun over dtls. The stun over tls you are pointing to is not used > with ice, but rather for other stun-using applications such as turn > > > I've built out my transports so that the lowest layer is UDP/TCP the next is > DTLS/TLS and the next demultiplexes STUN, RELOAD and APP. In other words > DTLS and TLS are completely transparent to the ICE transport. I don't > demultiplex any TLS or DTLS packets because when the SSL state is acquired > everything else can only be upper layer messages. What you've stated > indicates to me that you may receive a STUN message on the UDP/TCP layer > because you've mentioned having to "multiplex tls/dtls" with stun over > tcp/udp". Does my implementation sound correct to you?
No, this doesn't sound right. The idea here is that ICE provides a fast connectivity check and then you only establish TLS/DTLS connections over the single channel that ICE successfully establishes. If you do things the other way (TLS first, then ICE), then you end up trying to establish a zillion independent (D)TLS connections (which would be really slow even if it worked, which it won't) and then running ICE, which is pointless since you can't establish a (D)TLS connection unless you have two-way connectivity. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
