Subject: [Mip6] LC review of draft-ietf-mip6-precfgkbm-01.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 16 May 2005 15:02:43 -0400

Hi.

I've also reviewed this document in response to the IETF LC.

General comment. This document really needs another pass from an
editorial perspective in the sense of being understandable to a
general reader who doesn't already know all about this technology.
The document needs to have more text providing background,
applicability, context, etc. Morever, for someone to do a security
analysis, I suspect there needs to be more background context to
understand what is being proposed and why. E.g., who is assumed to
have this pre-configured info, and how/when do they use it? (Don't
assume that a reader of this document has just read RFC 3775 and is
familiar with all its details!)

I don't think a lot of work is needed here, but a pass needs to be
made with an eye towards making it more understandable to a general
reader is in order.

Personally, I'm not a big fan of this, as I believe it has rather
limited applicability and does not scale. That is, a CN needs per-MN
configuration information. Where will this be useful in practice? Not
in large deployments, I suspect. But in small deployments, I have to
wonder if this assumption actually plays out:

> 2. Applicability Statement
> 
>    Preconfigured shared keys (such as Kcn) between a mobile node and a
>    correspondent node are useful in several specific scenarios:
> 
>     -  mobile node and correspondent node are administered within the
>        same domain, and the correspondent node has good reason to trust
>        the actions of the mobile node

That is, in small deployments that HA and CN may well end up being
topologically near each other (e.g., located in the same region), in
which case the triangular routing isn't a big problem performance
wise. Where you you really want RO to work well is when the MN and CN
are topologically close to each other, but the HA is far away.

I think the applicability statement should explicitely point out that
per-MN configuration is needed on the CN, and part of the
applicability is environments where this is deemed acceptable.

Abstract  really needs beefing up.

Document would benefit from an introduction section targetted towards
a more general reader. As it is, it just starts off with details.

>    When a Binding Update is to be authenticated using such a
>    precomputable binding key (Kbm), the Binding Authorization Data
>    suboption MUST be present.  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].

Seem odd that nonce indicies "SHOULD NOT" be present, but upon receipt
it is only a "MAY" that ie be ignorred. Seems like the default would
be to ignore them, since they aren't supposed to be included. Or, if
they are included, do you really want to say they need to be processed
as defined in the base MIPv6 spec? 

Also why are they not covered by the authentication data? Is this
consistent with the base spec? And does it have any security
implications?

>     -  the correspondent node has some guarantee that the mobile node
>        will behave properly (perhaps by contractual agreement)

I must not understand something here. I read the above as saying that
this draft introduces vulnerabiilties not present in the base MIPv6
space, but that those vulnerabilities are acceptable because the MN
and CN are "are under contract, so MN won't be bad." Am I
understanding this correctly?

>     -  diagnostic procedures
> 
>     -  software development and testing

I don't understand these. Are there any examples (and if so, include
them in the document)

Question: when are these extensions used? E.g., what happens if MN has
them configured but CN does not (or vice versa)? Is there a fallback?
is there negotiation? Do things still work?

>    are under the same administration.  The return routability procedure
>    is RECOMMENDED for all general use and MUST be the default, unless
>    the user explicitly overrides this by entering the abovementioned
>    preconfigured data for a particular peer.

Which user? On the MN? on the CN? both?  That is, does the MN (not the
CN) choose when to enable this? How does the CN know which to use?

>    protected against reboots.  If the mobile node were to send a fresh
>    Binding Update to its correspondent node every hour, 24 hours a day,
>    every day of the year, and utilize the same care-of address every
>    time, this would require changing keys every 7 years.  Even if the

Aren't these numbers disingenious? I.e., isn't the timeout associated
with BUs on the order of only a few minutes, and much less than one
hour?

(well, later the document hints that longer lieftimes might be in
use...)

>    There is no upper bound on the lifetime defined for the precomputable
>    Kbm.  As noted, the key is very, very likely to be quite secure
>    over the lifetime of the security association and usefulness of
>    applications between a mobile node and correspondent node that fit
>    the terms specified in section 2.

The document really needs more text about lifetimes. For one thing, it
seems like bad things will happen of the MN and CN have different
ideas of what the lifetime should be.  What does this document
_recommend_? Shouldn't the lifetimes be part of the configuration?
Or???

References need updating.

Thomas

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

---

From: "Charles E.Perkins" <[email-masked]>
Date: Mon, 16 May 2005 13:51:19 -0700

Hello again Thomas,

> familiar with all its details!)

