A Profile for Traffic Origin Authorizations (TOAs)

Source Address Validation (SAV) aims to detect and discard data packets that use a spoofed source IP address. The fundamental concept of the current practice is directionality: for data packets using a given source IP address, only those coming from a specific direction are considered legitimate. BCP84 introduces a more structured direction-based logic, i.e., identifying the incoming directions for traffic of a given source AS and determining the source prefix space that the AS is authorized to use. To support such validation, a mechanism is needed to allow entities to verify that an AS has been authorized to originate traffic using one or more prefixes as the source IP address. A Traffic Origin Authorization (TOA) provides this function. The TOA makes use of the template for RPKI digitally signed object , which defines a Cryptographic Message Syntax (CMS) wrapper for a generic validation procedure for RPKI signed objects. Therefore, to complete the specification of the TOA (see Section 4 of ), this document defines: The OID that identifies the signed object as being a TOA. (This OID appears within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object.) The ASN.1 syntax for the TOA eContent. (This is the payload that specifies the ASes being authorized to originate traffic as well as the prefixes that the ASes may use as the source IP address.) The TOA eContent is ASN.1 encoded using the Distinguished Encoding Rules (DER) . Additional steps required to validate TOAs (in addition to the validation steps specified in ). The content of a TOA identifies a list of one or more ASes that have been authorized by the IP address block holder to originate traffic and a list of one or more IP address prefixes within the address block that will be used as the source IP address. The IP address block holder can register one or more TOAs to authorize which ASes can originate traffic using specific prefixes within the block as the source IP address. By registering TOAs, IP address block holders can protect their source IP addresses from being forged by attackers inside unauthorized ASes. ISP or enterprise AS operators can use TOAs to improve the accuracy and robustness of SAV (see Section 6 for details). The TOA and the ROA have the similar format but have different intentions and contents. Prefixes used as the source IP address in traffic (which is contained in TOAs) and prefixes advertised into the routing system (which is contained in ROAs) can be different and asymmetric for the same AS. For example, in the Content Delivery Networks (CDN) and Direct Server Return (DSR) scenario, the AS where the edge server is located does not advertise the anycast prefix but will originate traffic using a source IP address within the anycast prefix (see ).

The content-type for a TOA is defined as id-ct-trafficOriginAuthz and has the numerical value of 1.2.840.113549.1.9.16.1.TBD. This OID MUST appear within both the eContentType in the encapContentInfo object and the content-type signed attribute in the signerInfo object (see ).

The content of a TOA identifies a list of one or more ASes that have been authorized by the address block holder to originate traffic and a list of one or more IP address prefixes within the address block that will be used as the source IP address. A TOA is formally defined as:

The version number of the TrafficOriginAttestation entry MUST be 0.

The asSet element contains a set of AS numbers that are authorized to originate traffic using source IP addresses within the given IP address prefixes.

The ipaddrBlocks element encodes the set of IP address prefixes that the specified set of AS numbers is authorized to use as source addresses when originating traffic.

Within the TOAIPAddressFamily structure, the addressFamily element contains the Address Family Identifier (AFI) of an IP address family. Each addressFamily MUST be either 0001 or 0002. There MUST be only one instance of TOAIPAddressFamily per unique AFI in the TOA. The addresses field contains IP prefixes as a sequence of type TOAIPAddress.

This element is of type BIT STRING and represents a single IP address prefix .

To validate a TOA, the Relying Party (RP) MUST perform all the validation checks specified in as well as the following additional specific validation steps: The IP address delegation extension is present in the end-entity (EE) certificate (contained within the TOA), and every IP address prefix in the TOA payload is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension. The EE certificate's IP address delegation extension MUST NOT contain "inherit" elements as described in . The Autonomous System identifier delegation extension described in is not used in TOAs and MUST NOT be present in the EE certificate. The TOA content fully conforms with all requirements specified in Sections 2 and 3. If any of the above checks fail, the TOA MUST be considered invalid and an error SHOULD be logged.

The security considerations of , , , and also apply to the TOA object.

Without TOAs, current SAV mechanisms (e.g., EFP-uRPF ) typically use BGP data, ROAs, or IRR route objects to determine the legitimate source IP address space of a given AS. However, due to the asymmetry between prefixes used as the source IP address and prefixes advertised into the routing system (as mentioned in Section 1), using BGP data, ROAs, and IRR route objects to perform SAV will have false positives (i.e., blocking legitimate data packets) and false negatives (i.e., permitting spoofing data packets). By using TOAs, SAV can accurately identify whether an AS is authorized to use a specific source IP address to originate traffic. If an AS originates spoofing traffic using a source IP address authorized to other ASes in TOAs, TOA-based SAV can identify and discard this spoofing traffic. Therefore, it is highly recommended to improve the accuracy and robustness upon current SAV by using TOAs.

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-trafficOriginAuthz draft-qin-sidrops-toa

Please add an item for the TOA file extension to the RPKI Signed Object registry (https://www.iana.org/assignments/rpki/rpki.xhtml#signed-objects) as follows: Name OID Reference Traffic Origin Authorization 1.2.840.113549.1.9.16.1.TBD draft-qin-sidrops-toa

Please add an item for the TOA file extension to the "RPKI Repository Name Scheme" registry created by as follows: Filename Extension RPKI Object Reference .toa Traffic Origin Authorization draft-qin-sidrops-toa

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--rpkiTOA-2025 draft-qin-sidrops-toa

The IANA is requested to register the media type application/rpki-toa in the "Media Type" registry as follows:

Intended usage: COMMON Restrictions on usage: None Change controller: IETF]]>