Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations

Introduction The Signed Prefix List (SPL) is a Resource Public Key Infrastructure (RPKI) object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) procedure and how it can be combined with ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks, AS forgery, and reduction of attack surface for forged-origin prefix hijacks. An AS forgery occurs when an offending AS illegitimately inserts another AS (victim AS) as the origin in a BGP announcement (prefix may belong to a third party or the offender). A forged-origin prefix hijack occurs when an offending AS makes a BGP announcement with illegitimate insertion of a {prefix, origin AS} tuple that is Valid per ROA-ROV . The various BGP security threats that SPL-ROV helps to address are described in . Operational considerations associated with SPL-ROV are discussed in . The verification procedures described in this document MUST be applied to BGP routes with {AFI, SAFI} combinations {AFI 1 (IPv4), SAFI 1} and {AFI 2 (IPv6), SAFI 1} . The procedures MUST NOT be applied to other address families by default.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

The following list includes the terms used with special meanings and acronyms.

"Route is ineligible": The term has the same meaning as in , i.e., "route is ineligible to be installed in Loc-RIB and will be excluded from the next phase of route selection."
SPL: Signed Prefix List (see ).
VSP: Validated SPL Payload (see ).
ROA: Route Origin Authorization (see ).
ROA-ROV: ROA-based Route Origin Verification (see ).
SPL-ROV: SPL-based Route Origin Verification (see ).
RP: Relying Party (see ).

Signed Prefix List (SPL) and Validated SPL Payload (VSP) The definition and semantics of Signed Prefix List (SPL) are provided in apply here. Additional clarification is that the SPL object does not implicitly permit a more-specific prefix subsumed by a listed IP address prefix to be originated by the subject AS listed in it. For any such more-specific prefix to be permitted by the SPL object, it must be explicitly listed in the list of IP address prefixes. Normally there would be a single valid Signed Prefix List (SPL) object for a given asID . However, if multiple valid SPL objects which contain the same asID exist, then union of the resulting address prefix members forms the complete set of members. The complete set (resulting from a single or multiple SPLs) is locally stored by a Relying Party (RP) or compliant router, and such an object is called the Validated SPL Payload (VSP) for the asID in consideration. For a given asID, there may be only a valid SPL object with zero prefixes listed. By creating such an empty SPL object, the subject AS is declaring that it does not originate any prefixes. For an empty SPL, the corresponding VSP conveys 'Empty' in place of the set of prefixes .

SPLs provide a second means to perform route origin verification (ROV) based upon RPKI data. In this document, we refer to the ROV based upon ROA data as ROA-ROV and the ROV based upon SPL data (algorithm described below) as SPL-ROV. This document makes no changes to the ROA-ROV procedure defined in . The SPL-ROV procedure described below is designed to augment and integrate with the existing ROA-ROV procedures. The ROA-ROV and SPL-ROV procedures produce independent verification results referred to as ROA-ROV-state and SPL-ROV-state, respectively. An eBGP router that conforms to this specification MUST implement both the ROA-ROV and SPL-ROV procedures specified below. For each received BGP route:

Set the ROA-ROV-state = the outcome (NotFound, Valid, or Invalid) of the route origin verification procedure in .
If the route contains an AS_SET, then set the SPL-ROV-state = Invalid and stop.
Else, if the route's origin AS does not have a VSP, then set the SPL-ROV-state = NotFound and stop.
Else, if the route's origin AS's VSP includes the route prefix, then set the SPL-ROV-state = Valid and stop.
Else, set the SPL-ROV-state = Invalid and stop.

The specific configuration of a mitigation policy is at the discretion of the network operator. However, the following mitigation policy is highly recommended. If either the route's SPL-ROV-state or ROA-ROV-state = Invalid (), then the route SHOULD be considered ineligible for route selection (see ) but MUST be kept in the Adj-RIB-In for potential future re-evaluation (see ). To be clear, the above applies when either or both of the two ROV states is (or are) Invalid. Routes with all other combinations of the SPL-ROV and ROA-ROV states (i.e., Valid-Valid, Valid-NotFound, NotFound-Valid, NotFound-NotFound) SHOULD be considered eligible for best path selection and SHOULD get the same preference level relative to each other (assuming other path properties are equal). For visualization purposes, below lists all possible combinations of the ROA-ROV and SPL-ROV states and the associated recommendations for the route's eligibility for path selection.

Index	ROA-ROV-state	SPL-ROV-state	Route Selection
1	Valid	Valid	Eligible
2	Valid	NotFound	Eligible
3	Valid	Invalid	Ineligible
4	NotFound	Valid	Eligible
5	NotFound	NotFound	Eligible
6	NotFound	Invalid	Ineligible
7	Invalid	Valid	Ineligible
8	Invalid	NotFound	Ineligible
9	Invalid	Invalid	Ineligible

