RPKI on IOS-XE (Enabling the feature)
Last updated
Last updated
Load ios-xe.rpki.enable.init.cfg
BGP is already setup between R1-R2 and R2-R3.
Configure RPKI on R2 for both IPv4 and IPv6, but do not use the information for local policy yet. We only want R2 to connect to the RPKI server and we want to see that R2 is loading the ROAs correctly, but we don’t want R2 to act on this information yet and actually perform any validity checks.
The RPKI server is reachable at 10.100.100.1 on port 3323.
BGP RPKI Route Origination Validation is a BGP security mechanism which reduces malicious and accidental route origination from the wrong AS. This prevents incidents such as the YouTube hijacking of 2008. During this incident, an AS attempted to null route YouTube’s prefix, but accidentally leaked Youtube’s prefix out to the internet, breaking YouTube’s traffic.
In RPKI Route Origination, each AS issues ROAs (Route Origination Authorizations) with the RIR. Typically the RIR hosts the signed ROAs, but each AS has the option to host their own CA and sign ROAs if they want. Each ROA object has three pieces of information:
The prefix (i.e. 1.0.0.0/22)
The max prefix length (i.e. /24)
The originating AS (i.e. 14003)
The ROA is a certification that the prefix can be announced by the originating AS. Announcements from other originating ASs should not be trusted.
The RIR signs this ROA and adds it to the RPKI repository. A route validation server, such as Routinator in our lab, is needed to load all ROAs from all RIRs, and interface with the routers. The routers use the RtR (RPKI to Router) protocol to pull in the database of ROAs from Routinator. The routers then use this locally to determine whether a given prefix:
Is valid (the prefix, prefix len, and originating AS match an ROA)
Is invalid (the prefix and prefix len match an ROA, but the originating AS is different)
Is not found (the prefix and prefix len do not match any ROA)
Note that this system does not validate the entire AS path. Only the originating AS (the first AS in the path) is validated using this system. This is “route origination validation” and not “path validation.”
On IOS-XE, we can only use TCP to interface with the RPKI server. This command enables the TCP connection:
Upon establishing the connection, the router will automatically start downloading ROAs and using them for prefix validation. The router will reject any prefixes that are invalid (they have a matching ROA but the originating AS is not valid).
To prevent this, and simply establish the connection without “doing anything” with the RPKI information, we use the following command:
This is different from the similar command bgp bestpath prefix-validate allow-invalid, which allows invalid prefixes to still be accepted and used as a bestpath. However, with the allow-invalid command, prefix validation is still occuring, and a valid prefix will be preferred over an invalid prefix. IOS inserts this validity check before the local preference in the bestpath algorithm. So to fully disable this behavior, we use the disable keyword instead of allow-invalid.
Notice that the BGP table has RPKI validation codes.
V means the prefix has a matching ROA
I means the prefix has an ROA but the originating AS is not valid
N means the prefix does not have a matching ROA, so the validity cannot be verified
Because we have disabled prefix validation for IPv4/uni and IPv6/uni, we should not see these codes in our BGP tables:
However, we should be able to see status about the RPKI server and browse the RPKI table. We can see information about the TCP connection using the following command:
More importantly, we can browse the RPKI table for both IPv4 and IPv6:
The table is fairly self explanatory. The maxlen column works sort of like le in a prefix list. For example, look at 1.6.8.0/22. The maxlen is 24, so the prefixes 1.6.8.0/22, 1.6.8.0/23, 1.6.9.0/24, etc, will match this ROA.
In the next lab we will begin acting on this information.
