November 2019 - ripe-db-requirements-tf

Alternate Universe RIPE Database
by Shane Kerr 19 Nov '19

19 Nov '19

Fellow task force members, [ Apologies for the length. ] Yesterday on a conference call one of the things that we agreed was that it would be a useful exercise to consider what the RIPE Database would look like if we were building one from scratch today. The idea is that we can start with a set of requirements that is truly necessary. I think of this as an alternate universe version of the RIPE Database, a universe where somehow there has never been a RIPE Database, but all of a sudden 25000 network operators decided to get together and create one. -------------------------------------------------------------------------- As a starting point, possibly our other selves would look at RFC 7020 for guidance. Particularly the goals: Internet number resources are currently distributed according to the following (non-exclusive) goals: 1) Allocation Pool Management: Due to the fixed lengths of IP addresses and AS numbers, the pools from which these resources are allocated are finite. As such, allocations must be made in accordance with the operational needs of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation. 2) Hierarchical Allocation: Given current routing technology, the distribution of IP addresses in a hierarchical manner increases the likelihood of continued scaling of the Internet's routing system. As such, it is currently a goal to allocate IP addresses in such a way that permits aggregation of these addresses into a minimum number of routing announcements. However, whether IP addresses are actually announced to the Internet and the manner of their advertisement into the Internet's routing system are operational considerations outside the scope of the Internet Numbers Registry System. 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. These goals may sometimes conflict with each other or with the interests of individual end users, Internet service providers, or other number resource consumers. Careful analysis, judgment, and cooperation among registry system providers and consumers at all levels via community-developed policies are necessary to find appropriate compromises to facilitate Internet operations. And also the technical considerations: As a result of the system of technical standards and guidelines established by the IETF as well as historical and operational constraints, there have been technical considerations regarding the services provided by the Internet Numbers Registry System as it evolved. These technical considerations have included: 1) Reverse DNS: In situations where reverse DNS was used, the policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements posed by reverse DNS zone delegation [RFC5855]. 2) Public WHOIS: The policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements for supporting WHOIS services [RFC3013] [RFC3912]. As the Internet and the Internet Numbers Registry System continue to evolve, it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them. This evolution is discussed in the next section. https://tools.ietf.org/html/rfc7020 I think that even these requirements are too broad for our re-imagined database. Lets look at the goals one by one: 1) Allocation Pool Management IPv4 has run out and IPv6 is effectively unlimited, so this is not actually a real goal any more. 2) Hierarchical Allocation While this is important in the context of IP usage (especially routing), I think that the RIPE Database only need record where it has gotten addresses from (the layer up in the hierarchy) and where it has given addresses to (the layer down in the hierarchy). 3) Registration Accuracy This one remains super important. Probably today this is our most important requirement. And the technical requirements, also one by one: 1) Reverse DNS The RIPE NCC plays a key role in the reverse DNS, but it is not clear exactly what requirements this places on the DNS. One can imagine other models of DNS delegation where the database does not contain any information about the DNS directly. However, reinventing how reverse DNS works is out of scope of our task force, and certainly including reverse DNS information in the database is a straightforward solution. 2) Public WHOIS Similar to DNS, there is no particular reason that there needs to be a public WHOIS for registration information. There may not be any particular need for there to be any public information about registrations at all. (I would prefer maximum transparency possible, but this does not seem like a strict requirement to me.) -------------------------------------------------------------------------- Getting back to our own universe, while the RIPE Database is first documented in the document RIPE 13, the original purpose for the database is probably best documented in RIPE 4: Task Force 2: Network Management and Operations European IP traffic is carried by a multitude of different infrastructures. The resulting pan-European IP infrastructure needs to be well managed in coordination with the managements of the underlying infrastructures. Currently this works well enough. With the expected growth a generally agreed management coordination is needed. This task force should develop a managament framework and collect the necessary management information. Coordination with all other task forces activities is needed. Task 2-1: Create and maintain a (`whois') database about RIPE IP networks and their management information. Term: Ongoing, reports monthly, first Dec89 Task 2-2: Create an infrastructure of operational contacts via various means of communication. Term: Jan90 Task 2-3: Create a procedure for notification of security relevant problems assuming that the networks itself are unusable. Term: Jan90 Task 2-4: Develop procedures for common network operations. These can be loosely agreed and need not be formally specified. Topics: Use of SNMP, reciprocal logins for testing purposes etc. Term: Mid90, first rep Jan90 Task 2-5: Gather operating statistics. Traffic volume. Number of networks, hosts. etc. These are useful for planning and external publicity. Term: Ongoing, first rep Jan90 Task 2-6: Set up a European NIC which makes available the results of tasks 2-1 to 2-5 to all interested parties. Term: End90, first rep Mar90 Task 2-7: Maintenance and distribution of sets of common utilities, needed for the execution of the tasks 2-1 to 2-5. Term: ongoing. Task 2-8: Create and maintain centers of expertise in certain areas: router hardware and software, NSS, IBM software, etc. Term: ongoing. https://www.ripe.net/publications/docs/ripe-004 Sadly the motivation for this particular list is not included in the RIPE document, although we can ask one of the authors (Daniel) if he thinks that it is useful for him to provide this. I tend to think in our alternate universe only the first three tasks have much relevance any more. -------------------------------------------------------------------------- So, my own straw-man proposal for the minimum set of goals of a greenfield RIPE Database would be mostly based on RFC 7020: A) Support accurate Internet number registration. B) Provide views of the registration information, including a public one. C) Include whatever data is needed to support dependent technologies like DNS and RPKI. If we can agree on a set of goals (whether a version of these or something radically different) we should be able to list requirements that follow from them. Cheers, -- Shane

