Colleagues I have many things to say about this proposal but I will start with a response to Sander's concern. On Tue, 4 Oct 2022 at 13:53, Sander Steffann <sander@steffann.nl> wrote:

Hi,

...

...

To break it down by rationale:

"One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify the request for an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the RIPE NCC ran out of IPv4 addresses in 2019."

This merely means that this particular reason is no longer relevant for IPv4 addresses.

Justifying getting more PA Allocations was never the reason to document PA Assignments in the RIPE database. Its purpose is to document who to contact for administrative and technical issues concerning the IP addresses. Being able to use that data to verify that IP addresses are actually in use before allocating more was just a useful side effect.

I therefore oppose this rationale. I know that organisations are lazy and only properly document assignments when they want the benefits for themselves (i.e. getting another allocation). I think there is a more important decision to make here: do we still want this level of documentation for operational purposes?

Again we are back to asking the question, "What is the purpose of the RIPE Database in 2022?". I know this is like the elephant in the room. I know most people look the other way every time I mention this topic. BUT it is so fundamental to many discussions we are having. For example, is the database still purely (or even primarily) only for 'operational purposes'? A term used so often that, like so many other terms used in this industry, is not even defined anywhere. Is using the content of the RIPE Database to stop the use of an IP address for criminal activity an 'operational purpose'. If someone is operating a network using a block of IP addresses and abusing other users of the internet, then surely knowing who is using that block of addresses and being able to contact them has 'operational' value. As Sander said, knowing how much of an allocation is in use was a side effect of this policy. Knowing who is operating a network on a block of addresses, and being able to contact them, is the real purpose of this policy requirement to document assignments. If we allow LIRs to choose what info to add to the database, those LIRs that knowingly provide resources and services to abusive end users will obviously choose not to document it. That may be used as a selling feature to abusive end users, to obscure and delay their identification. Whilst most LIRs take abuse seriously we all know there are some that don't. I oppose this proposal. cheers denis co-chair DB-WG

If we don’t want/need this level of documentation anymore then sure, remove the mandatory PA assignment registration in the RIPE DB. But in that case rewrite the proposal to make that very explicit. Removing the requirement using the wrong arguments is misleading. Call it what it is.

Cheers, Sander

--

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

Op 4 okt. 2022 om 17:46 heeft Randy Bush <randy@psg.com> het volgende geschreven:



...

Again we are back to asking the question, "What is the purpose of the RIPE Database in 2022?".

in this case, same as it ever was. same as it ever was.

And you may ask yourself “what is this RIPE database?” ;) Sander

On 4 Oct 2022, at 15:25, denis walker <ripedenis@gmail.com> wrote:

Colleagues

I have many things to say about this proposal but I will start with a response to Sander's concern.

On Tue, 4 Oct 2022 at 13:53, Sander Steffann <sander@steffann.nl> wrote:

...

Hi,

...

...

To break it down by rationale:

"One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify the request for an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the RIPE NCC ran out of IPv4 addresses in 2019."

This merely means that this particular reason is no longer relevant for IPv4 addresses.

Justifying getting more PA Allocations was never the reason to document PA Assignments in the RIPE database. Its purpose is to document who to contact for administrative and technical issues concerning the IP addresses. Being able to use that data to verify that IP addresses are actually in use before allocating more was just a useful side effect.

I therefore oppose this rationale. I know that organisations are lazy and only properly document assignments when they want the benefits for themselves (i.e. getting another allocation). I think there is a more important decision to make here: do we still want this level of documentation for operational purposes?

Again we are back to asking the question, "What is the purpose of the RIPE Database in 2022?”

My guess is that the fact the initial query protocol was called WHOIS and not WHATIS or even WHEREIS might be a good hint. Joao

