1. Are We There Yet? On RPKI Deployment and Security
Yossi Gilad
joint work with: Avichai Cohen,
Amir Herzberg, Michael Schapira, Haya Shulman

2. 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,…

3. 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

4. Prefix Hijacking Deutsche Telekom AS X 91.0/10 Path: Y-3320 91.0/10
prefers
shorter route
AS X
91.0/10
Path: Y-3320
91.0/10
Path: 666
AS Y
AS 666
91.0/10
Path: 3320
AS 3320
Deutsche Telekom
BGP Ad.
Data flow

5. 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

6. Example: Certifying Ownership
Deutsche Telekom certified by RIPE for address space /10
*This presentation uses real-world examples. See slide 54 for details on data sources.

7. 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 X
91.0/10
Path: 666
AS Y
91.0/10  AS 3320
AS 666
Deutsche Telekom
AS 3320
BGP Ad.
Data flow

8. 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

9. But who actually filters bogus advertisements?
Route-Origin Validation (ROV): use ROAs to discard route-advertisements from unauthorized origins [RFC 6811]
Verify:
signer authorized for subject prefix
signature is valid
/10:
AS = 3320, max-length = 10
RCs and ROAs
BGP Routers
RPKI cache
RPKI pub. point
Autonomous System

10. 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

11. 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? ¹

12. 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 ² ²

13. Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements do not perform filtering
42926
1299 RV
sensor
/24
9121
1239
4637
15003
6416
/24
AS and AS advertise in BGP the RPKI-invalid IP prefixes /24 and /24
6939
*This presentation provides examples based on empirical data. See slide 54 for details on data sources.

14. Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements do not perform filtering
42926
1299 RV
sensor
/24
Route Views sensor observes “bad” route to: /24
AS path: 4637, 6416, 15003
9121
6939
1239
4637
6416
15003
/24
Route Views sensor observes “bad” route to: /24
AS path: 6939, 1299, 9121, 42926

15. Measurements: Non-Filtering ASes
ASes that propagate invalid BGP advertisements do not perform filtering
15003
/24
42926
1299 RV
sensor
/24
9121
6939
1239
4637
6416
ASes that don’t filter invalid advertisements colored red

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
6416
15003
/24
42926
1299 RV
sensor
/24
9121
6939
1239
/24
AS announces another BGP advertisement for
prefix /24
4637

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.
42926
1299 RV
sensor
/24
Route Views sensor observes ``good’’ route to: /24
AS path: 4637, 1239, 9121, 42926
9121
6939
1239
4637
/24
6416
15003
/24
AS announces another BGP advertisement for
prefix /24

18. 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
42926
1299 RV
sensor
/24
9121
6939
1239
4637
/24
Route Views sensor observes ``good’’ route to: /24
AS path: 4637, 1239, 9121, 42926
Conclude: AS 1239 receives adv. by AS 42926, but did not relay the invalid one
(only non-red AS on legitimate adv. path)
6416
15003
/24
42926
1299 RV
sensor
/24
9121
6939
1239
4637
/24
AS announces another BGP advertisement for
prefix /24

19. 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

20. 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

21. 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

22. 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!

23. 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 3 is only offered a good route
AS 2
AS 3
To: 1.1/16
AS path: 2-1
Origin
AS 1

24. What is the impact of partial ROV adoption?
Collateral damages: Disconnection
Adopters might be offered only bad routes
AS 666
To: 1.1/16
AS path: 2-666
AS 3 receives only bad advertisement and disconnects from AS 1
AS 2 prefers to advertise routes from AS 666 over AS 1
AS 2
AS 3
To: 1.1/16
AS path: 2-1
Origin
AS 1

25. 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
To: 1.1.1/24
AS path: 2-666
AS 3 discards bad subprefix route
AS 2 advertises both prefix & subprefix routes
AS 2
AS 3
AS 2 does not filter and uses bad route for subprefix
To: 1.1/16
AS path: 2-1
Origin
AS 1

26. 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

27. 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

28. 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-plane-data-plane inconsistency

29. 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

30. Quantify Security in Partial Adoption
Bottom line: ROV enforcement by the top ISPs is both necessary and sufficient for substantial security benefits from RPKI

31. 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

32. 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 /24
Valid advertisement since AS 3303 is the “origin”
AS X
81.62/16
Path: 3303
/24
Path:
AS 3303
81.62/15-24  AS 3303
AS 666
Swisscom
Swisscom’s ROA allows advertising subprefixes up to length /24
BGP Ad.
Data flow

33. 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 /16, attacker announces /17 and /17 with AS-path
Swisscom should set the maxLength to 16

34. 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 non-advertised subprefixes covered by a loose ROA

35. 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

36. 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 See details in slide 54.

37. 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?

38. 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

39. 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

40. Obstacles to Deployment: Inter-Organization Dependencies
Upward dependencies:
Level 3 Communications did not obtain an RC. Consequently, its customers cannot obtain an RC

41. Obstacles to Deployment: Inter-Organization Dependencies
Good news: Not many organizations are upward-dependent

42. Obstacles to Deployment: Inter-Organization Dependencies
Downward dependencies:
Orange issued a ROA which renders
routes to other organizations invalid

43. Obstacles to Deployment: Inter-Organization Dependencies
Good news: Only a handful of prefixes are downward dependent

44. 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

45. 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

46. Three Obstacles to RPKI adoption
Insufficient value
Justified mistrust
Inter-organizational dependencies

47. Generating Value Incentivize ROV adoption by the top ISPs!
Both sufficient and necessary for significant security benefits.

48. Building Trust: ROAlert
roalert.org allows you to check whether your network is properly protected by ROAs
… and if not, why not

49. 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! ³

50. Building Trust: ROAlert

51. Building Trust: ROAlert
Unlike existing systems :
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 4

52. 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]

53. Thank You!
This work will also appear at NDSS’17 Tech report at Questions? 

54. 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

55. Survey Participants What is your role? `Which of the following
best describes your network?’’

56. Survey Participants How many IP addresses does your network include?
Where is your network?’
Does your organization
have an AS number?