Bridging the gap. NAT traversal and peer communications

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