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

[Tobias Heer <[e-mail]>]

Hello Jeff, 

Am 24.01.2011 um 16:40 schrieb Ahrenholz, Jeffrey M:

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

Ok, so I'll leave it as it was.
> 
>>> 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.

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

> 
> -Jeff