Hi Jeroen Your terminology is very confusing. You talk only about allocations and sub-allocations and keep referring to INETNUMs. You never once mention assignments. So my first question is what exactly is it that you want to be optional? The current policy says: 3.0 Goals of the Internet Registry System ...4.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. ---- 4.0 Registration Requirements All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations. ---- 6.2 Network Infrastructure and End User Networks ...When an End User has a network using public address space this must be registered separately with the contact details of the End User. ---- The message from the current policy is very clear. End Users operating public networks must be documented in the RIPE Database. There are two historical reasons given, uniqueness AND network operations. You have focused your argument on the fact that uniqueness of allocations is no longer needed. But you have ignored the other stated reason. Using the database to contact network operators for troubleshooting is one of the original purposes of the database. So if you now want this information to be optional and entered if an LIR feels like it, you need to justify why internet troubleshooting is no longer necessary at an End User network level. When we talk about the purposes of the database we are not talking about the purposes of the database as a container. We mean the purposes of the data contained within the database. Over time this data in the RIPE Database about End Users has been used, for example, by LEAs and other investigators to identify the users as well as for internet operational problem solving. The Database Task Force acknowledged in their report (ripe-767) that there are now different stakeholders who use the RIPE Database for different reasons: 2. The Difference between the RIPE Database and the RIPE Registry The information disclosed in the RIPE Database aims to facilitate cooperation and coordination between network operators and other stakeholders for a variety of operational tasks, including troubleshooting and preventing outages. --- 3. Why are we reviewing the RIPE Database functionality now? The RIPE Database provides essential information to members of the RIPE community, which helps them to keep individual networks and the overall Internet running in their region. Many stakeholders depend on the accuracy and availability of the data stored in the database to do their job properly, especially regarding cybersecurity. Some database users, such as ISPs or IXPs, have been part of the RIPE community for years, while others are relatively new, such as Law Enforcement Agencies (LEAs) or regulators. These user groups have different needs and expectations regarding the database --- 5.1 Data accuracy The data added to the database should be accurate to ensure uniqueness of Internet number resources and to provide reliable registration information to all parties involved in network operations. For example, contact details or information about a specific assignment should be accurate to facilitate contact with and identification of the organisation holding the assignment. --- 6.4 Purpose: Facilitating Internet operations and coordination The RIPE Database should facilitate communication and cooperation among stakeholders for the following reasons: -Operational issues such as measuring or troubleshooting networks -Handling abuse cases, supporting the handling of cyber incidents and supporting LEA investigations --- Unfortunately, the Task Force did not attempt to identify most of these 'other' stakeholders or what data they need or why. So we are left in a position where it has been acknowledged that many different stakeholders exist that need data currently provided by the public IP address registry, but who or what is unknown. There may well now be stakeholders with very legitimate reasons for needing accurate assignment data. Until we know more about these stakeholders we cannot make informed decisions about the content of the database. But the Task Force then went on to make a recommendation about assignments based on the rationale "A core reason for registration of IPv4 PA assignments was to justify an LIR’s need for additional IPv4 allocated address space. However, since the RIPE NCC ran out of IPv4 in 2019, this policy has been rendered obsolete." Just as you are doing in this proposal, they conveniently ignored the main reason(s) for documenting assignments and focused on one obsolete reason. The Task Force recommendation was "that as resource holders have full responsibility over the registration of their IPv4 PA assignment(s), they are free to make assignments or not." Which is also the basis of your proposal. The people entering data into a public IP address registry are not necessarily the ones who should be able to decide what data must be contained in the registry. You need to consider the requirements of different aspects of the industry and even the needs of the wider (public) community (the stakeholders). I do not think we are currently in a position to make an informed decision on this Task Force recommendation or your policy proposal. cheers denis co-chair DB-WG On Fri, 7 Oct 2022 at 16:31, Jeroen Lauwers <jlauwers@a2b-internet.com> wrote:

Hi Denis,

Again we are back to asking the question, "What is the purpose of the RIPE Database in 2022?". I know this is like the elephant in the room. I know most people look the other way every time I mention this topic.

This policy proposal is not about the goal of the database itl is just about how far we obligate LIRs in filling in information for inetnum objects and how much freedom we give the LIR to decide it by themself. So technically the goal of the database stays the same.

BUT it is so fundamental to many discussions we are having. For example, is the database still purely (or even primarily) only for 'operational purposes'? A term used so often that, like so many other terms used in this industry, is not even defined anywhere. Is using the content of the RIPE Database to stop the use of an IP address for criminal activity an 'operational purpose'. If someone is operating a network using a block of IP addresses and abusing other users of the internet, then surely knowing who is using that block of addresses and being able to contact them has 'operational' value.

For sure we always need to keep this in mind. And I think it would be a good subject to discuss in the database working group. But so far I don’t see any reasons to be insecure about this after changing this policy.

