[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime)



>>>>> "Andrew" == Andrew Krywaniuk <akrywaniuk@TimeStep.com> writes:

 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?

 Andrew> 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> Andrew:

 Andrew> Not exactly.

 Andrew> You can't realistically ever fully protect against DoS
 Andrew> attacks. But a good rule of thumb is to force a DoS attacker
 Andrew> to consume as much of his own computing power as he consumes
 Andrew> of yours.

I'd rather do better, because DOS attackers can operate in packs, so
they have a lot more resources than you do.

 Andrew> You receive a spoofed packet and it causes you to perform a
 Andrew> DH exponentiation = BAD.  You receive a spoofed packet and it
 Andrew> causes you to generate an unencrypted notify = OK.

 Andrew> Generating the unencrypted notify could involve nothing more
 Andrew> than a hash table lookup (which you had to do anyway to
 Andrew> determine that the spi/cookie was invalid), a couple of
 Andrew> memcpys, and a SendBuffer.

Or it may be a lot more costly.  IPSEC may be in hardware while IKE is 
in a control processor.

 Andrew> Plus, sending the unencrypted notify allows the peer to
 Andrew> generate an alarm: SOMEONE IS SPOOFING PACKETS!!! (since
 Andrew> either you generated the notify in response to a bad
 Andrew> spi/cookie or the notify itself was spoofed)

Certainly you can do logging or alarms based on bad input packets, but 
that's a local matter, not a topic for the protocol specs since it
doesn't affect the protocol.

 Andrew> But if you respond to the unencrypted notify by initiating a
 Andrew> new SA then you are at the mercy of a DoS attacker.

Right.  

If generating an unauthenticated notify allows the receiver of that
notify to take a useful action, it might make sense to take the
resource hit and generate that notify.  But I see no way that a
receiver of such a message can take any useful action.  Well, maybe
you could log them, because clearly someone may be attacking you or
the other end if you see those messages.  

On the other hand, the issue was that a half-open connection (SAs on
one side but not the other) is not self-correcting.  You CANNOT use
unauthenticated notifies to fix that for the reasons you mentioned.
Since you cannot, it makes sense for the spec to say that generating
such a notify is optional and you're also allowed to take no
(protocol) action at all for invalid SPI packets.

	paul


References: