BGP security: the BGPsec protocol

In our last post, we took a look at RPKI. With RPKI, it’s possible to reject prefixes that are originated by the wrong AS, as well as prefixes longer (more specific) than what the holder of the address block in question intended to be injected into BGP. This provides very good protection against accidents such as the YouTube/Pakistan incident.

However, a malicious party can easily work around RPKI by simply adding the AS number that’s authorized to originate a prefix to the end of the AS path in an otherwise fake BGP update. The RPKI mechanism won’t detect this; it simply trusts that the AS path is correct. And that’s where BGPsec comes in. The BGPsec protocol is intended to make sure that the AS path is indeed legitimate.

At this time, the Internet Engineering Task Force (IETF) is still working on documents that provide an overview of BGPsec and the BGPsec specification. BGPsec looks a lot like Secure BGP or S-BGP that was developed in the late 1990s at BBN Technologies. Unlike RPKI, BGPsec is an integral part of the BGP protocol, and thus, BGP routers must do the heavy lifting. When two BGP routers negotiate the use of BGPsec between them, they replace the AS_PATH attribute in BGP updates with a new BGPsec_Path attribute, which performs the same function—but now securely.

When a regular BGP router originates (injects into BGP) a prefix, it creates an AS_PATH attribute that contains just the local AS number. And when a router propagates a BGP update for a BGP neighbor in a different AS, it adds the local AS number to the left of the AS_PATH. This way, routers can determine whether an update was already seen by the local AS, and if so, reject the update because there’s a routing loop. A BGP update can contain several prefixes that share the same AS_PATH and other path attributes. Also, when a router creates an update that needs to go out to the members of a peer group, it simply generates the update once, and then sends copies of the update to all the members of the group.

With BGPsec, generating the BGPsec_Path rather than the AS_PATH works largely the same way, except that the router also includes the AS number that it’s sending the update to, and then generates a cryptographic signature over the information it added to the AS path. To protect the integrity of these signatures, routers can no longer pack multiple prefixes into a single update, and because the AS number of the receiving AS is in the update, a separate update (with a separate signature) must be generated for each neighbor.

With each hop in the AS path now protected with a signature, a router receiving a BGP update with a BGPsec_Path attribute can check whether the AS path is correct. Suppose the AS path is as follows: 789 456 123. The receiving router first checks the signature from AS 123. The signature contains a “Subject Key Identifier” that refers to the RPKI certificate of the router that created the signature, so the receiving router uses that certificate to check the signature. The router also checks that 123 intended to send the update to 456. It then checks the signature that was generated at AS 456 and whether 456 intended to send the update to 789. If then the signature from AS 789 also checks out, the AS path is valid and RPKI information can be used to bind the prefixes originated by AS 123 to that path.

It is possible to deploy BGPsec incrementally, where more and more ASes adopt the new mechanism over time. However, for BGPsec to work, there must be an unbroken path of BGPsec-capable routers between where a BGP update is originated and where it’s validated. When a BGPsec-capable router talks to a regular BGP router, it converts the BGPsec_Path to a regular AS_PATH, stripping off all security information in the process. Note that this is very different from RKPI deployment: here, as long as the holder of the address space generates a ROA, any AS can independently decide to run RPKI validation, without requiring support from intermediate ASes or changes to the BGP protocol.

Deployment of BGPsec will be challenging, as the protocol is quite resource-intensive. BGP updates will be larger due to the inclusion of signatures and supporting information. They will also be more numerous because each update can only carry a single prefix. Processing updates will take more time as each AS hop in the AS path requires a signature check. With a global routing table of more than half a million IPv4 prefixes and an average of four AS hops, that’s two million signature checks upon startup. Depending on the algorithm, this can easily take several minutes of computation, even on a fast CPU. In practice, it’s likely that BGPsec routers will have crypto hardware to speed up this function. Last but not least, BGPsec routers need access to a lot of RPKI information, so they’ll probably need significantly more memory than routers running regular BGP.

But all in all, the future of BGP looks more secure, even if that security will come at a cost of extra complexity and faster/bigger hardware.