Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09

From: [email-masked] (Henderson, Thomas R)
Date: Sat Jan 31 18:04:32 2004

Petri, here are some comments:

General:
i) In reading through the draft, it struck me that there are
lots of instances where HIP silently drops packets (if something
goes wrong, etc.).  For example, if a certain parameter type
is not supported, HIP drops the packet.  While it is necessary
to prevent exploitation of a "REJECT" mechanism, I think that
there probably will be some use to having a HIP REJECT (with
type code to denote the error) to tell the peer what went
wrong.  Something to think about...

ii) I'd like to ask that, when the issue tracker is restarted,
that "possible removal of Birthday count" be added to the list.
(see previous email message:
http://honor.trusecure.com/pipermail/hipsec/2003-December/000365.html)

Specific:
- top of page 5, "identies" -> "identities"

- The state machine doesn't seem to allow for retransmitted I2s.
If in ESTABLISHED, and I2 is received, it should not necessarily
cause drop of SAs or drop of I2 (due to birthday check fail)--=20
it may just mean that R2 needs retransmitted.  This means that=20
even though distinction between Initiator and Responder can mostly=20
be dropped when entering ESTABLISHED, there is still the=20
possibility that the Responder will need to retransmit the R2.

- how about "UPD" -> "UPDATE" (global change)?

- I must have missed this in previous drafts, but why do we need
to have different parameter type codes for BIRTHDAY_COOKIE?

- regarding the critical parameter, what is the situation for
which a critical parameter is not recognized by the recipient
(Sec 6.2.1, page 29)?  Shouldn't this cause an increment
of HIP version number?

- in the HOST_ID_FQDN parameter definition, there is a typo
error "FDQN" -> "FQDN"

- there are a couple of instances where packet processing
text is placed in the parameter definition section.  e.g.,
HMAC calculation and processing 6.2.11 and signature processing
(6.2.12)-- I think these sections should be in the packet
processing section 8, and keep section 6 limited to specifying
the syntax and semantics of the parameter fields.

- Section 8.2-- processing incoming application data.=20
  - first comment is that in sentence 1, it implies that IPsec
    SAs are selected based on IP addresses, which is not=20
    necessarily the case for BEET mode.
  - in sentence 4, should note that demultiplexing is based=20
    on HITs *and port numbers*

- page 61, "pacoket" -> "packet"

Tom

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]]
> Sent: Friday, January 30, 2004 6:03 AM
> To: [email-masked]
> Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09
>=20
>=20
> I uploaded pre2 version of the draft-moskowitz-hip-09 to
>=20
> http://hip4inter.net/drafts.php
>=20
> There are both text and html versions as well as diffs between 08 ->=20
> 09pre2 and 09pre1 -> 09pre2.
>=20
> Please, feel free to comment. Shortly (before leaving home):
>=20
> I have fixed the state machine (a bit) and changed the=20
> section 8 to meet=20
> the current idea of sending I1 as a response to an unknown=20
> ESP. This may=20
> still require fixes...
>=20
> NES is changed to UPD, NES_INFO parameter to NES, state names=20
> changed in=20
> the state machine, RESYNC state added and R-bit added to the=20
> HIP header=20
> for RESYNC purposes (this requires still some thinking).
>=20
> HIP_SIGNATURE (1&2) have new type numbers, we propose to leave some=20
> empty space behind them for possible future use (at the same=20
> time, HMAC=20
> type was changed to keep it below SIGs).
>=20
> Appendix F contains now help for checksum verification.
>=20
> Have a nice weekend!
>=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]
>=20
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>=20