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.
Authors, I find this text a bit tricky to read because does not use the
absolute terms of "Initiator" and "Responder". I suggest improving the
text unless the R1 generation counter is used for e.g. UPDATE. The same
applies to section 6.16. (Handling State Loss).
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."
I assume that you mean initiator with peer? I think it's in the best
interest of the initiator to store it as it improves security. If it
doesn't and always accepts it, then the communications is less secure.
If you mean the responder, I think it can opt out and not send the R1
generation counter at all, since it's optional. If it does send the
generation counter, it MUST store the counter.
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...
There's several editorial issues with this text:
* As said earlier, please use Initiator and Responder terms for clarity
avoid ambiguity with relative terms?
* The last sentence is in conflict with section 6.8: "The system MUST
store the received R1 generation counter for future reference"
* It is unclear if the stable storage applies to R1 counters or not.
Particularly, I think the authors should break down the crashing cases
separately:
1. Initiator crashes: it should reset the stored counter and accept any
new values from Responders.
2. Responder crashes: it should start with a new counter value.
Initiating hosts with previous contact with the Responder may experience
some delay until the Host Association at the Initiator expires and it
resets the counter value.
3. Both crash. The previous case combined; no issue here.
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."
4.1.2. Puzzle Exchange:
It is RECOMMENDED that the Responder generates a new puzzle and new
R1s once every few minutes
I take my comment back; the counter is liked to puzzle generation which,
in turn, is recommended to be periodical rather than based on the number
of iniatiators. So, the roll over is bound to time.
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."
Fine by me.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
