Routing Security and the Border Gateway Protocol Dr. Stephen Kent Chief Scientist - Information Security

Routing Security  Routing is key to network operation and thus an essential element of network management  Most routing protocols do not include significant much less comprehensive security provisions  Attacks against routing protocols are growing  BGP provides the basis for all inter-ISP routing  The protocol is highly vulnerable to human errors, and a wide range of malicious attacks  BGP a good example of an insecure routing protocol, despite inclusion of s few security features and ad hoc efforts by ISPs & vendors

BGP Overview

BGP Example AS-1 AS-A non-BGP RouterBGP Router IEX AS-C AS-3 AS-4 AS-5 AS-2 AS-B Internet Exchange (nee NAP) ISP ASSubscriber AS

The Scale of BGP  About 125K address prefixes in BGP routing tables  These prefixes map to about 17-18K paths  About 10K BGP routers in service  About 2K organizations “own” AS #’s  About 60K organizations “own” prefixes  About 6K Autonomous System numbers appear in paths  The average AS path length for a route is about 3.7, about 50% of routes are 3 ASes or fewer, 95% are fewer than 5 ASes in length

Understanding BGP  BGP is the routing protocol that connects ISP and subscriber networks together to form the Internet  BGP does not forward subscriber traffic, but it determines the paths subscriber traffic follows  Routers representing ISPs (and multi-homed subscribers) execute BGP to exchange routes via UPDATE messages  Each BGP router receives UPDATEs from its neighbors and selects one path for each prefix as the “best” and reports that path to its neighbors  No one has a comprehensive view of BGP operation!

Processing an UPDATE BGP Routing Algorithm Adjacency RIB IN-i UPDATE from AS i Local Policy Database Local RIB Send UPDATE To other ASes Change LOC-RIB Only if Needed If LOC-RIB Changed, Generate UPDATEs for Neighbor ASes UPDATE from AS j Adjacency RIB IN-j

Underlying Assumption re UPDATEs  Each AS along the path is assumed to have been authorized by the preceding AS to advertise the prefixes contained in the UPDATE message  The first AS in the path is assumed to have been authorized to advertise the prefixes by the “owner” of the prefixes  A route may be withdrawn only by the neighbor AS that advertised it  If any of these assumptions are violated, BGP becomes vulnerable to many forms of attack, with a variety of adverse consequences

BGP Security

BGP Security Problems  The BGP architecture makes it highly vulnerable to human errors and malicious attacks against l Links between routers l The routers themselves l Management stations that control routers  Most router implementations of BGP are susceptible to various DoS attacks that can crash the router or severely degrade performance  Many ISPs rely on local policy filters to protect them against configuration errors & some forms of attacks, but creating and maintaining these filters is difficult, time consuming, and error prone

BGP Security Solution Requirements  Security architectures for BGP should not rely on “trust” among ISPs or subscribes l On a global scale, some ISPs will never be trusted l People, even trusted people, make mistakes, and trusted people do “go bad” l Transitive trust in people or organizations causes mistakes to propagate (domino effect)  Security solutions must exhibit the same dynamics as the aspects of BGP they protect  Both implementation and architectural security concerns must be addressed

The Basic BGP Security Requirement  For every UPDATE it receives, a BGP router should be able to verify that the “owner” of each prefix authorized the first (origin) AS to advertise the prefix and that each subsequent AS in the path has been authorized by the preceding AS to advertise a route to the prefix  This requirement, if achieved, allows a BGP router to detect and reject unauthorized routes, irrespective of what sort of attack resulted in the bad routes  Conversely, if a security approach fails to achieve this requirement, a BGP router will be vulnerable to attacks that result in misrouting of traffic in some fashion

S-BGP Architecture

Secure BGP (S-BGP)  S-BGP is an architectural solution to the BGP security problems described earlier  S-BGP represents an extension of BGP l It uses a standard BGP facility to carry additional data about paths in UPDATE messages l It adds an additional set of checks to the BGP route selection algorithm  S-BGP avoids the pitfalls of transitive trust that are common in today’s routing infrastructure  S-BGP security mechanisms exhibit the same dynamics as BGP, and scale commensurate with BGP

