Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker

[Nick Hilliard <[e-mail]>]

Aris Lambrianidis wrote:
> I see two prongs in your email, a technical one (signalling method) and
> a "political" one (for
> lack of a better term), i.e. whether this draft is misguided in principle.

>From the bigger picture point of view, this draft is about trying to
make rpki accessible to operators, and builds on ideas first presented
in draft-ietf-sidr-origin-validation-signaling / RFC8097, which applies
to iBGP-only routing environments.

Stepping back a bit and looking at this problem, on almost every bgp
routing platform, rpki policy hooks have been implemented in a way which
makes deployment of rpki quite straightforward.  These hooks rarely
constitute more than a couple of lines for cache configuration, and
simple grammatical constructions for rpki policy matching.  In other
words, the router side of things is pretty easy.  The single item which
makes rpki deployment troublesome is operating an rpki cache or set of
caches.

If you want to deploy RPKI validation caches, there are several options
available: some of the RIRs already provide a hosted rpki validator
service, and RIPE NCC provides open source software with a GUI.
rpki-validator v2 is available now, and v3 is in the works with a
planned release date some time this month.  I.e. this is software which
is used already in operational environments, and which is under full
development support.

This means that the bar for pushing out a full rpki deployment using
actual caches is not very high in practice.  In the one case, all you
need is to create an online account and the whole lot is done for you,
albeit using an infrastructure which you probably wouldn't want to use
as a long term arrangement due to the fragility of depending on off-net
infrastructure (conversely noting that the rpki cache validation
mechanism is designed to be tolerant of situations where the cache is
unavailable).  In the other case, you need a VM or a deployment of VMs
and an amount of time and patience which is going to end up being
directly proportional to the scale of the deployment that you want to
build out.  Neither option involves rocket science, but both will
provide real RPKI, bells and whistles attached.

draft-ietf-sidrops-validating-bgp-speaker proposes to replace actual
RPKI with a synthetic flagging mechanism.  What's lost here is:
cryptographic authenticity, all the rpki validation policy hooks on
routers, and because this draft addresses ebgp rather than ibgp, we have
the extra complication that any upstream processing which involves
multiple bgp paths will also involve bgp best path selection, i.e. the
upstream is necessarily getting into the business of making implicit
routing decisions for the downstream without providing any of the hooks
that the downstream bgp speaker might want to use.

In one sense, this draft is not even about making rpki more accessible:
it's about how to translate a subset of rpki features into existing
policy methodologies, so that the operator doesn't need to use an rpki
cache.

The proposals in draft-ietf-sidrops-validating-bgp-speaker need to be
broken out into two separate sub-cases of multilateral ebgp (i.e. route
servers), and bilateral ebgp (i.e. normal bgp interconnection).

For all ebgp implementations, the moment you examine a community that
comes in over ebgp, you're implicitly trusting your peer to sanitise
that community for you.  In other words, because there is no
cryptographic authentication of the rpki state of the prefix, you're
depending on something which is no more or less reliable than hearsay
and which can be easily faked by tacking on an illegitimate community
and depending on misconfigured routers to forward the attribute.

Route servers present a particular complication because they are a 90%
solution to the problem of how to interconnect with lots of other
organisations at an ixp, with all the massive simplifications that a 90%
solution implies.  The conceptual difficulty with route servers is that
unless they provide add-path tx support (i.e. forward all prefixes to
rsclients so that the clients can make their own decisions about what to
do), they will perform bgp best path selection on behalf of their
clients, i.e. forward a single prefix, losing information in the process.

Job suggests that RPKI invalids should be dropped.  There might be sound
reasons to hold this opinion, but someone else might demand that RPKI
invalids be depreffed instead.  This outlines a fundamental difficulty:
without add-path tx support, the route server is touching the RPKI
problem and making explicit policy decisions on the basis of RPKI
validation results.  The problem with this is that rpki is subtle enough
that if you're going to want to deploy rpki at all, you probably want
enough policy manipulation hooks to get it to do what you want, not what
someone else decides for you.  These hooks would ideally need to specify
what to do with invalids, and unknowns and how to apply various
different attributes to them (e.g. tag, change localpref, change metric,
drop, keep, etc).

This sort of policy management needs to be handled from the route server
provisioning system, ideally dynamically so that client operators don't
need to prod the route server operator to make updates whenever they
want their policy changed.

If this is not present, then the route server is cooking up a bunch of
results based on a stated / implicit policy, but where the rsclient has
no means of inspecting all possible paths to make their own decision
about what to do with them.

As a further complication, the community mechanism proposed in this
draft requires code changes on the rsclient to make it work at all.
This is because generic extcomm support on routers doesn't usually exist.

This can't really be fixed by moving to bilateral peering because if you
move to bilateral, you're going to lose the community support proposed
by this draft, i.e. your peer at the IXP or on PNI probably isn't going
to support this draft.  This means that if you want RPKI, you're back to
square one: you will need to set up your own cache anyway.

The comments in this email
https://www.ietf.org/mail-archive/web/sidrops/current/msg00035.html
(text search term "tl;dr: route servers and rpki are an uncomfortable
fit", date Sat, 14 Jan 2017) are still relevant.

In summary, this draft provides a partial workaround for operators who
don't want to go to the effort of installing and configuring
off-the-shelf RPKI validator software, using a mechanism which will
provide arguably incorrect policy decisions in real world situations
using systems which they have no control over, which requires code
changes on client implementations, which doesn't provide a hook
mechanism to allow the operator to use their router's RPKI grammar, and
which in the best deployment scenario is only ever going to be possible
on a limited set of bgp peering sessions.  I can't reconcile this with
either good quality protocol definition or sound networking operational
procedures.

Regarding the argument that this already exists and that standardisation
is better than everyone doing their own thing:

> Signalling ROA status in route servers is already happening (France IX,
> AMS-IX), for better or worse.
> The question then now becomes, does the community want to consolidate
> into one way of doing things or not.

Standardising different implementations of a bad idea doesn't make it a
better idea.  If some IXPs are tagging prefixes on their route server
with rpki assessment information, then that's a decision for them to make.

I'm sorry if this assessment comes across as being harsh, but given the
limitations of what's being proposed, it would probably be more
constructive to use the time and effort that would otherwise be spent
working on this draft to educate operators about how relatively easy it
is to implement native rpki, and that if operators are serious about
rpki on route servers, then they will need either add path tx on the
route server or else use bilateral peering.

Nick