AT&T/as7018 now drops invalid prefixes from peers

Wed Feb 13 02:02:15 UTC 2019

On Wed, 13 Feb 2019 at 00:24, Job Snijders <job at instituut.net> wrote:

> On Tue, Feb 12, 2019 at 7:30 PM Matthew Walster <matthew at walster.org>
> wrote:
> > 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.
>

I have massively oversimplified the situation, true, but essentially the
vast majority of the pie chart of "why a prefix would be originated from
another ASN and/or of a different prefix length" is:

   - Leaking from within the originator's borders where the border acts as
   a point of aggregation (atomic or otherwise). Mostly harmless.
   - Someone else leaking out the prefix when they generate it to assist
   with traffic engineering, including through a proxy/filter
   (Pakistan/YouTube)
   - Someone maliciously acting, so as to steal that traffic (predominantly
   Bitcoin mining pools, but could be ACME TLS etc)

Have I missed anything (that has substantial real-life relevance to any
incident seen so far) or would you say that was a far summary?

> > 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.
>

Not relevant to RPKI as it currently stands, which is unrelated to the
current mechanism being used: origin validation. Path filtering and IRR
prefix list filtering are much more important tools that should be used
first -- RPKI can only supplement those tools and should not be used in
isolation, unlike the others which do a "good enough" job for most
non-transit networks.

> 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.
>

We do? I beg to differ. Much of Europe does, national networks in North
America generally do, but those in the LACNIC / AfriNIC / APNIC regions? Of
course there are exceptions (HKIX et al) but your average path length is
going to be generally longer in those regions, and all it takes is for
someone at a local IX to forge a couple of path attributes, and suddenly a
bunch of traffic shifts.

> > 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. :-)
>

Oh whooops! Copied the URL from the wrong tab! I of course meant the draft
you and Massimiliano Stucchi have at
https://tools.ietf.org/html/draft-ss-grow-rpki-as-cones-00 -- my bad!!

> > 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! :-)
>

My idea is deployable today (for some values of today). Mark all the
received NLRIs as not to be installed in the FIB, replicate the data via
BMP or BGP with add-paths to a collector, process it, and ship out the
results via a BGP session that sets the correct next-hops. I wrote a simple
BGP speaker that had 4 byte ASN capability advertisement and graceful
restart, literally in a day. Sure, it only supported IPv4 unicast, but with
the wide array of open source BGP engines out there, it wouldn't be so hard
to put something together that offloaded the entire policy phase from the
router to a control plane.

You could easily add modules in (just a chain of OOP interfaces) so that
you could compare across prefixes, apply aggregation and damping, near
real-time mirroring of IRR data to use as filter sets, maybe even read
interface stats via SNMP / streaming telemetry / sFlow to start moving
traffic around when ports get hot. Oh dear, I've re-invented SDN haven't I?
:S

However, just because you *could* deploy it today, doesn't mean you should
=)

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190213/405f4016/attachment.html>