[Hipsec] Base HIP: 02 PRE1

[[e-mail] (Henderson, Thomas R)]

> -----Original Message-----
> From: Pekka Nikander [mailto:[e-mail]]=20
> Sent: Sunday, January 23, 2005 1:11 AM
> To: Henderson, Thomas R; <[e-mail]>=20
> <[e-mail]>
> Cc: Petri Jokela
> Subject: Re: [Hipsec] Base HIP: 02 PRE1
>=20
>=20
> Tom and others,
>=20
> >> You can find the current pre-version,=20
> draft-ietf-hip-base-02-pre1, of
> >> the base draft in:
> >>
> >> http://hip4inter.net/drafts.php
> >
> > Here are a few more comments on this draft:
> >
> > Section 3:
> >>    (SPI) can be used for this purpose.  In many cases,=20
> this makes it
> >>  possible to use HIP without an additional explicit=20
> protocol header.
> >
> > Do we know this is true for "many" cases?  Or is it just ESP?
>=20
> I think it may be more appropriate to state "In some cases,".
>=20
Agreed.

> > Section 3.2:
> >> 3.2  Local Scope Identifier (LSI)
> >
>=20
> While I think that we are doing good progress with LSIs currently
> at the RG discussion, it might still be a good option to move LSIs
> into a separate draft.  Such a document could discuss LSIs, how
> they are used at the APIs and by applications, and _also_ define
> a HIP protocol extension for informing about used/assigned LSIs.
> Opinions?

I would favor such a document, scoped as "Using HIP with legacy
APIs" and it could contain more discussion about the LSIs and
incorporate the material in current Appendix A.

I'd be willing to take a first cut at it.

>=20
> > Section 4:
> >> All HIP implementations MUST implement, at minimum, the ESP
> >> transport format for HIP [23].
> >
> > Should this be a MUST?  Maybe strike this sentence (also in 4.7).
>=20
> Well, IMHO, it is important to provide some level of user plane
> interoperability.  Right now ESP is the lowest common denominator.
> Hence, in order to make all HIP hosts to be able to talk to each
> other, I think it makes sense to make this requirement.

My concern is that if someone adapts HIP for some non-ESP use
(e.g. a device that is SIP specific) then "MUST" forces that=20
implementor to code also the ESP portions.

I am not so concerned about user plane interoperability because
the market can decide these things, and the early implementations
will all support ESP anyway.

>=20
> > Section 4.7:
> >>   When new transport formats are defined, they MUST have=20
> smaller type
> >>   value than the ESP transport format.  The order in which the
> >>   transport formats are presented in the R1 packet, is the=20
> preferred
> >>   order.  The last of the transport formats MUST be ESP transport
> >>   format.
> >
> > Could you please remind me why ESP must be last?
>=20
> The idea was that you have the common denominator as the last one.
> In that way, if none of the earlier ones match, you know that the
> ESP will match.
>=20
> Maybe we should add some text to clarify this?

I guess this is tied to the above ESP discussion.

>=20
> > Section 8.2:
> >>   3.  The IP addresses in the datagram are replaced with the HITs
> >>       associated with the ESP SA. HIP association.  Note that this
> >>       IP-address-to-HIT conversion step MAY also be=20
> performed at some
> >>       other point in the
> >>       stack, e.g., before ESP processing. stack.
> >
> > Probably more needs to be said here regarding what to do when it is=20
> > IPv4
> > (i.e., convert to an IPv6 header then replace addresses with HITs).
>=20
> Or should we loosen this and say "... replaced with the HITs (or LSIs)
> associated with the HIP association"?

Perhaps we need a term here-- to borrow a multi6 terminology, we may
need to distinguish between LSI and "Upper Layer Identifier (ULID)"
that is used in the transport checksum.  We need to discuss in this
section the ULID, not the LSI (the two may be different).

In the absence of such definitions, I might suggest something like:
"The IP addresses in the datagram are replaced by constructing the
correct pseudo-header representation for the packet using HITs--
see section 4.2" or similar.=20

Tom