RE: draft-ietf-ipsec-ikev2-01.txt

[Tero Kivinen <kivinen@ssh.fi>]

Andrew Krywaniuk writes:
> It is easy to write software to check if someone is spoofing your IP from
> your own LAN if you're so inclined, although I suppose they could be
> silently listening on the LAN, forwarding the cookies to another location
> and spoofing the responses from there.

Because as you say it is easy to stop the machine that actually
does something nasty and is along the path, but it is very hard to
detect the machine that only listens and send the information need to
launch the attack to another host(s). 

> > Sending faked packet can be done from completely different host
> > (some hacked machine out there in Elboinia), and from different
> > machine every time. This way finding the attackers listening post is
> > much harder, and he can continue the attack much longer.
> I'm not including those cases because we're talking about attacks against
> the initiator here. The adversary has to be on the data path in order to
> learn the initiator's cookie.

I am very concern about attacks that are very hard to block and very
hard to find who is doing it. I was mostly talking about this kind of
listening post + sending info to somewhere else attack. 

> Well, the new draft of IKEv2 seems to imply that this is the expected
> behaviour of the initiator (a SHOULD). I have no problems with it being a
> MAY, but I don't think this should be the default behaviour. You are merely
> trading one DoS attack for another.

I agree that it should be MAY instead of SHOULD. And perhaps we need
to add more text about the how this is done.

I.e you need to process all packets, and you need to start as many
partial exchanges, to do that you want to do that only if you have
spare time. Also it should be done in a way that if you detect this
kind of problem you only first gather some time for possible response
packets and then start processing them in random order. If you happen
to hit timeout before you can process all packets then you try again
with new exchange and this time you propably take different cookies
where you respond, meaning that the propablity of succeeding is 1 /
(number of attacker packets ) * (number of packets per second you can
process * timeout in seconds). If the attacker is sending 10000
packets, you can process 50 packets per second and the timeout is 30
seconds, the propability is 15%. 

> Let's face it. Most machines out there aren't ultra-reliable under load. So
> unless you're ultra-confident about your robustness, you shouldn't try to
> outlast a DoS attack. Also, if you're being swamped with bogus replies then
> chances are you are dropping some packets. If so, you might as well drop the
> packets that are 99% likely to be spoofed and focus on giving good QoS to
> the rest of your flows. If you have some spare cycles, you can try to
> process some of the spoofed packets in the hope that it really is Bob. Keep
> in mind that Alice is not necessarily a user sitting in front of the
> computer who has the ability to abort the connection in real time.

Lets put it this way. Not all implementations are going to do it, but
I think the protocol should not make it impossible to try to do it. It
is then only implementation detail how it is done, if done at all.

> I just noticed that with IKEv2 you can avoid this attack against the gateway
> in a client to gateway scenario (the original responder can take advantage
> of IKEv2's ability to rekey under the protection of the original phase 1),
> which is good.

True. This is the kind of things I am looking for. Things that do not
complicate things but makes it possible to have some kind of
protection against DoS. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/