Subject: [rrg] Host based solutions

From: "Teco Boot" <[email-masked]>
Date: Fri, 28 Nov 2008 09:00:21 +0100

All,

Is there an accurate overview on host based solutions?
The overview Brian Carpenter posted in Augustus 2007 
(http://www.ietf.org/mail-archive/web/rrg/current/msg00294.html),
HIP is missing. IMHO, info for MIP6 it is partly correct.
I think Shim6 is correct, I did not verify the others.

Old table:
>              SHIM6  Six/  Mobile  LISP-   LISP-   eFIT-  Ivip
>                     One   IPv6    NERD    CONS    APT
> 
> Address
> portability                       Y       Y       Y      Y
> 
> Multihoming   Y     Y             Y       Y       Y      Y
> 
> Mobility                  Y                              Y*
> 
> IPv4 too                          Y       Y       Y      Y
> 
> No host                           Y       Y       Y      Y*
> changes
> 
> * Mobile IPv4 or IPv6 hosts making use of Ivip will need new host
 
On MIP6:
- Address portability: one could "lease" an EID and HA functions
    and run sessions with CoA as much as possible (RO).
- Multihoming: We have RO and dual MCoA tunnels is on its way
    (I-D.ietf-monami6-multiplecoa).
- IPv4 too: There is DSMIP (almost finished) for IPv4 support 
    (could be used for reaching v4 hosts where nodes in v6-only
    Network, CN - HA is IPv4 & IPv6).
- No host changes: MIP6 itself is optional, but RO support 
    is a SHOULD. NEMO can be used for hosts that lack MIP6
    support.
So one could say MIP6 is full Y (with remarks). IMHO it is hosts based
map&encap and works in many conditions.

I think Shim6 is complementary to HIP and MIP6. This is not shown in the table.

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.

Maybe there is another resource providing a more complete overview.

Teco.

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 30 Nov 2008 10:26:23 +0200

> 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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 30 Nov 2008 10:16:02 +0100

Hi Teco,

some comments about your table...

> Multihoming   y   Y     Y    Y      Y     Y     Y     Y

Shim6 can work with ULAs as identifiers, providing address protability.
Shim6 can use IPv4 locators (even though cannot use IPv4 identifiers, so 
i am not sure how you would count this as supporting IPv4, but at least 
has some degree of ipv4 support)
Shim6 can be used as RO mechanism in mobility. In order to support 
initial contact, an additional element like the HA is needed, but this 
is needed in any solution. In shim6, we reused the MIP HA cause it 
didn't seem interesting to redefine the same function with another shim6 
specific name. However, when used with MIP6, shim6 does provide 
additional enahced fault tolerance capabilities that mip6 lacks, of, 
namely support of multiple HoAs
Finally, you can use proxy shim6 and you would achieve no host changes

regards, marcelo