On Sat, Oct 7, 2023 at 9:27 AM Willy Manga <mangawilly@gmail.com> wrote:
Hi.

On 06/10/2023 16:00, nanog-request@nanog.org wrote:
> From: Matthew Petach<mpetach@netflight.com>
[...]
>
> There's significantly less pressure to deaggregate IPv6 space right now,
> because we don't see many attacks on IPv6 number resources.
> Once we start to see v6 prefix hijackings, /48s being announced over /32
> prefixes to pull traffic, then I think we'll see IPv6 deaggregation
> completely swamp IPv4 deaggregation.

How about we educate each other to not assume you must deaggregate your
prefix especially with IPv6?

If you're the victim of a prefix hijacking, you don't really have a choice.
Right now, that's the only way to try to counteract a prefix hijacking; to advertise something at least as specific as the prefix being hijacked, or smaller if possible.  

I see 'some' (it's highly relative) networks on IPv4, they 'believe'
they have to advertise every single /24 they have. And when they start
with IPv6, they replicate the same mindset with a tons of /48 . You can
imagine what will happen of course.

A better alternative IMHO is to take advantage to the large prefix range
and advertise a sub-aggregate when necessary. But absolutely not each
end-node or customer prefix.

Absolutely.
Right up the moment someone hijacks part of your IP space.
And then you announce a bunch of more specifics to try to counteract the hijacking.
If you're a good, responsible network, you remove the more specific prefixes once the hijacking is done.
If you're most networks, you're overworked, understaffed, and cleanup is at the bottom of the priority list, so you just leave them being announced, just in case someone tries to hijack your space again.

Most cases of deaggregation I've seen are the result of an event that took place that triggered it, not just because people don't know better.

Now, RPKI can help a little bit, at least with protecting you from accidental route leaks and unintended hijacks; but it only validates the ASN originating the prefix, it doesn't validate the full pathway.  So, being a determined hijacker, I'm going to set my router up to pretend to be the correct origin ASN, and announce more specifics, adjusting the AS-PATH to match what my neighbors and upstreams expect to see, and utter silent thanks that most networks use a relatively liberal "max length" for the prefixes in their ROAs (just in case *they* need to announce more specifics to counteract my hijacking effort).

As we crack the BGP path validation nut, and put some means in place to validate BGP adjacencies, this attack vector will fade away, and the need to be able to announce more specifics willy-nilly will slowly go by the wayside.  But for the moment, it's just as necessary in IPv6 as it is in IPv4, though the resulting impact is less, because wise networks allocate their IPv6 prefixes in a sparse manner, meaning that during a hijack event, you only need to announce the matching /48s for the blocks carrying relevant traffic, which should be a small fraction of your overall v6 assignment.

I completely agree that we should educate network engineers to only advertise the largest prefix possible that covers your space.
But I also realize that in the world of non-secured BGP adjacencies and non-validatable BGP AS-PATHs, we cannot fault people for having to deaggregate during prefix hijacking events.

Thanks!

Matt