|Main Archive Page > Month Archives > ipsec archives|
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:
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.
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.
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.
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:
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.
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:
Email secured by Check Point
Email secured by Check Point