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

– 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 :)

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.

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

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

NAT Overview

• Used by almost all users as gateway to Internet

• Allows multiple machines to share single IP

• Gives limited firewall functionality

• Performance

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

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

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)

Types of NAT's

• Defined in RFC3489 (STUN)– Full Cone– Restricted Cone– Port Restricted Cone– Symmetrical

• Hair-pinning

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

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

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

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

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

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

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

Standards Overview

• STUN

• SIP

• TURN

• ICE

• 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

STUN

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

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

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

NAT Traversal Overview

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

Connection Reversal

• Advantages– Works in every situation– Works with any protocol

• Disadvantages– Requires one peer to be publicly accessible

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

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

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

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

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

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

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

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

Multi-Traverse TCP

• Public

• Port mapping

• UPnP

• NAT-PMP

• TCP Hole-Punch

• UDP Hole-Punch w/ Reliable UDP

• Relay

Multi-Traverse UDP

• Public

• Port mapping

• UPnP

• NAT-PMP

• UDP Hole-Punch

• Relay

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

UDP Reliability Overview

• UDT

• SCTP

• Roll-your-own

• Pairing reliable with unreliable

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)

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)

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

Pairing reliable with unreliable

• Who needs reliable?

• TCP when it matters, UDP when it doesn’t

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

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.

Market Share

LinkSys31%

Dlink12%

Netgear5%Misc routers

23%

Unable to identify

22%

Public (no NAT)7%

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

NAT Type Results

Full Cone43%

Restricted Cone11%

Port Restricted Cone32%

Symmetric14%

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

Conclusion

• Thanks for attending

• Question and (hopefully) answers