Overview of NordicHIP project

The 24th NORDUnet Conference

Andrei GurtovHIIT

11.4.2008

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: 2006-2009 (4 years)• Project budget: 134 000 €/year

3

Host Identity Protocol Architecture

New layer betweenthe internetworkingand 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: 193.167.187.1,

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.7.6.2.b.f.2.2.3.4.c.0.b.1.a.f.7.9.9.9.0.6.5.1.0.0.1.0.0.2.hit-to-ip.infrahip.net. IN A 193.167.187.1IN AAAA 2001:470:1f00:ffff::1bb3IN 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

Client

Resolver

Asia

America

Europe

11

OpenDHT vs. DNS Performance

time nsupdate< update.txtreal 0m0.105suser 0m0.000ssys 0m0.004s

time dig 1.a.e.7.6.2.b.f.2.2.3.4.c.0.b.1.a.f.7.9.9.9.0.6.5.1.0.0.1.0.0.2.hit-to-ip.infrahip.net.real 0m0.008suser 0m0.000ssys 0m0.000s

time ./put.py colors redreal 1m8.558suser 0m0.156ssys 0m0.022s

time ./put.py colors greenreal 0m1.223suser 0m0.150ssys 0m0.023s

time ./get.py colorsreal 0m1.049suser 0m0.156ssys 0m0.020s

time ./put.py animals tigerreal 0m0.546suser 0m0.096ssys 0m0.016s

time ./get.py animals tigerreal 0m0.352suser 0m0.100ssys 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 ofCorresponding 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 caseswhere 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 instandards 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 supportingIPv4 and IPv6, they could inform each otherabout all their addresses

• When MN would move and lose its IPv4 address, the MN wouldstill have alternative CN addresses that it could try to use

• We have working implementation that can handleinterfamily 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 whenstudying 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 controlRandom MACs are generated in the

user space and assigned by using an ioctl system calls.

Currently only the Ethernet technology is supported.

IP controlExploits the privacy extension for

stateless address autoconfiguration

Supports only IPv6When an IP address is changed, HIP

locator update handles the mobility.

HI controlBased on HIP for Linux (HIPL)

implementation.HIP socket handler containsfunctionality for updating theexisting 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

IPv6 Internet

NR1 NR2 NR3

IPv4 Internet

A

B

DNS (v4 & v6):A: NID(A), locv6(A), hint=v4anycastforv6B: NID(B), locv4(B), hint=v6anycastforv4

IPv4 anycast address for v6 core

IPv6 anycast address for v4 core

B => A :packet:dst=NID(A), dsthint=locv6(A), IPdst=v4anycastforv6corerewrite at NRx:dst=NID(A), srchint=locv4(B), IPdst=locv6(A)

24

Book on HIP

25

Thanks!

• Questions?