Measuring Adoption of RPKI
Route Validation and Filtering
PEERING
The BGP Testbed
Andreas Reuter ([email protected])
Joint work with Randy Bush,
Ethan Katz-Bassett, Italo Cunha,
Thomas C. Schmidt, and Matthias Wählisch
1
Once upon a time ... someone incorrectly
announced an IP prefix.
2
Once upon a time ... someone incorrectly
announced an IP prefix.
3
Once upon a time ... someone incorrectly
announced an IP prefix.
4
Enter RPKI
Prefix hijacking prevention using Resource Public Key Infrastructure
5
Enter RPKI
Prefix hijacking prevention using Resource Public Key Infrastructure
ROA Data
Authorization object:
Which AS is allowed to
announce an IP prefix
6
Enter RPKI
Prefix hijacking prevention using Resource Public Key Infrastructure
ROA Data
Authorization object:
Which AS is allowed to
announce an IP prefix
+
Route Origin
Validation
Router operation to
validate BGP Updates
based on ROA data
+
Local Policy
Decide handling of
invalid BGP routes
(drop?)
7
Enter RPKI
Prefix hijacking prevention using Resource Public Key Infrastructure
ROA Data
+
Authorization object:
Which AS is allowed to
announce an IP prefix
ROA: 10.20.0.0/16-24 AS100
Route Origin
Validation
+
Router operation to
validate BGP Updates
based on ROA data
BGP: 10.20.0.0/16 AS100 ✔
BGP: 10.20.0.0/16 AS666 ✖
Local Policy
Decide handling of
invalid BGP routes
(drop?)
Accept
Reject
8
Research Problem
ROA Data
Authorization object:
Which AS is allowed to
announce an IP prefix
Public Data
+
Route Origin
Validation
+
Router operation to
validate BGP Updates
based on ROA data
Local Policy
Decide handling of
invalid BGP routes
(drop?)
Private Policy
Measure the adoption of RPKI-based filter policies.
9
Research Challenge
ROA Data
Authorization object:
Which AS is allowed to
announce an IP prefix
Public Data
+
Route Origin
Validation
Router operation to
validate BGP Updates
based on ROA data
+
Local Policy
Decide handling of
invalid BGP routes
(drop?)
Private Policy
Measure the adoption of RPKI-based filter policies.
Challenge: Private policies must be inferred from measurements.
10
Two principle approaches
Uncontrolled
experiments
Analysing existing BGP
data and ROAs, trying
to infer who is filtering.
Controlled
experiments
Actively announcing
BGP Updates and
dynamically creating
ROAs
Analyse resulting BGP
data to infer who is
filtering.
➔ Fast
➔ Easy
➔
➔
Slow
Needs experimental
facilities
11
Uncontrolled Experiments: The Basic Idea
➔
Leverage divergence between AS paths of invalid and
non-invalid routes to infer if an AS is filtering
12
Uncontrolled Experiments: The Basic Idea
➔
Leverage divergence between AS paths of invalid and
non-invalid routes to infer if an AS is filtering
Vantage point (VP) peers with route
collector (RC), sends full or partial
feed of selected routes to it.
RC
AS2
P1
VP
AS1
AS3
Vantage point selects
routes with different AS
path for the prefixes
P2
AS1 announces prefixes:
P1(valid) and P2 (invalid)
13
Uncontrolled Experiments: The Basic Idea
➔
Leverage divergence between AS paths of invalid and
non-invalid routes to infer if an AS is filtering
Filtering invalid
routes?
Vantage point (VP) peers with route
collector (RC), sends full or partial
feed of selected routes to it.
RC
AS2
P1
VP
AS1
AS3
Vantage point selects
routes with different AS
path for the prefixes
P2
AS1 announces prefixes:
P1(valid) and P2 (invalid)
14
Uncontrolled Experiments: Problems
15
Uncontrolled Experiments: Problems
➔ Limited visibility can lead to misclassification
16
Uncontrolled Experiments: Limited Visibility
➔ Analysing data from different sets of vantage points can yield different
classifications
17
Uncontrolled Experiments: Limited Visibility
➔ Analysing data from different sets of vantage points can yield different
classifications
2
P1
VP
1
Vantage point chooses
routes with different AS
path
3
P2
AS1 announces prefixes:
P1(valid) and P2 (invalid)
18
Uncontrolled Experiments: Limited Visibility
➔ Analysing data from different sets of vantage points can yield different
classifications
Is AS2 using RPKI-based
filtering policy?
2
P1
VP
1
Vantage point chooses
routes with different AS
path
3
P2
AS1 announces prefixes:
P1(valid) and P2 (invalid)
19
Uncontrolled Experiments: Limited Visibility
➔ Analysing data from different sets of vantage points can yield different
classifications
VP2
Another vantage point
chooses routes with same
AS path
Is AS2 using RPKI-based
filtering policy? Probably not!
2
P1
VP
P2
Vantage point chooses
routes with different AS
path
3
1
AS1 announces prefixes:
P1(valid) and P2 (invalid)
20
Uncontrolled Experiments: Limited Visibility
➔ Analysing data from different sets of vantage points can yield different
classifications
VP2
Another vantage point
chooses routes with same
AS path
Is AS2 using RPKI-based
filtering policy? Probably not!
2
VP
P1
1
P2
We don’t have a complete view of AS-level Internet.
3
Vantage point
chooses without considering
Inference
missing data can
lead
to
AS1
announces
prefixes:
routes with different AS
misclassification!
P1(valid) and P2 (invalid)
path
21
Uncontrolled Experiments: Problems
➔ Limited Visibility can lead to misclassification
➔ Limited Control
22
Uncontrolled Experiments: Problems
➔ Limited Visibility can lead to misclassification
➔ Limited Control
◆ Cannot distinguish between filtering based on
RPKI vs. filtering based on other attributes
23
Uncontrolled Experiments: Limited Control
Real World Example
3356
P1
VP
1239
3130
Origin
P2
1299
Vantage point chooses
routes with different AS
path
Origin announces prefixes:
P1(valid) and P2 (invalid)
24
Uncontrolled Experiments: Limited Control
Real World Example
Is AS3356 using
RPKI-based filtering
policy?
3356
P1
VP
1239
3130
Origin
P2
1299
Vantage point chooses
routes with different AS
path
Origin announces prefixes:
P1(valid) and P2 (invalid)
25
Uncontrolled Experiments: Limited Control
Real World Example
Is AS3356 using
RPKI-based filtering
policy?
3356
P1
VP
1239
3130
Origin
P2
1299
Vantage point chooses
routes with different AS
path
Origin announces prefixes:
No!
P (valid) and P (invalid)
Vantage point is using route age as tie breaker.
1
2
26
Uncontrolled Experiments: Problems
➔ Limited Visibility can lead to misclassification
➔ Limited Control
◆ Cannot distinguish between filtering based on
RPKI vs. filtering based on other attributes
◆ Do not know origin AS policy. Traffic engineering
might look like RPKI-based filtering.
27
Uncontrolled Experiments: Limited Control
Origin Policy
AS1
P1
VP
Origin
P2
AS2
Vantage point chooses
routes with different AS
path
Origin announces prefixes:
P1(valid) and P2 (invalid)
28
Uncontrolled Experiments: Limited Control
Origin Policy
Is AS1 using RPKI-based
filtering policy?
AS1
P1
VP
Origin
P2
AS2
Vantage point chooses
routes with different AS
path
Origin announces prefixes:
P1(valid) and P2 (invalid)
29
Uncontrolled Experiments: Limited Control
Origin Policy
AS1
10.20.0.0/22
VP
Origin
AS2
Vantage point chooses
routes with different AS
path
10.20.0.0/24
Origin announces prefixes:
P1(valid) and P2 (invalid)
30
Uncontrolled Experiments: Limited Control
Origin Policy
ROA:
Prefix:10.20.0.0/22 - 22
ASN: Origin
AS1
10.20.0.0/22
VP
Origin
AS2
Vantage point chooses
routes with different AS
path
10.20.0.0/24
Origin announces prefixes:
P1(valid) and P2 (invalid)
31
Uncontrolled Experiments: Limited Control
Origin Policy
Is AS1 using RPKI-based
filtering policy?
AS1
Path divergence at first hop is more likely
to be
P1
the result of traffic engineering at origin.
VP
Origin
P2
AS2
Vantage point chooses
routes with different AS
path
Origin announces prefixes:
P1(valid) and P2 (invalid)
32
Path Divergence
Fraction of path pairs
Divergence between AS paths of routes with the same origin
AS hop at which paths diverge
33
Path Divergence
Fraction of path pairs
Divergence between AS paths of routes with the same origin
No significant
difference between
distributions indicates
lack of widespread
filtering
AS hop at which paths diverge
➔ Invalid routes (probably) have different AS paths for non-RPKI reasons
34
Uncontrolled Experiments: Problems
➔ Limited Visibility can lead to misclassification
➔ Limited Control
◆ Cannot distinguish between filtering based on
RPKI vs. filtering based on other attributes
◆ Do not know origin AS policy. Traffic Engineering
might look like RPKI-based filtering
35
Uncontrolled Experiments: Problems
➔ Limited Visibility can lead to misclassification
➔ Limited Control
◆ Cannot distinguish between filtering based on
RPKI vs. filtering based on other attributes
◆ Do not know origin AS policy. Traffic Engineering
might look like RPKI-based filtering
➔ Not possible to reproduce
36
Uncontrolled Experiments: Problems
➔ Limited Visibility can lead to misclassification
➔ Limited Control
Inferring if a specific AS
◆ Cannot
distinguish
between filtering
based
is using
RPKI-based
filtering
on on
the
basisbased
of uncontrolled
RPKI vs.
filtering
on other attributes
experiments is prone to
◆ Do not know origin AS policy. Traffic Engineering
misclassification!
might look like RPKI-based filtering
➔ Not possible to reproduce
37
Controlled Experiments
38
Controlled Experiments
Hand-crafted ROAs and BGP Updates
39
Controlled Experiments: Advantages
Hand-crafted ROAs and BGP Updates
➔ Limited Visibility is less of an issue, we only care about
our prefixes
40
Controlled Experiments: Advantages
Hand-crafted ROAs and BGP Updates
➔ Limited Visibility is less of an issue, we only care about
our prefixes
➔ Limited Control
◆ Can distinguish between RPKI-based filtering vs. filtering
based on other attributes by changing ROAs/Updates
◆ We know the routing policy of origin AS
41
Controlled Experiments: Advantages
Hand-crafted ROAs and BGP Updates
➔ Limited Visibility is less of an issue, we only care about
our prefixes
➔ Limited Control
◆ Can distinguish between RPKI-based filtering vs. filtering
based on other attributes by changing ROAs/Updates
◆ We know the routing policy of origin AS
➔ Can repeat experiments and target specific AS.
42
Controlled Experiments: Our Setup
BGP
RPKI
Announce prefixes PA (Anchor)
and PE (Experiment)
Issue ROAs for both prefixes
+
+
+
+
+
+
Same RIR DB route object
Same length
Minimal bit difference
Announced at the same time
Announced from same origin
AS
Announced to same peers
Periodically change ROA for
experiment prefix
➔
Flips announcement from
VALID to INVALID to VALID
once a day
(Yes, we operate a grandchild RPKI CA ;))
43
Controlled Experiments: Observations
Situation: Origin and vantage point peer directly
PA
VP
Origin
PE
Vantage point chooses
routes with same AS path
Origin announces prefixes:
PA(valid) and PE (valid)
44
Controlled Experiments: Observations
Situation: Origin and vantage point peer directly
PA
VP
Origin
PE
Vantage point chooses
routes with same AS path
Origin announces prefixes:
PA(valid) and PE (valid)
45
Controlled Experiments: Observations
Situation: Origin and vantage point peer directly
Observation 1: VP has no route for PE
now that it’s announcement is invalid
PA
VP
Origin
Origin announces prefixes:
PA(valid) and PE (invalid)
Conclusion: VP is using RPKI-based
filtering.
46
Controlled Experiments: Observations
Situation: Origin and vantage point peer directly
Observation 2: VP has route via AS X
for PE now that it’s announcement is
invalid
PA
VP
Origin
AS X
Vantage point chooses
routes with different AS
path
PE
Origin announces prefixes:
PA(valid) and PE (invalid)
Conclusion: VP uses RPKI-based
filtering selectively.
47
Controlled Experiments: Observations
Situation: Origin and vantage point do not peer directly, other AS
on path
PA
VP
AS X
Origin
PE
Vantage point chooses
routes with same AS path
Origin announces prefixes:
PA(valid) and PE (valid)
48
Controlled Experiments: Observations
Situation: Origin and vantage point do not peer directly, other AS
on path
PA
VP
AS X
Origin
PE
Vantage point chooses
routes with same AS path
Origin announces prefixes:
PA(valid) and PE (valid)
49
Controlled Experiments: Observations
Situation: Origin and vantage point do not peer directly, other AS
on path
Observation 1: VP has no route for PE
now that it’s announcement is invalid
PA
VP
AS X
Origin
Origin announces prefixes:
PA(valid) and PE (invalid)
Conclusion: VP or AS X (or both) are
using RPKI-based filtering.
50
Controlled Experiments: Observations
Situation: Origin and vantage point do not peer directly, other AS
on path
Observation 2: VP has different route for
PE now that it’s announcement is invalid
PA
VP
AS X
Origin
PE
AS Y
Origin announces prefixes:
PA(valid) and PE (invalid)
Conclusion: VP or AS X (or both) are
using RPKI-based filtering.
51
Controlled Experiments: Observations
Situation: Origin and vantage point do not peer directly, other AS
on path
Observation 2: VP has different route for
PE now that it’s announcement is invalid
PA
VP
AS X
Origin
Resolve ambiguity Pby:
E
AS Y
Origin announces prefixes:
PA(valid) and PE (invalid)
➔ Establishing direct peering with VP
Conclusion: VP or AS X (or both) are
using RPKI-based filtering.
52
Controlled Experiments: Observations
Situation: Origin and vantage point do not peer directly, other AS
on path
Observation 2: VP has different route for
PE now that it’s announcement is invalid
PA
VP
AS X
Origin
Resolve ambiguity Pby:
E
AS Y
Origin announces prefixes:
PA(valid) and PE (invalid)
➔ Establishing direct peering with VP
➔ Checking if AS X has a vantage point
Conclusion: VP or AS X (or both) are
using RPKI-based filtering.
53
Results
54
Results
We found at least 3 AS that deployed RPKI-based filtering!
None of them are large providers ...
2 AS filtered all
invalid routes
1 AS filtered
selectively
Another measurement study found other results.
55
Results
We found at least 3 AS that deployed RPKI-based filtering!
None of them are large providers ...
Confirmed by 1 AS filtered
experiments selectively
and
talking to operators.
2 AS filtered all
invalidrepeated
routes
Another measurement study found other results.
56
Conclusion
➔ There are ASes that do RPKI-based filtering.
Not many, not the big ones, but at least some (>3).
➔ Uncontrolled experiments are unsuited to infer RPKI-based
filtering policies
➔ Controlled experiments are crucial to measuring adoption of
RPKI-based filtering policies
Internet infrastructure requires proper monitoring.
57
Next Steps
➔ We will extend our measurement methodology.
➔ We will establish a live monitoring system with public access.
BGP monitoring is based on collaboration!
➔ Please, establish direct peering with PEERING testbed.
◆ https://peering.usc.edu/peering/
➔ Please, peer with public route collectors.
58
Next Steps
➔ We will extend our measurement methodology.
➔ We will establish a live monitoring system with public access.
Have you enabled RPKI-based
BGP monitoring is based on collaboration!
OV on a router today?
➔ Please, establish direct peering with PEERING testbed.
◆ https://peering.usc.edu/peering/
➔ Please, peer with public route collectors.
59
Backup
60
61
62
63
Path Diversity
Path Diversity Distribution of a single vantage point
For ~50% of origins,
there is exactly one
distinct AS path
When invalid routes are included,
path diversity of some origins
increases
➔ Invalid routes tend to have different AS paths than non-invalid routes
64
Vantage Point Visibility Matters
Prefixes and their Origins
Some VPs see
barely anything
Some VP have
near ‘global’ view
65
Vantage Point Visibility Matters
Prefixes of invalid routes and their reasons for invalidity
Some VPs have
very few invalid prefixes
Some none at all
66
Vantage Point Visibility Matters
Per-Origin Prefix Visibility
➔ Virtually all VPs have some origin AS they only ‘see’ incompletely. Oops!
67
Invalid Announcements: Path Diversity
68