Re: [v6ops] Fwd: (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)

[Fernando Gont <[e-mail]>]

Hi, Nick,

On 7/2/23 17:22, Nick Buraglio wrote:
[....]
> 
> A few things that may be useful to add:
> 
> Using data enrichment such as correlation of address to behavior (i.e. 
> use of a passive system to look for patterns in addressing to behavior) 
> may decrease false positives. 

Could you elaborate a bit here?


> This is how we determine if we should or 
> should not filter ephemeral addresses, both v4 and v6, and it works 
> well. It does not lend itself to reputation lists in the larger sense, 
> but over time it will absolutely show patterns and curves in behavior 
> to specific blocks just like in IPv4.

Can you use such a system for, say, proactive defenses?



> Adding in some data about the detrimental effects of  over-filtering, 
> and the very real possibility of creating DoS events based on too many 
> routes in the blackhole table, etc. Easy enough to alleviate with 
> filters, but also leaves a bit of exposure in doing so (as you mentioned 
> in the filter FIFO addressing behavior).

Will do. Thanks!



> Having blackhole behavior or filter behavior that is expected to be 
> ephemeral and increasing in duration may aid in some of the resource and 
> minimize false positive impact. e.g. IP resource misbehaves, it is 
> filtered for n minutes and then unblocked. second offense is 15 minutes, 
> third offense is a day, whatever, you get the point. This is, again, how 
> orgs I have worked with for years have chosen to do things it works well 
> for those use cases.

There's also the question of how you "scale" the filters in terms of 
their lifespam. e.g., when you shorten the prefix, you might want to 
reduce the banning time.



> Operationally I have never felt that reputation lists are terribly 
> useful, personally (likely due to the old RBL days and pain caused by 
> them), but having them there as a guide is sometimes useful.

They are one tool in the toolbox. e.g., while you get the devops folks 
to patch vulnerable ednpoints, you probably don't want to e.g., show up 
in shodan.io (and similar).



> 
>     So that's what motivated the publication of this document.
> 
>     * TXT:
>     https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt <https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt>
>     * HTML:
>     https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.html <https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.html>
> 
> 
> FWIW, I didn't read it as implying that SLAAC was undesirable, but I did 
> only give it a quick skim.

We certainly didn't mean it. Obviously, ACLs rely on some address 
stability, so temporary addresses will be at odds with /128 ACLs.
(temporary addresses are theoretically supported by both SLAAC and 
DHCPv6, though)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494