Re: [Hipsec] New version of the HICCUPS draft

Jan Mikael Melen <Jan.Melen@nomadiclab.com> Wed, 05 November 2008 11:52 UTC

Return-Path: <hipsec-bounces@ietf.org>
X-Original-To: hip-archive@lists.ietf.org
Delivered-To: ietfarch-hip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF3F3A699A; Wed, 5 Nov 2008 03:52:21 -0800 (PST)
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB703A6998 for <hipsec@core3.amsl.com>; Wed, 5 Nov 2008 03:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWIcaeG4QWgD for <hipsec@core3.amsl.com>; Wed, 5 Nov 2008 03:52:19 -0800 (PST)
Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 12D773A6768 for <hipsec@ietf.org>; Wed, 5 Nov 2008 03:52:18 -0800 (PST)
Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9E28C1F43DF; Wed, 5 Nov 2008 13:52:12 +0200 (EET)
Received: from despair.unknown.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 50C081F43DC; Wed, 5 Nov 2008 13:52:12 +0200 (EET)
Message-ID: <491188EC.7000302@nomadiclab.com>
Date: Wed, 05 Nov 2008 13:52:12 +0200
From: Jan Mikael Melen <Jan.Melen@nomadiclab.com>
User-Agent: Thunderbird 2.0.0.7pre (X11/20080131)
MIME-Version: 1.0
To: Varjonen Samu <samu.varjonen@hiit.fi>
References: <490EFFC0.6060304@ericsson.com> <491068E3.5050203@hiit.fi>
In-Reply-To: <491068E3.5050203@hiit.fi>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] New version of the HICCUPS draft
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: hipsec-bounces@ietf.org
Errors-To: hipsec-bounces@ietf.org

Hi Samu

Thanks for the comments. See inline.

Varjonen Samu wrote:
> Gonzalo Camarillo wrote:
>> Folks,
>>
>> we have just submitted a new version of the HICCUPS draft:
>>
>> http://www.ietf.org/internet-drafts/draft-nikander-hip-hiccups-01.txt
>>
>> As usual, comments are welcome.
>>
>> Cheers,
>>
>> Gonzalo
>> _______________________________________________
>> Hipsec mailing list
>> Hipsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/hipsec
>
> Hi,
>
> 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 
> SEQ_DATA and ACK_DATA.

Oops... Will fix this one.

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

I'm a bit confused where are you referring at? Because we are saying in 
section 2 "The HIP protocol specification RFC5201 defines a number of 
messages and parameters.  The parameters are encoded as TLVs, as shown 
in 2.1.2.  Furthermore, the HIP header carries a Next Header field, 
allowing other arbitrary packets to be carried within HIP packets." and 
in section 2.1.1 "this document describes processing for Next Header 
values as they are carried on the HIP DATA packet." So we are basically 
saying that you would use the next header value of the HIP header in the 
same fashion as you would use with any other IPv6 protocol e.g. next 
header value 6 would be TCP.

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

Will fix that.

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

I agree that it should be somehow defined but I don't want to limit to 
only current type of APIs as there might be new ones and even 
implementation specific APIs which still could use the HIP_DATA as 
specified in this draft. We will have to think about that more in the 
future versions.

> 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.
>
There is no reason to do sequence counter that starts from 1 and is 
incremented every time host sends a packet, because data packet may be 
sent even if the hosts don't have a HIP association between them and 
thus the receiver doesn't have any context for the peer and will only 
store for a short period of time the last seen SEQ value.

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

there is an example included that you may implement it as an wrap-around 
counter if you like but you don't have to.

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

Maybe... this is really a implementation policy.

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

probably you mean DATA_RETRY_MAX. Yes this again is implementation policy.

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

I fail to see the use for this kind of function could you elaborate a 
bit more the case where you would like to know it?

>
> Section 4.3 "The host MAY responds..." to "The host MAY respond..."
>
Fixed that one.

> 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
Will do some rewording.

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

You do not need to cache the packets only the sequence numbers. It is 
like the ESP replay protection window which is a matter of local policy.

>
> Same section, "...to 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?

If the host replied to a HIP_DATA packet containing SEQ_DATA#h1, 
PAYLOAD_HMAC with a packet containing SEQ_DATA#h2, ACK_DATA#h1, 
PAYLOAD_HMAC it should not create a new packet containing only 
ACK_DATA#h1 because then you would still have a timer running for the 
SEQ_DATA#h2 that it has sent which would mean that you increase the 
number of packets sent through the network.

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

Interesting section "HIP Fragmentation Support" 
http://tools.ietf.org/html/rfc5201#section-5.1.3 allows it and section 
5.3 denies :-)

    Jan

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec