Search results for "2023-04" - address-policy-wg

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

by Rodolfo García Peñas (kix)

On Wednesday, December 20th, 2023 at 18:16, Tore Anderson <tore(a)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

1 year, 3 months

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by APEX NCC ORG

Thank you, Tore, for your quick feedback and time! Everything became clear now. Great thought and proposal. Have a good day! Regards, APEX NCC ORG. On 9/4/23 14:21, Tore Anderson wrote: > * APEX NCC ORG > >> Hello, Team! >> I read the offer provided: >> https://www.ripe.net/participate/policies/proposals/2023-04 >> three times. >> However, I still don't understand the real reason for introducing the >> AGGREGATED-BY-LIR status >> The text of the proposal contains only general provisions. >> Can you provide a more detailed description and examples? > Hi Andrii! > > There are several possible examples, but let me give you just one: > > Let's say you're a small cloud VPS provider in the business of leasing > out virtual machines to small businesses and private individuals. Your > cloud management software dynamically assigns IPv4 addresses out of > 192.0.2.0/24 to customers, so you have for example: > > 192.0.2.1/32 = assigned to Alice's first VM - used for a web server > 192.0.2.2/32 = assigned to Bob - used for a Minecraft server > 192.0.2.3/32 = assigned to Bob's hair salon business = web server > 192.0.2.4/32 = assigned to Alice's second VM - mail server > > …and so on. > > Current policy requires you to register four individual INETNUM > assignments of size /32 for the above four virtual machines. > > However, due to the GDPR requirements, you usually cannot put Alice's > and Bob's names or contact info into the RIPE database, so instead you > typically substitute your own (this is allowed by policy). > > That means you have now four individual INETNUMs with identical contact > information (your own). You need to add or remove these /32 INETNUMs as > customer VMs come and go. You can automate this, but it is a pointless > exercise in any case. > > To avoid this, we propose allowing you to create a single INETNUM that > covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can > already do with any IPv6 assignments made to the same VMs. This > aggregated object will cover all customer VMs in your cloud > infrastructure, present and future, and makes it so that you don't have > to send a RIPE database update every time a customer VM is provisioned > or discontinued. > > Tore > -- Best wishes, APEX NCC ORG -------------------------------- +38(056)-731-99-11, +38(067)-731-99-11, +38(050)-731-99-11, www.trifle.net

1 year, 6 months

Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?

by Nick Hilliard

Brian Storey wrote on 30/09/2023 00:03: > For me it comes down to this. As a community & considering the permitted > exceptions (individuals & P2P assignments):- > > 1) Is the publication of End User entities for an assignment important? > 2) Is the publication of a prefix assignment boundary between end users > important? Brian, thanks for this thoughtful analysis of this proposal. These two questions are indeed the crux of this issue. I'm also surprised at Angela's answers, but let's deal with the intent of the policy for the time being, namely whether the RIPEDB should or shouldn't include information about end user assignments and the entities to which they are assigned. My take is that, in theory, there would be a good deal of merit in publishing both if there were some way of ensuring that this data was accurate and well-maintained. However, from a practical point of view, there's a large amount of inaccurate and stale data in the RIPE database. A lot of effort has been expended over the last 30 years to attempt to address this problem, but no good solutions have been found and the outcome If we haven't solved this problem in 30 years, and if there are no proposals on the table to address data quality issue, I'd speculate that it's unlikely we'll solve the RIPE DB's data quality issues any time soon, and maybe now it would be appropriate to have a good, hard think about whether it's worth keeping this policy at all. But, speculation is not an appropriate substitute for fact. A better starting point for addressing the underlying data quality issue might be to formally measure it. There's ~4.7m inetnum/inet6num PA assignment registrations in the database. A quick check with a sample size calculator suggests that examining around 500 random inetnums / inet6nums for an a/b data quality outcome would give a result with 98% confidence, ~5% error margin. Is there an appetite for examining this in the DB-WG + the RIPE NCC? Nick

1 year, 6 months

Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

by Brian Storey

