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

[Yaron Sheffer <yaronf at checkpoint.com>]

Title: draft-kivinen-ipsecme-esp-null-heuristics comments

Hi Gabriel,

 

This thread is precisely the discussion that Paul mentions.

 

The two alternatives I see on the table right now (Paul might have different opinions) are:

 

-          Publish a modified/wrapped ESP as Standards Track, and heuristics as an extra Informational.

-          Decide that heuristics are a sufficient solution for the problem, and publish it as the only ipsecme work item related to this charter item.

 

Paul and I would like to see more discussion and hopefully WG consensus being formed, now that we have a real heuristics I-D for everyone to analyze.

 

Thanks,

            Yaron

 

---

From: ipsec-bounces at ietf.org [mailto:ipsec-bounces at ietf.org] On Behalf Of gabriel montenegro
Sent: Thursday, February 05, 2009 9:38
To: Dragan Grebovich; Yoav Nir; ipsec at ietf.org; Paul Hoffman
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

 

I'd like to ask the chairs to comment further about something
they (Paul) said during the virtual interim about Tero's
heuristics draft. From the minutes:

        Paul said that we will discuss on the list before we decide which direction we will go

What directions do you see possible? I can see the value in
publishing it as an informational draft as a separate orthogonal
effort to the deterministic approach.

It's not that heuristics are undoable, but as this
thread (and others before it) has borne: it is not a general
solution applicable in all cases.

---

From: Dragan Grebovich <dragan at nortel.com>
To: Yoav Nir <ynir at checkpoint.com>; ipsec at ietf.org
Sent: Wednesday, February 4, 2009 11:24:20 AM
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Hi Yoav

 

As per #4, I did not elaborate what the policy should be, because it is network-specific, however the goal of having ESP-NULL (in this implementation) is to have strong authentication, while enabling thirds party (intermediate) equipment to perform DPI.  That could be integrated in the in-line switch/router/firewall (for better performance, but more expensive), or could be handed off to the side to an appliance (more inspections, cheaper, but slower).  Who am I to tell a Checkpoint guy about both implementations?  :-)

 

I also disagree that we should inspect just a first few packets (and keep their state), and then leave it alone to be done in cache.  Besides the scenario you outlined below, there are other applications when inspection must be done on each packet in each flow. 

 

I am not saying that heuristics are not doable, I am just saying I know of implementations today that require this check performed on all packets, and I don't believe devices we are working on today or in the future would be able to support it with heuristics turned on and meeting scalability and performance requirements.. 

 

Also, DPI can be used for more than just AV or packet content snooping.  It could be used for QoS to determine more granular traffic shaping and application-level routing.  There is also LI/CALEA aspect but I will leave that alone for now.

 

 

 

---

From: Yoav Nir [mailto:ynir at checkpoint.com]
Sent: Wednesday, February 04, 2009 3:04 AM
To: Grebovich, Dragan (BL60:SF00); ipsec at ietf.org
Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote:

Yoav

 

I apologize for not being clearer earlier.  I was not suggesting any new/different policy enforcement. 

 

I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level.  Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly.  Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter.

 

I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point.  When a packet hits a decision point, the following has to be determined asap:

 

   1) Is the packet terminated here or am I to forward it?  Until now, forwarded packets were always forwarded and no action was performed on the content.  Now we may want to turn on a policy to inspect packet content which is not terminated here.

   2) Can I do anything with it" (has it cleartext or IPSEC payload)?  If cleartext - it is trivial ...

   3) Is it AH or ESP?  This is quick and trivial too ...

   4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). 

 

IMHO for each packet we have to perform the four steps.  It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call.  I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives.   Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency).  I am concerned that on large (high-end) devices this may take an unacceptably large toll.

 

Dragan 

I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted.

 

Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL)

 

So for each packet, the processing is something like this:

1. Is the protocol non-IPsec? if so, do the regular inspection
2. Is the protocol AH? if so,  skip to the payload and do the regular inspection
3. Is the process ESP with an SPI and endpoints that have already determined to be NULL?: If so, skip to the payload and inspect. Note that this is a simple table lookup
4. Is this a new ESP SA? Do the heuristics, and then mark it in the table

Of course it's possible for the endpoints to cheat, start of with ESP-NULL, and then after the heuristics marked it as OK, begin encryption. This "attack" will work if all your policy says is "ESP must be NULL". But that is not an interesting policy. Real policies will require deeper inspection of the internal flows, so the cost of the heuristics becomes negligible, as it only requires looking at the first few packets of each ESP SA.

Email secured by Check Point

Email secured by Check Point