]> Zhongguancun Laboratory

Beijing China liq23@mail.zgclab.edu.cn

Tsinghua University

Beijing China xuke@tsinghua.edu.cn

Tsinghua University

Beijing China zhuotaoliu@tsinghua.edu.cn

Tsinghua University

Beijing China qli01@tsinghua.edu.cn

Tsinghua University

Beijing China jianping@cernet.edu.cn

Operations and Management SIDR Operations This document defines a "Signed MOAS Group", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to authenticate the collective announcement of IP prefixes by Multiple Origin Autonomous System (MOAS). The Signed MOAS Group mainly includes two parts: an IP prefix and a list of Autonomous Systems (ASes) authorized to announce the prefix. At least one of these ASes SHOULD be authorized to announce the prefix by the prefix owner through a Route Origin Authorization (ROA). The validation of a Signed MOAS Group confirms that the authorized ASes and other listed ASes have collectively agreed to announce the prefix, ensuring that the announcement is legitimate, accurate, and mutually authorized.

Introduction This document defines a "Signed MOAS Group", a Cryptographic Message Syntax (CMS) protected content type to carry an IP prefix and a list of Autonomous Systems (ASes) authorized to announce this prefix. The Signed MOAS Group allows multiple ASes to collaboratively and securely announce an IP prefix, supporting scenarios such as business partnerships, traffic engineering, and DDoS protection services. A Signed MOAS Group object mainly consists of two components: an IP prefix and a list of Autonomous Systems (ASes) intended to announce the prefix collaboratively, which allows other RPKI-validating routing entities to audit the collection of announcements from multiple originating AS. At least one AS in the AS list SHOULD be authorized to announce the prefix by the prefix owner through a ROA, which means the IP prefix in the ROA SHOULD match the IP prefix in the Signed MOAS Group and the AS number in the ROA SHOULD appear in the AS list. The object is collectively signed by the listed ASes using a multi-signature technique, and the aggregated global signature is attached to the Signed MOAS Group object, ensuring that the announcement could be legitimately proposed by all participating ASes and is verifiable by any RPKI-validating remote routing entities. When validating a Signed MoasGroup, a relying party (RP) aggregates the public keys of all ASes in the AS list into a single global public key. This global key is then used to verify the multi-signature of the Signed MoasGroup. There are three possible validation outcomes. First, if the Signed MoasGroup is verified and at least one corresponding ROA is found, it is considered valid. Second, if the Signed MoasGroup is verified but no corresponding ROA is found, it is deemed suspicious. Finally, if the Signed MoasGroup fails verification, it is considered invalid. The Signed MOAS Group provides a technical way for securely managing multi-origin AS announcements, offering a robust and flexible solution to handle modern routing requirements. Any prefixes announced by ASes that are not included in a ROA or a validated Signed MOAS Group SHOULD be regarded as invalid, though their handling is subject to local routing policies. The intent is to offer a secure and authenticated method for managing MOAS scenarios, enhancing the overall security and integrity of the routing system. Signed MOAS Group objects follow the Signed Object Template for the RPKI .

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.

Signed MoasGroup eContentType The eContentType for a MoasGroup is defined as id-ct-rpkiSignedMoasGroup, with Object Identifier (OID) 1.2.840.113549.1.9.16.1.TBD. This OID MUST appear within both the eContentType in the encapContentInfo object and the ContentType signed attribute in the signerInfo object (see ).

Signed MoasGroup eContent A MoasGroup is formally defined as follows:

version The version number of the RpkiSignedMoasGroup MUST be 0.

ipAddressPrefix This field contains an IPAddressFamily which contains one instance of addressFamily and one instance of prefix.

asList This field contains the AS numbers that are intended to originate routes to the given IP address prefixes. The AS numbers that are authorized by ROA SHOULD be put in front of other AS numbers. The AS numbers MUST NOT duplicate.

digestAlgorithm The digest algorithm used to create the message digest of the attested digital object. This algorithm MUST be a hashing algorithm defined in .

messageDigest The message digest of the SignedMoasGroupObject using the algorithm specified in the digestAlgorithm field.

attestation The attestation is a CMS detached signature in the SignedData format as defined in . Each AS listed in the asList signs an individual digital signature of the message digest, and one AS aggregates all individual signatures into a global signature, referred to as the attestation.

