]> Zhongguancun Laboratory

Beijing China lichen@zgclab.edu.cn

Zhongguancun Laboratory

Beijing China liulb@zgclab.edu.cn

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Zhongguancun Laboratory

Beijing China qinlc@zgclab.edu.cn

Ops SIDR Operations This document defines a "Signed SAVNET-Peering Information" (SiSPI) object, a Cryptographic Message Syntax (CMS) protected content type included in the Resource Public Key Infrastructure (RPKI). A SiSPI object is a digitally signed object which carries the list of Autonomous Systems (ASes) deploying inter-domain SAVNET. When validated, the eContent of a SiSPI object confirms that the holder of the listed ASN produces the object and the AS has deployed inter-domain SAV and is ready to establish neighbor relationship for preventing source address spoofing.

Introduction Attacks based on source IP address spoofing, such as reflective DDoS and flooding attacks, continue to present significant challenges to Internet security. Mitigating these attacks in inter-domain networks requires effective source address validation (SAV). While BCP84 offers some SAV solutions, such as ACL-based ingress filtering and uRPF-based mechanisms, existing inter-domain SAV mechanisms have limitations in terms of validation accuracy and operational overhead in different scenarios . Inter-domain SAVNET proposes to exchange SAV-specific information among ASes to solve the problems of existing inter-domain SAV mechanisms. Two SAV-specific information exchanging protocols (or SAVNET protocols for short) are shown to achieve higher validation accuracy and lower operational overhead in large-scale emulations . However, operators face significant difficulties in deploying SAVNET protocols. To benefit Internet routing, supporting incremental deployment is an essential requirement of SAVNET protocols . As illustrated in the Section 9.2 of , during the partial or incremental deployment of SAVNET protocols, protocol-speaking agents (or SAVNET agents) within the SAVNET-adopting ASes need to find and establish connections with other SAVNET agents. Currently, there is no mechanism to achieve this automatically, and operators of SAVNET-adopting ASes must configure peering SAVNET relationship by hand, which is slow and error-prone. The neighbor discovery and connection setup process of SAV protocols can be done in an automatic and correct manner, with the introduction of a public registry that contains all ASes which both deploy SAVNET and are willing to setup SAVNET peering relationships. A newly adopting AS can use this registry as a reference, and pick appropriate ASes to setup SAVNET peering relationship. The Resource Public Key Infrastructure (RPKI) is the most suitable to host this public registry, because the primary purpose of RPKI is to improve routing security , and defending against address spoofing is a main aspect of routing security. To this end, a mechanism is needed to facilitate holders of Automous System (AS) identifiers to declare their deployment of SAVNET . The digitally Signed SAVNET-Peering Information (SiSPI) object described in this document serves the function. A SiSPI object is a cryptographically verifiable attestation signed by the holder of an AS identifier. It contains the identification information of one AS, which means the listed AS has deployed SAVNET and can perform SAV on its data plane. The SiSPI object makes use of the template for RPKI digitally signed objects , which defines a Crytopgraphic Message Syntax (CMS) wrapper for the SiSPI content as well as a generic validation procedure for RPKI signed objects. In accordance with Section 4 of , this document defines:

1. The object identifier (OID) that identifies the SiSPI object. This OID appears in the eContentType field of the enCapContentInfo object as well as the content-type signed attribute within the signerInfo structure.
2. The ASN.1 syntax for the SiSPI eContent, which is the payload that specifies the AS deploying SAVNET. The SiSPI eContent is encoded using the ASN.1 Distinguished Encoding Rules (DER) .
3. The steps required to validate a SiSPI beyond the validation steps specified in .

Terminology This document makes use of the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" , "X.509 Extensions for IP Address and AS Identifiers" , "Signed Object Template for the Resource Public Key Infrastructure (RPKI)" , and "A Profile for X.509 PKIX Resource Certificates" . The readers should be familiar with the terms and concepts.

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 SiSPI Content Type The content-type for a SiSPI object is defined as SAVNETAuthz, which has the numerical value of 1.2.840.113549.1.9.16.1.52 (suggested). This OID MUST appear both within the eContentType in the encapContentInfo structure as well as the content-type signed attribute within the signerInfo structure (see ).

The SiSPI eContent The content of a SiSPI object identifies a single AS that has deployed SAVNET for inter-domain SAV. The eContent of a SiSPI object is an instance of SAVNETAttestation, formally defined by the following ASN.1 module: Note that this content appears as the eContent within the encapContentInfo as specified in .

version The version number of the SAVNETAttestation that compiles with this specification MUST be 2 and MUST be explicitly encoded.

asID The asID field contains the AS number that has deployed SAVNET and can perform SAV on the data plane.

addresses The addresses field contains a SEQUENCE of IPFamilyAddresses, which stores the router's IP addresses within the AS whose ID is asID, which is utilized for establishing SAVNET connections.

Element IPFamilyAddresses This field contains a SEQUENCE which contains one instance of IPFamily and one instance of IPAddresses.

IPFamily This field contains an OCTET STRING which is either '0001'H (IPv4) or '0002'H (IPv6).

IPAddresses This field contains a SEQUENCE of ipAddress instances.

Element ipAddress This element is length bounded through the Information Object Class ADDRESS-FAMILY and its type is a BIT STRING.

