BGP security: an overview of the RPKI framework

BGP security: an overview of the RPKI framework

    bgp_security_RPKIThe Resource Public Key Infrastructure (RPKI) system is a way to couple an IP address range to an autonomous system number through cryptographic signatures, described in RFC 6480. IP prefixes and AS numbers are the resources; the public key infrastructure is run by the five Regional Internet Registries (RIRs) that give out IP addresses and AS numbers. (ARIN in North America, the RIPE NCC in Europe, the Middle East and the former Soviet Union, APNIC in Asia and the Pacific, LACNIC in Latin America and the Caribbean and AfriNIC in Africa.)

    RPKI leverages the X.509 certificate/public key infrastructure system that is also used with TLS/SSL to authenticate and encrypt HTTP sessions, email, et cetera. The use of X.509 certificates is specified in RFC 5280 and RFC 3779 adds extensions for IPv4 and IPv6 prefixes and AS numbers. The RIRs issue these certificates when a resource is given out. Certificates are typically renewed every year, and unlike the certificates used for HTTPS, there’s no identifying information in them. Each RIR uses a self-signed root certificate to sign the certificates they give out.

    Holders of address space in turn generate Route Origination Authorizations (ROAs) that associate an address prefix with an AS number, giving that AS permission to originate the prefix in question. The address holder signs the ROA with their certificate’s private key. The ROA also contains a maximum prefix length and an expiry date. For instance, if AS 3333 signs a ROA for 193.0.0.0/21 with a maximum prefix length of /22, then AS 3333 is allowed to originate 193.0.0.0/21, 193.0.0.0/22 and 193.0.4.0/22, but not 193.0.2.0/23 or 193.0.7.0/24. However, the holder of 193.0.0.0/21 can generate an additional ROA to allow AS 3333 (or another AS!) to originate the longer prefixes at any time as ROAs may overlap.

    Certificates and ROAs are published in publicly accessible repositories, where they can be downloaded and used to generate lists of which prefixes may be originated by which ASes. At this point, the signatures and lifetimes of the certificates and ROAs are checked. If the start date of a ROA (and all the certificates in the chain back to the root certificate) is in the future or its end date is in the past, any the signatures are invalid or have been revoked, the ROA is ignored. All the ones that validate are then used to create a “validated cache”. This is a process that every network executes independently. Then the validated cache is used to generate a filter that is uploaded to the routers.

    Routers then check BGP advertisements against this filter, with one of three results: valid, invalid or unknown. The valid state means that there is a ROA matching the prefix and AS number used to originate the prefix. Invalid means there’s a ROA, but the AS number or prefix length doesn’t match. Unknown means there’s no ROA that covers the prefix. A router can then take action based on the RPKI state of a prefix. For instance, this is an example from the Cisco RPKI documentation:

    !
    router bgp 65000
    address-family ipv4 unicast
    neighbor 10.0.102.1 route-map rtmap-PEX1-3 in
    bgp bestpath prefix-validate allow-invalid
    !
    route-map rtmap-PEX1-3 permit 10
    match rpki invalid
    set local-preference 50
    !
    route-map rtmap-PEX1-3 permit 20
    match rpki not-found
    set local-preference 100
    !
    route-map rtmap-PEX1-3 permit 30
    match rpki valid
    set local-preference 200
    !
    route-map rtmap-PEX1-3 permit 40
    !

     

    The route-map rtmap-PEX1-3 sets the local preference to 50 when the RPKI state is invalid, 100 when it’s unknown/not found 200 when the RPKI state is valid. So paths that validate are always preferred over paths that aren’t signed, which in turn are always preferred over paths that should validate but don’t. Even if the valid path has a longer AS path than the unknown or invalid paths.

    Unfortunately, this doesn’t protect against the case where 193.0.0.0/21 is valid, but a third party tries to get traffic for that prefix using unauthorized advertisements of more specific prefixes, such as 193.0.0.0/24 – 193.0.7.0/24. Those don’t validate and get a local preference of 50, but they still overrule the valid 193.0.0.0/21 advertisement with a local preference of 200, because of the longest match first rule discussed in the previous post.

    A more secure approach would be to reject prefixes for which a ROA is present but the advertisement doesn’t validate, i.e., filter out invalids. You would think then if a certificate or ROA expires before a new one is installed, connectivity is lost, and without connectivity, it may prove difficult to generate and upload new certificates and ROAs… But expired (or not-yet-valid) certificates and ROAs are simply ignored, so the prefixes in question revert to unknown rather than invalid and thus remain reachable.

    This is a similar example from Juniper’s RPKI documentation:

    user@R0# show policy-options
    policy-statement send-direct {

    from protocol direct;
    then accept;
    }
    policy-statement validation {
    term valid {
    from {
    protocol bgp;
    validation-database valid;
    }
    then {
    local-preference 110;
    validation-state valid;
    community add origin-validation-state-valid;
    accept;
    }
    }
    term invalid {
    from {
    protocol bgp;
    validation-database invalid;
    }
    then {
    local-preference 90;
    validation-state invalid;
    community add origin-validation-state-invalid;
    accept;
    }
    }
    term unknown {
    from protocol bgp;
    then {
    validation-state unknown;
    community add origin-validation-state-unknown;
    accept;
    }
    }

    }
    community origin-validation-state-invalid members 0x43:100:2;
    community origin-validation-state-unknown members 0x43:100:1;
    community origin-validation-state-valid members 0x43:100:0;

     

    Please see the documentation at your RIR for more information on how to get certificates for your IP addresses:

    RIPE has an RPKI tools and resources page, where, amongst other things, you can download an RPKI validator. They also run a Cisco router that you can access over Telnet to try out a few RPKI commands at rpki-rtr.ripe.net (user ripe, empty password) and a Juniper at 193.34.50.25 and 193.34.50.26 (user rpki, password testbed). RIPE also has an RPKI validator where you can view a lot of RPKI information online.

    LACNIC has an origin validation looking glass that shows the current RPKI state of the internet. At the time of this writing, 31770 prefixes covered by a ROA validate (that’s 91%), 2500 (7%) are invalid due to a bad maximum prefix length and 601 (nearly 2%) are invalid due to bad origin AS. And with a total of 547,000 IPv4 prefixes advertised in BGP, 93.6% of all prefixes aren’t covered by a ROA yet. Also see the NIST RPKI monitor, which shows there’s an upward trend for both valid and invalid ROAs.

    Boost BGP Preformance

    Automate BGP Routing optimization with Noction IRP

    NO COMMENTS

    Leave a Reply