| Internet-Draft | VRP Aggregation | August 2024 |
| Zhang, et al. | Expires 1 March 2025 | [Page] |
Resource Public Key Infrastructure (RPKI) enables address space holders to issue Route Origin Authorization (ROA) objects to authorize one or more Autonomous Systems (ASes) to originate BGP routes for specific IP address prefixes. Individual BGP speakers can utilize Validated ROA Payloads (VRPs) to validate the legitimacy of BGP announcements. This document highlights potential validation errors, and recommends extension of VRPs from reasonable aggregation to enhance Route Origin Validation (ROV) and prevent validation errors that may occur due to traffic engineering or route aggregation policies.¶
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 1 March 2025.¶
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. 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.¶
In Resource Public Key Infrastructure (RPKI), an address space holder issues a digitally signed object called Route Origin Authorization (ROA) to authorize a specific Autonomous System (AS) to announce BGP routes for one or more IP prefixes within the corresponding address space. The BGP speaker loads validated RPKI ROA objects from the Relying Party (RP) cache into its local storage. The loaded objects are formatted with (prefix, originating AS number, maximum length). These locally stored objects are referred to as "Validated ROA Payload" (VRP), as defined in [RFC6811]. VRPs will be used to validate the origination AS of BGP routes[RFC6483] .¶
However, due to factors such as traffic engineering or route aggregation, the prefixes announced by a BGP route may not be consistent with the prefixes registered in the ROA. Typically, address space holders register specific prefixes in the ROA, while the BGP route announcements may involve aggregated prefixes.¶
This document proposes to extend the original VRPs with new VRPs, which are generated based on aggregation of contiguous prefixes authorized to the same origin AS in original VRPs. VRP aggregation could improve the accuracy of route announcement validation, prevent valid announcements from being erroneously validated as "Invalid" or "Unknown," and avoid unnecessary traffic discarding. Ultimately, this approach aims to improve the practicality and effectiveness of RPKI deployment.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
RPKI is a cryptographic system that enables validation of the origin of route announcements and helps prevent route origin hijacking and other security threats. Typically, if an address space holder does not register a specific prefix in RPKI, it implies that the holder does not authorize an AS to advertise that prefix in routing announcements.¶
However, there are situations where a prefix included in a route announcement may be subject to aggregation or deaggregation due to factors such as traffic engineering or route optimization. As a result, the prefix being advertised might differ from the registered specific prefix in RPKI.¶
In such scenarios, when a route validation process relies solely on RPKI ROAs, it may inaccurately validate the route announcement as "Invalid" or "Unknown". This can happen when the aggregated parent prefix is announced, yet only the pre-aggregation sub-prefixes are registered in the RPKI. Complex routing policies or inaccurate registrations can both lead to similar situations.¶
In this section, we outline a series of typical scenarios that may lead to the validation outcomes being erroneously labeled as "Invalid" or "Unknown". We will explore three potential causes for such inaccuracies associated with aggregated but unregistered prefixes, specifically: route aggregation, traffic engineering (including path redundancy, load balancing, etc.), and issues arising from inaccurate registration.¶
By merging a series of contiguous IP address prefixes into a single less-specific prefix, routing information can be simplified and routing efficiency improved. However, if the AS that performs route aggregation has only been authorized to origin multiple sub-prefixes, the resulting aggregated BGP route announcement, will not be validated as "Valid".¶
+------------------------------------------+
| Announce | 76.191.64.0/18 √ |
(Provider)AS11404 +------------------------------------------+
| | RPKI ROA | 76.191.64.0/18, AS11404, 24 |
| +------------------------------------------+
|
| +----------------------------------------+
| | Announce | 76.191.74.0/23 √ |
| | Announce | 76.191.76.0/22 x |
| +----------------------------------------+
(Customer)AS62915 | | 76.191.74.0/23, AS62915, 24 |
| RPKI ROA | 76.191.76.0/23, AS62915, 24 |
| | 76.191.78.0/23, AS62915, 24 |
+----------------------------------------+
Internet Service Providers (ISPs) might utilize traffic engineering to enhance the network resource utilization, optimize network performance, and ensure Quality of Service (QoS). In this context, operators might announce multiple prefixes with parent-child relationships for the following considerations. If only the sub-prefixes are registered in RPKI, the parent prefix will be unable to be validated.¶
(Provider)AS15412 AS4780 AS4637
\ | /
\ | /
\ | /
\ | /
\ | /+---------------------------------------+
AS17709 | RPKI ROA | 60.244.0.0/16, AS17709, 24 |
| | RPKI ROA | 60.244.0.0/16, AS17709, 17 |
| +---------------------------------------+
|
| +----------------------------------------+
(Customer)AS7482 | RPKI ROA | 60.244.0.0/17, AS7482, 24 |
| RPKI ROA | 60.244.128.0/17, AS7482, 24 |
+----------------------------------------+
+-------------------------------------------------------------------------+
| BGP Route Announcement |
|Stat| Prefix | AS_PATH |
+-------------------------------------------------------------------------+
| √ |60.244.0.0/18|* 4637 17709 7482 |
| √ |60.244.0.0/18|* 4780 17709 17709 17709 7482 |
| x |60.244.0.0/16|* 15412 17709 17709 17709 17709 17709 17709 17709 7482|
+-------------------------------------------------------------------------+
(Provider)AS2914 AS6762 AS6939
\ | /
\ | /
\ | / +-----------------------------------------+
\ | / | | 93.113.148.0/24, AS49367, 24 |
| | 93.113.149.0/24, AS49367, 24 |
(Customer)AS49367 | RPKI ROA | 93.113.150.0/24, AS49367, 24 |
| | 93.113.151.0/24, AS49367, 24 |
+-----------------------------------------+
+------------------------------------------------+
| BGP Route Announcement |
| Status| Prefix | AS_PATH |
+------------------------------------------------+
| √ | 93.113.150.0/24 | * 6939 49367 |
| √ | 93.113.150.0/24 | * 2914 49367 |
| √ | 93.113.150.0/24 | * 6762 49367 |
| o | 93.113.148.0/22 | * 6762 49367 |
+------------------------------------------------+
RPKI is still in the process of incremental deployment; therefore, some prefixes have not yet been registered. Additionally, some ISPs do not maintain consistency between the ROAs registered in RPKI and the prefixes they announce. They may also fail to register the aggregated parent prefix in a timely manner after implementing an aggregation policy, leading to validation issues.¶
To address the problem described above, this document suggests extending VRPs by aggregating contiguous prefixes from the same AS into new VRPs. This section introduces a preliminary algorithm for VRP aggregation and details the implementation process, ensuring the correctness of the newly aggregated VRP.¶
This document suggests extending VRPs by aggregating those that contain contiguous prefixes authorized to the same AS. In this context, "contiguous" refers to IP address ranges that are sequentially contiguous in binary representation. This implies that the IP address spaces represented by the prefixes do not overlap with each other and there are no gaps between them.¶
The content of the ROA identifies that an IP address block holder has authorized an AS to announce routes to one or more prefixes within the address block. If an AS is authorized to several multiple contiguous IP address prefixes, it signifies that the AS can facilitate route reachability for the IP address blocks corresponding to these prefixes. Therefore, if this AS announces a parent prefix that aggregates these contiguous sub-prefixes, the routing to this parent prefix should also be considered accessible and recognized as a "Valid" route announcement.¶
The address holder is often not aware of network routing policies when issuing ROAs. The current RPKI architecture does not provide a mechanism to accommodate these dynamic changes in the registered ROAs. Therefore, this document advocates for the development of specialized extending the aggregated VRP aggregation to address this issue and achieve the aforementioned goal.¶
The fundamental principle of VRP Aggregation is to ensure the correctness of the newly generated prefixes after aggregation. In line with this principle, this document puts forward three rules for VRP aggregation.¶
This document provides two implementation options for VRP aggregation. Operators can make choices based on their specific needs and circumstances.¶
The first option is a data plane solution, which recommends feature extensions for routers. An implementation of the VRP Aggregation on routers is outlined as follows.¶
In the context of VRP aggregation, only the validity state validated as "Valid" by the aggregated VRPs is adopted. This is because the aggregated VRPs only provide certain potential BGP route announcements, indicating that these route announcements are reasonable if they occur. However, it can not validate the state of route announcements originating from other ASes.¶
For example, as shown in Figure 4, the two sub-prefixes authorized to be originated by AS4809 in two ROAs in RPKI could be aggregated in (202.111.192.0/19, AS4809, maxlength=20). However, AS4809 does not announce the parent prefix 202.111.192.0/19; instead, its provider AS4134 does. In this case, the aggregated VRP may cause the route announcement for the parent prefix to be validated as "Invalid" instead of "Unknown". If the router were to reject this route announcement (202.111.192.0/19), it could disrupt the corresponding traffic. Consequently, the validation results from the aggregated VRPs that are validated as "Invalid" are not accepted.¶
+----------------------------------------+
| Announce | 202.111.192.0/19 |
(Provider)AS4134 +----------------------------------------+
|
|
| +-----------------------------------------+
| | Announce | 202.111.192.0/20 |
| | Announce | 202.111.208.0/20 |
| +-----------------------------------------+
(Customer)AS4809 | | 202.111.192.0/20, AS4809, 20 |
| RPKI ROA | 202.111.208.0/20, AS4809, 20 |
+-----------------------------------------+
+-----------------------------------------------+
| Aggregated VRP | 202.111.192.0/19, AS4809, 20 |
+-----------------------------------------------+
The second option is a control plane solution, which requires distributing the routing table to the RP to determine the aggregated VRP used in Route Origin Validation (ROV). An implementation of the VRP Aggregation on relying party (RP) is outlined as follows.¶
Similar to the implementation scheme on routers, for the prefixes represented by the aggregated VRP, only the prefixes that match the routes in the routing table will be delivered to the router. Unlike the implementation scheme on routers, in the case of MOAS, the newly added VRP may validate the matched route as "Valid", while simultaneously validating another route announced by a different AS as "Invalid". In this situation, the owner of the address space needs to proactively authorize the prefix to all the ASes to avoid this issue.¶
The usage of aggregated VRP is different from the original VRP. The aggregated VRPs serve as a retrospective correction mechanism that supplements some potentially valid route announcements. If there is a route announcement whose prefix and origin AS match the aggregated VRP, it allows that route announcement to be validated as "Valid". However, the presence of an aggregated VRP does not necessarily mean that the AS will announce the aggregated prefix, nor could it validate any other route announcements that do not match as "Invalid". Consequently, one approach is that routers require modifications to employ the ROV process differently for aggregated VRPs than for the original VRPs. Another approach is that RPs determine which aggregated VRPs can be used to perform ROV, based on the routes on the BGP router in some way, as previously described.¶
In fact, such a situation can be avoided if the address space holders register all of the route announcements they may advertise in RPKI. For instance, AS4134 in Figure 4 could be authorized to originate the prefix 202.111.192.0/19. However, given the current low rate of ROA registration in RPKI, we choose not to adopt the instances where the aggregated VRPs could not validate a route as "Valid", to avoid unnecessary discarding of traffic.¶
TBD.¶
TBD.¶