bgp countermeasures (secure-bgp) bbn technologies stephen kent, charles lynn, luis sanchez, martha...
Post on 16-Dec-2015
215 Views
Preview:
TRANSCRIPT
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
top related