BGP Countermeasures (Secure-BGP)

1. BGP Countermeasures (Secure-BGP) BBN Technologies Stephen Kent, Charles Lynn, Luis Sanchez, Martha Steenstrup, Michelle Casagni, Karen Seo

2. Outline • Overview • Problem • Goals • Attack Model • Design Overview • Performance Issues • Deployment Scenario • Residual Vulnerabilities • Comparison with other approaches • Next Steps

3. Overview • In early 1997, we began work on BGP security: • assessed BGP vulnerabilities and possible countermeasures • designed Secure-BGP architecture -- aiming for a system that is dynamic, and scalable • analyzed overhead and performance impact (memory, CPU, bandwidth) • proposed optimizations • Follow-on work in 1998 and 1999 will include: • development of a prototype of Secure-BGP • experiments in the CAIRN testbed • presentation of the results and distribution of the software

4. The Problem • The Border Gateway Protocol (BGP) is vulnerable to attacks due to the lack of a scalable means of ensuring the authenticity and legitimacy of BGP control traffic: • no means of establishing the authority of an Autonomous System (AS) or BGP speaker to advertise a portion of address space (NLRI origin verification) • no means of establishing the authority of an Autonomous System (AS) or BGP speaker to advertise routes to a destination or destinations (AS_PATH validation) • need for peer authentication and ensuring of UPDATE integrity in conjunction with automated key management and anti-replay protection

5. Correct Operation of BGP • Each UPDATE is intact, sent by the indicated sender, and is intended for indicated receiver • Neighbor that sent the UPDATE was authorized to act on behalf of its AS to advertise the routing information in the UPDATE to the BGP speakers in the recipient AS • Neighbor withdrawing a route is the advertiser for that route • AS that generated the initial UPDATE is authorized by the Organization that owns the address space in the NLRI to represent the address space

6. Correct Operation of BGP (nice, but ...) • Neighbor that sent the UPDATE, correctly applied BGP rules, local policies, etc. • BGP speaker that received the UPDATE, correctly applied BGP rules, local policies, etc. • Subscriber traffic forwarded by a BGP speaker is valid (not spoofed, duplicated, etc.) We can’t enforce these aspects of correct operation because BGP affords speakers considerable latitude with regard to local policy, ASes do not tend to make public their local policies, and because validation and tracking of subscriber traffic is impractical

7. Goals of these Countermeasures • A scalable, deployable system that ensures • integrity, authenticity, and partial sequence integrity for each BGP routing UPDATE • valid AS_PATH in an UPDATE • authorization of the initial speaker to advertise the address space embodied in the UPDATE • Minimize the adverse effects of compromise of any BGP speaker, BGP management system, or portion of the proposed security infrastructure

8. Attack Model • BGP can be attacked in various ways • active or passive wiretapping of communications links between routers • tampering with BGP speaker software • tampering with router management data en route • tampering with router management server • Addition of the proposed countermeasures introduces a new concern • compromise of secret/private keying material in the routers or in the management infrastructure

9. Implications of Successful Attacks • Successful attacks on BGP or its management infrastructure can result in erroneous • UPDATE information • UPDATE distribution • route derivation and selection* • forwarding of user traffic* • destruction of user traffic* • Successful attacks on the security infrastructure could result in • BGP speaker spoofing • invalid address space representation by a speaker * not addressed by the proposed countermeasures

10. Design Overview • IPsec --> authenticity and integrity of peer-to-peer communication • Public Key Infrastructures (PKIs) --> secure identification of BGP speakers and of owners of ASes and of address blocks • Attestations --> authorization of the subject (by the issuer) to advertise the specified address blocks • Validation of UPDATEs using certificates and attestations • Distribution of countermeasures information --> certificates, CRLs, attestations

11. IPsec • IPsec use enables a BGP neighbor to verify • BGP message integrity • peer entity authentication (two way) • replayed BGP messages • BGP-4 has means for carrying authentication information, but no key management scheme or sequence numbering facility • IPSec supports automated key management, anti-replay service, etc. • Vendors are already putting IPSec into routers

12. PKI: Address Allocation Certificates • Used for verification of an organization's authorization to "advertise" a block of addresses • IANA is root of all addresses • Regional Registries below IANA (Internic, RIPE, and AP-NIC) perform allocation chores today • ISPs nominally receive address blocks from Registries • DSPs and subscribers nominally receive address blocks from ISPs • But, hierarchic allocation not always followed ... • Address space subordination extension (and hardware) can mitigate errors by registries, ISPs and DSPs

13. ISP-1 DSP-C SUB-YY Address Allocation PKI Example IANA DSP-A INTERNIC SUB-X ISP-2 SUB-Y DSP-B SUB-Z DSP-D SUB-XX SUB-ZZ

