Plenary session
9 May 2017
9 a.m.
CHAIR: Hello everyone, welcome back this morning. Please have a seat. We're going to start our first set of presentations with Filiz and she is going to talk about Accountability Task Force.
FILIZ YILMAZ: Good morning everyone. It's great to see the whole room crowded this early. My name is Filiz Yilmaz and here is William. We are the Accountability Task Force Chairs and we would like to give you a status update with regard to what the Task Force has done so far. We have been working on it for a couple of months now, and we will try to keep ourselves to only ten minutes so that we can use the rest of the time for dialogue and take further input from you.
So, just a little bit of history, what happened and how this started.
As the RIPE community, we have a good and standing history of having an understanding on our principles where we care about openness, transparency and bottom‑up processes. We live with these, we breed with these in our structure, we have Working Groups all aligned with those principles, but there is a 'but' there. We have been growing over the years, we became a bigger and larger group and at some instant, and these principles spread beyond us where other groups also started talking about these principles, which is great. But there is an understanding that maybe not everything is documented. There are some rules, unwritten rules that we all share, but there is no direct reference to it, maybe if someone would come and look for that.
And there might be gaps. Maybe we understand certain things in a certain way but it is much harder to explain or refer to it if an outsider comes and asks about that. And also, we would like to really be very transparent newcomers. When somebody comes into our group in our fora, there should be ‑‑ they should be able to understand okay, this is how I do things, this is how I raise my concerns, and this is the processes I need to follow.
So the newcomers and the explaining our principles and our processes to an outsider, has been on the focus since the last RIPE meeting. During RIPE 73, there was a presentation and there was some discussion on this. And in October 2016, there was an effort towards forming up a Task Force to work on these areas and having an understanding, reviewing our accountability within the RIPE community. For this purpose, we started with a smaller group, but we kept the membership to the Task Force open and we are currently 14 people. If I may ask our Task Force members to stand up and show your faces, that would be great. So that... some of us here and most of us are going to be around during the RIPE meeting until Friday, so if you have further comments to these individuals, please find them in the corridors and have a chat.
We have a website. We are documenting our scope, what we are going to do, etc., on this very URL, so you can follow us over there.
Now, quickly, we would like to give that status to you what we have done in the last ‑‑ since October. Fair enough there was a Christmas period in between, we know how it goes in the northern hemisphere, so a draft scope has been published and then it had a few iterations. So, at the moment, we are calling for a last call until 12th May, which is this Friday, so lock this scope so that we can further move on, because as you can imagine, it's pretty hard to work and produce more substantial outcomes when you have a moving scope.
The discussions are taking place at the RIPE list. We want to keep that very well known list as our mechanism for the communication for the Task Force. So if you are not part of this mailing list, please go join. There is other conversations there as well, but we didn't want to create a specific mailing list to communicate with the community and then the membership of it would be an issue. So, practical measures, we chose RIPE‑list.
At the moment, the draft scope is talking about a couple of bullet points. We want to make it very clear what we want to do over there. Basically, we want to do a talk taking exercise. We would like to review the existing RIPE community structures, procedures and processes, and we want to evaluate them in regards to their importance and quality. And with that, we would like to assemble a list and identify potential gaps.
Further on, we would like to, if we find out those gaps are important to fill in, it will be vital to fill in, we would like to publish recommendations for the community where we may say this is an important area and maybe the documentation is not substantial or it's not very well referred or it's not very clear.
And further identification of areas will be done where communications or maybe the materials may be required, maybe we will say okay, this is ‑‑ this seems to be an unwritten rule but there doesn't exist a document. So these are going to be our outcomes, and the scope of the Task Force is limited to the examination of the RIPE community. This is very important. We are not talking about accountability of of RIPE NCC. We are looking internally to ourselves.
So, we also have a current status update on the mapping document. This is ‑‑ like I said, it was very hard to guesstimate our timelines and etc. with the moving scope. But eventually we understood the intention why the Task Force was formed. Accordingly, we already started having a list of areas, capturing a list of areas where these accountability areas are mapped out and we are working on this document at the moment, and this review is underway. In fact, today we have our face‑to‑face meeting where we will go through the document and have our initial review on that. And this meeting is at lunch time. But it is open to you too. For logistics reasons the room cannot have everybody, unfortunately, but we are having it open on the WebEx link so if you would like to join it remotely as an observer, you are more than welcome, please use this link.
Now, this is the documents snapshot, we have not yet published to you, but we will, the one that we are going to have our initial review today. Only a partial view, it's not all the document. We just wanted to give you an example of of what we are looking at so that you can imagine what we are doing. And on the next steps so, we want to publish ‑‑
We want to lock the scope first, hopefully, by 12th May, this Friday. We want to publish the mapping document quite soon after our first review so that you can also have a look and maybe add new areas that the Task Force missed, and you can provide more comments for us to work on and include in our work. And then we would like to move ahead with the next steps, which will be identification of the gaps, if there are any, and recommendations to fill them in, such as maybe this area is not documented like I said, and the Task Force would recommend that the community considers to create documentation about this. And then eventually, hopefully, we would like to disband ourselves because we are a bunch of community members doing this voluntarily and we all seem to have day jobs and it would be great if we can disband ourselves and work at some point.
So, just one last slide before I finish. The current status of the recent discussions. There were some e‑mails coming up in the last couple of days on the RIPE list. There were some support for the scope as it is written. There were also suggestions about coming up with a timeline. Yes, once we lock the scope, we want to set up a timeline for ourselves. It was harder to do that with the moving scope.
Work plan: Yes, we will do that. Again, we will publish that on our web page as soon as we can lock the scope.
And don't come up with any new procedures. We won't. We hope we have made this very clear, it's not our intention to come up with any new procedures. All we are doing is a stock‑taking exercise to highlight the areas where we think that you may want to work on, and if you want to come up with a documentation for a certain area, then it will be up to the community.
So, finishing up. We want to hear from you now. We want to leave some ample time for further comments here. We lined up some questions. Of course you are more than welcome if you want to go beyond these questions, but first of all, do you support the scope so we can lock it and move ahead? We would like to move on with our work. Is the approach acceptable for you? Is this transparent for you? And finally, can the Task Force move and start producing our documentation and work?
Thank you. I will leave ‑‑
CHAIR: Any questions? By the way, people, this wasn't a lightning talk. It was actually deliberately brief so that we had room for questions.
AUDIENCE SPEAKER: Hi. My name is Daniel Karrenberg. I am supporting the RIPE community since its inception. You mentioned in your last but one slide some suggestions to improve the scope, the charter document. However, on the list I made some concrete proposals for language to be added to the scope that you published. Will you add that language?
FILIZ YILMAZ: Yes Daniel, we have seen those and as they were sent yesterday, that will be on our agenda today. As for the language, they sound reasonable to me, but I would like to have the rest of the Task Force members' opinion on that too. The main thing I think we would like to focus on is the intention of your suggestions, the real ‑‑ what you are suggesting. What I deduce from that is that you want to have a timeline and you want to have a work plan published. I don't have a particular objection to the wording you are suggesting, I think it can be used but we will run it today at our meeting and see. But work plan and timeline are the things that we already thought to cover any ways.
Are there any Task Force members that would like to respond to that? Also feel free if you would like to come to the mike and respond. Thank you.
AUDIENCE SPEAKER: So. I was going to ‑‑ Peter Koch, a member of the Task Force but of course not speaking for the Task Force. I am going to offer no opinion but a response to Daniel, to the room at large, which is that when somebody asked, I made a suggestion will you add it? Non silence on the list would actually help the Task Force fulfil its goal.
AUDIENCE SPEAKER: I am Shane Kerr and I am one of the few people who has been slightly active on the list. I also don't have any particular objection to Daniel's suggestions. However, he did mention the need for a timeline before, and I said I don't understand why. It seems like it's based out of some sort of concern or fear that it's going to create an unending bureaucratic nightmare, but that, you didn't answer my e‑mail, Daniel, so... I don't know why you think it's so important to have a timeline, and again I have no particular objection. So... my concern really is that, Daniel, you don't seem to be ‑‑ you seem to basically not support the intention of this Task Force. You seem to think that we're a community. We're not at all like ICANN. We have existing mechanisms of accountability, though this is actually kind of an affront to our honour, which, if that's your opinion, then that's fine, please go ahead and say it. But if there is something else going on, then it doesn't seem clear to me. So...
SHANE KERR: Just to be clear we do have a timeline that we have been working towards in the work plane internally, we just haven't published it yet. Our primary intentions are to try and have a majority of our work done before the next RIPE meeting so that we can present summary details to the community in a more depth type basis. That said, Daniel, do you have other comments?
DANIEL KARRENBERG: I'm just responding to Shane. I make no assumption or insinuations about whatever somebody's intention is. I just ‑‑ there was a task force created. A task force proposed a charter. And the charter didn't, in my opinion, is not a charter of a task force. It's a charter of a working group because it has no end time, it has no specific ‑‑ it doesn't mention a specific task. It's very broad and it doesn't mention even what one or the other output documents might be and that's what I'm not comfortable with. I'm not saying that the Task Force wants to do anything. So for outside of what our values are or has any sort of hidden motives. I am just saying if we are talking about accountability. We are we're not talking about a task force promoting PCP38; we are talking about a task force which is concerned about our very way of working and then at least the charter should be right. It should be a task force charter so it should be of an end, it should be as concrete as possible and when I made that suggestion the first time around. Some things changed but those points were not addressed. And I think I addressed the points of why I think the charter needs improvement in the e‑mail I sent. As I said, it's not a task force. It's a committee, it's a working group. The way it's described there, I'm not saying that you are, but that's the way the language is and we're talking about accountability and stuff. So it should be right.
The other thing, and since you invited me, I am afraid of is, and I have seen this in other communities like ours, that we start a process that inevitably leads to suggestions for further formal processes and formalisation. Once such proposals are on the table, we are very well known to fall into the pitfall to discuss the details and the commerce and all that kind of stuff, rather than asking ourselves is this really what we wanted in the first place.
The other pitfall is, that one group sort of proposes a formalism for whatever reason and then if someone speaks up and said we don't want to formalise this, that argument is not really discussed but what happens is like, oh, you against formalisation, so you are against [] modelen apple pie and openness and accountability and all that sort of thing and I don't want us to end up in this kind of discussion. I want us ‑‑ if more process is needed, if there are any gaps and that we see in the way we're working, then we should discuss on how to address them and it shouldn't be a foregone conclusion that it's a formal process is the solution.
SPEAKER: That's great feedback.
DANIEL KARRENBERG: Does that answer your question, Shane?
AUDIENCE SPEAKER: Nurani, and I am also a member of the Task Force. I just ‑‑ I have a few quick points to make.
Very first one is actually to thank the RIPE NCC because they kicked off the work with doing this fantastic mapping of different areas for us to look at, which was very, very good exercise and I think that might be helpful for, if people are not familiar with the work, it might be helpful to look at that.
Secondly, I just wanted to say to, to comment on some of the concerns raised by Daniel.
I think, when it comes to timeline, from what I understand from Daniel's concerns, it's really, the reason he wants a timeline is because that's part of the nature of a task force. When you start a task force up you don't want that to be a permanent thing. It has a clear task and a scope and an end. A task force might turn into a working group, and that's quite possible, but I guess at this point, we are trying to contain the work and I am perfectly comfortable with that.
I would also be comfortable with this turning into a working group if there was a need for that, but we're not there yet.
And then thirdly, I think addressing Daniel's concern of this turning into a... or the risk of this turning into a process where you over‑formalise processes in the community. I find it funny because we have in some ways in the Task Force, we spent more time discussing the risk of us spending too much time over formalising processes than we have in actually looking at things that might need formalising. So, I think it is a valid concern. I do think ‑‑ I trust this community enough to understand that we do not want this to become such an exercise. The Task Force is not here to try to come up with processes and procedures for all sorts of things where there is not a need. But I think we should also be open enough to say just because Daniel has been here for a very long time, and because I have been here for quite a long time, and I feel comfortable enough with participating in the processes, that doesn't mean that that's the case for everyone. So, if there are areas which are not clear to newcomers, for example, or where you kind of have to know because of history or, you know, if we can improve those things, I think that's a good thing, right.
So, improving accountability doesn't mean that we're saying that the RIPE community is not accountable now. It's just looking at how can we improve those things, and I think that's a very healthy exercise. Thanks.
AUDIENCE SPEAKER: Morning. I am Athina. I am part of the RIPE NCC staff that provides secretarial support to the Task Force. The other ones I would like to mention is Paul Rendek and Anthony [Golem]. We are working with a group and we are trying to provide any support they need. So when we were working with the group on the charter, on the Task Force charter, we really tried to step on the example of the previous Task Forces, and use the previous Task Force charters as an example. So... well, I understand that it might be a little bit early to have a concrete time frame because now the group is trying to grasp what exactly needs to be done and how long this will take. So ‑‑ but I would like also to mention a very interesting point of the when we are talking about a difference between the Task Force and what a working group is, we really try to find documentation on what a task force is and we could only find a very, very, very old document, an obsolete document that cannot really be used to describe what a task force is. So it was interesting to see that, well actually these things need to be highlighted and then find out whether we really want to have a description of what a task force is and then make the difference between Task Force and a working group. Thank you very much.
AUDIENCE SPEAKER: Brian Nisbet: So, I think this is ‑‑ what I want to say is, I am not a member of the Task Force. I have been around for a while. But, I think this is a good thing. I think that we ‑‑ occasionally, as people, we are very scared of words like 'accountability' and we're very scared when people start looking at the systems that we work with and we use. But I think we have to show that we are reviewing them. We have to show that we're taking a hard look at our own systems, and what Athina just said about, you know, the Task Force definition, no one ‑‑ everyone kind of assumes they know what that is and yet can anyone actually point to the place where it says this is a particular thing? And when we can't, that's a problem.
So, I agree with a lot of what Daniel sent to the mailing list around timelines, around definitions and obviously what we previously discussed on the mailing list about changing the charter to bring it back a bit to talk about where the issues are rather than to propose solutions to those issues. I'm really looking forward to see what the Task Force does and finds. We, as a community, the very openness that we have, someone every now and again as to look at it and say does this make sense? Does this actually comprehensible in 2017 or 2019 or 2020 or whenever? And I'm very much looking forward to seeing what comes out. I support this work. I would not support a task force which came out with a list of "and we need to do these things", but you have clearly said you are not going to do that. So that is good and that is positive. And I think that it shouldn't be something that goes on forever. I do support a timeline where it's actually fairly tightly bound with the assumption, with the situation we know this is this work and the community agrees that in three years' time or whatever random time interval, there will be another review and there will be another group of people. Because it shouldn't go on forever. Because it's a bad situation, but neither should we say we have done this review now and we don't need to do another one in the future. So I would very much like to see that when the Task Force, you know, tears down its tents and goes home to its day jobs or families or whatever, that it says, right, and we think that in X period of time there should be another review and another group of people should sit down and look at this again to make sure we are still on the track that we should be on in the community.
AUDIENCE SPEAKER: Hans Petter, RIPE Chair. I would like to thank the chairs and the Task Force for the work done so far. I'm very comfortable with the indications you gave on the timeline to complete something before the next meeting. I think that would be excellent if you are able to achieve that. That means that we actually have to conclude at this meeting on what's the scope.
It seems to me that producing the mapping document that you are working on, that's an excellent delivery and it will be the starting point for further discussion no matter. I don't think we need a permanent Working Group on this. I think dividing this work in smaller pieces and then having the discussion do we want to be a flexible environment where we can make up processes on the go? If we do that it may be good to document how we used to do it in the past, not to lock into that we always have to do it like that in the future. But in some places like selecting the RIPE Chair for instance, it may be good to write it down in advance so we know how to do the procedure and not change it on the way.
As to timelines, I started a process with selecting a RIPE Chair and we are way past that timeline for different reasons so it's always possible to adjust the timeline if something happens on the way. So, don't feel shy to be aggressive on the timeline and then come back and say we need another meeting to finalise this. I think that's quite okay. So looking forward to the result of today's meeting. Thank you.
SPEAKER: Just to summarise things. If anybody has any other comments that they didn't get up up today, feel free to talk to any members of the Task Force. We look forward to speaking to you.
(Applause)
CHAIR: Our next presenter is Elvis. I just would like to mention that we have the nominations deadline today at 3:30 for the Programme Committee so feel feel free to nominate yourself. Send an e‑mail with a bit of an intro, maybe a photo. Okay.
ELVIS VELEA: Morning everyone. My name is Elvis Velea. I am the CEO V4Escrow. Today we will be talking about what has happened over the past five years on the IPv4 market. My presentation, the IPv4 transfers five years after runout, is our way of sharing our work, the details of our work with the community.
We're going to show you quite a few numbers, statistics, lots of graphs, and... let's start.
Usually I present on Thursday and then there is a reason for my hangover. Apparently, yesterday was a great day. So I hope you all had a great Monday, a great start to the meeting, and let's dive into the numbers.
So, I borrowed this from Geoff Huston. Apparently the RIPE NCC will, according to his model and according to what we have seen in the past run out somewhere in 2021. We have had already a runout in 2012, in September, and since then we are in the last /8 stage. So, even the last /8 will probably run out somewhere in 2021. The last /8 stage means that any LIR could request a /22 from the RIPE NCC and receive it of course.
There is somewhere around 37 million IP addresses, according to Geoff Huston's slide as well. 37 million IP addresses still available to distribute. Most ‑‑ the biggest chunk was in AfriNIC in March. I'm not sure if they are still there. But we have about 18 million IP addresses reserved. So maybe we should start talking at some point on what to do with the 1 million IP addresses the RIPE NCC has been requested to reserve because it has been reserved for future use and somewhere in the lines of 2019, 2020, we might think what to do with them because if we just reserve them indefinitely it's going to be yet another pool of IP addresses that's going to stay unused.
So, 2012 was an interesting year. Lots of transfers in ARIN, even though they still had a pool of IP addresses. 2013 has seen ‑‑ well, 2012 has seen the first transfer in the RIPE region as well. 2013 has seen further transfers, and there used to be a continuous growth of the IPv4 market until 2016 when we have seen the first increase of the market, and I used to say that 2017 will continue the trend of decreasing the number of IP addresses that will be transferred. However, because MIT has just announced that they are going to sell half of their /8, adding that to the pool of transfers this year will actually mean that the projection for this year will show a slight increase to last year's transfer market.
So, the number of transfers per country will show a huge number of transfers happening in Romania. Now, this graph shows the number of blocks transferred to a country regardless where these were transferred from. So, what this shows is that Romania has seen 1,200, more than 1,200 transfers in the past few years, and that's mostly because there used to be an LIR there that decided they will ask their customers whether they want to either return their addresses or buy them. That has created huge amount of work, a huge amount of transfers over the past few years and has actually split the LIRs large block into very ‑‑ a lot of small chunks.
The next on the list is Russia and then Great Britain. We see Iran also in the list, 440 transfers, and then it goes on. I tried to make this so that it shows Hungary on the list as well. Hungary is, I think, place 29 with 41 transfers happening until, including quarter one of 2017.
When we look at the number of IP addresses. Then we have a different picture. Iran has received the most of IP addresses in the RIPE region. Followed then by Russia, Great Britain, the United States apparently is a country in the RIPE region, and Saudi Arabia as well. Why we see the United States there is because I have actually taken these numbers from the delegated extended files and these were the countries where the LIRs were saying that they reside. It doesn't necessarily mean that these IP addresses are used in the US or in any of these countries. In fact, this is just how they are registered in the delegated extended files.
So, 2012 and before:
Well ARIN has seen about 6 and a half, 6.8, almost 7 million IP addresses transferred in 2012 or about. The 65,000 IP addresses you see in the RIPE region have been transferred after the runout. So after September 2012, and APNIC has also seen 3.4 million IP addresses transferred, with almost 2,000 IP addresses being transferred from ARIN to APNIC. This is the start of the inter‑RIR transfers as we all know it today, and we haven't actually seen any transfers from APNIC to ARIN in 2012 or before.
So, this is the table showing the number of IP addresses and the number of transfers happening. APNIC has seen about 165 transfers in 2012 or before, well actually it's 2012, that's it. 165 there was in 2012. The RIPE NCC has seen 9 transfers of IP addresses in 2012. And nothing before because there was still a pool, a free pool of IP addresses.
So, the first transfer in the RIPE region was in October 2012. The first transfer in APNIC was in November 2010. They have had an intraRIR policy since February 2010, and an Inter‑RIR Transfer Policy since August 2011. They have run out on the 15th April 2011.
The first transfer in ARIN, it happened in October 2009. And they have had a policy since June 2009. They were just a bit over 10 million IP addresses transferred in total in the years before or during 2012.
2013 has seen an increase, as I have shown before, an increase of the number of transfers and an increase in the number of IP addresses transferred having 5 million IP addresses transferred within ARIN, about 2 million within the RIPE region, and one‑and‑a‑half million in APNIC. We have also seen a transfer of more than half a million IP addresses from ARIN to APNIC and this is basically when APNIC has started importing more and more IP addresses from other regions. For now, there was only a possibility of ‑‑ there was only an Inter‑RIR Transfer Policy that was compatible with ARIN, so for now we only see transfers from ARIN to APNIC. There is still zero IP addresses transferred from APNIC to ARIN.
So, we have had 154 transfers within the RIPE NCC region. 172 transfers within APNIC with 17 inter‑RIR transfers, all of them actually coming from ARIN. And about 30 transfers within ARIN.
The number of IP addresses transferred in the RIPE NCC region was almost equal to the number of IP addresses transferred within APNIC.
In 2014, well, this is when we see about 18 million IP addresses transferred. So more than a /16. 4.7 million IP addresses have been transferred within ARIN. And they have actually exported almost 1.1 million IP addresses. The RIPE NCC has seen a huge increase, if we could call it like that, a huge increase in the number of IP addresses being transferred within the region and that's because, there was an IPv4 policy cleanup in 2014 that removed needs‑based criteria, and therefore allowing transfers to happen freely with no barriers. Also, IPv4 PI can be transferred since November 2014. And as I said, more than a million IP addresss have been transferred from ARIN to APNIC. You can see the numbers of transfers within each region just below in the text.
Now, 2015: Well 2015 has seen the largest amount of IP addresses transferred so far. Now, keep in mind all these numbers do not include any transfers of legacy space that has happened within the RIPE region. That's because those are not simple to actually figure out. It's not that simple to figure out what's a transfer of a legacy space. It's any update of an organisation holding a legacy resource, a transfer, is it a merger and acquisition or ‑‑ basically, the RIPE NCC does not have the mandate to make these updates public. That may change and I welcome you to my next presentation tomorrow where we will discuss about this. However, the statistics that you see in front only account for transfers of PA PI space within the RIPE region and legacy space if the transfer happens between regions.
Now, 2015 has seen about 34 million IP addresses transferred within ARIN, and that's by far the largest number that I'm going to talk about. It has also seen 3.8 million IP addresses transferred from ARIN to APNIC making this a larger number so ARIN has exported more IP addresses towards APNIC than APNIC has transferred within the registry.
Now, ARIN has run out in 2015 as well and that's probably one of the reasons why we are seeing a lot of transfers happening in 2015. A lot of IP addresses transferred. We have also seen almost 2,700 transfers within RIPE NCC and 11 inter‑RIR transfers from ARIN. In total, overall, 51 million IP addresses were transferred in 2015 and, as I said again, this does not include legacy transfers within the RIPE region.
So, 2016. Well, first year that the number of IP addresses transferred decreases, we have seen just shy of 33 million IP addresses being transferred and the ARIN region has only seen 15 million IP addresses so that's about half, less than half compared to 2015. We have seen an export of 1.3 million IP addresses towards the RIPE NCC from ARIN, and the RIPE NCC's region ‑‑ the RIPE region has sent about 150,000 IP addresses towards ARIN. And the exchange between the RIPE region and APNIC has been almost equal. We again see about 3.3 million IP addresses transferred from ARIN to APNIC and only 22,000 transferred from APNIC to ARIN.
We see about 2,100 transfers happening within the RIPE region and about 100 inter‑RIR transfers from ARIN. ARIN has had about 500 more transfers in 2016 than in 2015, while the RIPE NCC has had about 500 less. So it's a bit obvious that the transfer market has slowed down in the RIPE region but has increased or has been more effective in the ARIN region. Overall, we see kind of the same numbers of blocks being transferred among all of the regions.
2017: In Q1 we have seen only 6.5 million IP addresses transferred. I'm sure Q1 will show more especially because we know MIT are transferring half of /8 and that will surely increase the numbers of IP addresses being transferred within ARIN and actually it's probably going to be just within ARIN. But we'll see what happens and I'm hoping that in Dubai, I'll get a chance to present an update and we'll see better numbers in 2017.
So, we have seen all of our 420 transfers, or almost 430 within the RIPE NCC region. 80 transfers within APNIC and 261 within ARIN. We were expecting another decrease in the total number of IP transfers, but the number of actual transfers is expected to increase.
We'll see a further deaggregation of large blocks. That's because some sellers prefer to split their larger block into smaller pieces and sell them to multiple buyers. That's mostly because smaller blocks cost is higher.
So, statistics in the RIPE region. We have about 5,400 transfers of P allocations. About 1,000 PI transfers since 2014. We have imported about 4.1 million IP addresss from ARIN and 120,000 from APNIC and we have exported about 168,000 to ARIN and 139,000 to APNIC.
What we have learned, and these are things that, if you are interested in transferring IP addresses, you should be very aware of. When you get an IP block, most of the times you won't get it from the same country that your organisation is. So you will have a few problems with geoIP location and if you immediately put that block into production, your customers will see content offered for other countries.
So, if you are not in a hurry, then we would recommend you to put the block into production and use it in a ‑‑ not put the block into production immediately but use it in a test environment and start contacting the geoIP providers to ask them to update their information.
You should always ask for a blacklist report on the IP block because sometimes the IP addresses that you will see may be blacklisted. If you are the buyer, request the seller to forward the reports that they receive (abuse). Be aware that they will keep on receiving abuse reports even up to a year after the block has been transferred to you. That's because the reporters do not always update their databases and they continue to send reports to the old abuse contact, even though you have made all the changes in the RIPE database and everything.
Start routing the address space immediately. That's very important. Because hijackers are looking at the transfers list and they will attempt to hijack your IP block. Even if for a few hours that's enough to cause a lot of trouble because most of the times they will just send billions of spam messages and your block will get blacklisted immediately. Also very important when you talk to the seller or the buyer directly. Make sure that the person you are talking to has the power of attorney from his company to actually transfer the IP addresses.
So fun facts. I will skip over these but you can look at them on the slides from the RIPE website.
Regional statistics. Hungary has had 41 transfers, about 231,000 have been transferred, IP addresses have been transferred to Hungarian LIRs. No PI transfers, no inter‑RIRs. Hungary has about 500 IPv4 allocations and assignments, about almost 6 million IP addresses. And 145 LIRs.
Now let's talk about pricing. The runout in ARIN has affected pricing so the price has started to go up in ARIN. And in 2015, we have seen that almost all of the regions have gone to a place where the prices were harmonised.
The RIPE Inter‑RIR Transfer Policy also caused the prices to harmonise between ARIN and RIPE. However, prices keep going up while supply is increasing. The minimum price we have observed was around 2013 and that was about $5 per IP address in ARIN and about 7 in RIPE. And there was a lot of IPv4 available in the market. We think that right now, that's what we see, prices are around the 10 to $12 per IP address, at minimum, and there are only a few large blocks available, there are six /16. There are a lot of transactions that are /17 or smaller happening at 12 to $14 and we have seen seen transactions happening between 15 and $20. There is not that much supply available any more. So, unless another /8 holder will join the market, I think that the prices will keep ongoing and we might see prices in 2017 as high as $20 per IP address. And we think that, and we estimate that the price per IP address in 2018 will be around $25 per IP address.
We also think that the IPv4 market place will continue to last until at least 2025.
So, the trend line is quite obvious. The price per IP address is going up. And what we see here is the minimum and the maximum price within a year. So, while the minimum is going up, the maximum is kind of trying to get to the same place. So, we're not seeing a huge diversity on the actual price of IP addresses.
Now, we have kind of been the only broker that had the guts to predict or to try to predict transfers, and how many IP addresses are going to be transferred within the next year. So, in 2014 we predicted that one /8 would be transferred and we were 98% right. In 2015 we said that about 4 /8s would be transferred, and we were about 90% accurate. And so on and so forth. So, for 2017, we think that the number of IP addresses will decrease to somewhere around two /8s in total.
IPv6. Well let's talk about that a bit as well. There has been a huge growth of IPv6 usage over the past few years. However, once we reach 10%, the growth has slowed down a bit. That's because growing from 10 to 20 is not as easy as growing from 1 to 2%. So, we're now somewhere around 18% worldwide and we're seeing a slow down on the IPv6 growth since 2016.
Hungary has around 8.88% according to Google. 8.88% IPv6 adoption, and we see about 26% of the LIRs in Hungary having four Ripeness stars. And that's a bit higher than the average in the RIPE region which is about 20%. However, the thing you should take from this slide is that the lower the IPv6 adoption, the higher the IPv4 prices will be in the next few years.
Thank you very much. Questions?
(Applause)
AUDIENCE SPEAKER: Shane Kerr from Dyn Oracle. One of your slides you mentioned that the available v4 space was basically drying up, disappearing. I was talking to someone earlier who I will not name, and they said that's not really true because people are just going to start shaking IP addresses out of more spaces. Like you mentioned in one of your opening slides about MIT selling half of its /8. Do you think it's just going to be kind of a general smooth curve or do you think there is going to be some kind of qualitative changes to how the market works now?
ELVIS VELEA: Well, I think that we're going to see an S curve. We're continuously going to see prices going up, more sellers jumping into the market because they will think this is the right time for me to sell. Then that will dry out and then prices will go up again and then more sellers will join the market and that's what I think is going to happen. Of course, we could see the department of defence coming and sending a couple of /8s on the market and that will probably give us enough work for several years. I doubt that will happen though.
AUDIENCE SPEAKER: James Kennedy, Liberty Global. Thanks, Elvis, for the presentation. I think it's good that you do discuss and highlight the substantial and increasing costs of buying from the market because it's relevant, it's reality and people need to be aware.
It's still surprises me how some organisations still overlook the value of sorting out their own IP management before looking to third parties but that's another discussion.
So, you have gone through the costs of purchasing the space. How would you advise from your experience on the risks involved to buyers, particularly around ownership issues and how would you recommend companies mitigate those risks?
ELVIS VELEA: I think the most important thing buyers should be aware of is when you talk to someone that wants to sell IP addresses, be it a broker that wants to be the middle man in this trust anchors, or the actual buyer ‑‑ sorry, actual seller ‑‑ it's very important to ask that person to prove that they have the power of authority, the power of authority of talking on behalf of that company. Because we have seen quite a few attempts of all kinds of people trying to talk on behalf of various companies, even having a business e‑mail addresses from that company, but not actually having the authority of that company to sell the blocks. Those people may even be the contact, they may even initiate the transfer. So I know the RIPE NCC is doing a better and better job at verifying the documentation provided and making sure that the parties that are involved in the transfer are ‑‑ have the authority from the company to actually do that.
Also very important is, as I said, that once a block it transferred, do start routing it immediately because hijacks happen and that can cause a lot of trouble.
CHAIR: Elvis we're running out of time. So let's do a quick, if we can do two quick questions and very concise answers, if you can.
AUDIENCE SPEAKER: Hi. Hank. A very nice presentation. One quick question. Slide number 7 you showed the number of countries getting IPs. Do you have numbers on which countries are selling IPs?
ELVIS VELEA: Networks I don't have those numbers right now. But, we all know that most of the transfers have happened from Romania while most of the receiving parties have been in Iran, Syria, etc., etc..
CHAIR: Last question...
AUDIENCE SPEAKER: Geoff Huston: Part of the reason for reports like this is to make sure that the Address Policies that we have reflect transfer are actually protecting those folk from, you know, the threats of various fraudulent or market distorting activities. Do you see in your stats evidence of speculation, hoarding or are the deliberate forms of if your use of these transfers for purposes other than I want them I'm going to route them, so do you see evidence of what I would sort of loosely call abuse inside these statistics yet?
ELVIS VELEA: Not that much, no. Most of the abuse we see is people pretending to be someone they are not.
CHAIR: We are out of time, but, Elvis, please stay in the room and if we have time in the end we can either address those questions or you have the opportunity to talk to them during the break. Thank you. Thank you, Elvis.
(Applause)
ANDREAS REUTER: Hello everyone, my name is Andreas Reuter. I'm talking about measuring the adopting of RPKI route filtering. These are the people that helped me with it.
As I'm sure you are all aware, there have been a number of high profile prefix hijacking incidents over the years, the famous one being in YouTube. Pakistan Telecom there was also in 2010, in China Telecom and the most recently a number of prefixes belonging to large financial institutions were hijacked.
So, to solve this problem we have the RPKI, the resource public key infrastructure and the RPKI can be used by network operators to authorise specific AS to legitimately announce their IP prefixes and this is done using route origin authorisations. In short, ROA. This is a cryptographic object and once they are validated the information on them can be used by BGP routers to use route origin validation and to confirm whether it is legitimate or not. The result of that validation can be used in the local routing policy to, for instance, filter out all invalid routes. So to give a quick example. We have a ROA here for this one, with a maximum length of 24 and it's authorising AS 100 to originate this. And if the router has this information and sees these two updates, one for 10.20.0.0/16 with origin AS 100, route origin validation will say this is valid and our policy might say we can accept this. The bottom announcement for the same prefix for origin AS 666 will evaluate to invalid and our policy might say to reject it. Just for completeness' sake, I'd like to mention if a prefix doesn't have a ROA in its name the router geolocation validation will say not found, which is the case with most prefixes today.
Every time in this talk I mention the term 'non‑invalid'; what I mean is either valid or not found.
We like to monitor the adoption of RPKI filtering policies and the challenge here is that of course these are private policies and we need to infer them using measurements. And there are two basic approaches to measuring something like this. One is uncontrolled experiments which involves analysing existing BGP data and existing router geolocation authorisations and trying to infer if there is an AS filtering. So this method is fairly fast and easy to do because it only requires historical data. The other approach is controlled experiments which involves actively announcing your own IP prefixes and creating your own origin authorisations and try to infer whether somebody is filtering. This is a slightly slower because you need to do experiments and you need access to experimental facilities.
In our work we have used a controlled approach but existing research uses the uncontrolled approach, that's why we have also evaluated it and that's why, today, I'm going to talk about both these approaches and specifically mention some of the problems we see with the uncontrolled approach. Let me first start with that one.
So the basic idea behind this approach is that we leverage the divergence between two AS paths and we try to infer if there is an AS that is filtering. If you look at this example topology. On the right side you see AS1, prefix one, the announcement for prefix 1 is valid; the announcement for prefix 2 is invalid. On the left side our vantage point in this context means it's a peer of a public route collector and it sends its selected best path to the collector, which then dumps it and then we can analyse it. So, these collectors, in our case we always use route views and RIS collectors. In our example the vantage point is chosen for prefix 1 the route via AS2 and for prefix 2 the route via AS3. The question is now, is this divergence because AS2 is filtering. Reason is because AS has received the announcement for prefix 2 and choose to filter it out and not propagate it, that's why the vantage point has chosen the point via AS3. We argue that this question cannot be answered using uncontrolled experiments and we have identified a number of problems with this approach that I'd like to talk about now.
The first aspect is that of limited control and there is two sub‑aspects to it. The first one is, that if you look at a situation as the one I have just shown you, you have no idea what the original AS is doing. You have no why whether it's doing traffic engineering or the divergence you observe is for some other reason. So again we look at the same situation, the origin announcing the two prefixes one valid, one invalid. Our vantage point choices different routes. Again, we ask ourselves the AS1 filtering. It's certainly possible. The more feasible explanation is that the origin is simply performing traffic engineering and it's announcing prefix 1 to AS1 and prefix 2 to AS2. So, to give you a specific example how this could, something like this could work out.
Let's say the origin announces 10.20.0.0/22 to AS1 and 10.20.0.0/4 to AS2 and then the network operator would like to secure the prefix and create a ROA and the ROA is for prefix 10.20.0.0/22 and the operator commits a common error, misconfiguration error where they set the maximum length field wrong, which results in this ROA, and this ROA has the effect that now the announcement for the /22 is valid, the /24 is invalid and if you, as a researcher, you stumble upon the situation, you might be tempted to conclude that somebody is filtering here, where, in reality, it has to do with RPKI filtering. This is something you cannot distinguish using this approach.
And so we argue that path divergence at the first hop is more likely to be explained as a result of traffic engineering at the origin and not RPKI filtering. So, just a quick note what I mean by first hop. It means that the two routes diverge on the first position on the AS path. So first is the origin and then the AS after are different. Just so that's clear.
We're interested in how many of these situations where you have two diverging routes can be feasibly explained by traffic engineering, so can diverge at the first hop. We looked at this. And what you see here is, on the X axis the position on the AS path where the two paths we analysed diverge and on the Y axis the number of divergences you see it heavily peaks for one. Over 80% diverge at the first point means that a lot of situation which looks like RPKI filtering are probably traffic engineering, and we then excluded all AS paths from invalid routes just to check whether this would make a difference in the divergence pattern, because if there was RPKI filtering you'd expect to be a different pattern. This is the green block. This is without invalid paths. You can see there is no significant differential which indicates a lack of widespread filtering. We have done this for a lot of vantage points and they all show the general pattern.
The other aspect of limited control is that, using this approach, you can distinguish whether an AS is filtering based on RPKI attributes or if it's filtering based on some other attribute. So to give you an example from the real world, here our origin announces the two prefixes our vantage point choices two divergence routes and we ask ourselves this question. Now, the divergence doesn't appear at the first hop so it can't be traffic engineering. In this case, however, it is actually the vantage point using route age as tie breaker and it has received for both prefixes both routes, and it just so happens that for prefix 19 route via prefix 6 arrived one while for 2 this one arrived first. This looks like filtering but it really isn't.
The second problem is that of limited visibility which can lead to misclassification. If you analyse data from one particular set of vantage points and you make a series of observations that lead you to classify an AS as filtering, if you had looked at a different set of data from different vantage points you might come to totally opposite conclusions. So, again we look at our situation here. And we ask ourselves AS2 filtering. Maybe we have considered data from vantage point 2 which adopts the same route for both prefixes and clearly shows AS to be an invalid route, probably not filtering. However, you had not considered the data, then you would never be aware of this using the uncontrolled approach. And this problem never goes away as long as you use uncontrolled experiments because there is no complete view of the AS level Internet and you can't just infer without considering the missing data.
And the third problem I'd like to mention is that it's not possible to reproduce anything because you are not actually conducting experiments; you are analysing existing data. So you can't confirm your observations. You are also constrained by whatever routes happened to be announced.
And for these reasons we think that inferring whether a specific AS is using RPKI‑based filtering on the basis and only on the basis of uncontrolled experiments is prone to misclassification.
Now let's talk about the other approach, controlled experiments. I also mention that this involved using crafting your own ROAs and sending out your own BGP updates. And this approach resolves most of the problems that we have with the other approach. So, the aspect of limited control, the problem with the recognising whether someone is doing traffic engineering or someone is filtering is gone because we know what the origin is doing because we are the origin. We can also distinguish easily now whether an AS is filtering based on some other route attributes or based on RPKI status. Because now we can change our route origin authorisations and see how the AS reacts to that.
The aspect of limited visibility is much less of an issue. It's still a problem but it can't lead to misclassification any more because now we only care about the data that results from our announcements. If there is missing data, that's something we can consider and it might be information to take out of it, but it can't mess up our classification. It doesn't contradict. If we found an AS that's filtering, it doesn't matter if there is missing data.
And, of course, we can now repeat experiments and we can target specific AS with announcements. And we can confirm our observations.
So, now I'd like to talk about our actual technical setup. On the BGP side of things, we announce two prefixes. PA is our anchor prefix and PE is our experiment prefix, and these prefixes are very, very similar as in they have the same route object in the database. They have the same length, there is only one bit difference ideally. They are announced always at the same time. From the same origin, from the same router even, and they always are announced to the same peers. So they are treated by us identically on the BGP level.
On the RPKI side of things, we initially issue two ROAs for both prefixes. Well one for each prefix. And we issue them in a way that both announcements are initially valid. And then we wait until these announcements propagate throughout the Internet and vantage points have chosen the routes for these two prefixes. And then we change the ROA for the experiment prefix and observe if there is any vantage point that now has a different route. And you might ask yourself why do we have the other prefix? The anchor prefix serves as a reference. Once we change the ROA and observe a vantage point changing its route for the experiment prefix but it has the same route for tower anchor prefix which we haven't messed with, then we can be sure that this change in route was actually because of RPKI and not because of some other routing attribute.
So, now let me walk you through some observations we have made while doing these experiments and how we interpreted them.
So, in this situation, the origin is directly peering with the vantage point. And initially we're announcing both prefixes valid and the vantage point adopts the same route, the direct route for both of them. And now we flip the ROA for the experiment prefix making the announcement invalid. And we observe, one observation we have made is that the vantage point has now route now for the experiment prefix and this tells us that it must be using some kind of RPKI‑based filtering policy. We know that at least for routes that it learns from us that it is filtering invalid routes.
The other observation that we have made is that the vantage point still has a route via ASX, so, this tells us ‑‑ well, I'm sorry. The other observation we have made is that the vantage point has a different route now. In here over via ASX, and this tells us also that the vantage point is using some kind of route RPKI policy. However, it's probably more selective than just filter all routes because we clearly see it adopting a route. So this could be that it's filtering routes learned from the origin and not filtering routes learned from ASX because it might be a provider.
The other observation is that we have made is that it's a more common one, the situation is that the origin and the vantage point are not peering directly and there is at least one AS in between. Again, initially both announcements are valid and the vantage point choses the same route for both of them via ASX. Now we flip the ROA for the expert prefix making the announcements invalid and again the same observation is that the vantage point has now no route and this time though we can't just say the vantage point is using RPKI‑based filtering because it also might be ASX and it also might be both of them, so there is some ambiguity that we have to resolve.
The other situation that we have opened is very similar to the one I have already showed you. Here, the vantage point still has a route but it's different and it's over ASY in this example, so this tells us either the vantage point or the ASX are using some kind of RPKI filtering, but we we don't know which one; it could be both and we have to resolve this ambiguity and there is two ways to resolve this ambiguity. One way would be to just establish a direct peering connection with the vantage point because then we're back to the other slides where we could unambiguously tell whether it's filtering or not. If that's not possible, we can see if there is a vantage point in ASX because we are already directly peering with it. If we had a vantage point, we could determine whether they are filtering or not.
So, now to the results.
So, the good news is that we have found a number of AS that are using RPKI filtering on the Internet today. The bad news is that this number is 3 and none of them were particularly large. So two of the ASs we found filtered all invalid routes regardless of where they learned them from and one AS that we found filtered routes learned directly from our origin but did not filter if it learned it from its providers.
So other work found our results.
And we have verified this by repeating these experiments and just to be sure that that you are methodology is sound we verified it also by talking to the operators and making sure they are filtering and they confirmed it.
So to conclude. There are ASs that are doing RPKI‑based filtering on the Internet. It's not many and it's none of the big ones probably, actually definitely. But at least some. We have found three. That doesn't mean there is only three out there; it just means with our methodology and our infrastructure that we are using experiments we can only measure these three. We are working on expanding what we can see hopefully, there are going to be more vantage points for us and we can establish more direct peering connections and we can measure forecasts. Furthermore, we feel that uncontrolled experiments and using only uncontrolled experiments is unsuited to inform whether a specific AS is using RPKI‑based filtering, and we feel that controlled experiments are crucial to measuring the adoption of RPKI‑based filtering policies.
And our next step in this work is that we will extend and refine our methodology. For example, I have shown you the example with the route age where the vantage point uses route edge as a tie‑breaker, so to distinguish from something like this we might want to consider not having static announcement we're doing right now, but announcing, proving the experiments, withdrawing everything, a clean /8 and try and do it again. These are some steps we want to take with your methodology. More importantly we will establish a live monitoring platform that the open to the public that will show you the latest results from our experiments and give you the means to assess how we are doing in terms of deployment.
And for the last two bullet points, I'd like to call upon you to please establish direct peering with the peering test bed which is a project that allows people who don't have access to BGP infrastructure to conduct experiments. It's a really great project. We are using this for these experiments and the more you peer with them, the more we can measure. And secondly, also please consider peering with public route collectors from the route use and RIS projects because again we are constrained by what we can see. If we can't see it, we can't measure it. And consider that this not only has benefits for researchers but benefits for everyone because everyone benefits from a more secure Internet backbone.
So that was my talk. I think I have got plenty of time left for questions now. So...
AUDIENCE SPEAKER: Erik Bais. Thanks for the talk. I have a couple of questions. One of them is can you specify the ASs that you found that were feel filtering on RPKI?
ANDREAS REUTER: AS 50300, 59715 and 8283, that's the one we found.
ERIK BAIS: The last one is the one from Netherlands. One of the things that I found out with peering with [] cola clue was that they were filtering at that point on exact not matching ROAs with more specifics. What's your opinion on that, because there is actually an opening for attack on having more specific within your ROA with a match up to a prefix length.
ANDREAS REUTER: So you are asking me in the context of how to measure this or...
AUDIENCE SPEAKER: No, no, what's your opinion on the filtering that [] cola clue is doing currently as testing is filtering based on only matching exact ROAs, valid exact and not ‑‑
ANDREAS REUTER: Okay. So if understand it correctly, so a ROA ‑‑ an announcement can be invalid because either the AS doesn't match or the length doesn't match and you are saying that cola clue is filtering on only exact matches while someone else might be filtering if the origin AS is matching but maybe the length doesn't match.
ERIK BAIS: Exactly.
ANDREAS REUTER: So, I mean... I can't tell you off the top of my head what the benefits would be of filtering for one reason and not the other one. So, I think this is something that we could target with with our methodology to kind of get more details about these policies, but sorry, I can't give you a satisfying answer about whether what the benefits of of filtering every invalid route or filtering only the ones that have the wrong length ‑‑ the wrong AS, sorry. But I'd like to talk to you about this off‑line, because...
AUDIENCE SPEAKER: Benno. It's probably not part of your research, but I would be very interested in, or maybe you can use your system in such a way that the adoption rate, the deployment, the number of networks deploying RPKI increases, is that your test bed also identifies what works and doesn't work. So what are the area deployed? Can you build some confidence in the RPKI mechanism by monitoring the network and indicating what goes wrong and what goes right to that operators get a feeling that this will work for us also and start deploying, so you go from 3, 4, 5 and hopefully to many, many networks that deploy RPKI. Do you see this can be part of your test bed or your way forward of your research?
ANDREAS REUTER: I think this could definitely be part of our platform that we'd like to build, a monitoring system, to give operators an idea of the ASs that we have found to be filtering, how the filtering affected for example prefix hijack attacks. Like, if there was substantial benefit to it and if we showed this, yeah, this could help with adoption and encourage people.
AUDIENCE SPEAKER: But maybe also I think maybe this is old information, operators might be, well not scared, but caused using RPKI because they think it will break more than it will help them out and I think also it's important in getting the message across to us, the people here in the room. Is that it does work as intended and that's my point I actually wanted to make.
ANDREAS REUTER: I think about the problem that operators might be hesitant to enable this because it might result in angry phone calls. That's understandable. And I think it it would be very important that, right now, a lot of invalid routes are being announced on the Internet, aren't supposed to be invalid, it's a simple misconfiguration error and it would be important that the systems are doing something to fix this. Once we see an invalid route we can say this is something that shouldn't be happened and if you had filtered it you would have been safe from this, so...
AUDIENCE SPEAKER: Geoff Huston. I was always on the understanding that ROAs were applied as filters to updates. So if I have something in a FIB and the ROA changes, it's still in my FIB. So you are saying a ROA change will sweep the FIB? Are we sure about this and have you tried an experiment where you simply withdraw and renounce and actually see whether the announcement itself changes path simply because of timing as distinct from a change in the ROA status?
ANDREAS REUTER: We have not done that specific experiment. Although we have announced ‑‑
GEOFF HUSTON: Would that not be a useful control at this point to understand that the change in, if you will, announced withdrawal patterns and filterings of updates, also affects paths. It's not just the ROA in your methodology that may have changed.
ANDREAS REUTER: But the effect that it's only the ROA that's causing the route change it be pinned down because we have a reference prefix, so while there might be benefit in withdrawing the announcements and, you know, using a clean /8, which we are planning to do in the future, I think that there is no danger that a route change could be misattributed because we do have a reference prefix for that.
AUDIENCE SPEAKER: Jen Linkova. Just curious. You mentioned that if you don't have direct peer vantage point you don't do know if it's intermediate AS or vantage point. So have you tried to look at not just in contra plane but forward in plane used, for example, Atlas probe to control prefixes and the prefix in question and see at which point your trace route change.
ANDREAS REUTER: We have not done any data plane measurements, no. But this might be something to think about. Thank you.
AUDIENCE SPEAKER: Randy Bush, IIJ. I have to declare that I work with Andreas. To answer Benno about operators worrying about what they will drop. I refer you back to Daniel [Elmartino's] presentation at RIPE in London where he actually compared the actual ROA databases over time versus the risk data over the same period and showed what would be actually dropped if you enforced. And it was negligible. That data, there is a website that's continuing doing that, by the way; rpki.me, I think it is, Daniel has up there and go see it.
CHAIR: Okay. So did you have a comment or...
AUDIENCE SPEAKER: A quick one.
CHAIR: I meant Matthias.
AUDIENCE SPEAKER: It's a question of Geoff. We did experiments in verifying RPKI route implementations and I mean Juniper completely is fine and we were ‑‑ Cisco as well, there was only a minor glitch, so this point that you raised did not affect the measurements here. And also regarding Benno's questions, I mean, we definitely ‑‑ I mean, the reason why we want to publish or make analysis public and also the monitoring system is to help the operators to assess the security of autonomous systems.
CHAIR: One ‑‑
AUDIENCE SPEAKER: A quick one. Marco. In your slide you showed, you encrypted the ROA once a day, if I got it right. Why once it day? Does it come from any operational experience?
ANDREAS REUTER: This has to do with the propagation time of RPKI objects. Once we issue the ROA it becomes part of the global RPKI. It resides in some public repository and local caches will periodically download it. We don't know what propagation that people are using, we don't know what's pre‑defined in the software, but somebody could be using something slow. The same goes for how many times the BGP routers query the local cache and if someone set their to query every four hours, we want to make sure that the RPKI change actually arrives at the router before we already flip it back.
AUDIENCE SPEAKER: But are we concerned in general that anything faster would not propagate besides your experiments?
ANDREAS REUTER: We have seen in the data some ASs that have a propagation time what seems to be three to four hours. We thought just to be sure I'll make a whole day out of it.
CHAIR: Thank you.
(Applause)
So this concludes our session, we're coming back in about 30 minutes. A reminder to send your nominations for the Programme Committee before 3:30 today and a reminder again to please evaluate the talks. That helps us improve them. Thank you.
Coffee break:
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
