1. TURN -01 Changes and Issues Rohan Mahy rohan@ekabal.com BEHAVE at IETF66 - Montreal

2. Lightweight TCP Framing Added in this version of the draft (#2) Rohan assumed this needs to run on the same port as regular STUN, so.. –consistent with text about the usage –Client can send to server anytime –Server only uses it once an active destination has been set JDR assumed we would demux on port –consistent with separate SRV records This is requirements question. Lets pick something.

3. Connect Request Mistakenly removed (#3) Will be added back Needed for case when TURN server is used for policy reasons (you can only connect to outside through a specific TURN server)

4. Connection Status Indication (#5) Needed for forking case if a connection for a single fork dies Also nice to have to tell if connection dies, but you still want to talk to TURN server over the same port. Always sent reliably now

5. More Changes TCP relayed to peer only if connection from TURN client reliable (#1) –UDP to UDP, TCP to TCP/UDP, TLS to TCP/UDP Now allowed to “refresh” my allocation even if my source address has changed. Convenient if I detect that my NAT reboots. (#6) Rewrote Overview (#7) Motivated odd/even port alignment options (#8) use REMOTE-ADDRESS in place of DESTINATION-ADDRESS (#9) use XOR-MAPPED throughout (#10)

6. Explicit OpenBinding / CloseBinding requests (#11, #B) ISSUE: If you are forking, would like to squelch data from one fork of many Added a CloseBinding request for this purpose. –Do we want one of these? Also added an explicit OpenBinding request for completeness (open a binding without issuing a Send) –Do we need this? Proposal: Keep CloseBinding, remove OpenBinding X

7. Set Active Destination states (#A) Currently document has a state machine for client and server to prevent client from being confused. Proposal in document to eliminate the server state machine in favor of client-enforced timer. If the client screws up, only the client is impacted –Proposal in draft doesn’t allow swap from one fork to another if I want to keep the old flow. Do we need this? Alternatively, Set Active Destination with no REMOTE-ADDRESS, wait, Set Active Destination with new active address X

8. Doors / Lockdown (#4) Was concept in previous versions of TURN Initial allocation can ask for the “door” property. Creates a binding for first datagram/TCP SYN received at door, then closes the door. –still can’t run real server: can’t ask for specific port, can’t get well- known port, can’t add a door to existing binding/allocation –still allows additional explicit bindings with Send / Connect / OpenBinding Why? Allows peers to optimize down to a single TURN relay in some cases (no forking). Also useful for interop with non- ICE peers Issue: Port scanner can easily “lockout” the real peer, but with ICE, the client can still communicate through 2 TURN relays Do we want this concept?

9. Keepalive via Data or STUN? (#C) Currently draft only refreshes allocations based on STUN messages. Data does not refresh allocation/binding timers (a change from last time). Is this OK? Proposal on list to separate allocation timer from binding timers. –Keep one timer –Split into allocation (set by STUN) and binding timers (set by Data?)