Database Working Group
.
RIPE 82
.
20 May 2021
.
16:00 (UTC + 2)
.
WILLIAM SYLVESTER: Good afternoon. We're here to talk about the Database Working Group today. We have an exciting agenda coming up. First, I'd like to thank the RIPE NCC and the secretariat for supporting us through this process, we really appreciate their support. But, with that, let's get started, and, Ed, you are up first.
ED SHRYANE: Hi everyone, I am a senior technical analyst with the RIPE NCC, working in the database team, and this is the operational update.
.
So, there is five of us on the team, and this update is the result of their hard work, so thank you to my colleagues for that in the last six months.
.
Progress since the last RIPE meeting in October:
.
Firstly, there was two WHOIS releases: 1.99 in December, and the most visible change was to require the ‑MAT suffix when creating a maintainer object, and this was discussed in the Database Working Group.
.
The second release was in April, and we fixed the managed flag on the aut‑num object, meaning that you can see managed attributes, RIPE NCC‑managed attributes in search results for aut‑num objects now. Previously, this was only seen for inetnum and inet(6)num objects, now it's also the case for aut‑num objects. There was a bunch of other under‑the‑hood changes, and all the details are in the release notes on the website.
.
Two WHOIS outages since October.
.
One, we had a partial query outage for eight minutes in March. It was to do with a rolling OS update. The servers weren't reenabled properly after the update. The takeaway was to improve automation, we need to improve automation around server maintenance, because currently it's a minute process.
.
Secondly, we had a database switchover in March. This is useful to do from time to time, so we practice in case of a failover, in case the primary server fails. And also it's ‑‑ we needed to do it for our maintenance. So similar doing package updates, making complete changes, we need to do a switchover of the primary database.
.
The good news is that it worked fine. Each time we switch over it takes just a couple of seconds. But on one of the switchovers, we caught ‑‑ we happened to catch an update that failed. And normally WHOIS tries to re‑try, will re‑try on a transient error with the database, but in this instance, the error that was thrown was a new one, so we had to take that one into account.
.
But we aim not to have any user visible issues on switchover, it should be transparent.
.
WHOIS features. So some statistics on recently ‑‑ recent changes and introduced features to WHOIS.
.
Firstly, abuse‑c validation, we're now at 102,000 addresses, up from about 90,000 at the last RIPE meeting, and we have about 3% invalid. That's about the same percentage as before.
.
The aut‑num route clean‑up. We're now cleaning about 6 objects a month and there is 59,000 remaining objects in there.
.
NWI‑8, to synchronise LIR portal users to a default maintainer in the RIPE database, now we're at 734 organisations. That's what we were at at RIPE 81, so this is good to see some uptake of this feature.
.
NWI‑9. We see over 150 distinct addresses connecting to our public NRTM. That's also up on the last RIPE meeting.
.
Finally, we added country code data to the database, and this is the from the legal address of LIR organisations, that was 24 ‑‑ covering all 24,000 LIR organisations in December, and since then we have been adding it for our new members as they are added to the database.
.
In progress, there is the next phase where we're doing the same for end‑user organisations with PI space.
.
Person objects.
.
So, there is a lot of personal data in the RIPE database, over 1.9 million. 1.7 million of those are referenced from inetnum assignments. Normally, if a person is unreferenced, they are cleaned up automatically, but cannot do that as long as there are references. But the vast majority of the references are from inetnum assignments and the top ten LIRs are responsible for just over 1 million of those.
.
We did a clean‑up last year to unlock person objects which were previously unmaintained person objects, which were locked by the RIPE NCC, so they couldn't be updated.
.
We assigned ‑‑ we sent 600,000 of those back to the allocation or assignment maintainer. Since then, we have seen 13,000 of those have been deleted and 600 have been updated. And there are 13,000 locked persons that are remaining. We have done some analysis on those, but it's going to take a bit more time to go through those, so that's still a work‑in‑progress for the database team.
.
Finally, I e‑mailed the top ten LIRs referencing person objects from the assignments, in May this year, asked them why they are adding person objects in the database. I think this is useful information, both for the RIPE NCC and we will share any ‑‑ we will share the feedback with the Database Requirements Task Force, so they can ‑‑ to help them form recommendations around person date in the RIPE database.
.
Secondly, I reminded them of their obligations under the GDPR and the database terms and conditions to properly inform persons that they are being added and also to maintain them.
Finally, I asked them to review unlocked person objects that we did last year to ‑‑ that we sent to their maintainer.
.
Data clean‑ups.
.
We did two data clean‑ups around domain objects. Firstly, about 1,500 domain objects which did not have a required N‑server attribute. We deleted those. Most of them related to the ERX project from 2002, but there were some user maintainer objects in there, so we got in touch with them and we announced it on the Working Group.
.
Secondly, there was a trailing dot in some N‑server attributes. The convention since 2012 has been to remove the trailing dot, but the existing data was not cleaned up at the time. And so now we have removed the trailing dot so the N‑server attribute is consistent across the whole database. That affected just over 500 domain objects.
.
On the RIPE database website, we have a new website template. And this is now providing consistency across a lot of ripe.net websites. This is already been done on RIPE Atlas and RIPEstat, but now the turn of the RIPE database and the portal, the LIR portal. So we think it's a cleaner interface.
.
It affects the left‑hand menu. There is a new header across the top of the page, we removed the footer altogether. There was a lot of detail in there. And we have added an apps which is to make it easy to switch between ripe.net websites. The main improvement is to make it more mobile‑friendly, the pages implements responsive web design, and the major upcoming work here is to finish updating the right‑hand side of the page, the data application space.
.
There is some background reading. I have added some things to the RIPE Atlas redesign, which is done in November. That went out in November. And also for the portal and RIPE database, my colleague Theo has a Labs article on that.
.
Upcoming changes:
.
These are changes that we have, we already plan to do in the next six months. We have an upcoming WHOIS release to align between the on‑premise and Cloud environments. We have noticed some environment differences that we need to reconcile. Firstly, now, all time stamps will be reported in UTC. Previously, or currently, some time stamps are reported in Central European Time. Thankfully, in the database itself, in the object data, the 'created' and 'last modified' is already in UTC but in some places we report Central European Time.
.
In addition to the time stamping UTC, it will consistently report ‑‑ the UTC time zone will append a Z to the time stamp.
.
Next will be simplifying the HTTP redirect and rewrite rules. These rules over the rules, and we reckon this is now a good time to clean these up.
Finally, we will be deprecating some insecure TLS cipher algorithms that our proxy servers currently support but that are not supported in the Cloud environment. So we will align those, but of course we'll be announcing this ‑‑ I plan to write a Labs article with all the details and there will an announcement as usual on the new release to the Working Group.
.
The unregistered route and route 6 NON‑AUTH clean‑up. This was announced on the Working Group. There is a proposal for a clean‑up. This issue was raised in January, that a /14 in AFRINIC was deregistered, but there were route and route 6 objects in the NON‑AUTH database that we are still referencing this prefix, a total of 23 of them. So the RIPE NCC, in coordination with AFRINIC, deleted these route objects but there are a bunch more in that database we so propose a clean‑up job to take care of those also. We consider available or unreserved prefixes in the delegated stats. We will use delegated stats across all the RIRs to identify unregistered space, and, currently using that metric, we can see 869 routes and 94 route 6 objects in the NON‑AUTH database that fit that criteria.
.
So the proposal is to run this every night, compare the prefixes with delegated stats. Give a one‑week grace periods in case of mistakes in the delegated stats. And then we will notify maintainers and subsequently delete those routes after two weeks or we can exclude them giving a good reason.
.
Geofeed.
This is a new proposal for geofeed. It's been discussed extensively in the Database Working Group already and Massimo will be presenting on this after my update. But the idea is that a new single optional attribute will be added to inetnum and NON‑AUTH... objects, superseding remarks that's already in use in a couple of hundred objects in the database. It's based on an IETF Internet draft. It's already been defined as NWI‑13. There was a problem statement, a solution definition and a technical impact analysis, but we're currently waiting for a legal review as initial feedback from the legal department was that a geofeed data qualifies as personal data.
And we want to improve the website more. Our next target is to improve the search interface. It hasn't changed much over the years, but we see some improvements that can be made. Firstly, the search page is ‑‑ acts like a Whois command line wrapper. All flags are available all the time and we need to understand how the flags work in order to use the page effectively. And in particular, filtering by type, by object type and inverse lookup can be difficult to use, especially for new users.
.
Also, out of region resources are not returned by default, so you will get a place holder if the resource is out of region.
.
And also, the full text search page is currently separate, so you need to know to go to that other page, that page is better for word searching. And you can match text much better using our full text search engine.
.
So the implementation plan is to start work on this in the next quarter. We will solicit feedback from the community on ideas on what can be improved. And also we will put pre‑releases regularly in the release candidate environment for testing.
.
Proposals.
.
So, these are proposals by the database team. We don't plan on working on these yet, but they have come on in the Database Working Group.
.
WHOIS tags.
.
As noticed by Cynthia, there was a weirdness in dB files, we use dB tags, this is metadata for an RPSL object in the database, it was a beta feature that was released in 2013. Currently there are two tags, a registry resource and user resource. But at some point in time we stopped updating the tags so not all resources are covered by these tags. They are included in some places but not in other places, so they are included as comments in the dump files, and you see them in the REST API responses, but you don't see them in queries, and we don't see use of these flags in the queries logs either. So the question for the Working Group is whether WHOIS tags should be deprecated. And the idea is, if we have consensus on this, that we remove the query flags and the existing tags altogether. And we need to ‑‑ the database team will publish an Impact Analysis on that in the Working Group.
.
Secondly, white pages. This is a feature that was introduced in 2008 as a way to easily reference persons with a significant presence in the industry. It also allows a reference to the person so they are not cleaned up automatically, But also, subsequently, we have an exclusion list of ‑‑ the database teams maintains an exclusion list separately to white pages and for a couple of reasons:
.
Atlas anchor contacts is one. Some users are using it as domain registry contact details. We have reserved names so there are primary keys in the database that are used in documentation. We use it for monitoring and we use it internally for other reasons like bug fixing. And finally, we have had some individual requests from users that they want to maintain their own data in the database.
.
So, the question again for the Working Group is: Should white pages be deprecated? And if the white pages are deprecated, the idea is that we would, instead, move white pages persons to the clean‑up job exclusion list instead and that we would review the current exclusion process in collaboration with the Working Group.
.
So that complete my operational update. Any questions?
DENIS WALKER: There are some questions on the Q&A and the first:
"I just want to once again reaffirm my support for e‑mailing the top ten LIRs referencing person objects and I hope to see more info on how that develops."
ED SHRYANE: Thanks.
DENIS WALKER: "In Remco's presentation in the Address Policy Working Group, he pointed out that there are about 30,000 objects with typos in the status attribute in the RIPE database, various versions of a signed PA with different case on the characters. When will a plan to fix this be ready?"
ED SHRYANE: Well, the reason that's happening is that the database is a case insensitive and we don't preserve case ‑‑ we don't insist on having upper case status values. But if this is an issue for the community and it's something ‑‑ if it's something we need to fix, then, yeah, we can create something for that and conduct an Impact Analysis.
DENIS WALKER: From Randy Bush: "Who is working with NCC legal on geofeed? Need to talk."
ED SHRYANE: Randy, I can put you in touch or e‑mail legal [at] ripe [dot] net directly. They are aware and they are working on a response.
DENIS WALKER: And finally, from Job Snijders:
"Do the RIRs use detached signature to verify their retrieve the delegated stats from the RIR? I see a simple MD5 checks exist but perhaps a GPG signature on the MD5 checksum would improve assurances when delegator stats are to be used to remove RIPE NON‑AUTH objects. "
ED SHRYANE: It's a reasonable question. We currently do use the MD5 checksums and we do connect over HTTPS to download these delegated stats. But as pointed out, it is important, we do trust these files, so it's a good idea to check using a signature would improve it.
DENIS WALKER: From Daniel Karrenberg:
"Does stopping the white pages mean that DK58 will be deleted?"
ED SHRYANE: No, I hope not. There were only four persons protected by this. But I think the issue is whether the community want a community‑maintained list or if they are happy to delegate this to the RIPE NCC. That's the current situation. But, yeah, the Impact Analysis, we should ‑‑ the idea is that we should have a list of valid reasons, of purposes for putting these persons in the database. The clean‑up job is there for a reason, that we don't want unreferenced personal data in the database that doesn't have a purpose, and if we ‑‑ if we're to have an exclusion list of white pages, there should be a purpose behind it.
DENIS WALKER: Another comment from Cynthia:
"I would prefer the exclusion list over white pages as it makes more sense to me, but regardless of what is used, I think we should have either not both white pages and exclusion list."
ED SHRYANE: Yeah, I agree.
DENIS WALKER: Finally from Christian Bretterhofer:
"I see a lot of inetnum and inetnum 6 objects with references to persons not from ISP but from its customer."
ED SHRYANE: Yes, so I believe this is where persons are referenced from assignments, so the LIR would have created assignments for an end user, for the customer, and there are a lot of persons referenced from assignments. And this is something that I'd like to find out more about and this is why we are e‑mailing the top ten LIRs to find out more about why they are doing this. I hope that answers the question.
DENIS WALKER: Yeah, that's the end of the question list.
ED SHRYANE: Thank you. I'll mute myself.
WILLIAM SYLVESTER: Okay, up next ‑‑ thanks, Ed, that was great. Up next is Massimo with geofeeds.
MASSIMO CANDELA: So, hello again, I am Massimo Candela, I work in NTT. The presentation here is about our proposal of having geofeed in the RIPE database, and it is based on our draft at the IETF, which is done with Randy, Warren and Rus.
.
So what is the problem?
.
IP geolocation is important. If you have IP wrongly geolocated customers will complain because they cannot access some content in their region. They will complain with you and you have now to fix it and now the problem is there is no real defined approach how to fix it. So there is no centre or common strategy, but ‑‑ or authoritative data, but what we have is a set of dataset, some produced by the geolocation provider, others are forks of these dataset, they are maintained directly by the content provider.
.
We have an original set of source and what basically can do is e‑mail them and contact many organisations hoping that at least one of them is the source of the error and the error can be fixed.
This is a list of, let's say, the most important geolocation providers at the moment, but there are many more and this list does not include content providers, so you can understand that this type of interaction may be overhead if this happens often.
.
What we are proposing is something really simple. It's based on three steps:
.
Step number 1, create a CSV file, which is a text file, where each line for a prefix or an IP that you want to geolocate. You put a prefix, comma; country, comma; region, comma; city, comma. So, each line like this. This format also exists, it is describes RFC 8805, it is called GeoFIT, it is really a good format and it's already supported basically geolocation providers including the one in the list before.
.
So, we are basing our effort on this format, that is already used.
.
So the next step is you publish it somewhere. But you just have to get a HTTPS URL, you can also put it on GitHub, there are two examples, and now you have an URL that points to that file. Of course nobody else knows about this URL, that's where it comes into play, that step number 3, basically what you do is you go in the LIR portal in case the RIPE database, you find the inetnum that covers the prefixes that you want to geolocate, that you want to provide geolocation for and basically you are the remark that points to the file. So you write exactly this thing, geofeed space URL.
.
Now, what ‑‑ this step back allows you to make the file out auto‑discoverable and also allows you to create a chain for basically easy on a ship verification, let's call it like that.
.
Also, multiple inetnum can point to the same geofeed file. This is what also we are currently doing at NTT so we have one file, you put your prefixes there and you can point various signs
.
Inetnums to that vary.
.
Now, this is an example of a geofeed file. You see that you can put country, region, city, you can also just stop at country or don't put anything. So you can decide the details that you want to provide for each prefix.
.
I am going to skip this. This is where you can find the country code in an easy‑to‑discover format.
.
Here is how you add the remark in the database. Basically, you go in your inetnum, you click it, you go in the recent remark field and then you add the string. When you save it basically you obtain this, after you do a WHOIS query, and you can see that there is remark geofeed the file blah‑blah‑blah. So now it is possible to discover this file automatically.
.
So basically you are done. The only thing that you can do is if you like you can use a tool like this to do a test. You basically run it ‑‑ it runs on all the platform, you do basically the prefix and this is do the entire lookup, with the file, do the longest prefix match on the file and give you the answer so you can check if you get back what you were supposed to get back.
.
Now, why we opted for geofeed, because, in my opinion, it's an amazing format, it is extremely flexible, we can geolocate IP addresses or prefixes, you can put a /24 and a /16 in the same file because the longest prefix match will be used. You can also geolocate at whatever level from nothing to just country to city. Also, you don't need to credit an inetnum for each prefix that you want to geolocate because basically you can take a parent inetnum, point to the file and in the file you can create all TTL granularity that you would like inside the file. So basically you can keep working on that file after.
.
Important info. We are not trying to replace the geolocation provider because they do an important role of validation of the data and of distribution of this data. What we have trying to do is ease and automate the communication with them to reduce the e‑mail exchange. Also another thing we are proposing is a safe easy way to consume this data because at the moment there is no approach for it and there are some original and quite unsafe way also that they are used. So, basically, by linking from the inetnum, we are already giving some assurance of the ownership of the source, because if you fetch the prefixes in the file you have to just run the one that is inside the parent inetnum that you use to reach the file.
.
Also, there is, in case of weekly authenticated RPSL, there is an optional authentication that is possible which is divest of the file fine with the key of the ‑‑ the RPKI certificate of the prefixes relevant, the relevant prefix.
.
So, now, there is this work item in the RIPE database and this is amazing, basically RIPE will be ‑‑ is the first of the five LIRs that started with this. Which is to add an attribute a specific geofeed attribute so that we don't have to exploit remarks for it, and this will allow to have basically a cleaner solution for sure, and of course once this is introduced you may have at most one between the geofeed and remark and at some point move completely to using the geofeed attribute.
.
So now, we are also how to consume this geofeed. This is this application again but it doesn't matter which application you use. The idea behind is the important key. We suggest to use WHOIS dump. All RIRs could use those. Also, in general, geolocation provider and other parties are already familiar with these dumps so it's nothing new. You can parse them all at once and basically collect all the geofeed URL fetch this and create essentially a big geofeed file for all the geofeed that you found.
.
So, this is something that is not ‑‑ we did it ‑‑ as I had said, geofeed format is also supported by all geolocation providers. The only thing to do is to create a crunch of run this, create this global CSV file and import that file like if it was whatever else, format, and already, some geolocation providers implemented this automatically. So, this is periodic auto‑fetching, which is great. It's already working out for us pretty good. More are experimenting with it, they didn't release that they have it in place already. But basically, since they supported geofeed file in case you have any ‑‑ if you like, you can, for example, ask them to automate this process and import automatically this file.
.
So, my presentation is over. I am here if you have questions, and of course I leave here also my e‑mail.
DENIS WALKER: There are some questions on the Q&A.
.
Harry Cross:
.
"Has there been the thought of hosting the content of the geofeed inside the database instead of introducing another external link that could go wrong, please?
MASSIMO CANDELA: I don't think it's really a good idea at all. First of all, having an external link is actually important for valid level. One is that the geofeed information, it's not something that the RIPE has to manage or anything. So, I will have this URL, it's my duty to keep it up to date. I cannot blame anybody else. And we are talking just about a file. Loading this directing the database can be quite cumbersome for the database. Additionally, you have to keep in mind that having an external file, it is important because in my case, for example, who has access to the LIR database is not maybe the person that is operational and has to change geolocation of the addresses so every time you have to ask somebody to has access to do it. Instead, its much easier to link to an external resource and from that moment on work on that resource. Take care of that resource. If it doesn't work because the URL is broken, that's your fault. That's basically....
DENIS WALKER: From Christian Bretterhofer:
"GFE companies, those companies take XXX euros per month and we give them that data for me. Do we get it back?"
MASSIMO CANDELA: So, that's ‑‑ the thing is when ‑‑ it's not that they take data for free. I mean, you have like ‑‑ if your geolocation is wrong, you also lose money because your customers are going to be unhappy.) So it's already ‑‑ the entire pipeline is already in place, so geolocation providers accept corrections by e‑mail already and this is happening for free from what I know. So it's for them to provide geolocation, they will do money anyway if it's your interest to provide correct geolocation because the only one that loses money is you if your geolocation is wrong. Basically we are trying to make this automatic.
DENIS WALKER: Again, Harry Cross:
"This would also bring the benefit of bring the geolocation into WHOIS."
MASSIMO CANDELA: I didn't get this question.
DENIS WALKER: I think it's a further reference to not having the external link but putting it in the database instead, but I think you have already answered that.
MASSIMO CANDELA: Okay.
DENIS WALKER: That's it for questions.
MASSIMO CANDELA: Thank you very much. Thank you for your time.
WILLIAM SYLVESTER: Up next we have Sander Buskens from RIPE NCC talking about the Cloud migration.
SANDER BUSKENS: I am assuming everyone can hear me fine.
.
My name is Sander Buskens, I am a developer on the RIPE NCC database team working ‑‑ I have been working a lot on the WHOIS migration and we'll be giving the update for this subject.
.
So, the Cloud work that we have done since last RIPE meeting, the last RIPE meeting if you remember prior to the last RIPE meeting we deployed the release candidate environment, the proof of concept version of WHOIS running in the Cloud, running on Amazon for the release candidate environment for the community to try out, for us to also experience running it in the Cloud.
.
So, since then we have had a number of WHOIS releases with a preparatory changes. One of the things is WHOIS, when we run it on premises, we do not run it in a container but we run it in the Cloud we will be running it as a containerised application, so we had that at RIPE 81, running as a container, but now we have extended this further to also abstract it a little bit from the Cloud provider. We can also run that elsewhere.
.
Other than that we have been adding some AWS support, most notably this is for the configuration of the application, so, when we run WHOIS on premises, we have configuration that is would pick up from the file system when the application starts up in the Cloud environment it's slightly different, so we actually pull the configuration from AWS. So we have had added some support for this to the application.
.
I think it's important to note that the WHOIS application itself, like the binary of the application is the same. We deployed the same version, exact same version to the on premises as we do to the Cloud environment, so it's its same application.
.
The other thing is UTC changes. This was already mentioned in Ed's presentation. Running on premise is in the Amsterdam time zone, running in the Cloud environment in the UTC time zone. Now, of course we want to align this to make sure that we're running in the same time zone because otherwise we might get some very interesting behaviour. So, for that, we have been going through the application, looking at all the different areas in which we display time zones. We displace time stamps and in which we store time stamps to make sure everything is UTC. We identified a number of places in the application where we display a time stamp but not with time zone information. Sometimes this was in UTC, sometimes in Amsterdam time. And then we have now aligned it everywhere so it's now all UTC that will be deployed, the 101 release.
We have been looking at the Cloud architecture, or a number of things that we have to improve upon. One of those is the HTTP rewrite rules, so, on premise environment that we have, like a service in front of application that gives a bunch of HTTP rewrites. In a Cloud environment, there were ways to replicate, it's not ‑‑ it did not support what we needed. We spoke to the AWS solution architects, came up with a number of different solutions, possible solutions. However, we want to keep it as straightforward as possible so in the end we decided to actually put the rewrite in the application itself in the WHOIS application. There is a couple of advantages to this:
.
It keeps the architecture simpler, we can reuse this also on premise, we can get rid of the Apachi servers and simplify things on premise.
.
Also, it allows for testing these rewrite rules. Something that we don't have at the moment, but we have quite extensive test suite that we run every time we build the application. So we can now also rewrite the ‑‑ test these rewrite rules.
.
Other thing that we were looking at is the database availability setup. So, on items were, we have like one primary write node with a standby write node and then we have a WHOIS application itself runs on four different physical machines, and on this machine is also a database, a read instance of the database which is replicated from the primary database. Cannot really reproduce this in the Cloud environment as such because the application will be running as a container to we were looking at using like a primary instance and a standby instance and no read instances, but of course because it's not on the same machine, it has like a performance penalty so we have been doing quite some load testing looking at this situation, noticing the impact of that. And also if we have separate read instances for the database per availability zone. If we run the application in Amazon, we are running it in free availability zones.
.
So, we don't ‑‑ if we run the read thing there, again we need to look at the performance.
.
Other things that we were doing, so when we deployed the proof of the concept back at RIPE 81 it wasn't feature‑complete in that IPv4 was working, IPv6 was not working back then. We have since had the advantage of a landing zone that's been implemented for us which is fully IPv6 enabled which also allowed us to enable the load balancers in the Cloud IPv6, which means that the proof of concept can now be contacted via IPv6 as well.
.
Mail updates. We have added support for that. So that's now also working. The client IP handling, I think we mentioned this at RIPE 81 as well. For WHOIS it's very important that we know who queries the RIPE database. If you query personal objects we do some accounting on that, you are only allowed to query a certain number of personal objects per a certain time frame. We do that based on the compliant IP. So for the rest and sync updates end points, we exported four headers from the load balancers. So that was already working. However, for the WHOIS port itself, Port 43 and also for NRTM 4444, this was not working at the time so we had to come up with a solution for that as well, within the Cloud environment, so that runs behind the network load balancer which does not support exported 4 so we came up with the proxy protocol which is supported by Amazon so we added support for that to the application which means that the client IP handling is now also working correctly for the WHOIS support in the Cloud environment.
.
And finally, the rewrite rules.
.
But I think we said enough about that already.
.
So, the other thing we did in conjunction with the CCOE, a Cloud Circle of Excellence, which was a circle that was started in RIPE which has a number of different colleagues all working together on clouds related efforts. One of the things we did was setting up a landing zone environment, so a landing zone environment is a bit like a data centre that has all the networking in place, like security controls in place, all of these things, you know, are really convenient for us. When we initially started the proof of concept we didn't have that, we had like an Amazon environment which we installed the application. So now we have this official landing zone environment. So we have the migrated proof of concept into that landing zone environment. We did that so it's now fully running in that environment.
.
Apart from that, we are also using some external environment so we have the release candidate environment but we also have a development environment and we are slowly but surely setting up external environments to move things across.
.
Other things we have been doing, there is a lot of functional integration and load testing. For the load testing I already said it's the database connectivity which is our maintain focus point there. We want to make sure that the performance is similar to what we experience on premises.
.
Integration testing with other systems. And a lot of functional test. The functionality of the application itself in principle doesn't change but wherever we do touch the infrastructure, we want to make sure that the functionality is still working correctly.
.
Also, we have had a Cloud partner that's been helping us reviewing the architecture that we came up and helping with improving the setup in general, looking at thing like monitoring, alerting, also looking at all the parts of the architecture in which way they fail to make sure that we achieve like a maximum availability.
.
And also the scripting that we use to provision the Cloud's infrastructure, also been helping with reviewing that and improving that.
.
And another thing that we have been doing is we also have some scripting, for example, for split files when we export these on a nightly basis, they need to be moved onto the FTP servers, we have some of those supporting shell scripting going on. We need to include the Cloud environment in that as well. So, we're working on that as well.
.
So next steps for us, so finalising the database setup. As I mentioned, there is a couple of ways we can go, so we need to finalise that and decide which one we're going with.
.
Deploying the final preparatory WHOIS release 1.101, with mainly the UTC changes.
.
The other thing we'll be doing is, we have an internal test environment, a bit like an acceptance environment, that is also being used with WHOIS environment by a lot of internal systems in RIPE. We are going to move that one to the Cloud and then we can do some extensive integration testing with all of these dependent systems. Any issues that we then bump into, we can tackle those.
.
Other thing is the external security pen test, so we're going to have, once we deploy to the Cloud, we need to have this security pen tested, to make sure that it's all good.
.
And finally, for switchover and failover testing, we need to conduct that extensively as well. I'll say a bit more about that in one of the other slides.
.
We have had quite some community feedback on the Cloud and the WHOIS Cloud proof of concept which we thank you and look forward to further community feedback, we'd definitely look at.
.
Other thing that we have is the internal review. We'll be looking at the whole WHOIS Cloud migration with legal from a cost point of view, the information securities, that's also ongoing.
.
What we have been doing is all the environments that we have been building up, we have been meticulously writing down all the steps that are involved which result in a detailed go‑live plan. We plan to rehearse this a number of times so that when finally we go live, things go according to this plan, and we'll publish, like, a somewhat more high level plan via the Database Working Group.
.
And finally we're aiming for a Q3 go‑live of the WHOIS.
.
And after that, we'll be looking at scaling down some of the internal environments, because we don't need like three or four development test environments, etc., etc.
.
So, for the service changes. What changes when we deploy this to the Cloud? There are a number of things. We'll be relying a bit more heavily on the DNS entries. It's very important that clients do not cache indefinitely these entries, because we are running in free availability zones and it could be one of those zones might not be available for whatever reason, that means the client needs to fall over to the next availability zone.
.
Also, the load balancers in Amazon support HTTP/2, so that will be supported. The SSL certificates will be signed by the Amazon Root Ca. This is already the case for the RC environment. As I have mentioned in this presentation, we'll be dropping support for for weaker servers which are not supported out of the box by the Amazon load balancers.
.
Other thing which changes is more whois.ripe.net. At the moment you can connect to that for Rest and the sync updates on port 80 and 444 HTTPS. However, when we move to Amazon this will no longer be the case when you can no longer connect to that port 43 and 4444 for NRTM. Finally we'll be publishing a Labs article explaining these service changes in detail.
For UTC, it's a bit of an overview. It's mainly in a response, a notification header in mail message sync updates and WHOIS REST API. They are now all being displayed in UTC and we are also displaying the time zone information. And the same goes for the list versions and the shell versions.
.
So, for switchover, it was also published in the Labs article. We'll be running a WHOIS on premises and of course in the Cloud environment, the Cloud environment AWS will be our preferred live environment. But what we want to do is switch over regularly from the DNS level, normally the DNS will be pointing towards the Cloud. However, when we perform a switch, we will switch the DNS entries to point to the on premise environment. Not to do this regularly into then switch over within 30 minutes. The aim of the switchover is to make sure that if ever we need it, we know for sure that the switchover will work correctly and the on premise environment will work correctly as well.
.
So, if ever we need it for failover in cases like AWS down time, we can then switch back to on premise. That should then happen within one hour.
.
And, in principle, if AWS is not available, the primary database will be in AWS so we will not be able to handle updates, so it will be read only for queries. If it turns out there is any extended down time in AWS, then we plan to move the primary database back to on on premise.
.
That concludes my part of the presentation. So I am handing back to over to you, Ed, for questions.
DENIS WALKER: We have three questions at the moment. Randy Bush:
"How AWS‑dependent has this become? i.e. How much effort to move to Google or European Cloud provider?"
ED SHRYANE: So the answer is not at all. So, we have been very careful to maintain our in‑house solution as well in parallel with AWS. We're trying to to this one step at a time and we're taking one Cloud provider right now but we're not ruling out using a different provider in future.
DENIS WALKER: Question from Harry Cross:
"I notice from the other AWS RIPE talks and PowerPoint presentations that usage has been made of things inside the Amazon ecosystem like Fargate. Has some justificational studying been done on the rationale of that and evaluating the risk of vendor lock‑in?"
ED SHRYANE: The answer is yes, we do take advantage of AWS specific features, because it makes ‑‑ either it makes our lives easier or it improves availability. So specifically, Fargate does simplify the deployment a lot because we don't have individual servers to worry about any more. We deploy the application within a container, and the AWS takes care of the orchestration, but at the same time, we can deapply the application jar standalone to our servers on premise. So we will take advantage of AWS‑specific features where it makes sense but we are avoiding vendor lock I didn't know and that will also be very important going into the future as well. So not just for the migration now but it's something we will be keeping very much in mind in the future.
DENIS WALKER: From Shane Kerr:
"The goal of the database in the Cloud is to get additional geographic locations, I guess not loads, since the on premise will handle the same load?"
ED SHRYANE: Absolutely right. We're not looking for additional server capacity, just to handle load, because we know our load has been increasing but it's quite predictable and we know ‑‑ we have over‑provisioned our environments, so we're quite ‑‑ we are ‑‑ we do know ‑‑ we are quite familiar with the load that's needed and we have done load testing as well with production data so we're quite confident on the the Cloud side too, but the idea of additional geographic locations is to improve availability. Currently we are in one region, in three availability zones, so we'll be ‑‑ we'll be resilient to a failure in one or two availability zones, that's the idea. But in future, we'd like to expand to multiple regions in case a whole region is taken out that we can be resilient to that. I am mindful of the data ‑‑ there is a lot of personal data in the database we need to keep within the EU to simplify our GDPR compliance.
DENIS WALKER: Elvis Velea:
"I believe it is a very bad idea to have the main database in AWS. Please reconsider."
.
From Rudiger Volk:
"How farfetched is the idea of including the alternate targeting to an alternate secondary Cloud provider in the secondary test process?"
ED SHRYANE: If I understand that, I take that to mean that we can test using an alternative Cloud provider? Sorry, I'll try and answer. But to ‑‑ we will try and ‑‑ we will leave the door open to supporting additional Cloud providers. And the application is open source, we'll be running it stand alone on premise so it will be, it will be a responsibility.
DENIS WALKER: Also from Rudiger. Any preparation to allow load management?
ED SHRYANE: Yes. Well, we're doing load testing to anticipate ‑‑ to size our environment to anticipate the production load. And there will be ‑‑ it will be easier to scale up and scale down as appropriate using a Cloud environment versus on premise. So ‑‑
DENIS WALKER: I think that's enough for the questions.
ED SHRYANE: Apologies, I don't have time to answer fully, but I can follow up on the Working Group mailing list.
WILLIAM SYLVESTER: Perfect. Right. So, we're running a little short on time. Next up we have Denis, who is going to be talking about the NWI proposals. We may run over a minute or two. For those of you who have to leave, thank you for attending and we'll follow up on the mailing list. We are also looking for an additional Working Group Chair. If anyone is interested, please reach out to the Chairs. And with that, Denis I'll let you take it over.
DENIS WALKER: Thank you. I am afraid no video because I am using a pretty crappy Chromebook and if you turn the video on you are going to lose the sound.
I will just quickly run through this. NWI, staying at the top of abuse contact changes, we have never had any support for this work item. So, we recommend to cancel NWI‑1.
.
Anyone disagrees, please take it up on the mailing list, please.
.
NWI‑2. Displaying history. This is an action‑point from RIPE 69. It's been open for almost 7 years. We get one comment every few months but no discussion. So it's not enough for consensus. So the Chair would like to make two recommendations based on the comments that have been made over the years.
.
One is to drop the arbitrary limit of deletion point of recreated objects. At the moment he can only look at the history back to the last time it was deleted.
.
The other is to allow the history of deleted objects that have not been recreated. So again, all the histories still there going back 20 years, so, it's possible to do that. If you support or object either of these recommendations, please say something and we need more than one person to comment in the next three months, otherwise we can't draw a consensus.
.
NWI‑4, multiple status attributes. This was about when you assign a full allocation the work was to create 2 smaller assignment objects or we could allow 2 status attributes in very defined situations. Now we have these small /24 allocations, and people are talking about having to make /25 assignments. Maybe this idea is more useful now. But again we still have no consensus on it. So, if you consider this to be important, support it. Otherwise we recommend to cancel NWI‑4.
.
NWI‑8, the SSO authentication groups. The Phase 1 has been completed. All non‑billing users are synced with the auth group. There was a long discussion early 2019 on Phase 2, which was how the user defined authentication groups. It had some support, we have had no comments for two years. So this is a final call. If this phase is considered useful, let us know, otherwise we will cancel Phase 2 and mark NWI‑8 as finished.
.
NWI‑10. Definition of country.
.
Phase 1 was completed last December. Adding country attribute has been added to the organisation objects with type LIR. The NCC is currently working on Phase 2, adding it to the PI referenced organisation objects. So this is ongoing.
.
NWI‑12, NNTLB [inaudible] 4. There's been a lot of interest in this, there is a problem statement being proposed. The NCC is to set up a BoF on Zoom about the way forward. There will be a Doodle poll, pick a date and time, please check the Database Working Group mailing list for details on that.
.
NWI‑13, the new geofeed attribute. There is a consensus to move forward with this. The NCC has done the Impact Analysis, we are waiting for the legal review, so this is in progress.
.
Other issues that have been discussed recently on recent UTF‑8, personal data, authentication of updates, particularly with passwords, white pages. There will be follow‑ups to come on the Database Working Group mailing list over the next few weeks or months.
.
All the NWIs, you can get more information from that URL.
.
So, any questions?
WILLIAM SYLVESTER: There is no questions that seem to be in the ‑‑ online.
DENIS WALKER: Okay. Thank you.
WILLIAM SYLVESTER: With that, we can take this discussion to the mailing list, and we're just about on time. Thanks everyone for attending, and thank you again to the secretariat and our stenographer and everyone else who has made this session happen, thank you to all the presenters, and we look forward to seeing you at RIPE 83.
DENIS WALKER: Thank you everyone.
.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
