Subject: [Hipsec] Base HIP: 02 pre2

From: [email-masked] (Ahrenholz, Jeffrey M)
Date: Tue Jan 25 21:06:01 2005

Petri,
I started reviewing the 02-pre2 draft, and have just a few editorial
comments:

in the abstract (p1):
/subsequent HIP message/subsequent HIP messages/
/session keys other security protocols/session keys for other security
protocols/

"The basic HIP exchange for two public hosts shows the actual packet
flow."
The above sentence has been in the abstract since the moskowitz-01
version (5 years); it does not make sense to me.

section 1.1 (p6)
/not good for using as/not good for use as/
/or as a index/nor as an index/

section 3.1.1 (p11)
/has the same length than the/has the same length as the/
/HI.n_len/HI.RSA.n_len/

section 4.1.1 (p16)
/function such be used/function should be used/

4.1.2 (p17)
/and its the encrypted public authentication key/and its encrypted
public authentication key/

6.2.18
remember my post from
<http://honor.trusecure.com/pipermail/hipsec/2004-June/000777.html>?
I think it should be noted that one of the ECHO_REQUESTs is critical
while the other is not.

-Jeff

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]]=20
> Sent: Tuesday, January 25, 2005 4:52 AM
> To: [email-masked]
> Subject: [Hipsec] Base HIP: 02 pre2
>=20
>=20
>=20
> Folks,
>=20
> I uploaded the base draft's current snapshot to
>=20
> http://www.hip4inter.net/drafts.php
>=20
> (txt, html and diffs as usual) I have made some changes that I have=20
> received since pre-1 version. The biggest change is the UPDATE packet=20
> handling.
>=20
> ESP is still defined as a MUST implementation so that we have=20
> something=20
> common between two implementations.
>=20
> There are some questions that have come up (now or earlier):
>=20
> In 6.2.7 HIP_TRANSFORM
>=20
> XXX: Deprecate MD5 in the light of recent development?
>=20
> Shall we deprecate?
>=20
>=20
> In 6.3. ICMP messages
>=20
> Any need to say more about rate limitations?
>=20
>=20
> In 8.9 Sending UPDATE packets, at bullet 4.
>=20
> Pekka N: "Do we need exponential back off?  If not, why not?
> Usually dropped packets are taken as an indication of
> congestion, and therefore TCP backs off exponentially."
>=20
> I haven't yet edited this one into the text, but it sounds=20
> reasonable.=20
> Any objections?
>=20
>=20
> ISSUES in the tracker:
>=20
> #49 IANA considerations section
>=20
> Requires something more.
>=20
>=20
> #52 Restricting HIT values
>=20
> I haven't yet edited changes into the draft. I will most=20
> likely follow=20
> the discussion that was on the mailing list.
>=20
>=20
> #53 Move LSIs to a separate draft
>=20
> LSIs are still in the current draft version but can be=20
> removed as there=20
> has not been any objections on the mailing list.
>=20
>=20
> #54 Move Appendix A. API issues to a separate draft
>=20
> Same comments as in #53.
>=20
>=20
> #55 User data transport format negotiation
>=20
> The current draft version contains a "negotiation".
>=20
> o TLV type values between 2048-4095 are reserved for new=20
> transport formats.
> o These values do NOT describe the TLV order in the HIP packet (as is=20
> the case with other TLV type values)
> o The transport format TLVs are inserted in the packet in the=20
> order of=20
> preference.
>=20
> The text in the draft related to this issue is still quite=20
> bad and must=20
> be edited.
>=20
> Related to this, Pekka put in one mail a quick proposal about=20
> introducing new TLV type areas, something like:
>=20
>      0- 1023:  Fundamental functionality, WG action
>             - move echo_RESPONSE to 1020
>=20
>   1024- 2047: Reserved
>   2048- 4095: Transform parameters
>   4096-32768: Reserved
> 32768-48XXX: Vendor
> 48XXX-65365: Fundamental functionality, WG action
>=20
> Any comments on this?
>=20
>=20
> /Petri
>=20
>=20
> --=20
> 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
>=20