RE: Time shifitng/future redirection attacks (was RE: Identifiers

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

> > Or in more general terms, this would allow time shifting attacks as
> > presented in section 2.2. Timing in
> > draft-nikander-mobileip-v6-ro-sec-02.
> > Note that MIP design especially limited BCE entries lifetime to a few
> > minutes to deal with this type of attacks.
>
> Which is of course something we can't do. As I said before, if someone
> in the middle can redirect an ongoing session, I don't consider this
> materially worse than what can happen today (disrupt the session).
> However, redirecting not only the current session but also future ones
> would be unacceptable.

I agree with this criteria.
The protection for a connection can be done once in the connection lifetime.
The problem here, then is at which layer your solution is working.
If you adopt a transport layer solution which the locator set exchanged only
applies to that particular connection, the security checks can be
simplified, IMHO like one RR check.
However, if you adopt a shim layer or IP layer solution, the solution has no
knowledge about
connections, so the exchanged locator set will apply to all connections,
present and future, incoming and outgoing. That is why IMHO we have to take
care of time shifting attacks when considering shim/IP layer solutions which
may require additional mechanisms

> It doesn't seem too hard to avoid this, though:
> new sessions can be forced through a "real" address rather than a
> negotiated backup address. Unfortunately, in a NOID/DHT-like scheme
> this probably means the application needs to be involved with this.
> Example:
>
> X publishes addresses A and B in the DNS.
> Y contacts X on A
> X negotiates C as an additional address
> A dies
> the session from Y to X starts flowing over C
> Y wants to set up a new session to X
> Y tries address A
> address A times out
> Y tries address B

Yes, this kind of approach can deal with these attacks.
There are other options, also.
But i guess we agree that we have to provide protection against this type of
attacks (which is good :-)


>
> And this is without adding crypto-based identifiers to the mix. Making
> all of this more flexible and more secure can be done using
> crypto-based 64 bit identifiers. I think those are a great idea, but so
> far there has been very little discussion on this topic.

as i said in previous mails, i think CBID add value and are a good option
and of course the provide protection from this attacks.

Regards, marcelo


>
>