Issuance of Signed MoasGroup It is highly RECOMMENDED that the AS initiating the Signed MOAS Group object be authorized by the prefix owner via a ROA. This AS, referred to as the authorized AS, then initiates the creation of the Signed MOAS Group object, selects a digest algorithm, and calculates the digest of the Signed MOAS Group object. The authorized AS shares this Signed MOAS Group object with other ASes listed in the object. Each listed AS (including the authorized AS) signs the digest using its private key and returns the signature to the authorized AS. Upon receiving and verifying all individual signatures, the authorized AS aggregates them into a global signature, i.e. the attestation, and attaches it to the Signed MOAS Group object. After that, the prefix owner MAY verify the Signed MOAS Group. Finally, the prefix owner or the authorized AS uploads the Signed MOAS Group to the RPKI repositories for validation and distribution.

Validation of Signed MoasGroup To validate a Signed MoasGroup, the relying party MUST perform all the validation checks specified in . In addition, the RP MUST perform the following validation steps:

1. The contents of the CMS eContent field MUST conform to all of the constraints described in .
2. The RP MUST verify the attestation of the Signed MOAS Group. This process involves two steps: first, aggregating the public keys of all ASes listed in the AS list to form a global public key; second, using this aggregated global public key to verify the attestation attached to the Signed MOAS Group object.
3. The RP MUST check for the existence of a corresponding ROA for the IP prefix in the Signed MOAS Group. The IP prefix in the ROA MUST match the IP prefix in the Signed MOAS Group, and the AS number in the ROA MUST appear in the AS list.

A Signed MOAS Group has three possible validation results. (1) Valid: If the Signed MOAS Group is verified and at least one corresponding ROA is found, it is considered valid. (2) Suspicious: If the Signed MOAS Group is verified but no corresponding ROA is found, the Signed MOAS Group is considered suspicious. (3) Invalid: If the Signed MOAS Group cannot be verified, it is considered invalid.

Operational Considerations To aggregate the signatures efficiently, the Signed MOAS Group SHOULD use BLS Signatures with BLS12-381 elliptic curve . ROA-authorized ASes SHOULD be placed at the beginning of the AS list to improve RP validation efficiency. It is highly RECOMMENDED that the RP only verifies the first AS and the prefix against the ROA. Multiple valid Signed MOAS Group objects may exist for the same IP prefix. However, it is highly RECOMMENDED that an AS participate in only one Signed MOAS Group for a given IP prefix. If changes to the AS list are needed, it is highly RECOMMENDED to revoke the existing Signed MOAS Group and issue a new one.

Security Considerations Despite it is highly RECOMMENDED that a Signed MOAS Group SHOULD be validated by at least one ROA, the data contained in a Signed MOAS Group is still self-asserted by the group of AS holders. This means that the presence of an AS in the Signed MOAS Group does not inherently imply any authority from the IP prefix holder for the AS to originate a route for any prefixes. Such authority is separately conveyed in the RPKI through a ROA.

IANA Considerations

SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) IANA is requested to allocate the following in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry:

Decimal	Description	Reference
TBD	Id-ct-rpkiSignedMoasGroup	draft-li-sidrops-rpki-moasgroup

RPKI Signed Objects IANA is requested to register two OIDs in the "RPKI Signed Objects" registry as follows:

Name	OID	Reference
Signed MoasGroup	1.2.840.113549.1.9.16.1.TBD	draft-li-sidrops-rpki-moasgroup

RPKI Repository Name Schemes IANA is requested to add the Signed MoasGroup file extension to the "RPKI Repository Name Schemes" registry as follows:

Filename Extension	RPKI Object	Reference
.smg	Signed MoasGroup	draft-li-sidrops-rpki-moasgroup

SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) IANA is requested to allocate the following in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:

Decimal	Description	Reference
.TBD	id-mod-rpkiSignedMoasGroup-2024	draft-li-sidrops-rpki-moasgroup

Normative References 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 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 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] To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing. 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 (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. This memo provides information for the Internet community. Mattr Self-Issued Consulting This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key). Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tplooker/draft-ietf-cose-bls-key-representations. 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.

Acknowledgments The authors would like to thank Shenglin Jiang, Yangfei Guo, Xingang Shi, Shuhe Wang, Xiaoliang Wang, Hui Wang, and Di Ma.