Bridging the gap. NAT traversal and peer communications

IntroductionDon't worry about notes - everything is available on a CD at the end of lectureSimple example client/server providedPure C implementation, easily portableLeast code possiblePerforms TCP and UDP hole-punchingIncludes slides and lecture textIncludes STUN client and UPNP explorerIncludes reference material (RFC's, etc)Includes list of links to online resourcesPlease save questions until the end of talkDo take notes on these, they're obviously not on the CD :)

About MeSpent 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 companiesContract work back in the day for Sega, 3DO, Spectrum Holobyte, etc.

Talk ObjectivesWhen finished, you should haveA 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 :)

TermsPrivateInternal IP address (typically issued by NAT)PublicNAT box public Internet IP addressRemoteInternet IP address of other systemRendezvousInternet IP address of server to negotiate communications (ex; SIP, etc)Hole-PunchEstablish a connection through a NAT

NAT OverviewUsed by almost all users as gateway to InternetAllows multiple machines to share single IPGives limited firewall functionalityPerformance

NAT vs FirewallFirewallMost common in corporate settingsPrimary focus typically securityDefault action is typically implicit denyComplex rulesSometimes used in conjunction with Socks/Proxy serverNATTypically used by end users and small businessesSimple to configureDefault action is typically implicit allowRewrites source addr, destination addr, checksum, etc

NAT FlavorsDefined in RFC2663Outbound NAT (most common)Sometimes called Basic NAT or NATPSessions only initiated by Private IPBi-Directional NATSessions initiated by Private or Remote IPRequires use of DNS_ALGTwice NATUsed where Remote and Private IPs overlapMultihome NATUses more than one physical link

NAT Performance concernsIP modification requires IP header checksum calculationPort modification requires TCP checksum calculationMore active connections require more memory/state trackingSome NAT's modify UDP contents (gamer mode)

Types of NAT'sDefined in RFC3489 (STUN)Full ConeRestricted ConePort Restricted ConeSymmetricalHair-pinning

Full ConeLeast restrictive type of NATSimilar in use to port mapping or port triggeringAll requests from same Private IP/port mapped to the same Public IP/portAny remote host can contact Private IP/port by contacting mapped Public IP/port

Full Cone Hole-PunchPrivate host contacts Rendezvous server, reports availableRemote host contacts Rendezvous server, requests IP/port of Private hostRendezvous server returns Public IP/port to Remote hostRemote host attempts to contact Public IP/portRemote IP/port mapped to Private IP/port

Restricted ConeSlightly more restrictive than Full ConeAll requests from same Private IP/port mapped to the same Public IP/portOnly Remote IPs that Private has contacted before can use mapped Public IP/port

Restricted Cone Hole-PunchPrivate host contacts Rendezvous server, reports availableRemote host contacts Rendezvous server, requests IP/port of Private hostRendezvous server returns Public IP/port to Remote hostRendezvous server directs Private host to contact Remote IP/portRemote host attempts to contact Public IP/portPrivate host attempts to contact Remote IP/portRemote IP/port mapped to Private IP/port

Port Restricted ConeMost restrictive type of NAT that still can be trivially traversedAll requests from same Private IP/port mapped to the same Public IP/portOnly Remote IP/port that Private has contacted before can use mapped Public IP/port

Port Restricted Cone Hole-PunchPrivate host contacts Rendezvous server, reports availableRemote host contacts Rendezvous server, requests IP/port of Private hostRendezvous server returns Public IP/port to Remote hostRendezvous server directs Public host to contact Remote IP/portRemote host attempts to contact Public IP/portPrivate host attempts to contact Remote IP/portRemote IP/port mapped to Private IP/port

SymmetricalMost restrictive type of NATCannot be realistically traversedAll requests from same Private IP/port to a specific Remote IP/port mapped to the same Public IP/PortOnly Remote IP/port that Private host has contacted before can use mapped Public IP/port

Standards OverviewSTUNSIPTURNICE

STUNDefined in RFC3489Simple protocolWidely used, many free public serversIdentifies Public IP address of userCan reliably identify type of NAT deviceCan reliably identify lifetime of mapping

LimitationsUDP only (TCP in the works)Can be time consuming depending on type of NAT and test performedRequires public server with two IP addresses

SIPDefined in RFC3261HTTP-like formatting (mostly)Focused on brokering connections between clients (mostly)Widely used, many free public serversMany client and server implementationsISPs unlikely to filter/shape due to typical type of traffic (ie; VOIP)

LimitationsHas problems working with NAT (why ICE was created)Not that simple to implement

TURNDefined in IETF DraftAt its core, just a relay serverSimilar to SOCKS5Allows communications between clients when neither can be hole punched

ICEDefined in IETF DraftCollection of protocols and methodologiesDesigned to be transparent to NATUnlike UPnP, never directly interactsSTUN for NAT identificationSIP/RDP for connection negotiationUDP hole-punching for establishing linkTURN used if hole-punching not possible

NAT Traversal OverviewConnection ReversalRelay (TURN)ProxySocksPort forwardingUPnPNAT-PMPUDP Hole-PunchTCP Hole-Punch

