Poor ML and Security aspects. The reviewer states how the paper does not discuss in-depth regarding ML model security.
Further, flows themselves are not generally a way to go in NIDS and most practical NIDS rely on unsupervised ML.
Paper does not consider adaptive attacks on ML models, concept drift issues (threat landscape may change/mutate), or labeling cost, and follows close world assumption.
Poor Introduction
Paper writing needs work.
Conclusion: The paper is good from a network and system implementation perspective but the novelty towards ML and security is lacking.
Steps to improve:
[x] Rewrite the introduction with better references and claims.
[x] Do not sell the system as an ML-based intrusion detection system.
[x] Decouple ML and intrusion detection from the paper's novelty. While submitting don't mention ML.
[x] Show how NIDS can be one of the use cases but that's not the core problem paper is tackling. Instead, it advances the prior data plane designs towards accuracy and scalability.
[ ] Rewrite appendix.
Review 2
Assumption of the existence of majority benign flows (in the introduction) may not always hold (eg. real-time DDoS attacks).
Flow pre-classification in the switch data plane may not always be accurate.
Unclear threat model.
Lack of important details such as the link bandwidth and the traffic rate (both malicious and background) used in the experiments.
Poor flow of paper.
Conclusion: The paper's idea is good but the writing should be able to convince the reviewer.
Steps to improve:
[x] Rewrite the introduction making it clear that the paper does not fixate upon the small number of malicious flows.
[x] Define threat models and assumptions early on -- make it clear that the number of flows is limited by low switch capacity and if there are million/billion flows, we would need to scale out by deploying multiple instances.
[x] Make it clear that as "soon as pre-classification is accurate enough", we evict the flows to the remote server for further analysis.
[ ] Add link bandwidth and the traffic rate (tcp replay rate) in the experiments and if possible, vary these parameters for a fixed hash table entry.
[ ] Rewrite the paper, polish it, and improve the flow of arguments.
Most of the reviewer issue seems to stem from paper writing alone.
Review 1:
Conclusion: The paper is good from a network and system implementation perspective but the novelty towards ML and security is lacking.
Steps to improve:
Review 2
Conclusion: The paper's idea is good but the writing should be able to convince the reviewer.
Steps to improve:
Most of the reviewer issue seems to stem from paper writing alone.