On 10/18/2012 05:50 AM, Miika Komu wrote:
Hi,
On 10/18/2012 12:42 PM, Miika Komu wrote:
Hi,
On 10/17/2012 04:04 PM, René Hummen wrote:
Hi,
On 16.10.2012, at 21:00, Miika Komu <[email protected]> wrote:
On 09/23/2012 06:35 PM, René Hummen wrote:
Hi all,
I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some
technical as well as editorial issues that I consider worth
discussing
and fixing. Please note that especially the technical issues
regarding
the used packet space may not be considered problematic in case of
everyday Internet connections. However, resource-constrained
environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard
payload limits. Here, a few bytes of additional packet size can
determine whether packets need to be fragmented or not. Therefore, I
think, we should also consider these scenarios in the basic HIP
specification that is shared by all HIP variants.
I structured my feedback into different topics highlight by ###.
Technical issues:
------------------------
### R1 Counter ###
4.1.4. HIP Replay Protection
"The R1 counter SHOULD NOT roll over."
No explanation is given what implementors should do when a roll over
occurs.
Did you notice that the same section continues with:
Upon conclusion of an active HIP association with another host,
the
R1 generation counter associated with the peer host SHOULD be
flushed. A local policy MAY override the default flushing of R1
counters on a per-HIT basis. The reason for recommending the
flushing of this counter is that there may be hosts where the R1
generation counter (occasionally) decreases; e.g., due to hardware
failure.
Yes, but this describes the behavior of the peer, not of the host
sending the R1 counter value. Hence, this does not mention how to deal
with roll overs.
You're right, this is an open issue.
I think the whole R1 counter concept is a bit cumbersome because it is
buried into local policy issues and the roll over is problematic. I
would suggest removing the R1 counter and simply mandating the
Responder to send ECHO_REQUEST_SIGNED and the Initiator to send it in
I2. Since the nonce is fresh and signed, it should provide replay
protection even against a man-in-the-middle attacker.
Opinions?
I am using R1 counter for AES-CTR in HIP encryption in DEX for the CTR
offset. You are pointing out how this MAY be a problem. Got to block
time out to work through this.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
