1 the ini is a cooperative endeavor of:electrical and computer engineeringschool of computer science...

1The INI is a cooperative endeavor of: Electrical and Computer Engineering School of Computer Science

Graduate School of Industrial Administration Heinz School of Public Policy

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

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

NATA B

X

GoalNAT



TCP 3-Way Handshake

SYN

Client Server

SYN+ACKACK



TCP 3-Way Handshake w/ NAT

SYN

Client Server

SYN+ACKACK NAT



TCP 3-Way Handshake w/ NAT

SYN

Client Server

NAT



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 NATsGnutella / 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 NATsWalfish, 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 techniqueMIDCOMM

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)



SYN

SYNA B

X

SYN+ACK

SYN+ACKACK

ACK

ISN QISN P

Case 2: 2 Predictable NATs

NATNAT



Case 4: Random, 1 Predictable NAT

SYN

A B

Done

SYN+ACK

SYN

SYN

SYN+ACK

SYN+ACK

Blue

X

NAT NAT



Case 4 (cont.)

SYN

SYNA B

X

SYN+ACK

SYN+ACKACK

ACK

ISN QISN P NATNAT



Exploiting Birthday ParadoxGoal: 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.netint 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 at http://natblaster.sourceforge.net

1 the ini is a cooperative endeavor of:electrical and computer engineeringschool of computer science...

Documents