[address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

On Tue, 21 Nov 2023 at 10:14, Angela Dall'Ara <adallara at ripe.net> wrote:

>
> Dear colleagues,
>
> Policy proposal 2023-04, “Add AGGREGATED-BY-LIR status for IPv4 PA
> assignments”, is now in the Review Phase.
>
> The goal of this proposal is to introduce the AGGREGATED-BY-LIR status
> for IP


In general, i'm in favour of the proposal, however, it has raised several
questions that I think as a community need to address before we can decide
on the correct approach.

What is the purpose of the registrations on assignments in the RipeDB?

I always understood them as a way of recording who/what was using a piece
of address space so that you can contact the right organisation in the case
of an issue. In this case, there were explicit carve-outs for blocks of
dynamic address space so that the ISP could be contacted to determine who
was using that particular piece of address space at a single time.

Where address space was allocated on a more permanent basis the contact
details of the end site would be added so the organisation who was trying
to address the problem had a direct route to contact that end network. From
a technical point of view, it was useful as a reference to be able to work
out if several IP addresses in a subnet had been allocated to the same
customer or if there was a wider issue. This means that having the
assignment size fixed for each block and included in the RipeDB entry is
rather important.

Over time we have become more concerned about privacy, contact details
being shared, and the maintainability of the database. As such when IPv6
entries were added a specific additional label was created
AGGREGATED-BY-LIR that allowed an LIR to say this block of address space is
allocated to lots of individual organisations, with a boundary of /X please
contact us if you need the contact details for them. Part of the reason for
this was it gave the network operator to create long-lasting address
allocations that were non-dynamic (as opposed to being static) and force
them to register every single end user if they were going to try and be
efficient in their allocation of addresses.

For IPv6 I've not seen any issues raised about the creation of this class
of address (I did ask earlier but got zero feedback)

How does this Policy impact this use?

This policy appears to take the standard approach for IPv6 and apply it to
IPv4 (this is a good thing) it will reduce the number of individual entries
in the system (neutral) and hopefully increase the accuracy (a good thing)
but at the loss of explicitly including the contact details of the end user
site and replacing it with a contact for the LIR (neutral). The last step
appears to be the most controversial as it stops people from going directly
to the source as it were.

I think the operational impact here is a potential issue, some LIRs are
less than stellar in dealing with requests about things listed in the
RipeDB (mostly because of spam) so I can see the concern that some have
raised about not being able to get hold of people. However that's not a
Ripe issue explicitly but rather a function of the world of capitalism
(it's free to send an email, let's send lots of emails, we only need a few
people to respond to make money...)

If we want to fix this problem then maybe we need to add a new capability
onto the db that allows authenticated users to contact LIRs about their
address space (without using the published contact details) in a way that
would allow anti-abuse and LEAs to access the information they need, that
is very much not something that needs discussion in the WG because were
here to talk about address policy.

This policy is optional...

I think people have missed this, from my reading an LIR is not prevented
from continuing to put entries without marking them as aggregated so from
that point of view if you want to continue to include customer details (and
you have their consent) you can still do it.

So with all that said, I think I still support the policy with the caveat
about assignment size mentioned earlier

Thx

J
-- 

James Blessing
07989 039 476
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20231218/52eab09b/attachment.html>