[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-ipsec-ikev2-01.txt
> > Solving this sort of DoS attack in which the adversary is
> either (a) on the
> > same LAN as the responder or (b) located along the data
> path should be a
> > non-goal.
>
> Why? There are cases where I would really like to protect against this
> kind of DoS attacks too... Quite often the attacker cannot for example
> remove packets (it is just listening), and doing for example arp
> attacks are easily detectable by the other devices on the network so
> they might just draw attention to the attacker.
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.
> 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.
> > The danger here is that one SA request by Alice can result in 1000
> > replies by Bob (and 1000 DHs that Alice has to compute).
>
> True, but now it is the initiators choise how many of those he is
> willing to try. If the connection is very, very important he can
> simply continue until he succeeds. If he thinks it really doesn't
> matter even if he cannot read the daily dilbert using ipsec he can
> just forget the connection immediately.
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.
> Currently you only need one UDP packet for each IKE packet you see to
> kill all negotiations between two hosts. Also if the attacker needs to
> flood stuff instead of single packet it again draws more attention
> towards the attacker (itrace etc).
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.
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.
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: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Thursday, February 28, 2002 2:51 PM
> To: "Andrew Krywaniuk"
> Cc: dharkins@tibernian.com; ipsec@lists.tislabs.com
> Subject: Re: draft-ietf-ipsec-ikev2-01.txt
>
>
> andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk") writes:
> > How about: "Repeated re-keying using Phase 2 without PFS
> will increase the
> > amount of data that will be exposed if the Diffie-Hellman
> key is ever
> > compromised. Rekeying without PFS could also aid an attacker in
> > cryptanalysing encrypted ESP data if a weakness in the PRF
> algorithm is ever
> > discovered."
>
> I like that text.
>
> > - All previous proposals (IKEv1, IKEv2, JFK, and SIGMA) were
> > vulnerable to an active attacker answering Alice's
> message with bogus
> > information. Alice cannot distinguish a legitimate
> message 2 from a
> > bogus message 2. In this draft we explain how Alice can protect
> > herself from this attack, which is to be willing to continue
> > negotiation with every reply she receives. Only the
> legitimate Bob
> > will be able to send an acceptable message 4, so the
> multiple SA's-
> > in-progress will only last until the SA is set up.
> >
> > Solving this sort of DoS attack in which the adversary is
> either (a) on the
> > same LAN as the responder or (b) located along the data
> path should be a
> > non-goal.
>
> Why? There are cases where I would really like to protect against this
> kind of DoS attacks too... Quite often the attacker cannot for example
> remove packets (it is just listening), and doing for example arp
> attacks are easily detectable by the other devices on the network so
> they might just draw attention to the attacker.
>
> 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.
>
> > These sorts of adversaries can generally do all sorts of nasty
> > things like (a) arping for you or (b) simply removing your
> packets from the
> > wire.
>
> Yes, but if he starts doing that he draws attention to his machine,
> and someone will unplug the machine from the network quite soon...
>
> > The danger here is that one SA request by Alice can result in 1000
> > replies by Bob (and 1000 DHs that Alice has to compute).
>
> True, but now it is the initiators choise how many of those he is
> willing to try. If the connection is very, very important he can
> simply continue until he succeeds. If he thinks it really doesn't
> matter even if he cannot read the daily dilbert using ipsec he can
> just forget the connection immediately.
>
> Anyways if both ends are willing to consume enough resources to the
> exchange then the exchange will succeed finally, no matter the passive
> listener + active sender type attacker does.
>
> Currently you only need one UDP packet for each IKE packet you see to
> kill all negotiations between two hosts. Also if the attacker needs to
> flood stuff instead of single packet it again draws more attention
> towards the attacker (itrace etc).
>
> > The best response to this sort of attack is simply to give up on the
> > negotiation and retry after some comfort period.
>
> In same case yes, but lets say you want to go remote server to shut it
> down because you know that someone is just about to break into it
> using some newly discovered method (needing some time to actually do
> the attack) and the attacker really really wants to stop you closing
> the security hole before he can get in...
>
> In that case it really doesn't matter how many diffie-hellman
> calculations my laptops (and propably all of my friends borrowod
> laptops too, to distribute my diffie-hellamns) do before they can get
> it.
> --
> kivinen@ssh.fi
> SSH Communications Security http://www.ssh.fi/
> SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
>