Details

Use RPKI for Origin Validation on Public BGP Peering

Rationale:

In addition to filtering Bogon and Maritan routes JUNOS routers peering with eBGP neighbors should also apply Ingress Filtering to prevent the router processing bad updates sent from the neighbor router, either maliciously or by accident.

Traditional Ingress Filtering, outlined in Recommendation 4.1.5 Ensure Ingress Filtering is set for EBGP peers, uses manually administrated Routing Policy configured on individual routers to validate prefixes being received from BGP Neighbours in Peer Autonomous Systems (ASs) based on Internet Routing Registry (IRR) entries.

This technique is maintenance intensive and prone to errors, although semi automated tools do exist to help. It is also not readily enforceable on Transit Connections, where the router does not connect directly to the Origin AS, but instead receives their routes via a Transit Service Provider. The receiving AS has no option but to trust that their upstream provider/s are correctly implementing filtering, with no way to validate the routing information they receive independently.

This leaves BGP Routing prone to Hijack Attacks, with numerous incidents in recent years causing issues both with reachability for some prefixes/ASs and with theft of information, after traffic is re-routed to fake destinations.

To combat this the Resource Public Key Infrastructure (RPKI) framework was created to allow Public ASs to sign their Resources (IPv4 and IPv6 Prefixes they will originate) by creating a Route Origination Authorizations (ROA) Certificate, through their Regional Internet Registry (RIR) (AFRINIC, ARIN, APNIC, LACNIC or RIPE NCC).

Public ASs can perform Origin Validation on the routes received through BGP, whether from direct Peer networks or through a Transit Provider. The Junos Router does this by checking the route information it receives through BGP with a RPKI Validator Server (sometimes called an RPKI Cache Server) through the RPKI-RTR Protocol defined in RFC 8210. The RPKI Validator maintains a cache of ROAs distributed by the RIRs and returns a verdict to the Router, which may be either:

Valid – The AS, Prefix and Prefix Length all match a valid ROA

Invalid – A matching ROA exists for the Prefix, but either the Origin AS or the Prefix Length does not match

Unknown or Not Found – No matching ROA exists, most likely the Resource Owner has not created an RPKI with their RIR

Routing Policy on the Junos device is configured to determine whether routes should be accepted based on results returned by the RPKI Validator. Most commonly Valid and Unknown/Not Found routes will be accepted and Invalid rejected, but this should be determined by the policy of each individual AS.

A full discussion of RPKI is beyond the scope of this Benchmark, but is covered in detail in the Juniper TechLibary BGP Origin Validation Using Resource Public Key Infrastructure, available for free from the Juniper website.

RIPE NCC, one of the RIRs, provide detailed instructions for installing several common RPKI Validators (including their own) in How to Install an RPKI Validator.

Impact:

Incorrect configuration of any Route Filtering may impact on reachability

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Configuration and deployment of an RPKI Validator and a full discussion of all configuration options is beyond the scope of this Benchmark.
To configure an RPKI Validator Server, issue following commands from the [edit routing-options] configuration hierarchy:

[edit routing-options]
[email protected]# set validation group session port local-address

Where:

is a descriptive name chosen for the RPKI Server

is the IP address used on the RPKI Validator for the RPKI-RTR protocol

is the port configured on RPKI Validator for the RPKI-RTR protocol

is a Local Interface address that the Router should use as the source for RPKI-RTR sessions

**Note ** – If multiple Logical Systems are configured, RPKI Validation will need to be configured separately for all LSYS being used for Public BGP Peering.
Next create a Routing Policy to accept or reject routes based on the RPKI Validation Database, using the following commands for each term from the [edit policy-options] heirachy:

[edit policy-options]
[email protected]# set policy-statement term from protocol bgp
[email protected]# set policy-statement term from validation-database
[email protected]# set policy-statement term then validation-state
[email protected]# set policy-statement term then

Where: