Overview of NordicHIP project The 24th NORDUnet Conference Andrei Gurtov HIIT

2 Basic data on NordicHIP project Consortium –Andrei Gurtov (HIIT, coordinator), –Bengt Ahlgren (SICS), –Antti Ylä-Jääski (TML/TKK) Focus: Serve as a collaboration tool for national HIP activities by supporting mutual visits, courses, and some core technical work on Internet architecture, IPv4/v6 co-existence and naming infrastructure NORDUNET3 call Duration: (4 years) Project budget: /year

3 Host Identity Protocol Architecture New layer between the internetworking and transport layers

4 Host Identifier HIP = Host Identity Protocol (RFC 4423) HIT = Host Identity Tag (hash of self-generated public key, such as 2001:15:6099:97fa:1b0c:4322:fb26:7ea1) IP = Internet Protocol (IP address ex: , 2001:998:10:0:215:60ff:fe9f:60c4)

5 HIP Base Exchange HIP Base Exchange (BEX) is a four-way D-H key exchange, during which initiator solves a DoS-puzzle Initiator Responder I1 R1 + Puzzle I2 + Solution R2 Regular BEX handles only the current address LOCATOR parameter can be used in the BEX to inform about extra addresses

6 NordicHIP Research Areas Using DNS as an Access Protocol for Mapping Host Identifiers to Locators Interfamily Handovers between IPv4/6 HIP Privacy Management NodeID++ Architecture

7 Using DNS as an Access Protocol for Mapping Host Identifiers to Locators O. Ponomarev & A. Gurtov /HIIT

8 HIT -> IP Address Current HIPL implementation stores data in OpenDHT, but we may use DNS: 1.a.e b.f c.0.b.1.a.f hit-to- ip.infrahip.net. IN A IN AAAA 2001:470:1f00:ffff::1bb3 IN AAAA 2001:998:10:0:215:60ff:fe9f:60c4 My HIT was 2001:15:6099:97fa:1b0c:4322:fb26:7ea1 Location might be more flexible, e.g. an IP address and a UDP port

9 Why DNS? Domain Name System is the most widely deployed distributed database. Let us embed HIT/IP mapping to this system Almost every client can access a recursive resolver in the same network. We may use existing DNS servers instead of dht-gateways Simple UDP packets instead of XML-RPC requests And DNS is already used for OpenDHT boot-strapping

10 OpenDHT vs. DNS Architecture OpenDHT DNS DHT-gateway Client Resolver Asia America Europe

11 OpenDHT vs. DNS Performance time nsupdate< update.txt real 0m0.105s user 0m0.000s sys 0m0.004s time dig 1.a.e b.f c.0.b.1.a.f hit-to-ip.infrahip.net. real 0m0.008s user 0m0.000s sys 0m0.000s time./put.py colors red real 1m8.558s user 0m0.156s sys 0m0.022s time./put.py colors green real 0m1.223s user 0m0.150s sys 0m0.023s time./get.py colors real 0m1.049s user 0m0.156s sys 0m0.020s time./put.py animals tiger real 0m0.546s user 0m0.096s sys 0m0.016s time./get.py animals tiger real 0m0.352s user 0m0.100s sys 0m0.012s

12 Interfamily Handovers S. Varjonen & M. Komu /HIIT

13 The Problem Nodes are in IPv4 and IPv6 enabled network(s) Mobile Node (MN) moves to IPv6 only network and loses its IPv4 address Connectivity is lost if MN has no knowledge of Corresponding Node's (CN) IPv6 address MN has IPv4 & IPv6 CN has IPv4 & IPv6 connection using IPv4 Loses IPv4 X

14 Standardization Status in IETF Current standardization work considers only cases where the address has to be changed immediately, the LOCATOR parameter has a preferred bit set This work considers cases where the addresses transported in the LOCATOR parameter are used later if at all We propose to add the LOCATOR parameter to R1 and I2 as in standards but to leave the preferred bit unset CN should consider this kind of addresses as alternative addresses of the MN that it should store for later use

