How to setup RPKI route validation in JUNOS

Resource Certification (RPKI)

The Resource Certification (RPKI) system allows Local Internet Registries (LIRs) to request a digital certificate listing the Internet number resources they hold. It offers validatable proof of holdership of a resource's registration by a Regional Internet Registry (RIR).

BGP Origin Validation

Origin validation helps to prevent the unintentional advertisement of routes. Sometimes network administrators mistakenly advertise routes they do not control. RPKI offers BGP origin validation and verifies if the particular route announcement is authorized by the legitimate holder of the address space.

Route validation is based on Route Origin Authorisations(ROA's)information received from internet registrars like RIPE, ARIN and others. A ROA states which Autonomous System (AS) is authorized to originate a certain IP address prefix. In addition, it can determine the maximum length of the prefix that the AS is authorized to advertise. 



RPKI Cache Server validator software

Enabling route validation requires validator software to be installed on a UNIX box that will act as the RPKI cache server. Several valdiators are available, I used the one provided by RIPE here.
https://certification.ripe.net/content/static/validator/rpki-validator-app-2.16-dist.tar.gz

Start the validation service
> ./rpki-validator.sh start
[ info ] Starting rpki-validator...
[ info ] writing logs under log directory
[ info ] Web user interface is available on port 8080
[ info ] Routers can connect on port 8282
[ info ] Writing PID 1291 to rpki-validator.pid

The validator software starts collecting ROA's from the various registrars and presents it in a web interface.

Capture              


Enabling route validation in JUNOS 

JUNOS supports route validation from version 12.2 enabling routers to make routing decisions based on the validity of routes. First your router needs to be configured to communicate with the cache server to receive any of the following validation states from it.

VALID
The route announcement is covered by at least one ROA

INVALID
The prefix is announced from an unauthorised AS** The announcement is more specific than is allowed by the maximum length set in a ROA that matches the prefix and AS

UNKNOWN
The prefix in this announcement is not covered (or only partially covered) by an existing ROA  

To configure communication between your router(s) and the validator / cache server:

set routing-options validation group rpki-validator session 10.1.1.2 refresh-time 120
set routing-options validation group rpki-validator session 10.1.1.2 hold-time 180
set routing-options validation group rpki-validator session 10.1.1.2 port 8282
set routing-options validation group rpki-validator session 10.1.1.2 local-address 10.1.1.1

To verify:
rdirkse@router> show validation session detail
Session 10.1.1.2, State: up, Session index: 2
Group: rpki-validator, Preference: 100
Local IPv4 address: 10.1.1.1, Port: 8282
Refresh time: 120s
Hold time: 180s
Record Life time: 3600s
Serial (Full Update): 344
Serial (Incremental Update): 344
Session flaps: 28
Session uptime: 1w0d 02:17:49
Last PDU received: 00:00:02
IPv4 prefix count: 7891
IPv6 prefix count: 1222

To check routes received in the router's validation database:
rdirkse@router> show validation database
RV database for instance master

Prefix Origin-AS Session State Mismatch
2.0.0.0/12-16 3215 10.1.1.2 valid
2.0.0.0/16-16 3215 10.1.1.2 valid
2.1.0.0/16-16 3215 10.1.1.2 valid
2.2.0.0/16-16 3215 10.1.1.2 valid
2.3.0.0/16-16 3215 10.1.1.2 valid
<snip>  

Routing decisions
To actually make route decisions based on the validation state read from the validation database you can create a policy that assigns local-pref values preferring valid over unknown, and valid and unknown over invalids. Apply this policy as an import on the BGP neighbor.

set policy-options policy-statement route-validation term valid from protocol bgp
set policy-options policy-statement route-validation term valid from validation-database valid
set policy-options policy-statement route-validation term valid then local-preference 110
set policy-options policy-statement route-validation term valid then validation-state valid
set policy-options policy-statement route-validation term valid then accept
set policy-options policy-statement route-validation term invalid from protocol bgp
set policy-options policy-statement route-validation term invalid from validation-database invalid
set policy-options policy-statement route-validation term invalid then local-preference 90
set policy-options policy-statement route-validation term invalid then validation-state invalid
set policy-options policy-statement route-validation term invalid then accept
set policy-options policy-statement route-validation term unknown from protocol bgp
set policy-options policy-statement route-validation term unknown then local-preference 100
set policy-options policy-statement route-validation term unknown then validation-state unknown
set policy-options policy-statement route-validation term unknown then accept

All done, now verify your policy is applied correctly and routes have the correct local-pref value:

rdirkse@router> show route protocol bgp validation-state valid
2.0.0.0/16 *[BGP/170] 1w2d 19:29:38, MED 10, localpref 110
AS path: 8455 3215 I, validation-state: valid

rdirkse@router> show route protocol bgp validation-state invalid
5.153.173.0/24 *[BGP/170] 2d 18:25:10, MED 10, localpref 90
AS path: 8455 50459 I, validation-state: invalid

rdirkse@router> show route protocol bgp validation-state unknown
1.0.0.0/24 *[BGP/170] 2d 18:27:48, MED 10, localpref 100
AS path: 8455 15169 I, validation-state: unknown

Detailed information available from Juniper http://www.juniper.net/techpubs/en_US/junos12.2/topics/topic-map/bgp-origin-as-validation.html  

0 Comments


Not Published

0/1000 characters
Go Top