On Tue, 22 Oct 2013, Valery Smyslov wrote:
attacks (e.g., overloading the receiver with false fragments).
This attack is always possible both with and without fragmentation
(just overloading with false full messages) and IKE is designed to withstand
it.
Partially. For unfragmented IKE, the cookies/SPI mitigate this if
you give preference to IKE messages further in the processing queue.
With this draft, I'm forced to do more crypto on IKE packets before I
can decide if these need prioritization or not (with the exception of
the first packet, which cannot get fragmented anyway)
Handling fragmentation in IKE doesn't make it more vulnerable to this attack.
Handling encrypted fragments does, because you will spend more time
doing the crypto. Although this still happens after the cookie/spi
verification. You are doing an additional round of crypto on each fragment
in addition to the regular IKE crypto you need to perform on the assembled
packet. Fragments could be made artificially long and the IKE packet
artificial big, resulting in much more crypto. Now I think this might
not matter much, because the attacker needs to be local and they will
only be local to a remote endpoint which has enough CPU, not the ipsec
core gateway that actually might run out of CPU power when under attack.
On the other hand, handling fragmentation outside IKE (on IP level)
or using unauthenticated fragments in IKE, makes it susceptible to an attack,
described in the rationale, i.e. when attacker spending virtually zero
resources
can stop IKE communication by infrequently injecting bad fragments,
which results in "poisoning" of reassembling queue.
But the attack is theoretical and of no practical value.
1) on-path attacker (remote)
They can just DOS you regardless by withholding packets.
2) off-path attacker (remote)
These attackers don't know the cookies/spi's so they can't really sent
a forged fragment you would use for assembly - protected with crypto or
not. It is also impossible for them to time their attack so that one of
their fragments intersect with one of your fragments so they would need
to start sending fragments before the endpoint does but using mostly
wrong cookies/spis and would swamp an endpoint with easilly detectable
forged packets.
3) shared medium like wifi hotspot (local)
These are the only attackers with enough knowledge to sent sufficiently
advanced bad fragments interfering with incoming fragments. They can
already do all the damage they want without resorting to IKE fragment
spoofing. They can arp spoof the gateway, sent a Wifi de-association
request, sent enough garbage to fill the air waves, and interfere with
the IKE in such a way that you think the remote peer does not support
fragmentation at all. So this draft protects against a local attacker
that wants to masquerade as a network failure and only prevent you from
doing IKE, hoping you will fall back to plaintext traffic. Software
could notify the user that they seem to be under attack, which IMHO
would be more valuable to the user than quiet resilience against the
attack.
Using authenticated fragments prevents this kind of attack.
Yes, it prevents one of the low hanging fruits. Which I don't think is
worth the complexity of this draft compared to the existing
fragmentation code out in the wild.
But using IKE fragmentation in this case might eliminate this vulnerability.
At the price of adding more complexity to IKE. With the attacker not
stopped from their goal.
Additionally, regarding PMTUD, this should be done using PLMTUD (RFC 4821),
and should be described as such.
IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based
and RFC4821 has many restrictions when used with connectionless
datagram protocols, some of which are often difficult to satisfy in
environments,
where IKE is used. Second, the goal of PLMTUD is to find _maximum_
MTU size that is not fragmented by IP, in other words, to maximize
throughput. For IKE the goal of PMTUD is to find _any_reasonable_
MTU size that won't be fragmented by IP. Throughput is not important.
Third, PMTU discovery in the draft is completely optional and one may
use any other mechanisms (including PLMTUD, if it is available)
to obtain MTU information.
I agree. There is going to be like 2 to 4 fragments. Size does not
matter. It's better to cut down on latency/RTT by using an MTU size
that is for sure to work on the first go.
But that's also why this complexity is not worth it. Fragmentation does
only mean going from 1 IKE packet to 2-4 IKE packets. The timeframe
to mess with these are in the 5ms range. If an attacker has that
accuracy against you, you've lost already regardless. I doubt the
attacker can even pull it off on wifi.
The original IKE fragmentation is really nice and simple. Copy part of
the original IKE header, add a single payload with fragment payload
type and fragment number/max, sent fragments in a burst.
This draft looks like it is fixing a security issue, while it really
should be just about sending smaller packets as similar as possible
to the original single packet. Messing with one IKE packet versus 2-4
IKE packets is not a real problem that I think needs fixing.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
