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

From: Pekka Nikander <[email-masked]>
Date: Mon, 15 Nov 2004 19:31:15 +0200

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

_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 17 Nov 2004 09:56:18 -0800

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Monday, November 15, 2004 12:31 PM
> To: [email-masked]
> Subject: [Hipsec] Resolving the SPI question, or splitting 
> ESP out of base spec
> 

As I just posted on the thread on the RG list, I agree that this
does seem consistent if one adopts the viewpoint that ESP is not
"core" HIP.  There have been various suggestions and proposals
to consider HIP without ESP, for lightweight reasons (lightweight
HIP) or because it conflicts/duplicates a more efficient encryption
scheme (secure RTP).

Also, regarding ESP, in section 11.5 of base spec the use of ESP
NULL is a "SHOULD NOT", but there may be valid reasons to use just
ESP authentication.  I discussed this with Bob at the meeting and
he said that he did not intend for ESP NULL to only be a debugging
mode.

Tom