AT&T/as7018 now drops invalid prefixes from peers

Tue Feb 12 19:27:07 UTC 2019

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

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.

RPKI provides an additional layer of security, but it stands independent of
the need for prefix list and AS_PATH filter generation (likely derived from
IRR data). I'm actually of the opinion that the whole "PKI" part of RPKI is
the bit that really needs to die. PKI certificates brought no real benefit
to the solution. Embedding RFC 3779 (X.509 Extensions for IP Addresses and
AS Identifiers) makes the data so much less accessible and difficult to
process for all but the most technically competent system/network
administrators, especially considering most existing tools and libraries
for X.509 certificate operations just don't support doing anything
reasonable with them in a way that doesn't involve several hours afterwards
in a candle-lit bath with a Pink Floyd CD playing in the background.

Personally, I'd like to see BMP (RFC 7854, unidirectional flow of
information) bolted on to an extended version of the RTR protocol (RFC8210)
or a stripped down unidirectional BGP session, and have the whole policy
engine offloaded from the border router to some kind of daemon running,
potentially on a distributed controller of sorts, that:

   - Pulled in all this raw data and processed it, using the compute power
   available in servers after the invention of the Cyrix 200.
   - Asserted the veracity of the data it has received (real-time updates
   of prefix-lists, paths, trustworthiness, advertised "directionality" akin
   to peerlock etc) without having to periodically push new configuration to
   your routers.
   - Applied policy decisions, including mapping traffic for that
   destination into a FEC / MPLS tunnel as appropriate.
   - Possibly even applying aggregation at the FIB install level if
   appropriate to reduce total FIB entry size and programming time.
   - Distributed a final RIB (+FIB if needed) out to each of the BGP
   routers in the AS, depending on the view they needed.

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.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190212/039b8abb/attachment.html>