HIP-Based NAT Traversal in P2P-Environments

1. HIP-Based NAT Traversal in P2P-Environments Ari KeränenNomadicLab, Ericsson Research Supervisor: prof. Jörg Ott

2. Outline • Background • Network Address Translation (NAT) • NAT Traversal • Host Identity Protocol (HIP) • NAT Traversal Using HIP • implementation of a NAT traversal library • Measurement results • Findings & Conclusions

3. src: 10.0.0.1 dst: 130.233.240.9 src: 198.76.28.1 dst: 130.233.240.9 NAT NAT’s public address:198.76.28.1 Network Address Translation • NAT can transparently change a network internal, private address to a public address • a new mapping is dynamically created when the first packet for a connection passes the NAT • return traffic can use the same mapping to the other direction • allows normally only outbound connections • often use TCP/UDP ports for multiplexing

4. NAT Types • Mapping and filtering behavior varies between NAT implementations • Mapping • if the destination address and/or port changes, will the source public address at the NAT change • Filtering • which source addresses and/or ports on the external side of NAT are allowed to use the mapping

5. NAT Types • Endpoint independent filtering • any host using any port in the external side can use the mapping the NAT has created • Address (and port) dependent filtering • only packets from the same destination address (and port) that created the mapping are accepted • Endpoint independent mapping • NAT uses the same mapping (i.e., public address and port) for packets even if the destination address or port changes • Address (and port) dependent mapping • NAT mapping is changed if the destination address (or port) is changed

6. NAT Traversal • A way to make the responder behind a NAT reachable • Needed especially in P2P environments since a peer is likely behind a NAT • compare to client-server model, where servers are normally in the public, globally routable network • Can be done using hole punching • responder sends a packet to a (STUN) server and learns the NAT mapping from the response • the initiator may be able to use that mapping • depending on the type of the NATs

7. Interactive Connectivity Establishment • A robust NAT traversal solution • Combines hole punching with a set of optimizations and methodology • works also in scenarios where simple hole punching does not work • Both endpoints probe for connectivity using multiple (all) possible address candidates • relayed route as the last resort • controlling hosts decides when to stop tests and which path to use

8. A new namespace and a layer between transport and IP layers transport layer connections bound to host identity Enables natural host mobility and multihoming IP address changes invisible to upper layers transport layer connections survive address changes Host Identity Protocol

9. Host Identity Protocol • Connection established using a four-way handshake; the HIP base exchange • proof of identity, IPsec setup, DoS attack protection • Legacy applications can use HIP transparently • presentation of the host identity (Host Identity Tag) looks like a normal IPv6 address • Problems with NATs • HIP is normally run directly on top of IP • simple UDP encapsulation works if the responder is not behind a NAT

10. NAT Traversal Using HIP • Use ICE for traversing the NATs • ICE candidates sent in the HIP base exchange • base exchange through a relay or a P2P overlay network • Single NAT traversal solution for all applications • no need for application specific solutions

11. Implementation • Implemented ICE library • 3+1 Internet-Drafts • ICE: draft-ietf-mmusic-ice-19 • STUN: draft-ietf-behave-rfc3489bis-15 • TURN: draft-ietf-behave-turn-07 • (draft-rosenberg-mmusic-ice-nonsip-00) • Tested the library using various NAT types • is ICE able to create a path • how much traffic is generated

12. Measurement Scenarios • Two hosts behind different NATs • NAT types can be changed (filtering behavior + Linux NAT) • STUN/TURN server in the public network • ICE connectivity checks run between the two hosts

13. Measurement Results • ICE is able to create a working path in all the scenarios • outperforms simple hole punching • Best path depends on the scenario • Linux-Linux NAT scenario requires a relay • port dependent filtering with Linux NAT needs a relay depending on timing of the checks • all other scenarios work with direct path • some variation in the amount of messages

14. EI: Endpoint-Independent AD: Address-Dependent PD: Address and Port-Dependent L: Linux Measurement Results

15. Findings • The default timer values for non-RTP ICE are suboptimal • connectivity checks can take multiple seconds even in common NAT scenarios • can be fixed relatively easily • Good local stopping criteria/algorithm is essential for performance of ICE

16. Conclusions • ICE is a good solution for HIP P2P NAT traversal • works with all tested scenarios (and likely with many others) • minor changes to basic ICE are useful • The solution increases overhead • but not substantially compared to other options

17. That’s all folks! Questions?