RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]

["Bound, Jim" <Jim.Bound@hp.com>]

Pekka,

Didn't you have to keep as HIT cache on the end host?  Also I have read
the updated drafts and now I will say after much thought I am not clear
the pain for HIP is worth it and it will take a long time to sort this
out as IP stack developer.  THere will be much needed change on end host
and in the core of layer and I am not clear it is a big win.  And I like
the idea of IP adddreses used for IPsec identifiers totally.  It keeps
us all honest about  e2e in relation to the IP header.  I view HIP like
my work on the offload of IP stackes to NICs.  It will take much
thought.  But I think it is heing oversold completely.

For IPsec can we go offline we must make this an extension not a change
or it will not fly for a long time for implementation?

thanks
/jim

> -----Original Message-----
> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] 
> Sent: Friday, May 09, 2003 7:11 AM
> To: Bound, Jim
> Cc: multi6@ops.ietf.org
> Subject: Re: GSE IDs [Re: IETF multihoming powder: just add 
> IPv6 and stir]
> 
> 
> Jim,
> 
> Bound, Jim wrote:
> > Yes the HIP SPI could use the low order 64 bits but I want to read 
> > updates from Pekka N. just sent out for arch-03.  I am also unclear 
> > the HIP code changes to our transport layers or at the IP 
> layers will 
> > be done by what time frame.
> 
> HIP, in the way we implement it today, does not require any 
> changes to the transport layers at all, or to the IP layer in 
> anywhere else but at the end-hosts.  That is, of course, not 
> the only way to implement HIP, and it is probably also 
> possible to "distribute" HIP between an end-host and a middle 
> box, resulting in something that resembles MHAP.
> 
> In our current implementation, the only changes in the
> kernel are in IPsec ESP code.  All the rest is in user
> level, and the user level deamon dynamically modifies the
> IPsec SPD and SA entries to implement mobility.
> 
> Implementing multi-homing will require more extensive changes 
> to IPsec or elsewhere in the kernel.  We are still thinking 
> on how to do that.  Basically, we need to implement 
> destination address selection somewhere in the kernel.  (At 
> this stage we will be ignoring the actual selection 
> algorithm, and concentrate on the architecture:  Where to 
> "rewrite" the HIT into an IP address, and how to select the 
> right destination (and source)
> address(es).)
> 
> --Pekka Nikander
> 
>