BGP Countermeasures SecureBGP

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 cant 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 --gt authenticity and integrity of
  peer-to-peer communication
• Public Key Infrastructures (PKIs) --gt secure
  identification of BGP speakers and of owners of
  ASes and of address blocks
• Attestations --gt authorization of the subject (by
  the issuer) to advertise the specified address
  blocks
• Validation of UPDATEs using certificates and
  attestations
• Distribution of countermeasures information --gt
  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
IANA
DSP-A
INTERNIC
SUB-X
SUB-Z
SUB-Y
ISP-2
DSP-B
DSP-D
SUB-XX
SUB-ZZ
14
Address Certificates
Issuer
Subject
Extensions
all addr
Root Certificate
Registry Certificate
ISP/DSP Certificate
Subscriber Certificate
15
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
• owners 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 listeners AS to use the route in the UPDATE
• Includes identification of
• ASs or BGP speakers 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
Attestation Header
Issuer
Signed Info
Algorithm ID Signature
Cert ID
Subject
Exp Date
AS Path Info
NLRI Info
Signed Info
explicit in the aggregation case
20
Validating a Route

• To validate a route from ASn, ASn1 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 ASk1)
• 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 --gt 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 gt1
  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
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 its 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