[address-policy-wg] Mass deletion of assignments from RIPE Database?

Colleagues

[Apologies for the long email, but I feel the video is an
oversimplification of the issues involved.]

I have watched the video from the AP-WG agenda for RIPE 82 by the RIPE
Database Task Force (TF). As a netizen, rather than in any other
capacity, I am totally opposed to this recommendation which would
allow the removal of all IPv4 assignments from the public registry of
IP addresses. I would like to present some opposing arguments before
the discussion tomorrow in the AP session at RIPE 82. In the video
there are 4 justifications given. None of these can actually be
considered as a justification for this recommended policy change.

1/ some allocations have no registered assignments
This should be followed up by the RIPE NCC with ARCs. If the current
policy has not been followed, then assignment objects should be
created. If a few resource holders don't follow the policy, that is
not a justification for changing the policy. Encouragement to follow,
or enforcement of, the policy is the answer to this.

2/ Small (/24) allocations require even smaller (/25) assignments
There is an action point in the DB-WG (NWI-4) to allow multiple status
values in INETNUM allocation objects which would address this issue
without policy change.

3/ data minimisation, less data to maintain = more accurate [implying
that having no data gives 0% error]
Googling for 'data minimisation' it is hard to find any definition
that doesn't relate to personal data. This is the best fit I found:
"The principle of data minimization involves limiting data collection
to only what is required to fulfill a specific purpose."
If there is a valid purpose for assignment data then this isn't 'data
minimisation', it is 'data loss' resulting in reduced functionality.
So the historical, present and future use of assignment data is the
real question to consider.

4/ justify additional allocations
This was 'one of' the historical reasons for creating assignments in
the DB. Since run out this reason no longer applies. But that does not
mean there are no other reasons for having assignment data in the DB.
In the video the TF suggest that 'now' this reason no longer applies,
perhaps we can drop this policy requirement. As ripe-733 (assignment
policy) no longer even mentions this as a reason for creating
assignments in the RIPE Database, I don't see the connection between
this long since discarded reason and changing the policy now. The
video ignores any other reasoning for the existence of assignments in
the DB.

The suggestion in the video was that creating (PA) assignments would
be optional. It also said "Partitions and sub-allocations 'should' be
registered. It is important to note that in policy speak, 'should' is
not the same as 'must'. This makes everything more specific to (PA)
allocations optional. What are the likely consequences to this change?
Many operators maintain internal software to align their internal
address management with the RIPE Database. This involves a lot of
time, effort and money to keep the RIPE Database up to date. They are
also open to criticism if anyone finds a single email in the DB that
is invalid. It also exposes their publicly identified customers to
being directly accountable for their use of address space assigned to
them. While most end users probably don't have an issue with that,
internet abuse originates from somewhere. Those networks probably
prefer to be hidden out of view. By making all this data optional,
resource holders can simply delete all this data from the RIPE
Database. They can archive the software used to align their internal
systems with the RIPE Database. They can shield their customers behind
the court order firewall from any exposure to questioning of their
usage of their assigned address space. The resource holder can hide
themselves behind a contract putting responsibility of usage of
address space on their (now) hidden customers. Without a court order
this all becomes private, hidden data. It is easy to see benefits to
resource holders and operators for this change, but does it have a
negative impact on other RIPE Database data consumers? I suspect
making this policy change could/would result in a mass deletion of
(PA) assignment data from the RIPE Database leaving only the
allocations made by the RIPE NCC.

In this scenario what happens with abuse reporting? All reports would
have to be sent to the LIR holding the allocation resource. They could
put a simple mail forwarder on that email address and forward all
reports to the appropriate (hidden) customers. If anyone questions a
report sent, the answer could be "I forwarded it on to the user. If
they haven't replied to you, get a court order to reveal the customer
details and take it up with them directly."

What happens with blocking & blacklisting addresses? Unless it is
possible to determine assignment sizes from other data (routing
perhaps?) then the only option is to block or blacklist the whole
allocation. There are no aggregated objects with assignment sizes like
with IPv6.

Removing assignment objects also impacts the use of the RIPE Database
as a contact DB for network operators. Resource holders will have to
weigh up if the need for more specific network contacts was important
enough to justify them maintaining all their assignment data in the
RIPE Database. For larger resource holders, given the savings to them
by ditching this data, they may well choose to sacrifice network
contacts.

In the video the TF talks about the 'freedom' of LIRs to choose if
they want to enter assignment data or not. Their freedom is someone
else's denial. They also talk about a smaller, common, useful
database. This smaller, common database is not very useful to anyone
who uses the assignment data that is discarded to make it smaller.

Looking at it from the perspective of accountability, openness and
abuse issues, deleting 94% of the IPv4 registry data from this public
registry and turning all this information into private data requiring
individual court orders to access each bit of what was public data, I
believe would be a huge backwards step. Even if the reality turned out
to be half the assignments being deleted, is a partial data set, with
less eyes focussed on the reliability and accuracy of the data, of any
use to anyone?

In recent years the use of the DB by LEAs, abuse handlers and
researchers has been hotly debated and contested. If you look at
recent policy discussions and DB functionality issues, two phrases
come up time and time again. "It's not the purpose of the RIPE
Database to do 'abc'." "It's not the function of the RIPE NCC to do
'xyz'." So many engineers and operators seem to have difficulty
accepting that the purpose of the RIPE Database has evolved over time
and is now more than an engineer's and operator's tool. In today's
society the internet is not only an essential part of every day life,
it is also a dangerous place. The DB has become an essential tool for
LEAs and companies & organisations that try to address internet abuse.
That is despite many engineers and operators constantly dismissing
this as not a (historical) purpose of the RIPE Database. The same
argument is used against researchers. Use as a research tool was not
on the original list of purposes of the DB. The whole umbrella of
research is an essential part of moving forward with technology. It is
time to stop the endless arguments about the purpose of the RIPE
Database and accept that use by LEAs, abuse handlers and researchers
is now part of the fabric of the RIPE Database. Whilst the TF
acknowledges this friction in their draft requirements document, there
are no recommendations to resolve this issue. I would like to see the
TF address this and recognise these as valid purposes of the RIPE
Database. I hope recommendations will be included in a future draft of
the TF's requirements document that recognises these new and important
purposes of the RIPE Database by an expanding and diversifying set of
data consumers.

Moving forward on address policy with these newly accepted purposes of
the DB, the IPv4 assignments take on a more important role. In this
context I do not believe assignments should be made optional, and
almost certainly deleted to become hidden, private data, behind a
court order firewall.


cheers
denis
long standing, but forward looking, netizen


Question to the RIPE NCC...
Can you select a random week day and calculate the total number of
queries where the query string is an IPv4 address. If possible can you
determine if the query string address is contained within a PA
assignment object and calculate the percentage of these queries that
would have returned an assignment object. If this recommendation is
accepted, these queries in future would most likely only return the
resource allocation object.