[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime)
>From: Paul Koning [pkoning@xedia.com]
>Sent: Wednesday, January 19, 2000 11:50 AM
>To: akrywaniuk@TimeStep.com
>Cc: ipsec@lists.tislabs.com
>Subject: 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
In addressing the half-open connection state you seem to only consider
two possiblities, a clear notify or a notify sent using an existing
SA. Is it possible to send an authenticated notify without
an existing SA? If one such message is possible, it can get the parties
involved out of the half open state (the cost to create such a message
could be cheaper than getting an SA created and one can always rate
control the creation of such messages to minimize DOS attack).
Thanks,
-- sankar --
Follow-Ups: