Using the RIPE Database for IPAM
Colleagues Do you use the RIPE Database as your IPAM solution? If so, read on.... The RIPE NCC has done a brief review of the recommendations made by the DB Task Force (DBTF). You can find it here: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/initial-analysi... There is one point in the summary that I disagree with: One recommendation can be implemented immediately by the RIPE NCC: - 3. Using the RIPE Database as an IPAM solution The recommendation from the DBTF was: "The task force recommends limiting and discouraging the use of the RIPE Database as an enterprise IPAM solution." This has not yet been discussed by the community and there is no consensus on this recommendation. So the RIPE NCC should not be doing anything to implement this recommendation. There are a number of points relating to this. The first BoF held by the DBTF had 46 participants. They had some polls about IPAM: Where do you hold your canonical IP address assignment details? (13 answers) Internal database or IPAM system (5 - 38%) RIPE Database (5 - 38%) Internal database for detailed assignments and RIPE database for allocations (3 - 23%) What should we do about the IPAM use of the RIPE Database? (12 answers) We should discourage it (3-25%) We should tolerate it but provide restrictions and best practices (5-42%) We should promote it and facilitate it (4-33%) During the BoF some comments were also made on this: Shane's comment "IPAM seems to be an important thing" Nathalie said about 50% of people attending training courses over a number of years said they use the RIPE DB for IPAM. Also trainees said open source IPAM solutions often pull data out of the RIPE DB but have no functionality to push data to the RIPE DB. During the presentation by the DBTF in the DB-WG session at RIPE 83 Shane said (on IPAM): "if you had very light requirements for IPAM then maybe it is OK, but it's not really what it's for" "unable to find out if this [response] was based on misunderstanding of the question" "we think there are probably good ways to go forward with that, for example making hooks so that external IPAM solutions can hook into it...that makes sense, there are certainly many commercial vendors that make IPAM products who would be happy to use hooks, there are many ways that third parties could use this but probably not a requirement" So it looks like there are very mixed views on the use of the RIPE Database for IPAM. Some people also expressed surprise that so many people use the database for IPAM. It is clear that we don't actually understand who, how and why people use the database for IPAM. We need a better understanding of the how and why and the number of users doing this before we can make any decision about discouraging or encouraging this use of the database. Even to consider if IPAM should be defined as a purpose of the database. As we are talking about it, maybe now is the time to start this discussion. If you use the RIPE Database as your IPAM solution maybe you can offer some more details. cheers denis co-chair DB-WG
Denis, On 12/09/2022 16.12, denis walker via db-wg wrote:
Do you use the RIPE Database as your IPAM solution? If so, read on....
Thanks for bringing this up! This was an area that the RIPE Database Requirements Task Force always felt uncertain of. The quotes from me in your mail are correct, and I'd like to say a little more. Full disclosure: I'm speaking as one of the vice chairs of the former task force, but I am not speaking on behalf of the task force. The company I work for, NS1, provides a home for the NetBox (the open source software) and could be considered an IPAM provider. I am also not speaking on behalf of NS1, or for anyone but myself. Apologies for the length of this message. ---- One issue is that we (the task force) never defined what we mean by IPAM. Our surveys needed to cover several points and we wanted to keep them as short as we reasonably could; surveys ask people for their time, and we need to be respectful of that. We surely could have done better, but as you (Denis) pointed out the portion of people that replied that they use the RIPE Database for IPAM surprised us. ---- Using the RIPE Database to record certain information about number resources is a requirement of obtaining those resources. RIPE NCC members and other resource holders have to learn the RIPE Database and RIPE NCC systems, and if they want certain automation have to integrate them into their processes. Since organizations are forced to make this investment, it makes sense that they would want to use this system for as much of their IPAM needs as possible. This does not mean that all other things being equal that organizations would necessarily choose to use the RIPE Database as an IPAM solution. If organizations want to track their addresses very closely then the RIPE Database will be unsuitable as it currently is, because it is public. For any such organization, ideally they would only have to update information in one place and have it reflected everywhere appropriate. ---- The RIPE NCC is a non-profit member-based corporation, and as such has always been cautious about providing services. This includes: - Services that compete with members' businesses. - Services that compete with any for-profit businesses. As an example, the RIPE NCC used to provide secondary DNS services, and was encouraged by the RIPE community to stop this except in certain narrowly-defined cases. There are companies that provide such secondary DNS services: both non-profit and for profit, both in the RIPE service region and beyond. Having a service subsidized by a monopoly competing directly with commercial interests could be considered unfair. The RIPE NCC has felt free to provide services necessary to its function or that only it can provide, as well as experimental services that do not compete with anyone because the service literally does not exist anywhere else. So, the RIPE Database, reverse DNS, RPKI, RIPE Atlas, and so on, all fit the model and hopefully do not concern anyone. ---- I do not think that the situation about people using the RIPE Database for a certain amount of IPAM will change, because of the policy requirements. So the question then becomes, "What should the IPAM support of the RIPE Database look like?" My own feeling is that the RIPE Database already has a RESTful API which should meet most automation needs: https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API I do not think there are RIPE NCC-provided tools that many IPAM solutions have, like: - Programs which will scan a network to discover/validate devices - Tools that directly aid network planning - Tools for growth and capacity planning - Cost estimation and deployment model comparisons I haven't looked though! I do not know what the situation looks like for someone who wants this sort of functionality from a 3rd party software and wants it to integrate with the RIPE Database. Learning about that smells like market research, which I actually do think that it would be okay to ask the RIPE NCC to do if nobody in the community knows already. For resource holders who are happy to only use the RIPE Database but do not want their or their users' details public, adding non-public information to the RIPE Database seems like a possible way forward. As someone who has worried a lot about privacy you (Denis) probably have more to say about the implications of that than I do. ---- Thanks again for bringing this topic up, Denis! Cheers, -- Shane
Hi Shane Thanks for adding some more detail. I was struggling to know exactly what is meant by the phrase "using the RIPE Database as an IPAM solution". Googling for IPAM solution, I found many systems that provide lots of features that are clearly not available through the RIPE Database. I know the RIPE NCC has this overriding principle not to provide services that compete with members or other commercial services. Is it a question of where you draw the line on what features you can build into the database software? Geofeed is an interesting example of this. There are many commercial organisations that provide geolocation information. The argument given for building geolocation details into the RIPE Database is that resource holders have a better understanding of where addresses are actually located. So having this feature in the database provides more accurate data. But has this redrawn the line on geolocation services? Is there an argument that if resource holders must use the RIPE Database for some aspects of resource registration, it makes sense to add 'some' more features to the database to make the management of their address space easier? As for privacy, let's see how the discussion goes and what people want, then see if there are any privacy concerns. I know we have also had a principle that ALL data in the RIPE Database is public. We again moved that line when we stopped making password hashes public. If the community wanted to add some additional information to the database for any purpose, there is no reason why that information would need to be public. Private data could be allowed and accessed through the LIR portal. We do need more input from resource holders on this issue. cheers denis co-chair DB-WG On Tue, 13 Sept 2022 at 09:49, Shane Kerr via db-wg <db-wg@ripe.net> wrote:
Denis,
On 12/09/2022 16.12, denis walker via db-wg wrote:
Do you use the RIPE Database as your IPAM solution? If so, read on....
Thanks for bringing this up!
This was an area that the RIPE Database Requirements Task Force always felt uncertain of. The quotes from me in your mail are correct, and I'd like to say a little more. Full disclosure: I'm speaking as one of the vice chairs of the former task force, but I am not speaking on behalf of the task force. The company I work for, NS1, provides a home for the NetBox (the open source software) and could be considered an IPAM provider. I am also not speaking on behalf of NS1, or for anyone but myself.
Apologies for the length of this message.
----
One issue is that we (the task force) never defined what we mean by IPAM. Our surveys needed to cover several points and we wanted to keep them as short as we reasonably could; surveys ask people for their time, and we need to be respectful of that. We surely could have done better, but as you (Denis) pointed out the portion of people that replied that they use the RIPE Database for IPAM surprised us.
----
Using the RIPE Database to record certain information about number resources is a requirement of obtaining those resources. RIPE NCC members and other resource holders have to learn the RIPE Database and RIPE NCC systems, and if they want certain automation have to integrate them into their processes.
Since organizations are forced to make this investment, it makes sense that they would want to use this system for as much of their IPAM needs as possible. This does not mean that all other things being equal that organizations would necessarily choose to use the RIPE Database as an IPAM solution.
If organizations want to track their addresses very closely then the RIPE Database will be unsuitable as it currently is, because it is public. For any such organization, ideally they would only have to update information in one place and have it reflected everywhere appropriate.
----
The RIPE NCC is a non-profit member-based corporation, and as such has always been cautious about providing services. This includes:
- Services that compete with members' businesses. - Services that compete with any for-profit businesses.
As an example, the RIPE NCC used to provide secondary DNS services, and was encouraged by the RIPE community to stop this except in certain narrowly-defined cases. There are companies that provide such secondary DNS services: both non-profit and for profit, both in the RIPE service region and beyond. Having a service subsidized by a monopoly competing directly with commercial interests could be considered unfair.
The RIPE NCC has felt free to provide services necessary to its function or that only it can provide, as well as experimental services that do not compete with anyone because the service literally does not exist anywhere else. So, the RIPE Database, reverse DNS, RPKI, RIPE Atlas, and so on, all fit the model and hopefully do not concern anyone.
----
I do not think that the situation about people using the RIPE Database for a certain amount of IPAM will change, because of the policy requirements. So the question then becomes, "What should the IPAM support of the RIPE Database look like?"
My own feeling is that the RIPE Database already has a RESTful API which should meet most automation needs:
https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API
I do not think there are RIPE NCC-provided tools that many IPAM solutions have, like:
- Programs which will scan a network to discover/validate devices - Tools that directly aid network planning - Tools for growth and capacity planning - Cost estimation and deployment model comparisons
I haven't looked though!
I do not know what the situation looks like for someone who wants this sort of functionality from a 3rd party software and wants it to integrate with the RIPE Database. Learning about that smells like market research, which I actually do think that it would be okay to ask the RIPE NCC to do if nobody in the community knows already.
For resource holders who are happy to only use the RIPE Database but do not want their or their users' details public, adding non-public information to the RIPE Database seems like a possible way forward. As someone who has worried a lot about privacy you (Denis) probably have more to say about the implications of that than I do.
----
Thanks again for bringing this topic up, Denis!
Cheers,
-- Shane --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
denis walker via db-wg wrote on 13/09/2022 14:16:
I was struggling to know exactly what is meant by the phrase "using the RIPE Database as an IPAM solution".
the dbtf interpreted this as something along the lines of: "using the RIPE Database as the canonical reference for the holder's internal address assignments". The difficulty here is that the ripe db wasn't really designed to be granular enough, or private, or extensible enough, to suit the requirements of LIRs and other DB consumers for generic IPAM functionality. Separate to this, because it's a public database, there is no way of not exposing potentially confidential data. On the other hand, IPAM software suites are built for these purposes. Ultimately, people need to use tools that are fit for purpose. You can knock in a nail with a pliers, but that doesn't make it the best tool for hammering. Nor does it make it pliers any less useful as a type of tool. We're in the same territory here with the RIPE DB and purpose-built IPAM systems. Nick
On Thu, 15 Sep 2022, Nick Hilliard via db-wg wrote:
denis walker via db-wg wrote on 13/09/2022 14:16:
I was struggling to know exactly what is meant by the phrase "using the RIPE Database as an IPAM solution".
Hi, I had the exact same problem :-)
the dbtf interpreted this as something along the lines of: "using the RIPE Database as the canonical reference for the holder's internal address assignments".
Hmmm. i guess that is still open for interpretation... When the LIR admin distributes some space for department A or department B, we currently don't reflect that on the RIPEdb. However, the RIPEdb is still the source of truth for assignments, which are made to our members (i.e. "customers" in the commercial universe).
The difficulty here is that the ripe db wasn't really designed to be granular enough, or private, or extensible enough, to suit the requirements of LIRs and other DB consumers for generic IPAM functionality. Separate to this, because it's a public database, there is no way of not exposing potentially confidential data. On the other hand, IPAM software suites are built for these purposes.
I've struggled as a CSIRT about point-to-point (back-to-back) subnets. I need to be able to tell the world which IP is ours (the service provider) and which IP is managed by the member/customer (so i can associate the appropriate org and thus the abuse-c).
Ultimately, people need to use tools that are fit for purpose. You can knock in a nail with a pliers, but that doesn't make it the best tool for hammering. Nor does it make it pliers any less useful as a type of tool. We're in the same territory here with the RIPE DB and purpose-built IPAM systems.
And you shouldn't expect anyone to use the best tools always, nor manage stuff in the way you think is the most effective way for you. :-) Cheers, Carlos
Nick
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hello, sorry for coming "late to the party". Maybe this is of interest. Cable & Wireless developed a global IPAM system based on the Ripe-DB back in 2001. It had been been in use until the Vodafone takeover and is still used by Vodavone's main IP/Allocation administrator. Main features are: - classification of IP-Ranges on certain criterias like transfer net for pop X in ity Y - Supports IP-V4 and V6 - tool for requesting free ip space i.e. give me the next free transfer net for pop X in city Y - automatic sync with RIPE and APNIC - filtering (remove private attributes) whois daemon (mainly) for use with ARIN Its technically absolutely possible to implement IPAM attributed within the Ripe-DB and offer IPAM as a service for members. The software had been presented on the APNIC/APRICOT meeting back in 2006. I attached the paper in case anyone is interested. Its quite dry though. best regards, A. Vehling
participants (5)
-
av＠nethead.de -
Carlos Friaças -
denis walker -
Nick Hilliard -
Shane Kerr