I think we have to assume some familiarity with RFC 3775.  It is
unrealistic to think that someone would implement this
specification without first understanding Mobile IPv6.

I also don't believe we can specify:

>         ...                     who is assumed to
> have this pre-configured info, and how/when do they use it?

As long as they get the key and configure it, and follow
the specification, what else needs to be said??

Or maybe I am missing your point, and if you have some
suggested text I could add it to the specification.

> made with an eye towards making it more understandable to a general

Do you mean a reader who has no clue about RFC 3775?

It does say this:

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

Should it say more?

> Abstract  really needs beefing up.

This is a very, very small specification.  I think it
should stay that way.  What additional idea do you think
should be expressed in the abstract?

> a more general reader. As it is, it just starts off with details.

Jari sent some text for the Introduction, and I am planning
to use that.  Do you think it is sufficient?

> as defined in the base MIPv6 spec?

I really wanted to say that they are ignored for the case
of preconfigured keys.

> consistent with the base spec? And does it have any security

Since they are ignored, I am sure there is no security implication.
However, perhaps they should be covered by the Authenticator, to
avoid special rules in this case for the calculation.

I think it's better to just not send the Nonce Indices option
at all.

> understanding this correctly?

The draft clearly states the applicability conditions.
Under these conditions, the danger of misusing care-of
addresses is supposed to eliminated.  If there is a danger
of misusing care-of addresses, then the draft is not
applicable.  Thus, we can say that the vulnerability
of misusing care-of addrsses, which would otherwise be
present, is prevented by adherence to the applicability
conditions.

> I don't understand these. Are there any examples (and if so, include

I believe that everyone who has debugged a Mbbile IP has used
some sort of preconfigured keys to do the testing.  How should
I express this in the document?

> is there negotiation? Do things still work?

As Jari points out, things don't work well when the
preconfigured keys are not preconfigured.  Also, they
don't work well when the wrong keys are preconfigured.
There is a very long list of things that don't work
when things are broken.  For instance, if there is a
bug in the Mobile IPv6 implementation, it does not
work.

This is how Mobile IPv4 works.

> CN) choose when to enable this? How does the CN know which to use?

Both sides have to agree.  I don't understand how it could
be different.  The user does explicitly override the return
routability procedure for the particular peer.

> with BUs on the order of only a few minutes, and much less than one

The lifetime for the Binding Update is in the Binding Update.  It can
be a lot longer if there are preconfigured keys, since the danger of
replay protection is nearly absent.  The binding lifetime for the
preconfigured keys is until somemone wants to reconfigure the machines.
The vulnerability associated with return routability does not exist.

> _recommend_? Shouldn't the lifetimes be part of the configuration?

The lifetime of the Binding Update is in the Binding Update
message.  There is no expiration lifetime associated with the
preconfigured key, because there is no significant danger of
replay. 

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 May 2005 18:19:09 +0300

>bug in the Mobile IPv6 implementation, it does not
Generally speaking we want our protocols to fail
gracefully, have reasonable fallbacks when something
is not configured correctly etc. However, this does
not always apply. For instance, in this case I believe
we have some worries about bidding down attacks,
if we were to default to RR if this procedure fails (or
vice versa, neither procedure is strictly more secure
than the other).

So, I believe what Charlie you have written for the
behaviour on this point is more or less correct. But
as I pointed out in my review it would be useful to
document the rationale in Section 3. No, I don't
have text beyond what I have written above, sorry.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 21 May 2005 08:05:15 +0300

Charles E.Perkins wrote:

>>is not configured correctly etc.
>>    
>>
>In this case, the graceful fallback position is that
>the mobile node and correspondent node can't use
>route optimization until the shared data is corrected.
>Even so, they ought to be able to communicate by way
>of the home agent.
>  
>
Yes. And this is good enough for me.

(Even better would have been if we could
fallback to regular RO, but as explained in
previous e-mails, I don't think we can do that.)

--Jari

---

From: "Charles E.Perkins" <[email-masked]>
Date: Fri, 20 May 2005 19:14:58 -0700

Hello folks,

I have created a revised specification according to
comments received during Last Call.  It is available
at the following URL:
   http://people.nokia.net/~charliep/txt/mobilev6/precfg.txt

I would like to submit it to the Internet Draft
directories ASAP, so please let me know if I have
made appropriate resolutions for your comments.

I have one comment on some previous e-mail...

I think that is pretty much O.K.  It might be nice for
some indication to be brought to the user's attention,
so that the problem could be identified and corrected.
But, user interface details don't belong in this
document, I don't think.

Regards,
Charlie P.