Internet-Draft expires October 2024
Levine Expires 17 April 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-levine-6man-repsize-00
Published:
Intended Status:
Standards Track
Expires:
Author:
J. Levine
Standcore LLC

Publishing boundaries for IPv6 reputation

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.

Table of Contents

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.

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

  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, , <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, , <https://www.rfc-editor.org/info/rfc3629>.
[RFC4180]
Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) Files", RFC 4180, DOI 10.17487/RFC4180, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc4012>.

Author's Address

John Levine
Standcore LLC