Hi Tore, Thanks for the response. I only have a short window to reply, however I would clarify that I fall in to the " Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.»" category. I am therefore looking at this through the lens of this approach. In which-ever form the end user is illustrated, it's the total permitted absence of that which is the surprise; Unless I have misunderstood the recently shared RIPE NNC interpretation. Many thanks, Brian -----Original Message----- From: Tore Anderson <tore(a)fud.no> Sent: Monday, April 8, 2024 1:38 PM To: Brian Storey <Brian.Storey(a)gamma.co.uk>; Carlos Friaças <cfriacas(a)fccn.pt> Cc: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status * Brian Storey: > There is a subtly here which I don't think is fully appreciated. > > I previously highlighted my surprise to the RIPE NNCs interpretation > of the existing policy; as have others. Why is that? I think it's very > important to recognise that LIRs act and publish certain End User data > because it was deemed that this was a requirement and that not doing > so could see a breach of policy, therefore leading to Allocated PAs > being reclaimed - not good with scarce resources! They did this > because they understood they HAD to not because they WANTED to. > > If this school of thought no longer applies, then it is reasonable to > expect that some will reevaluate how much effort they continue to put > in and the consequences of that. Hi Brian, We have certainly no difficulty understanding that you and others might have not been aware of this before. But now you are, and so is anyone else that are following the RIPE policy development process. The cat is out of the bag, so to speak. Withdrawing 2023-04 would not undo this, because this is not a property of the proposal itself, but knowledge of the of the RIPE NCC's interpretation of the *current* address policy. Or as the working group chairs put it: «It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.» Furthermore, it is clear that this comes as no surprise at all to many LIRs, who have done this for a long time. Again quoting the working group chairs: «changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects» https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.n et%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2F2024-January%2F013980.html &data=05%7C02%7CBrian.Storey%40gamma.co.uk%7C5f1a1c8dfdc044cfcc9f08dc57c8bc2 3%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638481766859115331%7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3D%7C0%7C%7C%7C&sdata=bWifsFJ9cfucTWDCBWz4WueyMwcy6Ehr6ti5Lgi1Byg%3D&reser ved=0 > The two questions I previously posed here: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ripe.net%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2F2023-September > %2F013863.html&data=05%7C02%7CBrian.Storey%40gamma.co.uk%7C5f1a1c8dfdc > 044cfcc9f08dc57c8bc23%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638 > 481766859125299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 > luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JiSFtHNbG6Lz6I > jzIBE2nf6%2B4JwIJ8Ug3GAs97nIqtw%3D&reserved=0 > were:- > > "For me it comes down to this. As a community & considering the > permitted exceptions (individuals & P2P assignments):- > > 1) Is the publication of End User entities for an assignment important? Perhaps, perhaps not. That is for the working group to decide. It is however outside the scope of 2023-04. Again quoting the working group chairs from the previously linked-to message: «we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one». > 2) Is the publication of a prefix assignment boundary between end > users important?" We address this question in the proposal itself, see https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.n et%2Fmembership%2Fpolicies%2Fproposals%2F2023-04%2F%2312-differences-from-ip v6-aggregated-by-lir-status&data=05%7C02%7CBrian.Storey%40gamma.co.uk%7C5f1a 1c8dfdc044cfcc9f08dc57c8bc23%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C63 8481766859132088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=oyHBpPOS0YdV7jw7hXJOhO762 1F%2FY%2BAwBTmtp2f%2F%2F%2BM%3D&reserved=0. The gist of it is that since IPv4 assignments tend to be right-sized (rather than gigantic "one size fits all" prefixes like in IPv6), and that there is no HD-Ratio that needs calculating, we found it more appropriate to leave the assignment-size attribute optional. > Now, I've not commented since (for various reasons), however I have > followed the discussion of this closely. Internally, I've been > highlighting that a Business Risk item based on previous > interpretation could evolve and how we manage our exposure changes if > this proposal become policy. What this means in reality is that we can > choose how much effort we continue to place on updating our > Assignments as the end user customer base churns. There are end > customers who like their association to a PA Assignment to be > published and there are those who don't. It may well be easier for me > only publish by exception. I'm still thinking it through pending what > happens next with a few other indirect considerations. > > I don't believe I'll be the only one doing this. You and everyone else can do this right now. You do not need to wait for the possible acceptance of 2023-04. As mentioned above, you have in fact been free to do this «since at leas [sic] the late 1990s». Best regards, Jeroen & Tore

11 months, 3 weeks

@EXT: FW: Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

by Kessler, Emmanuel

