Re: [Hipsec] New version of the HICCUPS draft

[Varjonen Samu <[e-mail]>]

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
> [e-mail]
> 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.

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
_______________________________________________
Hipsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hipsec