[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime)
> Sankar> Why is "do nothing" a safe choice for the receiver of the bad
> Sankar> IPSec packet (IPSec packet without SA)? How does sending a
> Sankar> 'invalid spi' notify to the sender of the ipsec packet affect
> Sankar> the safety of the receiver? Isn't sending a notify better
> Sankar> than doing nothing?
Paul:
> Not necessarily. Sending a notify consumes resources that are not
> consumed by simply discarding the offending packet. Since
> DOS attacks
> basically are attempts to get the receiver to consume lots of
> resources, the less resources you use in dealing with invalid packets
> the safer you are from DOS attacks.
Andrew:
Not exactly.
You can't realistically ever fully protect against DoS attacks. But a good
rule of thumb is to force a DoS attacker to consume as much of his own
computing power as he consumes of yours.
You receive a spoofed packet and it causes you to perform a DH
exponentiation = BAD.
You receive a spoofed packet and it causes you to generate an unencrypted
notify = OK.
Generating the unencrypted notify could involve nothing more than a hash
table lookup (which you had to do anyway to determine that the spi/cookie
was invalid), a couple of
memcpys, and a SendBuffer.
Plus, sending the unencrypted notify allows the peer to generate an alarm:
SOMEONE IS SPOOFING PACKETS!!! (since either you generated the notify in
response to a bad spi/cookie or the notify itself was spoofed)
But if you respond to the unencrypted notify by initiating a new SA then you
are at the mercy of a DoS attacker.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
Follow-Ups: