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

["Henderson, Thomas R" <[e-mail]>]

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

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

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

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

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

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