[Mip6] Re: mip6-precfgkbm-01.txt review

Hello Jari,

Jari Arkko wrote:

> - 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".

O.K. with me, if no one else objects.

> - 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."

This is all O.K. with me, and I'm happy to use it.

> - 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.

The mobile device ought to avoid re-using old sequence
numbers, and the best way I know of is to store them across
reboots.  I think that "SHOULD" is O.K., as long as designers
are aware of the downside.  That is, if the sequence number
is not stored, then:
- a new key would have to be configured at both devices, or
- the correspondent node would reject future binding updates, or
- replays would be possible.

> - 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.

Do you mean that the draft ought to point out what
happens if the correspondent node is not yet configured?
I could just use your paragraph for that...

> - 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.

Well, this is exactly right, though.  Why is it "weak"?
Would you prefer that I omit this bullet?

?                     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...).

The draft already does say this in section 3:

   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. 

Does it need more?

> - 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.

I can delete them, but I don't agree with your statement!

> - 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."

This is fine with me.  I can replace section 2 in
its entirety by this text.

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

The idea is that binding lifetimes can be a lot higher.
The vulnerabilities (small as they are) associated with
return routability are not present.

> - Missing space?
> 
> > abovementioned

This is a word.  Do you prefer having two words instead?

> - Change
> 
> > very, very
> 
>   to just "very"

O.K., but I also think that
"very, very" is correct.

Regards,
Charlie P.

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6