> On Oct 10, 2023, at 13:36, Matthew Petach <mpet...@netflight.com> wrote:
>
>
>
> On Tue, Oct 10, 2023 at 12:58 PM Delong.com via NANOG <nanog@nanog.org
> <mailto:nanog@nanog.org>> wrote:
>> Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can
>> specify the maximum prefix length allowed to be advertised within a shorter
>> prefix and those (theoretically) block hijackers taking advantage of
>> advertising more specifics to cut you off?
>>
>> While I recognize that RPKI is not ubiquitous, enough of the major backbones
>> are dropping RPKI invalids that I think any sort of hijacking in violation
>> of that wouldn’t be very effective today.
>>
>> YMMV of course, but that seems to me to be a far better solution (almost
>> enough to make me rethink the questionable value of RPKI) than
>> disaggregation.
>>
>> Owen
>
> Owen,
>
> RPKI only addresses accidental hijackings.
> It does not help prevent intentional hijackings.
OK, but at least they can help limit the extent of required desegregation in
combat unless I misunderstand the whole MAXPREFIXLEN option.
>
> RPKI only asserts that a specific ASN must originate a prefix. It does
> nothing to validate the authenticity of the origination.
Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix
length”.
E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum
Length” attribute of /36, then any advertisement (even originated by 65500)
that is longer than /36 should be considered invalid.
> If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs
> protecting it, and AS YY has allowed more specifics to be announced within
> the prefix range covered by the ROA, I'm in like flynn, because I just need
> to configure my router with AS YY as the origin AS, then insert the expected
> ASN for the neighbor adjacency with my upstreams, and bob's your uncle, the
> more specific prefix passes RPKI validation, and traffic comes flying my way.
Yes, IF YY has allowed longer prefixes. If YY doesn’t allow longer prefixes
and/or doesn’t supply AS0 ROAs for more specifics that should not be announced,
then YY has indeed aimed a firearm squarely at their lower distal appendage and
fired.
However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as
well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY
would generate ROAs for
2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36
2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
> If AS YY doesn't allow longer prefixes within the scope of their ROA, then
> it's a bit dicier, because it comes down to AS-PATH length, but there's still
> a good chance you can suck in traffic from your adjacent neighbors.
Sure, but that’s true if the hijacker is willing to disaggregate down to
whatever your MAXPREFIXLEN is, no matter what, even if that’s /48. At least
this allows the AS owner to set some desegregation floor where the more
specific battle ends short of /48.
> So yes, hijackings in violation of RPKI aren't as effective, but RPKI doesn't
> prevent intentional hijackings--it just protects against accidental
> misconfigurations and unintentional hijackings.
Oh, you don’t have convince me on that one. I’ve long said “RPKI offers little
more than a cryptographically signed hint as to what hijackers need to prepend
to their announcements.”.
> Thus, deaggregation is still very much part of the defensive toolbox, even
> with RPKI in place.
Yes, but RPKI properly used does allow one to limit the extent of the
deaegregation battle.
> As a side note, it's also a really good reason why you shouldn't allow longer
> prefixes to be announced under your ROAs, except under very well understood
> conditions. ^_^;
Right… AND add AS-0 ROAs for any more specifics you don’t want announced.
Owen
