This doc makes the case that IKEv2 should implement its own
frag/reassembly mechanism, because some NATs don't pass IP fragments.
First, the issue with NATs and fragments should be made more clear,
especially citing existing descriptions of this issue, e.g., RFC4787.
Note that NATs which do not pass fragments violate RFQ-14 of that BCP
RFC, and it might be useful to report this issue to the vendor.
Second, it is not clear why this issue is being handled inside IKE.
Appendix A provides a design rationale, but it clearly trades
computation and space overhead for local storage, and still permits DOS
I don't see a strict computation/memory tradeoff here. You must
verify message validity in any case, whether it is done before
reassempling (on each fragment), or after it is complete (including
the case when you get garbage message due to false fragments).
The amount of consumped CPU power will be roughly the same.
The cost to verify several individual messages is higher than the cost to
verify a single message, especially when the individual messages are not
exactly the blocksize of the algorithm used.
Right. That's why I wrote "_roughly_ the same". Of course there is some
overhead, not only due to blocksize, but mainly due to the inclusion of IKE
Header
into ICV calculations for each fragment message.
So in the case of no attack, the overhead of your proposed mechanism is
higher. You can't drop an entire message when a single false fragment
arrives, because there could be other valid fragments on the way. So
either way you end up checking the same amount of data, but your
computational overhead is higher.
Yes, it is higher, but the amount of the overhead could be estimated
about 10%. If some system cannot bear this overhead, I think it is broken.
But the amount of memory consumption will be smaller if
you are able to discard false fragments.
Yes, but you also need to keep some state about pending partial valid
messages.
Right. But only after fragment is validated.
AFAICT, the memory difference is more likely to be negligible, but the
processing difference high.
No. In solution you have proposed (relying on IP fragmentation
inside UDP datagrams) the attacker could send you millions
of packets, all with different IP Fragmentation IDs in inner packet. As you
has no way to know which Fragmentation ID is valid (from real peer)
you will need to try to reassemble all of them, consuming
as much memory, as attacker wishes. If attacker is smart enough,
s(he) could easy make so, that all the false fragments will eventually
be reassembled by your system (into garbage), and you will also consume
the CPU power trying to validate them. In this case you will consume
roughly the same CPU power as with authenticated fragments,
but the amount of your memory consumption will be under attacker's control.
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.
Handling fragmentation in IKE doesn't make it more vulnerable to this
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. Using authenticated
fragments
prevents this kind of attack.
Avoiding fragmentation poisoning attacks is not a motivation of this work.
If you want to make that case, you need to explain why you think that is a
significant issue and worth the effort to fix inside IKE.
Actually, Security Consideration Section of RFC5996 has already
stated that IP fragmentation is a significant issue for IKE:
If the messages of IKEv2 are long enough that IP-level fragmentation
is necessary, it is possible that attackers could prevent the
exchange from completing by exhausting the reassembly buffers.
RFC5996 advices to avoid IP fragmentation by using Hash and URL
format for certificates. For some reasons, this is not widely supported
by implementations and is not generic solution (some systems
transfer a fair amount of data in Configuration Payloads, in which
case Hash and URL won't help).
The immediate goal of IKE Fragmentation was to deal with
devices, that block IP fragments. But the solution is all in line
with RFC5996, advicing avoid IP fragmentation whenever possible.
Further, this method does not necessarily avoid IP fragmentation.
Fragments are supposed to pass through a NAT (see my previous reference),
and when they do your mechanism wouldn't adjust the IKE size downward.
It doesn't matter. If IP fragmentation works in some environment - it is ok.
If it doesn't (either because some intermediate devices block
IP fragments or because an attacker is trying to exploit it),
then peers detect it and start using IKE Fragmentation.
An equally viable solution (see ** below) would involve placing a
single signed IKE message into a single IP packet, fragmenting that
packet, and transmitting those fragments inside UDP datagrams. This
approach could use the innermost IP encapsulation as the reassembly
layer.
**: Although this approach is susceptible to fragmentation overload,
so too is transmitting the original message over IP that is naturally
fragmented at the network layer anyway - this introducing no new
vulnerability.
But using IKE fragmentation in this case might eliminate this
vulnerability.
It might, but again that's not your threat model and there are other
vulnerabilities this method opens up (e.g., replay attacks have a higher
CPU impact).
Why? Are you reffering to the fact, that with IKE Fragmentation you need to
check 4 additional bytes to detect a replay? Is it really a CPU impact?
This IP-encapsulated IKE message would need the same negotiation
described in section 2.3, but would avoid the complexity of most of
the rest of the document, relying instead on existing IP reassembly.
In conclusion, I don't see the need for the level of detail and
mechanism proscribed, basically because it reinvents the wheel, but
see no other substantial issues with it.
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.
You are re-inventing PLMUTD. In places where you claim RFC4821 is too
complex - those are the places where your mechanism is deficient IMO.
E.g., positive verification that a message gets through as a confirmation
of when you've achieved a reasonable size.
It is sufficient for IKE.
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.
Agreed, but if that's the case, why not always send the smallest possible
message size (68 bytes)? It's because the overhead is too high (additional
headers, blocksize mismatch, and computational startup cost on each
block). Further, most transports don't care about 1400 vs. 1500 bytes;
they're searching for a rough approximation of a 'large' packet, as are
you IMO.
I think, the main difference is that PLMTUD is always trying
to increase MTU size when everything works fine, while in IKE
PMTUD is supposed to decrease it only if packets don't get through.
For IKE the former is just not needed.
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.
The transport folks spent a lot of time on PLMTUD; there are a lot of
lessons there that can and should be applied here. PLMTUD is already
flexible enough to apply here directly. You can always reinvent the wheel,
of course.
I appreciate the work transport folks has done. I will also appreciate
if you point out what exact lessons should be applied here and why.
And you may consider PMTUD in IKE as simplified PLMTUD,
implemented according with Section 10.4 of RFC4821.
Joe
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