As Sander said, knowing how much of an allocation is in use was a side effect of this policy. Knowing who is operating a network on a block of addresses, and being able to contact them, is the real purpose of this policy requirement to document assignments. If we allow LIRs to choose what info to add to the database, those LIRs that knowingly provide resources and services to abusive end users will obviously choose not to document it. That may be used as a selling feature to abusive end users, to obscure and delay their identification. Whilst most LIRs take abuse seriously we all know there are some that don't.

You are totally right. That is why this is only about inetnum objects. The LIR gets still obligated by the terms and conditions to fill in enough information for contacting efficient the maintainer as also By the Abuse Contact Management in the RIPE Database policy for having an abuse contact.

Kind regards,

Jeroen

Colleagues Over the weekend I re-read rfc7020 The Internet Numbers Registry System, from August 2013 https://www.rfc-editor.org/rfc/rfc7020

From the Abstract: This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.

Now when I say I read something, that usually means I studied it. What matters with most documents in this industry is the detail, not the headings. The DB Task Force made references to rfc7020 in their report. They said "The need to maintain an accurate public record of Internet number resource holders is common to all Regional Internet Registries (RIRs). This is outlined in RFC 7020". They went on to use this to justify the need to publish details in the RIPE Database about allocations made by the RIPE NCC to resource holders. Now this is where detail matters and the Task Force missed an important detail in rfc7020. In RIPE policy and terminology, we allocate resources from the RIPE NCC to a resource holder (LIR). The resource holder then assigns resources to end users. However, in rfc7020 there is no distinction between allocate and assign. It refers to a hierarchy of allocations from IANA all the way down to an end user. This is clearly illustrated in the definition in rfc7020 of an LIR: Local IRs ...LIRs perform IP address allocation services for their customers, typically ISPs, end users, or child LIRs (also known as "sub-LIRs"). So throughout the whole rfc7020 document, all references to allocate or allocation include what we understand in the RIPE region to mean both allocate and assign, as well as allocation and assignment. That means all the goals, principles and comments in rfc7020 apply equally to our allocations and assignments. In rfc7020 it specifies some goals including: 2. Goals Internet number resources are currently distributed according to the following (non-exclusive) goals: ... 3) Registration Accuracy: A core requirement of the Internet Numbers Registry System is to maintain a registry of allocations to ensure uniqueness and to provide accurate registration information of those allocations in order to meet a variety of operational requirements. Uniqueness ensures that IP addresses and AS numbers are not allocated to more than one party at the same time. The Task Force took this to mean what we consider as allocations to LIRs. But this also means what we consider as assignments to end users. So registering our assignments in the RIPE Database is a "core requirement of the Internet Numbers Registry System". rfc7020 goes on to say: 3. Internet Numbers Registry System Structure The Internet Registry (IR) hierarchy was established to provide for the allocation of IP addresses and AS numbers with consideration to the above goals. This hierarchy is rooted in the Internet Assigned Numbers Authority (IANA) address allocation function, which serves a set of "Regional Internet Registries" (RIRs); the RIRs then serve a set of "Local Internet Registries" (LIRs) and other customers. LIRs in turn serve their respective number resource consumers (which may be themselves, their customers, "sub-LIRs", etc.) It concludes with: 7. Security Considerations It is generally recognized that accuracy and public availability of Internet registry data is often an essential component in researching and resolving security and operational issues on the Internet. The bottom line is that we cannot make assignments optional unless we either disregard rfc7020 or we propose to the IETF an update to rfc7020 by removing a large proportion of the current registration data from the goals and core requirements. In fact we should now reconsider the way we register IPv6 assignments in the RIPE Database. rfc7020 makes no distinction between number systems. cheers denis co-chair DB-WG

Hi Sander, Thanks for your point of view.

Justifying getting more PA Allocations was never the reason to document PA Assignments in the RIPE database. Its purpose is to document who to contact for administrative and technical issues concerning the IP addresses. Being able to use that data to verify that IP addresses are actually in use before allocating more was just a useful side effect.

I agree that it is a side effect of the main goal. But I see that as the only reason why this current policy is still standing. That is why a big part of the policy proposal is about this and not to mislead people.

I therefore oppose this rationale. I know that organisations are lazy and only properly document assignments when they want the benefits for themselves (i.e. getting another allocation). I think there is a more important decision to make here: do we still want this level of documentation for operational purposes?

