1 / 47

Bridging the gap. NAT traversal and peer communications

Bridging the gap. NAT traversal and peer communications. Introduction. Don't worry about notes - everything is available on a CD at the end of lecture Simple example client/server provided Pure C implementation, easily portable Least code possible Performs TCP and UDP hole-punching

cyrah
Télécharger la présentation

Bridging the gap. NAT traversal and peer communications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Bridging the gap. NAT traversal and peer communications

  2. Introduction • Don't worry about notes - everything is available on a CD at the end of lecture • Simple example client/server provided • Pure C implementation, easily portable • Least code possible • Performs TCP and UDP hole-punching • Includes slides and lecture text • Includes STUN client and UPNP explorer • Includes reference material (RFC's, etc) • Includes list of links to online resources • Please save questions until the end of talk • Do take notes on these, they're obviously not on the CD :)

  3. About Me • Spent the last few years working on P2P software – but not piracy P2P :) • Technical due diligence for Film Finances Inc (completion bonding company) when evaluating game companies • Contract work back in the day for Sega, 3DO, Spectrum Holobyte, etc.

  4. Talk Objectives • When finished, you should have • A good understanding of the current state of NAT usage. • A sense of the strengths and weaknesses of different techniques of traversing a NAT. • All reference material necessary to develop your own implementation. • An understanding of the common problems encountered when implementing a solution. • Source code to a functional example :)

  5. Terms • Private • Internal IP address (typically issued by NAT) • Public • NAT box public Internet IP address • Remote • Internet IP address of other system • Rendezvous • Internet IP address of server to negotiate communications (ex; SIP, etc) • Hole-Punch • Establish a connection through a NAT

  6. NAT Overview • Used by almost all users as gateway to Internet • Allows multiple machines to share single IP • Gives limited firewall functionality • Performance

  7. NAT vs Firewall • Firewall • Most common in corporate settings • Primary focus typically security • Default action is typically implicit deny • Complex rules • Sometimes used in conjunction with Socks/Proxy server • NAT • Typically used by end users and small businesses • Simple to configure • Default action is typically implicit allow • Rewrites source addr, destination addr, checksum, etc

  8. NAT Flavors • Defined in RFC2663 • Outbound NAT (most common) • Sometimes called Basic NAT or NATP • Sessions only initiated by Private IP • Bi-Directional NAT • Sessions initiated by Private or Remote IP • Requires use of DNS_ALG • Twice NAT • Used where Remote and Private IP’s overlap • Multihome NAT • Uses more than one physical link

  9. NAT Performance concerns • IP modification requires IP header checksum calculation • Port modification requires TCP checksum calculation • More active connections require more memory/state tracking • Some NAT's modify UDP contents (gamer mode)

  10. Types of NAT's • Defined in RFC3489 (STUN) • Full Cone • Restricted Cone • Port Restricted Cone • Symmetrical • Hair-pinning

  11. Full Cone • Least restrictive type of NAT • Similar in use to port mapping or port triggering • All requests from same Private IP/port mapped to the same Public IP/port • Any remote host can contact Private IP/port by contacting mapped Public IP/port

  12. Full Cone Hole-Punch • Private host contacts Rendezvous server, reports available • Remote host contacts Rendezvous server, requests IP/port of Private host • Rendezvous server returns Public IP/port to Remote host • Remote host attempts to contact Public IP/port • Remote IP/port mapped to Private IP/port

  13. Restricted Cone • Slightly more restrictive than Full Cone • All requests from same Private IP/port mapped to the same Public IP/port • Only Remote IP’s that Private has contacted before can use mapped Public IP/port

  14. Restricted Cone Hole-Punch • Private host contacts Rendezvous server, reports available • Remote host contacts Rendezvous server, requests IP/port of Private host • Rendezvous server returns Public IP/port to Remote host • Rendezvous server directs Private host to contact Remote IP/port • Remote host attempts to contact Public IP/port • Private host attempts to contact Remote IP/port • Remote IP/port mapped to Private IP/port

  15. Port Restricted Cone • Most restrictive type of NAT that still can be trivially traversed • All requests from same Private IP/port mapped to the same Public IP/port • Only Remote IP/port that Private has contacted before can use mapped Public IP/port

  16. Port Restricted Cone Hole-Punch • Private host contacts Rendezvous server, reports available • Remote host contacts Rendezvous server, requests IP/port of Private host • Rendezvous server returns Public IP/port to Remote host • Rendezvous server directs Public host to contact Remote IP/port • Remote host attempts to contact Public IP/port • Private host attempts to contact Remote IP/port • Remote IP/port mapped to Private IP/port

  17. Symmetrical • Most restrictive type of NAT • Cannot be realistically traversed • All requests from same Private IP/port to a specific Remote IP/port mapped to the same Public IP/Port • Only Remote IP/port that Private host has contacted before can use mapped Public IP/port

  18. Standards Overview • STUN • SIP • TURN • ICE

  19. STUN • Defined in RFC3489 • Simple protocol • Widely used, many free public servers • Identifies Public IP address of user • Can reliably identify type of NAT device • Can reliably identify lifetime of mapping • Limitations • UDP only (TCP in the works) • Can be time consuming depending on type of NAT and test performed • Requires public server with two IP addresses

  20. SIP • Defined in RFC3261 • HTTP-like formatting (mostly) • Focused on brokering connections between clients (mostly) • Widely used, many free public servers • Many client and server implementations • ISP’s unlikely to filter/shape due to typical type of traffic (ie; VOIP) • Limitations • Has problems working with NAT (why ICE was created) • Not that simple to implement

  21. TURN • Defined in IETF Draft • At it’s core, just a relay server • Similar to SOCKS5 • Allows communications between clients when neither can be hole punched

  22. ICE • Defined in IETF Draft • Collection of protocols and methodologies • Designed to be transparent to NAT • Unlike UPnP, never directly interacts • STUN for NAT identification • SIP/RDP for connection negotiation • UDP hole-punching for establishing link • TURN used if hole-punching not possible

  23. NAT Traversal Overview • Connection Reversal • Relay (TURN) • Proxy • Socks • Port forwarding • UPnP • NAT-PMP • UDP Hole-Punch • TCP Hole-Punch

  24. Connection Reversal • Advantages • Works in every situation • Works with any protocol • Disadvantages • Requires one peer to be publicly accessible

  25. Relay • Advantages • Works in every situation • Can be designed to mimic other protocols • Not effected by multiple NAT boxes • Not effected by NAT type • Disadvantages • All traffic is routed through relay server • Single point of failure • Requires significant infrastructure for large scaling

  26. Proxy • Advantages • Looks like HTTP traffic • Works in situations where no other method does • Relatively simple in implement • Easily detected by checking browser settings • Disadvantages • Requires two connections for bi-directionality • Only works with TCP • Not common in consumer deployments • May require authentication • If autoconfigured, may use Javascript

  27. SOCKS • Advantages • Works with arbitrary protocols • Supports both TCP and UDP • Supports inbound requests • Relatively simple to implement • Easily detected by checking browser settings • Disadvantages • Not common in consumer deployments • Not common in corporate deployments either • May require authentication • May be configured to not allow inbound • If autoconfigured, may use Javascript

  28. Port Forwarding • Advantages • Best way to guarantee availability short of being public • Supported on virtually every router • Disadvantages • Requires user to add rule • Process is different with every router • Mapping is active even when application is not running

  29. Universal Plug and Play (UPnP) • Advantages • Very powerful • Just as good as manual port forwarding • Support for discovery of Public IP address • Mapping is active only when application is running • Support for discovery and adjustment of mapping lifetime • Disadvantages • Complicated (requires HTTP, XML, SOAP, etc) • Inconsistent implementations by manufacturers

  30. NAT-PMP • Advantages • Trivial to implement • Support for discovery of Public IP • Mapping is active only when application is running • Disadvantages • Not widely supported (pretty much just Apple) • Very limited functionality • Turned off by default

  31. UDP Hole-Punch • Advantages • Most widely supported traversal method • Requires little modification to most UDP protocols • Only one client needs to be ‘punchable’ to establish connection • Requires no user interaction to function • Disadvantages • Must implement own TCP-ish functionality if reliability or order is required • Packets may be modified (ala Gamer Mode) • Requires remote server to identify external IP • Requires remote server to broker connection • Requires remote STUN server to identify NAT type

  32. TCP Hole-Punch • Advantages • Requires little modification to most TCP protocols • Only one client needs to be ‘punchable’ to establish connection • Requires no user interaction to function • Disadvantages • Not as widely supported as UDP Hole-Punch • Requires remote server to identify external IP • Requires remote server to broker connection • No standard (yet) for determining NAT type

  33. Multi-Traverse TCP • Public • Port mapping • UPnP • NAT-PMP • TCP Hole-Punch • UDP Hole-Punch w/ Reliable UDP • Relay

  34. Multi-Traverse UDP • Public • Port mapping • UPnP • NAT-PMP • UDP Hole-Punch • Relay

  35. Superpeers • Anyone who is one of the follow • Publicly accessible • Manually configured port mapping • Automatically configured port mapping (UPnP) • Advantages • Better utilization of existing resources • Very similar to how some P2P systems work • Disadvantages • Requires a decent number of peers to be effective • Still requires failover to reliable network • Can be problematic monitoring status of superpeers

  36. UDP Reliability Overview • UDT • SCTP • Roll-your-own • Pairing reliable with unreliable

  37. UDT • Offers all the bells and whistles of TCP (order, delivery, etc) • Designed for higher latency networks (ie, not LAN) • Focused more on delivery of data than communications • Advanced flow control, windowing, etc • Easiest implementation of the ‘reliable UDP’ family • Source and library available (most platforms, but primary focus on Unix)

  38. SCTP • More like TCP the way it should have been • Most commonly used of ‘reliable UDP’ family • Not as advanced as UDT • Complicated implementation • Source code and library available (most platforms)

  39. Roll-Your-Own • Advantages • Does exactly what you need and nothing you don’t • Likely to be more lightweight than other options • Disadvantages • Reinventing the wheel • Mistakes in algorithms can be difficult to find • In the real world can be more complicated than it appears

  40. Pairing reliable with unreliable • Who needs reliable? • TCP when it matters, UDP when it doesn’t

  41. Testing Overview • Approx 100 of the common NAT routers • None older than 5 years • All running the latest firmware • Reset to factory default settings • DHCP disabled on LAN • DHCP used on WAN • WiFi disabled (if possible) or WPA turned on • UPnP or NAT-PMP turned on • Market share based on 2500 SOHO business installations • UDP characteristics identified using STUN • Connection (UDP) lifetime identified using STUN

  42. Testing Overview (cont…) • STUN tools used • STUN-CLIENT-0-96 • http://sourceforge.net/projects/stun/ • JSTUN-0.6.1 • http://nixbit.com/cat/communications/filesharing/jstun/ • STUN client • http://www.codeproject.com/useritems/STUN_client.asp • Stunc (mine) • Included on the CD • Run all tools on each router, compare results.

  43. Market Share

  44. Feature Results • 99% routers with port mapping support • 74% routers with UPnP support • 65% routers with UPnP on by default • 1% routers with NAT-PMP support • 0% routers with NAT-PMP on by default • 48% routers with hair-pinning support

  45. NAT Type Results

  46. Other Interesting Results • Average UDP connection lifetime 180s • 60% using default password • 16% behind second NAT • Best overall • DLink DGL-4300 • Best bang for the buck • Airlink101 AR325W • Worst bang for the buck • Apple Airport Extreme • Best name but worst product • 3Com, US Robotics

  47. Conclusion • Thanks for attending • Question and (hopefully) answers

More Related