Generating a Letter of Agency to reflect RPKI Validity

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/.¶

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

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

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

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).¶

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

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

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

Appendix B. Example RPKI LOA

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

  [email protected]

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

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

  [email protected]

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

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