[Mip6] mip6-precfgkbm-01.txt review

[Jari Arkko <[e-mail]>]

Hi Charlie,

As a part of ongoing last call I have reviewed this draft.

Overall:

- This is a solid draft and, with some modifications, should
  move forward. Its never been my big favorite due to its
  limited applicability, but it is also very efficient where it
  works. More efficient than pretty much anything else
  anyone has come up with in this space, so...

- I found a few areas where you could give more information
  and context to the reader, e.g., explaining the difference
  and impacts of using this vs. RFC 3775 mechanisms.

- I'm not too happy about all the details in the applicability
  statement text, but I have provided alternative suggestions.

Substantial:

- The title, "Precomputable Binding Management Key Kbm
  for Mobile IPv6" is correct, but at least to me, also not very
  descriptive from the point of view of what people want from
  this. What I think most people are interested to hear about
  is that if you have a preconfigured secret then you can use
  this draft for an efficient form of RO security.

  Suggestion: change title to "Securing Mobile IPv6 Route
  Optimization Using a Shared Key".

- Similarly, I think the introduction could say a few words
  to the reader on how this is different wrt base route
  optimization security. Suggested text below.

  "0. Introduction

       This specification introduces an alternative,
       low-latency security mechanism for protecting
       signaling related to the route optimization in
       Mobile IPv6. The default mechanism specified
       in [1] uses a periodic return routability test
       to verify both the "right" of the mobile node
       to a use a specific home address,  as well as
       the validity of the claimed care-of address.
       This mechanism requires no configuration and
       no trusted entities beyond the mobile node's
       home agent.

       The mechanism specified in this specification,
       however, requires the configuration of a shared
       secret between mobile node and its correspondent
       node. As a result, messages relating to the
       routability tests can be omitted, leading to significantly
       smaller latency. In addition, the right to use a specific
       address is assured in a stronger manner than
       in [1]. On the other hand, the applicability
       of this mechanisms is limited due to the need
       for pre-configuration. 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."

- Details about replay protection. The draft says

>    For this reason, a correspondent
>    node that uses a precomputable Kbm also MUST keep track of the most
>    recent value of the Sequence Number field of Binding Update messages
>    using the precomputable Kbm value.

  I would be interested in knowing whether this MUST requires
  you to keep the sequence numbers in nvm storage or if the
  intent is to only require this on a per-boot basis. The draft
  might benefit from slight text changes depending on the
  answer to this question. For instance, per-boot semantics
  are OK then s/MUST/SHOULD/ might be appropriate. Otherwise
  the text should probably be explicit about the requirement
  to do this with nvm storage.

- Behavior in a misconfiguration or delayed configuration
  cases. The draft says...

>    The Nonce Indices option SHOULD NOT
>    be present.  If it is present, the nonce indices supplied MAY be
>    ignored and are not included as part of the calculation for the
>    authentication data, which is to be carried exactly as specified
>    in [1].

  However, this implies that if the preshared secret configuration
  is entered to the correspondent node but not yet to the mobile
  node, both preshared approach and base Mipv6 procedure will
  fail.

  I think this is in fact correct, due to the need to avoid
  bidding down attacks to base mechanism. But this
  could be explicitly stated somewhere, maybe in Section 3.

- Requirements for assignment of keys. The draft says:

>     -  the method of assignment for keys between the correspondent node
>        and mobile node results in a stronger security association than
>        what can be provided by the Return Routability procedure.

  This seems a bit weak, imho. It seems to imply that there
  are different methods to assigning the keys and we are not
  being told what they are. I would rather simply require that
  there must be per-mobile node preconfiguration of the
  required data (and I see that in Section 3 you already
  prohibited group keys, good...).

  This would also make it less likely that someone misuses this
  draft in ways it was not intended to be used.

- Nits on applicability stament. The draft says:

>     -  diagnostic procedures
>     -  software development and testing

  I would delete these. Of course anything can be
  used for diagnostics.

- Overall applicability text. Given the above comments,
  I wanted to see if I could come up with some suggested
  text. Here's my attempt:

   "This mechanism is useful in the specific scenario where the following
   conditions are all met:

   -   Mobile node and correspondent node are administered within
       the same domain.

   -   The correspondent node has good reason to trust the actions
       of the mobile node. In particular, the correspondent node
       needs to be certain that the mobile node will not launch
       flooding attacks against a third party as described in
       [2, draft-ietf-mip6-ro-sec].

   -   The configuration effort related to this mechanism
       is acceptable.

   -   There is a desire to take advantage of higher
       efficiency or greater assurance with regards to
       the correctness of the home address offered via
       this mechanism.

   Generally speaking, the required level of trust that the
   correspondent node needs for enabling a precomputable Kbm with a
   mobile node is more often found within relatively small, closed
   groups of users who are personally familiar with each other, or who
   have some external basis for establishing trustworthy interactions.
   A typical example scenario where this mechanism is applicable is
   within a corporation, or between specific users. Application in the
   general Internet use is typically not possible due to the
   configuration effort. Application at a public network operator
   is typically not possible due to requirements placed on the
   trustworthiness of mobile nodes."

- Is there any change wrt the lifetime of bindings created
  through this mechanism vs. RFC 3775? Seems like they
  could be higher.

Editorial:

- Citations

>    The first citation is normative, and the second citation is
>    informative only.

   I'd prefer separate lists, most I-D tools should generate
   them. Don't worry about this if your tool has trouble,
   however.

- Missing space?

> abovementioned

- Change

> very, very

  to just "very"

--Jari


_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6