NATBLASTER: Establishing TCP Connections Between Hosts Behind NATs

1
NATBLASTEREstablishing 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

2
Agenda

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

3
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

4
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
5
TCP 3-Way Handshake
Client
Server
SYN
SYNACK
ACK
6
TCP 3-Way Handshake w/ NAT
Client
Server
NAT
SYN
SYNACK
ACK
7
TCP 3-Way Handshake w/ NAT
Client
Server
NAT
SYN
8
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

9
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

10
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

11
Assumptions

• The two hosts learn of each other through P2P
  application layer protocol
• Hosts can observe ISNs chosen by TCP stack
• Internal hosts wont see ICMP TTL Exceeded
  messages
• We send packets with low TTL values
• Many NATs dont 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

12
Techniques Overview

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

13
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, p1.
• If X sees sequential source ports, the NAT is
  predictable
• If not, the NAT is random (i.e., unpredictable)

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

15
Case 2 2 Predictable NATs
X
NAT
NAT
SYN
SYNACK
ACK
A
B
SYN
SYNACK
ACK
ISN Q
ISN P
16
Case 4 Random, 1 Predictable NAT
X
NAT
NAT
SYN
SYNACK
A
B
SYN
SYNACK
SYN
SYNACK
Done
Blue
17
Case 4 (cont.)
X
NAT
NAT
SYN
SYNACK
ACK
A
B
SYN
SYNACK
ACK
ISN Q
ISN P
18
Exploiting Birthday Paradox
Goal B has a 95 chance of guessing the correct
external port after generating T SYNACKs Naïve
approach A sends 1 SYN, B sends T SYNACKS T
64,51195 61,285 Our approach A sends T
SYNs, B sends T SYNACKS T 439 99.3
reduction of search space! O(vN) trials instead
of O(N)
19
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

20
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 /
• )

21
More Details in Paper

• Detailed description of Cases 1 6
• Other interesting issues
• Birthday paradox mathematical derivation

22
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(vN)
• 439 instead of 61,285 trials!

23
Thank You!

• Source Code available at http//natblaster.source
  forge.net