If we don’t want/need this level of documentation anymore then sure, remove the mandatory PA assignment registration in the RIPE DB. But in that case rewrite the proposal to make that very explicit. Removing the requirement using the wrong arguments is misleading. Call it what it is.

The main goal of the policy is to update it on the current situation and what is already happening in practice and to give more freedom to the LIR to decide how far in detail they want to register their (sub-)allocations in the RIPE DB. Of course, there needs to be always enough information for sufficient information gathering for things like abuse. This is already written down in the RIPE Database Terms and Conditions and the Abuse Contact Management in the RIPE Database policy. Getting another allocation is not possible anymore for IPv4. There are a lot of different situations imaginable with all their specific needs for the level of information. This you already can see back in the findings of the Database taskforce. So the question is do we want to update the policy to the current situation and still fill in enough information for abuse e.g. or do we want to enforce the current situation back to the policy? Feel free to let me know if the policy needs to be improved to show/explain better the goal of it. Kind regards, Jeroen

Hi Gert, Thank you also for your feedback. This seems to be very similar to the pre-proposal sent by Jeroen in May, which did not meet overwhelming support. Like, I was highly sceptical, and had a sub-discussion with James about the suspected intent, and nobody spoke up in favour of going this way. I tried to update the policy on the feedback that was given by the few people on the mailing list and at RIPE84. What I understand as feedback was there shouldn’t be a difference in own usage or if it is used by a third party and the /25 problem is a database issue. This formal proposal has some changes to the pre-proposal, but I can still not support the motivation - one of the fundamental pillars of RIPE address policy is "documentation", so argueing with, quote, "unnecessary efforts by LIRs to register IPv4 prefixes and by the RIPE NCC to ensure that LIRs complied with the policy" will meet very strong resistance from side. The proposal tries to aim for the extra work that needs to be done for making allocations in the RIPE DB. So it is just about the allocations and not about other information in the RIPE DB. I can imagine now you point it out, that the word choice could meet strong resistance. Would you maybe have an alternative for it? If we want to do away with registration requirements because we think that knowing the holder of an address block is less important nowadays, then say so. But "the inconvenience of following the policy" is a very bad reason to do away with it. Nowhere is concluded that knowing the holder of an address block is less important nowadays. In the end, the final responsibility is still at the LIR whereby this information is already in the database added by RIPE NCC itself. Next of that, it is still obligated (as the Terms and Conditions<https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms>/Abuse Contact Management in the RIPE Database policy<https://www.ripe.net/publications/docs/ripe-705> specifies) to put in enough information for efficient abuse handling for example. Also, the inconsistencies show that in practice not all information is added like the rules are telling. So at the moment, the policy is out of sync in comparison with what happens in reality. We have three options for this situation. - One way we stronger enforce the current rules. - The second one is to not do anything and keep the rules out of sync in comparison with reality. - Or we can change the policy to what is already in real life happening In my opinion, I think in this case it would be better to go for the 3rd option. It is better to focus on important information like the right contact information than if someone didn’t specify enough information about how their IPv4 prefix reservation is for their network. Also, I think the bigger majority of the LIRs are more than willing to put enough information in the database to make sure everyone can get the information they need like in the case of abuse. LIRs that outsource the IP space to third parties also benefit from having the right information. What is left is a really small group of LIRs that don't keep to the rules. With this policy change, I don’t see any difference in effect in comparison with writing down the wrong information. Next of that, this is only about inetnum objects and not about contact information. The second rationale is "there is too much stuff in the DB that should not be there" - since this was put in voluntarily by over-eager LIRs (as it seems), I (still!) do not see how changing the registration from "mandatory" to "voluntary" would change that. With changing from mandatory to voluntary we make sure that the LIR doesn’t get obligated to fill in repetitive information. I think having a BCP document that explains to LIRs what the community expects to see in the RIPE DB ("for a netblock that has /32s assigned to private end users, documenting the block only is considered better than having end user data in the RIPE DB", and stuff like that) is a much more useful way forward with perceived inconsistency between the way LIRs handle the existing lack of guidance in this respect. A BCP would maybe help indeed. But even with the courses and certifications that are already available, there are still LIRs that don’t follow this guideline and find a more suitable way for them to document stuff. I don’t think that stronger enforcement is the right way of pushing LIRs to follow rules exactly that are for them not practical. Also, I think no one is waiting for the extra resources RIPE NCC would need to enforce this. Personally, I think there is enough space to create the freedom for the LIR to choose what is suited best for the LIR itself. So there is space for changing the rules to what is already happening in practice. We can also try to think about a lot of situations different LIRs are facing and create a ton of rules for it with exceptions and all other stuff. But I think that just a guideline to "document what is needed” for inetnum objects is much more practical and saves everyone a bunch of overhead. Technically, the "new policy text" wouldn't work the way it is written - it says "Registration is the final step in making an allocation", but the sentence before that says "... not mandatory". Now what? Also when the policy changes is still the registration the final step. The only difference is that the LIR can choose what to register for inetnum objects. But in the end, the IP block is already registered by RIPE NCC in the database, and also the right contact information still needs to be filled in. Kind regards, Jeroen

Hello, Just want to summarize my thoughts as a member of, but not speaking on behalf of, the Database Requirements Task Force. APWG co-chair hat off. Resulting report from the TF’s work is available here, including purposes of the database, requirements, and resulting recommendations: https://www.ripe.net/publications/docs/ripe-767 - I don’t read this policy proposal as a revolution to solve all RIPE database issues. It's more a timely pruning exercise of policy that is and has been extremely inconsistently applied (and comprehended?) by users of the database. Clean-ups of existing data is not in scope. - Whether or not it was an original intention, documenting assignments in the database absolutely became *the* key functional mechanism for justifying additional IPv4 PA space from the RIPE NCC. That very real and very important function is now obsolete. - Registering assignments would still be possible and is recommended in this proposal “especially when LIRs want to sub-allocate or assign to another entity (sub-allocated PA/assignments) parts of the IPv4 resources they hold”. Indeed contact information for administrative and technical matters was reported by the TF as a baseline requirement for the database. Note LIR contact details are already in the database for every IP resource they hold, and they could share different info for separate\more specific networks if they so choose. No change there. However, *those who do not want to* would not be forced by policy to pump additional inetnum objects into a public database that the community has complained about already containing much unreliable info (paraphrasing from multiple feedback). Are those orgs and individuals really likely to keep such data accurate and up-to-date? - Re: GDBR, forcing IPv4 holders to create and maintain less entries can only have a positive (albeit probably negligible) effect on personal data in the database imho. - Re: Abuse, good point and important topic. Open question – considering orgs could still register assignments, how would this proposal have any practical effect on potential abuse or fraudulent use of IP space? Re: next steps – does the APWG see any value in exploring this topic further in its current or any other form? Regards, James On Tue, Oct 4, 2022 at 7:56 PM Jérôme Nicolle <jerome@ceriz.fr> wrote:

Hell all,

I'm thorned on this one.

While I fully understand RIPE NCC' willingness reduce the administrative burden on something that's supposed to be deprecated, we all know that the scarcity will introduce new challenges against fraudulent use of address space. If not with a fully documented assignments' database, we would loose a tool to mitigate abuse.

On the other hand, let's be realistic, only a very few of us document assignments in full, and in a way that's not actually bloating the database.

As far as I'm concerned, I see two scenarios :

- An ISP who wants to distinguish its infrastructure from its customers - A more general provider delegating prefixes routed from other ASNs.

The second case is clearly closed : to get a route object, the INETNUM has to be specified.

On the former though, I know of some large ISPs moving customers behing CGNs using former infrastructure space and didn't declare it within the database. It's a nightmare when trying to enforce aggressive anti-spam policies.

Does it matter ? I think not.

I'd like to postpone this proposal until we get reports on clear cases and arguments to alleviate the administrative burden and cleanse the database, if any stands. The current policy being not uphold to the best standards doesn't seem to me as a meaningful reason to lighten what _should_ be our responsibility.

Best regards,

-- Jérôme Nicolle +33 6 19 31 27 14

--

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 Jérôme, While I fully understand RIPE NCC' willingness reduce the administrative burden on something that's supposed to be deprecated, we all know that the scarcity will introduce new challenges against fraudulent use of address space. If not with a fully documented assignments' database, we would loose a tool to mitigate abuse. I don't think we would miss a tool against abuse after the policy change. LIRs would be still obligated by the Terms and Conditions as also Abuse Contact Management in the RIPE Database policy, to fill in enough information for sufficient contact handling and an abuse contact. Just to be sure this is extra specified in the new address policy that there needs to be enough good information to have sufficient abuse handling. I'd like to postpone this proposal until we get reports on clear cases and arguments to alleviate the administrative burden and cleanse the database, if any stands. The current policy being not uphold to the best standards doesn't seem to me as a meaningful reason to lighten what _should_ be our responsibility. Yeah, you can see it in the way that LIRs are not following the best standards or you can see it in the way that best standards are not suitable for every LIR. Personally, I think most of the LIRs don’t follow it, is because of that the best standards are not suitable for them. Kind regards, Jeroen

Hello, I agree with David. After further thought, I believe the registration of PA Assignments that are used by entities other than the holding LIR should remain *mandatory*. For reasons of transparency and well, to know who is using the IP space. But I still believe there would be benefit in changing the registration policy of LIR infrastructure Assignments to *optional*. Why? Primarily to: a. Reduce data duplication. The LIR’s tech and admin contact info is already contained in the parent PA Allocation (and also in several other LIR objects). b. Support data accuracy. Anecdotal but from my experience of managing multiple LIRs of different sizes and their address space over the years, I know that simply having less objects to maintain in the RIPE database makes it easier, and more likely, for the LIR admin to keep their data up-to-date. Interesting stats (thanks Ed!): - Total IPv4 PA Allocations in the database today = 60,587 - Allocations without any Assignment = 18,157 (30% of total) - 14,744 of those 18,157 childless Allocations have a covering route object Under current policy, the LIRs should register 14,744 - 29,488 additional Assignment inetnums in the RIPE database. What value would that bring? I also like Gert’s suggestion to better educate LIRs about what the community expects of them – incl. database registration – in a BCP document. Both efforts can help improve data management in the RIPE Database going forward. Regards, James On Fri, Oct 7, 2022 at 8:03 PM David Farmer via address-policy-wg < address-policy-wg@ripe.net> wrote:

On Tue, Oct 4, 2022 at 2:44 AM Angela Dall'Ara <adallara@ripe.net> wrote:

...

Dear colleagues,

A new RIPE Policy Proposal, 2022-02, "Remove mandatory IPv4 PA assignment registration in the RIPE Database"

is now available for discussion.

This goal of this proposal is to change the registration of IPv4 assignments from mandatory to optional.

The registration of IPv4 PA assignments should not be completely optional. Using the word "optional" implies to me that the decision to register an assignment or not is completely at the discretion of the LIR, and I don't believe that is appropriate. LIRs should have an obligation to register PA assignments if the registration is requested by the customer who receives the assignment and/or if the assignment will be visible outside the LIR's network, such as in the global route table. However, registration of assignments not requested by the customer or that are not visible outside the LIR's network should be at the LIR's discretion.

Thanks

-- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --

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

On Wed, Oct 19, 2022 at 2:26 PM Jan Ingvoldstad <frettled@gmail.com> wrote:

On Wed, Oct 19, 2022 at 9:37 AM James Kennedy <jameskennedy001@gmail.com> wrote:

...

Under current policy, the LIRs should register 14,744 - 29,488 additional Assignment inetnums in the RIPE database. What value would that bring?

It brings value in resolving technical issues and IP address abuse issues, e.g. contacting the correct party when a compromised server participates in DDoS, spamming/phishing, etc.

Contacting the LIR only vaguely makes sense, it's like contacting the domain registrar because someone is sending phishing mail from gmail.com. In other words, mostly completely useless.

Understood and agreed if those details are different then they absolutely should be registered in an assignment. Which the LIR could still do in the scenario I mentioned. But the LIR could also decide not to register if the infra assignment would simply duplicate their existing data. Which many LIRs already do. Anyway, I don’t intend on pushing the river or repeating my perspective further. Just wanted to share my two cents :) Regards, James [community member, apwg co-chair hat off]

