Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

["Grewal, Ken" <ken.grewal at intel.com>]

Additional comment below...

...Snip...

>> Cache eviction - how will this work?
>> We can keep adding SAs (based on heuristics), but how do we decide
>> when a given SA is no longer needed? This compounds the issues with
>> keeping state, as in the best case, cache eviction will likely be
>> policy based. How is the policy determined and how do we
>> differentiate between short and long lived SAs? As the SA cache will
>> be of a finite size, this WILL lead to a cache thrash (add SA, evict
>> SA, ...), causing further resource consumption.
>
>This is actually quite good point, and it is also implementation
>detail that do affect the performance.
>
>How this can be solved depends quite heavily on the environment where
>heuristics is used. If we are doing firewall that already keeps state
>of all TCP/UDP flows, then it would be natural to weakly bind IPsec
>SAs and TCP/UDP flows inside together. For example keep in track when
>there is no more TCP/UDP flows using the IPsec SA (i.e. all the
>TCP/UDP flows which used this SA before, have now been moved to new
>IPsec SA), and after that you can most likely remove the IPsec SA
>entry quite quickly.

[Ken] This may be feasible for stateful devices, but does not work for stateless devices (QOS/Statistics/auditing functions). Even in stateful devices, it requires coupling between observation on flows and the associated heuristics cache engine, which creates an additional overhead. 
>
>Another, and probably more common implementation will be just some
>simple LRU based mechanisms to reuse old IPsec SA entries. This kind
>of things are usually already done for the UDP protocols.

[Ken] These require timestamps (or other ordering / metric based approaches) and monitoring to ensure the cache is up to date. Furthermore, it may also provide opportunities for adversaries to use periodic replays to provide cache thrash and associated overhead in re-executing heuristics engines. 

I am not convinced that SW based solutions will scale 10Gbps solutions, let alone future 40/100Gbps bandwidth requirements, especially at these network 'choke' points, so a HW orientated solution may be desirable...which brings us back to cost/complexity...

>
>> How about dynamic route changes for already established SAs? The
>> same problem will exist as the Monday morning problem, but without
>> the diffie-hellman overhead. Because we are caching state on one
>> device, a change in route where the packets take a different path
>> will force the new device to 'relearn' all the cached info.
>
>Yes, but heuristics is still fast operation, thus that should not be
>problem. Bigger problem usually is that the deep inspection state is
>lost too...

[Ken] But not for stateless devices, which will carry the 'resync/Monday morning problem' each time.

>
>> High availability is another one to consider, especially during
>> maintenance periods. One device is powered down and a backup device
>> takes over. This is similar to route changes in principle, where the
>> backup device will need to relearn all the state.
>
>As here the heuristics is run on the same device which is running the
>deep inspection, they do already require methods of transferring that
>deep inspection state from one device to another, and moving the IPsec
>SPI cache state at the same time should not be a problem.

[Ken] But again, this is additional work, which can be avoided if we have no state.
>
>> Agree, but the heuristics engine may be heavily used as VOIP becomes
>> prevalent, especially within the Enterprise. Lots and lots of UDP
>> traffic that is short lived, which ties back to earlier points on
>> cache maintenance and frequency of exercising the heuristics engine.
>
>If we know anything about the contents of the UDP packet (i.e.
>recognize that it is VOIP traffic), we can most likely do heuristics
>based on the single packet. Even if there is only 32 bits of the known
>data in the packet (lets say version number and magic cookie or
>similar), then usually that is already enough for detecting the
>parameters and the probability that random ESP-encrypted packet has
>same content is less than 0.000000024% (1/(2^32) * 100%).
>
>So if VOIP traffic is heavily used then the heuristics most likely
>will have special protocol detection code for it.

[Ken] The point being that this traffic may be short lived, smaller packet, hence more packet per bandwidth, which will exercise the heuristics engine / cache issues much more then, say long lived TCP sessions (which are rare). 

>
>> Auditing / logging / sniffing / sampling are some examples of
>> stateless devices that do require to peek in the packets. Probably
>> lots more also, so look for others to provide examples...
>
>As those do not affect the forwarding of the packet, then the
>reliability requirements for them is much lower, meaning that they can
>also work without storing any state, and running heuristics for per
>packet basis. That of course do require implementing the heuristics on
>the hardware if we are talking about gigabit links or faster. My guess
>is that without any hardware support and only using software with
>modern CPU you can probably process more than 100MBit/s, but most
>likely not full 1GBit/s speed.

[Ken] Agreed on the need to implementing heuristics in HW, but this contradicts the original 'benefit' of heuristics, where heuristics engine can be run in SW and a resultant cache entry stored in HW. Adding an ever changing set of rules + heuristics engine is a non-starter - at least that is the feedback I am getting from the HW engineers I have spoken with - mucho complexity + cost!

>
>Of course if you are talking about very low cost appliances, then they
>will not have modern CPUs, but on the other hand people do not
>normally expect them to keep up with 1GBit/s speeds...
>
>> The speed of deployment may or may not be true. If the stars are
>> aligned, then it could be deployed within one or two refresh cycles,
>> which is about the same for heuristics in intermediaries devices.
>> After all, only a handful of vendors own a large percentage of the
>> market for OS / intermediary devices. Adoption is obviously based on
>> customer pull/perceived usefulness.
>
>The difference is that heuristics can be deployed within one or two
>refresh cycles of the intermediate devices after customers start to
>ask for it.
>
>Modified ESP can be deployed within one or two refresh cycles of the
>slowest vendor whose devices are used in the network.
>
>Meaning that if the printer vendor used in the network does not update
>their IPsec to support that modified ESP, then that modified ESP
>cannot be used by intermediate devices.

[Ken] There will always be a migration path, as well as exception cases. It is much easier to add a static rule for a fixed printer, then to have dynamic rules to allowing encrypted data to pass through the network. Additionally, some of the legacy devices may not even support a secure connection, so the traffic will be in the clear anyway. E.g. How many printers support IPsec today? If they need to support this in the future, then it is just as easy for them to support WESP, instead of ESP-NULL...
>
...snip...


[Ken] I think we need to consider all these issues in determining if a heuristics solution will work and scale under ALL circumstances. By contrast, WESP does not have any of these issues (bar adoption), as it is being designed for efficiency, cost effectiveness and scalability.