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