@EXT: Inputs/observations from EUROPOLon proposal 2023-04
Dear partners, companies and RIPE, on the last RIPE meeting, my inputs have unfortunately been hampered by some technical problems of online connection. With this message, I would like to express from Europol perspective, our questions and some clear concerns about the measure 2023-04 as proposed. We have been very recently informed about the project of measure that would indeed remove User assignment data from the RIPE Database public registry. We have started a consultation of EU law enforcement services (that however takes time), and informed the EU Commission.
From the first feedback we have gathered, the measure will have some clear negative impacts on the capacity of law enforcement authorities to lead investigation, considering the current situation and practices.
Various law enforcement actors (LEA) do appreciate to have the information in the RIPE databases. This direct access helps many investigators to work swiftly in their daily activity against cybercriminals, fraudsters, pedophiles, terrorists...as we all know. The first negative impact will concern the swift availability of data : with the new measure, LEA will systematically have to request information to the LIRs, with a court order. Beyond the sole matter of lawfulness requirement, it will not ease as such the daily work, but instead it will be another barrier to the facilitated access to the data : easing the access means easing an efficient and swift investigation. The proposed measure does not prioritize it. Maintaining access to the data of end users at RIPE level is also a way to ensure access to all data, in spite of the uncertainty of answers from some LIRs. Registration practices are far to be uniform across the various LIRs. Please kindly consider that capacity of Law Enforcement is asymmetric towards large volumes of ransomware attacks, online scam types and massive sharing of Child Sexual Abuses Material,...all support from our partners is the most precious to counter these realities. The other main impact will be on the quality of collected data. In practice, the proposed policy could indeed allow assignments to be somewhat anonymised. The measure would have here an impact on data granularity : The shift to aggregated assignments would result in less granular data available to law enforcement. While individual assignments offer specific and detailed information about each IP address's usage, aggregated data may obscure such details, potentially complicating investigations that rely on precise IP address information.. We do understand that the aggregated registration of IPv4 addresses would streamline administrative processes for LIRs but, it is important to acknowledge that it would also have a negative impact on the efficiency and effectiveness of law enforcement investigations. The less detailed information will require additional steps or inquiries to ascertain the specifics of an IP address's usage, potentially delaying investigative processes. Identifying IPV4, remains highly challenging in many cases, as all know, and IPV6 will not replace it at short term. All delays hamper the general (complex) process of investigation and may have an strong impact on the final result (bad guys arrested and new victims prevented or saved) EU has recently adopted the NIS2 directive with its article 28 for a better access to DNS information for the legitimate actors. we observe that the planned measure 2023-04 would open an opposite (negative) trend on the access to IP information. We express our serious concern with the impact that such a measure would have on various investigations carried out by EU competent authorities, and the protection of victims, should it be adopted. Thank you for your attention and consideration. Regards Emmanuel KESSLER Head of Team - Prevention/Outreach Europol - O3 European Cyber Crime Centre (EC3) Eisenhowerlaan 73, 2517 KK The Hague, The Netherlands Phone: [Moderated] / mobile [Moderated] www.europol.europa.eu<http://www.europol.europa.eu/>
Hello Emmanuel, and thank you for your message! Please find our comments and questions inline below: On Wed, 2023-12-13 at 20:30 +0000, Kessler, Emmanuel wrote:
With this message, I would like to express from Europol perspective, our questions and some clear concerns about the measure 2023-04 as proposed. We have been very recently informed about the project of measure that would indeed remove User assignment data from the RIPE Database public registry.
2023-04 aims to *increase* the level of End User assignment coverage in the RIPE database, not remove or decrease it. Quoting from the proposal: «As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs (…) Since the RIPE Database Requirements Task Force published their report in May 2021, the PA allocations without any child assignment have grown by 18.4 percent.» We hypothesise that this trend is least partially caused by LIRs considering that registering all assignments individually is too labour-intensive and not worth the effort, especially in highly dynamic environments where individual (but otherwise identical) assignments rapidly come and go. 2023-04 would provide these LIRs a less labour-intensive option to register such assignments. Whether or not they would avail themselves of the new option is of course an open question, but it seems clear that something has to be done if the current trend towards less assignment coverage in the database is to be reversed.
We have started a consultation of EU law enforcement services (that however takes time), and informed the EU Commission.
Did this consultation take the information in the Impact Analysis into account – in particular the clarification made by the RIPE NCC that 2023-04 does *not* change the current policies and procedures when it comes to the registration requirements for End User contact information? If it did not, this concern may well be the same as the one we addressed in the message yesterday. Would it be possible for you to share the questionnaire that was sent to the LEAs with the working group?
The first negative impact will concern the swift availability of data : with the new measure, LEA will systematically have to request information to the LIRs, with a court order.
Could you please detail or give some examples of exactly what kind of information the LEAs would need to request from the LIRs using court orders? Taking into account the current policies and procedures, we suspect that the information about the End Users that LEAs can obtain directly from the RIPE database is inserted there voluntarily in the first place. If that is the case, wouldn’t it be more efficient for the LEAs to first contact the published contact information (found either in the End User assignment, or its containing allocation) and request the information that way – without going to the courts? Many LIRs would gladly help address any issues and are probably more capable in doing this than most End Users. Conversely, if the information requested is something the LIR prefers to withhold from the LEAs and the general public, it seems reasonable to assume that this information will not have been published in the public RIPE database in the first place. If so, a court order would be necessary - but that would be the case today, as well.
The other main impact will be on the quality of collected data. In practice, the proposed policy could indeed allow assignments to be somewhat anonymised.
As clarified by the RIPE NCC in the Impact Analysis, the current policies and procedures are already allowing assignments to be “somewhat anonymised”. This is not a change that 2023-04 will bring about.
The measure would have here an impact on data granularity : The shift to aggregated assignments would result in less granular data available to law enforcement. While individual assignments offer specific and detailed information about each IP address's usage, aggregated data may obscure such details, potentially complicating investigations that rely on precise IP address information..
As mentioned above it would be useful to know precisely what kind of information you are referring to here. We would appreciate it if you could share some examples. There is one thing we can think of, though - the assignment-size attribute. This is currently intended to be optional, as we did not see an independent justification for making it mandatory in IPv4. Given an LEA investigation into activity from 192.0.2.9, located within an aggregated inetnum object for 192.0.2.0/24 without the assignment- size attribute present, it would be impossible to deduce from the RIPE database alone if 192.0.2.10 is assigned to the same End User or not. If the assignment-size was present, the LEA would be able to answer that question without contacting the LIR. (assignment-size: <= /30 → same End User; assignment-size: >= /31 → different End User). This could be seen as an independent justification for making assignment-size mandatory in IPv4. If we amended 2023-04 accordingly, would that alleviate the LEAs concerns in this regard?
Identifying IPV4, remains highly challenging in many cases, as all know, and IPV6 will not replace it at short term.
The comparison with IPv6 is highly relevant. Apart from making the assignment-size attribute optional as discussed above, 2023-04 does not allow LIRs to do anything with their IPv4 assignments that has not already been allowed with IPv6 assignments for many years. The proposal is essentially a copy and paste from the IPv6 policy. With that in mind, do you see any principal difference between the proposed AGGREGATED-BY-LIR for IPv4 and the already existing AGGREGATED-BY-LIR for IPv6? Is the former more problematic for LEAs than the latter? If so, could you elaborate on why that is? Best regards, Tore and Jeroen
Hi Tore Before I dig deeper into what you said let me first focus on two points that you just made. On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore@fud.no> wrote:
Hello Emmanuel, and thank you for your message!
Please find our comments and questions inline below:
Did this consultation take the information in the Impact Analysis into account – in particular the clarification made by the RIPE NCC that 2023-04 does *not* change the current policies and procedures when it comes to the registration requirements for End User contact information?
This is NOT clarified at all in the Impact Analysis. Why are you still saying this when I know, you know and by now probably every one knows, it is simply NOT true. You acknowledged again in your reply to me yesterday that this proposal removes that famous line from the current policy: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." Removing this line *does* change current policies and would change procedures if the RIPE NCC was enforcing the current policy. We have been through this so many times. This is a very clear statement that says ALL assignments MUST contain the End User contact details. Removing this line means that assignments no longer need to contain any End User contact details. That is a significant change to the details that may or may not be entered into future assignment objects.
As clarified by the RIPE NCC in the Impact Analysis, the current policies and procedures are already allowing assignments to be “somewhat anonymised”. This is not a change that 2023-04 will bring about.
Again this is simply not true. That line you propose to remove does not currently permit anonymised assignments as they MUST include contact details of the End User. So this IS a change that 2023-04 WILL bring about. Will you please finally acknowledge that 2023-04 will allow totally anonymised, individual assignment objects that the current policy does not allow? (This is without even using the aggregated feature you are proposing to introduce.) cheers denis
Best regards, Tore and Jeroen
Hi Denis, On Fri, 2023-12-15 at 11:45 +0100, denis walker wrote:
On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore@fud.no> wrote:
Did this consultation take the information in the Impact Analysis into account – in particular the clarification made by the RIPE NCC that 2023-04 does *not* change the current policies and procedures when it comes to the registration requirements for End User contact information?
This is NOT clarified at all in the Impact Analysis. Why are you still saying this when I know, you know and by now probably every one knows, it is simply NOT true.
(…)
As clarified by the RIPE NCC in the Impact Analysis, the current policies and procedures are already allowing assignments to be “somewhat anonymised”. This is not a change that 2023-04 will bring about.
Again this is simply not true. That line you propose to remove does not currently permit anonymised assignments as they MUST include contact details of the End User. So this IS a change that 2023-04 WILL bring about.
Will you please finally acknowledge that 2023-04 will allow totally anonymised, individual assignment objects that the current policy does not allow? (This is without even using the aggregated feature you are proposing to introduce.)
As we mentioned in our message on Wednesday, Jeroen and I simply defer to the RIPE NCC’s interpretation of what current policy allows and does not allow. We will be happy to acknowledge that 2023-04 changes something the moment the RIPE NCC acknowledges the same. Let me remind you of the example assignment made by «SuperLIR GmbH» to «CarFactory GmbH», registered in the RIPE database as follows: 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 We assume that you agree that the above is a «totally anonymised, individual assignment object»? We asked the RIPE NCC whether or not the above object was compliant with *current* IPv4 address policy or not. The RIPE NCC Policy Officer answered as follows: «The above registration compliant with current IPv4 address policy. …» (For the full answer, see https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... ). This sentiment is echoed in the 2023-04 Impact Analysis (section A, paragraph 3). In light of this, we remain convinced that we accurately and truthfully represent the RIPE NCC’s interpretation of the current policy in our messages to the working group, and also that we accurately and truthfully represent the RIPE NCC’s view that 2023-04 will not change the contact registration requirements. (While admin-c and tech-c will remain mandatory, they can be delegated as in the example object above.) We are well aware that you strongly disagree with the RIPE NCC – and by extension, Jeroen and I – in this interpretation. That is of course totally fine. However, if you would like to see the actual implementation of the policy brought in line with your interpretation of it, you would need to persuade the RIPE NCC to change their mind – not Jeroen or I. Jeroen or I cannot change the RIPE NCC’s procedures. To that end, you might want to submit a policy proposal that would clarify for the RIPE NCC what the correct implementation should be, so that their procedures are brought in line with your expectations. If you do that, we can put 2023-04 on hold pending the outcome of your proposal. Best regards, Tore and Jeroen
On 2023 Dec 15 (Fri) at 14:28:13 +0100 (+0100), Tore Anderson wrote: :To that end, you might want to submit a policy proposal that would :clarify for the RIPE NCC what the correct implementation should be, so :that their procedures are brought in line with your expectations. If :you do that, we can put 2023-04 on hold pending the outcome of your :proposal. : Please don't do that. Denis wishing to change policy should not block this proposal. Additionally, I believe that Denis' proposal on this topic is unlikely to reach concensous, as you can guess from reading the acrimonious discussion across several lists. :Best regards, :Tore and Jeroen -peter
Hi Peter On Fri, 15 Dec 2023 at 14:33, Peter Hessler <phessler@theapt.org> wrote:
On 2023 Dec 15 (Fri) at 14:28:13 +0100 (+0100), Tore Anderson wrote: :To that end, you might want to submit a policy proposal that would :clarify for the RIPE NCC what the correct implementation should be, so :that their procedures are brought in line with your expectations. If :you do that, we can put 2023-04 on hold pending the outcome of your :proposal. :
The idea of writing a policy to change the way the RIPE NCC interprets other policies makes no sense. The RIPE community simply needs to request that the RIPE NCC reviews its interpretation of the current address policy and explains it on the list for further community discussion.
Please don't do that. Denis wishing to change policy should not block this proposal.
I don't want to change policy but keep this part under discussion, as it is right now.
Additionally, I believe that Denis' proposal on this topic is unlikely to reach concensous, as you can guess from reading the acrimonious discussion across several lists.
It's a pity many people choose to discuss policy on several (private) lists rather than contribute to the open, transparent, archived discussion on the official address policy list. Maybe someone can sumarise these acrimonious discussions... cheers denis
:Best regards, :Tore and Jeroen
-peter
--
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
Hi Tore We have been through all these arguments before, but it is the review phase now so they need to be repeated. On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore@fud.no> wrote:
Hello Emmanuel, and thank you for your message!
Please find our comments and questions inline below:
On Wed, 2023-12-13 at 20:30 +0000, Kessler, Emmanuel wrote:
With this message, I would like to express from Europol perspective, our questions and some clear concerns about the measure 2023-04 as proposed.
We have been very recently informed about the project of measure that would indeed remove User assignment data from the RIPE Database public registry.
2023-04 aims to *increase* the level of End User assignment coverage in the RIPE database, not remove or decrease it. Quoting from the proposal:
«As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs (…) Since the RIPE Database Requirements Task Force published their report in May 2021, the PA allocations without any child assignment have grown by 18.4 percent.»
18.4% of 19,221 is 3536. How many /24 allocations were made in that time period that quite likely don't have assignments?
We hypothesise that this trend is least partially caused by LIRs considering that registering all assignments individually is too labour-intensive and not worth the effort, especially in highly dynamic environments where individual (but otherwise identical) assignments rapidly come and go.
Pure speculation without any numbers. But what you are suggesting is that some LIRs don't consider it worth the effort to comply with RIPE policy and don't want to get involved in discussions to change the policy. I don't agree with your proposal but at least you are trying to change something you don't agree with. As for the labour intensity, we know the answer to that, but no one will even talk about updating the 25 - 30 year old RIPE Database design, data model and technology... As for 2023-04 increasing the level of End User assignment coverage, this is pure fantasy. In theory you could perhaps argue that the 'coverage' has increased if many LIRs create aggregated objects and claim that many assignments have been made from within that block. But the End User details will be completely lost within that amorphous block. Not even the assignment boundaries can be deduced. Many other LIRs may well anonymize their future or even already existing assignments by removing all references to the End User's identity and contact details. This may be done at the request of the End User. Or it may be done because the LIR has adopted a policy of not entering any details of their customers (End Users) into a public database. I have spoken to LIRs who have made it clear that it is already their policy regardless of current RIPE address policy requirements. They consider it commercially sensitive data. There are technical solutions to mitigate this but again no one will talk about the database.
2023-04 would provide these LIRs a less labour-intensive option to register such assignments. Whether or not they would avail themselves of the new option is of course an open question, but it seems clear that something has to be done if the current trend towards less assignment coverage in the database is to be reversed.
Less labour intensive by dumping the detail. This is about eliminating a problem rather than solving the problem, again because no one will talk about technical solutions. You cannot define a trend based on two measurement points. I agree something does need to be done to get more LIRs complying with RIPE policies. But changing the registration rules so that more people appear to follow them is not the way forward.
We have started a consultation of EU law enforcement services (that however takes time), and informed the EU Commission.
Did this consultation take the information in the Impact Analysis into account – in particular the clarification made by the RIPE NCC that 2023-04 does *not* change the current policies and procedures when it comes to the registration requirements for End User contact information?
If it did not, this concern may well be the same as the one we addressed in the message yesterday.
Would it be possible for you to share the questionnaire that was sent to the LEAs with the working group?
The first negative impact will concern the swift availability of data : with the new measure, LEA will systematically have to request information to the LIRs, with a court order.
Could you please detail or give some examples of exactly what kind of information the LEAs would need to request from the LIRs using court orders?
Taking into account the current policies and procedures, we suspect that the information about the End Users that LEAs can obtain directly from the RIPE database is inserted there voluntarily in the first place.
Or because some LIRs have correctly interpreted the current policy.
If that is the case, wouldn’t it be more efficient for the LEAs to first contact the published contact information (found either in the End User assignment, or its containing allocation) and request the information that way – without going to the courts? Many LIRs would gladly help address any issues and are probably more capable in doing this than most End Users.
Conversely, if the information requested is something the LIR prefers to withhold from the LEAs and the general public, it seems reasonable to assume that this information will not have been published in the public RIPE database in the first place. If so, a court order would be necessary - but that would be the case today, as well.
The other main impact will be on the quality of collected data. In practice, the proposed policy could indeed allow assignments to be somewhat anonymised.
As clarified by the RIPE NCC in the Impact Analysis, the current policies and procedures are already allowing assignments to be “somewhat anonymised”. This is not a change that 2023-04 will bring about.
The measure would have here an impact on data granularity : The shift to aggregated assignments would result in less granular data available to law enforcement. While individual assignments offer specific and detailed information about each IP address's usage, aggregated data may obscure such details, potentially complicating investigations that rely on precise IP address information..
As mentioned above it would be useful to know precisely what kind of information you are referring to here. We would appreciate it if you could share some examples.
There is one thing we can think of, though - the assignment-size attribute. This is currently intended to be optional, as we did not see an independent justification for making it mandatory in IPv4.
Given an LEA investigation into activity from 192.0.2.9, located within an aggregated inetnum object for 192.0.2.0/24 without the assignment- size attribute present, it would be impossible to deduce from the RIPE database alone if 192.0.2.10 is assigned to the same End User or not.
If the assignment-size was present, the LEA would be able to answer that question without contacting the LIR. (assignment-size: <= /30 → same End User; assignment-size: >= /31 → different End User).
This could be seen as an independent justification for making assignment-size mandatory in IPv4. If we amended 2023-04 accordingly, would that alleviate the LEAs concerns in this regard?
Identifying IPV4, remains highly challenging in many cases, as all know, and IPV6 will not replace it at short term.
The comparison with IPv6 is highly relevant. Apart from making the assignment-size attribute optional as discussed above, 2023-04 does not allow LIRs to do anything with their IPv4 assignments that has not already been allowed with IPv6 assignments for many years. The proposal is essentially a copy and paste from the IPv6 policy.
It is a good idea to align the IPv4 and IPv6 systems of registration 'where appropriate'. But maybe copy and paste without due consideration is not the best way to do it. There are differences. In those "many years" of aggregating IPv6 assignments not much of the internet was using IPv6. So it is not a valid argument to say there have been no problems with aggregating IPv6 over those "many years" so it must be OK. As more of the internet moves to IPv6, maybe we will start to see the problems that have been insignificant in the past. Maybe we will need to expand the IPv6 registration of assignments to match the current IPv4 policy. Again there are technical solutions here that no one will talk about. cheers denis
With that in mind, do you see any principal difference between the proposed AGGREGATED-BY-LIR for IPv4 and the already existing AGGREGATED-BY-LIR for IPv6? Is the former more problematic for LEAs than the latter? If so, could you elaborate on why that is?
Best regards, Tore and Jeroen
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Hi Denis, On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote:
We have been through all these arguments before, but it is the review phase now so they need to be repeated.
Indeed. We will now restate our responses too, as required by the PDP. That said, there are no new arguments presented, so anyone reading this should feel free to skip the rest of this message.
On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore@fud.no> wrote:
«As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs (…) Since the RIPE Database Requirements Task Force published their report in May 2021, the PA allocations without any child assignment have grown by 18.4 percent.»
18.4% of 19,221 is 3536. How many /24 allocations were made in that time period that quite likely don't have assignments?
We will ask the RIPE NCC to provide the working group with the updated statistics you request here.
We hypothesise that this trend is least partially caused by LIRs considering that registering all assignments individually is too labour-intensive and not worth the effort, especially in highly dynamic environments where individual (but otherwise identical) assignments rapidly come and go.
Pure speculation without any numbers.
We have no hard data that prove (or disprove) this hypothesis, that is true. We have not surveyed the LIRs in question to ask them why they opt not to register assignments. That said, as we do have quite a bit of experience as LIR hostmasters (including working with highly dynamic network environments), we would prefer to call the hypothesis an educated guess, rather than pure speculation.
But what you are suggesting is that some LIRs don't consider it worth the effort to comply with RIPE policy and don't want to get involved in discussions to change the policy.
Regrettably, yes.
I don't agree with your proposal but at least you are trying to change something you don't agree with.
We do appreciate you recognising that.
As for the labour intensity, we know the answer to that, but no one will even talk about updating the 25 - 30 year old RIPE Database design, data model and technology...
We don't doubt that updating the RIPE database design, data model and technology is a good idea, but we believe this question falls outside of the scope of proposal 2023-04 (and the AP-WG charter entirely).
As for 2023-04 increasing the level of End User assignment coverage, this is pure fantasy. In theory you could perhaps argue that the 'coverage' has increased if many LIRs create aggregated objects and claim that many assignments have been made from within that block.
If a WHOIS lookup of an IPv4 address that today will return an ALLOCATED PA object (even though it is in fact assigned and in use) but after the implementation of 2023-04 will return an AGGREGATED-BY-LIR object, then we consider that the assignment coverage has increased.
But the End User details will be completely lost within that amorphous block.
We believe this concern has been addressed in the following message, under the heading «Does 2023-04 change the contact registration requirements for assignments?». https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/0139...
Not even the assignment boundaries can be deduced.
As mentioned in the proposal text itself, we did not see any independent justification for making the assignment-size attribute mandatory in IPv4, as its use in the calculation of the HD-ratio in IPv6 is not applicable. That said, if you or anyone else in the working group can identify and clearly articulate an independent justification for making the assignment-size attribute mandatory in IPv4 too, then we will certainly give that due consideration and possibly amend the proposal accordingly.
Many other LIRs may well anonymize their future or even already existing assignments by removing all references to the End User's identity and contact details. This may be done at the request of the End User. Or it may be done because the LIR has adopted a policy of not entering any details of their customers (End Users) into a public database. I have spoken to LIRs who have made it clear that it is already their policy regardless of current RIPE address policy requirements. They consider it commercially sensitive data.
We believe these concerns have been addressed in the following message, under the heading «Does 2023-04 change the contact registration requirements for assignments?». https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/0139...
There are technical solutions to mitigate this but again no one will talk about the database.
We assume you refer to improving the RIPE database technology here, which we have answered earlier on in this message.
2023-04 would provide these LIRs a less labour-intensive option to register such assignments. Whether or not they would avail themselves of the new option is of course an open question, but it seems clear that something has to be done if the current trend towards less assignment coverage in the database is to be reversed.
Less labour intensive by dumping the detail. This is about eliminating a problem rather than solving the problem, again because no one will talk about technical solutions. You cannot define a trend based on two measurement points. I agree something does need to be done to get more LIRs complying with RIPE policies. But changing the registration rules so that more people appear to follow them is not the way forward.
We believe the concerns about «dumping the detail» and «changing the registration rules» have been addressed in the following message, under the heading «Does 2023-04 change the contact registration requirements for assignments?». https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/0139... As for the «technical solutions» part, we assume you refer to improving the RIPE database technology, which we have answered earlier in this message.
Taking into account the current policies and procedures, we suspect that the information about the End Users that LEAs can obtain directly from the RIPE database is inserted there voluntarily in the first place.
Or because some LIRs have correctly interpreted the current policy.
We do not believe that interpretation to be correct, as noted in the following message, under the heading «Does 2023-04 change the contact registration requirements for assignments?». https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/0139...
It is a good idea to align the IPv4 and IPv6 systems of registration 'where appropriate'.
Agreed.
But maybe copy and paste without due consideration is not the best way to do it.
We believe we have given this due consideration prior to submitting the proposal. We have looked at how AGGREGATED-BY-LIR is being used in IPv6 (it appears to be popular amongst LIRs as there are almost 60k such objects in the database) and contrasted this with how there is an ongoing challenge with LIRs not registering their IPv4 assignments at all (cf. ripe-767 section 6.1.2). We truly believe AGGREGATED-BY-LIR strikes a good balance here, otherwise we would not have submitted our proposal.
There are differences. In those "many years" of aggregating IPv6 assignments not much of the internet was using IPv6. So it is not a valid argument to say there have been no problems with aggregating IPv6 over those "many years" so it must be OK. As more of the internet moves to IPv6, maybe we will start to see the problems that have been insignificant in the past.
IPv6 is extensively used nowadays, yet so far we have not seen anyone describing any problems caused by AGGREGATED-BY-LIR in IPv6 (much less attempt to fix them). If there truly were any problems with IPv6 AGGREGATED-BY-LIR, we would have expected them to manifest by now. We have not seen any reason to expect that IPv4 AGGREGATED-BY-LIR would be any more (or less) problematic than IPv6 AGGREGATED-BY-LIR.
Maybe we will need to expand the IPv6 registration of assignments to match the current IPv4 policy.
That is certainly something the community could do if it wanted. That would not be our preferred approach, though, as we fear this might import the problem of LIRs not registering assignments (cf. ripe-767 section 6.1.2) from IPv4 into IPv6, do nothing to help with the labour intensiveness of keeping the RIPE database up to date in highly dynamic environments (rather it would introduce or aggravate that problem in IPv6), as well as leave us with a major headache about what to do with the ~60k invalidated AGGREGATED-BY-LIR inet6num objects.
Again there are technical solutions here that no one will talk about.
We assume you refer to improving the RIPE database technology here, which we have answered earlier on in this message. Best regards, Jeroen and Tore
Hello again Denis, On 16/12/23 19:53, Tore Anderson wrote:
On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote:
On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore@fud.no> wrote:
«As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs (…) Since the RIPE Database Requirements Task Force published their report in May 2021, the PA allocations without any child assignment have grown by 18.4 percent.» 18.4% of 19,221 is 3536. How many /24 allocations were made in that time period that quite likely don't have assignments? We will ask the RIPE NCC to provide the working group with the updated statistics you request here.
We just received the following response from the RIPE NCC: «6843 inetnum PA allocations were created since 01-MAY-2021, and 4551 of those (67%) do not have any PA assignments. Please note that this number may include new inetnum objects created from transfers.» Best regards, Tore and Jeroen
Hi Tore On Wed, 20 Dec 2023 at 16:59, Tore Anderson <tore@fud.no> wrote:
Hello again Denis,
On 16/12/23 19:53, Tore Anderson wrote:
On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote:
On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore@fud.no> wrote:
«As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs (…) Since the RIPE Database Requirements Task Force published their report in May 2021, the PA allocations without any child assignment have grown by 18.4 percent.» 18.4% of 19,221 is 3536. How many /24 allocations were made in that time period that quite likely don't have assignments? We will ask the RIPE NCC to provide the working group with the updated statistics you request here.
We just received the following response from the RIPE NCC:
«6843 inetnum PA allocations were created since 01-MAY-2021, and 4551 of those (67%) do not have any PA assignments.
Most of these allocations are /24. So if 4551 of these /24 allocations have no assignments, and the increase in allocations without assignments is only 3536, then we actually have more allocations with assignments than we had before, putting aside the /24 allocation issue. So the trend is downwards. The overall number of allocations without assignments is decreasing. cheers denis
Please note that this number may include new inetnum objects created from transfers.»
Best regards,
Tore and Jeroen
On 20/12/23 17:27, denis walker wrote:
Most of these allocations are /24. So if 4551 of these /24 allocations have no assignments, and the increase in allocations without assignments is only 3536, then we actually have more allocations with assignments than we had before, putting aside the /24 allocation issue. So the trend is downwards. The overall number of allocations without assignments is decreasing.
Hello Denis, What do you mean when you say «the /24 allocation issue», exactly? Tore
On Wednesday, December 20th, 2023 at 18:16, Tore Anderson <tore@fud.no> wrote:
On 20/12/23 17:27, denis walker wrote:
Most of these allocations are /24. So if 4551 of these /24 allocations have no assignments, and the increase in allocations without assignments is only 3536, then we actually have more allocations with assignments than we had before, putting aside the /24 allocation issue. So the trend is downwards. The overall number of allocations without assignments is decreasing.
Hello Denis,
What do you mean when you say «the /24 allocation issue», exactly?
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
Hello, I would like to express my opinion. It is a personal opinion and does not represent any organization. I think that the proposal to include the AGGREGATED-BY-LIR option in IPv4 made is very interesting and correct, but I also think that the opinion expressed by Denis and other members of the working group is completely reasonable. I think we should make a modification that all parties agree on. In my opinion, I think we should ask ourselves what is going on and what are the reasons why information is being recorded in the DB in a non-uniform way. In this sense, I believe that the database shows a series of information that can be used to contact IP address holders, but this information is also used to attack organizations, either by identifying address ranges or by phishing and other types of attacks through the exposed means of contact. And for this reason, it is possible that some members may prefer not to register the information (not following the policy), register "anonymous" end-user ranges as LIR's own, etc. In this sense, I think it would be interesting to make a proposal to modify the policy (before or after the 2023-04 proposal), specifying what can and cannot be done, as well as what is recommended. For example, in IPv4, an assignment may be used for a pool of DSL client addresses, in which case the LIR must be registered as the owner, because there is no defined end user. It is logical that in IPv6, where there is a variable prefix length size, AGGREGATED-BY-LIR is used for this type of registration. On the other hand, in IPv4 the policy requires registering a range assigned to an end user as the users's own, but does not include the options for not including end-user information (if so desired) and thus hiding the information from possible attacks, including the netname, contact addresses, etc. Perhaps the only currently valid option is to register it in the name of the LIR, as has been shown with some DB objects. However, using AGGREGATED-BY-LIR for this purpose, I think (in my opinion) is not the right thing to do. I think that if we do not specify what can and cannot be done the database will end up with information that will only indicate the LIR as the user of the addresses. If we are able to specify the specific use of each state of the inetnum objects that includes the needs of all LIRs, the proposal made by Tore and Jeroen to include AGGREGATED-BY-LIR in IPv4 and thus homogenice the inetnum objects of both protocols will be accepted by the majority. Best regards. kix
hi, 2023-04 Add AGGREGATED-BY-LIR status for IPv4 PA assignments (which you may have mis-understood) aside, i am intellectually curious, but ianal, and i try not to play one on the net. i think i understand your concerns to a fair extent. the more and more accurate data leo can access without a court order makes life easier for leo. and, as a security guy who occasionally has to call leo, i have some sympathy for leo here. though in the extreme, we have a police state. but take anything to the extreme and it is silly. my point is that there is a spectrum. but as a privacy guy, i am interested in the tension between that and the privacy and data protection initiatives on which the eu seems to be in the lead (congrats). even operationally, we have a tension between privacy and data such as location (see geoloc: discussion), identity (whois), this proposal, etc. as i said, ianal, but i think the slow and frustrating court order is meant to dump that tradeoff on a judge. here, in our nerdy way, we're trying to automate it, but have the same tensions. so i wonder if you could shed some light on where you see the tradeoff here. randy, trying to move from positions to a conversation
participants (6)
-
denis walker -
Kessler, Emmanuel -
Peter Hessler -
Randy Bush -
Rodolfo García Peñas (kix) -
Tore Anderson