1 / 23

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

linette
Download Presentation

NATBLASTER: Establishing TCP Connections Between Hosts Behind NATs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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]

  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 ACK SYN+ACK

  6. TCP 3-Way Handshake w/ NAT Client Server NAT SYN ACK SYN+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 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

  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, p+1. • 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 ACK SYN+ACK A B SYN+ACK SYN ACK ISN P ISN Q

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

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

  18. 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)

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

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

More Related