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

Address Allocation PKI Example

SUB-Z

DSP-D SUB-XX

SUB-Y

SUB-ZZ

DSP-ASUB-XISP-1

DSP-C

SUB-YY

INTERNIC

ISP-2 DSP-B

IANA

14

Address Certificates

addr blksIANA orRegistry ISP/DSP

Issuer Subject Extensions

IANA IANARoot Certificate

ISP/DSP Certificate

Registry Certificate IANA Registry addr blks

addr blksRegistry orISP/DSP SubscriberSubscriber Certificate

all addr

15

AS and Router Certificates

Issuer Subject Extensions

ISP/DSP orSubscriber AS

ISP/DSP orSubscriber Router* AS

IANA ISP/DSP orSubscriber ASesAS Owner Certificate

Router Certificate

AS Certificate

* the subject name could be DNS

IANA IANARoot Certificate All ASes

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

BGPHeader

Addr Pref of Rtes Being Withdrawn

PathAttributes

Dest. Addr Pref. (NLRI)

AttributeHeader

Route + Address Attestations

AttestationHeader

IssuerSigned

InfoAlgorithm ID& Signature

SubjectExpDate

AS PathInfo *

NLRIInfo *

Path Attribute for Attestations

Attestation: Route or Address

Signed Info

UPDATE

*explicit in the aggregation case

Cert ID

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

Secure-BGP Peering Example

Secure-BGP deviceBorder Router

FDDI RingNAP

External PeerInternal Peer

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