Enhancing Interdomain Routing Security with RPKI
Are We There Yet?
On RPKI Deployment and Security
Yossi Gilad
joint work with: Avichai Cohen,
Amir Herzberg, Michael Schapira, Haya Shulman
The Resource Public Key Infrastructure
(informally) The Resource Public Key Infrastructure (RPKI)
maps IP prefixes to the organizations that own them [RFC 6480]
•
Intended to
prevent
prefix/subprefix hijacks
•
Lays the
foundation
for protection against more
sophisticated attacks on interdomain routing
–
BGPsec, SoBGP,…
2
Prefix Hijacking
AS X
AS Y
AS
3320
AS 666
91.0.0.0/10
Path: 3320
91.0.0.0/10
Path: Y-3320
91.0.0.0/10
Path: 666
prefers
shorter route
3
Deutsche
Telekom
Subprefix Hijacking
AS X
AS
3320
AS 666
91.0.0.0/10
Path: 3320
91.0.0.0/16
Path: Y-666
Longest prefix match
Path length does not matter
AS Y
91.0.0.0/16
Path: 666
4
Deutsche
Telekom
Certifying Ownership with RPKI
•
RPKI assigns an IP prefix to a public key via a Resource
Certificate (RC)
•
Owners can use their private key to issue a Route Origin
Authorization (ROA)
•
ROAs identify ASes authorized to advertise an IP prefix in BGP
5
Example: Certifying Ownership
Deutsche Telekom certified by RIPE
for address space 91.0.0.0/10
6
RPKI Can Prevent Prefix Hijacks
AS X
AS Y
AS
3320
AS 666
91.0.0.0/10
Path: Y-3320
91.0.0.0/10
Path: 666
AS X uses the authenticated mapping (ROA) from 91.0/10 to
AS 3320 to discard the attacker’s route-advertisement
7
91.0.0.0/10
Max-length = 10
AS 3320
Talk Outline
•
Challenges facing deployment
•
Route origin validation in partial deployment
8
AS 666
AS X
AS A
Insecure Deployment: Loose ROAs
1.2.0.0/16
Path: A
9
1.2.0.0/16
Path: 666-A
Picks shorter path
Lychev et al. show that this attack is
much less effective than prefix hijack
AS X
AS 666
Longest-prefix-match
Path length does not matter
AS A
Insecure Deployment: Loose ROAs
AS A
originates
1.2.0.0/16
but not
1.2.3.0/24
ROA is “loose”
1.2.0.0/16
Path: A
1.2.3.0/24
Path: 666-A
10
RFC 7115 mentions this attack
•
Loose ROAs are
common
!
–
almost 30% of IP prefixes in ROAs
–
89% of prefixes with maxLen > prefixLen
–
manifests even in large providers!
•
Attacker can hijack
all
traffic to non-advertised
subprefixes covered by a loose ROA
•
Vulnerability will be solved only when BGPsec is
fully deployed, but a long way to go until then…
–
better not to issue loose ROAs!
Insecure Deployment: Loose ROAs
11
Challenges to Deployment: Human Error
Many other mistakes in ROAs (see RPKI monitor)
–
``bad ROAs’’ cause legitimate prefixes to appear
invalid
–
filtering by ROAs may cause disconnection from legitimate destinations
–
extensive measurements in [Iamartino et al., PAM’15]
12
•
roalert.org
allows you to check whether your
network is
properly
protected by ROAs
•
… and if not, why not
Improving Accuracy with ROAlert
13
Improving Accuracy with ROAlert
•
Online, proactive notification system
•
Retrieves ROAs from the RPKI and compares them against
BGP advertisements
•
Alerts network operators about “loose ROAs” & “bad ROAs”
14
Improving Accuracy with ROAlert
•
Initial results are promising!
–
notifications reached 168 operators
–
42% of errors were fixed within a month
•
ROAlert is:
–
constantly monitoring (not only at registration)
–
not opt-in
•
We advocate that ROAlert be adopted and adapted by RIRs!
15
Talk Outline
•
Challenges facing deployment
•
Route origin validation in partial deployment
16
Filtering Bogus Advertisements
Route-Origin Validation (ROV)
:
use ROAs to discard/deprioritize route-advertisements
from unauthorized origins [RFC 6811]
Verify:
•
signer authorized for
subject prefix
•
signature is valid
BGP Routers
RPKI pub.
point
Autonomous System
17
RPKI cache
Major router vendors support ROV with
negligible overhead
Any AS, anywhere, can do ROV
But is it actually enforced?
18
ROV in Partial Deployment
We gain empirical insights regarding ROV enforcement
via
invalid
BGP advertisements
We monitored BGP paths from multiple vantage points
afforded by 44 Route Views sensors¹
–
Active
techniques presented earlier today
ROV in Partial Deployment
19
¹
http://www.routeviews.org/
Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements
do
not perform
filtering
20
Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements
do
not perform
filtering
O
r
i
g
i
n
1
1.2.3.0/24
Route Views sensor observes
“bad” route to:
4.5.6.0/24
AS path:
F, E, D, Origin 2
21
Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements
do
not perform
filtering
ASes that don’t filter
invalid advertisements
22
We find that at least 80 of 100 largest ISPs do not filter
What is the Impact of Partial
ROV Adoption?
•
Collateral benefit:
–
Adopters protect ASes behind them by discarding invalid routes
O
r
i
g
i
n
A
S
1
AS
2
A
S
6
6
6
To: 1.1/16
AS path: 2-1
To: 1.1.1/24
AS path: 666
AS
3
AS 3
is only offered
a
good route
23
1.1.0.0/16
Max-length = 16
AS 1
What is the Impact of Partial
ROV Adoption?
•
Collateral damage:
ASes
not doing ROV
might cause ASes
that
do ROV
to fall victim to attacks!
–
Disconnection:
Adopters might be offered only bad routes
O
r
i
g
i
n
A
S
1
AS
2
A
S
6
6
6
To: 1.1/16
AS path: 1
To: 1.1/16
AS path: 2-666
AS
3
AS 2
prefers to advertise
routes from
AS 666
over
AS 1
AS 3
receives only bad
advertisement and
disconnects
from
1.1/16
24
1.1.0.0/16
Max-length = 16
AS 1
What is the Impact of Partial
ROV Adoption?
•
Collateral damage:
ASes
not doing ROV
might cause ASes
that
do ROV
to fall victim to attacks!
–
Control-Plane-Data-Plane Mismatch!
data flows to
attacker, although AS 3 discarded it
O
r
i
g
i
n
A
S
1
AS
2
A
S
6
6
6
AS
3
To: 1.1/16
AS path: 2-1
To: 1.1.1/24
AS path: 2-666
AS 2
advertises both
prefix & subprefix routes
AS 3
discards bad
subprefix route
AS 2
does not filter and
uses
bad route for subprefix
25
1.1.0.0/16
Max-length = 16
AS 1
Quantify Security in Partial Adoption:
Simulation Framework
26
B
D
H
J
E
I
G
K
L
F
1.1.0.0/16
Max-length = 16
AS A
C
A
•
Pick victim & attacker
•
Victim’s prefix has a ROA
•
Pick set of ASes doing ROV
•
Evaluate which ASes send
traffic to the attacker
Empirically-derived AS-level network from CAIDA
Including inferred peering links [Giotsas et al., SIGCOMM’13]
Quantify Security in Partial Adoption
•
Top ISP adopts with probability
p
•
Significant benefit
only when
p
is high
27
Quantify Security in Partial Adoption
Subprefix hijack
success rate
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
28
Security in Partial Adoption
Bottom line:
ROV enforcement by the top ISPs is both
necessary
and
sufficient
for substantial security benefits from RPKI
29
Getting RPKI Adopted:
What Can We Improve?
•
Information accuracy
–
ROAlert informs & alerts operators about:
•
Bad ROAs
•
Loose ROAs
•
Preventing hijacks
–
Incentivize ROV adoption by the top ISPs!
–
Both sufficient and necessary for significant security benefits
30
Thank You!
This work appeared at NDSS’17
Tech report at
https://eprint.iacr.org/2016/1010.pdf
Questions?
31
Data Sources
•
BGP advertisements are constantly fed to ROAlert using CAIDA’s
BGPStream
•
ROAs and RCs obtained from RPKI repositories
–
trust anchors: afrinic, arin, ripe, lacnic, apnic, iana
•
Simulations use CAIDA’s AS topology graph from July 2016
–
Including inferred peering links
•
Measurements and examples are from a snapshot of our dataset from July
26
th
2016
32
This content explores the deployment and security aspects of Resource Public Key Infrastructure (RPKI), a system that maps IP prefixes to their owning organizations to prevent prefix/subprefix hijacks. It delves into prefix and subprefix hijacking scenarios, certifying ownership with RPKI, and how RPKI can prevent prefix hijacks by using Route Origin Authorizations (ROAs). The challenges in route origin validation deployment are also outlined.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Are We There Yet? On RPKI Deployment and Security Yossi Gilad joint work with: Avichai Cohen, Amir Herzberg, Michael Schapira, Haya Shulman
The Resource Public Key Infrastructure (informally) The Resource Public Key Infrastructure (RPKI) maps IP prefixes to the organizations that own them [RFC 6480] Intended to prevent prefix/subprefix hijacks Lays the foundation for protection against more sophisticated attacks on interdomain routing BGPsec, SoBGP, 2
Prefix Hijacking prefers shorter route AS X 91.0.0.0/10 Path: Y-3320 91.0.0.0/10 Path: 666 AS Y AS 666 91.0.0.0/10 Path: 3320 AS 3320 BGP Ad. Data flow Deutsche Telekom 3
Subprefix Hijacking Longest prefix match Path length does not matter AS X 91.0.0.0/10 Path: 3320 91.0.0.0/16 Path: Y-666 AS Y AS 3320 Deutsche Telekom 91.0.0.0/16 Path: 666 AS 666 BGP Ad. Data flow 4
Certifying Ownership with RPKI RPKI assigns an IP prefix to a public key via a Resource Certificate (RC) Owners can use their private key to issue a Route Origin Authorization (ROA) ROAs identify ASes authorized to advertise an IP prefix in BGP 5
Example: Certifying Ownership Deutsche Telekom certified by RIPE for address space 91.0.0.0/10 RIPE Legend: R seaux IP Europ ens Network Coordination Centre Org with RC 91.0.0.0/10 Max-length = 10 AS 3320 Deutsche Telekom 91.0.0.0/10 ROA 6
RPKI Can Prevent Prefix Hijacks AS X uses the authenticated mapping (ROA) from 91.0/10 to AS 3320 to discard the attacker s route-advertisement 91.0.0.0/10 Path: Y-3320 91.0.0.0/10 Path: 666 AS X 91.0.0.0/10 Max-length = 10 AS 3320 AS Y AS 666 AS 3320 BGP Ad. Data flow 7
Talk Outline Challenges facing deployment Route origin validation in partial deployment 8
Insecure Deployment: Loose ROAs 1.2.0.0/16 Max-length = 16 AS A Picks shorter path ROA allows advertising only one /16 prefix Valid advertisement since AS A is the origin AS X 1.2.0.0/16 Path: A 1.2.0.0/16 Path: 666-A AS A AS 666 BGP Ad. Data flow 9 Lychev et al. show that this attack is much less effective than prefix hijack
Insecure Deployment: Loose ROAs 1.2.0.0/16 Max-length = 24 AS A Longest-prefix-match Path length does not matter ROA allows advertising subprefixes up to length /24 AS A originates 1.2.0.0/16 but not 1.2.3.0/24 ROA is loose 1.2.0.0/16 Path: A Valid advertisement since AS A is the origin AS X 1.2.3.0/24 Path: 666-A AS A AS 666 BGP Ad. Data flow 10 RFC 7115 mentions this attack
Insecure Deployment: Loose ROAs Loose ROAs are common! almost 30% of IP prefixes in ROAs 89% of prefixes with maxLen > prefixLen manifests even in large providers! Attacker can hijack all traffic to non-advertised subprefixes covered by a loose ROA Vulnerability will be solved only when BGPsec is fully deployed, but a long way to go until then better not to issue loose ROAs! 11
Challenges to Deployment: Human Error Many other mistakes in ROAs (see RPKI monitor) ``bad ROAs cause legitimate prefixes to appear invalid filtering by ROAs may cause disconnection from legitimate destinations extensive measurements in [Iamartino et al., PAM 15] 12
Improving Accuracy with ROAlert roalert.org allows you to check whether your network is properly protected by ROAs and if not, why not 13
Improving Accuracy with ROAlert Online, proactive notification system Retrieves ROAs from the RPKI and compares them against BGP advertisements Alerts network operators about loose ROAs & bad ROAs 14
Improving Accuracy with ROAlert Initial results are promising! notifications reached 168 operators 42% of errors were fixed within a month ROAlert is: constantly monitoring (not only at registration) not opt-in We advocate that ROAlert be adopted and adapted by RIRs! 15
Talk Outline Challenges facing deployment Route origin validation in partial deployment 16
Filtering Bogus Advertisements Route-Origin Validation (ROV): use ROAs to discard/deprioritize route-advertisements from unauthorized origins [RFC 6811] Autonomous System Verify: signer authorized for subject prefix signature is valid RPKI cache RCs and ROAs RPKI pub. point 91.0.0.0/10: AS = 3320, max-length = 10 BGP Routers 17
Measurements: Non-Filtering ASes ASes that propagate invalid BGP advertisements do not perform filtering Origin 1 A 1.2.3.0/24 Origin 1 & 2 advertise in BGP RPKI-invalid IP prefixes RV B C sensor Origin 2 D 4.5.6.0/24 RV E F sensor 20
Measurements: Non-Filtering ASes ASes that propagate invalid BGP advertisements do not perform filtering Route Views sensor observes bad route to: 1.2.3/24 AS path: C, A, Origin 1 Origin 1 A 1.2.3.0/24 RV B C sensor Route Views sensor observes bad route to: 4.5.6.0/24 AS path: F, E, D, Origin 2 Origin 2 D 4.5.6.0/24 RV E F sensor 21
Measurements: Non-Filtering ASes ASes that propagate invalid BGP advertisements do not perform filtering Origin 1 A 1.2.3.0/24 RV B C sensor We find that at least 80 of 100 largest ISPs do not filter Origin 2 D 4.5.6.0/24 RV E F sensor ASes that don t filter invalid advertisements 22
What is the Impact of Partial ROV Adoption? Collateral benefit: Adopters protect ASes behind them by discarding invalid routes C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\OUIM4F8E\MC900435931[1].wmf 1.1.0.0/16 Max-length = 16 AS 1 To: 1.1.1/24 AS path: 666 AS 3 is only offered a good route AS 666 AS 2 AS 3 To: 1.1/16 AS path: 2-1 Origin AS 1 23
What is the Impact of Partial ROV Adoption? Collateral damage: ASes not doing ROV might cause ASes that do ROV to fall victim to attacks! Disconnection: Adopters might be offered only bad routes C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\OUIM4F8E\MC900435931[1].wmf 1.1.0.0/16 Max-length = 16 AS 1 AS 3 receives only bad advertisement and disconnects from 1.1/16 To: 1.1/16 AS path: 2-666 AS 666 AS 2 AS 3 AS 2 prefers to advertise routes from AS 666 over AS 1 To: 1.1/16 AS path: 1 Origin AS 1 24
What is the Impact of Partial ROV Adoption? Collateral damage: ASes not doing ROV might cause ASes that do ROV to fall victim to attacks! Control-Plane-Data-Plane Mismatch! data flows to attacker, although AS 3 discarded it C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\OUIM4F8E\MC900435931[1].wmf 1.1.0.0/16 Max-length = 16 AS 1 To: 1.1.1/24 AS path: 2-666 AS 666 AS 3 discards bad subprefix route AS 2 advertises both prefix & subprefix routes AS 2 does not filter and uses bad route for subprefix AS 2 AS 3 To: 1.1/16 AS path: 2-1 Origin AS 1 25
Quantify Security in Partial Adoption: Simulation Framework Pick victim & attacker Victim s prefix has a ROA Pick set of ASes doing ROV Evaluate which ASes send traffic to the attacker 1.1.0.0/16 Max-length = 16 AS A A B C D E F G H I J C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\OUIM4F8E\MC900435931[1].wmf K L Empirically-derived AS-level network from CAIDA Including inferred peering links [Giotsas et al., SIGCOMM 13] 26
Quantify Security in Partial Adoption Top ISP adopts with probability p Significant benefit only when p is high Subprefix hijack Prefix hijack success rate success rate 27
Quantify Security in Partial Adoption 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 Subprefix hijack success rate Adoption by the top 100 ISPs makes a huge difference! 28
Security in Partial Adoption Bottom line: ROV enforcement by the top ISPs is both necessary and sufficient for substantial security benefits from RPKI 29
Getting RPKI Adopted: What Can We Improve? Information accuracy ROAlert informs & alerts operators about: Bad ROAs Loose ROAs Preventing hijacks Incentivize ROV adoption by the top ISPs! Both sufficient and necessary for significant security benefits 30
Thank You! This work appeared at NDSS 17 Tech report at https://eprint.iacr.org/2016/1010.pdf Questions? 31
