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

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

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

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

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