Re: [Hipsec] New version of the HICCUPS draft

Jan Mikael Melen wrote:
> Hi Samu
> 

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

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.

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

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

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

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

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

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?

>>
>> 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 :-)
:) So, the final conclusion is that what ever RFC5201 says you can 
fragment HIP packets with IP-layer fragmentation.

> 
>    Jan
> 

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