Subject: [Hipsec] Base HIP: 02 PRE1

From: [email-masked] (Henderson, Thomas R)
Date: Mon Jan 17 00:27:01 2005

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]]=20
> Sent: Friday, January 07, 2005 5:29 AM
> To: [email-masked]
> Subject: [Hipsec] Base HIP: 02 PRE1
>=20
>=20
> Folks,
>=20
> You can find the current pre-version, draft-ietf-hip-base-02-pre1, of=20
> the base draft in:
>=20
> http://hip4inter.net/drafts.php
>=20

Here are a few more comments on this draft:

Section 3:
>    (SPI) can be used for this purpose.  In many cases, this makes it
>  possible to use HIP without an additional explicit protocol header.

Do we know this is true for "many" cases?  Or is it just ESP?

Section 3.2:
> 3.2  Local Scope Identifier (LSI)

I am curious-- does anyone else think it might be more appropriate
to move LSIs out of this draft and into an informative draft or an
appendix?  If I decided to make my implementation use LSIs that do
not conform to the specified subnet, would anyone be able to tell
the difference?

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).

Section 4.7:
>   When new transport formats are defined, they MUST have smaller type
>   value than the ESP transport format.  The order in which the
>   transport formats are presented in the R1 packet, is the preferred
>   order.  The last of the transport formats MUST be ESP transport
>   format.

Could you please remind me why ESP must be last?

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 performed at some
>       other point in the
>       stack, e.g., before ESP processing. stack.
=20
Probably more needs to be said here regarding what to do when it is IPv4
(i.e., convert to an IPv6 header then replace addresses with HITs).

> Appendix A.  API issues

This should probably be removed to a separate draft now that other =
aspects
of the data transfer are moved out of this draft.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Sun Jan 23 04:11:01 2005

Tom and others,

>> You can find the current pre-version, draft-ietf-hip-base-02-pre1, of
>> the base draft in:
>>

I think it may be more appropriate to state "In some cases,".

On the other hand, basically in any case where unambiguously
demultiplex packets based on the information in the existing
headers and state created with the help of the HIP protocol,
in theory on can send packets without extra overhead.  For example,
one could imagine a HIP extension that "signals" TCP or UDP
port numbers, and then uses plain TCP or UDP to send the traffic.
Of course, that would require that the kernels in the participating
machines do not assign those port numbers for non-HIP traffic,
but that should be doable.

> not conform to the specified subnet, would anyone be able to tell

As I have stated in more length at the RG side in the discussion
related to ULIDs, I think that LSIs and LSI formats are important
from the applications interoperability point of view.  That is, while
LSIs don't necessarily matter at the HIP protocol level, they are
important for legacy applications that use the LSIs at the current
IPv4 and IPv6 APIs.

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?

> Should this be a MUST?  Maybe strike this sentence (also in 4.7).

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.

> Could you please remind me why ESP must be last?

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.

Maybe we should add some text to clarify this?

> (i.e., convert to an IPv6 header then replace addresses with HITs).

Or should we loosen this and say "... replaced with the HITs (or LSIs)
associated with the HIP association"?

>> Appendix A.  API issues
>
> This should probably be removed to a separate draft now that other 
> aspects

Yes, I agree.

--Pekka