Network Working Group A. Martin Internet-Draft J. Abley Intended status: Best Current Practice Cloudflare Expires: 19 April 2025 16 October 2024 Generating a Letter of Agency to reflect RPKI Validity draft-martin-grow-rpki-generated-loa-00 Abstract 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 This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-martin-grow-rpki-generated- loa/. Discussion of this document takes place on the Global Routing Operations Working Group mailing list (mailto:grow@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/grow/. Subscribe at https://www.ietf.org/mailman/listinfo/grow/. Source for this draft and an issue tracker can be found at https://github.com/ableyjoe/draft-martin-grow-rpki-generated-loa. 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/. Martin & Abley Expires 19 April 2025 [Page 1] Internet-Draft Generating a Letter of Agency to reflect October 2024 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 19 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RPKI Authorisation of Routing Data . . . . . . . . . . . . . 4 3.1. Route Origin Authorization (ROA) Objects . . . . . . . . 4 3.2. Autonomous System Proider Authorization (ASPA) Objects . 4 4. Bring Your Own IP (BYOIP) Considerations . . . . . . . . . . 5 5. Constructing a LOA based on RPKI Validation . . . . . . . . . 5 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Provenance and Validity . . . . . . . . . . . . . . . . . 6 5.3. Route Origination and Service Provider Authorisation . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Letter of Agency . . . . . . . . . . . . . . . . . . 8 Appendix B. Example RPKI LOA . . . . . . . . . . . . . . . . . . 9 B.1. Customer originates a prefix to provider . . . . . . . . 9 B.2. Provider originates customer BYOIP prefix in Dutch . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Martin & Abley Expires 19 April 2025 [Page 2] Internet-Draft Generating a Letter of Agency to reflect October 2024 1. 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 Appendix A. Some limitations of this practice are discussed briefly in Section 6. 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Martin & Abley Expires 19 April 2025 [Page 3] Internet-Draft Generating a Letter of Agency to reflect October 2024 3. 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) [RFC4271]. 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. 3.1. Route Origin Authorization (ROA) Objects ROAs are described in [RFC9582]. 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. 3.2. Autonomous System Proider Authorization (ASPA) Objects ASPAs are described in [I-D.ietf-sidrops-aspa-profile]. 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". Martin & Abley Expires 19 April 2025 [Page 4] Internet-Draft Generating a Letter of Agency to reflect October 2024 4. 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. [RFC9323] 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 Section 3, 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. 5. 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). Martin & Abley Expires 19 April 2025 [Page 5] Internet-Draft Generating a Letter of Agency to reflect October 2024 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. 5.1. 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. 5.2. 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. Martin & Abley Expires 19 April 2025 [Page 6] Internet-Draft Generating a Letter of Agency to reflect October 2024 5.3. 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. 6. 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. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References Martin & Abley Expires 19 April 2025 [Page 7] Internet-Draft Generating a Letter of Agency to reflect October 2024 [I-D.ietf-sidrops-aspa-profile] Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley, R., and B. Maddison, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-18, 25 June 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, May 2024, . 8.2. Informative References [RFC9323] Snijders, J., Harrison, T., and B. Maddison, "A Profile for RPKI Signed Checklists (RSCs)", RFC 9323, DOI 10.17487/RFC9323, November 2022, . Appendix A. 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. Martin & Abley Expires 19 April 2025 [Page 8] Internet-Draft Generating a Letter of Agency to reflect October 2024 Appendix B. Example RPKI LOA B.1. Customer originates a prefix to provider INTRODUCTION This is an RPKI LOA that conforms to (this document). PROVENANCE AND VALIDITY This document was produced by Cloudflare on behalf of a customer at 2024-10-13 15:00 UTC. For more information about this document, please contact Cloudflare as follows: Cloudflare, Inc 101 Townsend Street San Francisco CA 94107 USA rpki@cloudflare.com ROUTE ORIGIN AND SERVICE PROVIDER AUTHORISATION 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. PREFIX ORIGIN AS PROVIDER AS 199.212.90.0/24 9327 13335 199.212.91.0/24 9327 13335 Route origin authorisation can be verified by reference to published signed RPKI objects, as illustrated by the following: https://rpki-validator.ripe.net/ui/199.212.90.0%2F24/9327 https://rpki-validator.ripe.net/ui/199.212.91.0%2F24/9327 B.2. Provider originates customer BYOIP prefix in Dutch Martin & Abley Expires 19 April 2025 [Page 9] Internet-Draft Generating a Letter of Agency to reflect October 2024 INTRODUCTIE This is an RPKI LOA that conforms to (this document). Dit is een RPKI LOA die voldoet aan (dit document). Dit document is in het Nederlands geschreven en is bedoeld voor een publiek dat Nederlands spreekt. Het is van belang dat kernzaken van dit document ook in het Engels geschreven zijn. HERKOMST EN GELDIGHEID Dit document is in opdracht van een klant door Cloudflare geproduceerd om 2024-10-13 15:00 UTC. Voor meer informatie over dit document kunt u contact opnemen met Cloudflare via: Cloudflare, Inc 101 Townsend Street San Francisco CA 94107 USA rpki@cloudflare.com OORSPRONG VAN ROUTES 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. De volgende route-oorsprongen zijn geautoriseerd door de publicatie van RPKI-ondertekende ROA en/of ASPA-objecten. Afhankelijke partijen moeten hun eigen validatie van deze objecten uitvoeren om de details in deze RPKI LOA te bevestigen. PREFIX OORSPRONG AS 199.212.92.0/24 13335 199.212.93.0/24 13335 Route-oorsprong autorisatie kan worden geverifieerd middels verwijzing naar gepubliceerde ondertekende RPKI-objecten, zoals geïllustreerd middels: https://rpki-validator.ripe.net/ui/199.212.92.0%2F24/13335 https://rpki-validator.ripe.net/ui/199.212.93.0%2F24/13335 Martin & Abley Expires 19 April 2025 [Page 10] Internet-Draft Generating a Letter of Agency to reflect October 2024 Acknowledgments Dirk-Jan van Helmond tried valiantly to repair the authors' tremendously poor Dutch in Appendix B.2. 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). Authors' Addresses Algin Martin Cloudflare Email: algin@cloudflare.com Joe Abley Cloudflare Email: jabley@cloudflare.com Martin & Abley Expires 19 April 2025 [Page 11]