A Profile for Mapping Origin Authorizations (MOAs)

This document defines security enhancement for the address mapping announcement in multi-domain IPv6-only underlay networks . For IPv4 service delivery in multi-domain IPv6-only network, IPv6 mapping prefixes are configured at the PE devices to identify the location of IPv4 address blocks at the network edge, the mapping between IPv4 address block and IPv6 mapping prefix provides the direction of data forwarding in IPv6 network, the IPv6 mapping prefix is considered as the mapping origin of the IPv4 address block. Prior to transmitting IPv4 service data, the PE at the edge of the IPv6-only network needs to exchange their respective mapping rules in advance, which also includes the correspondence between the IPv4 prefix and the IPv6 mapping prefix. In , PE device distributes the binding relationship between an IPv4 address block and its IPv6 mapping prefix through 4map6 extension of MP-BGP. Based on the mapping data obtained, the ingress PE can statelessly transform the incoming IPv4 packets into IPv6 ones and send them to the correct egress PE. From above it can be seen that the correctness of transmitting IPv4 service data in an IPv6-only network lies on the authenticity of the address mapping relationship. This can be further explained by the case where if an attacker maps an IPv4 address block using a fake IPv6 mapping prefix, IPv4 service data will be sent to the wrong egress PE, resulting in a situation of IPv4 prefix hijacking. In a small-scale controlled network, this problem may not be too serious. However, as the scale of IPv6-only deployment increases and there is interconnection between multiple operators, it is necessary to guarantee the authenticity of mapping relationship. This document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to verify the authenticity of the address binding. RPKI is a security framework by which network owners can validate and secure the critical route update or BGP announcements between public Internet networks [RFC6480]. For the scenario discussed, a new object, namely Mapping Origin Authorization (MOA), under the RPKI framework is defined in this document. MOA is a cryptographically signed binding between an IPv4 address block and its right IPv6 mapping prefix that is allowed to be declared in the announcement of MP-BGP. With this architecture, a legitimate holder of IPv4 address block, e.g. an ISP, can authorizes an IPv6 mapping prefix to map IPv4 address block. A distributed repository system stores and disseminates the data objects that comprise the RPKI, as well as other signed objects necessary for improved mapping data and routing security. When receiving the MOA objects from the relying parties, PE routers can use them for Mapping Origin Validation (MOV) of IPv4 address blocks: verifying and discarding "invalid" address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking.

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 abbreviations and acronyms are used in this document: – CMS: Cryptographic Message Syntax– MOA: Mapping Origin Authorization – MOV: Mapping Origin Validation– MP-BGP:Multiprotocol BGP – PE: Provider Edge– PKI: Public Key Infrastructure – RPKI: Resource Public Key Infrastructure– ROA: Route Origin Authorization

The content-type for a MOA is defined as MappingOriginAuthz and has the numerical value of x.x.xxx.xxxxx.x.x.x.x.xx. This OID MUST appear both within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object (see [RFC6488]).

The content of a MOA identifies a single IPv6 mapping prefix that has been authorized by the address holder to originate mapping and a list of one or more IPv4 prefixes that will be advertised. If the address holder needs to authorize multiple IPv6 mapping prefixes to advertise the same set of IPv4 prefixes, the holder issues multiple MOAs, one per IPv6 mapping prefix. A MOA is formally defined as: MappingOriginAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, MappingPrefix6 MPrefix6, ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF MOAIPAddressFamily } MappingPrefix6 ::= SEQUENCE { Prefix6Length INTEGER, Prefix6 BITSTRING } MOAIPAddressFamily ::= SEQUENCE { addressFamily OCTET STRING (SIZE (2..3)), addresses SEQUENCE (SIZE (1..MAX)) OF MOAIPAddress } MOAIPAddress ::= SEQUENCE { address IPAddress, maxLength INTEGER OPTIONAL } IPAddress ::= BIT STRING Note that this content appears as the eContent within the encapContentInfo (see [RFC6488]).

The version number of the MappingOriginAttestation MUST be xxx.

The MappingPrefix6 field contains the IPv6 Mapping Prefix that is authorized to originate mappings to the given IPv4 prefixes.

