Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Cynthia Revström
After reading denis's response I realized that I responded a bit too
hastily with my +1.
I am going to retract my support for this proposal as I really don't
get why you would need this without the "assignment-size" attribute.
I might have missed something but I can't see what possible benefit
"AGGREGATED-BY-LIR" has over "SUB-ALLOCATED PA" without it.
The only thing that I can think of is if you just want to just comply
with the policy without providing any additional info, in which case
the policy should just be updated to not require it if that is what
the community wants.
My reason for saying this is that some LIRs might choose to remove
specific inet(6)num objects that they have already created and just
create a big "AGGREGATED-BY-LIR" inet(6)num object as you can't have
inet(6)num objects under it.
Personally I would prefer it if an LIR just chose to document some of
their assignments while leaving some undocumented over "documenting"
them in a way that really doesn't specify any meaningful information.
If I have missed something and there actually is a true benefit[0] to
using "AGGREGATED-BY-LIR" without an "assignment-size" attribute then
do let me know.
I would really prefer if this was considered carefully before
implementing it due to the potential risk of losing data currently in
the database.
-Cynthia
[0]: "true benefit" here referring to something beyond just making it
compliant with RIPE policy as I think there are better solutions if
that is the case.
On Tue, Sep 12, 2023 at 4:56 PM denis walker <ripedenis(a)gmail.com> wrote:
>
> Hi Tore
>
> Your claims are not correct. Your simple example hides a lot of
> detail. I have given a real life example below taken from the database
> to illustrate what I mean. My apologies to the resource holder, but it
> is a perfect example to illustrate several points.
>
> On Tue, 12 Sept 2023 at 08:51, Tore Anderson <tore(a)fud.no> wrote:
> >
> > Hi Brian,
> >
> > * Brian Storey
> >
> > > Given the choice provided in the proposal, it seems to me like I
> > > could go the other way with this and aggregate everything? The end
> > > user allocation size distinction no longer looks to apply and I could
> > > interprete that the "purpose" of the whole aggregate is consistent
> > > (they are all used to reach "stuff") and therefore chose to not
> > > register any end user assigned /29s, 28s, /27s etc.
> >
> > It depends on whether or not all your assignments are completely
> > uniform (apart from the prefix value and length). If they are, you will
> > be able to aggregate them.
>
> Your definition of 'completely uniform' seems to only apply to contact
> details, as you make clear in the next paragraph. Many assignment
> objects currently contain more information than just contact
> references. You are making the assumption that the RIPE Database is
> still nothing more than an operator's contact database for network
> operational issues. In which case all you need is the tech-c.
>
> >
> > This means that they need to share a single common point of contact,
> > which is often the case for assignments associated with fully managed
> > Internet services provided to private individuals and small businesses.
> > Such assignments would be possible to aggregate.
> >
> > If on the other hand they are not uniform (for example if your
> > customers operate their own NOCs and therefore have different contact
> > information), you will not be able to aggregate them.
> >
> > I will try to explain by example here as well. Let's say you currently
> > have two customer assignments as follows:
> >
> > Customer 1:
> >
> > inetnum: 192.0.2.0 - 192.0.2.128
> > netname: BRIAN-ISP
> > country: GB
> > admin-c: BRIAN-RIPE
> > tech-c: BRIAN-RIPE
> > status: ASSIGNED PA
> > mnt-by: BRIAN-MNT
> > source: RIPE
> >
> > Customer 2:
> >
> > inetnum: 192.0.2.128 - 192.0.2.192
> > netname: BRIAN-ISP
> > country: GB
> > admin-c: BRIAN-RIPE
> > tech-c: BRIAN-RIPE
> > status: ASSIGNED PA
> > mnt-by: BRIAN-MNT
> > source: RIPE
> >
> > As you can see, except for the 'inetnum' value, they are completely
> > identical. That means you will be able aggregate them into a single
> > object:
>
> But your example is a bare bones object.
>
> >
> > > Does this not contradict other purposes / objectives of the registry,
> > > including the principles of registering public networks or am I
> > > missing something?
> >
> > We do not believe so. As demonstrated above, only highly redundant data
> > can be aggregated, so very little actual information lost in the
> > process.
>
> In real life lots of information may be lost.
>
> >
> > Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel
> > idea, it has been around in the IPv6 policy for many many years. If it
> > was indeed the case that it contradicted the purposes and/or objectives
> > of the registry, someone ought to have noticed and attempted to fix
> > that problem by now. That has not happened, as far as we know, which we
> > take as a sign that there is no such problem in the first place.
>
> This community has very little appetite to fix things properly if a
> quick fix will do or they can live with existing problems. The
> constant 'fight' to try to fix many problems with the RIPE Database
> illustrates this point very well.
>
> 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.
>
> 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.
>
> 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.
>
> The assignments are all randomly sized. Which is why you have dropped
> the inet6num assignment-size attribute for inetnum objects. So if I am
> getting abuse from one specific IP address what should I do? I have no
> idea 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.
>
> cheers
> denis
> c0-chair DB-WG
>
>
> >
> > Tore
> >
> > --
> >
> > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
2 years, 8 months
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Carlos Friaças
Greetings,
After reading your message, i had to go search if i expressed an opinion
on 2023-04 or not. It seems i did (back in September), but perhaps i
wasn't 100% clear about my opposition to this proposal.
So in order to make it clear for the co-chairs, i do oppose this proposal,
on the grounds that the quality of publicly available registration data
is likely to decrease if this proposal is approved.
Best Regards,
Carlos
On Fri, 5 Apr 2024, denis walker wrote:
> Colleagues
>
> I am not surprised this policy proposal (2023-04) has gone to last
> call. I expected this from the start, no matter what anyone said. And
> I won't be surprised when it is approved. I used to wonder why no one
> would even talk about bringing the RIPE Database into the modern
> world. Why continue to use an ancient, broken tool that is barely fit
> for purpose? It is quite obvious now. Playing on the complexity and
> difficulties with using the database allows people to justify changing
> the purpose and the rules, to make it more convenient. That is simpler
> and cheaper than fixing the tool. It is easy for a small vocal group
> to sell 'simple and cheap' to a silent majority. Convenience is easier
> to do than right. But it may have consequences.
>
> The proposers have assured us all that this proposal is about nothing
> more than introducing this optional, minor, inconsequential feature
> that changes nothing. They have argued that the RIPE NCC has
> "repeatedly" verified their claim that this proposal changes nothing
> 'of significance'. This is based on the RIPE NCC legal team's
> confusing impact analysis and the comments made once and referred to
> once by the RIPE NCC Registration Services through messages passed on
> by the policy officer. The legal team declined to clarify the
> confusing wording of their impact analysis. No one from Registration
> Services was willing to discuss the claims that they have been wrongly
> applying the policy for a number of years, or the reason why and when
> they stopped correctly applying the policy. I thought RIPE NCC staff
> were being encouraged to be more involved in community discussions?
>
> It has been said and confirmed recently by several people from the
> community that we no longer understand what some of the registration
> data in the RIPE Database means, why it is there and why we have these
> rules about it. This is despite the actual, current wording of these
> rules having been written into a version of the policy published in
> October 2003 that was authored by some people who are still leading
> members of this community, and at the time were RIPE NCC staff. The
> infamous line being removed by this proposal was a re-wording of
> earlier rules introduced in address policy with a long list of early
> authors, again including some people who are still leading members of
> this community. I asked if any one of these community leaders would
> offer some background information to the community on this, now poorly
> understood, registration data and the rules governing it. That may
> have helped with our current understanding. If we actually understood
> the data and rules that we are about to change, we might have more
> confidence in doing so. But nothing was said on this background.
>
> Europol has expressed serious concerns about these changes. They have
> stated that it takes time for them to consult with national LEAs, the
> EU commision and other partners. If someone had informed them earlier
> of the changes being considered that may affect them, they may have
> had sufficient time to do these consultations. Or perhaps they would
> have been able to express their deep concerns at an early stage,
> before the minds of the vocal few were made up. I did suggest early on
> in the discussion that the RIPE NCC contacts stakeholders of the RIPE
> Database and invite them to join the discussion. I was quickly told by
> other community members on the mailing list that this was not part of
> the policy development process. [Maybe it should be...]
>
> It is extraordinary that we have now reached a position where the
> convenience of a handful of vocal operators in this community is
> considered so important that we must proceed with all haste to
> introduce this optional, minor, inconsequential feature that changes
> nothing, without delay. That is without even a delay to allow Europol
> to complete it's consultations and report back to the working group. I
> saw references recently on the ripe.net website and LinkedIn about
> some productive meeting between the RIPE NCC and some internet
> governance groups. I hope the attitude of the technical community over
> this proposal won't undermine those meeting achievements. A technical
> community that clearly has not watched John Curran's keynote speech at
> NANOG that covers this very situation involving internet governance,
> the technical community and civil society. I would advise you all to
> watch it:
> https://www.youtube.com/watch?v=U1Ip39Qv-Zk
>
> You may question my comments about the vocal few. But the details of
> the who and how many are there for everyone to see in the public
> archive of these mailing lists. Only 22 people commented during the
> months of discussion over 2023-04. Of those, 6 people only made one
> comment and another 6 only two comments. Some of those 22 also opposed
> this proposal. So the number of people who actually expressed support
> is quite small. When you analyse these details for proposals across
> multiple WGs in recent years, and cross reference the who and how
> many, you see that there is a very small number of vocal people who
> tend to dominate these discussions. It is basically this small group
> of people whose voices dictate RIPE policy. The problem there is that
> we may find policy, accidentally or intentionally, following an agenda
> that suits the needs of these people, rather than the wider, silent
> community. Unfortunately, we don't have any other way to do this at
> the moment. However, when a change is controversial, has many serious
> objections and offers so few benefits, to push it through with so few
> supporters is very questionable. Especially as it has been well
> established during the long discussions that we (collectively) do not
> even understand the registration data and governing rules that we are
> about to substantially change. Nor do we have any firm evidence that
> even the minor benefits claimed by the proposers are likely to occur.
>
> I could go on and dispute the co-chairs' reasoning for declaring a
> rough consensus. But I have said it all before and it has been
> disregarded. Although I don't believe I have yet asked them for the
> evidence or statistical reasoning why they assert that this change
> will encourage those who don't declare any End User data now, will
> suddenly decide to provide it after this change.
>
> It is of course total nonsense to suggest that this change will end up
> offering more accurate data on assignments to End Users. It is quite
> possible that those resource holders that currently don't declare End
> User assignment data now, will simply create two appropriately sized,
> anonymous, aggregated objects below each of their allocations. That is
> 'job done' as far as operations is concerned. Those objects will never
> need to be updated again. No one has any clue how much, if any, of
> that address space is in use, by how many End Users with how many
> addresses each, or who the End Users are, or even if the same block of
> address space has been assigned to more than one End User by mistake.
> All that information will be lost. Including one of the basic
> functions of the registry, to ensure uniqueness of address usage.
>
> Quoting statistics on the number of allocations with no assignments is
> of course simply playing with numbers. It adds nothing to this
> discussion, but is intended to look like a supporting argument. A
> perceived problem that needs to be solved, but may not even exist on
> the implied scale. We don't know how many of those allocations are the
> /22 and /24 allocations made during the final stages of runout. These
> were 'intended' to be for new entrants into the industry who planned
> to provide LIR services. They would not be expected to have
> assignments if they were used for their infrastructure. (Or maybe they
> were not allocated as intended?) Many allocations are also made to
> organisations who do not provide LIR services and have no End Users.
> The address space is simply used by their organisation.
>
> Leo's final comment is a good one to end on.
> "Those LIRs that want to share data are already doing so. Those who
> would like to share some data if it were easier to do so will be
> accommodated if this proposal becomes policy."
> This basically sums up everything. ['want' 'like'] The RIPE NCC
> stopped enforcing address policy after runout because they did not
> believe they had any power to do so. Here Leo is suggesting that
> complying with policy is a choice. Some LIRs will choose to comply,
> others will choose not to comply with RIPE policy. Neither this
> community nor the RIPE NCC has any power to enforce any policy on
> operators. We can agree or disagree on any policy we like, but it
> cannot be enforced. RIPE policy has no teeth.
>
> The proposers have assured us that their focus is on providing this
> aggregation feature. So we must be able to assume that they, and the
> co-chairs, have deeply considered the implications of this change to
> the "status:'' attribute. So there shouldn't be any unintended
> consequences...
>
> Hopefully common sense will prevail and we will pause this process to
> assess where we have been, where we are and where we are going. (I
> think that is unlikely to happen...)
>
> cheers
> denis
>
> ========================================================
> DISCLAIMER
> Everything I said above is my personal, professional opinion. It is
> what I believe to be honest and true to the best of my knowledge. No
> one in this industry pays me anything. I have nothing to gain or lose
> by any decision. I push for what I believe is for the good of the
> Internet, in some small way. Nothing I say is ever intended to be
> offensive or a personal attack. Even if I strongly disagree with you
> or question your motives. Politicians question each other's motives
> all the time. RIPE discussion is often as much about politics and self
> interest as it is technical. I have a style of writing that some may
> not be familiar with, others sometimes use it against me. I also have
> OCD. It makes me see the world slightly differently to others. It
> drives my mind's obsessive need for detail. I can not change the way I
> express my detailed opinions. People may choose how to interpret them.
> ========================================================
>
> On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo(a)vegoda.org> wrote:
>>
>> Dear Address Policy WG,
>>
>> There was a consensus on this proposal and we are moving it forward to
>> Last Call. The RIPE NCC will publish an announcement with dates.
>>
>> There was a request, in Rome, for clarity over whether aggregated
>> assignments needed to have a fixed size or could vary. The proposers
>> suggested that a fixed size should be optional.
>>
>> We extended the list discussion by a month and the two issues raised
>> have been addressed.
>>
>> One was End User sites not having the End User's own admin-c instead
>> of the LIR's. There has been extensive discussion of this. One key
>> reason given is that it is common and acceptable to outsource a part
>> of an organisation's operations to another, more skilled, operator.
>> The RIPE NCC's impact analysis noted that the proposal "simply leaves
>> the status quo unchanged." It would not need to update its operational
>> processes.
>>
>> Concerns were also raised that aggregating assignments would impact
>> criminal investigations. But this proposal is intended to improve the
>> quality of data registered by offering LIRs a less arduous way to
>> share registration data. At the end of 2023 there were over 19,000 PA
>> allocations without any assignments. Those LIRs that want to share
>> data are already doing so. Those who would like to share some data if
>> it were easier to do so will be accommodated if this proposal becomes
>> policy.
>>
>> Kind regards,
>>
>> Leo Vegoda, for the Address Policy WG co-chairs
>>
>> --
>>
>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
>
2 years, 1 month
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Jeroen Lauwers
Hi Denis,
We have read through your message several times, but do not see any new arguments against proposal 2023-04 that have not already been discussed at length in the previous phases of the policy development process.
The main purpose of the Concluding phase is to provide an opportunity for people who have missed the previous two phases to oppose the proposal (see ripe-781), not to rehash discussions from the previous phases. Therefore, rather than repeat our answers in this thread, we chose to simply refer you back to our previous discussions in the previous two phases.
Best regards,
Jeroen & Tore
> Op 5 apr 2024, om 16:51 heeft denis walker <ripedenis(a)gmail.com> het volgende geschreven:
>
> Colleagues
>
> I am not surprised this policy proposal (2023-04) has gone to last
> call. I expected this from the start, no matter what anyone said. And
> I won't be surprised when it is approved. I used to wonder why no one
> would even talk about bringing the RIPE Database into the modern
> world. Why continue to use an ancient, broken tool that is barely fit
> for purpose? It is quite obvious now. Playing on the complexity and
> difficulties with using the database allows people to justify changing
> the purpose and the rules, to make it more convenient. That is simpler
> and cheaper than fixing the tool. It is easy for a small vocal group
> to sell 'simple and cheap' to a silent majority. Convenience is easier
> to do than right. But it may have consequences.
>
> The proposers have assured us all that this proposal is about nothing
> more than introducing this optional, minor, inconsequential feature
> that changes nothing. They have argued that the RIPE NCC has
> "repeatedly" verified their claim that this proposal changes nothing
> 'of significance'. This is based on the RIPE NCC legal team's
> confusing impact analysis and the comments made once and referred to
> once by the RIPE NCC Registration Services through messages passed on
> by the policy officer. The legal team declined to clarify the
> confusing wording of their impact analysis. No one from Registration
> Services was willing to discuss the claims that they have been wrongly
> applying the policy for a number of years, or the reason why and when
> they stopped correctly applying the policy. I thought RIPE NCC staff
> were being encouraged to be more involved in community discussions?
>
> It has been said and confirmed recently by several people from the
> community that we no longer understand what some of the registration
> data in the RIPE Database means, why it is there and why we have these
> rules about it. This is despite the actual, current wording of these
> rules having been written into a version of the policy published in
> October 2003 that was authored by some people who are still leading
> members of this community, and at the time were RIPE NCC staff. The
> infamous line being removed by this proposal was a re-wording of
> earlier rules introduced in address policy with a long list of early
> authors, again including some people who are still leading members of
> this community. I asked if any one of these community leaders would
> offer some background information to the community on this, now poorly
> understood, registration data and the rules governing it. That may
> have helped with our current understanding. If we actually understood
> the data and rules that we are about to change, we might have more
> confidence in doing so. But nothing was said on this background.
>
> Europol has expressed serious concerns about these changes. They have
> stated that it takes time for them to consult with national LEAs, the
> EU commision and other partners. If someone had informed them earlier
> of the changes being considered that may affect them, they may have
> had sufficient time to do these consultations. Or perhaps they would
> have been able to express their deep concerns at an early stage,
> before the minds of the vocal few were made up. I did suggest early on
> in the discussion that the RIPE NCC contacts stakeholders of the RIPE
> Database and invite them to join the discussion. I was quickly told by
> other community members on the mailing list that this was not part of
> the policy development process. [Maybe it should be...]
>
> It is extraordinary that we have now reached a position where the
> convenience of a handful of vocal operators in this community is
> considered so important that we must proceed with all haste to
> introduce this optional, minor, inconsequential feature that changes
> nothing, without delay. That is without even a delay to allow Europol
> to complete it's consultations and report back to the working group. I
> saw references recently on the ripe.net website and LinkedIn about
> some productive meeting between the RIPE NCC and some internet
> governance groups. I hope the attitude of the technical community over
> this proposal won't undermine those meeting achievements. A technical
> community that clearly has not watched John Curran's keynote speech at
> NANOG that covers this very situation involving internet governance,
> the technical community and civil society. I would advise you all to
> watch it:
> https://www.youtube.com/watch?v=U1Ip39Qv-Zk
>
> You may question my comments about the vocal few. But the details of
> the who and how many are there for everyone to see in the public
> archive of these mailing lists. Only 22 people commented during the
> months of discussion over 2023-04. Of those, 6 people only made one
> comment and another 6 only two comments. Some of those 22 also opposed
> this proposal. So the number of people who actually expressed support
> is quite small. When you analyse these details for proposals across
> multiple WGs in recent years, and cross reference the who and how
> many, you see that there is a very small number of vocal people who
> tend to dominate these discussions. It is basically this small group
> of people whose voices dictate RIPE policy. The problem there is that
> we may find policy, accidentally or intentionally, following an agenda
> that suits the needs of these people, rather than the wider, silent
> community. Unfortunately, we don't have any other way to do this at
> the moment. However, when a change is controversial, has many serious
> objections and offers so few benefits, to push it through with so few
> supporters is very questionable. Especially as it has been well
> established during the long discussions that we (collectively) do not
> even understand the registration data and governing rules that we are
> about to substantially change. Nor do we have any firm evidence that
> even the minor benefits claimed by the proposers are likely to occur.
>
> I could go on and dispute the co-chairs' reasoning for declaring a
> rough consensus. But I have said it all before and it has been
> disregarded. Although I don't believe I have yet asked them for the
> evidence or statistical reasoning why they assert that this change
> will encourage those who don't declare any End User data now, will
> suddenly decide to provide it after this change.
>
> It is of course total nonsense to suggest that this change will end up
> offering more accurate data on assignments to End Users. It is quite
> possible that those resource holders that currently don't declare End
> User assignment data now, will simply create two appropriately sized,
> anonymous, aggregated objects below each of their allocations. That is
> 'job done' as far as operations is concerned. Those objects will never
> need to be updated again. No one has any clue how much, if any, of
> that address space is in use, by how many End Users with how many
> addresses each, or who the End Users are, or even if the same block of
> address space has been assigned to more than one End User by mistake.
> All that information will be lost. Including one of the basic
> functions of the registry, to ensure uniqueness of address usage.
>
> Quoting statistics on the number of allocations with no assignments is
> of course simply playing with numbers. It adds nothing to this
> discussion, but is intended to look like a supporting argument. A
> perceived problem that needs to be solved, but may not even exist on
> the implied scale. We don't know how many of those allocations are the
> /22 and /24 allocations made during the final stages of runout. These
> were 'intended' to be for new entrants into the industry who planned
> to provide LIR services. They would not be expected to have
> assignments if they were used for their infrastructure. (Or maybe they
> were not allocated as intended?) Many allocations are also made to
> organisations who do not provide LIR services and have no End Users.
> The address space is simply used by their organisation.
>
> Leo's final comment is a good one to end on.
> "Those LIRs that want to share data are already doing so. Those who
> would like to share some data if it were easier to do so will be
> accommodated if this proposal becomes policy."
> This basically sums up everything. ['want' 'like'] The RIPE NCC
> stopped enforcing address policy after runout because they did not
> believe they had any power to do so. Here Leo is suggesting that
> complying with policy is a choice. Some LIRs will choose to comply,
> others will choose not to comply with RIPE policy. Neither this
> community nor the RIPE NCC has any power to enforce any policy on
> operators. We can agree or disagree on any policy we like, but it
> cannot be enforced. RIPE policy has no teeth.
>
> The proposers have assured us that their focus is on providing this
> aggregation feature. So we must be able to assume that they, and the
> co-chairs, have deeply considered the implications of this change to
> the "status:'' attribute. So there shouldn't be any unintended
> consequences...
>
> Hopefully common sense will prevail and we will pause this process to
> assess where we have been, where we are and where we are going. (I
> think that is unlikely to happen...)
>
> cheers
> denis
>
> ========================================================
> DISCLAIMER
> Everything I said above is my personal, professional opinion. It is
> what I believe to be honest and true to the best of my knowledge. No
> one in this industry pays me anything. I have nothing to gain or lose
> by any decision. I push for what I believe is for the good of the
> Internet, in some small way. Nothing I say is ever intended to be
> offensive or a personal attack. Even if I strongly disagree with you
> or question your motives. Politicians question each other's motives
> all the time. RIPE discussion is often as much about politics and self
> interest as it is technical. I have a style of writing that some may
> not be familiar with, others sometimes use it against me. I also have
> OCD. It makes me see the world slightly differently to others. It
> drives my mind's obsessive need for detail. I can not change the way I
> express my detailed opinions. People may choose how to interpret them.
> ========================================================
>
> On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo(a)vegoda.org> wrote:
>>
>> Dear Address Policy WG,
>>
>> There was a consensus on this proposal and we are moving it forward to
>> Last Call. The RIPE NCC will publish an announcement with dates.
>>
>> There was a request, in Rome, for clarity over whether aggregated
>> assignments needed to have a fixed size or could vary. The proposers
>> suggested that a fixed size should be optional.
>>
>> We extended the list discussion by a month and the two issues raised
>> have been addressed.
>>
>> One was End User sites not having the End User's own admin-c instead
>> of the LIR's. There has been extensive discussion of this. One key
>> reason given is that it is common and acceptable to outsource a part
>> of an organisation's operations to another, more skilled, operator.
>> The RIPE NCC's impact analysis noted that the proposal "simply leaves
>> the status quo unchanged." It would not need to update its operational
>> processes.
>>
>> Concerns were also raised that aggregating assignments would impact
>> criminal investigations. But this proposal is intended to improve the
>> quality of data registered by offering LIRs a less arduous way to
>> share registration data. At the end of 2023 there were over 19,000 PA
>> allocations without any assignments. Those LIRs that want to share
>> data are already doing so. Those who would like to share some data if
>> it were easier to do so will be accommodated if this proposal becomes
>> policy.
>>
>> Kind regards,
>>
>> Leo Vegoda, for the Address Policy WG co-chairs
>>
>> --
>>
>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
2 years, 1 month
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by denis walker
Colleagues
I am not surprised this policy proposal (2023-04) has gone to last
call. I expected this from the start, no matter what anyone said. And
I won't be surprised when it is approved. I used to wonder why no one
would even talk about bringing the RIPE Database into the modern
world. Why continue to use an ancient, broken tool that is barely fit
for purpose? It is quite obvious now. Playing on the complexity and
difficulties with using the database allows people to justify changing
the purpose and the rules, to make it more convenient. That is simpler
and cheaper than fixing the tool. It is easy for a small vocal group
to sell 'simple and cheap' to a silent majority. Convenience is easier
to do than right. But it may have consequences.
The proposers have assured us all that this proposal is about nothing
more than introducing this optional, minor, inconsequential feature
that changes nothing. They have argued that the RIPE NCC has
"repeatedly" verified their claim that this proposal changes nothing
'of significance'. This is based on the RIPE NCC legal team's
confusing impact analysis and the comments made once and referred to
once by the RIPE NCC Registration Services through messages passed on
by the policy officer. The legal team declined to clarify the
confusing wording of their impact analysis. No one from Registration
Services was willing to discuss the claims that they have been wrongly
applying the policy for a number of years, or the reason why and when
they stopped correctly applying the policy. I thought RIPE NCC staff
were being encouraged to be more involved in community discussions?
It has been said and confirmed recently by several people from the
community that we no longer understand what some of the registration
data in the RIPE Database means, why it is there and why we have these
rules about it. This is despite the actual, current wording of these
rules having been written into a version of the policy published in
October 2003 that was authored by some people who are still leading
members of this community, and at the time were RIPE NCC staff. The
infamous line being removed by this proposal was a re-wording of
earlier rules introduced in address policy with a long list of early
authors, again including some people who are still leading members of
this community. I asked if any one of these community leaders would
offer some background information to the community on this, now poorly
understood, registration data and the rules governing it. That may
have helped with our current understanding. If we actually understood
the data and rules that we are about to change, we might have more
confidence in doing so. But nothing was said on this background.
Europol has expressed serious concerns about these changes. They have
stated that it takes time for them to consult with national LEAs, the
EU commision and other partners. If someone had informed them earlier
of the changes being considered that may affect them, they may have
had sufficient time to do these consultations. Or perhaps they would
have been able to express their deep concerns at an early stage,
before the minds of the vocal few were made up. I did suggest early on
in the discussion that the RIPE NCC contacts stakeholders of the RIPE
Database and invite them to join the discussion. I was quickly told by
other community members on the mailing list that this was not part of
the policy development process. [Maybe it should be...]
It is extraordinary that we have now reached a position where the
convenience of a handful of vocal operators in this community is
considered so important that we must proceed with all haste to
introduce this optional, minor, inconsequential feature that changes
nothing, without delay. That is without even a delay to allow Europol
to complete it's consultations and report back to the working group. I
saw references recently on the ripe.net website and LinkedIn about
some productive meeting between the RIPE NCC and some internet
governance groups. I hope the attitude of the technical community over
this proposal won't undermine those meeting achievements. A technical
community that clearly has not watched John Curran's keynote speech at
NANOG that covers this very situation involving internet governance,
the technical community and civil society. I would advise you all to
watch it:
https://www.youtube.com/watch?v=U1Ip39Qv-Zk
You may question my comments about the vocal few. But the details of
the who and how many are there for everyone to see in the public
archive of these mailing lists. Only 22 people commented during the
months of discussion over 2023-04. Of those, 6 people only made one
comment and another 6 only two comments. Some of those 22 also opposed
this proposal. So the number of people who actually expressed support
is quite small. When you analyse these details for proposals across
multiple WGs in recent years, and cross reference the who and how
many, you see that there is a very small number of vocal people who
tend to dominate these discussions. It is basically this small group
of people whose voices dictate RIPE policy. The problem there is that
we may find policy, accidentally or intentionally, following an agenda
that suits the needs of these people, rather than the wider, silent
community. Unfortunately, we don't have any other way to do this at
the moment. However, when a change is controversial, has many serious
objections and offers so few benefits, to push it through with so few
supporters is very questionable. Especially as it has been well
established during the long discussions that we (collectively) do not
even understand the registration data and governing rules that we are
about to substantially change. Nor do we have any firm evidence that
even the minor benefits claimed by the proposers are likely to occur.
I could go on and dispute the co-chairs' reasoning for declaring a
rough consensus. But I have said it all before and it has been
disregarded. Although I don't believe I have yet asked them for the
evidence or statistical reasoning why they assert that this change
will encourage those who don't declare any End User data now, will
suddenly decide to provide it after this change.
It is of course total nonsense to suggest that this change will end up
offering more accurate data on assignments to End Users. It is quite
possible that those resource holders that currently don't declare End
User assignment data now, will simply create two appropriately sized,
anonymous, aggregated objects below each of their allocations. That is
'job done' as far as operations is concerned. Those objects will never
need to be updated again. No one has any clue how much, if any, of
that address space is in use, by how many End Users with how many
addresses each, or who the End Users are, or even if the same block of
address space has been assigned to more than one End User by mistake.
All that information will be lost. Including one of the basic
functions of the registry, to ensure uniqueness of address usage.
Quoting statistics on the number of allocations with no assignments is
of course simply playing with numbers. It adds nothing to this
discussion, but is intended to look like a supporting argument. A
perceived problem that needs to be solved, but may not even exist on
the implied scale. We don't know how many of those allocations are the
/22 and /24 allocations made during the final stages of runout. These
were 'intended' to be for new entrants into the industry who planned
to provide LIR services. They would not be expected to have
assignments if they were used for their infrastructure. (Or maybe they
were not allocated as intended?) Many allocations are also made to
organisations who do not provide LIR services and have no End Users.
The address space is simply used by their organisation.
Leo's final comment is a good one to end on.
"Those LIRs that want to share data are already doing so. Those who
would like to share some data if it were easier to do so will be
accommodated if this proposal becomes policy."
This basically sums up everything. ['want' 'like'] The RIPE NCC
stopped enforcing address policy after runout because they did not
believe they had any power to do so. Here Leo is suggesting that
complying with policy is a choice. Some LIRs will choose to comply,
others will choose not to comply with RIPE policy. Neither this
community nor the RIPE NCC has any power to enforce any policy on
operators. We can agree or disagree on any policy we like, but it
cannot be enforced. RIPE policy has no teeth.
The proposers have assured us that their focus is on providing this
aggregation feature. So we must be able to assume that they, and the
co-chairs, have deeply considered the implications of this change to
the "status:'' attribute. So there shouldn't be any unintended
consequences...
Hopefully common sense will prevail and we will pause this process to
assess where we have been, where we are and where we are going. (I
think that is unlikely to happen...)
cheers
denis
========================================================
DISCLAIMER
Everything I said above is my personal, professional opinion. It is
what I believe to be honest and true to the best of my knowledge. No
one in this industry pays me anything. I have nothing to gain or lose
by any decision. I push for what I believe is for the good of the
Internet, in some small way. Nothing I say is ever intended to be
offensive or a personal attack. Even if I strongly disagree with you
or question your motives. Politicians question each other's motives
all the time. RIPE discussion is often as much about politics and self
interest as it is technical. I have a style of writing that some may
not be familiar with, others sometimes use it against me. I also have
OCD. It makes me see the world slightly differently to others. It
drives my mind's obsessive need for detail. I can not change the way I
express my detailed opinions. People may choose how to interpret them.
========================================================
On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo(a)vegoda.org> wrote:
>
> Dear Address Policy WG,
>
> There was a consensus on this proposal and we are moving it forward to
> Last Call. The RIPE NCC will publish an announcement with dates.
>
> There was a request, in Rome, for clarity over whether aggregated
> assignments needed to have a fixed size or could vary. The proposers
> suggested that a fixed size should be optional.
>
> We extended the list discussion by a month and the two issues raised
> have been addressed.
>
> One was End User sites not having the End User's own admin-c instead
> of the LIR's. There has been extensive discussion of this. One key
> reason given is that it is common and acceptable to outsource a part
> of an organisation's operations to another, more skilled, operator.
> The RIPE NCC's impact analysis noted that the proposal "simply leaves
> the status quo unchanged." It would not need to update its operational
> processes.
>
> Concerns were also raised that aggregating assignments would impact
> criminal investigations. But this proposal is intended to improve the
> quality of data registered by offering LIRs a less arduous way to
> share registration data. At the end of 2023 there were over 19,000 PA
> allocations without any assignments. Those LIRs that want to share
> data are already doing so. Those who would like to share some data if
> it were easier to do so will be accommodated if this proposal becomes
> policy.
>
> Kind regards,
>
> Leo Vegoda, for the Address Policy WG co-chairs
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
2 years, 1 month
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
Hi Denis,
It would appear to me that your opposition to 2023-04 is largely based
on the premise that it introduces a new possibility for anonymous
assignments, a change which you do not want to see happen. This premise
also appears to underpin many of your musings in your «The bigger
picture» message. I disagree with this premise, as I believe this
possibility is already there in current policy.
Rather than decide to agree to disagree on that point, or endlessly
quarrel about it, I realised that it does not really matter what you or
I believe the policy requirements are - what matters is the RIPE
NCC's understanding of the policy and how they are implementing it. So
I simply asked their Policy Officer (Angela) to clarify this.
Her answers, which I with permission quote in full along with my
questions below, unequivocally confirms that that current policy does
indeed allow assignments to be registered anonymously in the RIPE
database. Hence, your opposition to proposal 2023-04 in this regard
appears to rest on a fundamentally flawed assumption.
Tore: «The context here is an IPv4 assignment that is not made to an
individual and that is not used solely for the connection of an End
User to a service provider.
1. Does current address policy as implemented by the NCC allow an End
User to delegate/outsource the contact information represented by the
mandatory "tech-c" and "admin-c" attributes to another entity,
typically (but not necessarily) the issuing LIR? (There does not appear
to be any disagreement on this point, but I include this question
anyway in case we are both wrong.)»
Angela: «Yes, you are correct. An End User is allowed to
delegate/outsource the contact information represented by the mandatory
"tech-c" and "admin-c" attributes to another entity, typically (but not
necessarily) the issuing LIR.»
Tore: «2. Assuming "yes" to question 1, for an assignment where the
"tech-c" and "admin-c" has been delegated in this manner: Does current
address policy require the corresponding "inetnum" database object to
contain some additional contact information, that is not delegated to a
third party, i.e., it must be refer to a point of contact that is
handled in-house by the End User him/herself?»
Angela: «The current address policy does not require the corresponding
"inetnum" database object to contain some additional contact
information that is not delegated to a third party.
LIRs can use the “netname” attribute to link assignments to end users
and their contact details in internal records.
There is a particular case: when the RIPE NCC receives a request for
assigning an AS number to an End User using a PA assignment, the IPv4
network to be announced by the requested AS must be registered in an
“inetnum” object showing the End User’s name. This can be in the
"descr” attribute or recursively in the "org" object added as
attribute.»
Tore: «3. Assuming "yes" to question 2, what kind of other contact
information is required, and in which "inetnum" database attribute(s)
must it be located? Here are some possible examples off the top of my
head, would any or all of these satisfy the policy requirement for an
in-house non-delegated contact information?
1. A street address
2. A (snail) mail address
3. An e-mail address
4. A fax number
5. A phone number»
Angela: «The answer to question 2 was “no’, however one way to record
End Users’ contact details is to create an “org” object to be added as
optional attribute in the “inetnum” object.
In “org” objects name, address and email are mandatory.
In “inetnum” objects the mandatory contact information are “admin-c”
and “tech-c”.»
Tore: «4. Assuming "yes" to question 2, is it mandatory to identify the
End User by name, or would it be sufficient with, e.g., a street
address without an organisation name (assuming there is only a single
entity located at that address), a post box snail mail address, a
generic user123(a)gmail.com e-mail address, or a phone/fax number that is
not listed in the white or yellow pages?»
Angela: «The answer to question 2 was “no’,...»
Tore (in a new e-mail): «I will ask you a couple of follow-up questions
just to make absolutely, 150%, certain I do not misunderstand you and
end up misrepresenting you to the mailing list:
1. When you write «LIRs can use the “netname” attribute to link
assignments to end users and their contact details in internal
records», this "can" is a MAY, not a MUST, to use IETF lingo? That
is, the LIR is free to instead use the "inetnum" attribute, i.e.,
the IP address(es), to link the assignment to the End User in their
internal record? If that is the case, would it be correct to say
that the LIR are free to set the "netname" attribute to essentially
anything, including a meaningless string of random characters?»
Angela: «Your interpretation is correct, the answer is yes to all
three questions.
Please also consider that the "netname" is not required to be
unique, LIRs can use the same one for multiple assignments.»
Tore: «2. When you write «one way to record End Users’ contact
details is to create an “org” object to be added as optional
attribute in the “inetnum” object», this is also a MAY, not a MUST?
That is, the LIR is free to omit the "org" attribute, even though
the only other contact information contained in the object is the
(LIR-delegated) "tech-c" and "admin-c" attributes?»
Angela: «Yes, the LIR is free to omit the "org" attribute, even
though the only other contact information contained in the object is
the (LIR-delegated) "tech-c" and "admin-c" attributes.
If the LIR requests an AS number on behalf of an end user to
announce a PA assignment, then the PA assignment MUST include the
legal name of the end user in the "descr" attribute or in the '"org"
object set as "org" attribute in the "inetnum" object.»
Tore: «3. To use a concrete example: Let's say «SuperLIR GmbH»
delegated 192.0.2.0/25 to the End User «CarFactory GmbH».
(CarFactory GmbH is not an individual, and the assignment is not
used solely for the connection to the provider, nor to justify an
application for an AS number). SuperLIR inserts the following
minimal database object:
inetnum: 192.0.2.0 - 192.0.2.128
netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ
country: DE
admin-c: SUPERLIR-NOC-RIPE
tech-c: SUPERLIR-NOC-RIPE
status: ASSIGNED PA
mnt-by: SUPERLIR-MNT
source: RIPE
In the event of an audit, SuperLIR GmbH will be able to inform the
RIPE NCC auditors that this object has been delegated to CarFactory
GmbH.
Is the above registration compliant with current IPv4 address
policy, or will the auditors demand any kind of changes be made?»
Angela: «The above registration compliant with current IPv4 address
policy. During an audit we could ask the LIR whether the assignment
is still in use. It does not matter for the RIPE NCC who is using
the assignment, as long as the LIR is maintaining the registration
up to date and is able to contact the end user. This means that if
the LIR moves the assignment delegation from CarFactory GmbH to
another end user in the same country for which is acting as "admin-
c" and "tech-c", the "inetnum" object would still be valid. It is
the LIR's responsibility to keep their internal records up to date
accordingly with the new end user.»
In light of the above, I hope that you will reconsider your opposing
arguments and either withdraw them or restate them in a way that does
not rely on this incorrect assumption. Anticipating this, I will only
address your remaining points that are not based on the
misunderstanding that 2023-04 opens up for anonymous assignments.
> It should not be permitted to aggregate a single assignment to a
> single End User.
While I agree that "aggregating" a single assignment seems like a
pointless practice, I do not quite see why it is necessary to introduce
policy language to ban it.
It is, as I understand it, possible to use AGGREGATED-BY-LIR with an
assignment-size identical to the prefix length in the inet6num
attribute today, but I cannot find a single example of this being done.
(Presumably because it is pointless to do so.)
It is also possible today to "aggregate" a single IPv4 assignment under
the «solely for connection» exception. Whether or not that has been
done is impossible for me to say, but even if it has I fail to
understand why it would constitute an actual problem.
I am not being totally dismissive towards adding a condition à la «an
object with status AGGREGATED-BY-LIR must contain at least two
individual assignments» to the proposal, but I would first like to
better understand the reasons why you feel this is a necessity.
> 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.
In IPv6, /48 is the limit beyond which extra documentation requirements
("need basis") kicks in. Assignments /48 or longer can be freely made
by an LIR without any supporting documentation, and this is presumably
why such assignments can be freely registered under a single
AGGREGATED-BY-LIR object. In other words, assignments shorter than /48
has more stringent documentation requirements, and therefore also more
stringent registration requirements.
See https://www.ripe.net/publications/docs/ripe-738#assignments_shorter
As there is no "need basis" for assignments in IPv4 regardless of size,
there simply is no equivalent value, not /24 nor anything else. (Well,
I suppose you could say that /0 is the equivalent value.)
>
> > > > 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?
No, it does not say anything about the number of addresses in the
assignment nor the layer-1 technology used. It is very common for
point-to-point links (the example given in section 6.2) to be assigned
/31 or /30. If the service provider and/or the customer is using a
first-hop redundancy protocol such as VRRP, it is necessary to assign a
/29 or larger.
In any case, there is no technological reason nor any policy limitation
that would prevent a service provider from assigning a preposterously
large prefix to a point-to-point link, like a /16, let's say.
> 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?
We do not expect the RIPE NCC to start a mass migration project as a
result of this policy proposal. It is our intention that assignments
made under the old policy would be grandfathered in, similar to how you
still see many objects with the obsoleted INFRA-AW tag remain in the
database today. LIRs would of course be free to change the status value
at any point, should they want to do so.
>
> 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.
You do not know that today, either, when it comes to aggregated
assignments made under the «solely for the connection» exception in
current IPv4 policy.
Such objects do not contain an assignment-size attribute, nor does
policy demand that all individual assignments contained within are of a
specific and uniform prefix length. Therefore, such assignments may
contain a hodgepodge of DSL customers, FTTH customers, business
customers, connected with or without VRRP, and so on. This would
continue to be permitted with AGGREGATED-BY-LIR.
Tore
2 years, 7 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Sebastian Graf
Dear Tore/Denis:
If we are looking at the Policy Language, then i'm not certain we are
reading the same things into it.
Or maybe i missed something. Feel free to point out the corresponding
section of the policy to me. I'm more than happy to update my views if
strong evidence is presented.
As a small LIR ... I may not see all edge cases.... but...... So feel
free to point out anything important that i may have missed.
Lets look at the actual language in the policy:
> "All assignments and allocations must be registered in the RIPE
Database. This is necessary to ensure uniqueness and to support network
operations."
The way i read it, this point is filled both with the current state of
things, and also if we have an aggregated status. Space would still be
registered. So the question is what kind of data needs to accompany it.
So lets look at what needs to be documented:
> "Registration data (range, contact information, status etc.) must be
correct at all times (i.e. they have to be maintained)."
I think you are arguing what both of you are considering "contact
information". It does NOT say we state to put personally identifyable
information into it.
If we read the text literally, then only putting enough information to
establish a contact (ie: contact information) would theoretically be
sufficient.
So theoretically, a "proxy" type of setup for email/postal mail/...
could be permissiable as long as any communication/... is forwarded to
the the actual responisble party.
In fact i would argue for most businesses (End-User or ISP) this is
already the case if they make use of "role" contacts for their
admin/noc/abuse/... handling.
> "Registration data (range, contact information, status etc.) must be
correct at all times (i.e. they have to be maintained)."
The other thing that i do not read from the statement is where it asks
to put "contact information" for the End-User. It simply reads contact
information (one could theoretically interpret this as "contact
information for the party that is responsible for managing the space....).
ANYWAY....
I still do not feel anything of significance would be lost, if something
could be lost at all. My personal opinion goes the other way.....I
suspect, if anything aggregated status could potentially lead to more
accurate data. Let me explain: With the aggregation we gain better
understanding of the network usage. PLUS the ability to create more
specific assignments (under the aggregated). So This way, i feel more
usable data would be int the database, compared to now.
This would also be in line with the goals in Section 3.0 - Point 2
"Agregation: Distributing IPv4 addresses in an hierarchical manner
permits the aggregation of routing information.".
If we look at the goal for registration: "Registration: The provision of
a public registry documenting address space allocations and assignments
must exist. This is necessary to ensure uniqueness and to provide
information for Internet troubleshooting at all levels.".
If we consider the usefulnes of data entered into the ripe-db for this
purpose, then most useful will be the ISP contact information. Contact
information for End-Users (could be an ISP as well) would also be useful
in some cases. Personal Information for "individual" type end users (ie:
Fred Testuser's DSL Line that comes with a Public IPv4 Address)....to a
lesser extend.
If we look at Section 3.1 ...it reads "Internet Registries (IRs) have a
*duty of confidentiality to their registrants*. Information passed to an
IR must be securely stored and *must not be distributed wider than
necessary within the IR*.".
So i am not certain why you are trying to force more data than actually
required/useful into the db. And yes in this context i would consider
LIR's in this to be part of this as some type of "local" IR's.
During the writing of this email, i realised that you (denis/tore) may
consider the need/usecase for adding a "restricted" flag into the DB,
that would allow adding information, that is only shown to a select
audience (ie: law enforcment, ripe staff and Ripe-Members) - wich could
be used to publish PII data. HOWEVER doing something like that would
"extend" the existing usecase(s) of the DB and dataentry required - as
such this should be in a different Policy Proposal/wg-discussion. Feel
free to put one forward, that we can discuss....
Regards
Sebastian
On 1/11/24 13:11, Tore Anderson wrote:
> Hi Jan,
>
> On 11/01/24 10:19, Jan Ingvoldstad wrote:
>>
>> On Thu, Jan 11, 2024 at 9:45 AM Tore Anderson <tore(a)fud.no> wrote:
>>
>> On 11/01/24 03:20, denis walker wrote:
>>
>> > This is total madness. You keep saying you have no intention of
>> > changing anything else. You keep saying the wording change
>> actually
>> > changes nothing in practice. Some other people don't agree with
>> you.
>> > Just don't change wording that you claim changes NOTHING and has
>> > nothing to do with aggregation and everyone is happy. The fact
>> that
>> > you are pushing so hard to make this wording change, you refuse to
>> > back down or compromise, you insist on changing wording that
>> changes
>> > nothing and has nothing to do with aggregation...proves that you
>> don't
>> > believe that yourself. The fact is, I suspect that this is the
>> real
>> > change you want. You want to drop the current policy
>> requirement to
>> > define assignments with End User contacts. It is the aggregation
>> that
>> > is the side issue here. There is no other explanation for why
>> you are
>> > insisting so strongly on changing wording that changes nothing.
>>
>> Here we find ourselves in conspiracy theory land, frankly.
>>
>>
>> Uh. While questioning your motives is perhaps a bit rude, this is WAY
>> over the top, Tore.
>>
>> Please retract this weird accusation, I really don't understand your
>> motives for trying to label this as having to do with a conspiracy
>> theory. It tarnishes the discussion.
>
> This goes far beyond «questioning our motives». There is an assertion
> of "proof" that Jeroen deliberately make statements that we do not
> believe ourselves, in other words that we are lying to the working
> group. It is suggested that we are maliciously attempting to deceive
> the working group as to our true motives for submitting the policy
> proposal and what changes it will effect, and that the stated motive –
> introducing AGGREGATED-BY-LIR – is a mere "side issue" which is not
> our true, hidden, motive.
>
> Presumably the RIPE NCC must also be actively participating in this
> deception, or at the very least turn a blind eye to it.
>
> This ticks all the boxes in the Wikipedia definition of a conspiracy
> theory, with the possible exception that Jeroen and I could not
> reasonably be classified as a «powerful group».
>
> That said, labels are unimportant, so consider the statement
> retracted. Let us instead say that we vehemently disagree with the
> allegation that there are any ulterior motives behind 2023-04 and that
> we are actively attempting to deceive the working group in any way.
>
>
>> While you seem to argue that the RIPE NCC is both omniscient and
>> omnicompetent, I do not think it is that easy.
>>
>> I simply think that the RIPE NCC and you are mistaken.
>
> That is fair enough. We note your disagreement with the RIPE NCC as
> well, which we take to mean you do not allege that we are actively and
> intentionally misrepresenting the RIPE NCC's position in our messages.
> That is something, at least.
>
>
>> Continously appealing to RIPE NCC as the authority of policy and
>> policy interpretation is not a good thing.
>
> The RIPE NCC is the secretariat of the RIPE Community and is delegated
> the task of implementing and enforcing the RIPE Community policies, as
> well as to providing training to the LIRs on how to operationalise
> said policies. If that is not an authority worth paying attention to,
> I do not know what is.
>
> After all, any LIR which prefers the RIPE NCC interpretation of the
> policy in this regard is may simply adhere to it and act accordingly,
> and this is commonly done today. Thus the RIPE NCC's interpretation of
> the policy – mistaken or not – ends up becoming the (de facto) way the
> policy is implemented anyway.
>
>
> Tore & Jeroen
>
>
>
>
2 years, 4 months
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Marco Schmidt
Hello,
First, let me note that this is not a comment on the policy discussion,
which has now concluded, but a separate response regarding how we ensure
compliance with RIPE Policy. We would like to clarify some aspects that
may be unclear to the community.
The RIPE NCC has always emphasised the importance of documenting
networks through assignments, and we are consistent in what we consider
valid contact information for End User/customer assignments. This stance
has not changed because of IPv4 runout. We do consider the member’s
contact details to be valid contact information for the customer if this
is what the member and their customer have agreed suits their business
needs.
There are a number of policies we follow for ensuring correct contact
information. The policy on IPv4 allocation, RIPE-804, requires that
contact information in the database must be correct [1]. The same policy
also mentions that an LIR can be closed if it “consistently violates the
RIPE community’s policies” [2]. We build on this in our public closure
procedure, where we state that incorrect registration in the RIPE
Database can lead to termination of a membership [3].
Together, this means the RIPE NCC is empowered to close down a member
for incorrect contact information in the database, and this includes
incorrect data about a member’s customers. When we discover incorrect
information, our practice is to follow a collaborative approach in which
we help our members correct the errors. This is in line with our overall
mission to support the broader Internet community, not through punitive
measures, but through educating members in our processes for requests,
ARCs and training courses so that we can collectively work to create an
accurate registry. See also our impact analysis for policy proposal
2017-02 (“Regular abuse-c Validation”) for a detailed description of how
we work with resource holders to correct information before considering
closure, in this case regarding “abuse-c:” contacts [4].
We do not consider it beneficial to the Internet community or our
members to immediately terminate memberships. However, if a member
submits repeated and intentionally incorrect contact information, this
will result in stronger actions on our end.
Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC
[1] IPv4 Address Allocation and Assignment Policies for the RIPE NCC
Service Region: https://www.ripe.net/publications/docs/ripe-804/#4
[2] Idem: https://www.ripe.net/publications/docs/ripe-804/#9
[3] Closure of Members, Deregistration of Internet Resources and Legacy
Internet Resources: https://www.ripe.net/publications/docs/ripe-808/#a1211c
[4] Regular abuse-c Validation:
https://www.ripe.net/membership/policies/proposals/2017-02/#relevant-ripe-p…
On 05/04/2024 16:51, denis walker wrote:
> Colleagues
>
> I am not surprised this policy proposal (2023-04) has gone to last
> call. I expected this from the start, no matter what anyone said. And
> I won't be surprised when it is approved. I used to wonder why no one
> would even talk about bringing the RIPE Database into the modern
> world. Why continue to use an ancient, broken tool that is barely fit
> for purpose? It is quite obvious now. Playing on the complexity and
> difficulties with using the database allows people to justify changing
> the purpose and the rules, to make it more convenient. That is simpler
> and cheaper than fixing the tool. It is easy for a small vocal group
> to sell 'simple and cheap' to a silent majority. Convenience is easier
> to do than right. But it may have consequences.
>
> The proposers have assured us all that this proposal is about nothing
> more than introducing this optional, minor, inconsequential feature
> that changes nothing. They have argued that the RIPE NCC has
> "repeatedly" verified their claim that this proposal changes nothing
> 'of significance'. This is based on the RIPE NCC legal team's
> confusing impact analysis and the comments made once and referred to
> once by the RIPE NCC Registration Services through messages passed on
> by the policy officer. The legal team declined to clarify the
> confusing wording of their impact analysis. No one from Registration
> Services was willing to discuss the claims that they have been wrongly
> applying the policy for a number of years, or the reason why and when
> they stopped correctly applying the policy. I thought RIPE NCC staff
> were being encouraged to be more involved in community discussions?
>
> It has been said and confirmed recently by several people from the
> community that we no longer understand what some of the registration
> data in the RIPE Database means, why it is there and why we have these
> rules about it. This is despite the actual, current wording of these
> rules having been written into a version of the policy published in
> October 2003 that was authored by some people who are still leading
> members of this community, and at the time were RIPE NCC staff. The
> infamous line being removed by this proposal was a re-wording of
> earlier rules introduced in address policy with a long list of early
> authors, again including some people who are still leading members of
> this community. I asked if any one of these community leaders would
> offer some background information to the community on this, now poorly
> understood, registration data and the rules governing it. That may
> have helped with our current understanding. If we actually understood
> the data and rules that we are about to change, we might have more
> confidence in doing so. But nothing was said on this background.
>
> Europol has expressed serious concerns about these changes. They have
> stated that it takes time for them to consult with national LEAs, the
> EU commision and other partners. If someone had informed them earlier
> of the changes being considered that may affect them, they may have
> had sufficient time to do these consultations. Or perhaps they would
> have been able to express their deep concerns at an early stage,
> before the minds of the vocal few were made up. I did suggest early on
> in the discussion that the RIPE NCC contacts stakeholders of the RIPE
> Database and invite them to join the discussion. I was quickly told by
> other community members on the mailing list that this was not part of
> the policy development process. [Maybe it should be...]
>
> It is extraordinary that we have now reached a position where the
> convenience of a handful of vocal operators in this community is
> considered so important that we must proceed with all haste to
> introduce this optional, minor, inconsequential feature that changes
> nothing, without delay. That is without even a delay to allow Europol
> to complete it's consultations and report back to the working group. I
> saw references recently on the ripe.net website and LinkedIn about
> some productive meeting between the RIPE NCC and some internet
> governance groups. I hope the attitude of the technical community over
> this proposal won't undermine those meeting achievements. A technical
> community that clearly has not watched John Curran's keynote speech at
> NANOG that covers this very situation involving internet governance,
> the technical community and civil society. I would advise you all to
> watch it:
> https://www.youtube.com/watch?v=U1Ip39Qv-Zk
>
> You may question my comments about the vocal few. But the details of
> the who and how many are there for everyone to see in the public
> archive of these mailing lists. Only 22 people commented during the
> months of discussion over 2023-04. Of those, 6 people only made one
> comment and another 6 only two comments. Some of those 22 also opposed
> this proposal. So the number of people who actually expressed support
> is quite small. When you analyse these details for proposals across
> multiple WGs in recent years, and cross reference the who and how
> many, you see that there is a very small number of vocal people who
> tend to dominate these discussions. It is basically this small group
> of people whose voices dictate RIPE policy. The problem there is that
> we may find policy, accidentally or intentionally, following an agenda
> that suits the needs of these people, rather than the wider, silent
> community. Unfortunately, we don't have any other way to do this at
> the moment. However, when a change is controversial, has many serious
> objections and offers so few benefits, to push it through with so few
> supporters is very questionable. Especially as it has been well
> established during the long discussions that we (collectively) do not
> even understand the registration data and governing rules that we are
> about to substantially change. Nor do we have any firm evidence that
> even the minor benefits claimed by the proposers are likely to occur.
>
> I could go on and dispute the co-chairs' reasoning for declaring a
> rough consensus. But I have said it all before and it has been
> disregarded. Although I don't believe I have yet asked them for the
> evidence or statistical reasoning why they assert that this change
> will encourage those who don't declare any End User data now, will
> suddenly decide to provide it after this change.
>
> It is of course total nonsense to suggest that this change will end up
> offering more accurate data on assignments to End Users. It is quite
> possible that those resource holders that currently don't declare End
> User assignment data now, will simply create two appropriately sized,
> anonymous, aggregated objects below each of their allocations. That is
> 'job done' as far as operations is concerned. Those objects will never
> need to be updated again. No one has any clue how much, if any, of
> that address space is in use, by how many End Users with how many
> addresses each, or who the End Users are, or even if the same block of
> address space has been assigned to more than one End User by mistake.
> All that information will be lost. Including one of the basic
> functions of the registry, to ensure uniqueness of address usage.
>
> Quoting statistics on the number of allocations with no assignments is
> of course simply playing with numbers. It adds nothing to this
> discussion, but is intended to look like a supporting argument. A
> perceived problem that needs to be solved, but may not even exist on
> the implied scale. We don't know how many of those allocations are the
> /22 and /24 allocations made during the final stages of runout. These
> were 'intended' to be for new entrants into the industry who planned
> to provide LIR services. They would not be expected to have
> assignments if they were used for their infrastructure. (Or maybe they
> were not allocated as intended?) Many allocations are also made to
> organisations who do not provide LIR services and have no End Users.
> The address space is simply used by their organisation.
>
> Leo's final comment is a good one to end on.
> "Those LIRs that want to share data are already doing so. Those who
> would like to share some data if it were easier to do so will be
> accommodated if this proposal becomes policy."
> This basically sums up everything. ['want' 'like'] The RIPE NCC
> stopped enforcing address policy after runout because they did not
> believe they had any power to do so. Here Leo is suggesting that
> complying with policy is a choice. Some LIRs will choose to comply,
> others will choose not to comply with RIPE policy. Neither this
> community nor the RIPE NCC has any power to enforce any policy on
> operators. We can agree or disagree on any policy we like, but it
> cannot be enforced. RIPE policy has no teeth.
>
> The proposers have assured us that their focus is on providing this
> aggregation feature. So we must be able to assume that they, and the
> co-chairs, have deeply considered the implications of this change to
> the "status:'' attribute. So there shouldn't be any unintended
> consequences...
>
> Hopefully common sense will prevail and we will pause this process to
> assess where we have been, where we are and where we are going. (I
> think that is unlikely to happen...)
>
> cheers
> denis
>
> ========================================================
> DISCLAIMER
> Everything I said above is my personal, professional opinion. It is
> what I believe to be honest and true to the best of my knowledge. No
> one in this industry pays me anything. I have nothing to gain or lose
> by any decision. I push for what I believe is for the good of the
> Internet, in some small way. Nothing I say is ever intended to be
> offensive or a personal attack. Even if I strongly disagree with you
> or question your motives. Politicians question each other's motives
> all the time. RIPE discussion is often as much about politics and self
> interest as it is technical. I have a style of writing that some may
> not be familiar with, others sometimes use it against me. I also have
> OCD. It makes me see the world slightly differently to others. It
> drives my mind's obsessive need for detail. I can not change the way I
> express my detailed opinions. People may choose how to interpret them.
> ========================================================
>
> On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo(a)vegoda.org> wrote:
>> Dear Address Policy WG,
>>
>> There was a consensus on this proposal and we are moving it forward to
>> Last Call. The RIPE NCC will publish an announcement with dates.
>>
>> There was a request, in Rome, for clarity over whether aggregated
>> assignments needed to have a fixed size or could vary. The proposers
>> suggested that a fixed size should be optional.
>>
>> We extended the list discussion by a month and the two issues raised
>> have been addressed.
>>
>> One was End User sites not having the End User's own admin-c instead
>> of the LIR's. There has been extensive discussion of this. One key
>> reason given is that it is common and acceptable to outsource a part
>> of an organisation's operations to another, more skilled, operator.
>> The RIPE NCC's impact analysis noted that the proposal "simply leaves
>> the status quo unchanged." It would not need to update its operational
>> processes.
>>
>> Concerns were also raised that aggregating assignments would impact
>> criminal investigations. But this proposal is intended to improve the
>> quality of data registered by offering LIRs a less arduous way to
>> share registration data. At the end of 2023 there were over 19,000 PA
>> allocations without any assignments. Those LIRs that want to share
>> data are already doing so. Those who would like to share some data if
>> it were easier to do so will be accommodated if this proposal becomes
>> policy.
>>
>> Kind regards,
>>
>> Leo Vegoda, for the Address Policy WG co-chairs
>>
>> --
>>
>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
2 years
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
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(a)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
2 years, 7 months
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Jeroen Lauwers
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. 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. And then we not even talking about if abusers would even try to write the proper contact information or privacy laws like GDPR.
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. 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.
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. At the moment the IP space without any child assignment in the database is growing every year. And I think we both agree that how more space is covered in the DB the better it is for the community.
Kind regards,
Jeroen
Op 22 sep. 2023, om 05:52 heeft denis walker <ripedenis(a)gmail.com<mailto:ripedenis@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(a)fud.no<mailto:tore@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://lists.ripe.net/mailman/listinfo/address-policy-wg
2 years, 7 months
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
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(a)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(a)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(a)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://lists.ripe.net/mailman/listinfo/address-policy-wg
>
>
2 years, 7 months