AT&T/as7018 now drops invalid prefixes from peers

Tue Feb 12 23:24:16 UTC 2019

On Tue, Feb 12, 2019 at 7:30 PM Matthew Walster <matthew at walster.org> wrote:
> On Tue, 12 Feb 2019 at 16:05, Nick Hilliard <nick at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190212/5a60901c/attachment.html>