Re: Attacking TTL-based "authentication"

On Fri, 17 Oct 2003, Tomasz Grabowski wrote:
[...]
> Assuming she is connected to R1 (best case) she needs to send such iTrace
> packets:
> 1. src: R8   TTL=253
> 2. src: R7   TTL=254
> 3. src: R2   TTL=255
> 
> How Victim can recognize that these packets were forged?

Of course, the victim can't.  But remember the threat model here.  If a 
victim can be on the path, everything is lost anyway.  If a victim is near 
to the path (and being able to spoof the address), you're in a very bad 
shape already.

In this case, if Victim wants to use iTrace to trace the attacks, 
obviously Victim's "local network" must be cleaned up first, implement 
ingress filtering etc., to be able to have more certainty of at least a 
part of the attack traces.

Obviously, the TTL-based mechanisms, when applied to large interdomain 
scenarios, operate under specific assumptions, like, the attackers will 
have low probability of
 1) being able to compromise hosts close to the target, AND
 2) these compromised hosts can spoof their addresses.

I'm not sure how relevant that is, because those who care about itrace 
probably do their "homework" properly in most cases.  Because hey, if they 
could compromise a system close by, why would they attack from afar?

But, the two assumptions above also apply partially to the all of the 
backbone networks through which the iTraces get sent through.  That is, if 
you have a compromised box with the ability to do spoofing, you can do 
quite a bit of evil.

If one is worried about "advanced" attacks, I guess the only way would be 
to use strong crypto.. that may be something that'd be needed, but I think 
a very plain model would probably be enough for at least as starters..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings