pretty secure Border Gateway Protocol (psBGP)

The pretty secure Border Gateway Protocol (psBGP) is a combination of practical solutions using the best features of the sBGP and soBGP which aims to secure the BGP [32]. The psBGP consists of two models: the centralised trust model and the decentralised trust model. The protocol uses the centralised trust model for authenticating AS numbers and BGP speakers, and the decentralised trust model for verifying IP prefix ownership and ASPATH [33]. The mechanism of this protocol will be explained in the context of five main security goals: The first and second goals are related to data origin authentication for ASNs and BGP speakers, while the third goal is concerned with data integrity that does not add any additional security to the BGP because it is achieved implicitly when the BGP establishes TCP peering sessions with neighbours. In other words, the TCP already has IPSec, which performs the same task; therefore, this section will not talk about the data integrity goal. The fourth and fifth goals focus on a way to verify prefix origination and ASPATH during the exchange of routing information [32]. The objective of the psBGP is to explore alternative policies and trade-offs to provide an acceptable balance between practicality and security.

2.3.3.1 psBGP mechanism

It would be useful to start by explaining the architecture of the two trusted models on which the psBGP is based for authenticating ASNs and BGP speakers and asserting ownership of IP prefixes and ASPATH; then the mechanism for and verification of these data to prevent IP prefix hijacking could be demonstrated. As mentioned above, data integrity will not be discussed in this subsection because it does not add any direct security contribution to the components of inter-domain protocols.

First, the centralised trust model uses RIRs as the root of trusted certificate authorities like big ISPs. In general, RIRs generate public key certificates and sign them for association with ASNs. When an organisation applies for an AS number, the RIR will bind the AS number to a certificate to issue another certificate called the ASNumCert. ISPs follow the same procedure with customers applying for the ASNumCert. This distributes the effort of providing ASNumCerts among AS number providers (e.g., RIRs and ISPs). ASes also need to keep their private keys, which correspond to their issued public keys, to prove the authenticity of their specific ASNumCert to the RIR when they need to modify the certificate or for any other reason. In terms of authenticating BGP speakers, the psBGP uses the same model. An AS with a certified ASNumCert issues an operational public key certificate shared by all BGP speakers within the AS – namely, the SpeakerCert. BGP speakers need to have the private keys that have already been issued and which correspond to the public keys of the ASes with ASNumCerts to sign the SpeakerCert [32].

To verify AS numbers, the psBGP assumes that BGP peers on the Internet have already been provided with all neighbours’ ASNumCerts through out-of-band mechanisms, taking into account the fact that the ASNumCert is revoked when the corresponding AS number is not used or reassigned to another organisation. While changing BGP update messages between BGP peers, each AS sends its ASNumCert, which has been issued and granted by a RIR, in the BGP update message so peers can verify its AS number. Peers in turn verify every received announcement based on the ASNumCert attached to the BGP update message. If the verification is successful, peers accept the announcement; otherwise, it is rejected.

To verify the BGP, speakers use SpeakerCerts already issued in the authentication phase. SpeakerCerts are distributed among BGP speakers upon sending and receiving update

messages. SpeakerCerts are used for establishing secure connections with peers and for signing BGP messages. Assuming that BGP speakers have their peers’ public keys, when a BGP speaker receives an update message from its peer, it will use its public key to verify the identification based on the SpeakerCert, which includes the signature of the peer.

Second, the psBGP uses a decentralised trust model for verifying the propriety of IP prefix ownership and ASPATH. The architecture of this model is based on lists of ASNs bound with their IP prefixes. In other words, each AS creates a prefix assertion list (PAL) that consists of a number of bindings of AS numbers and prefixes. The first assertion in the PAL is allocated for the AS itself, and the other assertions belong to the peering ASes where the assertions (the endorsements of an AS’s peers) are ordered based on the ASNs [13].

In terms of verifying the origination of a specific prefix to an AS, the AS’s peers utilise the architecture of the decentralised trusted model. Generally, each peer on the Internet needs to have prior knowledge of some level of due diligence offline to determine what IP prefixes are delegated to each of its peers [32]. Based on that delegation knowledge, peers will have the origination of prefix endorsements (assertions) of an AS. When the AS wants to announce a specific prefix, peers on the other side will check the consistency of peers’ assertions in the PALs to verify its ownership to the prefix [13]. If at least one peer asserts that the AS owns the prefix, the BGP packet will be accepted; otherwise, it will be rejected.

ASPATH is a BGP attribute that consists of a list of AS numbers and is always sent with update messages. To verify ASPATHs, the psBGP uses a bit vector data structure in the PAL to make the operation very quick. The PAL structure in ASPATH verification is devolved to take triple format, {prefix, [P1, P2, P3, ..., Pi], Vi[ni]}, instead of duple format,{fi, [P1, P2,

P3, ..., Pi]}, where fi is endorsed prefixes, Pi is peers of an AS, Vi is a bit vector, and ni is the corresponding length. A bit vector is a data structure array that compactly stores bits. psBGP speakers use digital signatures to sign the new structure of PALs and, based on the the signature, verify each other. For example, [P1, P2, P3] represents a list of an ASPATH; however, P3 will not accept an update message from P2 until it has the digital signatures of {f1, [P1], v1[n1]}P1, {f1, [P1, P2],v2[n2]}P2 from P2 [32].

2.3.3.2 Benefits and limitations

Compared to the sBGP, the psBGP signs ASN certificates received from RIRs or trusted authorities directly, consequently reducing the certificate management burden, while the sBGP depends on a hierarchal structure of multiple levels of trusted certificate authorities for signing ASNs and has a complicated management process. Another advantage of the psBGP solution is that it can address uncoordinated, misconfigured and malicious BGP routers [33]. The psBGP is able to distribute the difficult task of tracing IP address ownership across all ASes on the Internet by making each AS verify its peering ASes based on the PALs [33]. The third advantage of the psBGP is that it includes a method for describing IP prefix engineering such as IP address aggregation [32], which increases the accuracy of the protocol and reduces false positives during the verification of prefix origination and ASPATH.

The psBGP also has two serious drawbacks with regard to verifying the ownership of IP prefixes when it uses the decentralised trusted model. First, some ASes could have only one neighbour AS, which would in turn mean that their PALs would only have one prefix assertion. In this case, peers of these ASes would not be able to check or compare the consistency of the assertions because they would receive a PAL with only one assertion from

these kinds of ASes. Second, some ASes leave their entry in the PAL empty or null, which means no endorsement was given by those ASes to their peers [13]. In other words, the psBGP would not be able to stop ASes that have null assertion entries from achieving IP prefix hijacking or affecting the robustness of the protocol.