[Hipsec] comments on draft-ietf-hip-rfc5201-bis-04

["Ahrenholz, Jeffrey M" <[e-mail]>]

Here are some comments on (the first part of) the 5201-bis draft. First are some high-level comments and then small editorial nits.

(1) The terms "Host Identity" and "Host Identifier" do not mean the same thing in 4423-bis and 5201-bis, when comparing the definitions/terminology sections. Section 3 also uses "Identifier Tag" and "Identity Tag" inconsistently. I'd prefer to always call the HIT the "Host Identity Tag".

(2) I think the draft-ietf-hip-rfc4843-bis-00 document needs to be updated to reflect the new HIT format of: 28-bit prefix + 4-bit OGA + 96-bit pubkey. Section 3 mentions 96 bits from the HI while 4843-bis still has 100 bits. The OGA (Section 3.1, Appendix E) is not mentioned in 4843-bis, just the Context ID.

(3) Section 5.2 the 2nd table of parameter type ranges lists "handshake", and this is used elsewhere in the document, but not necessarily defined. We know the "HIP handshake" is synonymous with "HIP base exchange" but maybe that should be spelled out somewhere?

Below are the nits...

-Jeff

Section 1. Intro
s/called HIP association/called a HIP association/
s/That is it should be a part/That is, it should be a part/

Section 1.3
s/define the detail packet formats/define the detailed packet formats/

Section 3.1
The text that says "Firstly, the fixed length .... Secondly, it presents ...", I think this should use same text as Section 5.3 of 4423-bis; or revise it with something like:
"First, the fixed length of the HIT keeps packet sizes manageable and eases
protocol coding. Second, it presents a consistent format for the protocol,
independent of the underlying identity technology in use."

Section 3.2 references FIPS.95-1.1993 and if you follow this reference, it is
not about SHA-1 (it is much more dreary); it seems like the latest FIPS 180 reference is good enough for both SHA-1 and SHA-256 (I think the RFC 5201 [FIPS95] reference to PUB 180-1 1995 somehow became FIPS.95-1.1993)

Section 3.2 second paragraph, the HTML version says "Section Section 5.2.8"
(where "Section 5.2.8" is a link)

Section 3.2 mentions Section 4.2 and 6 of [I-D.mcgrew-fundamental-ecc]
the HTML tool incorrectly links Section 4.2 (of current doc)

Section 4.1 says "In the first two packets, the hosts agree on a set of cryptographic identifiers and algorithms..."; wouldn't you say the first 3 packets, since the 3rd/I2 packet contains the chosen HIP_CIPHER?

Section 4.1.1 s/Second, hand, the design/Second, the design/
(leftover text from RFC 5201)

Section 4.1.2 s/limits the usability of an old/limits the usability that an old/

Section 4.1.3 s/as well as it uses/as well as uses/

Section 4.1.7 s/if they are remain/if they remain/

Section 4.2 "rekey expiring user data security associations" - I'm not sure
that the words "user data" are needed?

Section 4.3 s/sendin an I1/sending an I1/

Section 4.5.1 s/in the place of the/in place of the/

Section 5.3.1 says "The HIP packet, however, MUST NOT be fragmented." while
Section 5.1.3 says "A HIP implementation must support IP fragmentation/reassembly." ...I think 5.3.1 is discussing HIP packets having an upper-layer payload, but this should be clarified.