Deployment Is the Juice Worth the Squeeze 1 Robert Lychev Sharon Goldberg Michael Schapira Georgia Tech Boston University Boston University Hebrew University Partial Landscape of BGP D ID: 306524
Download Presentation The PPT/PDF document "BGP Security in Partial" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
BGP Security in Partial DeploymentIs the Juice Worth the Squeeze?
1
Robert Lychev Sharon Goldberg Michael Schapira
Georgia
TechBoston University
Boston University
Hebrew UniversitySlide2
Partial Landscape of BGP Defenses
2
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
?)
Security Benefits or Juice
BGP and BGPSEC
coexistence
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
if network operators do not prioritize security in their routing policiesSlide3
Outline3
Background:
BGP, RPKI, BGPSEC routing policies in BGPSEC partial deploymentBGPSEC in partial deployment is trickyIs the juice worth the squeeze?SummarySlide4
BGP
4
4
Sprint28284323D
69.63.176.0
/24
D
69.63.176.0
/24
2828, D
69.63.176.0
/24
4323, 2828, D
69.63.176.0
/24
A
Sprint, 4323, 2828, D
69.63.176.0
/24
Slide5
The “1-hop hijack”
5
5
Sprint28284323D
69.63.176.0
/24
Which route to choose?
Use routing policies.
e.g. “Prefer short paths
”
4323, 2828, D
69.63.176.0
/24
?
A
A, D
69.63.176.0
/24
Slide6
Prefix Hijack
6
6
Sprint28284323D
69.63.176.0
/24
Which route to choose?
Use routing policies.
e.g. “Prefer short paths
”
4323, 2828, D
69.63.176.0
/24
?
A
A
69.63.176.0
/24
69.63.176.0
/24
A, D
69.63.176.0
/24
Slide7
A
A
69.63.176.0
/24
RPKI Prevents Prefix Hijacks
7
7
Sprint
2828
4323
D
69.63.176.0
/24
RPKI
Binds prefixes to ASes authorized to originate them.
X
RPKI invalid!
Sprint checks that
A is not authorized
f
or 69.63.176.0/24
69.63.176.0
/24Slide8
8
BGP
RPKI (origin authentication)
BGPSEC
S
4323,2828, FB,
prefix
S
2828, FB,
prefix
S
SP, 4323, 2828, FB,
prefix
Security Benefits or Juice
p
revent prefix hijacks
assume RPKI is fully deployed, and focus on 1-hop hijack.
Partial Landscape
of BGP D
efenses
p
revent route manipulationsSlide9
A
S
SP, A,
D
,
prefix
A, D,
prefix
X
BGPSEC invalid!
BGPSEC Prevents the “1-hop hijack
”
9
9
Sprint
2828
4323
D
69.63.176.0
/24
P/S
P/S
P/S
P/S
S
4323,2828, D,
prefix
S
2828, D,
prefix
S
SP, 4323, 2828, D,
prefix
S
2828, D,
prefix
S
4323, 2828, D,
prefix
2828, D,
prefix
S
P/S
?
Sprint
can verify
that
D
never sent
A
, D
prefix
S
RPKISlide10
What happens when
BGP andBGPSEC coexist?
10BGPRPKI (origin authentication
)
BGPSEC
S
4323,2828, FB,
prefix
S
2828, FB,
prefix
S
SP, 4323, 2828, FB,
prefix
Security Benefits or Juice
p
revent prefix hijacks
assume RPKI is fully deployed, and focus on 1-hop hijack.
Partial Landscape
of BGP D
efenses
p
revent route manipulationsSlide11
A
What
H
appens in Partial BGPSEC Deployment?
11
11
Sprint
2828
4323
D
Siemens
69.63.176.0
/24
P/S
P/S
P/S
P/S
Should Sprint choose
the long secure path OR
the short insecure one?
P/S
P/S
?
S
ecure
ASes
must accept legacy insecure routes
Depends on the interaction between BGPSEC and routing policies!
RPKI
S
4323,2828, D,
prefix
S
2828, D,
prefix
S
SP, 4323, 2828, D,
prefix
A, D
69.63.176.0
/24
Slide12
BGP Decision Process
12
local preference (often based on business relationships with neighbors) 2. prefer short routes …3. break ties in a consistent mannerSlide13
Security 1
st
local preference (cost)
(often based on business relationships with neighbors) Security 2nd 2. prefer short routes (performance)Security 3rd 3. break ties in a consistent manner
How to Prioritize Security?13
Survey of 100 network operators
shows
that 10%, 20% and
41%
would
place security 1
st
, 2
nd
, and 3
rd
,
[Gill,
Schapira
, Goldberg’12]
Security
Cost,
Performance
Security
Cost,
PerformanceSlide14
Our Routing Model
14
Security 1st
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.Slide15
Outline15
Background: BGP, RPKI, BGPSEC, routing policies
BGPSEC in partial deployment is trickyProtocol downgrade attacksCollateral damagesRouting instabilitiesIs the Juice worth the squeeze?SummarySlide16
A
Protocol Downgrade
A
ttack, Security 3
rd
!
16
16
Sprint
2828
4323
D
69.63.176.0
/24
P/S
P/S
P/S
S
4323,2828, D,
prefix
S
2828, D,
prefix
S
SP, 4323, 2828, D,
prefix
P/S
Security 3
rd
:
Path length trumps path security!
?
Protocol downgrade attack:
Before
the attack, Sprint has a legitimate secure route.
During
the attack, Sprint downgrades to an insecure bogus route .
A, D
69.63.176.0
/24
Slide17
Partial Deployment is Very Tricky!
17
We prove…No protocol downgrades?No collateral damages?No instabilities?
Security 1stSecurity 2nd
Security 3rd
A
2828
4323
D
Siemens
69.63.176.0
/24
P/S
P/S
P/S
A, D
69.63.176.0/24
P/S
?
Protocol downgrade attack:
A secure AS with a secure route
before
the attack, downgrades to an insecure bogus route
during
the attack.
Sprint
P/SSlide18
Collateral Damages; Security 2nd
3257
20960
5617
3356
52142
12389
M
prefix
10310
40426
7922
174
3491
P/S
P/S
P/S
P/S
P/SSlide19
Collateral Damages; Security 2nd
W
X
Z
Y
M
Before X deploys BGPSEC
?
X offers the shorter path
?
Shorter path!
prefix
D
V
P/S
P/S
P/S
P/S
P/S
Secure
ASes
: 5
Happy
ASes
: 8Slide20
Collateral Damages; Security 2nd
W
X
V
Z
Y
M
?
W offers the shorter path!
?
Security 2
nd
:
Security trumps path length!
Y experiences
collateral damage
because X is secure!
P/S
P/S
P/S
P/S
P/S
Secure
ASes
: 6
Happy
ASes
: 7
After X deploys BGPSEC
prefix
D
P/SSlide21
Partial Deployment is Very Tricky!
21
We prove…No protocol downgrades?No collateral damages?
No instabilities?Security 1stSecurity 2nd
Security 3rd
3257
20960
5617
3356
52142
12389
A
?
?
5617
Collateral damage
(during the attack):
More
secure
ASes
leads to
more
insecure
ASes
choosing bogus routes
10310
40426
7922
174
3491
prefix
P/S
P/S
P/S
P/S
P/S
P/SSlide22
We
prove…
No protocol downgrades?No collateral damages?No instabilities?Security 1st
Security 2ndSecurity 3rd
Partial Deployment is Very Tricky!
22
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.
Slide23
Outline23
Background: BGP, RPKI, BGPSEC, routing policies
BGPSEC in partial deployment is trickyIs the Juice worth the Squeeze? Can we efficiently select the optimal set of secure ASes?Can we bound security benefits invariant to who is secure?Is the BGPSEC juice worth the squeeze given RPKI?SummarySlide24
Let
S
be the set of ASes deploying BGPSEC, A
be the attacker and d be the destinationThe set of ASes choosing a legitimate route is
Happy
S
, ,
prefix
Quantifying Security: A Metric
24
3257
20960
5617
3356
52142
12389
?
10310
d
7922
5617
174
3491
A
d
prefix
A
|
Happy(S, A, d)
|
= 7Slide25
∑
a
ll
Aall
d
Let
S
be the set of ASes deploying BGPSEC,
A
be the attacker and
d
be the destination
Our metric is the average of the set of Happy
ASes
Happy
S
, ,
Quantifying Security: A Metric
25
|
Happy(S, A, d)
|
= 7
|V|
3
1
Metric(S) =
prefix
3257
20960
5617
3356
52142
12389
?
10310
d
7922
5617
174
3491
A
A
d
prefixSlide26
Problem: find set
S
of secure ASes that maximizes
s. t. |S| = k, for a fixed attacker A and destination dTheorem: This problem is NP-hard for all three routing models.
Happy
S
, ,
It is Hard to
D
ecide Whom to Secure
26
A
d
prefixSlide27
∑
a
ll
Aall
d
Problem:
Compute upper
and lower
bounds
on
for any BGPSEC deployment set
S
Bound Security Benefits for any
S
!
27
Happy
S
, ,
|V|
3
1
Metric(S) =
A
d
prefixSlide28
A
Bounding Security Metric. Security 3
rd
28
28
Sprint
2828
4323
D
Siemens
69.63.176.0
/24
A, D
69.63.176.0
/24
The bogus path is shorter!Slide29
A
Bounding Security Metric. Security 3
rd
29
29
Sprint
2828
4323
D
Siemens
P/S
Sprint is doomed
The bogus path is shorter!
P/S
P/S
P/S
P/S
Regardless of who is secure, Sprint
w
ill select the shorter bogus route!
69.63.176.0
/24
A, D
69.63.176.0
/24
Slide30
A
Bounding Security Metric. Security 3
rd
30
30
Sprint
2828
4323
D
Siemens
P/S
P/S
P/S
P/S
P/S
69.63.176.0
/24
A, D
69.63.176.0
/24
The legitimate path is shorter!
Sprint is doomed
The bogus path is shorter!
Slide31
A
Bounding Security Metric. Security 3
rd
31
31
Sprint
2828
4323
D
Siemens
69.63.176.0
/24
2828 and 4323
are immune
The legitimate path is shorter!
A, D
69.63.176.0
/24
Regardless of who is secure, 4323 and 2828 will select legitimate routes!
Sprint is doomed
The bogus path is shorter!
Slide32
∑
a
ll
Aall
d
Problem:
Find upper
and lower bound on
Different Idea: Bound
S
ecurity Benefits!
32
Key observation.
Regardless of who is secure:
Doomed
ASes
will always choose bogus routes
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
Happy
S
, ,
|V|
3
1
Metric(S) =
A
d
prefixSlide33
33
Security Benefits Bounds over
RPKIlower boundwith RPKI17%upper boundwith BGPSECIn the most realistic security 3rd model, the best we could do is make extra 17% happy with security!
53%36%47%
Average Fraction of Happy ASes
results based on simulations on empirical AS-level graphs Slide34
34
l
ower boundwith RPKI17%53%36%47%Securing 113 High Degree ASes & their Stubs
Securing 50% of ASes on the InternetImprovements in the security 3rd and 2nd models are only 4% and 8% respectively.
24%
Average Fraction of Happy
ASes
r
esults based on simulations on empirical AS-level graphs Slide35
35
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 ASesQuantified security-benefit improvements for many different BGPSEC deployment scenariosRobustness Testsadded 550K extra peering links inferred from IXP data on 09-24-2012accounted 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
Our MethodologySlide36
36
BGP
RPKI (origin authentication
)
BGPSEC
S
4323,2828, FB,
prefix
S
2828, FB,
prefix
S
SP, 4323, 2828, FB,
prefix
Security Benefits or Juice
p
revent prefix hijack
Unless Security is 1
st
or BGPSEC deployment is very large, security benefits from partially deployed BGPSEC are
meagre
Typically little observable difference between Sec 2
nd
and 3
rd
So Is the Juice Worth the Squeeze?
p
revent route manipulations
BGP and BGPSEC
c
oexistence:
very tricky
*protocol downgrades
c
ollateral damages
r
outing instabilitiesSlide37
37
THANK YOU
check out the full version at http://arxiv.org/abs/1307.2690ProofsMore empirical analysis and plotsRobustness testsBGPSEC deployment guidelines