Hi Ben, thank you very much for your reply. El 24/05/2025 a las 13:12, Ben Cartwright-Cox escribió:

I am not a fan of this proposal.

Part of the value the RIPE database offers is some kind of reasonable way to get into contact with operators, and this would basically turn a lot of the end records into unactionable records (other than for LEA use cases, something that I am reasonably sure that LEAs are not that familiar with at the moment anyway)

The proposal aims to maintain communication with operators without displaying the information directly. Contacting operators must be possible using data concealment methods, such as temporary email addresses that forward to real email addresses and obfuscating the name of the contact and their organization. The information published in the database is used not only to contact operators, but also during the reconnaissance phase of attacks on entities [1][2]. Minimizing the exposure of public information is a common countermeasure in security processes [3], and the database should offer this alternative. In response, entities hide information in the database, which can result in the database containing inaccurate information.

I've seen the value in the previous ones for removing the requirement for phone numbers and/or addresses, but removing/hiding the entire object is a step too far

I guess what I am not understanding is what you are trying to prevent here by hiding the person object?

The proposal is not only for person objects, but also for other objects that allow a company or person to be identified, if the company chooses to do so. For example, inetnums in the database allows you to obtain an entity's address ranges, making it easier to identify the attack surface [4]. Person/role objects could be used for phising attacks or phone wardriving. I am aware of the changes I am proposing. However, the alternative may be ineffective solutions, such as removing emails or phone numbers, using allocated-by-LIR to add ranges and hide end-user information, registering end-user information as ISP information [5], entering fictitious information [6][7][8], or simply not registering the information in the database ("The RIPE Database Requirements Task Force (DBTF) reported that, in May 2021, there were 16,232 PA allocations without any child PA assignments and 9,986 LIRs held PA allocations containing no PA assignments." [9]). If the database does not offer an alternative, these situations will increase over time and the information may become useless. In addition, the GDPR may impact object information, and an alternative of this type can help preserve contact information while maintaining the privacy of the information. Regards, Rodolfo García (kix) [1] https://www.51sec.org/2025/03/21/cehv13-notes-module-02-footprinting-and-rec... [2] https://ethicalhack.dieg0v.com/herramientas-basicas-para-obtener-informacion... [3] https://e-cq.net/assets/pdf/footprinting-encored.pdf [4] https://nmap.org/book/host-discovery-find-ips.html [5] https://apps.db.ripe.net/db-web-ui/query?searchtext=62.213.192.208 [6] https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=DP10823-RIPE&type=person [7] https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=DP10824-RIPE&type=person [8] https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=ORG-BB268-RIPE&type=organisation [9] https://www.ripe.net/community/policies/proposals/2022-02/

El 26/05/2025 a las 11:24, Lutz Donnerhacke escribió:

* Rodolfo García Peñas (kix) wrote:

...

I would like to make a proposal regarding the database so that privacy can be included in the objects. Among the main objectives of the database [1] are "To provide accurate registration information of these resources in order to meet a variety of operational requirements" and "Facilitating coordination between network operators (network problem resolution, outage notification etc.)", and therefore the database contains information to facilitate these actions.

That's the point. In the case of real trouble, you want to be able to reach out for somebody competent at the other end of the problem. That's why this information is collected, stored and made accessible.

Hi Lutz, In my opinion, the proposal does not change the fact that the information must be collected in the database and made it accessible. The information is simply there, but if the owner does not wish to display it, the database should hide it. Contact could still be made, but instead of sending an email to user@company.com, the email for the user would be a1b4au3afs.privacy-contact@ripe.net. In my opinion, hiding information is optional, but I think that possibility should exist and that it should be done at the database level. If this option is not offered, people may take unusual steps to hide information. For example, in the “NWI proposal: adjusting contact method requirements and adding new methods,” it can be seen that the information between the role and person objects is not consistent. Possibly, if someone wants to hide their information, they will create a role object, because it is not necessary to indicate a contact person or a telephone number. I do not know if historical information is available on the creation of these types of objects and if there has been any change in behavior in the volume of objects created since the publication of GDPR. Perhaps RIPE NCC has this statistical information. It also causes cases such as those shown in my other messages (e.g., incorrect or false information, not creating inetnum/inetnum6 objects, etc.).

...

One proposal is to use a Boolean model for each field (or for all fields in the object) to indicate whether the information should be "protected" or "public."

This option would simply say either: - "I don't care about others, go die yourself" or - "I'm responsible for problems, I cause"

...

Another example option would be to include levels such as "public" (publicly accessible), "LEA" (accessible by LEAs), "LIR" (accessible by other authenticated LIRs), and "private" (fully private).

This option would translate to - "I'm responsible for problems, I cause" - "I don't care about others, but RIPE NCC should not be sued for" - "If everything is fine, others at my league may contact me. If things are broken, I don't care" - "I don't care about others, go die yourself"

