From A to B

Challenges and Security

The RIRs provide a database in which AS operators store their guidelines, which define how AS operators announce or accept routes to and from external autonomous systems. From the outbound policy, appropriate inbound route filters can be set for peering partners on the partner's side of the peering, keeping BGP clean and making prefix hijacking more difficult [2]. Besides, each AS operator provides contact details in case of technical problems or misuse.

Of course, you cannot just blindly trust an arbitrary prefix from an arbitrary source. True to the motto "trust, but verify," it is important to check the incoming prefixes of the remote stations, which are referred to as peers in the BGP context [3]. The practice of autonomous systems distributing prefixes not assigned to their ASs is referred to as prefix hijacking. The aim is to redirect data traffic by manipulating the path selection.

On one hand, this arrangement can be used for man-in-the-middle attacks that sniff or manipulate data. On the other hand, denial of service attacks that disrupt the availability of services or entire networks are also possible. Last but not least, it could simply be a misconfiguration. Repeated cases of prefix hijacking have been seen, which highlights the need for countermeasures. However, incoming filters for route announcements cannot be used meaningfully or, if they are used, are under many restrictions.

Signing with Public Keys

The Internet Engineering Task Force (IETF) developed the Resource Public Key Infrastructure (RPKI) [4] as a potential countermeasure. This framework defines which autonomous systems are allowed to announce which prefixes. The attestation is based on the International Telecommunication Union Telecommunication Standardization Sector's (ITU-T's) X.509 PKI framework. RPKI uses the same hierarchy as for IP address assignment to reflect the chain of trust and consequently ensure attestation. The Internet Assigned Numbers Authority (IANA) is the root element of the PKI. From there it passes through the RIRs to the LIRs.

RPKI can use different responsibility models. Large companies or providers can use a local PKI, also known as delegated RPKI, and the option of a hosted RPKI. In this case, the PKI is operated by the RIR (the RIPE NCC in Europe).

Each LIR can have ASNs and IP prefixes attested by a certificate. Route origin authorizations (ROAs) can be created in this way. ROAs include the authorized ASN, the IP prefix, and the maximum length of the prefix, which means a potential attacker does not have the option of announcing this prefix with a more specific or higher prefix length, because a router prefers longer prefix lengths and an attacker could otherwise leverage this fact to redirect data traffic for a more specific prefix.

Certificates offer an option for cryptographic verification of the prefixes. If you do not set a maximum prefix length, the AS can only announce the entire prefix and not specific parts of it. Email alerts at RIPE-NCC point out unauthorized announcements and misconfigurations.

However, the remote station also needs to validate the ROA information of the incoming prefixes. This check can lead to the Not Found , Unknown , Valid , or Invalid results. Valid means that the check of the AS, the prefix, and the corresponding length was successful, whereas Invalid means the opposite. Not Found or Unknown means that no ROA was found. RIPE NCC provides sample configurations for manufacturers such as Cisco Systems and Juniper. However, not all router platforms support RPKI. Additionally, a potential compromise of the certification authority naturally would pose a risk.

BGPSec Validation

RPKI is not the only hedging option. Also based on RPKI, BGPSec offers a way of creating a chain of trust. The source of the routing prefix, the Originator, uses RPKI to sign the information, and all other routers of the AS path follow suit and sign with their private keys; therefore, each autonomous system authorizes the transferred prefix in the BGP update.

However, the use of RPKI and BGPSec also harbors risks for availability: Peers also need to check the certificates issued by the PKI. The Network Time Protocol (NTP) service must be available to check the validity period, as must HTTP-based services such as Online Certificate Status Protocol (OCSP) and certificate revocation lists (CRLs) to determine a possible revocation. However, routing information is required in turn, which leads to a loop dependency. With BGPSec, prefixes cannot be aggregated to reduce the number of prefixes transmitted. The PKI operator can also withdraw sovereignty from the AS operator by revoking the certificates used to sign prefixes or refusing to issue a certificate.

Admins and security managers can set static route filters to restrict inbound and outbound route announcements, which can be handled on the basis of the aforementioned data from the routing guideline of the responsible RIR. The guidelines are not particularly flexible. That said, it is always advisable to set route filters that block incoming prefixes from external sources.

For almost all peering instances, you will want to avoid standard routes because they only make sense for end customers without multihoming. Additionally, BGP routers should filter private IP address ranges bidirectionally with inbound and outbound route maps because other routers do not route them on the Internet anyway. These route maps usually match with prefix lists that can be checked for a subnet mask and prefix length in the accessibility information. To do this, they specify the number of matching bits with the "less than or equal to" (le) and "greater than or equal to" (ge) operands (Table 2).

Prefix lists offer the possibility of establishing an inbound and outbound binding to the peer in question. On this basis, you can apply inbound and outbound prefix filters, which enables pre-filtering in the distribution of prefixes. Route maps that use AS path ACLs, prefix lists, or community tags for this purpose are slightly more granular in terms of classification. The matching BGP attributes can be adapted on this basis. The route maps use sequence numbers for sequential processing of "classification" and "adaptation." They offer the option of changing BGP attributes, next-hop, and community tags with a set command on the occurrence of a positive match result.

BGP communities [5] can offer additional features and are a valuable addition. They use numbers as tags, which, in turn, define an expected behavior; therefore, a BGP directive can be controlled remotely. Both well-known and custom communities exist. Use of communities must be coordinated between the peers involved. You can store special tags in the communities for prefixes and, by doing so, communicate control commands to the peer for handling the data traffic for this prefix. Besides the filter and control options already presented, it also makes sense to filter out private ASNs in the AS path and AS paths that are too long.