Michael Schapira*
*School of Computer Science and Engineering, Hebrew U
*Hebrew U’s Cybersecurity Research Center*Fraunhofer Project Center for Cybersecurity @
Hebrew U
(How) Can WeSecure Internet Routing?
2
• The Internet infrastructure is alarmingly insecure
• Designed without security in mind
• Security not even on the horizon (yet!)
3 stories, 1 theme
3
• Naming/addressing with the Domain Name System (DNS)– DNS = the Internet’s phone book– google.com = ?
• Routing with the Border Gateway Protocol (BGP)– BGP = the Internet’s google maps / Waze
• The Network Time Protocol (NTP)– NTP = the Internet’s global clock
3 stories, 1 theme
• The Internet is becoming ever-more important
• Yet, today’s Internet is surprisingly fragile– suboptimal, insecure, unpredictable, …
• And new challenges just keep piling up…
The Internet Only Just Works
Applications:
Internet infrastructure:
routing, congestion control, naming, …
(TCP/IP, BGP, DNS, OSPF, ECMP,…)
Technologies:
constant innovation
stagnant!
constant innovation
Why Only Just Works?
6
• Replace the Internet!– Throw cryptography at the problem– Top-down approach– BGPSEC, DNSSEC, …
• Security not even on the horizon because of– meager benefits in partial adoption– costly changes to network (e.g., new hardware)– much room for human error– …
Today’s Approach toSecuring the Internet
7
“The Bureau … is charged with improving the defense of national infrastructures critical to the continuation of normal life in the State of Israel and to protect them … from cyber attack” (INCB website)
“Douglas Maughan, cybersecurity research program manager for the DHS’s Science and Technology Directorate ... had little luck convincing ISPs and router vendors to take steps to secure BGP.” (“The Internet’s Biggest Security Hole”, WIRED 2008)
Can Israel be Secure?
8
• Unique opportunity– focus on nation-state security (INCB, BSI)– strong foundations (research, gov’t)
• But… a paradigm shift is needed
Yes We Can
9
3 (Sub-)ProjectsHermes
Securing Internet Routing with BGPDionysus
Securing Naming/Addressing with DNS
ChronosSecuring Network Time with NTP
10
• Internet routing as an example
• A very appropriate example…
This Talk
11
• Part I: Internet routing with BGP• Part II: BGP (in)security• Part III: Today’s approach is
failing• Part IV: How can BGP be made
secure?
(if time permits, I’ll also talk about anonymity on the Internet)
This Talk
• New approaches, new models (security measures, economic incentives, …)– empirical validation– see survey of 100 network operators
in [Gill-S-Goldberg, CCR 2012]
• Theoretical impossibility results…– even for simple models…
• Extensive experimental analysis– custom algorithms: optimized, parallelized– multiple sensitivity and robustness tests– see report on new algorithms and experimental framework in
[Gill-S-Goldberg, CCR 2012]
Tackling These Questions
13
Disclaimer
The views and opinions expressed in this presentation are those of the
presenter and do not necessarily reflect the official views or position
of the Hebrew University or any agency of the Israeli government.
Part I: Internet Routing with BGP
14
The Internet Ecosystem
Verizon
Comcast
AT&T
Over 50,000 Autonomous Systems (ASes)
Range from small businesses and schools (e.g., HUJI) to large,
multinational, corporations (e.g., Google, Microsoft)
Inter-Net:A Network of Networks
AS-level topology– Nodes are Autonomous Systems (ASes)– Edges are links and business relationships
1
2
34
5
67
Client Web server
Autonomous Systems
• ASes sign bilateral long-term contracts.– How much traffic to carry – Which destinations to reach – How much money to pay
• Neighboring pairs of ASes typically have:– a customer-provider relationship, or– a peering relationship.
peer provider
customerpeer
The Commercial Internet
• More types of business relationships…
• Content providers (e.g., Google) can have their own backbone network
• Content Delivery Networks (CDNs)…
• Internet exchange points (IXPs)…
Real Life is More Complex…
Verizon
Comcast
AT&T
• Interdomain: Between ASes– across different entities
• Intradomain: Within a single AS– all network devices belong to the same entity
Intradomain vs. Interdomain
Verizon
Comcast
AT&T
• Interdomain routing establishes routes between ASes
• Currently handled by the Border Gateway Protocol (BGP)
Interdomain Routing with BGP
BGP ≠ Shortest-Path Routing!
Verizon
Comcast
AT&T
I want to avoid routes through Comcast if
possible I won’t carry traffic between
AT&T and Verizon
I want a cheap route I want
short routes
BGP is Crucial!
• The glue that holds the Internet together
• A few anecdotes:– Almost 50% of VoIP disruptions are BGP-related!– Every year or so a serious BGP-related Internet
outage makes the news!– BGP is notoriously vulnerable to attacks…
AS 2
AS 4
AS 1 AS 3
AS 5
AS 1, IP addresses X
AS 1, IP addresses X
AS 4, AS 3, AS 1, IP addresses X
AS 2, AS 1, IP addresses X
IP Prefix
• The destination announces itself to its neighbors• Routes to the destination are built hop-by-hop as
reachability information propagates through the network• Route selection based on local routing policies
?
BGP Routing Overview
AS 3, AS 1, IP addresses X
$
Verizon
43284
UPC Init 7 AGZurich
20984 $
$
$ $
IP Prefix
customer
peer peer
provider
Routing Model (Gao-Rexford)
Verizon
43284
UPC Init 7 AGZurich
20984
UPC, Prefix UPC, Prefix
Init 7, UPC, Prefix
43284, Init 7, UPC, Prefix
Verizon, UPC, Prefix
IP Prefix
$ $
1) Prefer revenue generating routes2) Prefer shorter routes
Routing Model (Gao-Rexford)
Verizon
43284
UPC Init 7 AGZurich
20984
20984,Verizon, UPC, Prefix
IP Prefix
$ $
XLosing $$
UPC, Prefix UPC, Prefix
Init 7, UPC, Prefix
43284, Init 7, UPC, Prefix
Verizon, UPC, Prefix
1) Prefer revenue generating routes2) Prefer shorter routes3) Do not carry transit traffic for free
Routing Model (Gao-Rexford)
• Thm [Gao-Rexford]: In the Gao-
Rexford model, BGP dynamics are guaranteed to converge to a unique stable routing configuration.
BGP Routing Outcomes
Part II: BGP (In)Security
AS 2
AS 1
I’m YouTube
No, I’m YouTube!
30
Repeated attacks against major financial institutions and governments in Europe and
the US
An Anecdote
31
Rare Incident? Not Really!
• To disconnect victim from the Internet (large corporation, nation state, …)
• To be a man-in-the-middle(snoop on traffic, tamper with traffic, …)
• To impersonate the victim• To hide under someone else’s identity• To attack protocols/mechanisms that
utilize Internet routing (BitCoin, DNS, …)
• …
Why Do this?
Another AnecdoteFebruary 2008: Pakistan Telecom hijacks YouTube!
YouTubePakistan Telecom
The Internet
I’m YouTube:IP addresses: ****
What should have happened…
YouTubePakistan Telecom
Xdrop packets
I’m YouTube:IP addresses: ****
Another Anecdote
What did happen…
YouTubePakistan TelecomPakistanTelecom
No, I’m YouTube!IP addresses: ****
I’m YouTube:IP addresses: ****
Another Anecdote
The InternetAS 1 AS 666
My IP addresses are ***
No, my IP addresses are ***!
Attack: Hijacking IP Addresses
The InternetAS 1 AS 666
Attack: Manipulating the BGP Path
AS 1 is my neighbor
My IP addresses are ***
• The attacker needs– a router with a BGP session to an AS–… configured to originate the prefix
• This could happen because– a network operator makes configuration
mistake– an insider launches an attack– an outsider breaks into the router–… or a black market of BGP routers…
Who Can Launch Such an Attack?
Naïve attack: Announce the shortest path I can to all
neighbors
a
$m
Is the Naïve Attack Optimal?Can’t lie about my business
relationship with a, so I might as well announce the shortest path I can.
Naïve attack: Announce the shortest path I can to all
neighbors
a
$m
Sometimes longer paths
are better!
Thm: It is NP hard to find (or even well approximate) the optimal attack. So, our results underestimate damage.
Sometimes not announcing is
better!
Is the Naïve Attack Optimal?Can’t lie about my business
relationship with a, so I might as well announce the shortest path I can.
• The victim AS doesn’t necessarily see the problem
• May not cause loss of connectivity– e.g., if the bogus AS snoops and redirects
• Even if detected, how can such attacks be stopped?– a polite phone call?– the “wall metaphor” is not appropriate here
• How can this be rectified?
Attacks on BGP are Hard toDetect/Prevent
AS 1
AS 3
v AS 2
m
IP
v, Prefix v, Prefix
m
IP Prefix
v
m, Prefixm, Prefix
A secure database maps IP prefixes to owner ASes
Proposed Solution: The Resource Public Key
Infrastructure (RPKI)
AS 1
AS 3
v AS 2
m
IP
v, Prefix v, Prefix
m
IP Prefix
v
m, v, Prefixm, v, Prefix
Does RPKI Solve the Problem?
Public Key Signature: Anyone who knows v’s public key can verify that the message was sent by
v.
a1
a2
v a3
m
IP Prefix
a1: (v, IP addresses X)
a1: (v, IP addresses X)
m: (a1, v, IP addresses X)
BGPSEC to the Rescue!
Part III:Why Today’s Approach is Failing
• Goldberg-S-Hummon-Rexford, SIGCOMM 2010• Gill-S-Goldberg, CCR 2012• Lychev-S-Goldberg, SIGCOMM 2013• Gilad-Cohen-Herzberg-Schapira-Shulman, NDSS 2017
• Step 1: Create a secure DB (<6%)– RPKI: Organizations -> Internet addresses
• Step 2: Replace BGP (0%)– BGPsec
BGP Security is a Distant Dream
• RPKI: Resource Public Key Infrastructure• Intuition: a secure “phone book”• Maps IP addresses to ASes that own them.
(AS number, IP addresses)
RPKI Revisited
• RPKI: Resource Public Key Infrastructure• Intuition: a secure “phone book”• Maps IP prefixes to ASes that own them.• Very low adoption
RPKI Revisited
Discarding Bogus Routes with RPKI
AS 1
v, IP addresses: ****
m
IP addresses
v
m, IP addresses: ****
According to RPKI, m’s a
liar!
Our answers rely on a combination of
1. a survey network practitioners
2. extensive empirical analyses
50
Why is RPKI adoption so slow?
• Hypothesis I: technical and logistic barriers (e.g., inter-organizational dependencies)
• Hypothesis II: Insufficient value
51
Nope, most of the Internet could adopt tomorrow!(check out roalert.org! [Yossi Gilad, Daniel Davidovich])
Indeed. The chicken and egg problem…
(Almost) no one bothersto register its addresses into
RPKI(< 6%)
(Almost) no one usesRPKI to filter “bad” routes
(?)
Why is RPKI adoption so slow?
Route-Origin Validation (ROV): use the RPKI to discard route-advertisements from
unauthorized ASes
BGP Routers
RPKI cache
RPKI
Autonomous System
52
But how can we tell whether an AS employs RPKI-based filtering?
We gain empirical insights regarding ROV enforcement via RPKI-invalid BGP advertisements
We monitored BGP paths from multiple vantage points afforded by 44 Route Views sensors²
² http://www.routeviews.org/ 53
ROV Adoption Measurements
Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements do not perform filtering
*This presentation provides examples based on empirical data.
54
42926
1299
RVsenso
r
RVsenso
r
IP addresses Y
9121
1239 4637
15003 6416IP addresses
X AS 15003 and AS 42926 advertise in BGP the RPKI-invalid IP addresses X and Y
6939
Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements do not perform filtering
55
15003IP addresses
X
42926
1299
RVsenso
r
RVsenso
r
IP addresses Y
Route Views sensor observes “bad” route to XAS path: 4637, 6416, 15003
9121
6939
1239 4637
6416
Route Views sensor observes “bad” route to YAS path: 6939, 1299, 9121, 42926
Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements do not perform filtering
56
15003IP addresses
X
42926
1299
RVsenso
r
RVsenso
r
IP addresses Y
9121
6939
1239 4637
6416
ASes that don’t filter invalid advertisements colored red
Measurements: Filtering ASesSeek ASes that advertise both “good” & “invalid” routes.Conclude that an AS performs ROV if it discards “bad” advertisements, but relays “good” ones, from 3 origins
42926
1299
RVsenso
r
RVsenso
r
IP addresses Y
9121
6939
1239
IP addresses Y
AS 42926 announces another BGP advertisement forprefix Y
4637
57
15003IP addresses
X
6416
15003 6416
Measurements: Filtering ASes
42926
1299
RVsenso
r
RVsenso
r
IP addresses Y
Route Views sensor observes ``good’’ route to: YAS path: 4637, 1239, 9121, 42926
9121
6939
1239 4637
IP addresses Y
AS 42926 announces another BGP advertisement forprefix Y
58
IP addresses X
Seek ASes that advertise both “good” & “invalid” routes.Conclude that an AS performs ROV if it discards “bad” advertisements, but relays “good” ones, from 3 origins
15003 6416
Measurements: Filtering ASes
42926
1299
RVsens
or
RVsens
or
185.70.84.0/24
9121
6939
1239 4637
79.98.130.0/24
Conclude: AS 1239 receives adv. from AS 42926, but did not relay the invalid one(only non-red AS on legitimate adv. path)
42926
1299
RVsenso
r
RVsenso
r
9121
6939
1239 4637
59
Seek ASes that advertise both “good” & “invalid” routes.Conclude that an AS performs ROV if it discards “bad” advertisements, but relays “good” ones, from 3 origins
Measurements: ResultsOur measurement techniques provide a view of ROV enforcement amongst the ASes at the core of the Internet
– since ASes at the core are likely to be on the paths covered by the Rout Views sensors At least 80 of top 100
ISPs do not perform ROV
60
Survey ResultsAn anonymized survey of over 100 network operators and security practitioners• advertised in different mailing lists, including ‘closed’ lists• 80% of respondents are network operators/managers and most of the
others are security/networking consultants
Do you apply RPKI-based route-origin
validation?
61
• ~30% of information in RPKI is “incorrect” as a result of human error…
• RPKI-based filtering disconnects legitimate destinations! the very same “attack” RPKI aims to
prevent
• RPKI does not even always protect those in the system
Also, (Justified) Mistrust in RPKI!
Obstacles to Deployment:Human Error
Concern about mistakes in the RPKI also reflected in our survey results:
What are your main concerns regarding executing RPKI-based origin authentication in your network?
63
• We ran simulations to quantify security:– empirically-derived AS-level network from CAIDA
• Including inferred peering links [Giotsas et al., SIGCOMM’13]
– using the simulation framework in [Gill et al., CCR’12]
• We measured the attacker success rate– in terms of #ASes attracted – for different attack scenarios– for different ROV deployment scenarios– averaged over 1M randomly chosen attacker/victim pairs
64
Quantify Security in Partial Adoption
Quantify Security in Partial Adoption
Adoption by the top 100 ISPs makes a huge difference!
• Comparison between two scenarios:– today’s status, as reflected by our
measurements – all top 100 ISPs perform ROV
• Each other AS does ROV with fixed probability
65
Bottom line:
ROV enforcement by the top ISPs is both necessary and sufficient for substantial
security benefits from RPKI
66
Quantify Security in Partial Adoption
67
BGP RPKI (origin
authentication)
BGPSEC
S
4323,2828, FB, prefix
S
2828, FB, prefix
S
SP, 4323, 2828, FB, prefix
• In deployment• Crypto done offline
• In standardization• Crypto done online
What does (partially-deployed) BGPSEC offer over RPKI?(Or, is the juice worth the squeeze?)
Secu
rity
Ben
efits
(Ju
ice)
BGP and BGPSECcoexistence
Road to BGPSEC full-deployment is very tricky because introducing
security only partially introduces new vulnerabilities Not fully deployed BGPSEC provides only meagre benefits
over RPKI
Landscape of BGP Defenses
A
Sprint
2828
4323
DSiemens
IP addresses X
P/S
P/S
P/S
P/S
Should Sprint choose the long secure path ORthe short insecure one?
P/S
P/S
?Secure ASes must accept
legacy insecure routes
Depends on the interaction between BGPSEC and routing policies!
RPKI
A, DIP addresses X
What Happens in Partial BGPSEC Deployment?
S
4323,2828, D,
prefix
S
2828, D, prefix
S
SP, 4323, 2828, D, prefix
A
Sprint
2828
4323
DSiemens
69.63.176.0/24
P/S
P/S
P/S
P/S
Should Sprint choose the long secure path ORthe short insecure one?
Secure ASes must accept
legacy insecure routes
A, DIP addresses X
Before attack, Sprint has a legitimate secure routeDuring attack, Sprint downgrades to a bogus route
What Happens in Partial BGPSEC Deployment?
• BGPSEC in partial deployment introduces new vulnerabilities1. “protocol downgrade attacks”2. security not monotone!3. instabilities
• BGPSEC provides meagre benefits over RPKI even if over 50% of ASes adopt!– using our security measure
Is the Juice Worth the Squeeze?
Part IV:How Can We Secure BGP Routing
• Cohen-Gilad-Herzberg-Schapira, HotNets 2015• Cohen-Gilad-Herzberg-Schapira, SIGCOMM 2016• Cohen-Gilad-Herzberg-Schapira-Shulman, upcoming
Hermes:Securing Internet Routing (BGP)
Constraints on design space:• Easily deployable– No changes to routers– Software only
• Fully automated– No human errors
• Significant benefits in partial deployment
Wanted:A New Paradigm for BGP
Security
Hermes Components
• Automating RPKI certification with DISCO
• Path-end validationd
d IP addresses
certified
DISCO: IntuitionOrganization
alNetwork
AgentRouter
RegistrarC1C2
I own Internet (IP) addresses X
Prove it!
DISCO: Intuition
Organizational
Network
Organizational
Network
AgentRouter
AgentRouter
Registrar
Securing routing via insecure routing?
DISCO Certification Success Rate
r PO Days till Certification
PA 1000s Years till Certification
3 0.3 16.46 10-4 0.13
5 0.26 19.19 2.1*10-6 6.66
7 0.23 22.02 4.2*10-8 323
9 0.2 25.01 9*10-10 15,243
11 0.18 28.22 1.9*10-11 706,182
13 0.16 31.68 4.2*10-13 32,300,076
15 0.14 35.41 9.3*10-15 1,468,884,419
Path-End Validation
• An easily deployable alternative to BGPSEC
• Significant benefits in partial deployment
Path-End Validation• RPKI provides origin authentication• Path-end validation also authenticates the “last hop”
A radical departure from BGPSEC
dv
a
RPKI
Did d approve reaching it via
v?BGPSEC Design Choices and Summary of Supporting Discussions
draft-sriram-bgpsec-design-choices-08
AS 11.2.3.0/24
Router
AS 24.5.6.0/24
Router
The Internet
RPKI Repository
AS 10
AS 20
Path-End Validation
AS 11.2.3.0/24
Router
AS 2
Router
The Internet
RPKI Repository
AS 10
AS 20
1020
Path-End Validation
AS 11.2.3.0/24
Router
AS 2
Router
The Internet
RPKI Repository
AS 10
AS 20Path-end Records
ip as-path access-list as1 deny _[^(10|20)]_1_ip as-path access-list allow-all permit
Path-End Validation
Router Configuration
• Compatible with today’s routers• Only one rule per-AS
– An order of magnitude less rules than origin authentication with RPKI
The implementation can be found at: https://github.com/routingsec/pathend
AS 2
Router
ip as-path access-list as1 deny _[^(10|20)]_1_ip as-path access-list allow-all permit
Adopter
Legacy
Provider
Customer
Legend
• AS 666 wants to attract AS 3’s traffic to IP prefix 1.2.3.0/24, but…– It can’t lie about business relationship– It can’t announce that it owns the prefix or is
AS 1’s neighbor– It has to launch 2-hop attack: (666,2,1,prefix)
AS 3
Attacker,
AS 666
Victim, AS 1
1.2.3.0/24AS 2
4
4.5
3.5
MANY CLIENTS ARE JUST 1 AS-
HOP AWAY FROM CONTENT
Intuition for Path-End Validation
• Path-end validation is not restricted BGPSEC!– Offline vs. online– Keep message format and use today’s routers
• Important implications for security– AS 666 launches a next-AS attack against AS 1• Not prevented by BGPsec• Prevented by path-end validation
AS 3
Attacker,
AS 666
Victim, AS 1
1.2.3.0/24AS 2
Adopter
Legacy
Provider
Customer
Legend
Path-End Validation vs. BGPSEC
Simulation Framework• Empirically-derived AS-level network from CAIDA – Including inferred peering links
[Giotsas et al., SIGCOMM’13]
• Evaluate fraction of ASes an attacker can attract– Under different adoption scenarios– Under different attacks
• Using the simulation framework in [Gill et al., CCR’12]
Simulation Results
Simulation Results
Simulation Results
Benefits from Local Deployment
Impact of k-Hop Attacks
BGP(no authentication)
Origin authentication (RPKI)Path-end validation
2-hop validation
Additional Results• Large content providers are better
protected
• Path-end validation mitigates high profile incidents
• Security monotone– BGPsec is not [Lychev et al.,
SIGCOMM’13]
Summary• Today’s agenda for securing BGP routing
faces significant hurdles
• A new paradigm for securing Internet routing– Readily deployable– Effective under very partial deployment
Thanks!
Measuring and Mitigating AS-level Adversaries Against Tor
Rishab Nithyanand, Oleksii Starov, Adva Zair, Michael Schapira, and Phillipa Gill, NDSS 2016
95Source AS Destination AS
Anonymity on the Internet• Challenge: By observing Internet traffic
one can infer who is talking to whom– Meta data is the message!– Track communications over time…
• …behaviors, interests, activities• Tor aims to solve this
TorEntry Exit
Middle
Tor circuit is constructed out of three Tor routers/relays
Does not know source
Does not know destinationWhich user is visiting the site?
Internet routing dynamics make timing attacks easier than you’d
think!
Timing Attacks & Routing
97Source AS
AS1
AS2
AS3 AS4
AS5
Entry relay Exit relay
Destination AS
AS2
98
Method:• Use VPN to connect to 200 sites (100 popular, 100 likely censored)
through Tor• Examine AS-level paths between source and destination and chosen
entry/exit relays.
53% of sites have at least some content delivered over a vulnerable Tor circuit
How often does Tor pick a vulnerable path?
Solution: Astoria• Choose an entry/exit relay to avoid attackers
– Usually there is such an option• Otherwise, use a linear program to minimize damage
– Choose probabilistically to minimize the amount of data observed by an adversary over time
Additional considerations:• Path computations need to be done on the client• ASes may collude (e.g., sibling ASes, state-level actors)• Minimize performance impact
– Cannot pre-construct circuits as in vanilla Tor • Being a good network citizen: don’t overload popular
relays
99
100
Fraction of sites with content delivered over vulnerable circuits decreases from 53% to 8% with Astoria
Astoria: Results
101
What’s next?• Interview with cryptographer Tibor
Jager on TLS, attacks, and countermeasures
• An Interview with That One Privacy Guy- The Man Behind That One Privacy Site
• Interview with Researcher Thyla Van Der Merwe on TLS and Online Privacy