SIDR Operations L. Chen Internet-Draft L. Liu Intended status: Standards Track Zhongguancun Laboratory Expires: 25 August 2024 D. Li L. Qin Tsinghua University 22 February 2024 A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET draft-chen-sidrops-sispi-00 Abstract 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. 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 25 August 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires 25 August 2024 [Page 1] Internet-Draft Signed SAVNET-Peering Information February 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. The SiSPI Content Type . . . . . . . . . . . . . . . . . . . 4 3. The SiSPI eContent . . . . . . . . . . . . . . . . . . . . . 4 3.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. asID . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. IPAddress . . . . . . . . . . . . . . . . . . . . . . . . 5 4. SiSPI Validation . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1. RPKI Signed Object Registry . . . . . . . . . . . . . . . 6 5.2. RPKI Repository Name Scheme Registry . . . . . . . . . . 7 5.3. Media Type Registry . . . . . . . . . . . . . . . . . . . 7 6. Using SiSPI . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. 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 [RFC3704] [RFC8704] 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-ps]. Inter-domain SAVNET [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 [emu-9-savs]. However, operators face significant Chen, et al. Expires 25 August 2024 [Page 2] Internet-Draft Signed SAVNET-Peering Information February 2024 difficulties in deploying SAVNET protocols. To benefit Internet routing, supporting incremental deployment is an essential requirement of SAVNET protocols [inter-domain-ps]. As illustrated in the Section 8 of [savnet], 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 [RFC6480], 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 [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 [RFC6488], which defines a Crytopgraphic Message Syntax (CMS) [RFC5652] wrapper for the SiSPI content as well as a generic validation procedure for RPKI signed objects. In accordance with Section 4 of [RFC6488], 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) [X.690]. Chen, et al. Expires 25 August 2024 [Page 3] Internet-Draft Signed SAVNET-Peering Information February 2024 3. The steps required to validate a SiSPI beyond the validation steps specified in [RFC6488]. 1.1. 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" [RFC5280], "X.509 Extensions for IP Address and AS Identifiers" [RFC3779], "Signed Object Template for the Resource Public Key Infrastructure (RPKI)" [RFC6488], and "A Profile for X.509 PKIX Resource Certificates" [RFC6487]. The readers should be familiar with the terms and concepts. 1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. 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. 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 [RFC6488]). 3. The SiSPI eContent The content of a SiSPI object identifies a single AS that has deployed SAVNET [savnet] for inter-domain SAV. The eContent of a SiSPI object is an instance of SAVNETAttestation, formally defined by the following ASN.1 [X.680] module: SAVNETAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, asID ASID, address IPAddress } ASID ::= INTEGER (0..4294967295) IPAddress ::= BIT STRING Note that this content appears as the eContent within the encapContentInfo as specified in [RFC6488]. Chen, et al. Expires 25 August 2024 [Page 4] Internet-Draft Signed SAVNET-Peering Information February 2024 3.1. version The version number of the SAVNETAttestation that compiles with this specification MUST be 2 and MUST be explicitly encoded. 3.2. asID The asID field contains the AS number that has deployed SAVNET and can perform SAV on the data plane. 3.3. IPAddress The IPAddress field stores the router's IP address within the AS whose ID is asID, which is utilized for establishing SAVNET connections. 4. 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 [RFC6488] as well as the following additional specific validation steps of the Signed AS List. * The AS Identifier Delegation Extension [RFC3779] 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 [RFC3779] MUST be absent. The pseudocode for SiSPI validation is as follows: function ValidateSiSPI(sispiObject, eeCertificate): // Step 1: Validate the SiSPI object using the generic RPKI // validation procedure. // This includes checking the CMS wrapper, signature, and // certification path. if not IsValidRPKISignedObject(sispiObject): return False, "Invalid RPKI Signed Object" // Step 2: Check the content-type of the SiSPI object. if not sispiObject.eContentType == SAVNETAuthzOID: return False, "Invalid content-type" Chen, et al. Expires 25 August 2024 [Page 5] Internet-Draft Signed SAVNET-Peering Information February 2024 // Step 3: Parse the eContent of the SiSPI object as // SAVNETAttestation. sispiContent = ParseSAVNETAttestation(sispiObject.eContent) if sispiContent is None: return False, "Unable to parse SAVNETAttestation" // Step 4: Ensure the version number is explicitly set to 2. if not (sispiContent.version exists and sispiContent.version==2): return False, "Invalid version" // Step 5: Validate the AS Identifier Delegation Extension in // the EE certificate. if not ValidateASIdExt(eeCertificate, sispiContent.asID): return False, "AS Identifier Extension validation failed" // Step 6: Ensure the EE certificate's AS Identifier Delegation // Extension does not contain 'inherit'. if "inherit" in eeCertificate.asIdentifiers: return False, "AS Identifier Delegation Extension contains 'inherit'" // Step 7: Ensure the IP Address Delegation Extension is absent. if HasIPAddressDelegationExtension(eeCertificate): return False, "IP Address Delegation Extension is present" // Step 8: Determine if all validation checks are successful. return True, "SiSPI object is valid" function ValidateASIdentifierExtension(eeCertificate, asID): // Check if the asID is within the set of AS numbers // specified by the AS Identifier Delegation Extension. return asID in eeCertificate.asIdentifiers function HasIPAddressDelegationExtension(eeCertificate): // Check for the presence of the IP Address Delegation // Extension. return "ipAddresses" in eeCertificate.extensions 5. IANA Considerations 5.1. 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: Chen, et al. Expires 25 August 2024 [Page 6] Internet-Draft Signed SAVNET-Peering Information February 2024 Name | OID --------------------------------------------- Signed SAVNET-Peering Information | 1.2.840.113549.1.9.16.1.52 5.2. RPKI Repository Name Scheme Registry Please add an item for the SiSPI object file extension to the "RPKI Repository Name Scheme" registry created by [RFC6481] as follows: Filename Extension | RPKI Object | Reference ------------------------------------------------------------------------ .sav | Signed SAVNET-Peering Information | draft-chen-sidrops-sispi 5.3. Media Type Registry The IANA is requested to register the media type application/rpki- sispi in the "Media Type" registry as follows: Type name: application Subtype name: rpki-sispi Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: Carries Signed SAVNET-Peering Information. This media type contains no active content. See Section 4 of draft-chen-sidrops-sispi for further information. Interoperability considerations: None Published specification: draft-chen-sidrops-sispi Applications that use this media type: RPKI operators Additional information: Content: This media type is a signed object, as defined in {{RFC6488}}, which contains a payload of an AS identifer as defined in draft-chen-sidrops-sispi. Magic number(s): None File extension(s): .sav Macintosh file type code(s): Person & email address to contact for further information: Li Chen Intended usage: COMMON Restrictions on usage: None Change controller: IETF 6. 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: Chen, et al. Expires 25 August 2024 [Page 7] Internet-Draft Signed SAVNET-Peering Information February 2024 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 provider-customer AS relationships. * Ensure that the AS paths conform to the provider-customer relationships indicated by the ASPAs, thereby validating the correctness of the routing information. 3. Closest AS 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, prioritize those that have a direct provider-customer relationship with the local AS (as indicated by ASPA objects), since they are potentially the closest peers. 4. SiSPI Objects Utilization: * Retrieve SiSPI objects from the RPKI repository to determine which ASes have deployed SAVNET. * Filter the previously identified closest 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 closest ASes with valid SiSPI objects, select candidates for SAVNET peering. * The selection criteria may include additional factors such as existing peering policies, traffic volumes, and peering agreements. 6. Peering Establishment: Chen, et al. Expires 25 August 2024 [Page 8] Internet-Draft Signed SAVNET-Peering Information February 2024 * Initiate peering negotiations with the selected candidate ASes. * Upon successful negotiation, establish SAVNET peering relationships and configure the necessary SAVNET protocols. 7. Security Considerations The security considerations of [RFC6481], [RFC6485], and [RFC6488] also apply to the SiSPI object. 8. References 8.1. Normative References [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . Chen, et al. Expires 25 August 2024 [Page 9] Internet-Draft Signed SAVNET-Peering Information February 2024 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, DOI 10.17487/RFC6485, February 2012, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [X.690] "Information Technology - ASN.1 encoding rules; Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2021. [X.680] "Information technology - Abstract Syntax Notation One (ASN.1); Specification of basic notation", 2021. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [inter-domain-ps] "Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements", 2023, . [savnet] "Inter-domain Source Address Validation (SAVNET) Architecture", 2023, . Chen, et al. Expires 25 August 2024 [Page 10] Internet-Draft Signed SAVNET-Peering Information February 2024 [emu-9-savs] "Emulations of 9 SAV Mechanisms with SAV Open Playground", 2023, . Authors' Addresses Li Chen Zhongguancun Laboratory Beijing China Email: lichen@zgclab.edu.cn Libin Liu Zhongguancun Laboratory Beijing China Email: liulb@zgclab.edu.cn Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Lancheng Qin Tsinghua University Beijing China Email: qlc19@mails.tsinghua.edu.cn Chen, et al. Expires 25 August 2024 [Page 11]