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-reconnaissance/
[2]
https://ethicalhack.dieg0v.com/herramientas-basicas-para-obtener-informacion-de-servidores-externos
[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/-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
