Hi Joe,
thank you for your review.
Please, see my comments inline.
Hi, all,
I've reviewed the following doc for TSVDIR:
draft-ietf-ipsecme-ikev2-fragmentation-04
Although this is not intended as a complete TSVDIR review, I have checked
for the typical issues.
Joe
-------------------------------------------------------------------
draft-ietf-ipsecme-ikev2-fragmentation-04
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.
But the amount of memory consumption will be smaller if
you are able to discard false fragments.
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.
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.
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. 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.
Thanks,
Valery Smyslov.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
