rover: a dns-based method to detect and prevent ip hijacksgersch/cs457/rover.pdf · ip hijacking...

ROVER: A DNS-Based method to Detect and Prevent IP Hijacks

Joseph GerschCSU Department of Computer Science

PhD Final ExamThursday, September 26, 2013

1

Friday, September 27, 13

Agenda• Introduction:

• Problem Statement: IP Hijacking

• minimal discussion of background and prior work

• Thesis Statement

• Invention: ROVER

• Research Results

• Global Internet Simulation & Inherent Metrics

• Analysis of IP Hijack Propagation

• Analysis of Incremental Defense Deployment

• Pragmatic Self-Interest Protections

• ROVER Reliability, Resilience, and Scalability

• Publications & Contributions

• Conclusion & Future Directions2


What is IP hijacking? How does it happen?

• BGP (Border Gateway Protocol) communicates routing data among Autonomous System (AS) networks across the world.

• BGP has no security. BGP simply trusts data from its neighbors.

I own 129.82/16

Intro Solution ConclusionResearch

3


What is IP hijacking? How does it happen?

• BGP (Border Gateway Protocol) communicates routing data among Autonomous System (AS) networks across the world.

• BGP has no security. BGP simply trusts data from its neighbors.

I own 129.82/16

I own 129.82/16


3


Hijack Consequences

• Black-hole an address block -- take them off the net• Impersonate• Eavesdrop• Send Spam and avoid detection• Not to mention.... crime and cyber-warfare

Leon Panetta: “A cyber-attack perpetrated by nation states or violent extremist groups could be as destructive as the terrorist attack on 9/11. Such a destructive cyber-terrorist attack could virtually paralyze the nation. They could use these kinds of cyber tools to gain control of critical switches. They could, for example, derail passenger trains or even more dangerous, derail trains loaded with lethal chemicals. They could contaminate the water supply in major cities or shutdown the power grid across large parts of the country. The most destructive scenarios involve cyber actors launching several attacks on our critical infrastructure at one time, in combination with a physical attack on our country. Attackers could also seek to


4


IP Hijacking intentional or mis-configuration

February 2008YouTube goes missing for 2 hours


5


IP Hijacking intentional or mis-configuration

Black Holes R Us

IP hijack meant to censor YouTube in Pakistan leaked from router to router across the entire world


5


RELATED WORK

• Much research into DETECTION, REACTIVE MITIGATION, & PROACTIVE PREVENTION techniques

• Detection is non-trivial; many attacks go undetected

• Reactive & Proactive Prevention Methods proposed to date are difficult to deploy and are not cost-effective


6


Scoresheet: Factors affecting Solution Deployment


Butler et al: “we...explain why no solution has yet struck an adequate balance between comprehensive security and deployment cost.”

7


Lots of proposals...But has it REALLY been solved?

• It’s been 16 years and there is no deployed solution....

• Current solutions are either too complex and costly to deploy, or are insufficient in what they solve --- Hobson’s Choice

• IT Risk Assessment Formula:• probability * impact > cost

• probability is low• Most ISP impact is low• But some are EXTREMELY

high

• Most ISP’s have “low/low”• But some have REALLY HIGH

impact!

• Will the reluctant or complacent many block a deployment needed by the few, especially if is too costly?


8


Thesis StatementIntro Solution ConclusionResearch

"A system based on the existing DNS infrastructure can be deployed by a small number of institutions in an incremental fashion and still effectively thwart origin and sub-prefix IP hijacking despite non-participation by the majority of Autonomous System owners.”

9


Solution Proposal

“ROVER”

Cost-effective Route Origin Verification using the pre-existing DNSSEC infrastructure

Securely Publish, authoritatively Verify


10


ROVER Architecture

11


Converting a CIDR address to a DNS Domain Name

12


Example zone fileIntro Solution ConclusionResearch

13


ROVER Verification of a BGP Announcement

• Upon receiving a BGP announcement and performing a DNS lookup based on the IP prefix:

• origin MATCH with DNS ==> VALID

• origin MISMATCH with DNS ==> BOGUS (origin hijack)

• no data found, RLOCK exists ==> BOGUS (sub-prefix hijack)

• no data found, no RLOCK ==> ALLOW (same as today, not authenticated)


14


Rover ExampleHijack Detection

• proof-of-concept testbed has been online over a year

• LEVEL3 experiment: “catch me if you can”

• detected hijack within 30 seconds of launch and detected it in multiple vantage points across the world!


15


Research Results

16


Research ResultsDoes it work? How well does it work?

What are its issues and limits?

• Global Internet Characteristics & Measurements

• Characterize Attack Propagation to Establish a Behavioral Baseline

• Analyze Defensive Methods:

• Incremental Filter Deployment

• Incremental Detector Deployment

• Pragmatic Self-Interest Actions

• Analyze Rover Resilience, Robustness & Scalability


17


Research Results

Global Internet Characteristics and Measurements

18


Simulation ProgramModeling the global internet


Sanity Checks:

compare to RIBs, TRACEROUTE, Looking-glass ROUTERs

compare known attacks

Cannot be identical to real net, but must be reasonable for evaluating results

19


Simulation Accuracy

20


Base MetricsIntro Solution ConclusionResearch

21


“Depth” Distribution

Tier-1 centric topology

Depth = number of hops to the nearest tier-1 AS

22


Research Results

Characterizing Attack Propagation and AS Vulnerability

23


Polar Graph Evolution (modified from prelim exam)

radius = degree radius = depth


24


Attack VarianceIntro Solution ConclusionResearch

Moratel vs Google ISI vs Harvest Electronics NZ25


Effect of Depth on Attack Propagation


26


Vulnerability AnalysisAll 42k ASes attack specific target


27


Re-defining “depth”distance from tier-1 or Tier-2 backbone network

Tier-1 Vulnerability Tier-2 Vulnerabilityvery similar behavior

28


But hey, don’t the Transit ASes try to filter their customers?

29


Impact of private peering and internet exchanges

• Private Peering: helps keep paths to the private peer intact, but makes attack to peer stronger (so filtering would be required)

• IX = many to many peering; the same observations apply

30


Research Results

Analysis of incremental Filter Deployment(Rover, RPKI or any other method)

31


Defensive Filtering for a Relatively Attack-Resistant AS


32


Comparison of filter Deployments: how many & Where?

Relatively Resistant Target Relatively Vulnerable TargetAverage # polluted ASes in successful attack

•Tier-1: 5,084•degree >= 500: 1,076•degree >= 300: 378•degree >= 200: 228•degree >= 100: 66

Average # polluted ASes in successful attack•Tier-1: 22,018•degree >= 500: 8,562•degree >= 300: 2,716•degree >= 200: 1,576•degree >= 100: 163


33


Even after Filtering, some attacks are still aggressive

• When AS 11537 attacks AS 98:

• no filters: 11,650 ASes become polluted• with filters at degree >= 100: 1025 ASes become

polluted (better, but still a lot)• analysis of polar graph can help determine where

additional filters could be placed

Top 5 attackers for AS98, after filtering at AS degree >= 100


34


Research Results

Analysis of Incremental Detection Deployment

35


IP Hijack Detection• 8000 random attacks

• Compare 3 Deployment Strategies:

• Tier-1: • 34% undetected

• average pollution = 2,344• median pollution = 1806• max pollution = 20,306

• BGPMON: • 11% undetected

• average pollution = 1,521• median pollution = 673• max pollution = 12,542

• 62 detectors at ASes with degree>500:

• 3% undetected• average pollution = 202• median pollution = 125• max pollution = 2804


36


Research Results

Pragmatic self-interest

37


while the world stands and watches....

I’ll do it by myself

• If inaction by others, what can an AS do on its own?• analyze relevant AS topology• reduce vulnerability• publish route origins and recruit others to publish (look for

dependencies)• incorporate filters based on published data• use detection

186 NZ ASes


38


ROVER Reliability, Resilience, and

Scalability

Threat Models and Failure Modes

Operational Considerations

Global DNS Capacity and Load

Resolving the Perceived Circular dependency between BGP and DNS

39


Threat Models and Failure modes

• Vulnerabilities• BGP

communication• DNS

communication• subscriber

communication• System

Redundancy and Fail-over


Attackers exploit vulnerabilities to mask attacks, prevent alarms, or trigger false alarms

40


An improved SystemIntro Solution ConclusionResearch

Internal ROVER DBExponential DNS Re-TrySubscriber Keep-Alives

41


Operational Considerations

• Operators will make mistakes; need to allow experimental publishing to verify correctness

• Transferring a prefix to another AS• IPv6: a /48 covering to a /64 requires 65k

zone cuts

• Solution: modify RLOCK and SRO records for activation time, flag, and prefix-limit fields


42


Conclusion

Contributions, Future Directions,Publications & Conference Presentations

43


Contributions

• Developed Solution Taxonomy for IP Hijacks• ROVER design: Resource Records, Reverse-DNS Domain

Naming Convention and Validation Algorithm• Web-based ROVER testbed• Global Internet Simulation Program, underlying database and

graphics output• Research on Internet Measurements, Vulnerability Analysis,

Incremental Filter Deployment, Incremental Detection Deployment;

• introduced depth and reach metrics.• Analysis of Robustness, Resilience and Scalability leading to

required design improvements

44


Future Directions

• Determine methods to communicate directly with routers for real-time hijack filtering

• Analysis of attacks that still get by critical mass filters (improve from 90% -> 99%)

• More research on pragmatic self-interest; processes, tools and methods

• Get ROVER deployed and accepted45


Publications & Presentations

• “Reverse-DNS Naming Convention for CIDR address blocks”, in Securing and Trusting Internet Names, SATIN2012 • “Reverse-DNS Naming Convention for CIDR address blocks”, IETF draft• “DNS Resource Records for BGP Routing Data”, IETF draft• Secure64 ROVER web site and testbed• “BGP Route Origin Verification Using Reverse DNS” and similar presentations at

• RIPE64• NANOG55• AUSNOG ’12• TIP2013

• “ROVER: Route Origin Verification Using DNS”, ICCCN 2013• “Characterizing Vulnerability to IP Hijack Attempts”, IEEE-HST 2013• “Effective Incremental Deployment of BGP Security”, submitted to IEEE INFOCOM 2014

• Also:• presented to ISOC Outreach Committee, • Presented to US FCC, FCC CSRIC committees• Presentations by CenturyLink to US Government Departments• Publishing of ROVER data by significant organizations: AT&T, HP, CenturyLink, Level3, Internet2 members


46


Final SummaryIntro Solution ConclusionResearch

"A system based on the existing DNS infrastructure can be deployed by a small number of institutions in an incremental fashion and still effectively thwart origin and sub-prefix IP hijacking despite non-participation by the majority of Autonomous System owners.”

47


Questions?

48


rover: a dns-based method to detect and prevent ip hijacksgersch/cs457/rover.pdf · ip hijacking...

Documents