On Thu, Oct 20, 2022 at 6:10 PM Leo Vegoda <leo@vegoda.org> wrote:

Hi Jan,

Hi Leo,

On Wed, 19 Oct 2022 at 05:26, Jan Ingvoldstad <frettled@gmail.com> wrote:

...

Contacting the LIR only vaguely makes sense, it's like contacting the

domain registrar because someone is sending phishing mail from gmail.com. In other words, mostly completely useless.

Can you please expand on this? People without your experience might not understand the processes you are referring to. Can you explain the problems that users need to resolve and the value that registration of small assignments in the database brings?

Okay. Let's say that there is an ongoing phishing campaign. A CERT or abuse department investigates, finds that IP address A.B.C.D is hosting malicious content. Currently, abuse departments can then use a locally installed whois tool to query ARIN, RIPE etc. whois databases to find out what the presumed correct contact point is, both for the purpose of disabling the phishing campaign. However, if the contact point is a LIR, instead of the end user, this means that the LIR's abuse department gets all the complaints and police contacts, increasing workload and delaying action, if any is taken at all. In phishing and other kinds of IP-traceable abuse, time is of the essence, so accurate and direct contact information for the party responsible is vital. It is therefore better to have a database of contact points with some errors in it, than a database that, over time, is designed to become useless.

