How does Internet (Big-I) routing work? The Internet is broken up into Autonomous Systems (AS) An AS is an administrative boundary. Each ISP has 1 or

Transcription

1 Internet Routing Robustness Improving ftp://engr.ans.net/pub/slides/ndss/feb-1999/ Curtis Villamizar How does Internet routing work? How noticeable are routing related outages? Why have routing attacks not occurred? What measures are being taken today? Approaches to improve external routing robustness.

2 How does Internet (Big-I) routing work? The Internet is broken up into Autonomous Systems (AS) An AS is an administrative boundary. Each ISP has 1 or { AS. Major ISPs have 10s of AS. more Within an AS an Interior Gateway Protocol (IGP) is used. OSPF and IS-IS are used exclusively. No major ISP uses { or EIGRP in their backbones. RIP-2 Routers within an AS are under common administration. { External routes (inter-as routes) are carried by BGP-4 IBGP is used within an AS to carry external routes. { EBGP is used to exchange routes among adjacent peers. { Inter-AS routing (EBGP) reects routing policy that is { by business relationships. determined

3 Some characteristics of Internet Routing Physical topology is relatively static. Logical topology (AS boundaries and adjacencies) is relatively static. 3. Routing is highly dynamic. 4. There are just under 4,000 AS numbers in use. 5. The global routing table has about 60,000 routes. Typical days see peaks on the order of thousands of announcements 6. in a fteen minute measurement interval. Last week (for example) saw a peak interval over 6,000 and 7. adjacent intervals in the 2,000-4,000 range. numerous These characteristics must be considered when examining 8. properties of proposals. scaling

4 of Internet route selection Characteristics Routing protocols implicitly prefer more specic routes unless conguration per route dictates otherwise. explicit Regardless of all other path attributes, if a more specic is accepted, trac will be directed toward that route. route If an erroneous route covers critical hosts such as DNS servers 3. WWW servers, a denial of service can occur. or Many providers accept all routes from peers, with minimal 4. but lower BGP LOCAL PREF (which does not ltering a more specic route from overriding a less specic). override A least one major provider does not lter route announcements 5. from its customers. Misconguration by a customer can cause widespread denial 6. service for a specic prex if there are no sanity lters. of Router software error or radical misconguration can cause 7. outage for a wide range of prexes. an

5 noticeable are routing related outages? How Outages can be widespread and can get wide press coverage. For example consider the incident on April 25, glitch cuts Net access" By Nick Wingeld, Sta, \Router News.com CNET \Net The Oops Heard 'Round the World" by Michael Outage: Wired Stutz, Other articles on are listed on the IPMA \Death of the Internet" page. this More than a year earlier a similar incident occurred. The seems to average one every few years. Internet Smaller incidents are occurring much more frequently.

6 Why have routing attacks not occurred? In a routing based outage false routing information is injected the global routing data. Since many sites log routing into activity malicious action would be too easily traced. The impact of a routing based attack would be limited to a of service. denial A routing attack in progress can be contained with the 3. of a route lter and completely neutralized if the installation lter is at or near the source. The combination of little eect (short term denial of service 4. and high risk (too easily traced) is probably what is only) preventing any malicious activity.

7 What measures are being taken today? IGP protocols use peer to peer authentication, usually based MD5, but sometimes based on simple password. Snooping on exchanges is dicult. IGP IBGP typically uses at least MD5 authentication within IBGP TCP/MD5 is also used, specically to address a itself. BGP denial of service (RFC2385). potential Often no authentication is used over EBGP though some 3. TCP/MD5 between peers. These are usually switched use and EBGP uses a TTL of Using TCP/MD5 is interfaces better practice. a The amount of sanity checking on external route announcements 4. ranges from close to none to only accepting specic prexes from specic peers.

8 Approaches to improve external routing robustness. Information Storage DNS - zone transfer on request, expire and refresh timers. IRR - current: centralized database with full mirrors; toward: distributed with exchange of deltas moving Authorization Model DNS - simple delegation hierarchy, authorization per DNS based on signature of zone le zone IRR - hierarchies on AS, IP address, and routes relying on AS and IP address, authorization per object based both hierarchy of maintainer objects on Verifying Route Announcements Sanity lters applied to EBGP peers Signatures on route origination only Signatures at each BGP exchange 3.

9 Possible Approaches Current Proposals DNS distribution with origin signatures DNS distribution with full AS path signatures IRR distribution with BGP lters on peers 3. Worth Considering IRR distribution with per ISP selection of lters, origin signatures, or full AS path signatures

10 Distributed Routing Registry Repositories do not need to trust each other. Repositories agree to common authorization rules and use authentication methods. common For any given object there is exactly one repository in which object can be created and modied unless delegated. the An object and any beneath it in the hierarchy may be to another repository. delegated Transactions are ooded and each repository can recheck the and authorization of incoming transactions. authentication Repositories and mirrors will have a complete copy of the set repositories through processing the deltas to the database. of A small number of ooding adjacencies are needed. Scales according to the rate of change of the database. For details, consult RPS WG internet-drafts.

11 the authorization check requires objects from other repositories, If then the sequence numbers of the local copies of those Transaction submitter 3 - seqnos needed for auth submit object 2 - authorization check 4 - redistribute Primary repository identified by RPSL source sequence number Transaction submitter sequence numbers of other databases repository Initial Object Submission and Redistribution databases is required for mirrors to recheck the authorization.

12 Transaction submitter 1 Primary repository identified by RPSL source 1 - submit object 2 3 return to submitter sign transaction 2 - authorization check 3 - seqnos needed for auth 4 - redistribute 4 sequence number Transaction submitter sequence numbers of other databases submitter and repository Alternate Initial Object Submission the submitter is protected against the possibility of the Note: replaying a submission later. This method is not in repository the cuurent draft.

13 sequence number Transaction submitter sequence numbers of other databases 1 Mirror repository sequence number Transaction submitter sequence numbers of other databases Further Transaction Redistribution repository 1 - redistributed transaction 2 - recheck the authorization against full DB at the time of transaction using seqnos 3 - auth pass/fail 4 - optionally sign then redistribute repository optional signature of mirror the authorization check was repeated, the mirror may optionally If add a signature before passing the transaction any further.

14 sequence number Transaction submitter sequence numbers of other databases repository 1 - redistributed transaction 2 - recheck the authorization against full DB at the time of transaction using seqnos Redistribution to Lightweight Mirrors 1 Mirror repository sequence number Transaction submitter sequence numbers of other databases repository Lightweight Mirror (router?) 3 - auth pass/fail optional signature 4 - sign and redistribute of mirror 5 - just check mirror signature 6 - apply change with no authorization check 5 6 lightweight mirror must trust the mirror from which it gets The feed. This is a safe assumption if the two are under the same a (the mirror providing the feed is a host owned by administration same ISP who owns the routers). The lightweight mirror the simply checks the signature to insure data integrity.

15 Transaction submitter 1 Primary repository identified by 5 6 RPSL source 4 Optional Commit and Conrm Mirror Repository 1 - submit object 2 3 return to submitter Mirror sign transaction Repository 2 - authorization check 3 - seqnos needed for auth 4 - redistribute 5 - mirror confirms 6 - repository confirms In the event of a disk crash, the repository has already successfully ooded the transaction before sending the conrm back to the submitter. If a mirror is under the same administration, the repository can recover from disk and roll forward the transactions from the mirror before resuming operation.

16 Signatures on Route Origination Only The BGP route originator signs the BGP route. Determine public key for an IP prex. When receiving a route the public key for the prex is 3. and the signature is veried. determined

17 Full AS Path Signature The BGP route originator signs the BGP route. At each exchange of a BGP route a signature is added the advertising router indicating what AS the route was by advertised to. When receiving a route the public key for the prex and the 3. key for each AS must be determined and the signature public veried for the originator and each AS in the AS Path.

18 Filtering Routes from EBGP Peers AS numbers and IP addresses are assigned hierarchically. Intention to announce a route can be registered with autho- from both the AS and the IP address holder. rization AS registrations may include AS adjacencies and policy. All registry changes must follow a set of authorization rules include authentication requirements (with public keys which authorization species cryptographic authentication) where Complete registry mirrors can (and should) repeat authoriza- and authentication checks. tion Filters may be constructed from registry information. The type of lter used by ISPs may vary.

19 of Filters with Registry Based Approach Types As a minimum measure, an ISP can lter their direct announcements using a (relatively small) list of customers based on registered routes. This prevents becoming prexes source of a denial of service. the As a protection to direct customers, lters may be added deny more specic routes for any customer routes. which lter list can become quite lengthy. These If registration of routes reaches a critical mass, the announcements 3. of routing peers can be limited to specic prexes with assigned according to stated policies along the preferences These lters can also become quite lengthy. path. Filters may assign preferences to specic AS paths if adjacencies 4. and policy of the complete path is documented in the database. This form of ltering is not yet in use.

20 and Cons of Origin Signature Pros Advantages: Prevents most or all accidental attacks seen today. Disadvantages: Replay attacks and accidental replay Scaling wrt number of routes and announcements. One signature verications per route received. { Deployment: None. {

21 and Cons of Full Path Signature Pros Advantages: Origination and path is authenticated. Disadvantages: Scaling wrt number of routes and announcements. Two or more signature verications per route received. { Route aggregation removes signatures of originator of more specics or increases BGP overhead dramatically. Deployment: None in Internet. Elsewhere? {

22 Pros and Cons of Registry and Sanity Filters Advantages: No signature checks per route when a route is received. Frequency of cryptographic authentication check is logical change (database update). Changes to registry topology are infrequent (on the order of a few hundred information day) and rarely needs to be reected in real time. per 3. BGP ltering is implemented in currently shipping routers. Disadvantages: Origin and path is sanity checked but not authenticated. Filters are expensive in terms of router resources, though expensive than signature verication. less

23 Deployment of Registry and Sanity Filters There are 5 closely cooperating major registries (ANS, CW, RADB, RIPE) referred to as the IRR. CANET, There are many private ISP registries and a number of wishing to join the IRR. registries Common policy description dened by RFC2280. Distributed registry and common authorization and au- model is specied (IETF drafts) and being thentication Source will be freely distributed. implemented. Numerous providers use the IRR or a private registry to router lters based on their own routing policy. congure Critical mass has not been reached. Route objects are about populated. Adjacencies and tools necessary to base 90% local policy on policies of entire routed path are not available.

24 Common Limitations Partial origin deployment yields routes with no originating or origination of unregistered routes. signature Partial transit deployment or cooperation yields incomplete chain or AS with no stated policy. signature Security compromise along the transit path results in denial 3. service in either case. A complete signature chain in this of provides no assurance of trac delivery and therefore case security advantage. limited

25 Among Proposals, Which is Better? This may be a question of applicability. Full AS path signatures may be preferable for smaller { security networks who prefer signatures though higher security advantage is oered. limited Sanity lters may be more applicable for the global { where scaling is critical. Internet Both types of information, AS adjacency and policy, and keys, can be held in the routing registry. public

26 Summary Signatures on BGP AS Path oers security advantage over In the ltering model there is often no assurance ltering. the downstream AS is ltering and lters are not that applied against the full AS path. A complete commonly chain provides a clear positive indication. signature Either originator only signature or ltering oer a substantial in routing robustness over doing nothing. improvement Filters oer scalability over the signature techniques that is 3. in very large deployments such as the global Internet. critical It may be that the two/three types of solution are applicable 4. dierent situations. in All of the information needed for either approach can be 5. using the routing registries with the addition of distributed optional public key per AS and route. an

27 References ftp://engr.ans.net/pub/slides/ndss/feb RFC-2280 (RPSL) draft-ietf-rps-rpsl-v2-0txt draft-ietf-rps-auth-0txt draft-ietf-rps-dist-0txt draft-ietf-rps-dbsec-pgp-authent-00.txt