1. 1 STUN Changes draft-ietf-behave-rfc3489bis-03 Jonathan Rosenberg Dan Wing Cisco Systems

2. 2 Changes since -02 Magic-Cookie –Determines RFC3489 or RFC3489bis Whether to use XOR or old mapped address –Stolen from transaction ID Branch cookie style from SIP Puts differentiation high up in the message Created ‘usages’ and defined 4 –Binding Discovery (“classic” RFC3489) –Connectivity Check (ICE) –NAT Keepalives (sip- outbound) –Short-Term Password (“classic” RFC3489) Removed attributes to determine NAT type

3. 3 Changes since -02 Clarified 0b00 begins each STUN packet Support for IPv6 Removed text recommending listening for late-arriving STUN responses for 10 seconds –Was an attempt to detect STUN attacks

4. 4 Changes since -02 Moved from TURN to STUN –Magic-Cookie originated in TURN, but found additional value when used in STUN –STUN Indications –Authentication framework Digest –Attributes ALTERNATE-SERVER REALM NONCE

5. 5 Changes since -02 Added BINDING-LIFETIME attribute –Placeholder for configuring stun keepalives easily

6. 6 Open Issue #1: Fate of type- determination attributes NAT type attributes: –RESPONSE-ADDRESS –CHANGED-ADDRESS –CHANGE-REQUEST –SOURCE-ADDRESS –REFLECTED-FROM What should we do with them? –Leave them in RFC3489bis –Back-reference to RFC3489 –Proposal: Create separate ‘diagnostic’ I-D

7. 7 Open Issue #2: TLS Not fully spec’d out on how to determine whether to send or receive TLS Issue raised on list – should we use NAPTR? –This was done in SIP because we needed to have priority across disparate protocols –Not the case here – client knows exactly which it needs (TCP/UDP/TLS) –Need to factor in usages – may want different ports for them Proposal – just SRV –_usage._transport.domain –Stun = binding discovery usage –Backwards compatible and folds naturally into ports per usage

8. 8 Need Help On … Failover behavior –Usage-specific (NAT keepalive behavior is different from connectivity check)