Subject: [Hipsec] Resolving the SPI question, or splitting ESP out of base spec

From: [email-masked] (Miika Komu)
Date: Thu Dec 2 10:58:01 2004

On Mon, 15 Nov 2004, Pekka Nikander wrote:

> And as a logical consequence of this,
>
>    What if we split out all concerning ESP from the base
>    specification, and make it a (mandatory) extension?
> ...
>
> If we take this path, we should probably also rename the REA
> payload as LOC, for locators.
>
> Any opinions?

There has been no responses to this this email, so here's one.

I guess this depends on whether we want to finish the base exchange and
get an RFC faster. If we split the IPsec stuff, it is going to delay the
standardization, IMHO.

On the other hand, perhaps the split would make HIP also a more "generic"
protocol. For example, this would make it easier to implement HIP enabled
multicast. However, the multicast requires other changes, and perhaps
should be further discussed in the research group...

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: [email-masked] (Pekka Nikander)
Date: Wed Dec 15 11:20:01 2004

> I know this is quite radical, but ...
>
> That seems to take care of a lot of problems.  Firstly, the
> SPI payload would really become an optional payload.  Semantically,
> it would just be a shorthand for a REA when
>
>   - the locator the one from the enclosing IP or UDP header
>   - the locator lifetime is infinite
>   - the roles include both HIP and ESP
>
> Secondly, that would allow us to better handle the problems with
> mixing re-keying and locator changes in a single UPDATE.
> Basically, the ESP extension specification would define a simple
> re-keying method, to be used when only that is used, and the
> mobility and multi-homing extension would define a more complicated
> re-keying method, to be used when multi-homing is applied.
>

So far I haven't seen any discussion on this other than Miika's
response where he is concerned about how fast we could do such
a split in practice, and some face-to-face discussions with Petri
where we have been trying to ponder this without coming into any
concrete conclusions, at least not yet.

I'd like to proceed by making a concrete proposal.  However,
before that, I'd like to get some feedback from the WG on whether
this is considered to be a viable way at all or not.  While the
short run benefit seems to be that it makes the mm spec easier to
get done, it opens potential complexities (but also increased
flexibility) in the longer run.

--Pekka