overview of nordichip project n.
Skip this Video
Download Presentation
Overview of NordicHIP project

Loading in 2 Seconds...

play fullscreen
1 / 25

Overview of NordicHIP project - PowerPoint PPT Presentation

  • Uploaded on

Overview of NordicHIP project. The 24th NORDUnet Conference Andrei Gurtov HIIT 11.4.2008. Basic data on NordicHIP project. Consortium Andrei Gurtov (HIIT, coordinator), Bengt Ahlgren (SICS), Antti Ylä-Jääski (TML/TKK)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Overview of NordicHIP project' - muncel

Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
overview of nordichip project

Overview of NordicHIP project

The 24th NORDUnet Conference

Andrei Gurtov



basic data on nordichip project
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
host identity protocol architecture
Host Identity Protocol Architecture

New layer between

the internetworking

and transport layers

host identifier
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)

hip base exchange
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
nordichip research areas
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
using dns as an access protocol for mapping host identifiers to locators
Using DNS as an Access Protocol for Mapping Host Identifiers to Locators
  • O. Ponomarev & A. Gurtov /HIIT
hit ip address
HIT -> IP Address

Current HIPL implementation stores data in OpenDHT, but we may use DNS:



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

why dns
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
opendht vs dns architecture
OpenDHT vs. DNS Architecture










opendht vs dns performance
OpenDHT vs. DNS Performance

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

time nsupdate< update.txt

real 0m0.105s

user 0m0.000s

sys 0m0.004s

time dig 1.a.e.7.6.2.b.f.

real 0m0.008s

user 0m0.000s

sys 0m0.000s

interfamily handovers
Interfamily Handovers
  • S. Varjonen & M. Komu /HIIT
the problem
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
standardization status in ietf
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
solution and implementation
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
hip privacy management
HIP Privacy Management
  • L. Takkinen & J. Lindqvist TML/TKK
problem and approach
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

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.

  • Bengt Ahlgren et al. / SICS
background and motivation
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
nodeid architecture
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
node mobility
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
ipv4 v6 interoperability
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
  • Questions?