NATBLASTER: Establishing TCP Connections Between Hosts Behind NATs

NATBLASTER:Establishing TCP Connections Between Hosts Behind NATs Andrew Biggadike, Daniel Ferullo, Geoffrey Wilson, Adrian Perrig Information Networking Institute Carnegie Mellon University [ACM SIGCOMM Asia Workshop, 2005, Beijing, China]

Agenda • Background • Problem Statement • Related Work • Environment & Assumptions • Our Techniques • Implementation • Results

Network Address Translation • NATs help solve depleting address space problems • Use private internal address spaces • Translates internal ports to unique external ports • But, NATs break network transparency • Host behind NAT cannot act as server in TCP connection (without extraneous configuration) • NATs drop packets from external network for which a mapping does not exist

Problem Statement NAT NAT A B Goal • Enable direct TCP connection between hosts behind NATs • There exists a third party not behind NAT both can connect to • Realistic for a P2P protocol X

TCP 3-Way Handshake Client Server SYN ACK SYN+ACK

TCP 3-Way Handshake w/ NAT Client Server NAT SYN ACK SYN+ACK

TCP 3-Way Handshake w/ NAT Client Server NAT SYN

Motivation • P2P protocols are increasingly being used • Workspace sharing (Groove) • File sharing (BitTorrent, KaZaA) • Instant Messaging & File Transfers • Network Gaming • P2P protocols use direct connections • Peers required to receive unsolicited connection requests from external peers • More difficult to statically pre-configure NAT when using P2P

Related Solutions • Port Forwarding ability in NATs • Gnutella / PUSH Proxy • Only one peer is behind a NAT • The role of server is transferred to the peer not behind a NAT • UDP Hole Punching • Allows for direct UDP connections between peers if both are behind NATs • Walfish, et al. • Suggests an indirection service that could proxy connections between two peers • Ford, et al. • Extend hole-punching to allow TCP connections using a TCP Hole Punching technique • MIDCOMM • IETF working group dedicated to this problem

Related Solutions (cont.) • NUTSS • Independently developed and similar to our work • Spoofing is needed in NUTSS, Natblaster does not require spoofing • Our Approach • Utilize a third-party only to establish direct TCP connection • Direct TCP connection: more efficient, more secure, more general

Assumptions • The two hosts learn of each other through P2P application layer protocol • Hosts can observe ISNs chosen by TCP stack • Internal hosts won’t see ICMP TTL Exceeded messages • We send packets with low TTL values • Many NATs don’t forward these errors to internal hosts • Can use host firewall if they do • NATs keep mappings despite ICMP TTL Exceeded message • All NATs we saw provide this property • NATs are at least 2 hops apart – Low TTL

Techniques Overview • Pre-Connection Diagnostics • Determine the environment • Determine NAT behavior • Connection Setup Phase – Create the TCP connection

Pre-Connection Diagnostics • Determine if Loose Source Routing (LSR) is available from A to B through X and from B to A through X. • Determine predictability of NA and NB • Each peer opens two TCP connections with X from sequential p, p+1. • If X sees sequential source ports, the NAT is predictable • If not, the NAT is random (i.e., unpredictable)

Two Environment Classes • Loose Source Routing • Predictable, Predictable (case 1) • Random, Predictable (case 3) • Random, Random (case 5) • No Loose Source Routing • Predictable, Predictable (case 2) • Random, Predictable (case 4) • Random, Random (case 6)

Case 2: 2 Predictable NATs X NAT NAT SYN ACK SYN+ACK A B SYN+ACK SYN ACK ISN P ISN Q

Case 4: Random, 1 Predictable NAT X NAT NAT SYN SYN+ACK A B SYN SYN+ACK SYN SYN+ACK Done Blue

Case 4 (cont.) X NAT NAT SYN ACK SYN+ACK A B SYN+ACK SYN ACK ISN P ISN Q

Exploiting Birthday Paradox • Goal: B has a 95% chance of guessing the correct external port after generating T SYN+ACKs • Naïve approach: A sends 1 SYN, B sends T SYN+ACKS • T ≈ 64,511*95% = 61,285 • Our approach: A sends T SYNs, B sends T SYN+ACKS • T = 439: 99.3% reduction of search space! • O(√N) trials instead of O(N)

Implementation • Implementation was in C on Linux Workstations using libpcap and libnet • The peers require root privileges for libpcap and libnet • Does not need root privileges if kernel module is used • The 3rd party can run with normal user privileges • Case 2 and 4 were implemented • Low TTL Value Determination was not implemented • Known values were hard-coded

Natblaster API http://natblaster.sourceforge.net • int natblaster_connect( • server_ip, /* IP of the 3rd party server */ • server_port, /* Port the server is listening on */ • local_ip, /* Local IP address bound to, also used by the server to resolve whom the buddy wants to connect to */ • local_port, /* Local port to return a connection on */ • buddy_external_ip, /* External IP of the buddy */ • buddy_internal_ip, /* Internal IP address of the buddy (used to uniquely identify the buddy on the 3rd party server) */ • buddy_internal_port, /* Internal port the buddy will connect on (used to uniquely identify the buddy on the 3rd party server) */ • device /* Device to forge/sniff packets on (optional)*/ • ) • natblaster_server( • listen_port /* Port to listen for Natblaster requests on */ • )

More Details in Paper • Detailed description of Cases 1 – 6 • Other interesting issues … • Birthday paradox mathematical derivation

Results • Tested using commercial NATs • Approximately 11 hops between peers • Case 2 implementation reliably opens connections • Case 4 implementation opens connections with expected probability • Birthday paradox reduces search space from O(N) to O(√N) • 439 instead of 61,285 trials!

Thank You! Source Code available athttp://natblaster.sourceforge.net

NATBLASTER: Establishing TCP Connections Between Hosts Behind NATs