multi6-threats-00.txt vs. MIPv6 - different strength verifications?

[Erik Nordmark <Erik.Nordmark@sun.com>]

Comparing the threats in draft-nordmark-multi6-threats-00.txt and
the residual threats in mobile IPv6 there are some interesting differences.
These differences are natural in that Tony and I try to based the
multi6-threats on the existing IPv4 Internet.

One case where MIPv6 is weaker than today's Internet is that an attacker
which is on the path for a few seconds can redirect packets for a few minutes.
In today's Internet an attacker needs to be on the path all the time in order
to be able to redirect packets to some other destination (for instance
by spoofing ARP on an Ethernet between two routers).
MIPv6 explicitly allows this but does limits the exposure to a few minutes.

Trying to compare different multi6 schemes and MIPv6 from a security
perspective there seems to be different types of verification going on.
In MIPv6 the strongest (which isn't very strong in this case) verification of 
the identity is that it is reachable at the home address i.e. there isn't
a MiTM between the correspondent and the home agent.
Once a node has be so verified the resulting redirection to a Care-of-address
remain valid for a few minutes and then needs to be renewed.

One can envision similar things for multihoming solutions.

We can have weak initial verification, for instance the first packet
arrived from some identifier/locator pair, and return traffic goes back
to the same node.

Then we can have strong verification, for instance using the DNS or the CBID
property with public key crypto, to verify that the peer indeed "owns" the
claimed identifier hence is authorized to specify the locators to use with it.

But, based on the MIPv6 model, one could also envision a weak but time limited
verification that builds on some earlier verification (whether the earlier
verification was weak or strong).
For instance, if the peer shows that it knows a clear-text random number
which was exchanged during the earlier verification, then it
might be reasonable to allow redirection to a new locator *for a limited time*.
 An on-path attacker could use this, but would have to repeat the attack every
few minutes i.e. it is not sufficient for the attacker to "drive by" some
link and launch an attack that lasts forever.
If the attacker needs to be on the path all the time the residual threat 
wouldn't be much different than what an on-path attacker could do today.

Comments?
   Erik