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

2. NANOG 25 - Toronto26/11/2002 Routing To Top Level Servers n Critical points of failure near root. –13 root and 13 gTLD servers –25 BGP routes (2 share a prefix) n Fault/attack near root could have disproportionately large impact. –13 bogus routes to deny service. –1 bogus route to provide bogus DNS. n Scale helps contain risk in lower tree. –Many millions of DNS servers. Root netorgcom nanogcairnbogusietf isi ops

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

4. NANOG 25 - Toronto46/11/2002 A Simple Filter n Current BGP provides dynamic routes –Explore the opposite extreme... n Select a single static route to each server. –Apply AS path filters to block all other announcements. Also filter against more specifics. n 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

5. NANOG 25 - Toronto56/11/2002 Why This Works: Theory n Scale is limited to a small number of routes. –No exponential growth in top level DNS servers. n 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. n Expect predictable properties and stable routes. –Servers don’t change without non-trivial effort. –Servers located in highly available locations.

6. NANOG 25 - Toronto66/11/2002 Why This Works: Data n 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 n 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.

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

8. NANOG 25 - Toronto86/11/2002 How Static Are The Routes? n 3 changes in route to “A” over 14 months. n 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 n 1 change in transit AS routing policy –11/8/01 (*,10913, 10913, 10913,*) -> (*,10913, *) –Could have built filter to allow this...

9. NANOG 25 - Toronto96/11/2002 What Routes Are Lost? n Results from 3/1/01 until 5/19/01 AS change. –Reduced reachability to “A” from 99.997% to 99.904% n 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 n Similar results for other time periods and servers.

10. NANOG 25 - Toronto106/11/2002 Example of Filtered Routes n With filter no route at 16:06:32 19836 10913 1239 701 * server No route at 16:08:30

11. NANOG 25 - Toronto116/11/2002 Simple Filter - Worst Case In Study ISP 3 (Europe) ISP 3 used one main route and a small number of consistent back-up routes.

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

13. NANOG 25 - Toronto136/11/2002 Our Adaptive Filter n 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?) n Algorithm details in upcoming paper http://fniisc.nge.isi.edu

14. NANOG 25 - Toronto146/11/2002 Impacts on Reachability (Adaptive Filter) ISP1 Root servers gTLD servers

15. NANOG 25 - Toronto156/11/2002 Impacts on Reachability (Adaptive Filter) ISP3 Root servers gTLD servers

16. NANOG 25 - Toronto166/11/2002 Conclusions n Routing faults can affect top level DNS servers. –Faults were observed in the current infrastructure. –Potential large scale denial of service. n 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.

17. NANOG 25 - Toronto176/11/2002 Discussion n Merit of the problem –Lots of concern over “securing” BGP and DNS –Routes to DNS servers are interesting special case n 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….

18. NANOG 25 - Toronto186/11/2002 You had to ask…. algorithm detail n Path Usage Uk(p) = Tk(p)/T where T = time period, Tk(p) = time path advertised n 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 n Allow interim addition during T if Tk(p) > Tr n Parameters used in this presentation: T=1 week, Tr=1 hour, Umin=10%, a=0.25, Pv=0.1