Hi, Some comments in-line:
> -----Original Message----- > From: Fernando Gont <[email protected]> > Sent: Wednesday, February 8, 2023 8:02 PM > To: gengnan <[email protected]>; [email protected] > Subject: Re: [OPSEC] (IETF I-D); Implications of IPv6 Addressing on Security > Operations (Fwd: New Version Notification for > draft-gont-opsec-ipv6-addressing-00.txt) > > 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?) > Actually no modification suggestions here. I was sharing a possible use case of block-lists. > > > 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. > Yes. It is hard to say absolute correctness in a dynamic environment. What I said is more like a design goal for related tools for particular application scenarios. > > > 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? I thought about some more security operations can be analyzed to figure out whether there are particular challenges induced by ipv6 addressing. The related operations may be: intrusion detection, attack traceback, source address validation, ddos mitigation, etc. The ipv6 addressing properties such as address scope and reachability have more or less impact on these security operations. Which exact operation should be incorporated depends on the focus of the draft. Some references that may be helpful: [1] https://www.senki.org/operators-security-toolkit/ [2] https://www.manrs.org/netops/guide/antispoofing/ > > Thanks! > > Regards, > -- > Fernando Gont > SI6 Networks > e-mail: [email protected] > PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
