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

[Tero Kivinen <kivinen at iki.fi>]

Grewal, Ken writes:
> >Are QOS and auditing devices really stateless?
> >
> >I would expect QOS devices to have all kind of reservation systems and
> >so on and for those I would expect them to be keeping state?
> 
> [Ken] QoS may be applied on the need of the underlying service. E.g.
> A static rule that indicates that I place voice traffic in a
> priority queue over data traffic may be sufficient as a basic
> stateless rule.

Note that you cannot do QoS without the co-operation of the sending
IPsec site. The sending IPsec node needs to put packets getting
separate QoS handling to separate SAs as otherwise the receiving IPsec
node will drop packets if they get out of the replay window.

Because of this there is no need to inspect the content of the ESP
packet, QoS must be done based on the IPsec SA, i.e. IP-addresses and
SPI number.

So for QoS there is no need to inspect the data inside the ESP-NULL
packet, as you cannot give different handling to different packets, as
if you do so, then those ESP-NULL packets getting slower path might
get dropped by the receiving IPsec node, as those packets getting
faster path have already moved replay window so that those slower
packets do not fit in to it anymore.

> [Ken] We have been through the deployment timeframe arguments before
> and it looks like we are going in circles here. It is speculative to
> say how long one solution will take to be adopted instead of
> another. This depends on a number of factors - e.g. some network
> appliance vendors have indicated that they will not employ
> heuristics in their network devices due the cost / complexity, but
> prefer a more deterministic approach, whereas others may be more
> willing to add this support and charge a premium for the appliances.

My guess is that regardless what we do, at least some middle box
vendors will implement heuristics in their high-end boxes, and after
one vendor supports it, others need to support it too to be able to
offer similar features than their competitors do. After a while even
more low-end devices will support it and soon most middle boxes do
support it. After that the requirements for supporting WESP will drop,
as middle-boxes work without it, so general support for it will stay
even lower.

But that is just my guess...

> [Ken] Why is DoS not a big problem, especially if we generate a new
> DoS opportunity on a new 'cache' in the network device?

DoS opportunities is a problem, but I do not think SPI cache will
create that much new opportunities. I.e. I claim that the SPI cache
can be implemented in such way that it does not offer any major DoS
opportunity. 

> BTW, insider threats are on the rise according to various public
> reports, so should not be discounted. This is one of the motivations
> of employing security, even within the Enterprise.

Yes, but I do not really think people are going to solve those using
ESP-NULL. I think they must move to encrypted ESP to provide
confidentiality also, and that makes the need for ESP-NULL visibility
even less.

For example most of the insider information (insider trading, leaking
trade secrets, espionage) problems cannot be solved by using ESP-NULL.

> [Ken] Perhaps there is a migration path consideration, where
> heuristics can offer interim benefits until a more deterministic
> solution is adopted. Adoption of either / both / neither will be
> ultimately based on numerous factors, including value, customer
> demand, etc.

This I agree and I have even tried to bring this up in my draft (see
last paragraph in the introduction section).
-- 
kivinen at iki.fi