Re: [Hipsec] New version of the HICCUPS draft

Varjonen Samu <> Tue, 04 November 2008 15:23 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 74E0C3A69C5; Tue, 4 Nov 2008 07:23:27 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D9F33A69C3 for <>; Tue, 4 Nov 2008 07:23:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z0F0x1M3WLcO for <>; Tue, 4 Nov 2008 07:23:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2BA2E3A69C5 for <>; Tue, 4 Nov 2008 07:23:24 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB0AE21AF4F; Tue, 4 Nov 2008 17:23:21 +0200 (EET)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 04859-05; Tue, 4 Nov 2008 17:23:15 +0200 (EET)
Received: from ( []) by (Postfix) with ESMTP id 7E9A221AF4C; Tue, 4 Nov 2008 17:23:15 +0200 (EET)
Received: from [] ( []) by (Postfix) with ESMTP id 6A34825ED06; Tue, 4 Nov 2008 17:23:15 +0200 (EET)
Message-ID: <>
Date: Tue, 04 Nov 2008 17:23:15 +0200
From: Varjonen Samu <>
User-Agent: Thunderbird (X11/20080925)
MIME-Version: 1.0
To: Gonzalo Camarillo <>
References: <>
In-Reply-To: <>
X-Virus-Scanned: amavisd-new at
Cc: HIP <>
Subject: Re: [Hipsec] New version of the HICCUPS draft
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Gonzalo Camarillo wrote:
> Folks,
> we have just submitted a new version of the HICCUPS draft:
> As usual, comments are welcome.
> Cheers,
> Gonzalo
> _______________________________________________
> Hipsec mailing list


Some comments and questions on draft-nikander-hip-hiccups-01. These are 
the points where I would like to see some clarifications.

In section 3 in the definition of the HIP DATA packet, it says that the 
optional parameters are SEQ and ACK and on the next line they are 

Same section in the reference to RFC5201 and end of section 2.1.1, a 
question. Currently Next Header is set to 0x3B (59) "No Next Header", 
Should there be "TBD IANA" for a new value for this field because now 
there is data after the header and the definition of 59 is
"Note that there is also a "dummy" extension header called No Next 
Header that has a value of 59. This is a placeholder that when found in 
the Next Header field indicates that there is nothing after that 
extension header." and this says there is *nothing* after the header.

section 3.3 Next Header, "identifies the data that protected by this..." 
to "Identifies the data that is protected by this..."

Section 4.2 the generation of a HIP DATA packet. Where and how exactly 
is the data gotten from the upper-layer? This is not handled in the 
draft. To me this sounds like it should be handled in native API draft 
for natively HIP aware applications  and for legacy applications by 
doing local policies like "protocols that would use UDP should use HIP 
DATA instead". Now the draft just gets the data from "somewhere".

Same section point 1, the host just takes a sequence number. I think it 
would be easier to just use monotonically increasing sequence numbers as 
the original SEQ and its UPDATE id does. Then the book keeping on which 
numbers are used is much simpler.

Same as above, more clarification on the processing window, duration, 
how it is defined and so on.

Same section point 4, how is RTT estimate calculated? Is there some 
uniform way to do this or can implementors just decide on one. For 
example TCP has some initial values and information on how to calculate 
the estimates, should we have something similar?

Same section point 5, is the DATA_ENTRY_MAX totally based upon local 
policy or is there some HIP default?

Same section and point, about the error notification and its 
counterpart, should also ACKed HIP DATA packets be ACKed to the 
application. This actually could be too much but for some applications 
it could be a useful socket option in Native API.

Section 4.3 "The host MAY responds..." to "The host MAY respond..."

Same section, "... if the packet contained SEQ_DATA and PAYLOAD_HMAC 
parameter. Because PAYLOAD_HMAC is mandatory parameter in HIP DATA 
packet it would be enough to say if it contained SEQ_DATA

Section 4.3.1, How long ago is this recently received, so how long and 
how much HIP DATA packets do I need to cache.

Same section, " avoid generating a new ACK packet to respond to a 
*replayed* HIP DATA packet". What is the valid reason for replay any 
packets and is it not that the idea in using sequence numbers should be 
used to fight against replay attacks, as it says on the same paragraph?

A question about the fragmentation in section 5. In section 5.3. in RFC 
5201 it says that HIP packets MUST NOT be fragmented, doesn't this 
include IP-layer fragmentation or not? Or did I just misinterpret that 

Samu Varjonen
Hipsec mailing list