1 0

Requirements for the RIPE Database... or Databases?
by Shane Kerr 18 Nov '19

18 Nov '19

Fellow TF members, tl;dr Do we want to explicitly say that we are making requirements for separate databases? (Probably with separate requirements.) More words follow... I was thinking about starting off a discussion about stakeholders in the RIPE Database, and I quickly remembered that the RIPE Database is at least two and maybe more databases in one. We have the number registry: * IP address assignments (hierarchical) * ASN assignments (semi-hierarchical) We have the routing registry: * Routes * Routers * Other routing policy information in various objects & attributes We have some DNS information, which is used to configure DNS delegation in DNS servers that the RIPE NCC maintains: * Reverse DNS domains We have abuse/security information: * "Incident Response Team" (a.k.a. CERT) * Various attributes (abuse-c, remarks, ...) We have the last remains of attempts at lighthearted fun: * Poems We have contact information used by everything (secondary data, cleaned up automatically if not referenced by something else): * Organisations * Persons * Roles We have the authentication/authorization that protects stuff (also secondary data, although I don't think cleaned up automatically): * Maintainers * PGP & X.509 certificates Finally, I'd like to note that there is a highly-coupled database, which is the RIPE NCC member database. The RIPE NCC keeps all kinds of non-public information, some of which is pushed to the RIPE Database (like organization contact information), some of which the RIPE Database has specific access to (like SSO authentication), and some of which is never entered into the RIPE Database (like billing status). So... do we want to explicitly say that we are making requirements for separate databases? 😄 Cheers, -- Shane

4 3

@EXT: RE: Requirements for the RIPE Database... or Databases?
by Marcolla, Sara Veronica 06 Nov '19

06 Nov '19

Dear all, tl;dr:No, because I agree with the need to understand these several "functionally diverse” DB as ONE holistic concept of RIPE DB. Additional context: Reading the RIPE Database Documentation (https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data…) it says that yes, the RIPE Database holds data for three separate registries (RIPE Internet Number Registry (RIPE INR) RIPE Internet Routing Registry (RIPE IRR) Reverse Delegation and ENUM Registry). However, while these could be three independent databases, the information in each of them is related to each other. In the past it was therefore decided to integrate the three registries into one logical database (which is also one physical database). I too substantially agree with the need to understand these several "functionally diverse' DB as one holistic concept of RIPE DB. One of the things I want to stress is that the RIPE Database is in reality used by many members of the RIPE community on a day-to-day basis and for many reasons, and if it is true that the RIPE Database has grown in complexity with more features, we need to keep in mind this practical usage, and perhaps strive for simplicity. Sara From: ripe-db-requirements-tf <ripe-db-requirements-tf-bounces(a)ripe.net> On Behalf Of Bijal Sanghani Sent: 05 November 2019 17:46 To: Shane Kerr <shane(a)time-travellers.org> Cc: ripe-db-requirements-tf(a)ripe.net Subject: Re: [ripe-db-requirements-tf] Requirements for the RIPE Database... or Databases? On 17 Oct 2019, at 14:07, Shane Kerr <shane(a)time-travellers.org<mailto:shane@time-travellers.org>> wrote: Fellow TF members, tl;dr Do we want to explicitly say that we are making requirements for separate databases? (Probably with separate requirements.) More words follow... I was thinking about starting off a discussion about stakeholders in the RIPE Database, and I quickly remembered that the RIPE Database is at least two and maybe more databases in one. We have the number registry: * IP address assignments (hierarchical) * ASN assignments (semi-hierarchical) We have the routing registry: * Routes * Routers * Other routing policy information in various objects & attributes We have some DNS information, which is used to configure DNS delegation in DNS servers that the RIPE NCC maintains: * Reverse DNS domains We have abuse/security information: * "Incident Response Team" (a.k.a. CERT) * Various attributes (abuse-c, remarks, ...) We have the last remains of attempts at lighthearted fun: * Poems We have contact information used by everything (secondary data, cleaned up automatically if not referenced by something else): * Organisations * Persons * Roles We have the authentication/authorization that protects stuff (also secondary data, although I don't think cleaned up automatically): * Maintainers * PGP & X.509 certificates Finally, I'd like to note that there is a highly-coupled database, which is the RIPE NCC member database. The RIPE NCC keeps all kinds of non-public information, some of which is pushed to the RIPE Database (like organization contact information), some of which the RIPE Database has specific access to (like SSO authentication), and some of which is never entered into the RIPE Database (like billing status). So... do we want to explicitly say that we are making requirements for separate databases? 😄 I believe we should cover all databases that come under the RIPE Database umbrella today and as part of our role we should review their role and need. It would be good to hear what others think, should our work cover ALL databases within the RIPE database? Is there agreement here? Thanks, Bijal Cheers, -- Shane ******************* DISCLAIMER : This message is sent in confidence and is only intended for the named recipient. If you receive this message by mistake, you may not use, copy, distribute or forward this message, or any part of its contents or rely upon the information contained in it. Please notify the sender immediately by e-mail and delete the relevant e-mails from any computer. This message does not constitute a commitment by Europol unless otherwise indicated. *******************

3 2