Hi, Valery,
On 10/22/2013 5:50 AM, Valery Smyslov wrote:
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.
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.
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.
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.
AFAICT, the memory difference is more likely to be negligible, but the
processing difference high.
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.
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.
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).
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.
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.
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.
Joe
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
