]> Cloudflare

algin@cloudflare.com

Cloudflare

jabley@cloudflare.com

RPKI LOA routing Letters of Agency (LOA) are commonly used to authorise network providers to accept and propagate routing information received from others. The Resource Public Key Infrastructure (RPKI) can be used to perform a similar function, with the advantage that RPKI-signed objects can be validated automatically and in a more robust manner than manual processing of documents. However, some network operators have established processes that expect and require LOAs to be exchanged, despite their limitations. This document proposes a format for constructing a LOA in the case where RPKI validation is available, with the goal of enabling a transition to a future where LOAs are no longer needed. About This Document Status information for this document may be found at . Discussion of this document takes place on the Global Routing Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Some organisations use IP addresses that have been assigned or allocated for their use and that are independent of any particular network service provider. For such address space to be reachable on the global Internet, routing information must be proagated from one or more originating autonomous systems and must be received by other adjacent or further distant autonomous systems in order for traffic directed at those addresses to be sent in the right direction. It is best current practice for network operators not to accept routing information from adjacent networks indiscriminately, but rather to filter routing information to ensure that Internet traffic is not routed inappropriately. Network operators are expected to accept routing information selectively, filtering and allowing only route advertisements that they have reason to believe are legitimate. In the case of routing information that is being received directly from a customer network, or is being originated by the network provider on the customer's behalf, such legitimacy has often been determined by the customer issuing a Letter of Agency (LOA), a document that provides authorisation for one operator to act on behalf of another. Such letters are commonly exchanged in the form of electronic documents exchanged over insecure mechanisms like e-mail with no integrity protection or strong authentication. For more discussion about LOAs, see . Some limitations of this practice are discussed briefly in . The RPKI provides an opportunity to provide equivalent authorisation to a Letter of Agency in a form that is independently verifiable and cryptographically strong. However, many network operators have established workflows that include LOAs, and at the time of writing many customers are not practised in the management of RPKI-signed objects. This document describes a template for constructing a Letter of Agency in the case where RPKI verification of a request to exchange routing informationi is possible. We propose that network operators accept such documents, with corresponding crypytographic validation of associated signed objects, in place of a conventional LOA.

Terminology 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.

RPKI Authorisation of Routing Data Suppose a customer requests that a network provide connectivity for their addresses, represented by an IP prefix. The provider is requested to either originate or accept the prefix from the customer's network using the Border Gateway Protocol (BGP) . The prefix will propagate from the provider's network with the AS_PATH attribute "... P+ C*" where P is the provider's Autonomous System Number (ASN), C is the customer's ASN, + denotes one or more repetitions and * denotes zero or more repetitions. For example, a customer with ASN C who advertises prefix A to the provider's ASN P might intend that the prefix propagates to adjacent networks of the provider with the AS_PATH "... P C". A different customer who directs the provider to originate prefix B on their behalf might intend that the prefix propagates to adjacent networks of the provider with the AS_PATH "... P". The RPKI can be used to sign and publish objects that reflect these intentions. The two object types used for this purpose are the Route Origin Authorization (ROA) and Autonomous System Provider Authorization (ASPA) objects.

Route Origin Authorization (ROA) Objects ROAs are described in . A valid ROA provides authorisation for a particular set of prefixes to be originated from a particular ASN. In the examples above, a signed ROA might authorise prefix A to be originated from ASN C, and another signed ROA might authorise prefix B to be originated from ASN P.

Autonomous System Proider Authorization (ASPA) Objects ASPAs are described in . A valid ASPA provides authorization for a particular prefix to propagate along particular edges in a graph of connected autonomous systems. In the examples above, a signed ASPA might authorise prefix A to exhibit the AS_PATH "... P C".

Bring Your Own IP (BYOIP) Considerations Originating routes on behalf of customers has long been a common function of network operators. At the time of writing it is also common for other types of provider, e.g. those that provide services such as content distribution or cloud compute. Such service providers sometimes use the phrase "Bring Your Own IP" (BYOIP) to describe the practice of using customer-supplied addresses to make services available on behalf of those customers. The provider may have many distinct and unrelated customers. A customer who authorises the provider to attach their BYOIP prefixes to their account does not normally authorise the use of those prefixes by other customers. In order to ensure that a particular BYOIP prefix is attached to an account that is authorised to use it, a provider requires further authorisation from the customer. provides a profile for RPKI Signed Checklists (RSCs) which can be used by a resource holder as an attestation. In the case of the examples in , the customer responsible for BYOIP prefix A might sign an attestation that authorises the use of that prefix with their account and make that attestation available to the provider. The attestion might be signed with the ROA or the ASPA associated with prefix A. Similarly, the customer responsible for BYOIP prefix B might sign a checklist authorising using the ROA associated with prefix B. Authorisation of particular BYOIP prefixes to be attached to particular provider accounts is necessarily provider-specific. Other mechanisms are possible. From the perspective of an adjacent network operator, the details of how a service provider manages appropriate safeguards relating to BYOIP are not important, and those details are not generally considered necessary to explain in a LOA.