The ipAddrBlocks field encodes the set of IPv4 prefixes to which the IPv6 mapping prefix is authorized to originate mappings. Note that the syntax here is more restrictive than that used in the IP address delegation extension defined in . That extension can represent arbitrary address ranges, whereas MOAs need to represent only IPv4 prefixes. Within the MOAIPAddressFamily structure, addressFamily contains the Address Family Identifier (AFI) of an IP address family. For the scenario discussed in this document, only IPv4 address block is allowed to be mapped, therefore, addressFamily MUST be 0001. Within a MOAIPAddress structure, the addresses field represents IPv4 prefixes as a sequence of type IPAddress. (See [RFC3779] for more details). If present, the maxLength MUST be an integer greater than or equal to the length of the accompanying prefix, and less than or equal to the length (in bits) of an IP address in the address family (32 for IPv4). When present, the maxLength specifies the maximum length of the IPv4 prefix that the IPv6 mapping prefix is authorized to advertise. (For example, if the IPv4 prefix is 203.0.113/24 and the maxLength is 26, the IPv6 mapping prefix is authorized to advertise any more specific prefix with a maximum length of 26. In this example, the IPv6 mapping prefix would be authorized to advertise 203.0.113/24, 203.0.113.128/25, or 203.0.113.0/25, but not 203.0.113.0/27.) When the maxLength is not present, the IPv6 mapping prefix is only authorized to advertise the exact prefix specified in the MOA. Note that a valid MOA may contain an IPv4 prefix (within a MOAIPAddress element) that is encompassed by another IPv4 prefix (within a separate MOAIPAddress element). For example, a MOA may contain the prefix 203.0.113/24 with maxLength 26, as well as the prefix 203.0.113.0/28 with maxLength 28. (Such a MOA would authorize the indicated IPv6 mapping prefix to advertise any prefix beginning with 203.0.113 with a minimum length of 24 and a maximum length of 26, as well as the specific prefix 203.0.113.0/28.) Additionally, a MOA MAY contain two MOAIPAddress elements, where the IPv4 prefix is identical in both cases. However, this is NOT RECOMMENDED as, in such a case, the MOAIPAddress with the shorter maxLength grants no additional privileges to the indicated IPv6 mapping prefix and thus can be omitted without changing the meaning of the MOA.

Before a relying party can use a MOA to validate a mapping announcement, the relying party MUST first validate the MOA. To validate a MOA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional MOA-specific validation step. -The IP address delegation extension is present in the end-entity (EE) certificate (contained within the MOA), and each IPv4 prefix(es) in the MOA is contained within the set of IP addresses specified by the EE certificate’s IP address delegation extension.

There is no assumption of confidentiality for the data in a MOA; it is anticipated that MOAs will be stored in repositories that are accessible to all ISPs, and perhaps to all Internet users. There is no explicit authentication associated with a MOA, since the PKI used for MOA validation provides authorization but not authentication. Although the MOA is a signed, application-layer object, there is no intent to convey non-repudiation via a MOA. The purpose of a MOA is to convey authorization for an IPv6 mapping prefix to originate a mapping to the prefix(es) in the MOA. Thus, the integrity of a MOA MUST be established. The MOA specification makes use of the RPKI signed object format; thus, all security considerations in also apply to MOAs. Additionally, the signed object profile uses the CMS signed message format for integrity; thus, MOAs inherit all security considerations associated with that data structure. The right of the MOA signer to authorize the target IPv6 mapping prefix to originate mappings to the prefix(es) is established through use of the address space and IPv6 mapping prefix number PKI described in. Specifically, one MUST verify the signature on the MOA using an X.509 certificate issued under this PKI, and check that the prefix(es) in the ROA match those in the certificate’s address space extension. As mentioned in draft xie-idr-mpbgp-extension-4map6, the 4map6 extension is mainly used for controlled IPv6-only network operated by single or multiple ISPs. In this scenario, as the IPv6 mapping prefix indicates the direction of IPv4 service data transmission in the IPv6-only network, and MOA is used to validate the mapping origin of IPv4 address block, there is no need to use IPv4 ROA for the validation of IPv4 BGP announcements; On the other hand, as the operation of MOA depends on the authenticity of address authorization in the underlying IPv6 network, if the IPv6 address prefix is maliciously originated by an third-party AS, even if the IPv4 address block is legitimately authorized to its corresponding IPv6 mapping prefix, traffic hijacking may occur due to the malicious announcement of the IPv6 mapping prefix. Therefore, it is recommended to also deploy IPv6 ROA validation where MOA is deployed.

With this document, IANA is requested to allocate the code for MOA in the registry of "RPKI Signed Objects". The codes will use this document as the reference.