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

William Herrin bill at herrin.us
Tue Feb 7 04:26:48 UTC 2023


On Mon, Feb 6, 2023 at 7:40 PM Fernando Gont <fgont at si6networks.com> wrote:
> On 7/2/23 00:05, William Herrin wrote:
> > On the one hand, sophisticated attackers already scatter attacks
> > between source addresses to evade protection software.
>
> Whereas in the IPv6 case , you normally have at least a /64 without
> restriction. You might have a /56 or /48 thanks to your ISP, or simply a
> /48 thanks to some free tunnelbroker provider...

That's not what's actually happening. What's happening is a mix of
your computer gets one address unless you bother to enable DHCP/PD, or
your CPE gets an IPv6 block and your computer does SLAAC and/or DHCP
to assign itself a single IPv6 address. A lot of the probing is coming
from hijacked computers, so they have the address they have.

Sophisticated attackers can do more with the address blocks they get
from their own service providers. But sophisticated attackers could
spin up VMs with stolen credit cards, hijack BGP and do all manner of
things with IPv4 and IPv6 too.


> > On the other hand, there are so many addresses in a /64 that an
> > attacker can literally use a fresh one for each and every probe he
> > sends. Without a process for advancing the /128 ban to a /64 ban (and
> > releasing it once activity stops), reactive firewalls are likely to
> > become less and less effective.
>
> Not just /128 to /64, but also e.g. /64 to /56 or possibly /48...

Maybe. But I suggest that in the absence of data about how such
attacks will evolve, it might be best to start with a version of a
defense that's easy to conceptualize and implement.

Risk is vulnerability times threat. You already understand the
vulnerability. Before expending much in the way of resources, you also
have to understand the threat.

Regards,
Bill Herrin


-- 
For hire. https://bill.herrin.us/resume/


More information about the NANOG mailing list