[rrg] Host based solutions

[Pekka Nikander]

> Updated table:
>
>             HIP SHIM6 Six/ Mobile LISP- LISP- eFIT- Ivip
>                       One  IPv6   NERD  CONS  APT
>
> Address
> portability   y              Y2     Y     Y     Y     Y
>
> Multihoming   y   Y     Y    Y      Y     Y     Y     Y
>
> Mobility      y              Y                        Y1
>
> IPv4 too      y              Y      Y     Y     Y     Y
>
> No host                      Y3*    Y     Y     Y     Y1
> changes
>
> 1: Mobile IPv4 or IPv6 hosts making use of Ivip will need new host
> 2: PI Home Address used as EID needs some form of Home Agent provider
> 3: Corresponding Node functionality assumed on all IPv6 hosts, MIP6
>    /NEMO assumed for nodes that need Loc/ID split.
>
> HIP info is to be verified by an expert.

Host-based HIP provides identifier portability, which you can take as  
address portability in many scenarios.  HIP proxy provides address  
portability, as it uses legacy IP addresses between the proxy and the  
legacy hosts.

HIP (both host and proxy) provide combined multi-homing and mobility,  
including support make-before-break scenarios with "instant" handover,  
i.e. handover takes place immediately when the loss of connectivity  
has been detected, without any signalling needed at that time.

HIP (both host and proxy) provides connectivity through IPv4 and IPv6,  
including NATs and v4/v6 NATs (the so-called SPINAT scenario).  For  
multi-homing, some of connectivity can be IPv4 and some IPv6 at the  
same time, some NATted and some non-NATed.  That is all abstracted  
away, emulating the old IP connectivity as closely as possibly, with  
the addition of allowing more controlled connectivity through Hi3 like  
or HIP BONE like distributed rendezvous.

Host-based HIP supports both IPv4 and IPv6 legacy socket interface,  
and for many applications it can even allow IPv4 apps to talk to IPv6  
apps, doing the socket version translation transparently.  (The last  
capability requires a small patch to the kernel-side of the socket  
interface.)

Host-based HIP obviously requires host changes, either the ESP BEET  
mode (already in Linux + FreeBSD) + a daemon, or a daemon running in a  
TUN interface + suitable local routing table entries.

HIP proxy doesn't require any host changes, and provides the illusion  
of a stationary IP network even through mobility and multi-homing  
events.

What comes to the main complaint about HIP, the usage of crypto, there  
are a few partial answers:

1. While today the only way to use HIP is to use ESP to protect the  
actual data packets, nothing prevents one from defining new  
encapsulation options for HIP, such as using the SHIM6 or even having  
very rigourous knowledge about the currently present IP addresses and  
running without any encapsulation at all.  However, the option of no  
encapsulation seems brittle compared to other options, and therefore  
nobody has studied it in detail, AFAIK (cf. problems with e.g. port co- 
ordination in ICE).

2. Even when using ESP, encryption is optional.  You can run ESP with  
no encryption, with only integrity protection.

3. The HIP public key authentication allows you to configure  
ridiculously short public keys so that the performance penalty is  
negligible even on small devices; e.g. there is a project going on to  
port HIP to Intel iMote2.

4. If you are concerned about privacy, you can implement BLIND [1].   
But then you probably fool yourself somewhat, as other parts of the  
overall Internet architecture are likely to still leave traces about  
you...

5. If you want to get rid of public key crypto altogether, you can use  
LHIP [2], where one replaces long-lived public-key identifiers with  
ephemeral hash chains.

6. If you care concerned about revocation of host identity public  
keys, you can make the HI PKs relatively short lived, and use  
delegation to authorise the host keys from some more permanent keys.   
(BTW, this latter is what Boeing does in their SME, AFAIK.)

In Summary: With HIP, today you cannot avoid some crypto, but the  
performance penalty can be tuned to be very low, other than for ESP  
integrity.  What comes to ESP integrity, you can either simply turn it  
off (which is non-standard today, IIRC), adopt some other  
encapsulation method for HIP (e.g. SHIM6), or define a new one.

------

But then, once more:  I don't believe HIP or any other host-based  
solution (alone) helps directly with the routing scalability problem.   
But of course, I may be wrong, and actually would like to be wrong :-).

In the long run, wide-scale adoption of any host-based id/loc  
separation mechanism is likely to lift the pressure from preserving IP  
addresses, but that is *only* in the long run.  With proxies, such as  
the HIP proxy, one can make the transition faster and gain benefits  
sooner.  But that all I already said almost two years ago in the  
(largely ignored) attempt to make the point that there is no real  
binary difference between host-based and network-based solutions [3]  
-- we have to consider the architecture (host or network) and the  
implementation (again host or network) separately.  For architecture,  
we should consider forward evolution.  For implementation, we should  
consider deployment incentives.

--Pekka

[1] Jukka Ylitalo and Pekka Nikander, "BLIND: A Complete Identity  
Protection Framework for End-points", to appear in Security Protocols,  
Twelfth International Workshop, Cambridge, 24-28 April, 2004.  http://www.tml.tkk.fi/~pnr/publications/cam2004.pdf

[2] https://datatracker.ietf.org/drafts/draft-heer-hip-lhip/, http://www.join.uni-muenster.de/drafts/draft-heer-hip-lhip-00.txt

[3] http://tools.ietf.org/html/draft-nikander-ram-generix-proxying-00