Dear All, I would have some comments about the previous points that mentions Europol Thanks for your cooperation spirit Regards Emmanuel Kessler -----Original Message----- From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of Kai 'wusel' Siering via address-policy-wg Sent: vendredi 5 avril 2024 21:41 To: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status Moin, am 05.04.24 um 16:51 schrieb denis walker: > I used to wonder why no one > would even talk about bringing the RIPE Database into the modern > world. Because this is address-policy (»The Address Policy Working Group develops policies relating to the management and registration of Internet number resources.«), not database (»The Database Working Group deals […]«). > Europol has expressed serious concerns about these changes. Europol has the means to challenge the maintainer of the address space for more information on individual usage; there is no real thread to Europol's operation by the change, it might just become less convenient to get the wanted information. --> Sorry, but reading this, I observe that you may indeed have only a fuzzy/limited idea of what Europol does, and the impact on LE operations.. As knowing the scope of Europol and digital investigation (we work here), we repeat that the matter is not only being less convenient. The matter is the loss of opportunities of identification that will vanish for investigators... > If someone had informed them earlier > of the changes being considered that may affect them, Well, this is happening all in the open. IF Europol is depending so greatly on the RIPE DB, they SHOULD be following the PDP already for years and years and voiced their concerns more timely. --> the matter is not just Europol, but the impact on investigations of LE services....Europol has been regularly well active in various working groups of RIPE... Please consider that capacities of investigators are impacted by a large number of negotiation processes : at E-governance level (ICANN, RIPE,..), UN treaties, Council of Europe conventions, numerous EU legislations (Nis2, E-evidence package, DSA,...), national levels ones... (and I may forget some..?!).... linked with judicial cooperation frameworks, companies regulations, cybersecurity actors, technological standards in permanent evolution, .... The number of working groups, regulations, proposals, legal acts, is the most consequent...it is a "jungle" of processes that have to be covered,...you can believe me... in spite of the efforts of our committed people, we are unfortunately not omniscient an always present everywhere....(nobody is...!). As in all organisations, capacities are not infinite and we have sometimes to prioritize those we have, under emergencies and the various agendas.. ...but whatever the raised questions, THE relevant question is overall that a joint work in open spirit is THE best way...beyond considering the only question of a seat gap at a moment... --> The matter should remain in the end, which impact (positive/negative...) ? when all know new popping processes from the beginning, it allows to formalize swiftly a full knowledge about impact, and prevent 2 undesirable ends that are : wasting time on a proposal that should be given up/ or persisting on the difficult adoption of a measure that will bring damage on victims protection... we can do great job to secure digital space, (just see Lockbit and the latest operations against ransomwares : https://www.europol.europa.eu/media-press/newsroom?q=cyber ) including protecting private sector and companies that are essential for business and the economic health of our countries, but if we lose the access to data, it means less operational achievements/ and criminals being more in capacity to target companies and peoples, who still "pay the bill" of crimes... > proceed with all haste to No haste visible at all; this is about 2023-04 — we already are in 2024-04. Regards, -kai -- 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

11 months, 3 weeks

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

by Peter Hessler

Hi everyone, I mentioned this during the WG session but want to bring it up on the mailing list, what is the definition of assignment-size. In the IPv6 implementation of AGGREGATED-BY-LIR there is an assignment-size attribute, which is proposed to be optional for the IPv4 version. >From the inet6num documentation: "assignment-size:" - This specifies the common size of all individual assignments aggregated into one block with the status 'AGGREGATED-BY-LIR'. This attribute is required to be present if the inet6num object has this status. The individual assignments do not need to be represented in the RIPE Database. But one or more assignments may be included if the member wishes to specify them for any reason. While there is no definition of what "size" means, my understanding is that the technical implementation follows the implemention requirements of inet6num objects, which is the CIDR size. However, in IPv4 it is allowed to do CIDR _or_ an arbitrary range of addresses. So if one were to create this inetnum object: inetnum: 192.0.2.0 - 192.0.2.255 netname: customers of example status: AGGREGATED-BY-LIR assignment-size: 32 ... Here the assignment size is ambiguous. Is it 32 addresses aka a /27, or is it a /32 aka 1 address. I propose that we define this to be a CIDR assignment and they put in the number of bits of the netmask, so the above example would be assignment-size of /32. -peter