14. IANA IANA IANA Registry addr blks IANA or Registry ISP/DSP addr blks Registry or ISP/DSP Subscriber addr blks Address Certificates Issuer Subject Extensions all addr Root Certificate Registry Certificate ISP/DSP Certificate Subscriber Certificate

15. IANA IANA IANA ISP/DSP or Subscriber ASes ISP/DSP or Subscriber AS ISP/DSP or Subscriber Router* AS AS and Router Certificates Issuer Subject Extensions All ASes Root Certificate AS Owner Certificate AS Certificate Router Certificate * the subject name could be DNS

16. Attestations -- Overview • Each UPDATE includes one or more “address” attestations and a set of “route” attestations • These are carried in a new, optional, transitive path attribute • They are used by BGP speakers to validate the destination address blocks and the full end-to-end path (AS_PATH) information in the UPDATE

17. Address Attestation • Indicates that the final AS listed in the UPDATE is authorized by the owner of those address blocks to advertise the address blocks (NLRI) in the UPDATE • Includes identification of: • owner’s certificate • AS to be advertising the address blocks • address blocks • expiration date • Digitally signed by owner of the address blocks, traceable up to the IANA via certificate chain • Used to protect BGP from erroneous UPDATEs (authenticated but misbehaving or misconfigured BGP speakers)

18. Route Attestation • Indicates that the speaker or its AS authorizes the listener’s AS to use the route in the UPDATE • Includes identification of: • AS’s or BGP speaker’s certificate issued by the owner of the AS • the address blocks and the list of ASes in the UPDATE • the neighbor • expiration date • Digitally signed by owner of the AS (or BGP speaker) distributing the UPDATE, traceable to the IANA ... • Used to protect BGP from erroneous UPDATEs (authenticated but misbehaving or misconfigured BGP speakers)

19. Encoding of Attestations BGP Header Addr Pref of Rtes Being Withdrawn Path Attributes Dest. Addr Pref. (NLRI) UPDATE Path Attribute for Attestations Attribute Header Route + Address Attestations Attestation: Route or Address Cert ID Attestation Header Issuer Signed Info Algorithm ID & Signature AS Path Info * NLRI Info * Subject Exp Date Signed Info *explicit in the aggregation case

20. Validating a Route • To validate a route from ASn, ASn+1 needs: • 1 address attestation from each organization owning an address block(s) in the NLRI • 1 address allocation certificate from each organization owning address blocks in the NLRI • 1 route attestation from every AS along the path (AS1 to ASn), where the route attestation for ASk specifies the NLRI and the path up to that point (AS1 through ASk+1) • 1 certificate for each AS or router along the path (AS1 to ASn) to use to check signatures on the route attestations • and, of course, all the relevant CRLs must have been checked

21. Distribution, Replacement, Revocation • Certificate & CRL servers: • replication for redundancy, scalability • location (NAPs?) offering direct access and requiring minimal routing • support download of whole certificate database • support queries for individual certificates • support download of all certificate revocation lists (CRLs), but push/pull model not yet defined • Attestations • distributed with BGP UPDATEs as path attributes • cached with associated routes • expiration date present, but no revocation mechanism chosen yet

22. Performance Issues -- Resources • Certificates (generation and signing done offline) • disk space for storing certificates • CPU resources for validating certificates • CRLs (generation and signing done offline) • disk space for storing CRLs • CPU resources for validating CRLs • Attestations • disk space for storing attestations • CPU resources for signing and validating attestations • resources for transmitting attestations (to make this a dynamic system)

23. Performance -- Certificates • Processing -- certificates and CRLs are signed infrequently; this should be done off-line (and not by routers) • Storage: • ~30 Mbytes for ~65K Certificates • ~2 Mbytes for ~3K CRLs • DNS or Certificate server -- 1 entry/address block, 1 entry/AS, 1 entry/BGP-speaker in an AS • Transmission bandwidth -- An UPDATE will not hold the certificates needed to validate an average route. Therefore, certificates will have to be cached. Certificates will be transmitted at a low frequency except at startup. * Estimates are based on observed MRT data from Jan 1998

24. Performance -- Attest.’s (worst case) • Processing (using DSA/SHA-1) • at initialization of a BGP router (with 25 peers), 7.5 hours to validate UPDATEs; 3.5 hours to generate/sign (LOC-RIB) for 25 peers • daily, 5-6 minutes to validate UPDATEs; 5-6 minutes to generate/sign attestations (assuming 10 UPDATEs/second) • Storage • address attestations -- ~7 Mbytes • route attestations -- ~20 Mbytes for ADJ-RIB per BGP peer; 80 Mbytes (4 peers) to 500 Mbytes (25 peers) • Transmission bandwidth • countermeasures information adds ~400 bytes to a typical (2.6 ASes in path) UPDATE of 63 bytes, but UPDATEs represent a very small portion of all traffic, so ...

