https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287229
--- Comment #37 from Lucas Aubard <lucas.aub...@irisa.fr> --- (In reply to Michael Tuexen from comment #33) In the attacks we consider, the attacker does not try to reach FreeBSD limits to force it to drop some fragments. Instead, the attacker sends a sequence of overlapping packets that the NIDS and the supervised host reassemble differently (e.g., the NIDS favors the oldest data in the overlapping portion while the supervised host prefers the newest). Thus, the attacker does not try to reproduce our entire set of test cases; they only need one of the test cases to perform the attack. In our testing, we are trying to obtain the FreeBSD reassembly policy, and the limits are reached because of the VM setting and the testing parallelization. For your information, here are the results of some experiments I ran with 40 or 60 processes: - (1) vm.kmem_size="200M", vm.kmem_size_max="200M", maxfragbucketsize=100, maxfrags=400 (default), 40 processes => inconsistencies. - (2) vm.kmem_size="200M", vm.kmem_size_max="200M", maxfragbucketsize=100, maxfrags=4000, 40 processes => no inconsistency. - (3) vm.kmem_size="200M", vm.kmem_size_max="200M", maxfragbucketsize=100, maxfrags=4000, 60 processes => inconsistencies. - (4) vm.kmem_size="1000M", vm.kmem_size_max="1000M", maxfragbucketsize=3 (default), maxfrags=1983 (default), 60 processes => inconsistencies. - (5) vm.kmem_size="1000M", vm.kmem_size_max="1000M", maxfragbucketsize=3 (default), maxfrags=4000, 60 processes => no inconsistency. - (6) vm.kmem_size="1000M", vm.kmem_size_max="1000M", maxfragbucketsize=100, maxfrags=4000, 60 processes => inconsistencies. Let me know if you want that I test other parameter values. For my specific case, I should increase kmem_size to 2000M so as not to experience reassembly inconsistency. -- You are receiving this mail because: You are on the CC list for the bug.
