Issue in Route Origin Validation from Route Partial Visibility
draft-wang-sidrops-route-partial-visibility-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Shuhe Wang , Ke Xu , Qi Li , Zhuotao Liu | ||
| Last updated | 2024-10-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-sidrops-route-partial-visibility-00
SIDROPS S. Wang
Internet-Draft Beijing Zhongguancun Laboratory
Intended status: Informational K. Xu
Expires: 23 April 2025 Q. Li
Z. Liu
Beijing Zhongguancun Laboratory and Tsinghua University
20 October 2024
Issue in Route Origin Validation from Route Partial Visibility
draft-wang-sidrops-route-partial-visibility-00
Abstract
In the Resource Public Key Infrastructure (RPKI), validating prefix-
origin pairs using Route Origin Authorizations (ROAs) globally and
performing Route Origin Validation (ROV) locally at each Autonomous
System (AS) with validated ROA payloads (VRPs) can lead to
inconsistent results due to partial route visibility. This document
highlights how partial route visibility can turn originally non-loose
ROAs into loose VRPs, outlines the causes of partial route
visibility, and discusses potential solutions to mitigate the issue.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Wang, et al. Expires 23 April 2025 [Page 1]
Internet-Draft ROV Issue from Route Partial Visibility October 2024
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Vulnerabilities of Loose ROAs . . . . . . . . . . . . . . 3
3.2. Refined Definitions for Loose ROAs and VRPs . . . . . . . 4
3.3. Route Partial Visibility . . . . . . . . . . . . . . . . 5
4. Causes of Route Partial Visibility . . . . . . . . . . . . . 6
4.1. Explicit Route Filtering . . . . . . . . . . . . . . . . 6
4.2. Implicit Route Filtering . . . . . . . . . . . . . . . . 6
4.3. Route De-aggregation . . . . . . . . . . . . . . . . . . 7
4.4. Route Aggregation . . . . . . . . . . . . . . . . . . . . 7
5. Potential Solutions . . . . . . . . . . . . . . . . . . . . . 8
5.1. Report Policies with Hidden Danger . . . . . . . . . . . 8
5.2. Defend Against Attacks Exploiting Loose VRPs . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Route hijacking is a significant vulnerability in the Border Gateway
Protocol (BGP) due to the lack of restrictions on prefix ownership
claims. To combat this, the Resource Public Key Infrastructure
(RPKI) [RFC6482] was introduced to validate prefix-origin pairs.
Prefix owners issue Route Origin Authorizations (ROAs) specifying the
prefix-origin pairs to RPKI repositories. Relying parties (RPs) in
each autonomous system (AS) then download the ROAs, generate
Validated ROA Payloads (VRPs), and distribute them to border routers.
These routers use the VRPs to perform Route Origin Validation (ROV)
[RFC6483][RFC6811].
One might assume that without engineering errors (e.g., issues with
the RPKI repository, RP malfunctions, or ROV execution failures), a
secure ROA would yield a secure VRP. "Secure" means each covered
prefix is protected from route hijacking. However, routes from an
origin AS and their corresponding ROAs travel through different
channels. Routes are distributed via BGP and may be affected by
Wang, et al. Expires 23 April 2025 [Page 2]
Internet-Draft ROV Issue from Route Partial Visibility October 2024
transit AS policies, limiting their global visibility. In contrast,
ROAs are collected in RPKI repositories, accessible to all RPs for
conversion into VRPs. This divergence can lead to inconsistencies
between globally validating routes using ROAs and performing local
ROV with VRPs.
This memo will first address the problem that route partial
visibility could cause inconsistencies in routing security between
using ROAs and VRPs. It will then summarize the possible causes that
could lead to route partial visibility. Finally, the memo will
discuss potential solutions to resolve or mitigate the resulting
vulnerabilities.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Problem Statement
Previous work [RFC9319] has introduced the concept of "looseness" for
ROAs, where not all sub-prefixes of the maximum length allowed by the
ROA are advertised in BGP. For example, in Figure 1, AS 201411
originates two prefixes, B (185.70.140.0/22) and D (185.70.140.0/23),
and issues a ROA (AS 201411, 185.70.140.0/22, 23), marked with
asterisks (*). No other prefixes are announced by any AS. Since
prefix E (185.70.142.0/23) is not announced, the ROA is considered
loose.
+-----------------------------------------------------------------------+
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX A XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX|
*************************************-----------------------------------+
* B=185.70.140.0/22 *XXXXXXXXXXXXXXXX C XXXXXXXXXXXXXXXX|
*-----------------------------------*-----------------------------------+
*D=185.70.140.0/23|XXXXXXX E XXXXXXX*XXXXXXX F XXXXXXX|XXXXXXX G XXXXXXX|
*************************************-----------------------------------+
Figure 1: an example of loose ROA
3.1. Vulnerabilities of Loose ROAs
A sub-prefix S that causes a ROA to be loose faces two primary
vulnerabilities:
Wang, et al. Expires 23 April 2025 [Page 3]
Internet-Draft ROV Issue from Route Partial Visibility October 2024
* Super-prefix Hijacking: An attacker can announce a super-prefix of
S, such as A (185.70.140.0/21) in Figure 1, with the same origin
AS. This route will be validated as "not-found" since its prefix
length is shorter than the ROA's range (22-23) and won't be
filtered. Because prefix E (185.70.142.0/23) is unannounced, the
attack route becomes the best route for addresses in prefix E,
leading to traffic hijacking.
* Forged-Origin Hijacking: An attacker can announce a route with S
and the original AS as the origin but with a fake AS path that
includes the attacker’s AS. This type of hijacking can also
affect non-loose ROAs but is guaranteed to succeed against loose
ROAs. In Figure 1, if an attacker announces prefix E with an AS
path ending in AS 201411, it will be validated as "valid" and
selected as the best route for addresses in prefix E.
Consequently, traffic will follow the attack route into the
attacker's AS, resulting in hijacking.
3.2. Refined Definitions for Loose ROAs and VRPs
The previous definition of loose ROAs misses some corner cases. For
example, in Figure 2, AS 201411 originates two prefixes, D
(185.70.140.0/23) and E (185.70.140.0/23), but issues three ROAs: (AS
201411, 185.70.140.0/22, 22), (AS 201411, 185.70.140.0/23, 23), and
(AS 201411, 185.70.142.0/23, 23). These can be combined into a
single ROA (AS 201411, 185.70.140.0/22, 23). This ROA is not loose
because all its sub-prefixes of the maximum length allowed are
advertised in BGP.
+-----------------------------------------------------------------------+
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX A XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX|
*************************************-----------------------------------+
*XXXXXXXXXXXXXXXX B XXXXXXXXXXXXXXXX*XXXXXXXXXXXXXXXX C XXXXXXXXXXXXXXXX|
*************************************-----------------------------------+
*D=185.70.140.0/23*E=185.70.142.0/23*XXXXXXX F XXXXXXX|XXXXXXX G XXXXXXX|
*************************************-----------------------------------+
Figure 2: an example of non-loose ROAs
To better define ROA looseness, a ROA is non-loose if, for any
address I covered by the ROA R, there exists an advertised route
that:
1. Covers I.
2. Is validated as valid (not necessarily by R).
Wang, et al. Expires 23 April 2025 [Page 4]
Internet-Draft ROV Issue from Route Partial Visibility October 2024
3. Has the longest prefix length among advertised routes whose
prefixes cover I.
4. Has a prefix length greater than or equal to R’s MaxLength (Lm).
If these conditions are not met, the ROA R is considered loose.
Since VRPs are derived from ROAs, we can define "loose VRPs"
similarly to "loose ROAs." The main difference is that for VRPs,
"the route should be advertised" changes to "the route should be in
the router’s local RIB" (Routing Information Base). This is because
ROAs apply to globally announced routes, while VRPs are used within
each AS and validate locally received routes. Therefore, only routes
visible to the local router determine VRP looseness.
Thus, we define a VRP as non-loose if, for any address I covered by
the VRP V on a border router, there always exists a route in the
router's local RIB that:
1. Covers I.
2. Is validated as valid (not necessarily by V).
3. Has the longest prefix length among all routes in the local RIB
whose prefixes cover I.
4. Has a prefix length greater than or equal to V’s MaxLength (Lm).
If these conditions are not met, the VRP V is considered loose.
3.3. Route Partial Visibility
In theory, the origin AS can control its own ROA issuance to ensure
consistency with its advertised routes but cannot ensure other ASes
will receive these routes precisely. A route initially announced may
fail to propagate to another AS. If this route's prefix is a sub-
prefix within the maximum length allowed by the origin AS's ROA, the
resulting VRP at the observer AS will be loose. We term this
phenomenon, where a route announced with a ROA is not visible to all
ASes, as route partial visibility.
In conclusion, a key issue with ROV is that non-loose ROAs don't
always produce non-loose VRPs due to the partial visibility of
announced routes.
Wang, et al. Expires 23 April 2025 [Page 5]
Internet-Draft ROV Issue from Route Partial Visibility October 2024
4. Causes of Route Partial Visibility
The general process for the formation of route partial visibility is
outlined as follows. For a given origin AS, it issues ROAs for all
its active and advertised prefixes, ensuring these ROAs are initially
non-loose. "Active" means that neither the prefixes nor their sub-
prefixes are expired or revoked. However, when a route from the
origin AS reaches a transit AS, certain BGP routing policies may
alter it. This could involve dropping the route, or changing its
prefix or origin AS and then propagating the modified route.
If the route is dropped, any AS that does not receive it will likely
have loose VRPs. Even if the route is altered but not dropped, the
VRP at an observer AS may still become loose, since the prefix may no
longer match with the VRP. These transit AS policies, which we term
"policies with hidden danger," inadvertently disrupt RPKI ROV. Below
are possible types of policies that may drop or alter passing routes.
4.1. Explicit Route Filtering
The simplest type of policy is explicit route filtering, including
import/export filtering, route blackholing, route damping, and
similar mechanisms. When a transit AS applies such policies, it
directly drops routes for specific prefixes. As a result, these
prefixes will have no corresponding routes in the downstream ASes of
the transit AS.
4.2. Implicit Route Filtering
When certain policies combine, they can implicitly drop routes.
Consider this scenario in Figure 3: a MOAS prefix is announced by
different ASes (AS a and AS b), with only AS a issuing a ROA for the
prefix. Both routes reach an ROV-disabled AS (AS d), where the route
selection policy retains only one route per prefix. Due to a shorter
AS path, AS d keeps the route from AS b and discards the valid route
from AS a.
This route from AS b continues spreading until it reaches an ROV-
enabled AS (AS e). Since the prefix has a ROA only for AS a, the ROV
policy at AS e marks the route from AS b as invalid and drops it.
Consequently, there will be no route for the MOAS prefix in
downstream ASes.
Wang, et al. Expires 23 April 2025 [Page 6]
Internet-Draft ROV Issue from Route Partial Visibility October 2024
+------+ +------+
| AS a |------| AS c |
+------+ +------+
with ROA |
+------+ +------+ +------+
| AS b |------| AS d |------| AS e |
+------+ +------+ +------+
without ROA ROV-disabled ROV-enabled
Figure 3: an example scenario of implicit route filtering
4.3. Route De-aggregation
In addition to dropping routes, routing policies can also transform
prefixes within routes. One such transformation is route de-
aggregation. In this process, the origin AS remains unchanged, but
the original route is replaced with one or more routes for the sub-
prefixes. If any de-aggregated prefix exceeds the maxLength
specified in its matching VRP, it will be validated as invalid and
get dropped, making the de-aggregation ineffective. Additionally,
the absence of routes for the de-aggregated prefixes can make the VRP
loose.
4.4. Route Aggregation
The opposite transformation is route aggregation. Route aggregation
suppresses the original routes and generates a new route with a
super-prefix encompassing all original prefixes. The ROV status of
the aggregated route can vary:
1. Valid: If the aggregated prefix has a ROA and the origin AS
matches the transit AS performing the aggregation.
2. Not Found: If no ROA exists for the aggregated prefix. For a
successful super-prefix hijack, the attack route must be shorter
than all original prefixes but not shorter than the aggregated
prefix.
3. Invalid: If another ROA exists for a different origin AS for the
aggregated prefix or any super-prefix of it, causing the
aggregated route to be filtered and the aggregation to fail.
Additionally, the absence of routes for the de-aggregated prefix
may contribute to VRP looseness.
Wang, et al. Expires 23 April 2025 [Page 7]
Internet-Draft ROV Issue from Route Partial Visibility October 2024
5. Potential Solutions
Since there is no prior work formally addressing the problem, no
solutions exist to systematically eliminate the issue in ROV with
route partially visibility. Generally, there are two main approaches
to address the problem: one is to eliminate potential risks by
addressing policies with hidden dangers, and the other is to defend
against damages when attacks occur due to these policies.
5.1. Report Policies with Hidden Danger
To resolve the issue fundamentally, transit ASes must report policies
with potential hidden dangers. The reporting approach depends on the
policy type:
* Route Filtering: ROAs cannot prevent super-prefix hijacks since an
attacker can always announce a route with a shorter prefix, making
its ROV state "not found." Ideally, the transit AS should inform
all its downstream ASes about the filtered routes, allowing them
to inspect overlapping prefixes in their received routes.
* Route Transformation (Aggregation or De-aggregation): The transit
AS should notify the origin ASes. For de-aggregation, origin ASes
should issue additional ROAs for the de-aggregated prefixes. For
aggregation, the transit AS should additionally obtain permissions
from all origin ASes to announce a ROA itself for the aggregated
prefix.
Implementing this proposal is challenging for several reasons.
First, transit ASes may be reluctant to disclose routing policies for
security reasons and see no benefit, as their own policies do not
affect them negatively. Second, malicious transit ASes might provide
false information about their policies. Additionally, other ASes may
be unwilling to adjust their routing policies or ROAs based on claims
from another AS.
5.2. Defend Against Attacks Exploiting Loose VRPs
A more practical approach is to let each observer AS handle the
defense, without involving the transit AS. While observer ASes may
not know which routes are partially visible to them, they can still
defend against potential forged-origin and super-prefix hijacks.
There are already many recent studies focusing on defending forged-
origin hijacks, and their main idea is combining the AS path feature
and validating the AS path of received routes, such as using ASPA
[I-D.ietf-sidrops-aspa-verification].
Wang, et al. Expires 23 April 2025 [Page 8]
Internet-Draft ROV Issue from Route Partial Visibility October 2024
For super-prefix hijacks, solutions fall into two categories:
* At the RPKI Level: Observer ASes can independently add, delete, or
modify local VRPs using techniques such as SLURM [RFC8416], which
is effective for route transformations.
* At the BGP Level: Observer ASes can add blocking rules or make
blackhole announcements for routes that could trigger super-prefix
hijacks, which is suitable for route filtering.
In summary, defending against the vulnerabilities of loose VRPs
requires systematic efforts.
6. Security Considerations
There is no security consideration in this draft.
7. IANA Considerations
There is no IANA consideration in this draft.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route
Origination Using the Resource Certificate Public Key
Infrastructure (PKI) and Route Origin Authorizations
(ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
<https://www.rfc-editor.org/info/rfc6483>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2012,
<https://www.rfc-editor.org/info/rfc6811>.
8.2. Informative References
Wang, et al. Expires 23 April 2025 [Page 9]
Internet-Draft ROV Issue from Route Partial Visibility October 2024
[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
Local Internet Number Resource Management with the RPKI
(SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
<https://www.rfc-editor.org/info/rfc8416>.
[RFC9319] Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B.
Maddison, "The Use of maxLength in the Resource Public Key
Infrastructure (RPKI)", RFC 9319, DOI 10.17487/RFC9319,
January 2012, <https://www.rfc-editor.org/info/rfc9319>.
[I-D.ietf-sidrops-aspa-verification]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
J., and K. Sriram, "BGP AS_PATH Verification Based on
Autonomous System Provider Authorization (ASPA) Objects",
Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
verification-19, 27 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-verification-19>.
Authors' Addresses
Shuhe Wang
Beijing Zhongguancun Laboratory
Building 8, CourtYard 1, Zhongguancun East Road, Haidian District
Beijing
China
Email: wangsh@mail.zgclab.edu.cn
Ke Xu
Beijing Zhongguancun Laboratory and Tsinghua University
Beijing
China
Email: xuke@zgclab.edu.cn
Qi Li
Beijing Zhongguancun Laboratory and Tsinghua University
Beijing
China
Email: liqi@zgclab.edu.cn
Zhuotao Liu
Beijing Zhongguancun Laboratory and Tsinghua University
Beijing
China
Email: liuzhuotao@zgclab.edu.cn
Wang, et al. Expires 23 April 2025 [Page 10]