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. Still, how does this text (same section) apply if the peer does not store the R1 generation counter? "Initiators are protected against R1 replays by a monotonically increasing "R1 generation counter" included in the R1." > Then, later we have in section 6.16. Handling State Loss: > > In the case of system crash and unanticipated state loss, the system > SHOULD delete the corresponding HIP state, including the keying > material. That is, the state SHOULD NOT be stored on stable storage. > If the implementation does drop the state (as RECOMMENDED), it MUST > also drop the peer's R1 generation counter value, unless a local > policy explicitly defines that the value of that particular host is > stored. An implementation MUST NOT store R1 generation counters by > default, but storing R1 generation counter values, if done, MUST be > configured by explicit HITs. Ok, so a system crash effectively resets the generation counter without expiring the HI. However, what about the case when the peer really uses the generation counter for replay protection purposes? This will possibly break connectivity for a long time... >> I suggest to add the following text: >> >> "If a roll over is detected, the associated HIs SHOULD be removed and >> new ones should be generated." >> >> Note, however, that such a change would also invalidate ACLs and HI-IP >> lookup information based on the original HIs. > > I believe a responder could be tricked into exhausting it's counter > values by a malign initiator? This is bad because changing the identity > would affect all host associations, not only the one with the malign > initiator? Your described vulnerability strongly depends on how a system maintains puzzle generations: "Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations. A system's local counter MUST be incremented at least as often as every time old R1s cease to be valid." Furthermore, should the latter sentence be rephrased as follows for higher clarity? "A system's puzzle generation counter MUST be incremented at least as often as old puzzle values cease to be valid." BR, René -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21429 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
