[address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Tore

Sorry guys but this is a very long email. There is a lot at stake
here. This policy proposal goes way beyond adding a new status value.
It may seem to be only small changes to a couple of paragraphs. But
these changes completely undermine the current IPv4 registration
principles.

You make lots of references to copying wording from the IPv6 policy.
So let me point out one statement in ripe-690, the BCOP referenced in
that policy. One of the first things it says in the Executive Summary
is "IPv6 is not the same as IPv4." You are trying to suggest it is a
simple task to retrofit IPv6 registration policy onto IPv4. It may not
all be possible and even where it is, there may be significant
consequences. You are glossing over some of these consequences. I am
trying to highlight them.

You are portraying this proposal as a simple addition of an optional
construct that would simplify some operations. You are masking the
fact that it removes one of the core principles of current IPv4
registration policy..registering of End User networks using public
address space..which covers most of the internet. That removal can be
applied to the whole dataset, in unpredictable ways, and radically
change the public registry. Maybe some people believe it is the right
change to make now. I don't claim to be an expert in this field.
Personally I don't believe it is. But this is not something that
should be decided by a handful of the small group of people who
determine most policy in this region with a few "+1 great proposal"
comments. A change of this magnitude needs wider consultation.

Now I will answer your points below.

On Fri, 22 Sept 2023 at 10:56, Tore Anderson <tore at fud.no> wrote:
>
> Hi Denis,
> > This is where the implications get interesting. Each of the objects
> > in the example I gave is in itself individually aggregatable. There
> > is nothing in your policy proposal that says an aggregate must cover
> > multiple assignments to multiple End Users. You say:
> > "In case of an audit, the LIR must be able to present statistics
> > showing the number of individual assignments made in all objects with
> > a status of 'AGGREGATED-BY-LIR."
>
>
> Yes, this requirement is copied verbatim from the IPv6 policy.

Which is also loosely written. It should not be permitted to aggregate
a single assignment to a single End User.

>
> > So the number 1 is valid. You don't require the block size of the
> > individual assignments to be specified in the audit. So that 1 could
> > be the same size as the aggregate or a single IP address.
>
>
> Correct, just as in the IPv6 policy. Though I fail to see the point in
> "aggregating" only a single assignment.

Actually you are right. By dropping the requirement to include End
User contact details from the policy, you have allowed assignment
objects to also be anonymised. So all identification and contact
details for the end user, which may be in optional attributes, can be
removed from the assignment object. Only if they operate their own NOC
would you need to include any contacts for the End User. Some LIRs
don't comply with current policy because they don't want to publish
any details of their customers in a public registry.

>
> > Your proposal has dropped the requirement:
> > "When an End User has a network using public address space this must
> > be registered separately with the contact details of the End User."
>
>
> Correct, as we are copying the wording from the IPv6 policy, which does
> not contain that specific sentence.

But the IPv6 policy also includes this:
"When more than a /48 is assigned to an organisation, it must be
registered in the database as a separate object with status
'ASSIGNED'."
I don't see your equivalent of this copied from the IPv6 policy into
your new IPv4 policy. Maybe more than a /24 might be an equivalent in
IPv4 terms. You refer to 'that specific sentence' so casually, yet
this is the main element of the current IPv4 assignment policy.
Dropping this sentence is a major change to the assignment policy.
This has far more consequences than just adding an optional construct.

>
> > It is not specified in the current policy if those contact details
> > must be the tech-c/admin-c or the address of the company. So the
> > objects in my example comply with the current policy.
>
>
> We might have to agree to disagree on this one, but to me it seems
> clear that the mandatory contact details referred to by policy *are*
> admin-c and tech-c, nothing more, nothing less. This follows from the
> inetnum object template, where admin-c/tech-c are the only mandatory
> attributes that relates to contact information.

You might want to disagree with me but on this one you are clearly
wrong. Neither policy has any definitions of contacts. In fact I don't
believe any policy or other RIPE document defines what a contact is.
The IPv6 policy doesn't even mention the word 'contact' anywhere. So
you cannot claim that a contact *is* related to some specific
attribute(s). Especially some subset of attributes that *you* imagine
it is referring to. What about abuse-c, zone-c, maintainers,
notifications, remarks, descriptions. Is it a role or a person or some
persons referenced from a role or referred to in a comment? There is
nothing in the policy connecting a contact with any specific
attribute, mandatory or optional. So the only thing you can reasonably
deduce is that the term contact refers to what is generally accepted
as a contact. A free text name and address is therefore a valid
contact for the purposes of this policy.

>
> In your examples, the LIR included street addresses of the assignees in
> the unstructured descr fields. This is essentially useless for trying
> to get in touch with someone about solving operational problems - I
> mean, when was the last time you physically travelled to someone's
> office or sent them snailmail in order to troubleshoot a network issue?

Yet again you are assuming this public registry held in the RIPE
Database is nothing more than an operator's phone book for
troubleshooting network problems. There are stakeholder groups who use
the RIPE Database public registry for other purposes.

>
> When reading the requirement to register the End User's contact details
> with the goal of registration stated in section 3.0.4 of the policy in
> mind - «to ensure uniqueness and **to provide information for Internet
> troubleshooting at all levels**» (emphasis mine) - it seems clear to me
> that the mandatory contact information referred to by policy must be
> more immediate and long-distance forms of contact, such as 'phone' in a
> person object or 'e-mail' from a role object. These are mandatory
> attributes, and can be used as tech-c/admin-c in inetnum objects, which
> are also mandatory.

First of all the goals in the IPv4 policy are outdated and need
revising. For example:
"3.0.3 Fairness: Public IPv4 address space must be fairly distributed
to the End Users operating networks."
is no longer even possible with free market constraints.
The term 'contact details' can include more than one contact. So the
name and address can satisfy the condition for End User contact
details and the tech-c can satisfy the goal of troubleshooting at all
levels whether it is for the End User or LIR.

>
> Thus, the registration goal and requirement in the policy and the chain
> of mandatory attributes in the RIPE database ties together very nicely
> in a structured, machine-readable and logical way:
> inet[6]num→tech/admin-c→person→phone, alternatively:
> inet[6]num→tech/admin-c→role→e-mail.

I would love the data in the RIPE Database to all be structured and
machine readable. However the current data model is defined in a way
that all data is human readable, unalterable, text blocks. Here you
are making assumptions that are not defined and which coincidentally
partially support your argument. Apart from the lack of definition of
contacts, there is no reference or link to 'mandatory' attributes. You
can use many combinations of mandatory and optional attributes that
are either machine readable or human readable free text in
person/role/inet(6)num objects in order to satisfy the policy
registration requirements.

>
> > With the current policy only when an End User is a natural person can
> > you replace the contact details with that of the LIR. With your
> > policy ANY or even ALL End Users can replace their contact details
> > with that of the LIR by changing the status to AGGREGATED-BY-LIR. In
> > theory every ASSIGNED PA object in the RIPE Database can become an
> > AGGREGATED-BY-LIR object with only LIR contact details. Now that
> > won't happen as a lot of responsible End Users will want their
> > contact details in the database for network problem resolution.
>
>
> Well, it depends. Is the LIR' NOC the correct point of contact for
> network problem resolution, i.e., is there already a single value used
> for tech-c and admin-c across a set of adjacent assignments?
>
> If yes, then the LIR could aggregate those objects.
>
> If no, e.g., if the End Users operate their own NOCs, then those
> objects can not be aggregated.
>
> This is of course all the same as in the IPv6 policy today.
>
> > But we all know there are LIRs who provide services to spammers and
> > othe abusers, knowingly or otherwise. You can be sure these End
> > Users' details will disappear from the database.
>
>
> Are you certain that updated and working contact information of
> spammers and abusers are correctly registered in the RIPE database
> today? (Rhetorical question, no answer sought.)

In the IPv4 policy Section 4.0 Registration Requirements it says:
"Registration data (range, contact information, status etc.) must be
correct at all times (i.e. they have to be maintained)."
As this information in assignments is maintained by the LIR it is
their responsibility to ensure it is correct.

>
> > > Thus the LIR in question already has a 'short cut' option available
> > > to them, should they feel managing the assignees' address
> > > information in the RIPE database is too burdensome - they can
> > > simply chose to not include that information in the first place.
> > >
> > > I want to emphasise that this policy proposal does not grant them
> > > this option, it is already there today.
> >
> > This again is misleading. The LIR CANNOT do what you suggest with the
> > current policy. The current policy says:
> > "When an End User has a network using public address space this must
> > be registered separately with the contact details of the End User."
> > As I said above, It is not specified if those contact details must be
> > the tech-c/admin-c or the address of the company. In the example I
> > gave the admin-c/tech-c are the details of the LIR. But they comply
> > with the policy by including the address of the companies. They are
> > the End User contact details. If they chose to remove this optional
> > information then they no longer comply with current policy. But you
> > drop this policy condition. Therefore with your policy proposal you
> > allow them to remove this optional info and still comply with the
> > policy. Netname is just a string of LIR defined characters and does
> > not need to be unique. So they can all be set to the same string.
> > Country is also LIR defined and generally meaningless so they can all
> > be set to the same pointless value. So your proposal allows this LIR
> > to make all these assignments 'the same' and replace them all with a
> > single AGGREGATED-BY-LIR object. This is a very significant change to
> > the public registry. With this proposal ANY set of data can be
> > anonymised. There is no longer any requirement for End Users running
> > public networks to be identifiable or contactable.
> >
> > This IS an option granted by this proposal that is NOT there today.
>
>
> Here are three randomly selected assignments that demonstrates how this
> option is there today:

NO it is not there now.

>
> inetnum:        213.174.234.0 - 213.174.234.31
> inetnum:        62.213.192.208 - 62.213.192.223
> inetnum:        213.162.203.0 - 213.162.203.255
>
> All of them have netnames à la «LIRNAME-CUSTOMER-NUMBER-1234», strongly
> suggesting this is a downstream assignment to a specific customer and
> not made to the LIRs own infrastructure or DHCP pools, and the only
> thing resembling contact information are the admin-c and tech-c
> attributes, which refer to the LIR itself.

The first and third example above may not comply with current policy.
They do not include the contact details of the End Users. This is only
valid if the End Users are natural persons and have replaced their
contact details with that of the LIR.

I think you are misunderstanding how the current policy works. Let's
go back to that sentence you want to remove:
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User.
Where the End User is an individual rather than an organisation, the
contact information of the service provider may be substituted for the
End Users."
Suppose an End User is a company who wants the LIR to manage the
network for them. The tech-c and possibly the admin-c and also the
abuse-c may all be set to the contacts for the LIR. Because they are
not a natural person (individual) they don't qualify for the exception
in the policy to substitute their contact details with those of the
LIR. But all the '-c' contacts refer to the LIR. So they are not
complying with policy. There are no contact details of the End User.
To comply with the policy in these situations the LIR can include the
name and address of the End User company in the optional descr
attribute. This satisfies the policy condition of providing the
contact details of the End User in the assignment object. Why do you
think so many LIRs provide these optional details? They don't do it
for fun. They do it to comply with the current policy.

Your proposal allows them to dump all this optional information. They
no longer need to provide contact details of the End User. This is an
option your proposal provides that is not there now. Over time all
these optional descr attributes with End User contact details will
disappear. That would be a significant loss to the public registry.

>
> > I can see a follow up question to the DB-WG, "How do I aggregate a
> > whole allocation?" Which may well replace the current question, "How
> > do I assign a whole allocation?" The consequence of this proposal is
> > the same as a previous suggestion to make assignments optional. Both
> > allow for the mass anonymisation of End Users.
>
>
> This possibility, as demonstrated above, is already there today - both
> in the IPv4 and IPv6 policies.

As I have demonstrated above, no it isn't there now in the IPv4 policy.

>
> > Are you suggesting that abusers generally work with single IP
> > addresses, rather than cycling through a block of addresses?
>
>
> Not really, but I would rather suggest that spammers and abusers are
> not likely to faithfully and correctly publish their assignments and
> contact information in the RIPE database in the first place.

All this information is published in the RIPE Database by the LIRs who
have a responsibility to ensure it is correct.

>
> If you are building your anti-spam/abuse methodology on the assumption
> that otherwise bad actors are behaving as good actors when it comes to
> maintaining the RIPE database, I don't think that methodology would
> work very well.
>
> From the proposal: «As of August 2023, there were 19,221 PA allocations
> without any child PA assignments held by 10,052 LIRs». What do you do,
> exactly, if you start receiving abusive traffic from any of these
> ranges?

Block and blacklist the whole allocation if no more specific
information is available.

>
> > > Note that this is not really much different than what you have to
> > > do today for abuse coming from customer assignments that are
> > > «registered as part of the service provider's internal
> > > infrastructure», cf. ripe-708 section 6.2.

Doesn't that suggest they are DSL customers with a single IP address?

> >
> > Just a note that ripe-708 was the address policy of 2018. There have
> > been 5 updates since then.
>
>
> My mistake, a Google-snafu there. That particular sentence is unchanged
> as of ripe-804, though, so the points stands.
>
> > > That said, AGGREGATED-BY-LIR would here have made it
> > > clear that the abusive address is indeed assigned to a downstream
> > > customer and is not part of the service provider's internal
> > > infrastructure.

Assuming an LIR has chosen to use this new 'optional' status value. As
many LIRs already have aggregated their DSL customers and tagged them
as such in remarks attributes, why should they change it?

> >
> > Take a look at these two examples of real data:
> > 82.116.118.0 - 82.116.119.255
> > 88.149.40.0 - 88.149.40.255
> >
> > One is listed in a remarks as "dynamic DSL address pool" and the
> > other as "DHCP Customers". They are already aggregated. What do we
> > gain by changing the status on these objects from ASSIGNED PA to
> > AGGREGATED-BY-LIR? Suppose one LIR changes the status and the other
> > does not. As you said it is optional. Nothing changes for either LIR
> > in terms of what they must create, modify or delete in the database.
> > They are already aggregates. What can a casual viewer of this data in
> > the database deduce from these two new objects with different status
> > values? Without parsing the remarks they cannot deduce anything.
> > Either could be a single End User or multiple End Users. The status
> > doesn't distinguish either option. Why do we need a new status value?
> > We end up with two values that are completely interchangeable with no
> > way to interpret their different meanings without parsing remarks.
>
>
> If you are a machine, and not a human, free-text remarks such as
> "dynamic DSL address pool" are essentially meaningless. They are
> optional too, the LIRs could easily have omitted them. If they had, it
> would have impossible to tell whether those addresses had been assigned
> to one or more downstream customers or if they had been assigned to the
> LIR itself.

If it has this new aggregated status you still don't know if it is a
block of maybe 1000 DSL customers of a collection of randomly sized
assignments to End Users. You still need the free text remarks to
avoid confusion.

>
> Furthermore, there is a chance that at least one of the customers in
> those pools are using his or her assigned address for some purpose like
> running a MineCraft server, let's say. If, so, that single IP customer
> assignment is no longer «used solely for the connection of an End User
> to a service provider» and would need to registered as a separate
> assignment.
>
> Everybody ignores that requirement, of course, because otherwise the
> result would have been complete and utter mayhem. Nevertheless, it is a
> de jure policy violation. AGGREGATED-BY-LIR solves that.

Aggregation is one way to address that issue. There are other ways
that don't require dumping the basic principle of registering contact
details for End Users. Again looking at the IPv6 policy under the
definition of 'Assign' it says:
"This includes for example letting visitors connect to the assignment
holder's network, connecting a server or appliance to an assignment
holder's network and setting up point-to-point links with 3rd
parties."
We could apply some appropriate wording to the definition of DSL
customers to cover situations like running a MineCraft server. Maybe
something like:
"IP addresses used solely for the connection of an End User to a
service provider (e.g. point-to-point links) are considered part of
the service provider's infrastructure. These addresses do not have to
be registered with the End User's contact details but can be
registered as part of the service provider's internal infrastructure.
This applies even if the customer allows other people to connect to
the internet through their connection."
I am sure someone could find more appropriate wording that would more
accurately restrict the exception to this type of use case.

>
> > The bottom line is that this new status value adds no new benefit,
> > but can be seriously mis-used to cause considerable damage to the
> > RIPE Database as a public registry. It WILL be misused by those
> > operating public networks who wish to keep their details hidden from
> > public view.
>
>
> We do not propose to do anything that hasn't already been done in the
> IPv6 policy and database for years and years and years, and the sky has
> not fallen.

Your policy proposal is about adding a new status value for IPv4. The
title does not propose to retrofit the whole IPv6 policy onto IPv4.
Most of the internet has been on IPv4 for years and years and years.
Dumbing down IPv4 registration data to the level of IPv6 may well have
a significant impact on the registry.

> The End Users that want anonymity for whatever reason have
> ample opportunity to remain anonymous today, even while staying policy
> compliant (not that bad actors would care about that).

If you apply the policy correctly they do not have that opportunity
now. You have to violate the policy for an End User to be anonymous
now.

>
> Finally, there *is* a benefit to this proposal, an actual itch we're
> trying to scratch, specifically where there are many identical small
> assignments being made and removed in a rapid and automated fashion, to
> End Users that don't operate their own NOCs. I've mentioned the cloud
> VPS provider example before here.

If this policy proposal only scratched that one itch it might be fine.
But it goes WAY beyond that. It completely undermines the current IPv4
registration policy. Again it might be possible to address the cloud
VPS situation with a similar exception to DSL customers. You don't
need to destroy the entire policy to address a few exceptions.

cheers
denis
co-chair DB-WG


>
> Tore
>