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

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.

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

> For every one of the assignments in this example allocation you can
> change the status to AGGREGATED-BY-LIR and remove all the
> identification and contact information for the actual end user. 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.

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

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?

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.

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.

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

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

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.

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

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

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

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.

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

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.

Tore