Robert Lychev Sharon Goldberg Michael Schapira
Georgia Tech
Boston University
Boston University
Hebrew University
1
Security Benefits or Juice
What does (partially-deployed) BGPSEC offer over RPKI?
 road to BGPSEC full-deployment is very tricky because introducing
security only
introduces
new
vulnerabilities
(Or, partially
is the juice
worth the
squeeze?)
 not fully deployed BGPSEC provides only meagre benefits over RPKI
if network operators do not prioritize security in their routing policies
BGP
• In deployment
• Crypto done offline
• In standardization
• Crypto done online
BGP and BGPSEC
coexistence
RPKI
(origin authentication)
BGPSEC
2
1.
Background:
1.
BGP, RPKI, BGPSEC
2.
routing policies in BGPSEC partial deployment
2.
BGPSEC in partial deployment is tricky
3.
Is the juice worth the squeeze?
4.
Summary
3
4323, 2828, D
69.63.176.0/24
Sprint
Sprint, 4323, 2828, D
69.63.176.0/24
4323
2828, D
69.63.176.0/24
2828
A
D
69.63.176.0/24
D
69.63.176.0/24
4
4323, 2828, D
69.63.176.0/24
Sprint
4323
2828
D
?
Which route to choose?
Use routing policies.
e.g. “Prefer short paths”
A, D
69.63.176.0/24
A
69.63.176.0/24
5
4323, 2828, D
69.63.176.0/24
Sprint
4323
2828
D
?
A,AD
69.63.176.0/24
Which route to choose?
Use routing policies.
e.g. “Prefer short paths”
69.63.176.0/24
A
69.63.176.0/24
6
Sprint
RPKI invalid!
4323
X
A
69.63.176.0/24
2828
Sprint checks that
A is not authorized
for 69.63.176.0/24
A
D
RPKI
69.63.176.0/24
69.63.176.0/24
Binds prefixes to ASes authorized to originate them.
7
Security Benefits or Juice
BGP
assume RPKI is fully deployed, and focus on 1-hop hijack.
prevent
prefix
hijacks
RPKI
(origin authentication)
prevent
route
manipulations
BGPSEC
8
P/S
?
S
P/S
2828
Sprint can verify that
D never sent
X
A, D, prefix
SP, A, D, prefix
A, D prefix
S
2828, D, prefix
A
P/S
4323
BGPSEC invalid!
S
P/S
Sprint
RPKI
P/S
D
69.63.176.0/24
9
Security Benefits or Juice
BGP
assume RPKI is fully deployed, and focus on 1-hop hijack.
prevent
route
manipulations
prevent
prefix
hijacks
What happens when BGP and
BGPSEC coexist?
RPKI
(origin authentication)
BGPSEC
10
Secure ASes must
accept legacy
insecure routes
P/S
Sprint
?
Should Sprint choose
the long secure path OR
the short insecure one?
P/S
4323
A, D
69.63.176.0/24
A
P/S
Siemens
P/S
D
RPKI
P/S
P/S
2828
69.63.176.0/24
Depends on the interaction between BGPSEC and routing policies!
11
1.
local preference
(often based on business relationships with neighbors)
2. prefer short routes
…
3. break ties in a consistent manner
12
Security 1st
1.
Cost,
Performance
Security
local preference (cost)
(often based on business relationships with neighbors)
Security 2nd
2. prefer short routes (performance)
Cost,
Performance
Security
Security 3rd
3. break ties in a consistent manner
 Survey of 100 network operators shows that 10%, 20% and 41%
would place security 1st, 2nd, and 3rd, [Gill, Schapira, Goldberg’12]
13
Security 1st
1.
local preference (cost)
(prefer customer routes over peer over provider routes)
Security 2nd
2. prefer short routes (performance)
Security 3rd
3. break ties in a consistent manner
 To simulate routing outcomes, we use a concrete model of local
preference. [Gao-Rexford’00, Huston’99, etc.]
 Our ongoing work tests the robustness of this local pref model.
14
1.
Background: BGP, RPKI, BGPSEC, routing policies
2.
BGPSEC in partial deployment is tricky
1.
Protocol downgrade attacks
2.
Collateral damages
3.
Routing instabilities
3.
Is the Juice worth the squeeze?
4.
Summary
15
P/S
Sprint
?
Security 3rd:
Path length trumps
path security!
P/S
4323
A, D
69.63.176.0/24
P/S
2828
P/S
D
A
69.63.176.0/24
Protocol downgrade attack:
Before the attack, Sprint has a legitimate secure route.
During the attack, Sprint downgrades to an insecure bogus route .
16
No protocol No collateral
No
We prove…
downgrades? damages? instabilities?



Security 1st
Security 2nd
Security 3rd
?
Protocol downgrade attack:
P/S
Sprint
4323
P/S
A, D
69.63.176.0/2
4
A
Siemens
P/S
D
P/S
P/S
2828
A secure AS with a secure route before
the attack, downgrades to an insecure
bogus route during the attack.
69.63.176.0/24
17
20960
3257
52142
12389
5617
174
P/S
3356
P/S
3491
P/S
10310
P/S
40426
P/S
prefix
7922
M
Before X deploys
BGPSEC
?
Y
Z
X
V
?
D
P/S
prefix
P/S
P/S
P/S
Shorter
path!
P/S
X offers the
Secure ASes: 5
shorter path
Happy ASes: 8
W
M
After X deploys
BGPSEC
X
V
D
P/S
prefix
P/S
P/S
P/S
?
Security 2nd:
Secure
ASes:
6
Security
trumps
Happy
path ASes:
length!7
P/S
Z
?
Y
P/S
Y experiences
W offers the
collateral damage
shorter path!
because X is secure!
W
M
No protocol No collateral
No
We prove…
downgrades? damages? instabilities?



