Skip to content

Home

Jump to bottom Edit New page
danielkopp edited this page Apr 10, 2017 · 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

The latest version of the BGPSec specification supports transparent route-servers:

Objective 4

  • There is a important point raised about the (default) behaviour of RPKI and its implications at an IXP. It was initiated by Job Snjders and discussed among by a group of people (see bellow).

The discussion started with:

“ Route Server operators should configure there route servers to reject/drop/ignore 'RPKI invalid' announcements, and thats should be the end of it. “

A recommendation for the operation at IXPs of RPKI was given by Nick Hilliard:

“ I'd hazard a guess that if an IXP were to provide a primitive facility in their provisioning system to allow clients to specify whether they wanted rpki-invalid or rpki-notfound dropped or used in the decision engine, that would satisfy most route server client organisations' policy requirements. “

The participants of the discussion revealed to have two main interest groups. Group A wants to have RPKI invalids dropped by default, amongst other points to promote a safer operation of route forwarding in general. Group B is against any action taken by the IXP, but instead want’s to have the decision of the IXP behaviour configureable and in default operation to forward the RPKI validation result as a community tag.

A list of people that jonied the discussion, with there opinion:

Job Snjders - (default drop) Carlos M. Martinez (configurable, tagging) Nick Hilliard - (configurable) Randy Bush - (configurable, tagging) Joel Jaeggli - (default drop) Jakob Heitz - (no comment on the topic) Marco Marzetti - (default drop, tagging optional) Matthias Waehlisch - (no comment on the topic) Martijn Schmidt - (default drop)

Objective 5

Somehow connected to Objective 4 concerns where raised, if the route server is not dropping invalids by default in a case when two routes for a similar prefix exist. This should never lead to a situation where a invalid route will be selected by the decision process of the route server over a valid one.

Objective 6

Define difference between a Route Server signalling prefix origin validation results through the communities defined in draft-ietf-sidr-origin-validation-signaling.

“ The draft does not clarify why there is a difference between a Route Server signalling prefix origin validation results through the communities defined in draft-ietf-sidr-origin-validation-signaling, and any other ASN signalling those communities via an eBGP session. Right now the two documents appear in relation to each other as following:

- draft-ietf-sidr-origin-validation-signaling-10.txt
    "define 3 communities"
- draft-ietf-sidrops-route-server-rpki-light    
    "you can attach those 3 communities to a prefix and announce them"

So what is the point? Either a generalised mechanism should be defined in which the pro's and con's of outsourcing one's routing security are explicitly highlighted and applies to all networks, or a justification should be provided why a Route Server is different from any other ASN in this specific context. “

Objective 7

Different statements within the security considerations:

"The introduction of a mechanisms described in this document does not pose a new class of attack vectors to the relationship between route- servers and peers." - however this is not true from an internal consistency point of view. Earlier on in the section this is written: "Therefore, a route-server could be misused to spread malicious prefix origin validation results."

Objective 8

Provide a configuration example on any platform which implements the recommendations mentioned in section 3.4 "Error Handling at Peers"?

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.

Internet Drafts Implementing the Objectives

Related Work

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