Time shifitng/future redirection attacks

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

> Correct. That is how the Internet works. Multi6 doesn't have to fix that.
> We have to make sure that *if* the host we contact using IPA subsequently
> asserts that it can also be contacted using IPZ, that assertion is true.

I sense folks talking a bit past eachother on the mailing list so let
me try to help.

In the case when nothing moves around I think we understand the requirements
quite well. Something that is on the path can be a MiTM today and
multi6 doesn't need to make that aspect any more secure.

But it is more difficult to undersyand the requirements when nodes are moving
around; a node might be on the path for a short instance (driving by
the 802.11 coffeeshop).
Would we or would we not be concerned if such a drive-by (which many call 
a "time-shifting" attack) would result in the temporarily on-path node can 
be a MiTM for future communication? (e.g. by creating/installing 
multi6 related state in various peer nodes while it was on the path) 

I actually don't think the answer is obvious; we don't have much experience
with nodes moving around being able to attack things as they move.

In Mobile IPv6 a conservative approach was taken which limits such
drive-by attacks to the maximum lifetime of the binding, which is set to
a few minutes.

Note that the range of solutions that has been discussed in multi6
go from such drive-bys being impossible (because of a strong binding to
a separate identifier in HIP, or because of relying on the relative security
of the DNS for forward+reverse lookups in NOID), to 
systems that are first-come/first-serve (WIMP being an example with
a separate ID space, a MAST approach with a PBK being an example without
a separate ID space) that allow the first host which is using an ID/address
to claim that without any time limit.

The threats draft talks about pre-mediated attacks which is a particular
aspect of "drive-bys"; things that are different because nodes move around.
Based on the mailing list discussion I suspect we need to flush out the 
this whole area of nodes moving around a bit more in the draft.

  Erik