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

[andrew.krywaniuk@alcatel.com]

Okay, so the bottom line is that we both agree that this should be a MAY and
not a SHOULD. Do people on the list object to this change in requirements
language?


> 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%.

If an implementation chooses to use this feature, I think it's an
implementation detail what exact algorithm they use. I think the only advice
we really need to give them is to (a) give priority to SAs on which you
don't detect this attack, and (b) don't attempt to store all the packets and
process them sequentially (e.g. randomly drop x% of the packets). Also,
should the initiator retransmit the first packet more frequently in this
case?

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tero Kivinen
> Sent: Sunday, March 03, 2002 8:27 AM
> To: andrew.krywaniuk@alcatel.com
> Cc: ipsec@lists.tislabs.com
> Subject: RE: draft-ietf-ipsec-ikev2-01.txt
>
>
> 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/
>