This paper focused on discussing various string-matching algorithms, and proposing modifications to the well-known Aho-Corasick string matching algorithm to reduce the amount of memory required to store known malicious strings and improve worst-case timing. They achieve results in both of these areas, while slightly degrading average-case performance.
Overall, this paper didn't evoke very strong responses by most people, both in the reviews and during the post-presentation discussion.
People generally agreed with the paper in that decreasing the amount of memory used for signatures is important. Most people thought that it was highly beneficial to ensure that most, if not all, of the signatures used by an intrusion detection system fit in fast on-chip memory. Off-chip SDRAM simply cannot provide the memory bandwidth available through on-chip memory. It was generally agreed that, if current trends continue, the memory that can be fit on-chip will increase faster than the number of signatures tracked by intrusion detection systems. With the authors' model for highly compressed storage of signatures, fitting entire libraries of signatures on-chip will be possible. It was suggested that reading 128 bytes of memory each clock cycle (as outlined by the authors) was a rather lofty goal, but attainable using the BlockRAM found in most FPGAs.
A few of the paper reviews stated that the simulations were somewhat flawed. One person argued that it was unfair to compare the performance of algorithms designed to run in software to algorithms optimized to run in hardware, but it was generally decided that the performance comparions were not significantly skewed in favor of the authors' system. It was also mentioned that some of their numbers were suspect -- primarily, their metrics for hardware performance. The clock rate of the hardware systems was never stated, and no explanation was given for the fact that a theoretical reconfigurable system performed almost as well as an ASIC.
Another concern was that perhaps the authors' focus on worst-case performance at the expense of average-case performance was inapproprate. Upon discussion, however, it was concluded that achieving good worst-case performance is very important for intrusion detection systems, as it protects from denial-of-service attacks and the like. As long as average-case performance is acceptable, they argued that a solid worst-case performance is extremely desirable.
Despite a few questions about the paper -- the questionable numbers, the metrics used, and memory bandwidth issues -- reactions were fairly positive. While the majority of participants thought the paper belonged in the middle third of those reviewed this semester, only one person believed it was in the bottom third. This raised an argument that the method in the paper had some obvious room for improvement, but the contribution was still deemed to be acceptable.