SiSPI Validation Before, a relying party can use a SiSPI object to validate a routing announcement, the relying party MUST first validate the SiSPI object. To validate a SiSPI object, the relying party MUST perform all the validation checks specified in as well as the following additional specific validation steps of the Signed AS List.

• The AS Identifier Delegation Extension MUST be present in the end-entity (EE) certificate (contained within the SiSPI object), and the asID in the SiSPI object eContent MUST be contained within the set of AS numbers specified by the EE certificate's AS Identifier Delegation Extension.
• The EE certificate's AS Identifier Delegation Extension MUST NOT contain any ''inherit'' elements.
• The IP Address Delegation Extension MUST be absent.

The pseudocode for SiSPI validation is as follows:

IANA Considerations

RPKI Signed Object Registry Please add an item for the SiSPI object file extension to the RPKI Signed Object registry (https://www.iana.org/assignments/rpki/rpki.xhtml#signed-objects) as follows:

RPKI Repository Name Scheme Registry Please add an item for the SiSPI object file extension to the "RPKI Repository Name Scheme" registry created by as follows:

Media Type Registry The IANA is requested to register the media type application/rpki-sispi in the "Media Type" registry as follows: Intended usage: COMMON Restrictions on usage: None Change controller: IETF ]]>

Using SiSPI A router can use the AS_Path from BGP announcements, ASPA objects, and SiSPI to find the closest ASes to set up SAVNET peering, as described below:

1. BGP AS_Paths Analysis:
   • Collect AS paths from BGP announcements.
   • Determine the frequency or preference of certain AS paths based on routing policies, which may involve path attributes like AS path length, origin type, local preference, and MED (Multi-Exit Discriminator).
2. ASPA Verification:
   • Use ASPA objects to verify the legitimacy of customer-provider AS relationships.
   • Ensure that the AS paths conform to the customer-provider relationships indicated by the ASPAs, thereby validating the correctness of the routing information.
3. Peering Candidates Determination:
   • Identify the ASes that frequently appear on the preferred paths to various destinations, implying they are topologically 'close' or significant transit providers.
   • Among these ASes, rank those according to their frequency in an descending order, since the frequency indicates the weight of traffic from the local AS and higher frequency represents more volume of traffic to transmit for the local AS.
4. SiSPI Objects Utilization:
   • Retrieve SiSPI objects from the RPKI repository to determine which ASes have deployed SAVNET.
   • Filter the previously identified candidate ASes by checking whether they have a valid SiSPI object, which would indicate their readiness to establish SAVNET peering.
5. Peering Candidates Selection:
   • From the set of candidate ASes with valid SiSPI objects, select candidates for SAVNET peering based on their rankings.
   • The selection criteria may include additional factors such as existing peering policies, traffic volumes, and peering agreements.
6. Peering Establishment:
   • Initiate peering negotiations with the selected candidate ASes.
   • Upon successful negotiation, establish SAVNET peering relationships and configure the necessary SAVNET protocols.

Based on the above steps, a description of the detailed procedure to establish SAVNET peering relationships is as follows:

1. Let the set of selected AS paths to all the potential destinations be denoted as ASPaths.
2. Let i = 1. Validate ASPaths(i) using ASPA objects.
3. Let the set of validated AS paths be denoted as ASPaths-V.
4. If ASPaths(i) passes the validation of ASPA objects, add it to ASPaths-V.
5. Increment i to i+1.
6. If ASPaths(i) is null, then set i_max = i - 1 and go to Step 7. Else, go to Step 4.
7. Let j = 1 and k = 1. Initialize AS-set S(1) = ASPaths-V(1)(1) and N(ASPaths-V(1)(1)) = 1.
8. If ASPaths-V(j)(k) belongs to S, N(ASPaths-V(j)(k)) = N(ASPaths-V(j)(k)) + 1. Else, N(ASPaths-V(j)(k)) = 1 and S(J * k) = ASPaths-V(j)(k).
9. Increment k to k+1.
10. If ASPaths-V(j)(k) is null, then go to Step 11. Else, go to Step 8.
11. Increment j to j+1.
12. If ASPaths-V(j)(k) is null, then go to Step 13. Else, go to Step 8.
13. Rank the AS-set N according to its values in descending order.
14. Retrieve SiSPI objects from the RPKI repository and let the set of ASes within the SiSPI objects be denoted as O.
15. Let m = 1. Create a SAVNET neighbor candidate set C.
16. If N(m) belongs to O, add N(1) to C.
17. Increate m to m + 1.
18. If N(m) is null or the number of ASes in set C exceeds 4000, go to Step 19. Else, go to Step 16.
19. Establish SAVNET peering relationship with the selected candidate ASes in set C.

Newly SAVNET-adopting ASes The newly SAVNET-adopting ASes need to register the SiSPI object proactively to help other SAVNET-adopting ASes find it and establish SAVNET peering relationships, as well as using the SiSPI objects to establish SAVNET peering relationships with other SAVNET-adopting ASes. To register the SiSPI object, the newly SAVNET-adopting ASes should share its information as described in . To establish SAVNET peering relationships with other SAVNET-adopting ASes, the newly SAVNET-adopting ASes should collect BGP announcements, ASPA objects, and SiSPI objects, and run the procedures described in .

Security Considerations The security considerations of , , and also apply to the SiSPI object.

References Normative References BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK] This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK] This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References