25. Optimizations • Cache previously validated routes to avoid re-validation, e.g., if router crashes or neighbor link is lost • Required BGP caching would cover ~89% of UPDATEs • retain peer cache over route flap • caching last two distinct paths from a single peer hits another 6% of UPDATEs • Mark routes “withdrawn” for use later, e.g., if link flapped, to speed up validation for reinstated routes • Keep only needed certificate fields in Secure-BGP databases

26. Optimizations (continued) • Offload generation/signing of route attestations, e.g., from routers to AS (also reduces vulnerability to compromise of keys) • Background verification of alternate routes • Deferral of verification until route is used • Heuristics to guide which prefixes are aggregated in an UPDATE -- this is aimed at reducing the amount of information that has to be made explicit (see page 19) in when an aggregate is later split into its components. • There are not many different ASes in most AS paths

27. Other Performance Savings • Most organizations will obtain their address blocks from their provider --> reduces number of address attestations needed. • Most DSPs and subscribers use default routing, not BGP • Most organizations/users are singly homed • Limit where UPDATE validation occurs, e.g., not needed for • singly homed “leaf” organizations • singly homed DSPs • multi-homed DSP -- check only if receive >1 route to same address blocks

28. Deployment Scenario • Near term we plan to use an auxiliary BGP box collocated with BGP border routers • Later, the countermeasures can be implemented as desired -- users can implement them, router vendors can offer them as a product separate from the router or as part of the router

29. Auxiliary BGP box • No changes required to router hardware or software except for re-configuration to work with this box • Provides CPU, memory, and disk needed to handle BGP routing and security countermeasures • Collocated with each BGP border router • auxiliary boxes peer with each other (with boxes in same AS and boxes collocated with neighbor routers) and the border router • border router peers only with auxiliary box and (optionally) internal BGP routers (same AS)

30. Auxiliary BGP box (continued) • Inexpensive hardware, simple interface to existing routers, easy use of PC crypto cards • Suitable base BGP code is readily available, e.g., gated • Compared to having countermeasures integrated into router, requires extra rack space and a router port, increases the number of items that can fail and that need to be managed

31. Deployment Assumptions • IANA and registration authorities will support PKIs • First tier ISPs will implement countermeasures • Lower level ISPs/DSPs/Subscribers may implement • ISPs/DSPs/Subscribers who are running e-BGP will cooperate in the generation and distribution of route attestations • Subscribers (or their providers) will cooperate in the generation/maintenance of address attestations • Auxiliary BGP devices can be deployed without changes to current router hardware or software (and may even improve performance of existing routers)

32. External Peer Internal Peer Secure-BGP Peering Example NAP FDDI Ring Border Router Secure-BGP device

33. Residual Vulnerabilities • Suppression of BGP messages by a misbehaving BGP speaker -- since AS1's BGP policies are not typically available to AS2, there is no simple way for AS2 to determine if AS1's speakers are misbehaving • A speaker can fail to withdraw a route that “should” be withdrawn, or it may inappropriately reassert a previously withdrawn route (mitigated by attestation expiration) • Misapplication of local policy-- not even detectable by other ASes, due to privacy of local policies • Passive wiretapping -- could use IPsec encryption

34. Comparison with Other Approaches • Routing Policy System Security -- C. Villamizar (ANS), C.Alaettinog (ISI), D. M. Meyer (University of Oregon), S. Murphy (TIS), C. Orange (RIPE) • NLRI Origin Verification -- T. Bates (Cisco Systems), R. Bush (RGnet), T. Li (Juniper Networks), Y. Rekhter (Cisco Systems) (Used with DNSSEC) • Protection of BGP Sessions via the TCP MD5 Signature Option -- A. Heffernan (Cisco Systems)

35. Comparison w/Other Approaches(cont.) • Analysis of overhead (storage, CPU, bandwidth) using real-world BGP data • Dynamic AS_PATH verification at each AS hop. • PKI for NLRI/Origin-AS verification (vs. IRR Database or DNS lookup) • Automated key management for authentication of peering sessions • AS has to provide attestations for each route even if it’s not going to do route validation. • Adds extra overhead to BGP UPDATEs • Changes the protocol

36. Next Steps • Additional performance analysis • Completion of design • Revocation mechanisms for certificates (maybe attestations) • Syntax details for attestations and certificates • Software design (APIs, file structures, etc.) • Assessment of how to best handle multicast • Development of prototype and experimentation in DARPA Cairn testbed • Selection of BGP implementation (gated, routed) • Develop, test and demonstrate software • Set up PKIs -- number of CAs, CRL issuance • Brief ISPs/DSPs, registries, IANA & router vendors