Tero, > The reason I am in favor of heuristics instead of WESP, is that > heuristics requires changes only on the middleboxes, we do not need to > make new extension that will affect all the end nodes supporting > IPsec. > > Also heuristics is not harmful, as it does not harm others, it is > simply internal matter inside the middlebox. I do consider WESP a bit > harmful, as it adds extra bytes to all packets, and does not offer
I think heuristics is a good solution, but contrary to your thinking I don't think it's a panacea to all our problems. Heuristic solution is not an exclusive alternative, but a complement to the deterministic approach in providing an interim solution using a subset of devices that are capable and willing to consume the heuristics overheads. Few of us, long time back, had done some work on the issues with heuristics and I post a summary of what we had discussed. Claiming that heuristics requires only modification of the network entities is somewhat misleading, as the nature of the modifications is very different. Such changes would imply a radical change in architectures of devices that currently do not have the capability to run complex code with the corresponding memory requirements. Furthermore, those changes are ongoing as heuristics has to continuously change to accommodate changing traffic patterns and algorithms (e.g. leveraging new, future cryptographic algorithms for ESP, which have different IV/ICV length requirements). From the point of view of testing and compliance, such complexity is in itself an issue which compounded with the potential for incorrect determination is perhaps a deployment blocker. Heuristics are applicable to only some (not all) stateful devices. Even within stateful devices, not all of them are expected to be able to handle heuristics, particularly as they grow to handle 100K-400K flows. Heuristics will NOT work for high speed, high aggregation, stateless devices. These devices provide services such as stateless statistics, QoS markings or stateless firewalls (which provide basic access control functions in filtering unwanted network traffic). Stateless devices by definition do not maintain dynamic, per-flow state (although they typically have fixed, static rules) and hence employing any heuristics-based solution would require a radical architecture change for these devices. This would be in the form of incorporating state into the device or the ability to execute the heuristics engine at line rate for every packet, which would require a pure hardware-based solution. Heuristics are not a good match for short-lived flows. Measurements of Enterprise traffic patterns reveal that a significant portion is represented by UDP and short-lived flows. UDP traffic has been measured at 25% of the total. The concept of "flows" which heuristics uses to amortize the initial cost of parsing and analysis is not as applicable here. Handling such cases (e.g., VoIP) via heuristics is very costly and may end up becoming the bottleneck for the services offered. The heuristics draft itself concedes that UDP checks will be more expensive, as it does not contain immutable fields (such as those available in TCP flows) that can be used as part of the heuristics algorithm to increase the probability of drawing the correct conclusions. Heuristics requires a proper cache flushing mechanism. Heuristics based approach recommends executing the heuristics engine in software and subsequently caching the results in hardware by using the packet attributes (e.g. IP addresses, SPI). However, it does not provide a clean solution for cache management and specifically eviction of a given cache entry, if and when a given flow is no longer needed. The proposed approaches for cache management recommend simple Least Recently Used (LRU) type algorithms, which will unnecessarily flush legitimate cache entries for legitimate, but intermittent traffic patterns or an approach of binding TCP flow analysis with the appropriate cache entry, which may work for stateful protocols, but is ineffective for stateless protocols such as UDP. Additionally, the engine will have no idea about short and long-lived security associations and may prematurely remove cache entries, even though the SA is still active. This will require further iter ations using the heuristics engine, when a subsequent packet for that security association is seen. Furthermore, the cache will likely be of a finite size and any of the above approaches will cause a 'cache trash' resulting in performance degradation, as well as unnecessary CPU consumption in re-execution of the heuristics engine. This provides a new DoS attack vector for potential adversaries by forcing cache add/remove harmonics by simply replaying packets at well-chosen intervals. It is hard or costly to handle quick route changes via heuristics. Heuristics works best in the presence of long-lived TCP sessions. "Long-lived" must apply both to the session at the end-nodes involved as well as to how it is being routed throughout the network. Even if the former is true, constant routing changes render these sessions short-lived from the point of view of heuristics, as the new devices involved must re-run and relearn the flow based on heuristics. Route changes invalidate the amortization of building heuristic state Heuristics can lead to more latencies in error recovery and indeterminate results. The heuristics draft discusses the possibility of several potential false positives in connection with DPI engine results. Confusing failure and garbage results can lead to slow error recovery. As pointed out by the heuristics draft, lack of explicit knowledge of the Next Protocol may require more passes, hence more latency and state to be built. Cheers, Manav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
