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

From: [email-masked] (Pekka Nikander)
Date: Mon Nov 15 11:19:00 2004

I know this is quite radical, but while pondering the generalised
locator proposal I sent some minutes ago, my thoughts followed
the following patter:

   - Most probably we want to include SPI in REA, since we may
     want to introduce multiple new SPIs in a single packet.

   - SPI and REA could be made a single packet type; the length
     field would tell which it is.  But this would be ugly.

   - What if we made SPI optional, and defined that the base
     exchange should have either SPI or REA?

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?

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.

If we take this path, we should probably also rename the REA
payload as LOC, for locators.

Any opinions?

--Pekka