Security 1st
Security 2nd
Security 3rd
20960
3257
?
52142
12389
5617
Collateral damage (during the attack):
More secure ASes leads to more insecure
ASes choosing bogus routes
174
P/S
?
P/S
3356



P/S
3491
7922
P/S
40426
A
P/S
P/S
10310
prefix
21
No protocol No collateral
No
We prove…
downgrades? damages? instabilities?
Security 1st
Security 2nd
Security 3rd









Theorem: Routing converges to a unique stable state if all ASes
use the same secure routing policy model.
 But, if they don’t, there can be BGP Wedgies and oscillations.
22
1.
Background: BGP, RPKI, BGPSEC, routing policies
2.
BGPSEC in partial deployment is tricky
3.
Is the Juice worth the Squeeze?
4.
1.
Can we efficiently select the optimal set of secure ASes?
2.
Can we bound security benefits invariant to who is secure?
3.
Is the BGPSEC juice worth the squeeze given RPKI?
Summary
23
Let S be the set of ASes deploying BGPSEC,
A be the attacker and d be the destination
20960
3257
52142
12389
3356
5617
5617
174
?
3491
| Happy(S, A, d)| = 7
10310
7922
prefix
A
d
The set of ASes choosing a legitimate route is
Happy S,
A ,
d
prefix
Let S be the set of ASes deploying BGPSEC,
A be the attacker and d be the destination
20960
3257
52142
12389
3356
5617
5617
174
?
3491
| Happy(S, A, d)| = 7
10310
7922
prefix
d
A
Our metric is the average of the set of Happy ASes
1
Metric(S) =
|V| 3
∑
all A
all d
Happy S,
A ,
d
prefix
Problem: find set S of secure ASes that maximizes
Happy S,
A ,
d
prefix
s. t. |S| = k, for a fixed attacker A and destination d
Theorem:
This problem is NP-hard for all three routing models.
26
Problem: Compute upper and lower bounds on
1
Metric(S) =
|V| 3
∑
Happy S,
A ,
d
prefix
all A
all d
for any BGPSEC deployment set S
27
Sprint
The bogus path is shorter!
4323
A, D
69.63.176.0/24
2828
A
Siemens
D
69.63.176.0/24
28
P/S
Sprint
Sprint is doomed
The bogus path is shorter!
P/S
4323
A, D
69.63.176.0/24
P/S
2828
A
P/S
D
69.63.176.0/24
Regardless of who is secure, Sprint
will select the shorter bogus route!
P/S
Siemens
29
P/S
Sprint
Sprint is doomed
The bogus path is shorter!
4323
P/S
The legitimate
path is shorter!
A, D
69.63.176.0/24
P/S
2828
A
P/S
D
69.63.176.0/24
P/S
Siemens
30
Sprint
2828 and 4323
are immune
The legitimate
path is shorter!
Sprint is doomed
The bogus path is shorter!
4323
A, D
69.63.176.0/24
2828
A
Siemens
D
69.63.176.0/24
Regardless of who is secure, 4323 and
2828 will select legitimate routes!
31
Problem: Find upper and lower bound on
1
Metric(S) =
|V| 3
∑
Happy S,
A ,
d
prefix
all A
all d
 Key observation. Regardless of who is secure:
1. Doomed ASes will always choose bogus routes
2. Immune ASes will always choose legitimate routes
 Lower bound on Metric(S) = fraction of immune ASes
 Upper bound on Metric(S) = 1 – fraction of doomed ASes
32
Average Fraction of Happy ASes
upper bound
with BGPSEC
47%
36%
17%
53%
lower bound
with RPKI
results based on simulations on empirical AS-level graphs
In the most realistic security 3rd model, the best
we could do is make extra 17% happy with security!
33
Average Fraction of Happy ASes
Securing 50% of ASes on the Internet
47%
24%
36%
17%
53%
lower bound
with RPKI
results based on simulations on empirical AS-level graphs
Improvements in the security 3rd and 2nd models
are only 4% and 8% respectively.
34

Graph: A UCLA AS-level topology from 09-24-2012
 39K ASes, 73.5K and 62K customer-provider and peer links

For each attacker-destination pair, simulated routing and
determined the sets of doomed and immune ASes

Quantified security-benefit improvements for many different
BGPSEC deployment scenarios

Robustness Tests
 added 550K extra peering links inferred from IXP data on 09-24-2012
 accounted for traffic patterns by focusing on only certain destinations
(e.g. content providers) and attackers
 currently repeating all analysis with respect to different local pref models
35
Security Benefits or Juice

Unless Security is 1st or BGPSEC deployment is very large,
security benefits from partially deployed BGPSEC are meagre

Typically little observable difference between Sec 2nd and 3rd
BGP
prevent
prefix
hijack
prevent
route
manipulations
*protocol downgrades
collateral damages
routing instabilities
BGP and BGPSEC
coexistence: very tricky
RPKI
(origin authentication)
BGPSEC
36
check out the full version at
http://arxiv.org/abs/1307.2690
1
2
3
4
Proofs
More empirical analysis and plots
Robustness tests
BGPSEC deployment guidelines
37