Hi Paul,
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)
The SPIs are still there and you are supposed to check them
before you will do any crypto. What is the difference?
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
No, there is no additional round of crypto. After you has verified
and decrypted fragment you will store it in decrypted form.
After reassembly has finished you will get decrypted message.
No more crypto to apply.
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.
I am not so confident.
1) on-path attacker (remote)
They can just DOS you regardless by withholding packets.
There may be cases when attacker, even on-path,
could only eavesdrop and inject packets, but not to block them.
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.
Again, I am not so confident that it is impossible, especially for
particular implementation. Remember, that TCP ISN was also
considered impossible to predict untill we saw a successfull attack
on particular implementation of TCP.
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.
Sorry, I don't follow your logic here. Security software should
thwart the attacks as much, as it could, and not just
notify user that he is under attack and give up. DoS attacks
are difficult to thwart and sometimes are easy to perform.
So what is the reason not to thwart one kind of them?
I agree that others are still possible, but they may have
their own drawback for attacker and why should we
give him/her more options to choose from?
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.
Is it really _much_ complex if you first fragment then encrypt compared
to first encrypt then fragment?
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.
See above.
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.
Not much difference from the draft - just move fragmentation
before encryption.
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.
It is about sending smaller packets, but doing so in a secure manner.
Paul
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
