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

Hi Jeroen

I only used abuse as one example. But as you have picked up on it I'll
go with the flow.

On Fri, 22 Sept 2023 at 09:45, Jeroen Lauwers <jlauwers at a2b-internet.com> wrote:
>
> Hi Dennis,
>
> It is good that you look carefully at the effects of the policy proposal, especially for abusing matters by end users. I only miss the complete pictures for this point. In the hypothetical case l as a LIR would like to help spammers I could use 6.2 as a valid reason for not registering the contact details of the end user.

No you can't, unless they are a natural person (with contact details
replaced in their assignment object with those of the LIR) or only
have a single IP address (DSL customer).

>  Second I could change quickly the IPs of the spammer and then update this quickly enough in the DB that still no one would be able to get any info. Because before the moment people have time to check the DB the information would be already gone. So as LIR I would be fully complying with the rules of the address policy and still be able to help spammers.

You might be able to change it faster than a human can read it, but
not faster than a machine can process it. The information has not
'gone'. The database has a historical audit trail. Every change you
make is logged. I am working on a proposal for a one time post
processing of historical data. This will make much more information
available from the data without violating privacy or GDPR. This will
prevent LIRs from doing tricks like this to hide things.

But it is interesting that you seem to think you can make quick
changes to the database without too much effort, when it is something
you want to do. But one of the cornerstones of your argument for this
proposal is that it is too much effort to make quick changes, when it
is something you don't want to do, like complying with policy.

> And then we not even talking about if abusers would even try to write the proper contact information or privacy laws like GDPR.

There are requirements for LIRs to enter correct information into the
database. You know who the End Users are as they pay you for services.
You have contracts with them. The information in assignment objects is
entered by the LIRs not the End Users.

>
> In a lot of cases, it would be good to have end-user information but I don’t think we can solely trust on the idea that if we can contact end users a problem would be solved. In my experience, even with technical problems most end users won't have enough skills to solve problems by themself.

Again you are assuming that the RIPE Database is nothing more than a
phone book for operators to solve network problems. It is a public
registry; it has evolved beyond a simple phone book for operators.

> So imagine than a case where the end user is on purpose abusing the IP space. In the end, it is the LIR's responsibility who is using the IP addresses that are assigned to this LIR. So I think in case of that a LIR is accidental or on purpose accommodating a spammer it is more efficient to focus on the LIR than the end user for stopping the abusing end user.

So as an LIR are you accepting responsibility (and liability) for
abuse from one of your End Users?

>
> We hope that with this proposal more IP space will be covered in the database by making it easier to comply with the rules and give fewer LIRs the overwhelming feeling of repetitive tasks.

You keep pushing this "overwhelming feeling of repetitive tasks"
angle. Machines have been helping with these repetitive tasks since
Charles Babbage developed his analytical engine almost 200 years ago.
Most LIRs have engineers who understand computers. We are after all
the people who manage the global internet. We are running a service
used by the biggest tech companies in the world. So are you saying
that in 2023 we can't manage a distributed database without
overwhelming repetitive tasks?

> At the moment the IP space without any child assignment in the database is growing every year.

You can manipulate numbers to make any point you like. How many of
these 'growing' allocations without assignments are /24 allocations?
Not only has the RIPE NCC been making only /24 allocations for quite a
few years, but people also buy /24 blocks on the open market which
then get registered as allocations. The RIPE NCC /24 allocations were
intended to be used by new LIRs who needed some IPv4 address space for
their own infrastructure. So you would expect them to have no
assignments. But that is not what happened with a lot of them. Many of
these /24 allocations are now held by financial investors, managed by
brokers and rented out to End Users, many of whom are other LIRs who
may then even sub-assign them. None of this is represented in the RIPE
Database as the old data model can't match new business models like
this. There is nothing wrong with new business models. It is an
inevitable consequence of monetizing IP addresses. But the RIPE
Database needs to catch up. That is difficult because no one will talk
about it. This proposal doesn't help with the bigger picture.

You talk about LIRs sometimes being a better option to contact
regarding address space usage. When the LIR/resource holder is a
financial investor with no knowledge of IT, the broker renting out the
space wants to keep a low profile, but they may be providing the LIR
services, and the End User may also know nothing, then who do we talk
to now in this new chain?

> And I think we both agree that how more space is covered in the DB the better it is for the community.

ALL address space is covered by allocations. Having lots of the more
specific information hidden is not better for the community.

Cheers
denis
co-chair DB-WG


