Subject: [Hipsec] more clarifications to the base draft

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 9 May 2005 10:23:17 -0700

Petri,
I have some comments/suggestions after reviewing the packet formats and
packet processing sections of the base draft, while going over our
implementation.

Checksum
- It's a little confusing that the HIP header's IPV6 next header should
be IPPROTO_NONE=59 but when computing the HIP checksum the pseudo-header
is IPPROTO_HIP=99. These values make sense though, so I'm not suggesting
any changes.

General note: may want to consistently write "Initiator" versus
"initiator", and "Responder" versus "responder"

TLV format
- mentions transport formats using values 2048 to 4095
  "Currently, one transport format is defined: the ESP transport format
[23]."
  What does this mean, since ESP does not use parameters that are
2048-4095?

HIP_TRANSFORM
Although it says there are 6 maximum suite IDs, this is for the R1, and
the I2 HIP_TRANSFORM contains 1 maximum suite ID (the chosen suite
actually used in the I2.)

HMAC
Can there be both types of ECHO_REQUESTs (covered/not covered by
HMAC+SIG) in a HIP packet?
In the section on the I2 Packet, the "either" hints at there being only
one possible type, but I think this came up once during an interop.

CER
The description for this packet seems unclear and may need to be
rewritten.

These two statements seem slightly contradictory:
(Processing incoming I1) Under no circumstances does the HIP state
machine transition upon sending an R1.
(R1 management) An implementation MAY keep state about received I1s and
match the
   received I2s against the state, as discussed in Section 4.1.1.

Instead of RFC 2451, when referring to AES we probably want RFC 3602.
(RFC 2451 is older and contains no mention of AES.)

-Jeff

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec