I’m going to take a little break from my other two series to inject a short series on BGPSEC. I’ll return to HTIRW and RFCs you need to know shortly.
BGPSEC is a set of standards currently under consideration in the IETF to secure BGP beyond the origin AS – in other words, to secure BGP operation across the Internet at large. Since the RPKI is covered in pretty good detail in other places, I’m going to focus on BGPSEC itself, covering the basic operation of BGPSEC, as well as the various problems and holes in the idea. I should start by saying I’m all in favor of providing a more secure Internet DFZ (default free zone), but that we must do so in a way that makes sense operationally and technically. When you’re thinking through security, the most important question you need to ask is – what is it I’m trying to prove or prevent? It does absolutely no good to “secure existing operation,” or to focus on “proving the protocol is working correctly.” This would be much like securing the carrying of telnet over the wire, and claiming to have solved the authorization and authentication issues in user access to some device. It doesn’t work that way.
BGPSEC operation is based on the certificates issued through the RPKI process, such that each AS receives at least one public/private key pair. The private key can be used to sign objects, and the public key, in turn, used to verify the signature across those objects – much like the public/private key pair in PGP and many other encryption mechanisms. Any particular AS, to secure the routes it is advertising, uses the private part of its key to build a hash across the BGP updates it is sending to its AS level neighbors. The figure below illustrates this concept for those who are more visually inclined.
In this case, AS65000 has received a certificate from some signing authority. It uses the private key out of the key pair it has obtained to sign the update for 192.0.2.0/25 towards AS65001 across the entire AS Path (which includes just AS65000 right now), the receiving AS (AS65001 in this case), and the destination prefix (NLRI, 192.0.2.0/25). So the update from AS65000 to AS65001 contains something like this:
- Attributes: SIGA([65000,AS65001],192.0.2.0/25)
- AS Path: 
- Destination (NLRI): 192.0.2.0/25)
When AS65001 advertises this destination to AS65002, it adds another signature calculated using its private key across the entire AS Path, including the AS it is sending the update to, as well. So the update from AS65011 towards AS65002 would look something like this:
- Attributes: SIGB([65000,65001,65002],192.168.0.2.0/25,SIGA)
- AS Path: [65000,65001]
- Destination (NLRI): 192.0.2.0/25
Why should each AS build a signature across the entire AS Path, including the AS the BGP speaker is sending the update to? Because the signatures are intended to prove the connections between AS65000, AS65001, and AS65002 exist. You can think of this as a little like a two way connectivity check used to ensure both ends of a connection report the connection before using it in an SPF calculation.
What about the dual peering points between AS65000 and AS65001? Will each AS have a single private/public key pair (resource certificate) issued by some RIR? If so, then compromising a single eBGP speaker in AS65000 would force the entire AS to roll its key – this is not a good result. Generally, then, each eBGP speaker in the AS would have its own public/private key pair, signed by the AS level private key, which is in turn issued by/signed by a routing registry or some other trustable entity in the routing system.
(continued next week)