Hello, Nan,
Thanks a lot for your input! In-line....
On 8/2/23 00:52, gengnan wrote:
Hi Fernando,
Here are some thoughts after I reading the draft:
1. To my knowledge, the block-lists can be used for mitigating some
DDoS attacks by putting the Zombie's addresses in the block-lists. Of
course the lists should be updated dynamically in some way so as to
reduce false negatives and false positives.
Agreed. Are you suggesting any modifications/changes here? (i.e.,
anything that we have missed?)
2. For "Both types of ACLs have a similar challenge in common": IMO,
how to keep high accuracy for address filtering/validation in an
efficient way is really a challenging problem for both manual
configuration-based filtering and automated tool-based filtering.
Agreed here.
Particularly, I think (more from the operator's point of view) there
should be zero false positive so that legitimate users are not
affected and operators have confidence to conduct filtering
operations (e.g., deploying some tools). On the basis of zero false
positive, false negatives should be reduced as less as possible.
Of course I agree with the theory. But in reality, there's always a
possibility of false positives one way or another.
In a simple case, e.g.:
1) A user connecting to an ISP performs malicious activity
2) His/her address gets block-lists
3) The user performs a DHCP-release (or equivalent) to try to release
the previous address and get leased a new one.
4) A new user connects to the ISP and is leased the IP address from #1
5) This new user gets blocked as a result of the malicious activity of
the previous user of the IP address.
Similarly, if a user starts attacking from multiple addresses in a /64,
a system dynamically creating and/or applying block-lists will have to
aggregate such block-lists. -- i.e., you just can't simply employ
block-lists with thousands and thousands of addresses.
3. There are also some methods (e.g., RTBH [RFC 5635], uRPF
[RFC3704]) which do address filtering based on FIB instead of ACL.
Are they in the scope of the draft?
At least for this initial version, we have tried to focus on the
specific aspects where IPv6 changes the scale of the problem. However,
we have also received suggestions to consider other aspects into scope.
Anything in particular you think we should/could consider
incorporating/discussing?
Thanks!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