>
> Kind regards,
>
> Jeroen
>
>
> Op 22 sep. 2023, om 05:52 heeft denis walker <ripedenis at gmail.com> het volgende geschreven:
>
> Hi Tore
>
> I will first answer your points in this email, now I've had more time
> to think about it. Then I plan to send two longer emails. One on the
> bigger picture and one specifically about your proposal text. It is
> disappointing that so many people just said "+1 great proposal". I
> think they have responded to the headline and not considered the
> details or the implications. So let's consider some of them...
>
> On Wed, 13 Sept 2023 at 08:59, Tore Anderson <tore at fud.no> wrote:
>
>
> Hello Denis,
>
> Let me start off by clearing up a misunderstanding:
>
> My brief example did not mean to convey that non-uniform contact
> information is the only thing that could make a set of objects non-
> uniform and thus unsuitable for AGGREGATED-BY-LIR.
>
> Rather, the exact opposite was the intended meaning - which is that
> almost any attribute can make a set of objects non-uniform. The tech-c
> attribute was only used an example to demonstrate this.
>
> With that out of the way, my answers to your remaining points follow
> in-line:
>
> * denis walker
>
> Now let's look at a real life example.
>
> whois -rBm 195.238.192.0 - 195.238.223.255
>
> The first thing to note is that the admin-c and tech-c values are the
> same in all the more specific assignments. Even the mnt-by is the
> same, although you make no mention if that is a blokker for
> aggregation or not. So by your definition these are 'completely
> uniform' objects and can be aggregated.
>
>
> As I clarified above, these objects are in my view *not* uniform, as
> they have distinct netname, descr and country attributes (possibly
> others I missed too, I only skimmed through them quickly).
>
> The LIR in question clearly has a policy of publishing the street
> address of each assignee in the descr attribute. That is totally fine,
> and will continue to be totally fine after 2023-04 is implemented, but
> it makes their objects unsuitable for aggregation.
>
>
> 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."
> 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.
> 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."
> 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.
> 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. But we all
> know there are LIRs who provide services to spammers and other
> abusers, knowingly or otherwise. You can be sure these End Users'
> details will disappear from the database.
>
>
> You will also note that all these objects contain optional descr
> attributes. These attributes contain name and address details of the
> end user. That is important information for many stakeholder groups
> using the RIPE Database public registry. That detail will be lost in
> an aggregation. Given that current policy requires these assignments
> to be registered in the public registry, many users do include this
> detail. Now we all know the RIPE Database design and technology is
> very old and it does currently require some effort to manage this
> data. (A problem that all users have noticed but no one has attempted
> to fix.) Given a 'short cut' option, human nature suggests people
> will use it, even if it is not the right thing to do for a public
> registry. So aggregating across the whole database, may result in a
> massive amount of detail being lost from the public registry.
>
>
> It is important to note that the information you mention as "important"
> here - the assignee's address - is (as you rightly point out) optional
> to include. An LIR is under no obligation to publish this information,
> and the inetnum object does not even contain an attribute dedicated to
> it.
>
> (While the organisation object has mandatory org-name and address
> attributes, the org attribute is optional in inetnum objects.)
>
> 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.
>
> 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.
>
>
> Also note that there are gaps in the more specific assignments for
> this allocation. For example 195.238.193.224 - 195.238.193.255 is not
> assigned. Can your aggregated objects span these gaps? If so then we
> lose sight of what address space is in use or available. It may no
> longer be needed for further allocations but people do still use that
> information.
>
>
> Yes, just as in IPv6, aggregated objects can span gaps. This is
> essential, as the primary use case targeted by AGGREGATED-BY-LIR is
> automated assignment pools with a high churn rate (e.g., a dynamic DHCP
> pool).
>
>
> This may be your specified primary use case, but it can then be
> extended to the entire database.
>
>
> In such environments, the .1, .2 and .3 addresses might be assigned
> before .2 might get de-assigned again - all within seconds, with no
> operator involvement. We believe it is not necessary to reflect this
> high level of granularity and rapid churn rate in the RIPE database.
>
> The assignments are all randomly sized. Which is why you have dropped
> the inet6num assignment-size attribute for inetnum objects. So if I
> amgetting abuse from one specific IP address what should I do? I have
> noidea from the aggregated block what the block size is that includes
> this one IP address. Is there any other way to find this information,
> maybe from routing details? If not, should I block and blacklist the
> entire aggregated block? That could affect hundreds, maybe even
> thousands, of users in some cases. This is not a problem with IPv6 as
> you know the size of the block containing that address.
>
>
> My personal recommendation would be to block the specific IP address
> you are receiving abusive traffic from and send a complaint to the
> abuse-c for the inetnum in question.
>
>
> Are you suggesting that abusers generally work with single IP
> addresses, rather than cycling through a block of addresses?
>
>
> 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.
>
> 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.
>
> 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.
>
> cheers
> denis
> co-chair DB-WG
>
>
> Tore
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/
>
>