1 year, 4 months

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Brian Storey

Hi Tore, Thanks for explaining this particular use case. Reading the proposed New Policy Text, it provides the LIR with an adminsitrative choice. Whilst I understand this choice, the rantionale behind the proposal is to find a reasonable way to fill the gap for the Provider Allocations not registered for the specific exception documented: "IP addresses used solely for the connection of an End User to a service provider... can be registered as part of the service provider's internal infrastructure". 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. Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? Many thanks, Brian -----Original Message----- From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of Tore Anderson Sent: Monday, September 4, 2023 12:22 PM To: Andrii Syrovatko <andrey_syrovatko(a)trifle.net>; address-policy-wg(a)ripe.net; adallara(a)ripe.net Cc: APEX NCC ORG <registry(a)apex.dp.ua>; Trifle NOC <noc(a)trifle.net> Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) * APEX NCC ORG > Hello, Team! > I read the offer provided: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ripe.net%2Fparticipate%2Fpolicies%2Fproposals%2F2023-04&data=05%7C01%7 > Cbrian.storey%40gamma.co.uk%7C3a23e9f95d904f83274a08dbad391d6b%7C743a5 > d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638294233043320645%7CUnknown%7CT > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0%3D%7C3000%7C%7C%7C&sdata=9dEJGnNWdlapbyyzjM5qgJvn%2BB6G%2BGp6jjmu > %2FcDzZPY%3D&reserved=0 > three times. > However, I still don't understand the real reason for introducing the > AGGREGATED-BY-LIR status The text of the proposal contains only > general provisions. > Can you provide a more detailed description and examples? Hi Andrii! There are several possible examples, but let me give you just one: Let's say you're a small cloud VPS provider in the business of leasing out virtual machines to small businesses and private individuals. Your cloud management software dynamically assigns IPv4 addresses out of 192.0.2.0/24 to customers, so you have for example: 192.0.2.1/32 = assigned to Alice's first VM - used for a web server 192.0.2.2/32 = assigned to Bob - used for a Minecraft server 192.0.2.3/32 = assigned to Bob's hair salon business = web server 192.0.2.4/32 = assigned to Alice's second VM - mail server …and so on. Current policy requires you to register four individual INETNUM assignments of size /32 for the above four virtual machines. However, due to the GDPR requirements, you usually cannot put Alice's and Bob's names or contact info into the RIPE database, so instead you typically substitute your own (this is allowed by policy). That means you have now four individual INETNUMs with identical contact information (your own). You need to add or remove these /32 INETNUMs as customer VMs come and go. You can automate this, but it is a pointless exercise in any case. To avoid this, we propose allowing you to create a single INETNUM that covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can already do with any IPv6 assignments made to the same VMs. This aggregated object will cover all customer VMs in your cloud infrastructure, present and future, and makes it so that you don't have to send a RIPE database update every time a customer VM is provisioned or discontinued. Tore -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip…

1 year, 6 months

@EXT: Inputs/observations from EUROPOLon proposal 2023-04

by Kessler, Emmanuel

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/>

1 year, 3 months

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

by denis walker

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(a)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

1 year, 3 months

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

by Tore Anderson

Hi Jan, On 11/01/24 13:27, Jan Ingvoldstad wrote: > On Thu, Jan 11, 2024 at 1:11 PM Tore Anderson <tore(a)fud.no> wrote: > > 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. > > This statement basically renders the point of a policy working group moot. Not at all. Any working group member who is of the opinion that the RIPE NCC is interpreting a RIPE Community policy incorrectly, is free to at any point submit a policy proposal that clarifies the allegedly misinterpreted policy text with the aim to make the RIPE NCC change its procedures accordingly. The RIPE NCC's Impact Analysis will then reveal whether or not the proposed new policy text does attain its goal and that the RIPE NCC will change its procedures as desired, should the proposal pass. Finally, the proposal will need to reach (rough) consensus in order to confirm that the RIPE Community does indeed concur with the proposer's opinion that the old policy was interpreted incorrectly, and that the RIPE NCC's procedures ought to change. Absent this, the RIPE NCC's operationalisation of the policy will stay as-is. Tore & Jeroen

1 year, 2 months

address-policy-wg search results for query "2023-04"