Review of draft-ietf-mip6-precfgkbm-03.txt

[Bernard Aboba <aboba@internaut.com>]

Overall, I do think it makes sense to have a pre-configuration option for
route optimization, if only for testing purposes.  The document does
include discussion of applicability, ableit in Section 3 (I'd suggest this
discussion be placed earlier in the document, by swapping Sections 2 and
3).


Section 1:

This section is somewhat unclear about the security properties as
compared to RFC 3775.  In particular, there are two statements that appear
ambiguous:

"In addition, the right to use a specific address is assured in a stronger
manner than in [1]."

and

"This mechanism is also limited to use only in
scenarios where mobile nodes can be trusted to not misbehave, as the
validity of the claimed care-of addresses is not verified."

My assumption is that the address referred to in the first statement is
the HoA.  Otherwise, the statements appear to contradict each other.

Section 4

"  A mobile node MUST use a different value for Kcn for each node in
   its Binding Update List, and a correspondent node MUST ensure that
   every mobile node uses a different value of Kcn. "

What is the correspondent node supposed to do if it finds that more than
one mobile node has the same value of Kcn?  Is there an error message that
is supposed to be sent, or is the implementation supposed to flag this
error when it is configured incorrectly?

"  Given typical mobility patterns, there is little danger of replay
   problem"

I think this assumes that the replay counter is committed to stable
storage.  This requirement is not stated explicitly in the document;
"keeping track" might just mean keeping a value in memory.

"   Note that where a node has been configured to use the mechanism
   specified in this document with a particular peer, it SHOULD NOT
   attempt to use another mechanism, even if the peer requests this
   or claims to not support the mechanism in this document.  This is
   necessary in order to prevent bidding down attacks."

Actually "bidding down" attacks are prevented by verifying that the nodes
have negotiated the highest possible security level.  It would appear that
this advice requires that the MN and CN use preconfiguration, even if a
higher level of security is available.  Given the use of this draft in
testing, I think the issue is not "bidding down" per se, but more one
of reproducibility.  You'd want preconfiguration to be used so that a
particular code path can be tested, and not some other path that might
be triggered by a negotiation.

References
----------

RFC 3775 has been assigned an RFC #, so it can be cited.  Typical practice
is to have a different subsection for normative and informative
references.