TURN draft-ietf-behave-turn-09

1
TURNdraft-ietf-behave-turn-09

• Philip Matthews
• Rohan Mahy
• Jonathan Rosenberg

2
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.

3
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)

4
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.

5
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.

6
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.

7
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.

8
Diagram
TURN
3
UDP from self to alloc
Bad Guy
Send to Self w. spoofed 5-tuple
2
NAT

• BadGuy needs to
• Know TURN service IP/port
• Learn reflexive IP/port (on-path)
• Spoof reflexive IP/port
• Learn allocation (on-path or guess)

1
4
Data From BadGuy
Allocate
Client
Client will detect attack Gets data from
unknown peer, unless
9
Without TURN
Bad Guy
NAT

• BadGuy needs to
• Learn reflexive IP/port (on-path)
• Spoof reflexive IP/port

1
4
Data to Peer
Subset of requirementsof previous attack
Client
10
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
11
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

12
Issue IPv6 support

• draft-ietf-behave-turn IPv4 -gt IPv4
  and IPv6 -gt IPv6
• draft-ietf-behave-turn-ipv6 IPv4 -gt 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 -gt 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 -gt IPv6 case
  right now?
• Unclear how much this would delay TURN

13
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

14
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--gtpeer direction
• Plan to add unless someone objects or has a
  better suggestion

15
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

16
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

17
Open Issue Public TURN Server

• Do we need guidance on what it means to run a
  public open TURN server? E.g., dont use long
  term auth?
• Proposal An operational issue dont address