1 / 18

Protecting the BGP Routes to Top Level DNS Servers

Protecting the BGP Routes to Top Level DNS Servers. UC Davis Felix Wu. USC/ISI Xiaoliang Zhao Dan Massey Allison Mankin. UCLA Lan Wang Dan Pei Lixia Zhang. AT&T Randy Bush. NANOG-25, June 11, 2002. Routing To Top Level Servers. Root. Critical points of failure near root.

teryl
Download Presentation

Protecting the BGP Routes to Top Level DNS Servers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protecting the BGP Routes to Top Level DNS Servers UC Davis Felix Wu USC/ISI Xiaoliang Zhao Dan Massey Allison Mankin UCLA Lan Wang Dan Pei Lixia Zhang AT&T Randy Bush NANOG-25, June 11, 2002

  2. Routing To Top Level Servers Root • Critical points of failure near root. • 13 root and 13 gTLD servers • 25 BGP routes (2 share a prefix) • Fault/attack near root could have disproportionately large impact. • 13 bogus routes to deny service. • 1 bogus route to provide bogus DNS. • Scale helps contain risk in lower tree. • Many millions of DNS servers. net org com cairn nanog ietf bogus isi ops NANOG 25 - Toronto

  3. Example DNS Routing Problem • Invalid BGP routes exist in everyone’s table. • These can include routes to root/gTLD servers • One example observed on 4/16/01: originates route to 192.26.92/24 ISPs announce new path 3 lasted 20 minutes 1 lasted 3 hours Internet c.gtld-servers.net 192.26.92.30 rrc00 monitor NANOG 25 - Toronto

  4. A Simple Filter • Current BGP provides dynamic routes • Explore the opposite extreme... • Select a single static route to each server. • Apply AS path filters to block all other announcements. • Also filter against more specifics. • Route changes on a frequency of months, if at all. • Change in IP address, origin AS, or transit policy. • Adjust route only after off-line verification NANOG 25 - Toronto

  5. Why This Works: Theory • Scale is limited to a small number of routes. • No exponential growth in top level DNS servers. • Loss of a server is tolerable, invalid server is not. • Resolvers detect and time-out unreachable servers. • Provided surviving servers handle load, cost is some delay. • Expect predictable properties and stable routes. • Servers don’t change without non-trivial effort. • Servers located in highly available locations. NANOG 25 - Toronto

  6. Why This Works: Data • Analysis based on BGP updates from RIPE. • Archive of BGP updates sent by each peer. • 9 ISPs from US, Europe, and Japan. • February 2001 - April 2002 • Some data collection notes • Used only peers that exchange full routing tables • Otherwise some route changes are hidden by policies • Adjusted data to discount multi-hop effect. • Multi-hop peering session resets don’t reflect ISP ops. NANOG 25 - Toronto

  7. Simple Filter - Impact on Reachability ISP1 (US/Tier 1) NANOG 25 - Toronto

  8. How Static Are The Routes? • 3 changes in route to “A” over 14 months. • 2 (valid) changes in the origin AS • 5/19/01 origin AS changed from 6245 to 11840 • 6/4/01 origin AS changed from 11840 to 19836 • 1 change in transit AS routing policy • 11/8/01 (*,10913, 10913, 10913,*) -> (*,10913, *) • Could have built filter to allow this... NANOG 25 - Toronto

  9. What Routes Are Lost? • Results from 3/1/01 until 5/19/01 AS change. • Reduced reachability to “A” from 99.997% to 99.904% • 18 events when trusted route was withdrawn • 2 resulted in no route available (28 secs, 103 secs) • 8 instances of a back-up route lasting over 3 minutes • Longest lasting back-up advertised for 15 minutes • Similar results for other time periods and servers. NANOG 25 - Toronto

  10. Example of Filtered Routes 1239 10913 * server 19836 701 No route at 16:08:30 • With filter no route at 16:06:32 NANOG 25 - Toronto

  11. Simple Filter - Worst Case In Study ISP 3 (Europe) ISP 3 used one main route and a smallnumber of consistent back-up routes. NANOG 25 - Toronto

  12. Toward a More Balanced Approach • Required infrequent updates to the filter. • Especially useful to automate infrequent tasks. • Natural tendency to forget task or forget how to do task • More paths improves robustness • Simple filtered allowed only 1 path. • ISP3’s reachability can be improved if filterallows two routes… • Strike a balance between allowing dynamic changes and restricting to trusted paths. NANOG 25 - Toronto

  13. Our Adaptive Filter • Slow down the route dynamics and add validation. • Apply hysteresis before accepting new paths • Add options for validating new paths: • Believe route based purely on hysteresis • Probabilistic query/response testing against known data. • Trigger off-line checking (did origin AS really change?) • Algorithm details in upcoming paper http://fniisc.nge.isi.edu NANOG 25 - Toronto

  14. Impacts on Reachability (Adaptive Filter) gTLD servers ISP1 Root servers NANOG 25 - Toronto

  15. Impacts on Reachability (Adaptive Filter) gTLD servers ISP3 Root servers NANOG 25 - Toronto

  16. Conclusions • Routing faults can affect top level DNS servers. • Faults were observed in the current infrastructure. • Potential large scale denial of service. • Solution is to make these routes less dynamic • Relies on unique properties of top level servers. • Lose some robustness to failure • Gain protection against invalid routes. NANOG 25 - Toronto

  17. Discussion • Merit of the problem • Lots of concern over “securing” BGP and DNS • Routes to DNS servers are interesting special case • Do less dynamic routes make sense? • Only applies to this unique scenario • Our data shows trade-off is effective • very interested in access to data for counter example…. NANOG 25 - Toronto

  18. You had to ask…. algorithm detail • Path Usage Uk(p) = Tk(p)/T where T = time period, Tk(p) = time path advertised • Adjust filter at end of time period T • Smooth with exponentially moving weighted average U(p) = (1-a)*U(p) + a*Uk(p) • Allowable routes have Uk(p) > Umin or U(p) > Umin • Validate all new routes and check old routes with Pv • Allow interim addition during T if Tk(p) > Tr • Parameters used in this presentation:T=1 week, Tr=1 hour, Umin=10%, a=0.25, Pv=0.1 NANOG 25 - Toronto

More Related