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

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Fri, 21 Jan 2011 14:25:35 -0800

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.

---

From: Tobias Heer <[email-masked]>
Date: Mon, 24 Jan 2011 14:51:58 +0100

Hello Jeff,

thanks for your comments. Responses are in line.

> (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" an…
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…

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

> s/That is it should be a part/That is, it should be a part/
Done.

> independent of the underlying identity technology in use."
I used your suggestion. Thanks.

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

> (where "Section 5.2.8" is a link)
Resolved.

> 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 chos…
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?

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

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

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 24 Jan 2011 07:40:00 -0800

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

I guess there's nothing we can do here, they need to fix the tool.

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

Yes, makes sense.

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

I guess it's 5.1.3 and 5.3:
5.1.3 says IP fragmentation MUST be implemented
5.3 says the HIP packet MUST NOT be fragmented

So fragmentation in 5.3 refers only to piggy-backed data, I think.

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

Yes, SHOULD NOT sounds good. This text seems to say: if the data you are trying to piggy-back on the I1 would cause the HIP packet to fragment, send the data in its own (TCP/UDP/IP) packet following the BEX.

-Jeff

---

From: Tobias Heer <[email-masked]>
Date: Mon, 24 Jan 2011 16:47:47 +0100

Hello Jeff, 

>> processed. The third packet only contains the effect of the agreement.

Ok, so I'll leave it as it was.
> Yes, SHOULD NOT sounds good. This text seems to say: if the data you are trying to piggy-back on the I1 would cause the HIP packet to fragment, send the data in its own (TCP/UDP/IP) packet followin…

Yes, that was my interpretation, too. The text is from the original RFC5201.
I'll change it to a SHOULD NOT and maybe state this more explicitly.

Tobias