Network Working Group J. Levine Internet-Draft Standcore LLC Intended status: Standards Track 14 October 2024 Expires: 17 April 2025 Publishing boundaries for IPv6 reputation draft-levine-6man-repsize-00 Abstract Applications such as e-mail track the reputation of the hosts that connect to them by IP address. Since the IPv6 address space is so large, a reputation system needs to aggregate the data for the IPs useded by a single entity. This document describes a file format a network operator can use to describe the sizes of the IP prefixes it allocates, for reputation systems to use to determine the aggregation boundaries. It also specifies an addition to the the Routing Policy Specification Language (RPSL) inetnum: class to refer to the location of the boundary file, and a method to sign boundary files. 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 17 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. Levine Expires 17 April 2025 [Page 1] Internet-Draft expires October 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Boundary file format . . . . . . . . . . . . . . . . . . . . 3 3. Authenticating the boundary files . . . . . . . . . . . . . . 3 4. Locating the boundary files . . . . . . . . . . . . . . . . . 3 5. Security considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 8. Informative References . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Applications such as e-mail track the reputation of the hosts that connect to them by IP address. The IPv4 address space is small enough that it is practical to track individual addresses, but the IPv6 address space is far too large for that to be practical. Networks and hosting providers have widely varying allocation policies. Some may allocate a /48 to each customer, while others allocate individual /64's, and some hosting providers put multiple customers in a /64 making the allocation size for those customers in practice /128. This document provides a way for providers to publish a description of their allocation policies, to make it possible to tell reliably where the boundaries between allocations are. 1.1. Requirements Language 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. Levine Expires 17 April 2025 [Page 2] Internet-Draft expires October 2024 2. Boundary file format The boundary file is a sequence of lines of UTF-8 [RFC3629] text. Each line either starts with a '#' character indicating that it is a comment, or is a sequence of comma-separated (CSV) values as described in [RFC4180]. Each CSV line has the form: ip_prefix,prefixsize,allocsize The ip_prefix and prefixsize define a range of IP addresses to which the allocation size applies. The ip_prefix is an IPv6 address [RFC5952]. The prefixsize is a decimal integer in the range 32 to 64, inclusive. The allocsize is a decimal integer in the range 48 to 128, inclusive. It declares the prefix length of each suballocation within that range. Multiple lines can describe nested ranges, in which case the line with the longest prefix applies. Two lines MUST NOT have the same ip_prefix and prefixsize. For example: # allocations in the example network 2001:db8::,32,48 2001:db8:1234::,48,64 In this example, 2001:db8::/32 is allocated in /48 prefixes, except that 2001:db8:1234::/48 is allocated in /64 prefixes. 3. Authenticating the boundary files If desired, a network MAY sign a boundary file using the method described in Section 5 of [RFC9632]. The signature is created and appended to the boundary file in exactly the same way that a signature is created and appended for a geoip file. Clients validate the signatures the same way the validate signatures for geoip files. 4. Locating the boundary files Routing Policy Specification Language (RPSL) is defined in several documents including [RFC2622] and [RFC4012]. This document proposes an update to the inet6num: class to identify the location of boundary files, and a workaround method until RPSL is updated. A new "boundary:" feed attribute would include the URL where the boundary file is located, e.g.: Levine Expires 17 April 2025 [Page 3] Internet-Draft expires October 2024 inet6num: 2001:0db8::/32 boundary: https://www.somenet.example/boundary.csv In the absence of that attribute, the boundary file is described in a remark: attribute including the word "boundary", a space, and the URL, e.g. inet6num: 2001:0db8::/32 remark: boundary https://www.somenet.example/boundary.csv When fetching boundary files, the most specific inet6num: object that has a boundary reference MUST be used. When processing files retrieved in this fashion, clients MUST ignore information for addresses outside the inet6num: range. If the range in the inet6num: range has been subdivided into smaller ranges, clients MUST use information from the smallest range that publishes a boundary file. 5. Security considerations The signature described in Section 3 provides assurance that the contents of the boundary file describes the network's actual policy. In the absence of a signature, RDAP over https followed by https retrieval of the boundary file provide assurance that the data are accurate to the extent that the RPSL database correctly contains the network's information. 6. Acknowledgements This document was informed by discussions with Erik Nygren, Nick Buraglio, and George Michaelson. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . Levine Expires 17 April 2025 [Page 4] Internet-Draft expires October 2024 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- Separated Values (CSV) Files", RFC 4180, DOI 10.17487/RFC4180, October 2005, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9632] Bush, R., Candela, M., Kumari, W., and R. Housley, "Finding and Using Geofeed Data", RFC 9632, DOI 10.17487/RFC9632, August 2024, . 8. Informative References [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, . [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005, . Author's Address John Levine Standcore LLC Email: standards@standcore.com Levine Expires 17 April 2025 [Page 5]