I don't think this proposal will change behavior. Are the phone numbers published in the database currently answered? Are emails responded to? If someone does not respond to emails, RIPE NCC is notified and they try to facilitate contact. I think it could be the same in this case.

If this problem is really an issue, I'd propose two other models:

Ultra thin whois ================ The whois server at RIPE only contains contractual information, which delegates every query to the responsible LIR. Every LIR is required to operate its own whois server as part of the LIR contract with RIPE. RIPE NCC sets up monitoring resources including penalties for not operational systems. This model has the opportunity to comply to local law, like we have in non-EU-countries, because the personal data does never cross juristic boundaries anymore.

IANA operates in this way: $ whois -h whois.iana.org 217.17.192.66 refer: whois.ripe.net inetnum: 217.0.0.0 - 217.255.255.255 organisation: RIPE NCC status: ALLOCATED whois: whois.ripe.net changed: 2000-06 source: IANA

This model is interesting and very similar to the one used in RPKI. The LIR can choose between managing the information on the LIR portal or on its own servers. However, my proposal relates to the information contained in the database and how it is displayed, not how the database is implemented (single or distributed). In both cases, the information should be the same. Even so, I think it is a very interesting proposal, and perhaps it should be analyzed in a separate proposal, bearing in mind that not all LIRs are large ISPs and making them manage their own whois servers creates additional work.

Remove whois ============ According to the GDPR, no data should be collected, if there is no need for. Hence, remove all admin-c, tech-c, zone-c, abuse-c fields from the database. Remove all inetnum*-objects which are more specific. There is no need for. The remaining objects are only those, which are required for RPSL queries.

Not storing information is different from not displaying it. To fulfill its purposes, the information must be in the database, and the records and contacts may be different for an LIR and the customers of that LIR. Therefore, in my opinion, there is a need to identify inetnum/inetnum6 objects and contacts (admin, tech, zone, abuse). Contact methods will not display the information (if the user so chooses it), but the recipients will be different.

Remaining comment from my time at ICANN Whois Review: The LEAs do not need whois. They only use it for an initial orientation. They assume, that the registrar (LIR) is part of the organized crime, so all the data is untrustworthy by definition. They are interested in the contractual data, the registry (RIPE) has. And those data should be validated in regular intervals.

I have indicated several possibilities for filtering the information in the database as examples. Perhaps an LIR has no problem sharing the information with LEAs or other ISPs, but it is possible that no LIR (or its customers) wants to share its address ranges and contact persons with “hackers/phishers/...”, and that is the situation we are in. Regards, Rodolfo García (kix)

Hi Lutz, On Tuesday, May 27th, 2025 at 09:02, Lutz Donnerhacke <L.Donnerhacke@iks-service.de> wrote:

* Rodolfo García Peñas (kix) wrote:

...

El 26/05/2025 a las 11:24, Lutz Donnerhacke escribió:

...

That's the point. In the case of real trouble, you want to be able to reach out for somebody competent at the other end of the problem. That's why this information is collected, stored and made accessible.

In my opinion, the proposal does not change the fact that the information must be collected in the database and made it accessible. The information is simply there, but if the owner does not wish to display it, the database should hide it. Contact could still be made, but instead of sending an email to mailto:user@company.com, the email for the user would be mailto:a1b4au3afs.privacy-contact@ripe.net.

So you want to introduce a level of indirection, which does not tackle the problem of spam and phishing at all, but make it worse. You can be still reached by the "privacy-address", but you lose the information, which system was originating the mail. You can't anymore block well known spammer hosters, as well as combine suspicious mail body coming from dynamic address ranges. Instead, everything is coming from the well trusted RIPE servers, you never will block.

It is not a question of resolving spam from the contact system, but rather of avoiding unnecessary exposure of personal data. The source data will be included in the message; what is being hidden is the recipient's information. In fact, the source information is necessary to provide a response. Email filtering can be done at the destination, as before; nothing changes in this regard. In fact, anti-spam tools could even be added to proxies if this is the goal.

Bad actors will use the privacy proxy addresses in the same way as they are using the current ones. Unless you require RIPE NCC to operate spam and phishing prevention at their servers at a very high level, those services will make the problem worse.

Malicious actors already use current addresses without difficulty. Nothing will change in this regard. What is different is that by hiding the destination information, the malicious actor will not know who they are sending spam to or who they are trying to contact.

And for what? The human eye can't recognise the mail address anymore? So the bad actors does not longer know. Who is this person, which they are sending mail to? Seriously?

So that the source does not know the address assignment information or the contact person's details. This improves the security of the entities and individuals registered in the database. We are not just talking about contact addresses; the aim is to protect the information so that not everyone has access to it.

Okay, you might add an real proxy-privacy service at this point, like ICANN is doing. This would require a human intervention step, where the content of the message is checked for legitimate use cases. Processing time between 24 and 72 hours. Very cool solution for an (emergency) contact during a network disruption. Not!

