RPKI.net Tool Rcynic: What to do if routes are showing up incorrectly as valid, invalid, or unknown:

Sometimes routes may appear as invalid or unknown when they should appear as valid. This will happen if the rcynic implementation is misconfigured in some way. Two of those reasons might be concerning the Trust-Anchor-Locators (TALs), or with permissions of the rcynic folders. Problems with the TALs include that it could be missing, it is in the wrong format, or its contents are incorrect. In regards to permissions, rcynic could have been run manually using sudo, thus creating files and folders with the user:group of root:root preventing the rcynic agent from being able to access or modify these files. These two issues can be identified quickly and can be remedied with relative ease once the problem has been identified.

Author: Humberto Nieves
 
Sometimes routes may appear as invalid or unknown when they should appear as valid. This will happen if the rcynic implementation is misconfigured in some way. Two of those reasons might be concerning the Trust-Anchor-Locators (TALs), or with permissions of the rcynic folders. Problems with the TALs include that it could be missing, it is in the wrong format, or its contents are incorrect. In regards to permissions, rcynic could have been run manually using sudo, thus creating files and folders with the user:group of root:root preventing the rcynic agent from being able to access or modify these files. These two issues can be identified quickly and can be remedied with relative ease once the problem has been identified.
 
1. Check the Trust-Anchor-Locator
One of the common issues with why a route might be showing up as invalid, or unknown when it should be valid is because there is something wrong with the Trust-Anchor-Locator (TAL). The TAL can be either missing, is in the incorrect format, or has the wrong information. The first step is to check a handful of the IP prefixes that are showing up as incorrect and see which RIR they are registered to. My favorite tool to find this information is RIPEstat. The RIPE Network Coordination Center has created a great online tool that allows you to find a whole slew of information relating to an IP address space, Autonomous System Numbers (ASN) and other useful information. 
 
Find RIR of IP Prefix: Goto http://stat.ripe.net and in the Search RIPEstat search bar on the center of the page enter the IP prefix that you are searching for. In the search results you will see a box titled Prefix Overview. This box will list the AS associated with the IP prefix, the company name of the owner, as well as the RIR associated with the IP prefix. In order to properly validate this route, the TAL for this RIR has to be installed and available to the RPKI tools.
 
Check for Missing TAL: In a normal Linux installation the TALs are stored in the /etc/rpki/trust-anchors folder. There should be a TAL for every Regional Internet Registry (RIR) at a minimum, APNIC has multiple TALs. At this point we should know which RIR the IP prefix or prefixes are associated with. Check your trust-anchor folder and see if there is a .TAL file for every RIR, except for APNIC which will have have 5. The name of each TAL is immaterial, but we recommend naming them by their respective RIR the same way that RIPE does for their RIPE Validator; arin.tal, lacnic.tal etc. The exception is APNIC which should be named apnic-X.tal where X is the root origin listed ie apnic-afrnic.tal, apnic-arin.tal etc. The root origin can be found on the first line of the TAL where it declares "rsync:". This will declare the certificate and it's associate RIR or IANA. Links to TALs for each RIR are below. The APNIC TALs need to be placed in individual files. The RIPE TAL is in the format for the RIPE Validator, which is slightly different. Because of this the RIPE TAL will need to be modified to match the RFC 7730 or RFC 6490 TAL format. Checking the format will be addressed below.
 
 
Check the TAL Format: Rcynic can accept Trust-Anchor-Locators in two format, those specified in RFC 7730 and RFC 6490. Any deviation from this will create an error. The most common issue is that the TAL is in the RIPE Validator format. TALs that are in the RIPE Validator format have additional lines and tags that make it unreadable to Rcynic. Below is an example of a RIPE Validator TAL:
 
ca.name = LACNIC RPKI Root
certificate.location = rsync://repository.lacnic.net/rpki/lacnic/rta-lacnic-rpki.cer
public.key.info = MIIBIjANBgkqhkiG9w0BAQEFAAOC...
prefetch.uris = rsync://repository.lacnic.net/rpki/
 
Meanwhile the same TAL in the RFC 6490 format is below:
 
rsync://repository.lacnic.net/rpki/lacnic/rta-lacnic-rpki.cer
 
MIIBIjANBgkqhkiG9w0BAQEFAAOC...
 
To make the RIPE Validator formatted TAL work with Rcynic you will have to do the following to make it match the RFC 6490 format:
1. Completely remove the first and fourth lines, the ones starting with "ca.name" and "prefetch.uris"
2. Remove the "certificate.location = " and leave everything from "rsync:" onward.
3. Remove the "public.key.info = " and leave everything else after the equal sign.
4. Make the "rsync:" line the first line. Add an empty line after it, and make the public key the third line.
 
After you have made the changes run sudo -u rcynic rcynic and then run validation_status on your rcynic.xml file to see if any of the TALs were unreadable. The command is validation_status /var/rcynic/data/rcynic.xml | grep unreadable and it will show if there was an unreadable trust anchor. The location of the rcynic.xml file can be different depending on your installation. If the TAL format is correct but you are still getting an "unreadable_trust_anchor_locator" error, then you could have an old or incorrect TAL.
 
Check TAL Contents: If after the previous steps you are still receiving an "unreadable_trust_anchor_locator" then it is possible that the TAL that you have is old or corrupt. To confirm this you will have to view the TAL in question and compare it to the latest TAL being hosted by the RIR. Visit the pages listed above and ensure that the latest TAL is installed. Remove any old TALs that you have.
 
2. Check User and Group Permissions
Rcynic data is stored by default at /var/rcynic/data. This is where the rcynic.xml file is stored, as well as authenticated data that will be routinely read, deleted and rewritten by rcynic. Sometimes the owner and group of the folders can be changed accidentally by running sudo rcynic without specifying the appropriate user or misconfiguring the rcynic-cron job. If you run sudo rcynic some of the folders in the /var/rcynic/data folder will have the user:group as root:root. This will prevent rcynic from being able to delete and modify that data. If logging for rcynic is set to /var/log/syslog it will be represented with an entry for rcynic or rcynic-cron stating that permission was denied, similar to the line below.
 
rpki rcynic[#####]: Couldn't prepare directory /var/rcynic/data/authenticated.2016-07-12T19:22:03Z/: Permission denied
 
To check for this goto the /var/rcynic/data folder and run ls -l . If the user:group for the files are not rcynic:rcynic (or whatever user you have designated to run rcynic) you will need to change this. You can remedy this with the command sudo chown -R rcynic:rcynic /var/rcynic/data
 
In summary, these steps should help correct the issue of why routes validation status would be appearing as incorrect or unknown. The issue could be with a Trust-Anchor-Locator (TAL), where it could be missing, in the wrong format, or with incorrect information. If everything is correct with the TAL, then the other possibility is that permissions could be incorrect within the /var/rcynic/data folder. Some folders could have the user:group as root:root preventing the rcynic user from acting upon the files correctly. There could potentially be other issues with why the routes are validating as incorrect, but these are two that are easy to check and correct.