Configurable communities for RPKI status about arouteserver

[pierky]

Hello, just to let you know that I'll take this feature into account for the next release, which is WIP.

Still not 100% sure about adding the additional customizable communities for RPKI validation state...

[pierky]

I've pushed a branch (still WIP) where I'm addressing this feature request.

4 new BGP communities are added: you can see them here https://github.com/pierky/arouteserver/blob/rpki_bov_custom_communities/config.d/general.yml#L814-L860

The idea is to cover the 4 communities that are described in the Euro-IX list, so we'll have the 3 RPKI BOV states + a "not performed". The main difference from what I understand from the Euro-IX list is that the 3 custom BOV communities I'm adding will NOT be propagated to the route-server clients, only the "BOV not performed" will be.

The "BOV not performed" is used like this: https://github.com/pierky/arouteserver/blob/rpki_bov_custom_communities/examples/auto-config/bird4.conf#L833-L838 (here's where a possible blackhole policy is implemented, thus BOV is not performed for those routes and the community is attached). Another use case is if BOV is not enabled and the community is configured, so it will be attached to all the routes, to signal the IXP operator's will to not do BOV.

The 3 states communities are used like this: https://github.com/pierky/arouteserver/blob/rpki_bov_custom_communities/examples/auto-config/bird4.conf#L544-L564 Here they are added to the existing RFC8097, but also they are eventually removed from routes that are announced (https://github.com/pierky/arouteserver/blob/rpki_bov_custom_communities/examples/auto-config/bird4.conf#L387-L400).

I'm explicitly dropping the 3 states communities from exported routes because I believe that they would violate the concept of RPKI itself: BOV is something that happens below the umbrella of a cryptographically verified chain of trust, and signals or information that are generated inside that trust boundary should not be conveyed outside of it.

[pierky]

The proposed solution was merged into dev, the new communities will be released in 1.10.0.

[pierky]

Oh I see... :-(

I can open a new issue if that's better.

That would be great, thanks!

[pierky]

Hello @bluikko,

thanks for raising this topic.

The 3 extended communities that ARouteServer uses to track the "RPKI verdict" are those from RFC8097 - BGP Prefix Origin Validation State Extended Community. That RFC was created specifically to document BGP communities used "to carry the origination Autonomous System (AS) validation state inside an autonomous system".

As you said, I agree that

the more difficult points lay in upper layers like "should this be configurable"

In my opinion the code should keep using the current RFC8097 communities to tag the routes with their validation state, hence I think a configurable custom community should not be implemented.
The reasoning behind this is that a RFC was specifically created to categorise those routes; unlike other informational communities (like those used to set the reject reason), those used to carry the validation state of RPKI Origin Validation have been standardized, so I believe it's worth using them.

I see the main motivation is that Alice-LG is not currently able to consume those communities and associate a description to them, but in this case I think it should really be up to its authors to add such a feature.

In any case, while digging into the code to reply to this issue I found a bug, which I fixed in afdb27d. In OpenBGPD, the RFC8097 were not added to the routes at all. Thanks for indirectly triggering the investigation that led to the fix ;-)

[bluikko]

In my opinion the code should keep using the current RFC8097 communities to tag the routes with their validation state, hence I think a configurable custom community should not be implemented.

I see and you have a good reason behind this opinion. It will not be a problem for me, I will just patch the config after generation.

I see the main motivation is that Alice-LG is not currently able to consume those communities and associate a description to them, but in this case I think it should really be up to its authors to add such a feature.

Totally agreed. However this lack of support points to the fact that RFC8097 is not implemented by most IXPs. They seem to actually follow the Euro-IX guidelines listed in https://www.euro-ix.net/en/forixps/large-bgp-communities/

Just wanted to make you aware of this alternative community scheme in case you are not familiar. It seems to be very popular with IXPs to the point of being the de-facto standard. I did a quick survey of IXP and 7 out of 9 used the Euro-IX scheme, the rest used arouteserver defaults or no scheme.

In any case, while digging into the code to reply to this issue I found a bug, which I fixed in afdb27d. In OpenBGPD, the RFC8097 were not added to the routes at all. Thanks for indirectly triggering the investigation that led to the fix ;-)

That is excellent!!

[bluikko]

Seems good so far. There is a slight issue on the textual representation of the route server policy:

The bullet points (unordered list items) for the 2 new sections are on their own line, just by themselves, and the text going with that bullet points is on the next line.

The bullet points also seem to have less indentation than the other 2 previous bullet points.

I can open a new issue if that's better.