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