Remove RPKI Light

[job]

I consider https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light an extremely insecure mode of operation. We should not encourage such "outsourced security", especially not in places where people highly depend on the convenience provided by a route server.

I'd pull out the feature until it actually makes it to RFC status, which at this point is questionable.

[tking]

I dispute this request. If you do not trust the route server, please don't use it. If you do not trust the route server RPKI validation please don't use it.
As many customers/members trust the IXP (= route server) operators they trust the data they receive from it. So, RPKI Light makes a lot of sense for them.
I am pretty sure RPKI Light will reach RFC status soon.

[job]

Route Servers, like any ASN, should drop RPKI invalid announcements, not propagate them. It's that simple!

Would be the same as giving someone a vial of poison and defending yourself "but I clearly labeled it". Friends don't give friends poison.

[tking]

From my point of view it is not that simple: I agree that invalids should be dropped. How about unknowns? This is the reason we need RPKI Light.

[job]

Nope. You are trying to legitimize a weaker security posture for route servers. We don't need "RPKI Light" at all.

[tking]

You don't need it. Okay, others might.

[job]

@tking It's better to continue to discuss this in IETF, where the contributions are archived in the appropriate forum and can help construct a sense of concensus (or lack thereof) and further the dialogue. If you are in Chicago in two weeks time I'd be happy to try and persuade you over a cup of coffee. @pierky, it's up to you what you want to do with this enhancement request.

[pierky]

@job, @tking, thank you for your comments on this topic.

Since the beginning I was torn about whether to add RPKI light to the features of this tool. Personally I would not use it in a route server; I believe that if something needs to be validated, it must be done within the boundaries of my trust domain, that only includes components I manage directly, so - as a client - I would not appreciate such a feature.

Your comments led me to reconsider all the messages appeared on sidrops and grow and finally I decided to keep this feature somehow but also to "discourage" its use.

Currently, RPKI handling is limited to a global flag in the general configuration file, reject_invalid, that is True by default.
This means that

• routes received by the route server from its clients are validated then
• custom locally-significant communities, if provided within the configuration, are attached to the routes depending on their validity state;
• if the reject_invalid flag is True, INVALID ones are dropped;
• remaining routes (including INVALID ones if reject_invalid is False) are announced to the clients.

Now I plan to add more granularity to the use of RPKI

• by allowing client-specific level configuration of the reject_invalid flag
• by introducing an additional client-specific boolean flag: announce_invalid, False by default;
• by lowering local-pref of INVALIDs.

The mix of the two flags and of communities à la RPKI-light allows to have the route server able to receive INVALID routes and to announce them only to clients that have been configured with announce_invalid: True and which are supposedly ready to correctly interpret and handle them.

So:

• default values would have the route server to discard INVALIDs received by clients;
• reject_invalid: False and announce_invalid would lead the route server to propagate INVALIDs to those clients for which the latter flag has been set to True.
  In the second scenario, in the case where no roa_invalid communities (those used to mark INVALID routes) were provided within the configuration, an error would be logged and the configuration building process stopped, to prevent blind announcement of INVALID routes to clients that, in that case, would not be able to identify them.

Fine configuration granularity and an opt-in mechanism to receive INVALIDs seem to be a quite commonly accepted outcome among people who participated in the conversation on grow too.

The bottom line is that with ARouteServer I would like to provide a tool in the hands of IXP staff, possibly something that is easy to use and that offers by default feature-rich configurations with low effort. While I am determined to distribute a default configuration that is as secure as possible for the whole Internet, I can't even imagine to know all the deployment scenarios that IXPs have to cover, so I prefer to leave them freedom of choice.

I'll do my best to follow this draft on sidrops and grow and to evaluate further actions on the basis of its evolution.

Thanks again for your time on this.

[pierky]

In the end I decided to remove RPKI-Light support from ARouteServer.

After some tests and lines of code I noticed that current versions of BIRD (1.6.3) and OpenBGPD (OpenBSD 6.0) do not implement RFC8097 communities. OpenBGPD does not allow to use them at all while BIRD, which allows to configure "custom" extended communities, treats them strictly according to RFC4360:

If a route has a non-transitivity extended community, then before advertising the route across the Autonomous System boundary the community SHOULD be removed from the route.

To keep RPKI-Light support in ARouteServer would mean to possibly have something "broken" and incomplete going in production; moreover, as I already said, I don't like the idea behind RPKI-Light too much.
That said, currently I prefer to keep a strict approch until the community reaches a consensus and BGP speakers include support for RFC8097 (or whatever will be eventually decided to be used to signal validity state to route server clients). If/when the draft will become an RFC, the consensus reached and all benefits/drawbacks weighted up I will take it into account and merge it again into this tool, doing my best to provide high flexibility in configuration.

In the meanwhile, I implemented some configuration customization mechanisms that allow operators to use ARouteServer to generate configs and, at the same time, to code their own policy about RPKI validation results handling within .local files (site-specific custom snippets of config). Among other things, this will allows operators to do something similar to RPKI-Light. These new features (BIRD hooks and .local files) can be found in the dev branch and will be included in the next release of ARouteServer.