TURN draft-ietf-behave-turn-09 Philip Matthews Rohan Mahy Jonathan Rosenberg

Recent Work on TURN Two new versions -08 and -09 since Philly One conf call on April 8th. Some work on STUN (e.g. SOFTWARE attribute, duplicated responses) which has also affected TURN.

Changes in -08 Removed BANDWIDTH attribute –Was poorly specified; not clear how to fix; not seen as critical to specify now; left to a separate document. Changed REQUESTED-PROPS to contain a set of one-bit flags –Provides an easier way to add new properties; already added new P flag. Preserving vs Non-Preserving Allocations (see next slide)

Preserving vs Non-Preserving Allocations Preserving allocations relay all the secondary IP headers fields (DSCP, TTL, ECN, flow label, fragmentation fields, options/extensions) “correctly”. They also relay ICMP error messages. Non-Preserving allocations relay at least one of these fields “incorrectly” and/or do not relay ICMP messages. Preserving allocations support Path MTU Discovery, QoS, etc. If desired, a client requests a Preserving allocation by setting the P bit in REQUESTED-PROPS. Server may or may not be able to grant request. –Probably requires privileged operations or kernel access to support –Non-preserving allocations can be implemented by an un-privileged application.

Changes in -09 Mostly bugfixes and clarifications. Added ICMP attribute –Needed to support ICMP msg relaying in Preserving allocations Changed codepoint for “Wrong Credentials” error to 441 to avoid conflict with “Stale Nonce” error. If server responds with 508 “Insufficent Port Capacity”, it now includes the REQUEST-PROPS attribute with all supported flags set to 1. Discuss use of new SOFTWARE attribute. –09 calls this “SOFTWARE-TYPE”; will fix in next version. Renamed “RELAY-ADDRESS” to “RELAYED- ADDRESS” for consistency.

Changes in -09 (cont.) Noted that TURN msgs can be demuxed from other messages (.e.g., ICE connectivity checks and RTP or other application data) by checking if source tranport address is the TURN server. Discussed the issue of retransmitted Allocation requests, where the first request fails but the second succeeds. Stated that server MAY remember transmitted failure responses to handle this case. Clarified that is is OK to delete a non-existent allocation. About 13 other changes/clarifications. See list of changes in the document.

Issue: Unauthenticated Permission Refresh Cullen: Concerned that Send indications and ChannelData msgs are not authenticated, but they install or refresh the corresponding permission. –Seriousness of this problem not really known yet.

Diagram NAT TURN Client Bad Guy Send to Self w. spoofed 5-tuple 1 2 Allocate 3 UDP from self to alloc 4 Data From BadGuy BadGuy needs to: 1.Know TURN service IP/port 2.Learn reflexive IP/port (on-path) 3.Spoof reflexive IP/port 4.Learn allocation (on-path or guess) Client will detect attack – Gets data from unknown peer, unless

Without TURN NAT Client Bad Guy 1 Data to Peer 4 BadGuy needs to: 1.Learn reflexive IP/port (on-path) 2.Spoof reflexive IP/port Subset of requirements of previous attack

Solutions Option 1: Do nothing. A concerned client can use TLS to avoid the problem. Option 2: Add DTLS to improve Option 1 – now UDP works securely Option 3: Introduce a Send request/response transaction in addition to the current Send indication. –Can use w/o DATA attribute to install/refresh a permission, or with DATA attribute to install/refresh and send data. –Send indications and ChannelData msgs no longer refresh permissions. –ChannelBind transactions can also refresh permissions (as they do today) Option 4: Clients MUST ignore Data from unknown peers Proposal: Option 4

Preserving Mechanism Introduced in TURN-08 Written/Reads much like an extension – i.e., isolated into its own section Introduces complicated stuff that is hard to implement/understand for the typical app developer Not used/needed by any existing TURN implementation or usage Needs significant review Proposal: –Extract to separate document and proceed independently

Issue: IPv6 support draft-ietf-behave-turn: IPv4 -> IPv4 and IPv6 -> IPv6 draft-ietf-behave-turn-ipv6: IPv4 -> IPv6 Base TURN spec has restriction that the relayed transport address and the 5-tuple must use same address family Some do not like this restriction, especially in the light of NAT64 and similar proposals. Option 1: Keep restriction, and leave split as is. Option 2: Drop restriction, and merge second document into first –Would have to cover details of IPv4 -> IPv6 header translation. Could reference SIIT (RFC 2765) for much of this, but will likely need to tweak details. –How interested are people in IPv4 -> IPv6 case right now? –Unclear how much this would delay TURN

Issue: ALTERNATE-SERVER At last meeting, we agreed to keep ALTERNATE- SERVER in TURN for use in things like anycast discovery of servers. –However, details of anycast discovery are more complex than expected. Possible interim proposal: –ALTERNATE-SERVER allowed in authenticated Allocate responses (only). –Authentication requires 2 round trips. TURN server provider must ensure these two round trips “work”. –One option is to return NONCE and REALM values that work with any server in the group. Alternative: Defer entirely to future extension –Many other protocols that use anycast have not included it in their core protocol definition

Other additions: PMTUD with Non-Preserving Allocations It would be nice to do PMTUD even with a non-preserving allocation Cullen: Could include a flag in a Send indication that says “please set DF bit”. –Only allows PMTUD in client-->peer direction Plan to add unless someone objects or has a better suggestion

Open Issue: Add Channel Number to ChannelBind Response Proposed by Scott Godin – found it helped his implementation Suggest: eliminate any and all feature creep – without clear benefit, skip this

Open Issue: Detecting In-Use Channels Do we need a way to discover whether a channel is currently in use? Suggestion: feature creep – no need

Open Issue: Public TURN Server Do we need guidance on what it means to run a public open TURN server? E.g., don’t use long term auth? Proposal: An operational issue – don’t address