...

Additionally, introducing this policy change without also doing something about historical records, seems pointless.

Can you expand on this, too?

If small assignments, for whatever value of "small", do not have value and are only causing extra work, the obvious thing to do is to purge the database of these records as well. However, there is no proposal to do so, and that means that this policy proposal only suggests making very modest changes in how the database is managed, with dubious benefits. -- Jan

Hi, On Mon, Oct 24, 2022 at 04:02:19AM -0700, Leo Vegoda wrote:

As I read the proposal, it is intended to allow LIRs to prune the records they believe do not add value. It would enable discretion, rather than blind obedience. Is that a negative? If so, why?

This puts an enormous amount of trust on the LIR, of which we have manythousands, in all sorts of experience and responsibility levels. If I, as a LIR contact, choose to decide "this is only work for me, it adds no value for me", I can use that argument to put no records at all whatsoever into the RIPE DB, no? ... which would be absolutely contrary to one of the fundamental pillars of address policy "registration where the addresses are". Gert Doering -- LIR admin, and lazy at that -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Mon, Oct 31, 2022 at 01:49:46PM +0100, Tore Anderson wrote:

I never quite understood why we appear to be totally OK with not requiring each individual IPv6 customer assignment to be registered in the database, while we continue to require it for IPv4.

For pool assignments (dynamic IP addresses handed out to dial-in customers), we as a LIR just registered them as ASSIGNED PA assigned to ourselves (and "back then" these assignments fell under the INFRA-AW clause). But for "static assignments", I think policy never permitted this.