S-BGP Design Overview  S-BGP makes use of: l IPsec to secure point-to-point communication of BGP control traffic l Public Key Infrastructure to provide an authorization framework representing address space and AS # “ownership” l Attestations (digitally-signed data) to bind authorization information to UPDATE messages  S-BGP requires routers to: l Generate an attestation when generating an UPDATE for another S-BGP router l Validate attestations associated with each UPDATE received from another S-BGP router

A PKI for S-BGP  Public Key (X.509) certificates are issued to ISPs and subscribers to identify “owners” of AS #’s and prefixes  Prefix data in certificates is used to verify authorization with regard to address attestations  Address attestations, AS #’s and public keys from certificates are used as inputs to verification of UPDATE messages  The PKI does NOT rely on any new organizations that require trust; it just makes explicit and codifies the relationships among regional Internet registries, ISPs, and subscribers

Subscriber Organizations Regional Registries ISPs IANA Address Allocation Hierarchy Subscriber Organizations ISPs IANA (historical) Allocate Assign

Subscriber Organizations Regional Registries ISPs IANA AS # Allocation Hierarchy

Two Types of Attestations  An Address Attestation (AA) is issued by the “owner” of one or more prefixes (a subscriber or an ISP), to identify the first (origin) AS authorized to advertise the prefixes  A Route Attestation (RA) is issued by a router on behalf of an AS (ISP), to authorize neighbor ASes to use the route in the UPDATE containing the RA  These data structures share the same basic format

Simplified Attestation Formats Algorithm ID & Sig Value Signed Info Certificate Issuer ID Attestation Type Route Attestation (Prefix 1, … Prefix n ) AS n, AS n-1, … As 2, Origin AS Address Attestation (Prefix 1, … Prefix n ) Origin AS

Housekeeping for S-BGP  Every S-BGP router needs access to all the certificates, CRLs, and address attestations so that it can verify any RA  These data items don’t belong in UPDATE messages  S-BGP uses replicated, loosely synchronized repositories to make this data available to ISPs and organizations  The repository data is downloaded by ISP/organization Network Operation Centers (NOCs) for processing l Each NOC validates retrieved certificates, CRLs, & AAs, then downloads an extracted file with the necessary data to routers l Avoids need for routers to perform this computationally intensive processing l Permits a NOC to override problems that might arise in distributing certificates and AAs, but without affecting other ISPs

S-BGP System Interaction Example Repository S-BGP router S-BGP router upload self download everything ISP NOC upload self download everything exchange uploads push extract push extract S-BGP router S-BGP router UPDATEs Regional Registry Get ISP certificate Get ISP certificate S-BGP router UPDATEs

Deployment Issues for S-BGP

Deploying S-BGP  S-BGP requires: l Router software that implements S-BGP l Router hardware with appropriate storage & signature processing capabilities l Regional registries must assume CA responsibilities for address prefixes and AS # assignment/allocation l ISPs and subscribers that execute BGP must upgrade routers, must act as CAs, and must interact with repositories to exchange PKI & AA data  S-BGP can be deployed incrementally, with the constraint that only adjacent S-BGP ASes will receive and make use of S-BGP UPDATEs

S-BGP Deployment Impediments  Technical l Insufficient memory in most routers for RAs, AAs, public keys, etc. l Insufficient non-volatile memory for S-BGP data (e.g., to speed up recovery after reboot) l Slow CPUs for management protocol processing  Procedural l NOC & registry staff have to be trained l Operations staff have to believe it’s a good idea  Economic l ISPs cannot afford to replace/upgrade BGP routers l Registries cannot afford to offer CA services w/o imposing fees l Router vendors cannot afford to implement S-BGP software and hardware unless ISPs will buy it

Summary  Routing security is an essential aspect of net management security  Existing routing protocols have not been designed with security in mind, and are highly vulnerable as a result  BGP is representative of the security problems exhibited by routing protocols  It is the critical infrastructure element for Internet routing, called out with DNS security in the Administration Cyber Security plan  S-BGP is an example of the sort of comprehensive security solution required to address issues of this complexity and scale

Questions?