Skip to content

Home

Jump to bottom Edit New page
Thomas King edited this page Dec 5, 2015 · 20 revisions

RPKI-Light: RPKI and BGPSec Validation at the Route Server

Use-Case

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.

Objectives

  1. RPKI validation results (Invalid, Valid, Unknown) must be signalled from the route-server to peers.
  2. BGPSec validation results must be signalled from the route-server to peers.
  3. A spreading of the RPKI and BGPSec validation results across AS boundaries must be avoided.
  4. The proposed solution must be easy to implement in up-to-date BGP speakers (e.g., configure a filter).
  5. The IXP (=AS number) signalling RPKI / BGPSec validation results must be identifiable by the peer receiving the BGP announcement.

Discussion about Implementation

Objective 1 & Objective 4

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

Objective 3

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

Objective 5

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

Objective 3

Goals

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

Current Situations

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

Related Work

Add a custom footer
Add a custom sidebar
Clone this wiki locally