In IPv6, LIRs may create an status:AGGREGATED-BY-LIR inet6num, essentially saying something like «in this block there are a gazillion end users, and I am the tech/abuse contact for all of them».

In IPv4, there is no such option. The LIR is required by policy to create a gazillion individual status:ASSIGNED inetnums instead, all containing the exact same contact info. These do not add any value though, they're just a PITA to maintain.

Is there any particular reason why we can't simply "backport" status:AGGREGATED-BY-LIR to IPv4?

The way you word it for IPv6 seems to make sense for IPv4 as well - so yes, this sounds like a good idea to cover the "these addresses are assigned, but there is no interesting contact info here" aspect, and at the same time making IPv4 and IPv6 policy less different. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Mon, Oct 31, 2022 at 02:41:05PM +0100, Tore Anderson wrote:

Not sure about the history, but the current version of this "loophole" is quite narrowly defined in the current policy (section 6.2):

«IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure.»

While it does not differentiate between dynamic and static assignments, do note the use of work «solely».

Indeed. That's the thing, p2p links, which ended up being "okayish" for "end user get a single /32, on the link, and nothing more". [..]

For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice to be able to ("legally") do something similar for IPv4.

I'd say "at least two members of the WG see this as a valid problem statement, so a policy proposal might be called for" :-) (The "should we have competing proposals for the same document active at the same time" discussion is left to the WG chairs, of course) Gert Doering -- LIR admin -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

* Jérôme Nicolle

Thank you for your honest statement. I feel likewise.

Le 31/10/2022 à 14:41, Tore Anderson a écrit :

...

Playing devil's advocate, I would argue that the moment some broadband subscriber decides to set up a port forwarding of 443/tcp to some web server on the LAN where a cake recipe blog is hosted or whatever, the LIR/ISP is then instantly obligated to create a individualised /32 assignment for that address.

It is neither wanted (would potentially conflicts with EU' GDPR in some ways), nor technically feasible (would create way too much load on the database as we'd all have to update it in realtime).

