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)

[Nick Buraglio <[e-mail]>]

On Tue, Feb 7, 2023 at 5:42 PM Fernando Gont <[e-mail]> wrote:

> 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?
>

Cross referencing flow data with syslog data with policy based alerting.
SIEM-type collection with some logic, essentially. Long (and medium) term
behavior analysis on traffic and host behavior. It definitely takes some
effort and probably isn't for everyone, so YMMV 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?
>

It really depends on how you define "proactive". If you mean leveraging
that data for instatianting filters before the traffic occurs like a
reputation list, probably not, although over time that type of list may be
able to be derived from the data. I am more thinking of a "realtime" black
hole on transit traffic with a passive monitoring system which uses policy
to define "good" and "undesirable" patterns. It is less for a service
provider style network and more suited for a network with no
ingress/egress asymmetry, although based on how you use the data collected
it could (and I have seen deployments where it does) build a list of
addressing that is simply always misbehaving and could be carte blanche
filtered at different locations.  This is fairly common in what I call
"open perimeter" networks, where there is a need to avoid middle
boxes, I've seen and helped implement this a handful of times using
everything from triggered BGP blackhole to flowspec, to simple ACLs.
The advantages are that the RBLs are tailor made for the environment
because they are generated from the actual traffic, and not a consumable
stream. The disadvantage is that they are not vetted at all and require a
lot of care and feeding.

As I type all of this I realize that this may be (and likely is) more
complex / specialized than you're aiming for, as it definitely skirts away
from the simple addressing feeds and essentially operates as a
self-generated RBL.


>
>
>
> > 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
>
ᐧ