[address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

Hi Tore

We have been through all these arguments before, but it is the review
phase now so they need to be repeated.

On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore at fud.no> wrote:
>
> Hello Emmanuel, and thank you for your message!
>
> Please find our comments and questions inline below:
>
> On Wed, 2023-12-13 at 20:30 +0000, Kessler, Emmanuel wrote:
>
>
> > With this message, I would like to express from Europol perspective,
> > our questions and some clear concerns about the measure 2023-04 as
> > proposed.
> >
> > We have been very recently informed about the project of measure that
> > would indeed remove User assignment data from the RIPE Database
> > public registry.
>
> 2023-04 aims to *increase* the level of End User assignment coverage in
> the RIPE database, not remove or decrease it. Quoting from the
> proposal:
>
> «As of August 2023, there were 19,221 PA allocations without any child
> PA assignments held by 10,052 LIRs (…) Since the RIPE Database
> Requirements Task Force published their report in May 2021, the PA
> allocations without any child assignment have grown by 18.4 percent.»

18.4% of 19,221 is 3536. How many /24 allocations were made in that
time period that quite likely don't have assignments?

>
> We hypothesise that this trend is least partially caused by LIRs
> considering that registering all assignments individually is too
> labour-intensive and not worth the effort, especially in highly dynamic
> environments where individual (but otherwise identical) assignments
> rapidly come and go.

Pure speculation without any numbers. But what you are suggesting is
that some LIRs don't consider it worth the effort to comply with RIPE
policy and don't want to get involved in discussions to change the
policy. I don't agree with your proposal but at least you are trying
to change something you don't agree with. As for the labour intensity,
we know the answer to that, but no one will even talk about updating
the 25 - 30 year old RIPE Database design, data model and
technology...

As for 2023-04 increasing the level of End User assignment coverage,
this is pure fantasy. In theory you could perhaps argue that the
'coverage' has increased if many LIRs create aggregated objects and
claim that many assignments have been made from within that block. But
the End User details will be completely lost within that amorphous
block. Not even the assignment boundaries can be deduced. Many other
LIRs may well anonymize their future or even already existing
assignments by removing all references to the End User's identity and
contact details. This may be done at the request of the End User. Or
it may be done because the LIR has adopted a policy of not entering
any details of their customers (End Users) into a public database. I
have spoken to LIRs who have made it clear that it is already their
policy regardless of current RIPE address policy requirements. They
consider it commercially sensitive data. There are technical solutions
to mitigate this but again no one will talk about the database.

>
> 2023-04 would provide these LIRs a less labour-intensive option to
> register such assignments. Whether or not they would avail themselves
> of the new option is of course an open question, but it seems clear
> that something has to be done if the current trend towards less
> assignment coverage in the database is to be reversed.

Less labour intensive by dumping the detail. This is about eliminating
a problem rather than solving the problem, again because no one will
talk about technical solutions. You cannot define a trend based on two
measurement points. I agree something does need to be done to get more
LIRs complying with RIPE policies. But changing the registration rules
so that more people appear to follow them is not the way forward.

>
> > We have started a consultation of EU law enforcement services (that
> > however takes time), and informed the EU Commission.
>
> Did this consultation take the information in the Impact Analysis into
> account – in particular the clarification made by the RIPE NCC that
> 2023-04 does *not* change the current policies and procedures when it
> comes to the registration requirements for End User contact
> information?
>
> If it did not, this concern may well be the same as the one we
> addressed in the message yesterday.
>
> Would it be possible for you to share the questionnaire that was sent
> to the LEAs with the working group?
>
> > The first negative impact will concern the swift availability of data
> > : with the new measure, LEA will systematically have to request
> > information to the LIRs, with a court order.
>
> Could you please detail or give some examples of exactly what kind of
> information the LEAs would need to request from the LIRs using court
> orders?
>
> Taking into account the current policies and procedures, we suspect
> that the information about the End Users that LEAs can obtain directly
> from the RIPE database is inserted there voluntarily in the first
> place.

Or because some LIRs have correctly interpreted the current policy.

>
> If that is the case, wouldn’t it be more efficient for the LEAs to
> first contact the published contact information (found either in the
> End User assignment, or its containing allocation) and request the
> information that way – without going to the courts? Many LIRs would
> gladly help address any issues and are probably more capable in doing
> this than most End Users.
>
> Conversely, if the information requested is something the LIR prefers
> to withhold from the LEAs and the general public, it seems reasonable
> to assume that this information will not have been published in the
> public RIPE database in the first place. If so, a court order would be
> necessary - but that would be the case today, as well.
>
> > The other main impact will be on the quality of collected data.
> > In practice, the proposed policy could indeed allow assignments to be
> > somewhat anonymised.
>
> As clarified by the RIPE NCC in the Impact Analysis, the current
> policies and procedures are already allowing assignments to be
> “somewhat anonymised”. This is not a change that 2023-04 will bring
> about.
>
> > The measure would have here an impact on data granularity : The shift
> > to aggregated assignments would result in less granular data
> > available to law enforcement.
> > While individual assignments offer specific and detailed information
> > about each IP address's usage, aggregated data may obscure such
> > details, potentially complicating investigations that rely on precise
> > IP address information..
>
> As mentioned above it would be useful to know precisely what kind of
> information you are referring to here. We would appreciate it if you
> could share some examples.
>
> There is one thing we can think of, though - the assignment-size
> attribute. This is currently intended to be optional, as we did not see
> an independent justification for making it mandatory in IPv4.
>
> Given an LEA investigation into activity from 192.0.2.9, located within
> an aggregated inetnum object for 192.0.2.0/24 without the assignment-
> size attribute present, it would be impossible to deduce from the RIPE
> database alone if 192.0.2.10 is assigned to the same End User or not.
>
> If the assignment-size was present, the LEA would be able to answer
> that question without contacting the LIR. (assignment-size: <= /30 →
> same End User; assignment-size: >= /31 → different End User).
>
> This could be seen as an independent justification for making
> assignment-size mandatory in IPv4. If we amended 2023-04 accordingly,
> would that alleviate the LEAs concerns in this regard?
>
> > Identifying IPV4, remains highly challenging in many cases, as all
> > know, and IPV6 will not replace it at short term.
>
> The comparison with IPv6 is highly relevant. Apart from making the
> assignment-size attribute optional as discussed above, 2023-04 does not
> allow LIRs to do anything with their IPv4 assignments that has not
> already been allowed with IPv6 assignments for many years. The proposal
> is essentially a copy and paste from the IPv6 policy.

It is a good idea to align the IPv4 and IPv6 systems of registration
'where appropriate'. But maybe copy and paste without due
consideration is not the best way to do it. There are differences. In
those "many years" of aggregating IPv6 assignments not much of the
internet was using IPv6. So it is not a valid argument to say there
have been no problems with aggregating IPv6 over those "many years" so
it must be OK. As more of the internet moves to IPv6, maybe we will
start to see the problems that have been insignificant in the past.
Maybe we will need to expand the IPv6 registration of assignments to
match the current IPv4 policy. Again there are technical solutions
here that no one will talk about.

cheers
denis

>
> With that in mind, do you see any principal difference between the
> proposed AGGREGATED-BY-LIR for IPv4 and the already existing
> AGGREGATED-BY-LIR for IPv6? Is the former more problematic for LEAs
> than the latter? If so, could you elaborate on why that is?
>
> Best regards,
> Tore and Jeroen
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/