KURTIS LINDQVIST: According to my watch, we're back on the hour and we are due to start again. Welcome back everybody and hope you enjoyed the quiz.
So, let's continue ‑‑ as reminder by the way, this is recorded still, and we will have you finished at ‑‑ in 45 minutes and right on time for the NCC staff to prepare for the GM. But before then, we will ‑‑ before we start, the next agenda item, let's see if there is any questions on Hans Petter's presentation from before the break. If there is any additional questions for Hans Petter? I don't see any questions. No. Okay. So, with that, then, the next part of the agenda is the operation update by Felipe, so I'm going to hand over to you.
FELIPE VICTOLLA SILVEIRA: Good afternoon, everyone. I hope you are all healthy and safe in these interesting times.
Before I start, I would like to give a thank you to the Board for the trust they gave to me, Gwen and Kaveh, to be interim managing directors of the RIPE NCC. And I would also like to wish Hans Petter the best of luck and that you have our full support.
So my name is Filippe, I am the Chief Operations Officer at the RIPE NCC, and this is the operational update.
So, I'll start by telling you how is life at the RIPE NCC after we ran out of IPv4.
So, we announced the IPv4 ran out on the 25th November 2019. It was a moment that we had long anticipated and planned for. As we approached the end of our pool and we have seen a very sharp increase in the number of LIR applications. I am going to talk a bit more about that later. Since we have allocated the last block from our pools, a new policy kicked in, which is the policy 2019‑02, and this policy defines the rules in which ‑‑ how the address space should be distributed after the run‑out. It's mostly the recovered address space that we got due to closures. So this policy defines that you should have a waiting list and the allocation size should be reduced from a /22 to a /24. So that is what we have been doing since the run‑out.
In our forecast, that they are going to continue to allocate these small blocks in the foreseeable future.
So back in October, 2016, we had a little bit less than a /8. Most of these addresses was recovered address space, as you can see in the green area in the chart, but also we still had a little bit left from the 185 /8, so it's the last block we got from IANA back in 2012. And last year, in November, we have run out of both of them.
So we completely ran out of IPv4 ‑‑ well not really because you can still see there is a yellow line over there and part of this is address space that is in quarantine. So now, instead of having an IPv4 pool, we have an IPv4 puddle. And this puddle contains mostly recovered address space that we get from closures. This address space is initially put in quarantine. It stays in quarantine for a while, probably six months, and after that it's released into our free pools and then added ‑‑ distributed to the members, using the waiting list as explained before.
So, if you are an LIR and you didn't get an IPv4 block from us in the past, you might be eligible to join the waiting list and get a /24.
Currently, as Nikolas has explained this morning in the Address Policy Working Group in case you were there, our waiting list is empty. We have 1,340 /24s available in our pool. We expect to release a further 456 /24s from quarantine over the next six months.
You can see in the chart over here, the evolution of the waiting list since it was introduced. So shortly after the run‑out, the waiting list went up to more than 100 LIRs that were waiting for a /24. After a while we have released some of these blocks from quarantine. And then the waiting list quickly went down to zero by around mid‑January.
And it has been like this since that time.
As I explained before, we had a very sharp increase in the number of new LIR accounts, leading to the run‑out. So, you can see here that, for example, in July last year, we had a number of 788 LIR accounts being activated in a single month. That was a record high, and I don't think we're going to see anything like that in the foreseeable future.
In average, we're getting more than 500 new LIR applications every month. After the run‑out, and you can see this in the red line obviously, the numbers dropped significantly, and we currently have around 100 new LIR applications every month.
Here you can see how our membership grew over the last year or so. So back in May last year, exactly one year ago, we had a little bit more than 22,000 active LIR accounts. This number grew very strongly until the run‑out, where, at the moment of run‑out, we had more than 25,000 and 500 active LIR accounts. After the run‑out, this number stopped growing, and actually between December and January we had a little bit of a reduction in the total number of active LIR accounts and that's an expected trend, because a lot of organisations that have multiple LIR accounts they can't consolidate these accounts by the end of the year so they do not have to pay the invoices for next year.
After that we saw a little bit of an increase in the number of active accounts and now it's pretty stable, so we have around 25,000 and 300 active LIR accounts.
This has implications for our future income development. When we did some forecasting last year we have been a bit pessimistic so this is actually good news for our future income development. And if you are interested about the financial aspects of the run‑out, I suggest you attend the GM, and Gwen is going to talk more about that.
So changing the subjects now to tickets. I want to show some tickets statistics, I'd like to start with transfers. This chart shows evolution of transfers during the year for several different years so each year is represented by a different line. So in 2018 is the green, the blue is 2019, and purple 2020. And you can see that consistently we have more transfers than in the previous year. There is not a single month that we have less transfers than the same month in the year before, and we expect to see this trend to continue going forward.
Here, we can see the total number of tickets for the different categories in Registration Services. So this includes all the different tickets that we include, it includes the tickets from customer services. What I mainly want to show here is the red line that are the resource requests, which includes IPv4 requests. But also, the purple line, which is the registry uptake tickets, which mostly includes transfers but also things like sponsorship change.
Back around the same time last year, we had way more resource requests than registry update tickets. This year, the trend reversed and now we have way more registry update tickets than resource requests. And this is a trend we also expected and we think that this trend should continue like this.
So now I'd like to change topics and talk about sanctions, or specifically about compliance in the Internet community.
So, we have recently found that two members from Iran and one from Syria were found to be in the European Union sanctions list: It's very important to say that RIPE NCC is an organisation established under Dutch law. And therefore we are legally obliged to comply with certain regulations, like, for example, the European Union sanctions. So, we had to freeze the provision of services to these three members according to our audit procedure.
We're very much aware that this has geopolitical implications for our service region. The provision of correctly registered number resources, it's fundamental to have Internet operating in those countries. So I'm going to quote our Executive Board now.
"The board wishes to caution against measures applied in the pursuit of short‑term policy objectives that may undermine the wider Internet governance system, which is essential to the stability of the global Internet."
And you can see the full announcement in the following link.
So what we have done so far to mitigate that: We have submitted an urgent temporary request that would allow us to continue to providing services to these members, and we are making a reference to the Covid‑19 situation and also potential humanitarian impact if we're forced to terminate the SSAs of these members.
We're also seeking for a more permanent exemption for our services, including the current and the future European Union sanctions.
In our approach, freezing the provision of services ensures the compliance with sanctions while we wait for a response from the authorities.
So, changing now the topics to the recognised IPv4 transfer brokers and how we can ensure the policy compliance.
So we have a list of recognised brokers on our website. We can find the link over there. In the origin ID of this list, I would encourage good behaviour on the part of the brokers. So we return to have this recognised status from the RIPE NCC, the brokers have to agree to comply with certain things like, for instance, the RIPE policies and the RIPE NCC procedural documents.
Late last year, there were some complaints in the members discussed mailing list about some brokers that were supposedly violating the RIPE policies, and for the RIPE NCC, it was very difficult to enforce those rules. And some of the other members are also questioning the value of such service.
So, early this year, the board has asked input from the community about whether you want us to continue maintaining such a list. And there was a lot of discussion going on in the mailing list, and then, after that, the board weighed the pros and cons of both arguments and decided to keep the service as it was seen as a valuable resource for our members.
However, the board also decided to apply stronger due diligence and are going to ask the brokers to agree with stronger terms so we can prevent abuse and the RIPE NCC can actually do its job to enforce those rules.
We are currently working on a proposal for a new legal framework and internal procedures.
Closely related to that is, we have the IPv4 listing services. For the ones who do not know the listing service and the application in the LIR portal, that allows the members to advertise their address space, either the ones they are offering or that they are buying.
This application was written several years ago and it's basically reaching the end of life. So it's very expensive for the engineering team to fix any bugs in this application. So we basically need a full ground‑up reimplementation.
It doesn't have a lot of usage, so we did some research, so we cross‑referenced address space that was in the listing service versus address space that we're seeing being submitted to transfers Registration Services, and the correlation was quite small. We had around 40 LIRs that, in 2019, published an ad in the listing service and then later on have actually requested a transfer.
So, our advice is that investing further in this tool doesn't make much sense, and it's not a wise way to spend membership resources. So what we propose to decommission this service, unless there were strong objections. So I'd be happy to hear your input. You can go to the chat now or you can go, later on, to the members discussion or the NCC Services mailing lists and give your opinion there.
The last topic I want to talk about today is RPKI and the steps are taken towards building a resilient and secure trust anchor.
The RPKI foundation was built several years ago. When I talk about several years ago, I talk about eight, nine years ago, when the technology was still not established as a standard for the routing security problem. So, resilience, scaleability, redundancy, they are not primary concerns that we had back then.
The situation has changed significantly over the last couple of years. We are seeing a very strong up‑take in the RPKI deployment worldwide, which puts a lot of pressure on existing infrastructure, but also on existing operational procedures.
Now, we have been paying very close attention to this recent development, and since last year, it became obvious to us that we had to reassess our technical infrastructure, our operational procedures, because those requirements are not part of the original design. So, back then, we set our focus to increase the security and the resiliency of the RPKI trust anchor, and by around mid‑last year we have started with the RPKI resiliency project which has the goal to increase to provide a trust anchor that's secure, reliable, highly available and transparent and with trustworthy operational procedures.
So, as part of this project, we are assessing five different areas. The first one is the technical infrastructure. So things like high availability, scaleability, redundancy, our 24/7 support, having proper SLAs in place.
We have done an assessment mid last year that led to some improvements in our infrastructure, but now we are starting again at this process, where I'm going to talk about in a minute.
The second concern is security. So things like penetration testing, vulnerability testing, and so on. So we had a company specialise in cyber security, are doing all sorts of testing in our trust anchor, all their findings have been either fixed or mitigated. And are currently considering how we are going to do moving forward, if you want to have these kinds of checks done on a routine basis, for example.
The third element concerns cryptography and our clients with the IETF RFCs. So what one should do here is to hire a company that's going to go through our code, go through the IETF as RFCs and then basically say that we're doing what they are saying that we're doing. In other words, to bring transparency to our code base.
The fourth aspect is a very important one, it's about operational procedures. So it's more about how can we keep the integrity of our trust anchor. So, procedures like key signing and key roll, for example. We're in the process of contacting a company just now that to do an audit on these procedures and compare how we're doing ‑‑ considering the industry standards for RPKI. And then we're going to improve whatever findings they get there. And at least you have very transparent, fully published operational procedures that are watertight.
The last aspect concerns our legal framework. So, the more and more companies that start to use RPKI, they want to know what happens when things go wrong. So, where are the liability issues? So it's very important that we have a very strong legal framework here.
Earlier this year, we had a series of incidents happening on RPKI infrastructure. We have published postmortems and also a Labs article that Nathalie Trenaman wrote, giving a full details about these stints. So if you didn't have a chance to read the article and you are interested, I fully recommend it.
We're taking these incidents very seriously and since then we have started app internal task force basically to reassess or technical infrastructure and/or software development procedures. We are looking to things like, for example, monitoring, quality assurance, dev ops, among other things.
This task force is not the same as RPKI resiliency project, they are more autonomously, they are very close to each other so the idea is that once the task force is finished, all the results will be included in the RPKI resilience project, they are going to continue the work from there. And if you want to know more information about our current and future plans for RPKI, I invite you to read my Labs article that I wrote last week, and the link is up over here.
So, to close my presentation, I'd like to say that we see a very solid future for RPKI, and the RIPE NCC will play our role in supporting successful adoption of RPKI worldwide. And as one of the RPKI trust anchors, we will do our best to provide a secure and reliable service to the technical community.
Over the next few years, we want to continue investing the necessary resources into providing a world‑class service. And we want to do this in strong collaboration with RIPE and the wider Internet community; in other words, with all of you.
Thank you. And if you have any questions?
BIJAL SANGHANI: Hi. We have one question from Ron da Silva:
"Were all these new LIRs just supposed to take all the remaining IPv4 by a small set of entities who are just looking to resell?"
FELIPE VICTOLLA SILVEIRA: It's a good question. It's very hard to know exactly what they are going to do with the resources. They requested ‑‑ they get it, they have to keep it for a couple of years before they can transfer it away. I personally believe that some of them actually want to resell, but it's very hard to say.
BIJAL SANGHANI: Thanks.
ROB EVANS: There is one in.
BIJAL SANGHANI: I see it in the Q&A now. Peter Hessler from KLEO Connect:
"When reviewing the legal aspects of the RPKI service, please make sure not to make the same mistake that ARIN did and not publicly publish the public key for the tell. Many organisations are not willing or able to sign such an agreement and the lack of publicly available tell will kill adoption of RPKI."
FELIPE VICTOLLA SILVEIRA: Thank you for the input. I can say we're not planning to do so.
BIJAL SANGHANI: We have one more question from Martin Levey of ‑‑
"Does the Dutch court request requiring the two Syria and Iran LIRs affect RPKI records in any way?
FELIPE VICTOLLA SILVEIRA: The Dutch court is before the Dutch authorities. But neither of these LIRs, they had RPKI setup, so in the end, yeah ‑‑ in the end would have to remove it if they had something, but they didn't have so we didn't have to do anything.
BIJAL SANGHANI: Thank you. We have got a question from James Kennedy:
"Are there plans to integrate RPKI for provider‑independent end users into the sponsoring LIRs RPKI dashboard? The separate wizard for PI resources is a bit cumbersome."
FELIPE VICTOLLA SILVEIRA: Thanks for the input. Yeah, if it's not in our road map, it should be indeed.
BIJAL SANGHANI: I think that's it for the questions.
KURTIS LINDQVIST: Okay. Then, thank you. I don't see any more questions. I think you're done for this time. Thank you.
So, the next point on the agenda is the Q&A, so this is the chance for the RIPE community and the RIPE members also to ask questions, comments, thoughts on the service provided by the NCC or discuss them with the NCC or the wider community as well, of course.
So, this is a bit hard in this ‑‑ this is more or less an open Q&A, if anyone has any questions for the NCC that they haven't already asked. I think they have gone through a lot of presentation we just saw, it was quite extensive. I don't see any other questions coming up.
We are actually quite ahead of schedule. It's very unusual to have this much time in NCC Services, but I guess that's a good thing.
If not ‑ I don't see any more questions ‑ then I think we are almost done. I understand that the NCC wanted to make an announcement about the GM before I close this off? But I'm not quite sure who is making that announcement.
SPEAKER: I am here to make the announcement. So I would just like to remind everyone that the General Meeting will begin in our new Zoom session at 1800 UTC plus 2. If you have registered for the General Meeting you have already received the link to the Zoom webinar and also the live webstream which takes place on a different webstream page, not the RIPE 80 website. Please note that participation in the General Meeting is restricted to the registered members only. So, if you're not going to be following us for the GM, then we'll see you back here and we're done with the RIPE meeting part of today. Thank you.
KURTIS LINDQVIST: Thank you very much. And with that, we are actually done and we can all have a little break before the GM. Thank you all for watching. I'll hand over to ‑‑ I actually don't know. I guess we're done now. Thank you all.
BIJAL SANGHANI: Thanks, bye everyone.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
