Subject: [Hipsec] New version of the HICCUPS draft

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 03 Nov 2008 15:42:24 +0200

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
[email-masked]
https://www.ietf.org/mailman/listinfo/hipsec

---

From: Varjonen Samu <[email-masked]>
Date: Tue, 04 Nov 2008 17:23:15 +0200

> As usual, comments are welcome.

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.

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

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.

BR,
Samu Varjonen

---

From: Jan Mikael Melen <[email-masked]>
Date: Wed, 05 Nov 2008 13:52:12 +0200

Hi Samu

Thanks for the comments. See inline.

Varjonen Samu wrote:
> 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.

> 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 

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.

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

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

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

> policy or is there some HIP default?

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

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

> packet it would be enough to say if it contained SEQ_DATA
Will do some rewording.

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

> 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 

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

    Jan

---

From: Varjonen Samu <[email-masked]>
Date: Fri, 07 Nov 2008 13:34:15 +0200

> header value 6 would be TCP.

Sorry for the messed up question but you managed to get the right point 
out of it. This was exactly what I was needing clarification with. It 
was not directly obvious from the text that use IPv6 extension header 
next header values directly. But I would probably use 17 (UDP) with HIP 
DATA.

> specified in this draft. We will have to think about that more in the 
OK

> counter if you like but you don't have to.

Yeah, managed to miss almost full paragraph of text. Maybe then there 
should be something like "Processing window could practically be,..." or 
something that I cannot miss it again :D

> bit more the case where you would like to know it?
OK, brain missfire, it actually would more useful to suppress the NACKs 
after timeouts, for example in streaming apps.

If you do not need ACK do not put SEQ, and if you put SEQ and need ACK 
then the upper-layer will also wait for some content, for example ping 
or sorts (ICMP message wrapped into HIP DATA with SEQ and get back the 
HIP DATA wrapped mirror of the timestamp in ICMP message and ACK). So it 
would already be obvious it succeeded.

> like the ESP replay protection window which is a matter of local policy.

Hiccups 4.3.1 page 11
"
    It is recommended that a host cache HIP
    DATA packets sent with ACKs to avoid the cost of generating a new ACK
    packet to respond to a replayed HIP DATA packet.
"

I think that says it is recommended to cache packets and not just the 
sequence number?

> http://tools.ietf.org/html/rfc5201#section-5.1.3 allows it and section 
:) So, the final conclusion is that what ever RFC5201 says you can 
fragment HIP packets with IP-layer fragmentation.

>    Jan

BR,
Samu