Connection ReversalAdvantagesWorks in every situationWorks with any protocolDisadvantagesRequires one peer to be publicly accessible

RelayAdvantagesWorks in every situationCan be designed to mimic other protocolsNot effected by multiple NAT boxesNot effected by NAT typeDisadvantagesAll traffic is routed through relay serverSingle point of failureRequires significant infrastructure for large scaling

ProxyAdvantagesLooks like HTTP trafficWorks in situations where no other method doesRelatively simple in implementEasily detected by checking browser settingsDisadvantagesRequires two connections for bi-directionalityOnly works with TCPNot common in consumer deploymentsMay require authenticationIf autoconfigured, may use Javascript

SOCKSAdvantagesWorks with arbitrary protocolsSupports both TCP and UDPSupports inbound requestsRelatively simple to implementEasily detected by checking browser settingsDisadvantagesNot common in consumer deploymentsNot common in corporate deployments eitherMay require authenticationMay be configured to not allow inboundIf autoconfigured, may use Javascript

Port ForwardingAdvantagesBest way to guarantee availability short of being publicSupported on virtually every routerDisadvantagesRequires user to add ruleProcess is different with every routerMapping is active even when application is not running

Universal Plug and Play (UPnP)AdvantagesVery powerfulJust as good as manual port forwardingSupport for discovery of Public IP addressMapping is active only when application is runningSupport for discovery and adjustment of mapping lifetimeDisadvantagesComplicated (requires HTTP, XML, SOAP, etc)Inconsistent implementations by manufacturers

NAT-PMPAdvantagesTrivial to implementSupport for discovery of Public IPMapping is active only when application is runningDisadvantagesNot widely supported (pretty much just Apple)Very limited functionalityTurned off by default

UDP Hole-PunchAdvantagesMost widely supported traversal methodRequires little modification to most UDP protocolsOnly one client needs to be punchable to establish connectionRequires no user interaction to functionDisadvantagesMust implement own TCP-ish functionality if reliability or order is requiredPackets may be modified (ala Gamer Mode)Requires remote server to identify external IPRequires remote server to broker connectionRequires remote STUN server to identify NAT type

TCP Hole-PunchAdvantagesRequires little modification to most TCP protocolsOnly one client needs to be punchable to establish connectionRequires no user interaction to functionDisadvantagesNot as widely supported as UDP Hole-PunchRequires remote server to identify external IPRequires remote server to broker connectionNo standard (yet) for determining NAT type

Multi-Traverse TCPPublicPort mappingUPnPNAT-PMPTCP Hole-PunchUDP Hole-Punch w/ Reliable UDPRelay

Multi-Traverse UDPPublicPort mappingUPnPNAT-PMPUDP Hole-PunchRelay

SuperpeersAnyone who is one of the followPublicly accessibleManually configured port mappingAutomatically configured port mapping (UPnP)AdvantagesBetter utilization of existing resourcesVery similar to how some P2P systems workDisadvantagesRequires a decent number of peers to be effectiveStill requires failover to reliable networkCan be problematic monitoring status of superpeers

UDP Reliability OverviewUDTSCTPRoll-your-ownPairing reliable with unreliable

UDTOffers 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 communicationsAdvanced flow control, windowing, etcEasiest implementation of the reliable UDP familySource and library available (most platforms, but primary focus on Unix)

SCTPMore like TCP the way it should have beenMost commonly used of reliable UDP familyNot as advanced as UDTComplicated implementationSource code and library available (most platforms)

Roll-Your-OwnAdvantagesDoes exactly what you need and nothing you dontLikely to be more lightweight than other optionsDisadvantagesReinventing the wheelMistakes in algorithms can be difficult to findIn the real world can be more complicated than it appears

Pairing reliable with unreliableWho needs reliable?TCP when it matters, UDP when it doesnt

Testing OverviewApprox 100 of the common NAT routersNone older than 5 yearsAll running the latest firmwareReset to factory default settingsDHCP disabled on LANDHCP used on WANWiFi disabled (if possible) or WPA turned onUPnP or NAT-PMP turned onMarket share based on 2500 SOHO business installationsUDP characteristics identified using STUNConnection (UDP) lifetime identified using STUN

Testing Overview (cont)STUN tools usedSTUN-CLIENT-0-96http://sourceforge.net/projects/stun/JSTUN-0.6.1http://nixbit.com/cat/communications/filesharing/jstun/STUN clienthttp://www.codeproject.com/useritems/STUN_client.aspStunc (mine)Included on the CDRun all tools on each router, compare results.

Market Share

Feature Results99% routers with port mapping support74% routers with UPnP support65% routers with UPnP on by default1% routers with NAT-PMP support0% routers with NAT-PMP on by default48% routers with hair-pinning support

NAT Type Results

Other Interesting ResultsAverage UDP connection lifetime 180s60% using default password16% behind second NAT

Best overallDLink DGL-4300Best bang for the buckAirlink101 AR325WWorst bang for the buckApple Airport ExtremeBest name but worst product3Com, US Robotics

ConclusionThanks for attendingQuestion and (hopefully) answers