RE: Time shifitng/future redirection attacks

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Erik,

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

Thanks

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

I don't think that the decision is obvious but I think it is very importatn
ti understand the additional vulnerabilities that we are introducing. It may
be acceptable to introduce them, though.

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

Agree.
I think that the section of future attacks considers this issue but perhaps
adding some more examples to understand the full range of time shifting
attacks would be fine.
Additionally, perhaps it makes sense to explicitly note that the direction
of communications. I mean, the threats when you allow that the state created
by an incoming connection is shared with future outgoing communications.

So, there is state created at a moment in time, a time shifted attack is
about using this (false) state in future communications, but additionally,
IMHO it is also important to note whether this communication are in the same
direction of the communication that created the state.

finally, i think that explicitly noting that there is a difference level of
threat when the state affects only a connection or it refers to the complete
identity of the host.

Regards, marcelo

>
>   Erik
>
>