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

[Tero Kivinen <kivinen at iki.fi>]

Grewal, Ken writes:
> 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.

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. 

> 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...

> 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. 

> 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.

> 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.

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.

> >Heuristics can also be implemented regardless of IKEv1 or IKEv2.
> >Modifying the ESP will be IKEv2 only, thus it will require end
> >nodes to start using that too. It seems that quite a lot of devices
> >are still using already obsoleted IKEv1 still, even when IKEv2 has
> >been out for 3 years...
> 
> This point is somewhat moot, as we are trying to address a new use
> case for ubiquitous transport mode IPsec, which is not the case
> today. It is a new use case, so if people want it, they will use the
> correct version of IKE.

To use correct version of IKE, in these use cases, do still require
ALL vendors used in the network to support IKEv2 in ALL of their
devices and in ALL of their operating systems before the modified ESP
can be assumed by the intermediate devices.

I.e. it for example requires that every single Windows Vista and Windows
XP (and of course older versions) machine to be updated to Windows 7
so they get IKEv2 support. 

> In fact, the same argument is true for all the other changes we are
> putting into IKE under the different charter items...

Nope. None of the other modifications we are doing is something that
requires every single IPsec implementation to be modified. You only
need resumption support if you are ever going to use it. If you do not
use it you do not need to know anything about it.

On the other hand the modified ESP support is required by all devices
talking IPsec in the enterprice network before the middle boxes can be
used. 
-- 
kivinen at iki.fi