Transcript Presentation

Are We There Yet?
On RPKI Deployment and Security
Yossi Gilad
joint work with: Avichai Cohen,
Amir Herzberg, Michael Schapira, Haya Shulman
1
The Resource Public Key
Infrastructure
The Resource Public Key Infrastructure (RPKI) maps IP
prefixes to organizations that own them [RFC 6480]
• Intended to prevent prefix/subprefix hijacks
– We will show that this is often not the case
• Lays the foundation for protection against more
sophisticated attacks on interdomain routing
– BGPsec, SoBGP,…
2
Talk Outline
• Background
• Quantify RPKI’s deployment and security
– Who uses the RPKI?
– How “good” is RPKI in partial deployment?
• Discuss the obstacles facing full deployment
– Insecure deployment
– human error
– inter-organization dependencies
• Propose and evaluate solutions
3
Prefix Hijacking
prefers
shorter route
AS X
91.0/10
Path: Y-3320
AS Y
AS 666
91.0/10
Path: 3320
AS
3320
Deutsche
Telekom
BGP Ad.
91.0/10
Path: 666
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
*This presentation uses real-world
examples. See slide 54 for details on data
sources.
6
RPKI should 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/10
Path: Y-3320
AS Y
91.0/10
Path: 666
AS X
91.0/10  AS 3320
AS 666
AS
3320
Deutsche
Telekom
BGP Ad.
Data flow
7
Talk Outline
• Background
• Quantify RPKI’s deployment and security
– Who uses the RPKI?
– How “good” is RPKI in partial deployment?
• Discuss the obstacles facing full deployment
– Insecure deployment
– human error
– inter-organization dependencies
• Propose and evaluate solutions
8
But who actually filters
bogus advertisements?
Route-Origin Validation (ROV):
use ROAs to discard route-advertisements from
unauthorized origins [RFC 6811]
Autonomous System
RCs and ROAs
RPKI cache
RPKI pub.
point
Verify:
• signer authorized for
subject prefix
• signature is valid
91.0.0.0/10:
AS = 3320, max-length = 10
BGP Routers
9
But who actually filters
bogus advertisements?
Major router vendors support ROV with
negligible overhead
Any AS, anywhere, can do ROV.
But which AS actually does ROV?
We present the first measurement study of
ROV adoption
10
ROV adoption: Measurements
ROA issuing rates are constantly monitored
Information accessible since ROAs are public ¹
Measuring ROV adoption is challenging:
How to tell if a BGP router performs ROV?
¹ https://rpki-monitor.antd.nist.gov/
11
ROV adoption: Measurements
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 ²
² http://www.routeviews.org/
12
Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements do
not perform filtering
15003
6416
191.96.100.0/24
AS 15003 and AS 42926 advertise in
BGP the RPKI-invalid IP prefixes
191.96.100.0/24 and 185.70.84.0/24
42926
1239
4637
RV
sensor
1299
6939
RV
sensor
9121
185.70.84.0/24
*This presentation provides examples
based on empirical data. See slide 54 for
details on data sources.
13
Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements do
not perform filtering
15003
Route Views sensor observes
“bad” route to: 191.96.100.0/24
AS path: 4637, 6416, 15003
6416
191.96.100.0/24
1239
42926
185.70.84.0/24
9121
4637
RV
sensor
Route Views sensor observes
“bad” route to: 185.70.84.0/24
AS path: 6939, 1299, 9121, 42926
1299
6939
RV
sensor
14
Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements do
not perform filtering
15003
6416
191.96.100.0/24
42926
1239
4637
RV
sensor
1299
6939
RV
sensor
9121
185.70.84.0/24
ASes that don’t filter
invalid advertisements
colored red
15
Measurements: Filtering ASes
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
191.96.100.0/24
AS 42926 announces another
BGP advertisement for
prefix 79.98.130.0/24
42926
1239
4637
RV
sensor
1299
6939
RV
sensor
9121
185.70.84.0/24
79.98.130.0/24
16
Measurements: Filtering ASes
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
191.96.100.0/24
AS 42926 announces another
BGP advertisement for
prefix 79.98.130.0/24
42926
Route Views sensor observes
``good’’ route to: 79.98.130.0/24
AS path: 4637, 1239, 9121, 42926
1239
4637
RV
sensor
1299
6939
RV
sensor
9121
185.70.84.0/24
79.98.130.0/24
17
Measurements: Filtering ASes
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
Conclude: AS 1239 receives adv. by AS
6416
42926, but15003
did not relay the invalid one
(only non-red AS on legitimate adv. path)
191.96.100.0/24
AS 42926 announces another
BGP advertisement for
prefix 79.98.130.0/24
42926
Route Views sensor observes
``good’’ route to: 79.98.130.0/24
AS path: 4637, 1239, 9121, 42926
1239
4637
RV
sensor
1299
6939
RV
sensor
9121
185.70.84.0/24
79.98.130.0/24
18
Measurements: Results
Our 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
19
Measurements: Results
An anonymous 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
Does not protect against
subprefix hijacks
[Heilman et al. 2014]
Do you apply RPKI-based
route-origin validation?
*See slide 55 for more details
on survey participants
20
Talk Outline
• Background
• Quantify RPKI’s deployment and security
– Who uses the RPKI?
– How “good” is RPKI in partial deployment?
• Discuss the obstacles facing full deployment
– Insecure deployment
– human error
– inter-organization dependencies
• Propose and evaluate solutions
21
What is the impact of partial
ROV adoption?
• We identify two phenomena:
– Collateral benefits: Adopters protect other ASes
``behind’’ them
– Collateral damages: ASes not doing ROV might cause
ASes that do ROV to fall victim to attacks!
22
What is the impact of partial
ROV adoption?
• Collateral benefits:
– Adopters protect ASes behind them by
discarding invalid routes
AS 666
To: 1.1.1/24
AS path: 666
AS
2
Origin
AS 1
AS 3 is only offered
a good route
AS
3
To: 1.1/16
AS path: 2-1
23
What is the impact of partial
ROV adoption?
• Collateral damages: Disconnection
– Adopters might be offered only bad routes
To: 1.1/16
AS path: 2-666
AS 666
AS 2 prefers to advertise
routes from AS 666 over
AS 1
Origin
AS 1
AS
2
AS
3
AS 3 receives only bad
advertisement and
disconnects from AS 1
To: 1.1/16
AS path: 2-1
24
What is the impact of partial
ROV adoption?
• Collateral damages:
Control-Plane-Data-Plane Mismatch!
– Control/data plane discrepancy causes data to
flow to attacker, although AS 3 discarded it!
• Occurs even when AS 2 deprefers invalid routes
AS 666
AS 2 advertises both
prefix & subprefix routes
AS 2 does not filter and uses
bad route for subprefix
Origin
AS 1
To: 1.1.1/24
AS path: 2-666 AS 3 discards bad
subprefix route
AS
AS
2
3
To: 1.1/16
AS path: 2-1
25
Quantify Security in Partial Adoption
• 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 attacker/victim pairs
26
Quantify Security in Partial Adoption
• Collateral benefits:
– Top ISP adopts with probability p (p=¼, ½, ¾, 1)
– Significant benefit only when p is high (p= ¾, 1)
Prefix hijack success rate
Subprefix hijack success rate
27
Quantify Security in Partial Adoption
• Collateral damages:
– Top ISP adopts with probability p (p=¼, ½, ¾, 1)
– Avoid collateral damage only when p is high (p= ¾, 1)
Prefix hijack leads to disconnection
Subprefix hijack causes control-planedata-plane inconsistency
28
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
Adoption by the top 100 ISPs makes a
huge difference!
Prefix hijack
Subprefix hijack
29
Quantify Security in Partial Adoption
Bottom line:
ROV enforcement by the top ISPs is both necessary and
sufficient for substantial security benefits from RPKI
30
Talk Outline
• Background
• Quantify RPKI’s deployment and security
– Who uses the RPKI?
– How “good” is RPKI in partial deployment?
• Discuss the obstacles facing full deployment
– insecure deployment
– human error
– inter-organization dependencies
• Propose and evaluate solutions
31
Security Vulnerability:
Loose ROAs
Longest-prefix-match routing
ensures that the hijacker’s route
to AS 666 is preferred
AS 3303 originates 81.62/16
but not 81.62.0/24
81.62/16
Path: 3303
AS
3303
Swisscom
BGP Ad.
Data flow
AS X
81.62/15-24  AS 3303
Valid advertisement since
AS 3303 is the “origin”
81.62.0/24
Path: 666-3303
AS 666
Swisscom’s ROA allows advertising
subprefixes up to length /24
32
Security Vulnerability:
Loose ROAs
Manifests even in large providers, e.g., Swisscom
• ROA allows up to /24, but only /16s announced
• To hijack all traffic to prefix 81.62.0.0/16, attacker announces
81.62.0.0/17 and 81.62.128.0/17 with AS-path 666-3303
• Swisscom should set the maxLength to 16
33
Security Vulnerability:
Loose ROAs
• Loose ROAs are common!
– almost 30% of IP prefixes in ROAs
– 89% of prefixes with maxLen > prefixLen
• Attacker can hijack all traffic to nonadvertised subprefixes covered by a loose ROA
34
Talk Outline
• Background
• Quantify RPKI’s deployment and security
– Who uses the RPKI?
– How “good” is RPKI in partial deployment?
• Discuss the obstacles facing full deployment
– Insecure deployment
– human error
– inter-organization dependencies
• Propose and evaluate solutions
35
Obstacles to Deployment:
Human Error
Many other mistakes in RPKI (see RPKI monitor)
– legitimate prefixes are often considered invalid
– ROV causes disconnection from legitimate destinations
– Extensive measurements in [Iamartino et al., PAM’15]
Using RPKI database of July
2016. See details in slide 54.
36
Obstacles to Deployment:
Human Error
Concern for disconnection was also pointed out in
our survey:
What are your main concerns regarding
executing RPKI-based origin authentication in
your network?
37
Obstacles to Deployment:
Human Error
Who is responsible for “bad ROAs”?
• Hundreds of organizations are responsible for
invalid IP prefixes, but…
• Good news: most errors are due to a small number
of organizations
38
Talk Outline
• Background
• Quantify RPKI’s deployment and security
– Who uses the RPKI?
– How “good” is RPKI in partial deployment?
• Discuss the obstacles facing full deployment
– Insecure deployment
– human error
– inter-organization dependencies
• Propose and evaluate solutions
39
Obstacles to Deployment:
Inter-Organization Dependencies
Upward dependencies:
Level 3 Communications did not obtain an RC.
Consequently, its customers cannot obtain an RC
40
Obstacles to Deployment:
Inter-Organization Dependencies
Good news: Not many organizations are
upward-dependent
41
Obstacles to Deployment:
Inter-Organization Dependencies
Downward dependencies:
Orange issued a ROA which renders
routes to other organizations invalid
42
Obstacles to Deployment:
Inter-Organization Dependencies
Good news: Only a handful of prefixes are
downward dependent
43
Obstacles to Deployment:
Inter-Organization Dependencies
Bad news: These are large prefixes that belong
to large Internet providers
– Orange and Level 3 are but two examples
44
Talk Outline
• Background
• Quantify RPKI’s deployment and security
– Who uses the RPKI?
– How “good” is RPKI in partial deployment?
• Discuss the obstacles facing full deployment
– Insecure deployment
– human error
– inter-organization dependencies
• Propose and evaluate solutions
45
Three Obstacles to RPKI adoption
• Insufficient value
• Justified mistrust
• Inter-organizational dependencies
46
Generating Value
• Incentivize ROV adoption by the top ISPs!
• Both sufficient and necessary for significant
security benefits.
47
Building Trust: ROAlert
• roalert.org allows you to check whether your network
is properly protected by ROAs
• … and if not, why not
48
Building Trust: ROAlert
• Online, proactive notification system
• Retrieves ROAs from the RPKI and compares them
against BGP adv.
– Online feed through CAIDA BGPStream ³
• Alerts network operators from “bad ROAs”
(offenders and victims alike!)
• Enter ROAlert.org!
³ https://bgpstream.caida.org/
49
Building Trust: ROAlert
50
Building Trust: ROAlert
• Unlike existing systems 4:
– constant monitoring (not only at registration)
– not opt-in
• Initial results are promising!
– notifications reached 168 victims and offenders (over 6
months period)
– 42% of errors were fixed within a month
• We advocate that ROAlert be adopted and adapted by
RIRs!
4 https://www.nanog.org/sites/default/files/RPKI%20-%20NANOG63.pdf
51
Improving RPKI
• Eliminate downward dependencies via “wildcard
ROAs” (see our NDSS’17 paper for details)
• MaxLength considered harmful. Why not remove?
[Gilad, Ossaga & Goldberg 2016]
52
Thank You!
This work will also appear at NDSS’17
Tech report at https://eprint.iacr.org/2016/1010.pdf
Questions? 
53
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 26th 2016
54
Survey Participants
What is your role?
`Which of the following
best describes your network?’’
55
Survey Participants
How many IP addresses
does your network include?
Where is your network?’
Does your organization
have an AS number?
56