-
Notifications
You must be signed in to change notification settings - Fork 5
Home
Nowadays, at an IXP there are usually a lot of peers running routers not capable of running RPKI/BGPSec validation. However, RPKI and BGPSec validation already provides some value as it allows to detect route leaks / hijacks. Typically, many peers rely on the route-server anyway for receiving BGP information from other peers connected to IXP. So the route-server is a good place where RPKI and BGPSec validation could happen if there is a way of signalling the RPKI and BGPSec validation results to the peers.
This document is about a means to signal RPKI and BGPSec validation done at the route-server to peers. The way of signalling should be equal at all IXPs offering this service so that customers can easily consume this service.
- RPKI validation results (Invalid, Valid, Unknown) must be signalled from the route-server to peers.
- BGPSec validation results must be signalled from the route-server to peers.
- A spreading of the RPKI and BGPSec validation results across AS boundaries must be avoided.
- The proposed solution must be easy to implement in up-to-date BGP speakers (e.g., configure a filter).
The IXP (=AS number) signalling RPKI / BGPSec validation results must be identifiable by the peer receiving the BGP announcement.
- Well-known BGP Communities (RFC1997) or Extended BGP Communities (RFC4360) could be used for this.
- Well-known BGP communities / Extended BGP Communities can be easily filtered and used as triggers for dropping a route (e.g., for invalid RPKI validation results) or adjusting the local_pref of a route (e.g., for unknown RPKI validation results).
- If Extended BGP Communities (RFC4630) are selected the non-transitive feature can be used meaning that these Extended BGP Communities are stripped from a route before a BGP speaker is exporting it to another AS.
- If BGP Communities (RFC1997) are used we have to specify that a BGP speaker MUST strip these BGP Communities before a route is exported by a BGP speaker to another AS.
What is is benefit for this?Is this objective really needed?What is the use-case for this?- On the Euro-IX Tech mailing list we all decided that this objective is not of relevance.
The latest version of the BGPSec specification supports transparent route-servers:
- https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-13
- https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-06
- Coin an Internet Draft that defines how RPKI and BGPSec validation results are signalled from a router-server to peers.
- Implement the Internet Draft within the Euro-IX community - only for IXPs offering a RPKI and BGPSec validation service at the route-server. Implementation is done only on a voluntary basis.
- AMS-IX Falcon (http://www.ams-ix.net): AMS-IX is already running a route-server in beta mode providing RPKI validation. For signalling the following BGP communities are used:
- Prefix has ROA status: VALID (6777:65012)
- Prefix has ROA status: INVALID (6777:65022)
- Prefix has ROA status: UNKNOWN (6777:65023)
- DE-CIX (http://www.de-cix.net): Is currently designing and testing a solution.
- Lyonix (http://www.lyonix.net) / Rezopole: Is currently executing RPKI validation with sharing the result.
- Nicix (http://www.nicix.net) / Rezopole: see Lyonix
- JPNAP (http://www.jpnap.net/english/): RPKI validation is currently tested.
- BGP Prefix Origin Validation State Extended Community (https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling): For iBGP there is already a draft that describes more or less what we are trying to do with eBGP