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

[Tobias Heer <[e-mail]>]

Hello Jeff,

thanks for your comments. Responses are in line.


Am 21.01.2011 um 23:25 schrieb Ahrenholz, Jeffrey M:

> 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".
I have taken care of the Identifier vs. Identity issue. It is now always Identity when a concrete representation of a Host's identity is meant. In general, the Host Identity is an identifier (not the identity of the host). I left identifier when the identifier-nature was important. Thanks for noticing it. 

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

Julien has agreed to do this update as soon as we are done with the requirements for the new ORCHID document.
I think the time has come to do that.

> 
> (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?
> 
I  added HIP Base Exchange to the "Definitions" section and explained that it is the HIP handshake.

> 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/
> 
Done.

> 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."
I used your suggestion. Thanks.

> 
> 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)
Done. Removed the reference.

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

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

This is odd. The HTML version tries to be smart but fails. There is no link pointing to that section in the xml document. I have no clue what to do because there is nothing I could remove.

> 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?
I'd say that the agreement has already been reached when the second packet was processed. The third packet only contains the effect of the agreement.
Does that make sense?

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

> Section 4.1.2 s/limits the usability of an old/limits the usability that an old/
> 
Done.

> Section 4.1.3 s/as well as it uses/as well as uses/
> 
Done.

> Section 4.1.7 s/if they are remain/if they remain/
> 
Done.


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

> Section 4.3 s/sendin an I1/sending an I1/
> 
Done.

> Section 4.5.1 s/in the place of the/in place of the/
> 
Done.

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

You mean 5.3 and 5.3.1?

The case is a bit schizophrenic anyway. I think the requirement in 5.3 should be lowered to a SHOULD NOT be fragmented, emphasizing the potentially negative effects of fragmentation.
What do you think?


Thanks again for your comments.

Tobias