Greetings,
I am reviewing
draft-ietf-opsawg-prefix-lengths-03
I think this proposal is broadly ready for advancement and I don't
there there are huge problems with the document as is other that the
method for creating authenticated prefixleg data and then autheticating
that prefixlen data is probably onerous.
A couple of notes accumulated while reading.
In IPv4, IP addresses can be blocked at
different prefix levels, such as /24 or /32.
it's more accurate to observe that IPv4 blocklists can leverage variable
length subnet masks from (typically) rir assignment or ISP swip whois
all the way down to individual maximally deaggregated ipv4 addresses
(/32) . The purpose associated with the blocklist may dictate shorter
prefixes, e.g. if the blocklist is identifying residential users,
hosting providers, dynamic pools, geoip regions then subnetting may
track the IPv4 usage.
In IPv6 on the other
hand, blocking at e.g. the /64 level could lead to overblocking
(throwing multiple VMs from different users into the same bucket),
while blocking at the e.g. /128 level would lead to filling up
space in the blocklist pretty quickly. The same applies to
throttling. [I-D.ietf-opsec-ipv6-addressing] recently also raised
this issue.
Other than the general feasibility problem with /128s the problem
doesn't go away at the /64 level. BT (AS856) announces uniformly
2a00:2380::/25 as the prefix containing customer assignment.
deaggregating to the /64 if you believe that is the appriate level then
there are potentially 2^39 entries necessary to render them all.
* Rate limiting/CAPTCHAs: A similar issue arises on the Web, where
"close" prefixes might be thrown together (e.g. in the same /56,
even though the ISP hands out /64s), which leads to people
"jointly" running into rate limits and then either being blocked
from a service or having to solve annoying CAPTCHAs.
I have been exposed to rate limits present at the /48 level also so it's
not facile to assume that such behavior would be limited to prefixes
commonly assigned via prefix delegation.
an example prefix list that is publicly available that has most of these
properties is the apple privacy relay list.
e.g.
https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/
https://mask-api.icloud.com/egress-ip-ranges.csv
3.2. End-site prefix length with CGN
I'm not sure that this section should exclude or simply ommits the
possibiliy that someone would use this mechanism in ipv6.
e.g. using the privacy relay example, this is an https/quic proxy
service not a nat.
2a04:4e41:700::/40,US,US-MA,BOSTON,
we can plausibly describe the order of magnitude number of users
associated with this prefix. moreover one wouldn't specify customer
assignments within the range because there are no direct assignments.
IPs may be doled out at random or there may be a method for allocating
them, which is a good reason to not specify an end site length.
Unfortunately, the RPSL in
some repositories is weakly authenticated at best. An approach where
RPSL was signed per [RFC7909] would be good, except it would have to
be deployed by all RPSL registries, and there is a fair number of
them.
The RADB method of rejecting route objects which would be invalidated by
an existing ROA is potentially helpful. I think the proposed
autheticator method is plausible e.g. I would expect to provide a
somewhat stronger level of auhtetication.
The consumer of prefixlen data SHOULD fetch and process the data
themselves. Importing datasets produced and/or processed by a third-
party places significant trust in the third-party.
the compilation of blocklists is very much one of those considerations
where someone is going to take this data process it and then pass it to
other parties.
the security considerations section should probably suggest routing
registry operators not allow the publication of a inetnum for which no
roa exists.
On 5/3/25 00:43, Benoit Claise wrote:
Hi Joel,
I hope that everything is great with you.
This draft below, which I believe fall under your expertise, will
enter WGLC pretty soon.
Would you have a little bit of time to review it?
Regards, Benoit.
-------- Forwarded Message --------
Subject: [OPSAWG]I-D Action: draft-ietf-opsawg-prefix-lengths-02.txt
Date: Wed, 16 Apr 2025 06:56:16 -0700
From: [email protected]
Reply-To: [email protected]
To: [email protected]
CC: [email protected]
Internet-Draft draft-ietf-opsawg-prefix-lengths-02.txt is now
available. It is
a work item of the Operations and Management Area Working Group
(OPSAWG) WG of
the IETF.
Title: Publishing End-Site Prefix Lengths
Authors: Oliver Gasser
Randy Bush
Massimo Candela
Russ Housley
Name: draft-ietf-opsawg-prefix-lengths-02.txt
Pages: 29
Dates: 2025-04-16
Abstract:
This document specifies how to augment the Routing Policy
Specification Language (RPSL) inetnum: class to refer specifically to
prefixlen comma-separated values (CSV) data files and describes an
optional scheme that uses the Resource Public Key Infrastructure
(RPKI) to authenticate the prefixlen data files.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-prefix-lengths-02
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-prefix-lengths-02
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