The policy in question allows the LIR to replace the End User's contact information with its own, in case the End User is an individual. This solves the GDPR issue, but it does not allow for aggregating a pool of such assignments – unless they are *solely* used for the connection of the End User to the service provider. https://www.ripe.net/publications/docs/ripe-733#62

...

For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice to be able to ("legally") do something similar for IPv4.

That's what LIR' "Provider Assignments" are for : you stick them up to your BNG's and it never had to do with any individual customers.

I'm not sure we have an issue here, it has been best practice and well adopted since I came around…

Some zeolots of course did declare each and every B2B customer as to brag about it or offload their hotlines, but that's probably a misinterpretation of current policies. As far as I know it never happened on residential broadband yet.

Actually, declaring each and every customer assignment in that way is probably the correct and de jure way to following the policy to the letter – again, unless the assigned addresses in question are all *solely* used for the connection to the service provider. However, given a thousand random broadband customers, you're pretty much certain to find at least one that uses the IPv4 address for something additional, like running a server of some sort. The policy *does* require separate assignments for those (regardless of them being individuals or organisations). Now, as you say, the best practice or de facto interpretation of policy is to simply ignore that requirement because it's not really technically feasible. Yet, https://www.ripe.net/publications/docs/ripe-767#612 suggest that least some LIRs are pedantically following policy to the letter, by «overassigning» individual /32s. I think, therefore, that it would be good to bring the policy text itself in alignment with the de facto/best practice interpretation most of us follow. 2022-02 in its current form is one way to do that, while backporting IPv6's AGGREGATED-BY-LIR would be another. Tore

On Mon, Oct 24, 2022 at 1:02 PM Leo Vegoda <leo@vegoda.org> wrote:

Hi Jan,

Hi, Leo!

On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad <frettled@gmail.com> wrote: Does this approach rely on the registered user knowing about their network and Internet connection? What happens when everything was installed by an external contractor?

I'm sorry, I don't understand. What does who installed a network have to do with this? You get in touch with an abuse contact, which is supposed to be whoever is responsible for handling abuse complaints for a network address. If a contractor's email address is somehow in there, then the contractor should know that their email address is listed as abuse contact, and when someone gets in touch about abusive content/behaviour hosted at A.B.C.D, either do something about it, or forward to the correct contact point. The same goes for any other scenario.

As I read the proposal, it is intended to allow LIRs to prune the records they believe do not add value. It would enable discretion, rather than blind obedience. Is that a negative? If so, why?

This is putting the cart before the horse. The proposal should argue why this is a positive. -- Jan

HI Leo On Mon, 24 Oct 2022 at 16:25, Leo Vegoda <leo@vegoda.org> wrote:

Hi Jan,

On Mon, 24 Oct 2022 at 04:44, Jan Ingvoldstad <frettled@gmail.com> wrote:

...

On Mon, Oct 24, 2022 at 1:02 PM Leo Vegoda <leo@vegoda.org> wrote:

...

On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad <frettled@gmail.com> wrote: Does this approach rely on the registered user knowing about their network and Internet connection? What happens when everything was installed by an external contractor?

I'm sorry, I don't understand. What does who installed a network have to do with this?

You get in touch with an abuse contact, which is supposed to be whoever is responsible for handling abuse complaints for a network address.

If a contractor's email address is somehow in there, then the contractor should know that their email address is listed as abuse contact, and when someone gets in touch about abusive content/behaviour hosted at A.B.C.D, either do something about it, or forward to the correct contact point.

The same goes for any other scenario.

I am trying to understand the difference between an assignment that lists a company name but has all the contact information pointing at the LIR and just relying on the contact data in the allocation. Is there any difference?

Yes. It is not only about contacting but also identifying. It seems to be an 'accepted practice' to list the name and address of the 'holder' of the assignment in the "descr:" attribute. This is regardless of who an operator might contact for network or abuse issues. cheers denis

...

...

As I read the proposal, it is intended to allow LIRs to prune the records they believe do not add value. It would enable discretion, rather than blind obedience. Is that a negative? If so, why?

This is putting the cart before the horse. The proposal should argue why this is a positive.

You are right. The obligation is on the proposal. But it is often helpful to look at the complete picture when evaluating a proposal.

Kind regards,

Leo Vegoda, Address Policy WG co-chair

--

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