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

[Iljitsch van Beijnum <iljitsch@muada.com>]

[People, why are we CC'ing everyone and their little sister?]

On 29-mrt-04, at 2:21, marcelo bagnulo wrote:

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

> If i understand what you are saying correctly, this approach wouldn't 
> really
> prevent the attacks presented in section 4.1.2 Premiditated 
> redirection of
> draft-nordmark-multi6-threats-00.txt, right?

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

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.