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

[Thomas Narten <[e-mail]>]

Thanks Jari for the review.

Some followup on your comments (I've just read the document as well).

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

I'd go a bit further and add "static" or "pre-configured" to "Shared
Key". Or is the former assumed when the term "shared key" is used?

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

I definitely agree.

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

I think the above is good, and it would have saved me some thinking
had I read it before reviewing the document!

Actually, I view that last part of the above as quite significant.
There may also be problem related to broken implementations and such,
if a CN has a binding cache entry with a long time out that is no
longer correct (e.g., a COA address has been assigned to another
node).

Think also about a hacked cell phone that is able to do a DOS attack
on a specific server/host pair.

> - 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 (IMO limited) applicability makes me wonder if we should publish
this as experimental rather than standards track.

Thomas

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