70 likes | 248 Views
DTLS-ICE. draft-thomson-rtcweb-dtls-ice-00. Exchanging signaling is hard, but it’s the quickest part of session setup Collecting candidates, connectivity checking, candidate nomination, DTLS handshake. Latency optimized. If you like latency, great! Ship it.
E N D
DTLS-ICE draft-thomson-rtcweb-dtls-ice-00
Exchanging signaling is hard, but it’s the quickest part of session setup • Collecting candidates, connectivity checking, candidate nomination, DTLS handshake
Latency optimized If you like latency, great! Ship it. Setup times on intercontinental calls ~1-2s Thanks to Dan and EKR who noted the flaws in this flow and spoiled a great argument with their “technically you don’t need to ask for a cookie” blahblah Layering is great… until you decide to optimize 76 RTT
Neat layering is for chumps • Overload the 2RTT STUN connectivity check semantics on the 2RTT DTLS handshake • Check: s/STUNBinding/DTLSClientHello&ServerHello/ • Nominate: s/STUNBinding/DTLSFinished&Finished/ • Username fragment(s)/password packed into the cookie: • prevent/mitigate DoS • provide verification of consent • Remove two round trips
Faster? How much? • DTLS depends on saving the handshake messages • Multiple handshakes started, only one completes • Not that much extra state over what ICE maintains 4 RTT
Other things • Consent freshness can just use (D)TLS heartbeat [RFC 6520] • Mandate support of heartbeats and prohibit the use of peer_not_allowed_to_send • Dealing with some NATs can be helped by gathering peer reflexive candidates • Just use STUN for that, but in parallel