"The slow path can’t take advantage of constant time operations, but fortunately is less often used as most packets arrive in order. It’s also used when inserting new flows."<p>Going to be in a world of hurt once a slow-path DDoS packets come rolling in.
This is a cool idea like the potato powered clock. There are so many holes here. Let me just pick one. They don't seem to account for reassembly issues which is a huge problem and vastly multiplies your problem space depending on how you implement the solution. What the fuck am I going on about you ask?<p>Think of it like this: sig: abc
Traffic a[1] b[2] c[3]<p>where the packets are properly ordered in 1 2 3 order. Simple fragmentation could be sending them out of order - I believe this paper accounts for that. What if instead you send a[1] b[2] b[2] c[3]? Windows assembles this one way (depending on the version), linux another, bsd another. It's super fun. Then what if you send c[3] b[2] c[3] a[1] b[2]. One could argue, "hey d*ckhead we're going to normalize the traffic first" the problem is what is normal? Stevens had tons of good work on this. Some systems have a 'normalization' standard that's similar to how their network gear works. Also I find the fact that they say 'all the patterns' must be matched for the sig to fire. Does that include an or? Are they breaking the or down into sub detectors or something? The 10,000 signature thing is also kind of fake as the number of signatures constantly grows like the number of amazing taylor swift songs.<p>All in all these authors need to go read the old breakingpoint test standards, or ixia, or nss, or really anyone.
For multi-server situations, using Arista's Tap Aggregation (TapAgg) architecture is a popular solution for splitting up network packets after doing a optical fibre tap on the network connection:<p>* <a href="https://www.arista.com/en/solutions/tap-aggregation-with-danz" rel="nofollow">https://www.arista.com/en/solutions/tap-aggregation-with-dan...</a><p>The hosts would run software like Suricata, which is multi-threaded, and so can take advantage of many cores. (Until recently (3.0?) Snort was single-threaded.)
Discussed at the time:<p><i>Achieving 100Gbps intrusion prevention on a single server</i> - <a href="https://news.ycombinator.com/item?id=25108392" rel="nofollow">https://news.ycombinator.com/item?id=25108392</a> - Nov 2020 (35 comments)
I’m yet to see a signature matching system with defaults which are actually good. Don’t get me wrong, the ability to add regex filters are infinitely valuable for custom or emergency mitigations, but I think largely current systems blocking heuristics which look like attacks aren’t solving much.<p>That being said, I’m interested to see anomaly detection engines that learn data patterns and flag potentially malicious traffic.
General purpose CPUs seem to have peaked - purpose built hardware is definitely on the rise. It worked well for GPUs (FPUs used to be external too) so I guess it shouldn't be a surprise. Mainframe on the desktop!
Direct link to the PDF <a href="https://www.usenix.org/system/files/osdi20-zhao_zhipeng.pdf" rel="nofollow">https://www.usenix.org/system/files/osdi20-zhao_zhipeng.pdf</a> (not suggesting skipping the intro post as it had some good context/color)
For completeness, this is a (very good) November 2020 (two years ago) write up on a paper [1] with a video presentation (19 minutes) [2].<p>[1] <a href="https://www.usenix.org/system/files/osdi20-zhao_zhipeng.pdf" rel="nofollow">https://www.usenix.org/system/files/osdi20-zhao_zhipeng.pdf</a><p>[2] <a href="https://www.youtube.com/watch?v=KCUCUMNPMl0" rel="nofollow">https://www.youtube.com/watch?v=KCUCUMNPMl0</a>