The BGP security threats addressed by deploying SPL-ROV together with ROA-ROV () and the mitigation policy () are discussed below.

AS Forgery While Hijacking an ROA-ROV-NotFound Prefix: If AS A creates an SPL, it is protected by SPL-ROV in case an offending AS X inserts AS A as the origin AS and announces a third-party prefix not covered by a ROA.
AS Forgery Together with a Conflicting ROA: A conflicting ROA is one which attests the origination of a prefix from an AS but the AS has not included the specific prefix in its SPL. Consider the scenario in which AS A creates a Signed Prefix List. In this case, AS A is protected by SPL-ROV if an offending AS X inserts AS A as the origin AS and announces a prefix for which AS X holds an RPKI certificate and has signed a conflicting ROA showing AS A as the origin.
AS Accidentally Strips AS_PATH and Mis-Originates Prefixes: An AS learns a route from an eBGP neighbor and announces the prefix to another eBGP neighbor as if it is being originated by it (i.e., strips the received AS_PATH and re-originates the prefix). This can be called a re-origination or mis-origination attack (also see Type 5 route leak in ). This attack has been seen to happen in practice due to malfunctioning route optimizers. It can be mitigated at neighboring ASes by SPL-ROV if the AS in consideration has registered an SPL.
Attack Surface Reduction: Often a prefix owner includes more prefixes and/or more more-specific prefixes (using maxLength or otherwise) in their ROA but has no plans to announce some or many of them. Such overly broad ROAs create a larger attack surface for forged-origin prefix and/or subprefix hijacks (). Creation of an SPL and the deployment of SPL-ROV can reduce this attack surface by effectively restricting the broad set of prefixes announcements authorized by the ROA to the subset of prefixes originated by the origin AS (i.e., prefixes in its VSP).
AS can declare itself "Not Originating Prefixes in the Internet": An SPL can be created with an empty prefix list in it. In doing this, the AS is asserting that it is not originating any prefixes in the Internet. Any route showing this AS as the origin AS is Invalid per SPL-ROV.

Operational Considerations

A prefix owner with a prefix listed in the SPL of an AS may one day decide to split its prefix and announce only a more-specific prefix (subsumed under the prefix) from the AS in consideration. This operation needs to be managed carefully by applying the make-before-break principle. When notified of the intent, the AS must update its SPL to add the more-specific prefix while maintaining the original prefix. However, the updated SPL will take time to propagate to the RPs throughout the Internet. So, the AS must continue to announce the original prefix as well as the more-specific prefix for at least a period greater than the estimated propagation time of the updated SPL. At a later time, the less specific prefix may be removed from the AS's SPL. The prefix owner should be kept informed about the operational procedure so the expectations can be properly managed.

A prefix owner with a new prefix may request the AS operator with an SPL to announce it. The AS operator SHOULD recommend the prefix owner to create a ROA for the new prefix. The AS operator MUST update its SPL to add the new prefix. Ubiquitous BGP propagation of the routes based upon the new prefix cannot be achieved until the updated SPL has propagated to RPs throughout the Internet. AS operators that make such SPL updates may choose to delay announcement of the new prefix to minimize triggering SPL-ROV Invalids at down-path ASes.

A prefix owner may dispute with the originating AS that its prefix has not been included in the AS's SPL. This can happen due to miscommunication or operational errors at the AS. A compliant AS should have appropriate operational processes to avoid such discrepancies and fix any such issues expeditiously.

An AS may have a DoS/DDoS mitigation service provider (MSP) to defend against attacks targeting systems within its originated address space. Such an AS may request the MSP to include the prefixes contracted for the protection service to be included in the MSP AS's SPL. The prefixes under such a contract would be typically more-specific prefixes than the AS's normal announcements. With such an SPL in place, in the event of an attack, the MSP AS can announce the more-specific prefixes for mitigation purposes and they will be Valid per SPL-ROV. It is assumed that appropriate ROAs are also registered in advance so that the announcements are Valid per ROA-ROV as well .

IANA Considerations This document has no IANA considerations.

Security Considerations In the SPL profile specification , it is highly RECOMMENDED that an AS should only maintain one SPL that contains all the prefixes originated or intended to be originated by that AS. If an operator chooses to maintain multiple SPL objects (each with only a subset of the prefixes that could be originated by the AS), then consideration must be given to the risk imposed in scenarios in which an RP might receive some but not all of the SPL objects. Given the semantics of the SPL data as a comprehensive permit list for an AS's BGP originations, receiving some, but not all, SPL data of an AS can result in unintended route filtering and potential loss of reachability.