Subject: [Hipsec] Base HIP: 02 PRE1

From: [email-masked] (Henderson, Thomas R)
Date: Mon Jan 24 11:24:00 2005

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Sunday, January 23, 2005 1:11 AM
> To: Henderson, Thomas R; <[email-masked]>=20
> <[email-masked]>
> 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

---

From: [email-masked] (Pekka Nikander)
Date: Mon Jan 31 05:35:01 2005

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

Great!

> (e.g. a device that is SIP specific) then "MUST" forces that

Well, I have experienced a number of cases at the IETF where
the least-common-denominator interoperability has came up, and
some people (even the IESG IIRC) have been very strict of having
such as a MUST implement case.

I agree with you that there seems to be emerging other uses of
HIP but the original intention, where ESP is a central part.

My suggestion is that we go for a MUST in the base specification,
but also add something like:

   "Specific future documents of MAY define HIP profiles where
   implementing ESP is not MANDATORY.  However, any such use MUST
   be explicitly labelled to be non-compliant with <xref target=
   "I-D.ietf-hip-esp">the ESP transport format and method</xref>."

Hence, as a default case, I-D.ietf-hip-base implementations
MUST be compliant with I-D.ietf-hip-esp, unless they are also
compliant with <some-future-document> which explicitly allows
compliance to I-D.ietf-hip-base without compliance to
I-D.ietf-hip-esp

Ok?

>>>>       associated with the ESP SA. HIP association.  ...
>>>
>
> ..., I might suggest something like:
> see section 4.2" or similar.

Looks good to me other than I would add parenthesis round "pseudo",
resulting in:

"The IP addresses in the datagram are replaced by constructing the
correct (pseudo-)header representation for the packet, using HITs
in the place of IP addresses -- see section 4.2"

Ok?

--Pekka