15 Solution and Implementation Now if the MN and CN are in network supporting IPv4 and IPv6, they could inform each other about all their addresses When MN would move and lose its IPv4 address, the MN would still have alternative CN addresses that it could try to use We have working implementation that can handle interfamily handovers; i.e., changing between IPv4 and IPv6 addresses No major difficulties during the implementation work During the implementation work, we came upon couple of new things that have to be considered when studying HIP and mobility further

16 HIP Privacy Management L. Takkinen & J. Lindqvist TML/TKK

17 Problem and Approach Problem: –When a mobile, wireless host changes its location, does authentication with other hosts etc., local and distant adversaries are able to track the host because both MAC address and interface identifier of the IPv6 address remain unchanged General solution: –The host must be able to hide its identifiers in all layers of TCP/IP stack, and use disposable identifiers with all networking applications HIP privacy management is one example of a solution: –MAC addresses, IP addresses and Host Identifiers (HI) are random and changed periodically –IPSec ESP protects the layers above Security Parameter Indexes (SPI) of ESP traffic are random and changed as well User is able to choose the privacy level of the system: –normal or stealth

18 Implementation MAC control Random MACs are generated in the user space and assigned by using an ioctl system calls. Currently only the Ethernet technology is supported. IP control Exploits the privacy extension for stateless address autoconfiguration Supports only IPv6 When an IP address is changed, HIP locator update handles the mobility. HI control Based on HIP for Linux (HIPL) implementation. HIP socket handler contains functionality for updating the existing socket bindings.

19 NodeID++ Bengt Ahlgren et al. / SICS

20 Background and Motivation The Internetwork problem was once solved with IPv4 –Since then, the problem has gradually been unsolved... NATs, firewalls and other middleboxes Nodes and whole networks moving Traffic which make deliberate harm IPv6 is not an alternative –Besides, we have not managed to migrate to it! NodeID internetwork architecture –Bridge over heterogeneous domains NATs and firewalls should be first order components –Require minimal set of common pieces e.g., avoid new global managed address space must anyway handle domains with different address spaces (IPv4 & IPv6, private & public) –Need strong migration incentives (c.f. IPv6) Integrated mobility (nodes and nets) Provide multihoming NAT traversal –Protection from unwanted traffic (DoS protection) –Benefit from partial deployment

21 NodeID++ Architecture Use a node identity layer –separation of node identity and node location(s) using cryptographic identifiers –we call these Node ID or NID (same as in HIP) Abuse the identity layer by doing routing on the node identifiers –(not part of HIP) Locator domain (LD) –world consists of independent LDs –LDs are self-contained with coherent –internal addressing and routing –connectivity between LDs is dynamic Node identity router (NR) –aka NID router –connects LDs –forwards packets using a NID routing table –very much like an IP router forward packets using an IP routing table

22 Node Mobility A moves to another location (1) & (2): recursive registration until old registration state encountered (home agent in this case) –Localizes mobility signaling! (3): de-registration down old registration path Node ID architecture provides: bridging over heterogeneous domains (IPv4, v6, etc) node and network mobility (& multihoming?) NID router replacing NAT devices NID router home agents can fend off unwanted traffic (DoS protection) single nodes and networks can start using it

23 IPv4/v6 Interoperability Motivation – To completely remove the problem of migration to IPv6, the Node ID architecture needs to have a mechanism handling multiple networks of different technologies – That would enable coexistence of IPv4 and IPv6 Main idea – use anycast addresses on the NID routers connecting the IPv4 and IPv6 Internets DNS : – same content in v6 & v4 worlds – add anycast address leading to the other side as routing hints NRx: – gateways between v4&v6 – no routing state here! – need session state however Packet: – put real dst locator as hint – need srchint to find way back

24 Book on HIP

25 Thanks! Questions?