On Tue, Feb 12, 2019 at 7:30 PM Matthew Walster <matthew@walster.org> wrote:
> On Tue, 12 Feb 2019 at 16:05, Nick Hilliard <nick@foobar.org> wrote:
>> Matthew Walster wrote on 12/02/2019 14:50:
>> > For initial deployment, this can seem attractive, but remember that one
>> > of the benefits an ROA gives is specifying the maximum prefix length.
>> > This means that someone can't hijack a /23 with a /24.
>>
>> they can if they forge the source ASN.  RPKI helps against misconfigs
>> rather than intentional hijackings.
>
> As it stands today, RPKI is only useful to prevent fat-fingering of ebgp routing policies, where routes are leaked from a point of "legitimate" re-origination such as a web filter service.

This simply isn't true. I'm willing to argue a bit about to what degree and in what circumstances RPKI Origin Validation technology is useful or not, but the use of the word "only" in this context is incorrect.

> It's entirely unsuitable (at present) for anything where someone is re-originating the prefix somewhere else with the same origin ASN present (i.e. maliciously) and it doesn't protect against someone accidentally sending you a prefix they heard elsewhere that is valid.

This also is not true. It is not as black and white as you make it out to be.

1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the AS_PATH except on the direct EBGP sessions between 7018 and 2914. This means that you can craft BGP UPDATES with 2914 all you want, but 7018 won't accept them. You can't inject yourself between AT&T and NTT using spoofing.

2/ Many networks give all their peering partners the same LOCAL_PREFERENCE, so you'll have to not only spoof the BGP Origin ASN but also compete & win for the shortest path in order for your hijack to arrive at the intended location.

We as industry essentially already have path validation for paths of length 1. This may not seem much, but since people in this industry tend to peer directly with networks that matter to them. The majority of Internet traffic flows over paths that have an AS_PATH length of 1.

> My understanding is that part of that problem can be solved with https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03 but once again it's still only preventing fat-fingering and not malicious intent.

Uh... that draft is about something else entirely. :-)

> I think I'd have a hard time convincing people of that though, and the RIR policy folk would have a small heart attack at the level of complexity required.

you are probably right about that, I'd prefer to stick to a technology that actually exists and is deployable! :-)

Kind regards,

Job