Usurp: Distributed NAT Traversal for Overlay Networks Salman Niazi, Jim Dowling salman,jdowling@sics.se Swedish Institute of Computer Science

Usurp A NAT-aware message routing service, implemented as an overlay network. Nodes primarily use structured overlay network (SON) IDs as network endpoints. Build NAT-traversing P2P applications! Peer-to-Peer (P2P) apps are layered over Usurp middleware so that they both traverse NATs and can make NAT-aware connection decisions.

Client-Server NAT Infrastructure NAT Type Indentification Message Relaying Hole-Punching for UDP Rendezvous Servers STUN Servers TURN Servers Stateless 2 Public IPs Stateful High B/W Stateful Low Latency P2P Network Stun servers are stateless. Challenges: Stun servers require 2 public IP addresses. Turn and Rendezvous servers are stateful. Needs lots of them as the system scales. Requires additional addressing/routing support to enable communication with private nodes!

Distributed NAT Infrastructure Public Nodes have an Open IP address or support the UPnP IGD profile. SON of Public Nodes Addressing/Routing, STUN, TURN, Rendezvous services P2P Network Private Nodes are behind NATs/firewalls and become clients of public nodes.

background on nats

NAT Devices NAT devices differ in many application-observable aspects. NAT port mappings, Traffic filtering, NAT binding timeouts, ICMP handling, Queuing, Hair pinning, Buffer sizes 192.168.1.1 78.229.32.1 Internet NAT Gateways allow the use of many private IP addresses behind a single public IP address Solve the IP shortage problem Using NATs doesn’t affect clients in client-server Internet services HTTP, SMTP, IMAP, SSH, FTP, DNS, etc NAT Gateways present a connectivity problem for Peer-to-Peer (P2P) apps Only 20-40% of nodes are public nodes in existing systems. Active Queue Management (vs Drop tail behaviour) NAT behaviour is vendor-specific, but several common behaviours: NATs create transient mappings between private (ip:port) and public (ip:port) bindings. NATs exhibit differing packet filtering rules when mapping from public to private address space. NAT has at least 2 Network Interfaces: private network interface, public network interface. You can also have multi-layer NATs, Corporate NATs (many public network interfaces). There is no standard for NAT behaviour, although there are now recommended behaviours: IETF Network Address Translation (NAT) Behavioral Requirements for Unicast UDP NAT Behavioral Requirements for ICMP 192.168.1.121 192.168.1.54 IETF NAT Behavioral Requirements standards not adopted yet by manufacturers.

USURP

Usurp Component Architecture Both Public & Private Nodes Public Nodes Only Also have a Bootstrap Client here!

NAT type identification using DISTRIBUTED STUN

NAT Type Classification We use the BEHAVE RFC [1]. Defines NAT behaviour as a set of policies: Port Allocation Port Mapping Port Filtering NAT Binding Timeout X Symmetric Port-Restricted Partial-Cone Full-Cone

NAT Port Allocation Policy NAT with Public IP = 124.29.31.1 Source IP:port NAT Port Destination IP:port Port Allocation Policy 192.168.1.12:4983 4983 134.229.81.12:8888 Preservation 192.168.1.12:4983 56000 121.85.141.13:6543 Contiguity 192.168.1.12:4983 54832 184.121.54.83:1234 Random Preservation Contiguity Random When a packet is sent out from a certain private endpoint of a node behind a gateway to some public endpoint, a rule in the NAT table is created. Symmetric NATs sometimes have a random port allocation policy. :54832 :56000 :4983 192.168.1.12:4983 134.22.81.12:8888 184.121.54.83:1234 121.85.141.13:6543 56000 +∆

Port Mapping Policy Endpoint Independent Mapping (Preservation) Source IP:port NAT Port Destination IP:port 192.168.1.12:4983 4983 134.22.81.12:8888 134.22.81.12:6543 184.121.54.8:1234 Endpoint Independent Mapping (Preservation) Source IP:port NAT Port Destination IP:port 192.168.1.12:4983 56000 134.22.81.12:8888 134.22.81.12:6543 Host Dependent Mapping (Contiguity) 192.168.1.12:4983 56001 184.121.54.8:1234 192.168.1.12:4983 Source IP:port NAT Port Destination IP:port 134.22.81.12:8888 13545 134.22.81.12:6543 45352 184.121.54.8:1234 6957 Port Dependent Mapping (Random)

