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
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
