maximum ipv4 bgp prefix length of /24 ?

Sat Oct 7 17:15:21 UTC 2023

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

> Hi.
>
> On 06/10/2023 16:00, nanog-request at nanog.org wrote:
> > From: Matthew Petach<mpetach at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20231007/07cb49bc/attachment.html>