From: Dragan Grebovich <dragan_at_nospam>
Date: Tue Feb 03 2009 - 03:01:26 GMT To: <email@example.com>
I reviewed your heuristics draft and I believe it is interesting and
I believe the actual implementation would require more code than
current front-end hardware allows. The hardware we work with have a
limited space for that much heuristics code. Our preference is to find
a quick direct match (in a few instructions max). We would have to
respin hardware to allow your heuristics implementation. This might not
be implementable today, as hardware respins are costly and take
On low-end products, e.g. Access (aka Edge) it is unlikely that
today's and even tomorrow's implementations will have stateful DPI
implemented; these devices have low target COGS and usually do not have
simple packet filters and stateless firewalls and signature-based DPI
and IDS/IPS. It is unlikely that this would be the potential
implementation target for heuristics, as the cost/price would go up.
High-end products, e.g. Data Center front-ends, would allow a
heuristics implementation; it may have a stateful firewall and/or
IDS/IPS and other DPI capabilities, however this class of devices is
migrating towards virtualized platforms (major vendors are moving in
that direction), and they would be terminating tens or even hundreds of
thousands of SAs.
Even if these high-end devices have implementations running on
multicores, everyone is struggling to provide low latency and high
throughput, squeezing the last possible bit through of the pipe.
Keeping state until one finds that there is a match or not may introduce
unwanted latency and create large memory consumption (multiply
everything by e.g. 100K Sas) which we may not be able to afford.
On these High-end appliances, there is a definite need for
load-balancing between flows. That means the amount of the required
memory space will be at least 2x or 3x more, and also there is need for
additional CPU and I/O overhead to maintain two or more loanbalancers in
Another problem I see is that more traffic today is carried on UDP,
and those are inherently difficult to track as "flows". One must keep a
significant portion of traffic to determine ESP vs. ESP-NULL. Years ago
it was rare and mostly used for implementations such as SNMP, but these
days new applications ar ecoming out (e.g. Bittorrent-over-UDP).
SIP-over-UDP is another such implementation that may cause problems, if
heuristics are implemented in intermediate devices.
There will be stateful appliances in the future, but stateless
devices will remain in the future; these will not be able to perform
heuristics as defined in the heuristics draft. They may have to be
redeployed to other places in the network, causing forklift replacements
Even by your own conclusion, heuristics are not 100% accurate. There
are some "false positives" and some "false negatives" situations.
In summary, I find your draft to be interesting, and I am looking
forward to seeing it progress on Informational track. I believe also,
that a deterministic approach would be quicker and easier. I suggest
the "visibility" draft remain on the WG Standards track as it is more
Dragan Grebovich, CISSP
Enterprise Communication Solutions
Product Development Data Systems
Strategy and Architecture - Security
Billerica, MA 01821 U.S.A