NAT Port Filtering Policy Source IP:port NAT Port Destination IP:port EI HD PD Incoming Packet 192.168.1.12:4983 4983 134.229.81.12:8888 Y Y Y 134.229.81.12:8888 Y Y N 134.229.81.12:7856 Y N N 85.185.241.13:6543 134.22.81.12:8888 Symmetric NATs often have a port-dependent filtering policy. Port-Restricted NATs often have a port-dependent filtering policy. Partial-Cone NATs have a host-dependent filtering policy. Full-Cone NATs have an endpoint-independent filtering policy. Symmetric = {<EI Filt, Random} Full-Cone = {EI, Random} Partial-Cone Port-Restricted Cone 134.22.81.12:7856 192.168.1.12:4983 85.185.241.13:6543 EI =Endpoint Independent; HD=Host Dependent; PD=Port Dependent

Distributed STUN Identifies the NAT Type: Mapping, Port Allocation and Filtering Polices & Binding Timeout Can re-run this protocol during application lifetime if one has a NAT that changes its type: e.g., corporate NATs

ADDRESSING, ROUTING and connection establishment

SON for Addressing and Routing Successor-list replication can be used so that private nodes have several parents If you are using successor-list replication, and periodic stabilization identifies a dead node, you may be a parent of the failed node, and inform it that its parent has died. A child then has to find a new parent – successor list replication is used for this. Parent failure identified using private->public node heartbeats & p-stabilization.

Node Descriptors SON key is used to connect to nodes NAT type contains: Mapping, Allocation, Filtering Policies IP Endpoints Single endpoint for public nodes Multiple Parent Endpoints for private nodes Timestamp for descriptor creation IP header = 20 Bytes UDP header = 8 bytes Usurp header (public node) = 35 bytes Usurp header (private node, 3 parents) = 47 bytes

Connection Establishment Parallelize connection attempts to private nodes by connecting to all its parents concurrently. Parallelized connection attempts is like parallel lookups on Kademlia.

NAT Hole Punching Strategies Connection reversal From public node to a private node Simple Hole-Punching Endpoint-Independent mapping or filtering Port-prediction using Contiguity Port-prediction using Preservation

NAT-Aware Connections It is the combination of NAT types of 2 nodes that is important when connecting two nodes behind NATs [2]. B’s Parent 1. Bind port X and Connect(B, Policy) 2. Response: B’s NAT IP 2. Connect(A’s NAT IP/port) 3. Send msg to random port at B’s NAT IP addr 4. Connect sent to port X on A’s NAT Rule-of-Thumb: If a connection is initiated by a less restrictive NAT to a more restrictive NAT, the more restrictive NAT performs the hole punching A B HD Mapping, Preservation, PD Filter PD Mapping, Random, PD Filter

EXPERIMENTS

Experimental Evaluation Evaluate performance of a Peer Sampling Service (Cyclon) in the presence of NATs. Compare behaviour and performance of: Baseline Cyclon (no NATs) Cyclon (with NATs) Cyclon over Usurp. Message-level simulator using Kompics. NAT emulator that emulates mapping, port allocation and filtering policies.

Cyclon Layered on Usurp

Experimental Setup Ratio public to private nodes is set to 1:4 Percentages of NAT types are taken from [2]. Rule binding expiration time Randomly chosen from {30, 60, 90, 120, 150, 180 sec} Simulate multiple nodes behind a NAT. Network size 1024 nodes. Constant node arrival rate of 500ms. Latencies modelled using the King Data Set [3] Results average of 30 runs

Experiment Setup Chord parameters Cyclon parameters successor stabilization of 2 seconds finger stabilization 3 seconds Cyclon parameters Cycle period 10 seconds View size 15 Shuffle Length 5

Clustering Coefficient

Average Path Length

Average In-Degree

Usurp Overhead vs Time

Overhead vs % Private Nodes

Massive Failure

Churn: Percent failures/cycle How churn affects the SON Join failures == failures of nodes to join the SON

Conclusions and Future Work Presented a fully distributed message routing infrastructure for IP networks with NATs P2P applications can be layered on Usurp. Validated Usurp using a PSS Acceptable overhead on public nodes for small networks Working on integration of a SON that supports sub-second lookups

References [1] BEHAVE RFC, Audet, F., Jennings, C.: Network address translation (nat) behavioral requirements for unicast udp (2007) IETF [2] Roverso et al., Natcracker: Nat combinations matter, ICCC, 2009. [3] Gummadi, K.P. et al, King: Estimating latency between arbitrary internet end hosts. In SIGCOMM Internet Measurement Workshop (2002)