Skip to main content

Publishing boundaries for IPv6 reputation
draft-levine-6man-repsize-00

Document Type Active Internet-Draft (individual)
Author John R. Levine
Last updated 2024-10-14
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-levine-6man-repsize-00
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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

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,
              <https://www.rfc-editor.org/info/rfc4180>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952,
              DOI 10.17487/RFC5952, August 2010,
              <https://www.rfc-editor.org/info/rfc5952>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9632]  Bush, R., Candela, M., Kumari, W., and R. Housley,
              "Finding and Using Geofeed Data", RFC 9632,
              DOI 10.17487/RFC9632, August 2024,
              <https://www.rfc-editor.org/info/rfc9632>.

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,
              <https://www.rfc-editor.org/info/rfc2622>.

   [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,
              <https://www.rfc-editor.org/info/rfc4012>.

Author's Address

   John Levine
   Standcore LLC
   Email: standards@standcore.com

Levine                    Expires 17 April 2025                 [Page 5]