Re: [Hipsec] WGLC: draft-ietf-hip-hiccups-01

[Jan Melen <[e-mail]>]

Hi,

Here is link to updated version:
http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt

On Feb 22, 2010, at 8:46 PM, Henderson, Thomas R wrote:

> 
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Gonzalo Camarillo
>> Sent: Tuesday, January 26, 2010 7:19 AM
>> To: HIP
>> Subject: [Hipsec] WGLC: HIP-based overlays
>> 
>> Folks,
>> 
>> we would like to WGLC the set of specifications that describe how to
>> build HIP-based overlays. The documents under WGLC are the following:
>> 
>> http://tools.ietf.org/html/draft-ietf-hip-bone-04
>> http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00
>> http://tools.ietf.org/html/draft-ietf-hip-hiccups-01
>> http://tools.ietf.org/html/draft-ietf-hip-via-00
>> 
>> This WGLC will end on February 23rd. Please, send your
>> comments to this
>> list.
>> 
> 
> comments on draft-ietf-hip-hiccups-01:
> 
> Overall, I think that this document mainly makes sense in the context of HIP BONE and should be folded into that specification.  However, if kept stand-alone, it would help to clarify in the introduction that this specifies a data service with the following semantics:  unordered, duplicate free (subject to receiver ACK cache size and lifetime), reliable (up to a retransmission count), authenticated, and encrypted message-based delivery service.  I would also recommend stating that APIs to higher-level protocols that might use this service are outside the scope of this specification.
> 


Added the semantics and that APIs are outside the scope.


>> 2. Terminology
>> 
>> 
>>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>   document are to be interpreted as described in RFC 2119 [RFC2119].
> 
> This section is empty; probably at the very least it should point to the normative references that define the terminology in use later in the document.
> 

Yes, added reference to RFC 5201 for terminology.


>> 3. Background on HIP
>> 
>> 
>>   The HIP protocol specification [RFC5201] defines a number of messages
>>   and parameters.  The parameters are encoded as TLVs, as shown in
>>   Section 3.1.2.  Furthermore, the HIP header carries a Next Header
>>   field, allowing other arbitrary packets to be carried within HIP
>>   packets.
> 
> Perhaps this section could go away or be refactored if this draft is merged to hip-bone.
> 
>> 4.1. Definition of the PAYLOAD_MAC Parameter
>> 
>>     Length            length in octets, excluding Type, Length, and
>>                       Padding
> 
> are there any minimum or maximum size limitations for this parameter?  Should the maximum length be tied to the maximum size that the HMAC can handle?


Do you mean that we should be more specific than what we are saying about the HMAC itself:
  Payload HMAC      HMAC computed over the data to which the Next
                     Header and Payload Data points to. The size of
                     the HMAC is the natural size of the computation
                     output depending on the used function.

> 
>> 5.1. Handling of SEQ_DATA and ACK_DATA
>> 
>> 
>>   A HIP DATA packet contains zero or one SEQ_DATA parameter.  The
>>   presence of a SEQ_DATA parameter indicates that the receiver MUST ACK
>>   the HIP DATA packet.  A HIP DATA packet that does not contain a
>>   SEQ_DATA parameter is simply an ACK of a previous HIP DATA packet and
>>   MUST NOT be ACKed.
> 
> is it legal to have a HIP DATA with zero SEQ_DATA and zero ACK_DATA?  If not, suggest to say that if SEQ_DATA is missing, ACK_DATA must be present.
> 
> Can SEQ_DATA be present with no PAYLOAD_MAC parameter?


Fixed either SEQ_DATA or ACK_DATA must be present and in case of SEQ_DATA also PAYLOAD_MAC is required.


> 
>>   packet.  A host MAY choose to hold the HIP DATA packet carrying ACK
>>   for a short period of time to allow for the possibility of
>>   piggybacking the ACK parameter, in a manner similar to TCP delayed
>>   acknowledgments.
> 
> Should the ACK_DATA format allow for multiple sequence numbers, if so, to avoid carrying a Type and Length field for each one?


Yes and now it is defined.


> 
>>   1.  The host creates a HIP DATA packet that contains a SEQ_DATA
>>       parameter.  The host is free to choose any value for the SEQ_DATA
>>       parameter in the first HIP DATA packet it sends to a destination.
> 
> This section would be clearer if you replaced "SEQ_DATA parameter" and "SEQ_DATA value" with "SEQ_DATA sequence number".

Fixed.


   Thanks for reviewing the draft
       Jan