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

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 15 Dec 2004 11:10:02 -0800

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Wednesday, December 15, 2004 8:20 AM
> To: Pekka Nikander
> Cc: [email-masked]
> Subject: Re: [Hipsec] Resolving the SPI question, or splitting ESP out
> of base spec
> 
> 
> > I know this is quite radical, but ...
> >
> >   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.
> 
> 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.
> 

I will voice support for splitting up the current base and mm drafts into
possibly the following:
i) core HIP signaling (I1 through R2, CLOSE, CLOSE_ACK, NOTIFY, UPDATE), 
without IPSec-related fields or processing
ii) IPsec (ESP) extension (ESP_TRANSFORM, SPI, rules for KEYMAT, BEET
semantics, NES and rekeying)
iii) mobility (locator change)
iv) host multi-homing
v) upper layer considerations (transport checksums, MTU, congestion
control, user-space API)

I think that the above will allow us to more easily consider and
experiment with variants that have been proposed (such as use of HIP
without ESP, and use of HIP using IKEv2 exchange for signaling, and
even possibly use of HIP in multi6 context).

Is this too much decomposition?  My rationale for splitting mobility
and multihoming is that our initial experience is that multihoming is
going to take a while longer to sort out completely (and we are lacking
initial implementation experience in that area).  My rationale for
suggesting a "upper layer" document (v) is thinking ahead to the
possibility that IKE or some multi6 protocol is used instead of base
exchange, in which case it might be nice if all of the upper layer
considerations are not embedded in the base document.

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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 15 Dec 2004 22:20:46 +0200

> v) upper layer considerations (transport checksums, MTU, congestion

I think this is a reasonable proposal, and as a first reaction seems 
good
other than that I'm not sure about transport checksums.  In my opinion,
separating the IP routing and the upper layers from each other is an
important feature of HIP.  Hence, at minimum, I think that we want the
base spec to say that the upper layer checksums, if there are ones,
SHOULD be computed based on location-independent identifiers.  To leave
space for something like multi6 protocols, we may still leave it open
what those identifiers are, and just suggest HITs as the default case.

But I'm afraid I need to think about this a little bit longer, and
consider the details, e.g., where the KEYMAT derivation really belongs.

> even possibly use of HIP in multi6 context).

IMHO, this is a good goal.

> initial implementation experience in that area).

Agreed.

> My rationale for suggesting a "upper layer" document (v) is
> thinking ahead to the possibility that IKE or some multi6
> protocol is used instead of base exchange, in which case
> it might be nice if all of the upper layer considerations
> are not embedded in the base document.

I think this is a reasonable goal as well, but OTOH I have a hard
time to figure out how exactly to say things.  Maybe we want to
say some things a few times, i.e., to repeat them in different
documents.

IIRC, right now we say very little about MTU, congestion control,
or APIs.  AFAIK, we can't say much about them other than MTU, which
seems to mostly fit into the ESP document at this point of time.
Hence, I may be inclined to retain the transport checksum considerations
in the protocol spec, to say something about MTU in the ESP spec,
and leave the other upper layer considerations for RG work at this
point of time.

In any case, the purpose of this WG is to get the defined minimal
set of documents out so that we have a stable reference point for
our experiments and further protocol and architecture design.

--Pekka

---

From: Petri Jokela <[email-masked]>
Date: Thu, 16 Dec 2004 15:51:28 +0200

Pekka Nikander wrote:
> I think this is a reasonable proposal, and as a first reaction seems good

I'll start working with the base specification part with this proposal 
in mind. So, I hope I get the first version out soon.

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec