Detections
Analytics

4.1.6 Ensure RPKI is set for Origin Validation of EBGP peers

Information

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]
user@host# set validation group <group-name> session <RPKI Server IP> port <RPKI Server Port> local-address <Local IP>

Where:

<group-name> is a descriptive name chosen for the RPKI Server

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

<RPKI Server Port> is the port configured on RPKI Validator for the RPKI-RTR protocol

<Local IP> 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]
user@host# set policy-statement <policy-name> term <term-name> from protocol bgp
user@host# set policy-statement <policy-name> term <term-name> from validation-database <RPKI Database Result>
user@host# set policy-statement <policy-name> term <term-name> then validation-state <RPKI State>
user@host# set policy-statement <policy-name> term <term-name> then <action>

Where:

<policy-name> is a descriptive name for the Routing Policy

<term-name> is a descriptive name for the Term

<RPKI Database Result> is the result returned by the RPKI Validator

<RPKI State> is the RPKI State to be recorded locally for the route (normally the same as the RPKI Validator result)

<action> is a Routing Policy action such as to accept or reject the route

These steps can be repeated until all of your required terms and actions are configured.
Here we create the rpki-validation Routing Policy given in the Audit Procedure example:

[edit policy-options]
user@host# set policy-statement rpki-validation term valid from protocol bgp
user@host# set policy-statement rpki-validation term valid from validation-database valid
user@host# set policy-statement rpki-validation term valid then validation-state valid
user@host# set policy-statement rpki-validation term valid then accept
user@host# set policy-statement rpki-validation term invalid from protocol bgp
user@host# set policy-statement rpki-validation term invalid from validation-database invalid
user@host# set policy-statement rpki-validation term invalid then validation-state invalid
user@host# set policy-statement rpki-validation term invalid then reject
user@host# set policy-statement rpki-validation term unknown from protocol bgp
user@host# set policy-statement rpki-validation term unknown then validation-state unknown
user@host# set policy-statement rpki-validation term unknown then accept

The final term matches on all BGP Routes which do not return either valid or invalid from the RPKI Server, so does not require the additional match condition on the validation-database result.
The RPKI Routing Policy should now be applied to all BGP Neighbours or Groups used for Public BGP peering using the following commands from the [edit protocols bgp] configuration heirachy:

[edit protocols bgp]
user@host# set group <group-name> import <policy-name>

OR

[edit protocols bgp]
user@host# set neighbor <Neighbor IP> import <policy-name>

Where:

is the name of the BGP Group

is the Routing Policy configured in the previous step

is the IP Address of the individual neighbor to which policy will be applied

Note - Other BGP Import policies may already be applied, it is important to ensure all policy is applied correctly and in the correct order to prevent disruption to the network.

Default Value:

BGP Origin Validation is not configured by default

See Also

https://workbench.cisecurity.org/files/3069

Item Details

Category: SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|SC-7, CSCv7|12

Plugin: Juniper

Control ID: ec38cfafe4f01eab0abfb5f05c012dad2b1b3aa1a83a1061c775a9e27895fc63