Presentation is loading. Please wait.

Presentation is loading. Please wait.

TURN Jonathan Rosenberg Cisco Systems. Changes since last version Moved to behave terminology Many things moved into STUN –Basic request/response formation.

Similar presentations


Presentation on theme: "TURN Jonathan Rosenberg Cisco Systems. Changes since last version Moved to behave terminology Many things moved into STUN –Basic request/response formation."— Presentation transcript:

1 TURN Jonathan Rosenberg Cisco Systems

2 Changes since last version Moved to behave terminology Many things moved into STUN –Basic request/response formation and transactions –Digest authentication –Magic cookie –Alternate server/300 resp –Reads as a stun usage Authentication – can now use regular digest for Allocate –No need for shared secret request Set Active Destination sections rewritten and clarified with state machine Unified TCP and UDP treatment of set active destination –Now can send subsequent TURN signaling in TCP case Send is an indication, not a request Allow set active destination even if you never sent data there

3 Changes MAPPED-ADDRESS is server reflexive Added RELAY- ADDRESS for relayed address Can request specific port properties –Specific port –Port parity –Contiguous port request hints Can ask for specific IP address –Needed for ICE tcp Can ask for a specific transport protocol –Allows UDP/TCP conversions (TLS too from client) –No traffic shaping in conversion Permissions set on send and set active destination

4 Changes New Connect request for opening TCP connections –Used to be coupled with sending data –Send is now unreliable –Need to know if connection setup succeeds TCP connections NOT opened from ephemeral ports –Opened from allocated port –Allows simultaneous open Closures of tcp connections from external host do not release allocation –Because you can open multiple connections from an allocated address –Couldn’t do that before Allocated lifetimes refreshed by Allocate request ONLY, not data –Allows separation of TURN and data processing –Possible now since TURN can run over TCP once connection setup

5 Changes Hokey mechanism for dealing with connection setups that take longer than STUN transaction –Get a tentative response, need to try Connect again later Added long overdue example Update to overview of operation

6 Open Issue #1: Disambiguation Magic cookie allows to know that a message is STUN/TURN But, in the case of TURN – is this for ME or for downstream element? –STUN connectivity checks through TURN server Proposal: New header that contains IP address of server that is the target –Specific to TURN – would be in TURN draft

7 Open Issue #2: XOR encoding of other addresses Should other addresses besides MAPPED-ADDRESS be xor encoded? Proposal: NO –Not needed – nasty NATs look for their own address

8 Open Issue #3: Allocation Identification Today, incoming Allocate request is mapped to an allocation based on incoming ‘flow’ –Not through an explicit identifier Whats the problem? –NAT reboot followed by refresh – will not refer to previous allocation Proposal –Subsequent turn signaling includes IP/port of allocation to identify allocation –If refresh comes over new ‘flow’, update mapping of that allocation to the ‘flow’

9 Open Issue #4: Demux over TCP Server needs to look at magic cookie to differentiate (bytes 5-8) However, server doesn’t know framing protocol –Unlike ICE usages and sip-outbound Spec doesn’t say how to actually do demux when you don’t know framing protocol Options –Signal the framing – requires TURN server to support various app framings (YUCK!!) –Do the cookie hunt and use timers for buffer release of data (ICK!) –Always use Send and Indication – no unencapsulated data (EGADS!) –Define a new lightweight demux for TURN (32 bytes will suffice) (HMM…)

10 Lightweight Demux Idea 32 bits – 8 bit type, 24 bit length Two types defined: –STUN –Data Use for TCP and UDP –Avoids need for cookie check for UDP data as well – more important for turn than other usages Always use this

11 Open Issue #5: 32 bit alignment TURN tries to keep all attributes 32 bit aligned But DATA can be arbitrary byte lengths – what to do? Proposal: –Length refers to length of data, but if its not a multiple of 4, padding is added to the end of the actual data –Would need to be described in STUN itself

12 ToDos IANA registrations Terminology still needs some work Usage of authentication with turn Redo IAB considerations based on updates Update of security considerations – need to think about lack of integrity/security on data stream Clean up MAPPED-ADDRESS vs. XOR-MAPPED Add discussion on usage of alternate server


Download ppt "TURN Jonathan Rosenberg Cisco Systems. Changes since last version Moved to behave terminology Many things moved into STUN –Basic request/response formation."

Similar presentations


Ads by Google