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