Title: Advanced Computer Networks
1Advanced Computer Networks
- Routing and DNS Security
- Lan Wang
- lanwang_at_memphis.edu
- http//www.cs.memphis.edu/lanwang
Based in part upon the slides of Dan Massey
(CSUI).
2Protecting Routing To Top Level DNS Servers
Wang04
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
nanog
cairn
bogus
ietf
isi
ops
3Example DNS Routing Problem
- Invalid BGP routes exist in everyones 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
4A 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
5Why 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. - DNS name resolvers detect and time-out
unreachable servers. - Provided surviving servers handle load, cost is
some delay. - Expect predictable properties and stable routes.
- Servers dont change without non-trivial effort.
- Servers located in highly available locations.
6Why 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.
- Feb. 24, 2001 - Feb. 24, 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 dont reflect
ISP ops.
7How Static Are The Routes?
ISP1
ISP2
- (a) ISP1 3 major 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,) -gt (,10913, )
8Example of Filtered Routes
1239
10913
server
19836
701
No route at 160830
With filter no route at 160632
9Simple Filter - Impact on Reachability
ISP1 (US/Tier 1)
10Simple Filter - Worst Case In Study
ISP 3 (Europe)
ISP 3 used one main route and a smallnumber of
consistent back-up routes.
11Toward 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.
- ISP3s reachability can be improved if
filterallows two routes - Strike a balance between allowing dynamic changes
and restricting to trusted paths.
12Our Adaptive Filter
- Apply heuristics before accepting new paths
- Add options for validating new paths
- Believe route based purely on heuristics
- Probabilistic query/response testing against
known data. - Trigger off-line checking (did origin AS really
change?)
Slow down the route dynamics and add validation.
13Algorithm 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) aUk(p) - Allowable routes have Uk(p) gt Umin or U(p) gt
Umin - Validate all new routes and check old routes with
Pv - Allow interim addition during T if Tk(p) gt Tr
- Parameters used in this presentationT1 week,
Tr1 hour, Umin10, a0.25, Pv0.1
14Impacts on Reachability (Adaptive Filter)
ISP1
Root servers
15Impacts on Reachability (Adaptive Filter)
ISP3
Root servers
16Conclusions
- 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.
17Discussion
- 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.
18Assignments
- Project progress report, due midnight Mar. 10
- Midterm, Mar. 15
- Guest lecture on Wireless Network Research, Mar.
17 - In-class presentation (Mar. 22 and Mar. 24)
- R. Mahajan, D. Wetherall and T. Anderson,
Understanding BGP Misconfiguration - G. Goodell, W. Aiello, T. G. Griffin, J.
Ioannidis, P. McDaniel and A. Rubin, Working
Around BGP An Incremental Approach to Improving
Security and Accuracy of Interdomain Routing - L. Subramanian, V. Roth, I. Stoica, S. Shenker
and R. H. Katz, Listen and Whisper Security
Mechanisms for BGP - S. Kent, C. Lynn and K. Seo, Secure Border
Gateway Protocol - Kent, C. Lynn, J. Mikkelson and K. Seo, Secure
Border Gateway Protocol (S-BGP) -- Real World
Performance and Deployment Issues