TURN draft-ietf-behave-turn-07

1
TURNdraft-ietf-behave-turn-07

• Philip Matthews, Avaya
• Jonathan Rosenberg, Cisco
• Rohan Mahy, Plantronics

2
What New?

• Two revisions (-06 and -07) since last meeting.
• Long list of changes in each revision.
• See change list in document for details
• For time reasons, will focus on Open Issues
  first, and Major Changes second.

3
IP Header Bits (1)

• New proposal (with JDR, Magnus, Lars)
• Two types of allocations when doing UDP-to-UDP
  relaying
• Fully-compliant
• Preserves ECN, DSCP, DF bits
• Decrements TTL
• Relays ICMP messages (TBD)
• Think RAW sockets or kernel implementation
• Partly-compliant
• Does not do one or more of above.
• Think unprivileged user-space implementation

4
IP Header Bits (2)

• If the client requests a fully-compliant
  allocation (using a new flag in the
  REQUESTED-PROPS attribute), then server must
  reject Allocate request if it can not satisfy the
  request.
• TCP-UDP relaying has less-stringent requirements
  (i.e., something easily implementable in
  user-space).

5
IP Header Bits (3)

• Document will give guidance on when a client
  should use a fully-compliant allocation. For
  example, when app
• Wants to use ECN, or
• Requires a proper DSCP along the entire path,
  or
• Wants to use RFC1191-style PMTUD, or
• Wants to use RFC4821-style PMTUD and needs to
  discover the real MTU
• If RFC4821-style PMTUD is used with a
  partly-compliant allocation, then the value
  discovered may not be the true MTU.

6
ALTERNATE-SERVER (1)

• TURN-05/-06
• Attribute only allowed with 300 Try Alternate
  error response.
• No way to find out what real error code was
• Required positive knowledge condition would not
  occur on alternate server.
• To avoid redirect loops
• TURN-07
• Attribute allowed with any error response.
• 300 Try Alternate is not used.
• Positive knowledge not required. Instead, new
  STUN rules say must wait 5 minutes before trying
  the same server again.

7
ALTERNATE-SERVER (2)

• EKR, Cullen Ditch this just use SRV mechanism.
• Marc P-H
• Dont use for load-balancing.
• Change attribute to contain a domain name (rather
  than an IP address and port)
• Allows the server to dynamically redirect the
  client, as opposed to the SRV mechanism which is
  more static.
• Proposal
• Remove ALTERNATE-SERVER from STUN for now.
• Add later as a enhancement once a well-defined
  mechanism exists.

8
BANDWIDTH (1)

• Proposal for handling BANDWIDTH
• BANDWIDTH attribute specifies a Token Bucket
• Token Bucket Rate
• Token Bucket Size
• Client MAY include BANDWIDTH in Allocate req
• Client includes if it wants a service guarantee
  (e.g., for voice or video)
• Client does not include if it wants best-effort
  service (e.g., for variable-rate data)
• If server cannot provide requested service, it
  rejects the request.
• Server MAY include BANDWIDTH attribute in error
  response specifying service guarantee it could
  provide

9
BANDWIDTH (2)

• Some possible server implementations
• Server provides best-effort service only. Rejects
  requests containing a BANDWIDTH attribute.
• Server provides a simple controlled-load service
  only. Ensures sum of token bucket rates does not
  exceed some max value. No policing.
• Suitable if server trusts clients not to send
  faster than advertized rate.
• (2) Policing each allocation using Token
  Bucket.
• Appropriate if clients might send faster than
  their advertized rate
• Mixing best-effort and controlled-load on same
  server ??

10
BANDWIDTH (3)

• Questions
• As proposed, the BANDWIDTH parameters are
  modelled after IntServs Controlled-Load service.
  Should a different set of parameters be used
  (e.g., RFC 3890 - Bandwidth Modifier for SDP)?
• As proposed, if the client wants controlled-load
  but the server only supports best-effort, the
  request is rejected, and the client must retry if
  it is willing to accept best-effort. Is this a
  problem?
• As proposed, the bandwidth specified is the
  bandwidth on the client lt-gt server connection,
  and is the max of the traffic in each direction.
  It also includes control traffic. Should the
  bandwidth be measured differently?

11
Public TURN Servers

• How do we handle authentication for public TURN
  servers?
• Option 1 Public TURN servers do not use
  authentication.
• Option 2 Public TURN servers use authentication
  client obtains username and password through
  out-of-band mechanism (e.g. user visits a
  webpage).
• Option 3 Dont say anything about how to do this
  in the document.
• Proposal Document will recommend option 2, and
  briefly describe how this could be done.

12
Lifetimes

• Permission lifetime
• 5 min (fixed) refresh by sending data to any
  peer with same IP address OR using empty Send
  indication
• Channel lifetime
• 10 min (fixed) refresh by sending data on
  channel OR rebinding channel to peer
• Allocation lifetime
• 10 min (default client can request a longer
  time) refresh using Refresh transaction

13
Other Changes

• STUN-formatted messages are no longer framed
• Completely reworked the mechanism for binding a
  channel (EKRs proposal)
• Completely reworked the mechanism for requesting
  an even port or a pair of ports (Cullens
  proposal)
• Can no longer request a specific port
• 5-tuples cannot be re-used for two minutes after
  allocation expires.
• Clients must use a different port for a new
  allocation