Constructing a LOA based on RPKI Validation A LOA constructed according to this specification is referred to as an RPKI Letter of Agency (RPKI LOA). An RPKI LOA is intended to be a human-readable representation of validation that can be performed by automated systems. Consequently, there is no benefit in an RPKI LOA being machine-readable. Automatic verification of authorisation to originate or propagate a prefix SHOULD use RPKI-signed objects and perform signature validation directly and SHOULD NOT attempt to process the contents of an RPKI LOA. This document specifies an ordering and a list of details that MUST be included in a LOA for it to be consistent with this specification, but provides few normative requirements for presentation or precise wording. This is intended to provide sufficient consistency for the LOA to be clear and familiar while leaving flexibility for providers to be able to include additional information and adopt a style that suits their particular circumstances. This section describes a number of sections, all of which MUST be included in an RPKI LOA. Some sections specify text to be included verbatim, while other sections describe the information to be included without prescribing particular text. Where this specification requires particular text to be included verbatim, that text MUST be included in English. RPKI LOAs MAY also include translations of that normative text in other languages. All other parts of an RPKI ROA MAY use any languages or scripts. Each of the following sections MUST be separated so that they can easily be distinguished from each other. Each section MAY include a section heading.

Introduction This section MUST begin with the following text, included verbatim: "This is an RPKI LOA that conforms to (this document)." This section MAY also include other introductory information, such as useful external references or information about the resource holder.

Provenance and Validity The name and contact details of the person or organisation issuing the RPKI LOA should be included. The date at which the RPKI LOA was prepared should be included.

Route Origination and Service Provider Authorisation This section MUST begin with the following text, included verbatim: "The following route originations have been authorised by the publication of RPKI-signed ROA and/or ASPA objects. Relying parties should perform their own validation of these objects in order to confirm the details provided in this RPKI LOA." All prefixes that are the subject of the RPKI LOA MUST be included. Each prefix MUST be clearly annotated with the origin ASN and also the provider ASN in the case where the origin AS is not the same as the provider AS. This section MAY include references tools that a reader might use in order to confirm the authorisations described in the document. For example invocation syntax and example output from command-line tools might be included in order to make it easier for a reader to confirm the information described.

Security Considerations LOAs do not provide strong authorisation because it is not straightforward to authenticate their contents. Anecdotally, LOAs are often accepted by unqualified staff without systematic or thorough review. It is not clear that the exchange of LOAs provides useful legal protection to any party in the event that a related subsequent complaint was made. The form of LOA described in this document does not in itself provide stronger authorisation; however, the contents do provide a means by which the recipient of a LOA can obtain a measure of authentication which is cryptographically strong. The recipient of an RPKI LOA who reads and follows the directions within is able to obtain more confidence about the authorised use of IP addresses described within it than with a conventional LOA.

IANA Considerations This document has no IANA actions.

References Normative References 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. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. Yandex JetLend Internet Initiative Japan Fastly Vigil Security, LLC Workonline This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. Informative References This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a general-purpose listing of checksums (a 'checklist'). The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC.

Letter of Agency A Letter of Agency (LOA) is a document used in telecommunications to authorise a provider to act on behalf of a customer. LOAs were originally specified for use in the United States and their use is specified in the Code of Federal Regulations Title 47 / Chapter 1 / Subchapter B / Part 64 / Subpart K, "S 64.1130 Letter of agency form and content". LOAs were subsequently adopted more informally for use between Internet providers in order to document and authorise the use of IP addresses administered by a customer to be made reachable by an Internet Service Provider. The acronym LOA is sometimes taken to mean "Letter of Authorisation" despite its original meaning.

Example RPKI LOA

Customer originates a prefix to provider

Provider originates customer BYOIP prefix in Dutch

Acknowledgments Dirk-Jan van Helmond tried valiantly to repair the authors' tremendously poor Dutch in . Any residual crimes against language are the fault of the authors alone. Lucas Pardue's stylistic recommendations were all implemented with the result that the document is now much more palatable to Lucas Pardue. These fine and wonderful other people also helped with this document (your name goes here).