In most cases, no human intervention will be necessary, and I do not believe that delays will be any longer than they are currently. In any case, an emergency contact channel could coexist, validated by strong authentication, operational agreements between LIRs, or, as proposed, different levels of access to database information. It is not all or nothing.

You are right, that several people do not want to give away their contact information. If this is acceptable behaviour: Fine, drop the information from the database = "Remove Whois".

I am not suggesting that the information should be removed from the database. On the contrary, the aim is to retain the registration information while allowing the owner to choose whether or not to make it publicly visible. In fact, the proposal may encourage many LIRs to enter the information into the database.

Otherwise if the information is necessary to operate in the Internet yourself, then you have to publish this information: Standing in public requires to be seen by others. If you do not want to stand in public, use an Internet Service Provider, which is standing there instead of you. You can't have both.

I disagree with this. Given the changes in the current legal and social context, the database should be adapted. Including information in the database does not mean that it has to be displayed publicly. According to RIPE document 804, section 6.2, 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' Even if an entity does not wish to register information in the database, if it is an 'End user', this information should still be included. This paragraph was omitted from the document. Is the intention to exclude the user's contact information? Would it not be better to include the information but not make it visible?

...

...

...

One proposal is to use a Boolean model for each field (or for all fields in the object) to indicate whether the information should be "protected" or "public."

This option would simply say either: - "I don't care about others, go die yourself" or - "I'm responsible for problems, I cause"

...

Another example option would be to include levels such as "public" (publicly accessible), "LEA" (accessible by LEAs), "LIR" (accessible by other authenticated LIRs), and "private" (fully private).

This option would translate to - "I'm responsible for problems, I cause" - "I don't care about others, but RIPE NCC should not be sued for" - "If everything is fine, others at my league may contact me. If things are broken, I don't care" - "I don't care about others, go die yourself"

I don't think this proposal will change behavior. Are the phone numbers published in the database currently answered? Are emails responded to? If someone does not respond to emails, RIPE NCC is notified and they try to facilitate contact. I think it could be the same in this case.

Data accuracy and responsiveness are different problems. If we conclude, that the information can*t be validated, and nobody is willing to take action on inaccurate or unresponsive entries, then this information MUST NOT be collected in the first place: "Remove Whois".

These are indeed different problems. However, this does not justify removing the information from the database. On the contrary, with information privacy mechanisms in place, it is possible to retain the data and, by not exposing it publicly, the quality of the data may even improve.

Besides that, I stand for my interpretation of your proposals.

...

...

Ultra thin whois

This model is interesting and very similar to the one used in RPKI. The LIR can choose between managing the information on the LIR portal or on its own servers.

Valid extension: Let the LIR choose to use the RIPE DB instead of running their own.

I agree, but this would be a proposal to be dealt with separately.

...

However, my proposal relates to the information contained in the database and how it is displayed, not how the database is implemented (single or distributed). In both cases, the information should be the same.

You miss the point of this proposal: The only information stored in a DB is the information, is the information of the active contract, which is always known and validated. Requiring a third party (LIR) to update a subset of their contract information in a DB, which is located in a different, possibly distinct legal region, will always let to inaccuracies over time.

What I propose is a conscious design. The information included in the database is that of active contracts. But what happens if a company does not want to publicly disclose the address ranges it is using to prevent them from being attacked? What happens when a person's personal data is displayed publicly, including their name, surname, telephone number, company name, email address, and that person does not want the information to be publicly accessible? What does the database offer for these situations?

...

...

Remove whois

Not storing information is different from not displaying it. To fulfill its purposes, the information must be in the database, and the records and contacts may be different for an LIR and the customers of that LIR. Therefore, in my opinion, there is a need to identify inetnum/inetnum6 objects and contacts (admin, tech, zone, abuse). Contact methods will not display the information (if the user so chooses it), but the recipients will be different.

The whole purpose of this database is to have access to the most accurate contact information, in order to resolve network issues quickly. Storing information and preventing access, violates this purpose. Hence, the information MUST NOT collected in the first place. Plain and simple.

I understand your point, but I think we need to distinguish between indiscriminate access to information and functional access for cases where it is necessary. Just because information is not publicly visible does not mean that it is not accessible in a controlled manner. There are multiple possible mechanisms (I have proposed some examples) that allow for quick contact in real situations, without this implying total exposure of personal data and entities at all times. Protecting information does not mean that it is not stored in the database; on the contrary, I believe it is a tool for including more information, with greater detail and quality. What is proposed is to decouple public visibility and operational availability.

Lutz

Regards, kix -- Rodolfo García Peñas (kix) http://www.kix.es/ "I asked him once how to change the key bindings and Dave said 'You use the Change Configuration command. On Unix it is abbreviated as cc.' Dave Conroy and Lawrence Stewart.