Plenary session
24 May 2016
2 p.m..
CHAIR: Now that somebody has explained to me how the microphone works, we can get started. Welcome back, I hope you all had a nice lunch, and we are ready to start the next Plenary session. And we are going to start off with an update for about the IANA stewardship transition from the CRISP team. I think everybody here should know more or less what it's about so I don't think this needs much introduction.
NURANI NIMPUNO: Hello everyone, good afternoon, my name is Nurani Nimpuno and I work with NetNod but I'm here as the vice‑chair of the CRISP team. And Athina and me will be giving what we hope is a very last update in this transition process.
So, where are we now? As you all know two years ago the US Government made an announcement and said that we will transition the stewardship of the IANA functions, so the allocations of IP addresses, domain names and protocol parameters to the multi‑stakeholder community and this kicked off this whole process and that also started the creation of the CRISP team who was attacked to put together the proposal for the numbers community.
So we are here. When we last gave an update at the last RIPE meeting, there was still a few things that were not complete for the numbers community. But we also were waiting for one of these work streams, the work stream 1, which was looking at the ICANN accountability and we did not, at that time, know if they were going to come in on time. We were hoping but we were not absolutely positive. And Athina is going to talk a little bit more about that later, but we are happy to say that we actually have submitted this transition proposal, and we have, from our side, from the community side, done everything we set out to do.
So, the IANA stewardship package has been transmitted, and I'd actually like a little applause for that.
(Applause)
So why is that important? It's important because it means that the IANA functions, the stewardship of them have been, has been transitioned, but it really was the culmination of this huge process which involved so many people and so many communities, not just this community, and it was actually a proof that this way of developing work in policy works, so in that sense it was a historic process.
So we had quite a few challenges along the way. We have talked about some of them before. The timeline was an incredibly aggressive timeline. We were also, even though we submitted on time, we were waiting for other communities. The other tricky part was that the Government, the US Government said they wanted one unified proposal. So, us completing our proposal was all well and good, but we needed to make sure that our proposal also actually fitted with the other ones.
And there were a lot of other little parts, a lot of moving parts in this process. A lot of speculation about what various actors would do and we said from our perspective, all we could do was to be committed to the success of the transition, to support the proposal and respect the principles that we set out, and to continue to be transparent and consultative with the community.
So, last time, about half a year ago when we gave the last presentation on this, there was still two parts of sort of the proposal work that needed to be completed. One was the intellectual property rights where the number community had said that we wanted that to be held by the IETF trust. We were still talking to the names community about that and didn't have agreement on that and I can say that we reached an agreement and they were happy in the end to accept our proposal. So we are very happy about that.
And the other part was the finalisation of the SLA.
So, basically the CRISP work has now been completed and we have handed over to the RIRs.
So where are we now? We have submitted the package, the culmination of all the proposals, and now we are in Phase 2. So we have done Phase 1. And now this is being reviewed by the NTIA and by the US Government. And from our end we feel that we have done everything we can. At this point we are not really tasked to do anything apart from answering questions and clarifying anything that needs clarifying, and once that Phase 2 is completed, we will enter into the implementation phase.
So, I'm going to hand over to Athina and she can talk a little bit more about the ICANN accountability process.
ATHINA FRAGKOULI: I am head of legal from the RIPE NCC. Before I talk about accountability, I'm going to talk about the implementation of the CRISP proposal from our side with the SLA, the Service Level Agreement for the IANA numbering services. So, just to tell you a little bit of a background on the SLA. The drafting of the SLA. So, the SLA was a requirement, as Nurani said, from the CRISP proposal of the IANA transition. Which is based on the current NTIA contract and the current operational practices. It is in accordance with CRISP principles in the proposal, and it is being drafted by the RIRs. That is the legal team and supported also from the RIR CEOs. It is very important to mention there has been many many discussions around the SLA and these discussions were conducted in a fully transparent manner. Anyone can comment on the various drafts. There were two public consultations, consultation periods, and people could submit their comments in the mailing list. There have been discussions with ICANN that includes the IANA operators, the lawyers, the directors, all comments have been submitted to the mailing lists for transparency purposes. Every comment has been addressed, and every modification in every version of the SLA has been justified, and all this documentation can be found in the link I mention here in the bottom.
There have been many versions of the SLA. So, just to clarify which version is coming from. We had the CRISP proposal and that gave us a version number 1. We had two public consultations and based on the feedback we received, we came up with versions numbers 2 and 3. The IANA operator reviewed the SLA and that gave us version 4. We had comments by ICANN and we discussed with ICANN, especially in Marrakech, after Marrakech we have version 5. Also NTIA had a comment on our SLA and that was a comment on a particular, on the wording of a particular provision so that we make sure that there is a smooth transition from the NTIA contract to our SLA and that was also taken into account, and we have version number 5.1. This is where we are now. We are still waiting for some final comments by ICANN, and hopefully this will give us the final SLA, that hopefully will be signed in Helsinki or by Helsinki, I don't know, we don't have a concrete date. That's the SLA, but since I'm here I'm also going to give you the update on the ICANN accountability CRISP Working Group.
The outcome of this Working Group was important for the IANA transition because, as Nurani said, it was a part of the transition plan for the names community. The names community had certain requirements, certain accountability requirements, and these were addressed in the report from this Working Group.
We were not ‑‑ well the proposal, now it's completed, but there has been a lot of drama until we get there. This is a work of two years, intensive work of two years, conflicting interests, a lot of pressure and so on. Before the meeting in Marrakech, I wasn't positive that we would achieve a proposal, but we made it. And so, in Marrakech, the proposal was approved by the chart erring organisations, ASO, which is the organisation for numbers approved its second after the RSSOC. We also issued a minority saying that okay, accountability of ICANN is very important, but we have also our accountability which is outlined in our agreement and SLA is one of them, so we want our SLA to be signed before this whole ICANN ‑‑ before this whole proposal is implemented.
The proposal was submitted to the ICANN board, together with the ICG proposal for the IANA transition, was approved by the board, was submitted to the NTA, all this in Marrakech in a very festive atmosphere, it was magic, yes.
Next steps: The implementation of the proposal. We're now working on the implementation. Because the proposal is very nice. Now it has to be implemented. We have some new ICANN bylaws drafted, these have been discussed. As ASO representatives, we send our support to these bylaws and the bylaws are meant to be approved this week by the ICANN board. And, of course, after the transition, there is still some accountability work to be conducted by the same group. And this includes the review of accountability of an ASO, the organisation for numbers is also in the scope of this work, so we will follow this progress and these discussions and please watch this space.
Now, this slide, I took it from the slide package I presented to you at the last RIPE meeting, and here I outlined our goals, as ASO representatives, you know, and our participation in this group, what we want to achieve. Back then I told you that we want to stay true to our principles, to our community, especially the CRISP proposal principles. We want to stick to our time lines so there are no delays for the IANA transition. We don't want any proposal to interfere with our contractual arrangements with ICANN. That was very important for us, and of course, we want to have a proposal that would give sufficient community empowerment. Now, going back, looking back, have we achieved these goals? I'm very happy to say yes, we have achieved all of these goals. We did stay true to our principles. The IANA transition, has not been delayed. Our contractual arrangements are all intact, they are not at all interfered, there is no inferences from this proposal. And the community is indeed empowered by this proposal. And I must say that this was very much thanks to the great structure that already existed for years in the numbers community. So, as a final remark, I have to say this: As a numbers community, we shined in this process. We had a clear ‑‑ actually we were the only community that could show this dialogue between the representatives and the community, every time like we were giving feedback, we were asking for feedback, we were reporting, and no other community could show this in such a diligent way.
We always had a clear position that was in line with our principles, because the numbers community had given some clear principles to us, and we could move within this frame. And within this frame we could also be flexible and we could negotiate, but without jeopardising our principles.
We had consistent message and that is not a given, because in other communities, you wouldn't see that. There were representatives from the same community that had conflicting opinions on that, on the matter. This never happened with us. We always had like one front and we were coming very strong with our message. And, I must say that if one community really stood out from this process, that was the numbers community, and we could hear it all the time, all the numbers, numbers. I don't know if it sounds a bit cheesy, but I was very proud to be part of this community. That was very nice.
And with that, I give the microphone to Nurani.
NURANI NIMPUNO: I'm just going to say a few very final words since this will be the last presentation. I just thought, following up actually what Athina said. What we want to say to this community is, first of all, we got what we wanted. We got everything we wanted and we didn't do it through friction and conflict, we did it through consultation and through cooperation. And that, I think, is one of my take‑aways.
It also feels to work with the other communities. We are very comfortable within our own community but it actually forced us to work collaboratively with the names community, with the IETF community and that was really good, it was a tough, difficult at times, experience, but it was a very, very good experience and I think it also made it clearer in, outside of this room what the numbers community is. And it also, one of the take‑aways from this process was also that the principles of transparency and bottom up and inclusiveness, these principles that we take for granted in this community, they were really proven to work, and like Athina said, not only was the work that a lot of you and we did praised, but the numbers community was referenced over and over again and held up as an example for how you do things in a collaborative, inclusive, bottom‑up way. So, we have received a lot of praise from people in this room and others for the work we have done, but I actually wanted to say thank you to this community and to ‑‑ especially to, you know who you are, some of you, who were part of shaping this community and who laid the ground work for this, because it's actually thanks to you that we managed to do this. So, this is to you.
(Applause)
And now you can grill us.
BRIAN NISBET: Again, thank you very much for all of your work. And take questions, comments or otherwise.
AUDIENCE SPEAKER: Salam Yamout from the RIPE NCC Board. First, again, congratulations for a work very well done and for the trust this community has put in you and in itself. My question has to do with a long term vision, since today is the last presentation we hear about the IANA transition. Do you think in Phase 3 when this will come into implementation, that that system, numbers, names, parameters, communities, can hold up to ‑‑ what are the problems you anticipate and will this maze of organisations coming together be able to hold up against, say, government attacks, now that the United States Government is not in its back any more?
NURANI NIMPUNO: You always come with a tricky question, Salam. Well, I actually think ‑‑ even those of us who said we believed in the multistakeholder model, we are sick of hearing the word, right, but I think this this process was one of the most challenging processes these communities have had, and we had to do it as one community, and it actually, we rose to the challenge. So I think that the process itself has shown that this, sort of, this collaborative way of doing things where not one stakeholder has more power than another stakeholder is actually the best protection against any undue influence by a single stakeholder. So, I think so. I mean, nothing is guaranteed. It means that we need to keep respecting these principles, right, and we need to continue to work together. That was one part of your question. I think the next was about what happens next, right?
And just in terms of the transition now, it is with the US Government, and that is a process where we are not involved apart from answering questions, so we'll see what happens there. And then, hopefully at the next RIPE meeting, it will be the RIRs standing here presenting that the transition is completed.
But I think the work that Athina mentioned in this work stream 2 of accountability, that is ongoing work, but making sure that ICANN is accountable but also that all of us who participated in this sort of structure, that we're accountable, and accountability is never something you achieve, it's something you can strive for.
AUDIENCE SPEAKER: This is Izumi Okutani but perhaps, I don't know, Milton has stood up and if you are answering to the the earlier question it might be better if you go first.
AUDIENCE SPEAKER: This is Milton Mueller from ARIN and the United States. So, the question was about the role of governments and whether ICANN would be able to resist pressures from governments once the United States is no longer backing them and this is actually kind of a hot button issue in the United States because some of the right wing opponents of the transition are trying to frame the transition as if it is this kind of a threat, and I would just point out that this was in the accountability process, as Athina probably knows, the role of the governmental advisory committee was a very contentious issue and we can certainly say that the governments who wanted to empower governments within ICANN, who wanted to use this process to make governments stronger within ICANN, came away extremely disappointed, and we did make some minor changes in the role of the GAC, some of us thought that they were a little bit too much, but the GAC is essentially now just another stakeholder group within ICANN. In some ways a little more powerful, in most ways weaker because they have been required to act by full consensus, which means that if any Government stands up and objects, then the GAC cannot issue formal advice.
And the alleged threat that governments are somehow going to come from outside of the GAC or somehow take over ICANN, I think is completely insulated against that now because any major change in the bylaws has to be approved by the community, it used to be that the ICANN board could simply with a two thirds majority just completely change any by‑law they wished, and that is over. That is not going to happen any more to make a major change in fundamental bylaws they have to get really major support across different supporting organisations and advisory groups. So I think to answer the question that was put a little more thoroughly, it would not be a bad idea given how important this issue is in certain quarters. Thanks.
AUDIENCE SPEAKER: Izumi Okutani, as a Chair of the CRISP team. So I think we're now at the phase we actually did as we can as a community and now we are moving to the process where it's up to the NTIA and approved by the US Government. So I think we already did what we can as a community. And I sort of want to share my reflection of the experience.
I was very amazed and impressed how we, as the RIR, regional RIRs, we have the five communities, we actually don't have a global meeting, we usually have the regional meetings, but when it comes to a point where we really have to work jointly as the numbers community, we actually really share all the core spirit and the essence of the numbers community, and it actually led to Athina's observation that we were very well coordinated. I think this is our strength and I really want to share with everyone who is here that this is actually an important strength that we have.
And, also, I want to take this opportunity to thank the colleagues from the RIPE region who have worked with me, because I don't think they are really going to like say too much themselves on what great work they have done. So Athina, working together on enhancing accountability, and the CRISP team, colleagues from the RIPE region, Andrei, Paul Rendek and, of course, Nurani, I really wouldn't have ‑‑ I feel we couldn't have achieved what we wanted without working together as the leaders of the CRISP team, so I really would like everyone to acknowledge, it's just not on what we shared on the mailing list but there was so much work behind it, so, great contributions, and I think you should be proud of the representatives that you have.
And lastly, I want to join Nurani in thanking the RIPE community. You have been regularly, constantly contributing on the key steps after transition where we really needed the community input and support to the process. This was so encouraging. So, I think this transition, the process itself, is almost completed and the community engagement phase, but there may be other opportunities where we might have to come together either as a RIPE community or jointly as the RIR communities, and I really hope we can learn from this experience and keep this strength. Thank you. Thank you to everyone, to the CRISP team, members, Athina, and to the RIPE community.
(Applause)
ATHINA FRAGKOULI: I think this community also owes a big, big thank‑you to Izumi, as the Chair of the CRISP team and as the liaison of the ASO.
CHAIR: One last comment.
AUDIENCE SPEAKER: Hi. Rob Evans. I'll join everyone else in saying well done for what was supposed to be a quick job over the Christmas before last, turned into 18 months. But I wonder whether you guys have got any feeling about what the US Government spending freeze on NTIA transition is likely to mean, or is that a completely unknown quantity?
ATHINA FRAGKOULI: I think I have the right person to respond to that is reaching the microphone. This is for you John, yes.
JOHN CURRAN: I'm actually going to be not going to answer the question directly. I'm going to point out that, today, there is actually a hearing going on in Washington DC at 10 a.m. eastern, four o'clock local time, the Oversight Committee in the Senate that handles the commerce department is having a discussion about this whole process, and how they feel about the IANA transition. Some of the folks are actually here. Andrew Sullivan was here earlier in the week has jumped on a plane to be back there in the hearing from the IETF. There is speakers from the ICANN community, and, at the end of the day, I think I'll refer for an answer to Larry Strickling's comments who was the ‑‑ he's the director of NTIA and he said that he was aware ‑‑ this is we have had several hearings ‑‑ he told the congress he was aware of their need to be consulted in this matter and would commit to ongoing reports, and in fact NTIA has filed quarterly reports about the status, the work that's been done, the efforts that have been made so congress is very well aware. Whether or not at the end of the day they take action to give a thumbs up and say this is great or take action to say they are not impressed, we don't know. But they have been well apprised and NTIA has said it will keep them involved. I expect once the bylaws that ICANN has have been ratified, once the agreements have been signed to implement the various steps like the SLA, that will all go to congress and they'll have a chance to comment at that time.
Regardless of what motions or bills are made in the interim, ultimately it's when they get the whole package and they come back with an answer that's going to matter. Thank you.
BRIAN NISBET: Thank you. In which case I think there's one last thing to do here. I'll hand over to Hans Petter.
HANS PETTER HOLEN: This is not really a question, but if I could have the CRISP team up on the stage. So as a small token of appreciation from the community, I would really like to give you something tangible to bring home so that you can show your grandchildren in 100 years' time that you actually achieved something in this process. So, if I could get all of you over here.
So we have here a certificate presented to the members of the CRISP team in appreciation for your work on behalf of the RIPE community as member and vice‑chair to Nurani, for the consolidated RIR IANA stewardship proposal team.
(Applause)
Andrei, the same for you.
And last, Paul, also for your work on behalf of the RIR community as a member of the consolidated RIR stewardship proposal team.
A plaque to have on your wall, while that is probably the most valuable token we can give you, we have also brought a bottle so you can enjoy with your friends to remember this.
And then, there is one person that has done a tremendous job for the CRISP team, namely the Chair, it's Izumi, can you please come up as well. So it's assumey, would I like to present to you for your work as Chair of the CRISP team and your contribution to the IANA stewardship transition process.
(Applause)
BRIAN NISBET: So, onwards. Not all speakers should expect a plaque and champagne after their presentation. The programme team apologise, they don't give us the budget.
So, after that, we have another happy story ‑ in fact, hopefully an even happier story. So, if Randy is somewhere ‑‑ this is Randy Bush on a happy story of Inter‑RIR transfer of legacy blocks from ARIN to RIPE.
RANDY BUSH: Randy Bush, IIJ. A multistakeholder, bottom up, blah, blah... no, none of that.
So, legacy at ARIN is a tough story. I have to sign something called ‑‑ if you want to have RPKI and things like that, you have to sign a legacy resources service agreement which says among other things that ARIN can change the contract arbitrarily, and you relinquish rights to legacy space, so if you have a lawyer, you are not going to sign it. The policy community is vigilante, anti‑legacy‑space, has been for many years, is slowly coming around but it is slow. But the host people and the actual people who operate ARIN are wonderful. And so this is a story of that.
A few years back we all rationalised legacy and PI policy, so you can be a legacy member and did not lose whatever rights you might have in legacy space, and you can be sponsored by a friendly LIR and lose no rights. In either case you pay, you get services, as if it was a business. How strange.
So, I happen to have, with my third hand, I have a small company, RGnet, had four legacy blocks in the ARIN region for decades, I originally got most of them from SRI before the Internic even transitioned. I had been working on RPKI forever. And I happen to have a bit of infrastructure in the RIPE region. And one of my day jobs at IIJ is a RIPE member. So, it made sense to try to transfer from ARIN to RIPE, because then I could have RPKI etc., etc.. Of course, as an old hippy, the thought of dealing with the bureaucratic mess was a little scary. And the process is seen documented, and, since I was raised by five women, I know how to follow orders. So, I thought I'd give it a go.
So, the first thing they told me was, go to the ARIN website and there's a button for this. And there is. Which is transfer resources. So I gave it a go, and what did it do? It gave me an online form, and I won't take you through the details. But I discovered a hole. I could transfer my address space but I couldn't transfer my ASNs. We forgot that when we did inter registry transfer, we should probably clean this up. It will take a little while of course.
Then, the ARIN bureaucracy yielded a form, I had to fill out a form, sign it, I had to do something called notarise, which is an American thing, and I think you have something similar here, which is to attest to the fact that I signed it. Well, we don't have such a thing in Japan. I happened to be going to NANOG a week or two later so the ARIN folk said fine, give it to us at NANOG by hand, we'll look you in the eye. So I paid them $500, this is now February 10th, things will take a much longer time than they need to because I'm a klutz, but, I give the form to the ARIN host folk at NANOG in San Diego. Now they were in San Diego and ARIN is on the other side of the states so the corporate jet was occupied so it took a week for them to get back there, but they did. Then the host person from RIPE says bingo, we have been told by ARIN that they're ready to transfer. This is three days later. I'm telling you, this is a happy story. It is a happy story and it doesn't even have multistakeholders in it.
So, the poor RIPE host person says, "I have to confirm that I want to receive this transfer even..." the host person didn't misspell it, I did. I have to tell them what infrastructure I have in the RIPE region that, you know, I should have something here. And am I going to be a member or am I going to use a sponsoring LIR?
Now we go through the bureacracy on this side. So I had to send them a proof of the existence RGnet. We had to fill out a legacy agreement between myself and the sponsoring LIR, a utilisation plan, and I happened to be teaching a security workshop in Aukland so I didn't get this stuff done for another ten days. Then the sponsoring LIR went on a ski holiday. It was Sander. It's okay. So now we're up to March 11th. Sander returns from skiing. We sign the agreement. We send it to the RIPE host person who says we forgot to list the resources ‑‑ idiot ‑‑ I like the host person to do it for me. I said, "Thank you, I'm administratively impaired, thank you for covering for me." And RIPE starts to process it. But it's a weekend. Monday, RIPE says, I need to create an organisation object in the database and let them know the org ID, and for each block I have to specify the net name, etc., etc., etc., you have all been through this, or many have. I hadn't used the RIPE database for so long it's ridiculous. I had a maintainer ID and I actually remembered it. And I had old objects in the database. Actually, they were the same kind of objects that were covering the same address space etc. So I played adventure, and found all the stuff and I cleaned out most of the old objects and I created an organisation object. Those people who have been following the mailing list will appreciate this. It actually works. And then a person object. And there is this problem of what is the identifier of a person I ranted about that, in 2000, half that rent can be correct, I can be different people in different database...
So, there were a bunch of RIPE database cruft. You either don't want to know it or you know it. Right... so I'm not going to lead you through it.
On March 16th, the RIPE Hostmaster says we scheduled with ARIN to do the transfer and update our registries this afternoon at 1700, which, as an operator, is strange to me; we don't do much after about 1300, so if something goes wrong we can clean it up. But they wanted to do it at 1700, and it was fine, at least it wasn't a Friday at 1700. But the reverse DNS is a problem. Remember, that ARIN points to my servers, but now ARIN is not going to have the data any more. RIPE actually has to tell ARIN to point to my servers. So, we're going to now move things around in a funny way and the end result and data are just the same. But, administrative procedures have to be fun.
So, ARIN had to delete the reverse delegations, RIPE had to delegate for which I had to create domain objects to tell them to delegate. I couldn't create the domain objects until RIPE received the transfer. And then RIPE system had to get ARIN to delegate.
I got up in the middle of the night and created the domain objects. Who here is old enough to remember the 18‑minute gap? Not many. It was something that happened in Nixon, when he wanted to hide what was happening. Everything he did was recorded except for an 18‑minute gap. Okay. This is a complex process, and a very careful process. Okay. This is delicate. In my case, this is a transfer of a live network and live DNS. This isn't some broker selling space across the Atlantic.
So, there was a gap of a few hours where the reverse DNS did not work. If this was some big network with a whole lot of servers or services and users, etc., this becomes a little delicate. But, so, I go back to sleep, wake up in the morning and everything is fine. This was the first Inter‑RIR transfer of live DNS space. You don't want to know how it's done. It is a can of worms. There's an Inter‑RIR zone let support system with magic files placed where the other picks it up. It's a dance, an administrative dance where the data ends up in the same place anyway.
Of course, Heas noticed the DNS gap and sent me a surly e‑mail.
Six weeks, it could have been two or three. There was no real pain. They even made the administrative stuff about as painless as you can make that. Amazing help from the host folk. ARIN helped me through it. There was a RIPE host person that not only helped me through the bureacracy but gave me ‑‑ you know, helped me fill out every line on the stupid forms. And the communities who made this all possible. The RIPE host person, when I asked them will you get in trouble if I say how helpful you were and went out of your way, they said no. "If you can take an extra step to help someone, then take it," is the orders they are given. I can't say enough.
Now, remember, my goal was to make the RPKI work. I wanted to put up a certificate authority under RIPE certificate authority, not hosted, but the up/down protocol.
So, I used Dragon research CA and relying party software. I had some problems with their software. There is a funny term, I have one foot in Dragon Labs. My sequel was, what it used to use, the new stuff used Postgres, this cares about UIDs, so the software had to go in and out of root and I had to operate in a directory that it could happen. So, the code was hacked to fix all this.
The old Debbion and Ubuntu stuff runs Python that doesn't do SSL 1.2. You want that for the RRDP protocol, which you have heard about, which is replacing Rsync. So, to be able to do that, I had to move to something that supported 1.2, which is, since I'm a Ubuntu user, zone yell. Here is the test to see if you have 1.2. And Debian Wheezy runs old, Ubuntu Trusty runs old, so I had to go to Xenial. Xenial at that point was pre‑released. Watch out for open SSH 7, it doesn't like short RSA keys etc. But Xenial is pretty good. I also happen to like Let's Encrypt for my certificates, so I have automation systems for that. And I also like DANE. So, I do the, it A style of DANE, 2.11 for those who know the obscure DNS incantations. And the result was a working CA under RIPE with my resources. The parent is RIPE. You can see it clearly in their name ‑‑ well, thanks, Geoff ‑‑ and so on and so forth. Here is a ROA, just for giggles.
I documented it, I have wiki'ed the entire process, so you can copy it and you can steal these slides, of course.
Again, big thanks to ARIN and RIPE host people who were just stunning. Tim and owe leg and Alex who made all the RPKI stuff work. That's up/down protocol to RIPE production. It's real. Rob [Osign] at Dragon for ‑‑ I create bugs, I'm really good at breaking things, really, really good, trust me. And the RIPE and ARIN communities for making the transfer possible.
CHAIR: Randy will take your questions now. This was actually, it was a happy story.
RANDY BUSH: It is a happy story. It is. And there are lots of moving pieces, and he they all worked and they were all thought out and the host people and DNS transfer, all that actually worked. Scott?
AUDIENCE SPEAKER: Hi Randy, Sandra Brown, IPv4 marker group. Thank you for the discussion on Inter‑RIR transfers, one of my favourite topics of course. I think ‑‑ I have a comment first of all. I think to your point that it didn't handle the ASN transfer, I know when we wrote the RIPE policy, we built it into the policy to be able to, so it sounds like an operational issue, where there may not be a handoff, so we can maybe follow up on that point.
I had a bit of a question, because you talked a lot about different aspects of when the IPs got to the RIPE side of things, you talked about them being possibly legacy, you mentioned possibly PA as an option, you talked about Sander being your sponsoring LIR, and I understand you can also have no relationship to RIPE when you do a transfer. So, are those the four options you were given when you brought the IPs into RIPE? And what is ‑‑ this concept of Sander being your sponsoring LIR, what is that exactly? Why did you choose to use that?
RANDY BUSH: I'm a cheap son of a bitch. I cannot remember the options well even though I was one of the architects of the policy. I think Athina, who is here, can tell us ‑‑ you don't have to, Athina, don't worry about it ‑‑ I think there are really only three. I can come in naked, just like I was in ARIN, under no policy, no formal relationship. I can become a member, okay. And the difference between becoming a member in the RIPE region and in the ARIN region is twofold: One is that I do not give up the rights to the legacy space. I don't know if RIPE can change the policy ‑‑ the contract arbitrarily, but if they do, or for any reason I feel like it, I can pull out and go back to the naked state losing no rights. Third is, I can come under a sponsoring LIR, and again, withdraw if I want to. Depending upon how much address space you have, how many blocks, not how many hosts equivalents, you may find going under a sponsoring LIR to be cheaper, and I'm already an ARIN member in my day job, so, you know, save a few euros. As to the missing ASN transfer, I don't know where, I couldn't fill it out on the ARIN form, and I hope Scott Leibrand has a comment.
AUDIENCE SPEAKER: I do have a comment. Scott Leibrand, I have not yet won the travel lottery that let's me on that corporate jet, so I don't know where that was. I just checked the ARIN policy and you are correct that it does not allow for a .4 Inter‑RIR ASN transfers. It does allow for within ARIN ASN transfers. This is the first I have heard of someone having an actual operational need to transfer an ASN. So, if that is a legitimate need, then we could certainly write a policy to fix that and I think it would get pretty good support. Up to now it's a nobody wanted it.
RANDY BUSH: As I said, I am really good at finding bugs.
AUDIENCE SPEAKER: There's no policy basis in the ARIN region at this stage for ASN transfers, there's, although, a policy base for AS transfers in the RIPE region, so it's not an operational issue but more a policy issue on the ARIN side.
RANDY BUSH: But that's transferring within the RIPE region, will RIPE accept such a transfer from ARIN and the only thing that's missing is the transmission from ARIN, question mark.
AUDIENCE SPEAKER: That's right.
CHAIR: We have two more questions and then we are going onto the next presentation.
AUDIENCE SPEAKER: Sander Steffann. The fourth option that you are missing is, in RIPE region, you can voluntarily give up your legacy status and convert it to PA status if you choose to.
RANDY BUSH: That's right. John, you can tell us where the corporate jet is?
AUDIENCE SPEAKER: But, I just wanted to say a couple of things. Randy, I do thank you for this presentation, and it's very helpful for people to see how one of these actually works.
Regarding your characterisation legacy RSA, it's actually not all wrong, let's put it that way. ARIN does specifically say, here is the rights you get and here is the rights you think you may have that you don't have, and you sign that as an RSA holder in the ARIN region. Also, if you end your LSRA relationship, you don't get anything back; the only way you resume your prior status is if it's as a result of a contractual breach and we go to arbitration and Arin loses. It's a one‑way door in, you do have to give up specific rights. You get others by contract, but it may not be what people are looking for is correct.
We do have hundreds of people signing this thing though because they are often in the process of transferring resources they don't mind signing the LSR A as part of the cleaning it up and monetize it go or whatever.
The only other thing I wanted to say is that this whole process is been informative to look at and the RIRs have been talking about things like the DNS nuggets and how to make that a little better, and I think there is some things that could be done if we're going to see a lot of live transfers. One of the things we may need to know is how much effort to put into live transfers. If that's going to be big, you need to at the time RIRs that because it's a different level of work. The last thing is, I think this is so informative that we should, every year, move the space back and have you go through the process again so you can give an update here at ARIN.
RANDY BUSH: Are you that desperate for 500 bucks? I think I'll stop...
CHAIR: Thank you, Randy. That was very interesting.
(Applause)
Okay. Our final presentation for this session is Philippe Duke. He will be talking about how local or national policy, so to speak, may be not so local or national after all.
PHILIPPE DUKE: Hello, I am from NetAssist and today I'm going to tell you about things, how Government regulation affects Internet in different ways cannot predict.
First of all, I should say that we work ‑‑ I work in NetAssist, which is the company ‑‑ my company is works as ISP and IN. We have a lot of progress around the world and especially in the European region, we provide connectivity for business and home customers as well. And our mission is to help people use Internet, help people to connect this application and make their work done. This is what we live for and this is our main task.
And sometimes we have some complaints from our specific we work with from different regions, and that time was some complaint from eastern Europe. The complaint shown and the body of some country that already implemented censorship. First of all, I want to say I split several times of censorship. It's just a little control, control some resources and just a little bit introduces their way to manage Internet.
The second type is blacklisting, the Government provides some blacklist of sites, but you should be impossible to access, using stand‑out way, direct way, just type in by URL and so on.
And it seems like, it seems that the country, what I will talk about, implemented the second type of censorship. So of course I cannot stay here without talking about the country which was, which made it, and it was sure that something might happen, but the country I want to talk to you today is big enough and have a lot of companies, which is actually part of RIPE which make a lot of useful things, and I don't know that ‑‑ I don't know why some of administrators are making mistakes, cannot predict. But anyway, this country started some sort of censorship since 2012.
So, this censorship is designed to ‑‑ is not a big task to bypass, it's some kind of censorship where you have active probing and so on. It's a blacklist each operator should download and then block several types of sites, you see on the screen, and that's easy to do but sometimes not easy. So, there's a few ways how operators might do it.
They might block the whole resource, they might block some content on the site. They might block something that belongs to the server. It doesn't matter, but the thing that should be implemented is the site should become unavailable for most of the people who want to access it without using some proxies and so on.
So, operators are a little bit different in implementation of this kind of blockage. Some may use DNS zones to notify records and just pull it out to some page which shows that you are unable to access it because it's blocked by legal reasons, for legal reasons. Some use IP blockage which may lead to problems. Some try to filter http traffic, which is quite expensive. And you know that the main task of censorship is do not blocking too much leads to collateral damage, which is not good for anybody, for anybody to, who knows what it may lead to. Everyone knows how ‑‑ everyone knows how it works, how accidents like YouTube in Pakistan which led to collateral damage into the world. You know it. Somehow, some techniques are not easy to implement because of the cost it may lead to. You always just like balancing scales, what you block and not to block too much.
When governments says that you should block some page on the resource on the website, you should probably you should use L7 filter in your URL just to filter some exact content, but in the case when you decide to use SSL, when it's impossible to do and if you know that commitment is not ethical and nobody use it, I hope.
So, you always balance and the cost range. If you have small player in the game, you are probably maybe thrashed by big players, that are capable of introduce more specific filtering. So, it's an expensive thing for small players, so...
And the big operators probably try to implement filtering using big routers which an IP blackholing which is quite easy to do and it's not ‑‑ it's not expensive so just run one entry to routing table and go on. That's very good.
And so, why do we care about the problem and why is it a problem to start with? We care about the problem because many traffic run through ISPs in the country, and some countries are able to use just uplinks which belong to Russia and controlled by operators or single operator or it doesn't ‑‑ and it doesn't change the situation too much when they have two or three uplinks, they are all literally maybe the same. So, when the operator has a mistake implementing this kind of blockage and in the wrong place, you just get a problem in the countries outside the country, where the censorship being implemented first time, first way.
So, of course, it may lead to some BGP problems, it may lead to damage to peers that peer into the ISP, and we already had, we already had seen such accidents, and there was, it was easy to predict. So literally, what I'm talking about the possible scenarios I'm talking about looks like this.
You have some ISP which belongs to the country where censorship is implemented and you have a transit, and the transit also belongs to the same country and you have some different uplinks of the transit, there may be some peers like Britain, maybe, like layer 3, it doesn't matter, but in some cases you are able to access resource, in some cases you are not. This is the real situation. Because cannot analyse why your customers just cannot access your service from the some same point from the same ISP, it's a really weird situation. And it's really difficult to do. You probably should learn the topology and BGPlay and so on. And same accident I predicted already happened with the site you are probably willing to be blocked is one who is supported copyright here, maybe someone who is support copyright content is here, and so this site was blocked in Russia, and they blocked months earlier before the accident happened. So, imagine the site which was blocked, blocked because of a judgement, and they worked fine for customers in Europe, everything worked fine, unless they had massive DDoS attack on them. I don't know, I cannot be sure who started this attack, but anyway they used service of some autonomous system called DDoS grant, this is autonomous system, they filtered traffic on L7, maybe more they have more complicated techniques to filter it by statistical method. Anyway, they had like filtering AS, they filtered the traffic, and you may see ‑‑ and they had uplinks, one of which was TransTeleCom uplink, which had implemented blocking runway. As you may see, the site was unreachable from some ‑‑ from the ‑‑ TTK trans route, customers of this site and users of this site was clever enough to make it traceable and find out the problem by themselves and they found, as you may see the site is reachable through the NTT network, and was unreachable through the TransTeleCom.
This is how it looks like when you have a blockage this way. You may see that any peers of TransTeleCom that gets announced with more specific announced they get, they get unable to access this site.
So, the accident shown that the problem exists and we should start searching for more and start searching for operators which have problems, and start searching for countries which experience some problems but did not report them because of the situation. It may be true. We just suggested and started doing our research. And we included some Ukrainian regions which was close and we had a complaint from them. We just suggested it was because ISP DNS configuration really.
Thanks so much for RIPE Atlas. This is really good technology to find out the problems in Internet. To find out how Internet sees you. I think that's very good project. So, we tested some ‑‑ we test some set of countries which was near the board of the country where censorship was implemented firstly, so we test some expected to be blocked site using the provided blacklist by Government, and we run several techniques filtering out connection time‑outs and failures, adding such sites and nodes to the list. We all did by hand mainly. It was easy to do.
And we find out some interesting results. First of all, we tried to use SSL certificate, in the case of SSL probe failing we just marked the site as failing and so on. We tried to eliminate DNS and IP miss configuration by testing some sites like GitHub which would work as well, and any situation, it shouldn't be blocked.
And we found some interesting results. A few countries was affected for sure, like Kazakhstan, Uzbekistan, not entirely all probes in two countries were affected. Countries like Georgia and Azerbaijan and Armenia used probably non Russian up links so they had no problem, but we suggested that it might be. European countries likely not affected. And we seen the reason. The reason was SSL time‑out. There was ‑‑ that's why the site was unavailable. And it seems like everything is fine, but traceroutes stops somewhere in Moscow, somewhere in the kernel of the network in Moscow.
So, I have given you the list of networks which was affected by this thing. As you may see on the map, I just explained it in red, the places where perhaps which had problem accessing two test sites from the blacklist, and you may see that it's quite ‑‑ it's like some regions, some regions where the uplink took place.
So, we found out transit AS where the traceroutes stop, was well known for Golden Telecom, they provide Internet for many countries around, and we found Looking Glass and in Looking Glass we found some strange entry, the entry which points to test net, as you may see from IP address it was strange and we found it was likely to be blocked by black hole, which you'd expect it to be. Just a very simple way. Just block site and black hole and everything works fine. But it's not for transit traffic.
So what do I say to do? First of all, what I found is not full picture, it's not full. Of course, the accident may happen at any time, and any time the administrator tries to block a site using no technique, trying to test it, but the thing that ‑‑ the problem belongs to the network which has a big size around the country, this is an example of educational network in this site and you may see it's connected to many places, to many exchange points and the traffic passed through this network, you get blockage, you get your customers not working.
So research should continue and people from around countries which implementing blockage in some way should also monitor connectivity to their site. And if you have a possibility not to transit your traffic through such networks, you should be ‑‑ you should use it. Probably I should thank [Retin] Network, they always counted such problem, they predicted it and never get into blocking.
So, there was mixed configuration from administrative sites. We contacted two networks and we had a contact and the TransTeleCom fixed the problem ‑‑ but the problem may appear again, we don't know where, we know why, we don't know just when and how it might appear. But this is just the members to add trait network to be careful when you implement censorship in any way. You should do it probably you should do it carefully, and I just suggest you make it near your PA, your provider edge, where your customers stand in.
This is all we found. And this is our contacts. I am ready for your questions. Thank you so much for listening.
(Applause)
AUDIENCE SPEAKER: Alexander, from Russian federation. Maybe it's not a question, it's some notes. I could ‑‑ I would like to make a little translation in short of this presentation. Just, I think the reason for this presentation was that some Ukrainian sites, particular Ukrainian sites fall under blockage in Russia. So, just one sentence, but I would like to mention that, three or four years ago, before implementing Russian censorship system, it was stated by a lot of people, including Dmitry Burkov of RIPE NCC, that implementing censorship in a country will kill a transit through the country, so I would like to thank the presenter and his company for independent confirmation of this fact.
And, also, I would like to mention that the latest words of Russian Government to get interaction with RIPE NCC on getting copy of RIPE database is just a little steps for improving the Russian censorship system going down from blockage of content to filtering routing, so I would like NCC about needness of really accurate steps with Russian Government. So thank you very much for stating obvious things, but, again and again, as independent part.
PHILIPPE DUKE: I realise our role in the informational society. I realise the role of RIPE in the informational society of course, and probably the variety of sites the Government blocks is very big. It depends from for a lot of reasons, as we know, but, of course, RIPE should be ‑‑ of course, we all should be careful when talking to Government. Every time Government plays a game, we have a problem. So... thank you so much for the question. Thank you so much. I would like to say that we'll ‑‑
BRIAN NISBET: Sorry, there are more questions.
AUDIENCE SPEAKER: Hi, Collin Anderson. So, two things that I wanted to mention. Firstly, that this has come up in a number of cases, for example leakages of hijacking where YouTube in Pakistan. So there is kind of a literature that this follows into. There are a number of conferences on these sorts of issues, like [Fokai] at USENIX, and I think that they would be really interested if you systemitised this and published this, because it's really use envelope this respect. I also much more shallowly probed this question with RIPE Atlas two years ago for this conference and I didn't see the prefix announcements, and so I kind of left it at that, so personally, I'm thankful because this solves a question that I have had.
I looked at your slides and the prefix announcement was a /32 which shouldn't necessarily have propagated to BGP peers, did you see leakages of routes or did you see that essentially it wasn't until the victim come network that it started getting blackholed? This is see this was POP you will gating downwards in much more of the routing plain?
PHILIPPE DUKE: Thanks so much for your question. I understand what you are asking about. Of course, the routing entry was propagated for peers. Thank got that it wasn't propagated and if it was propagated, probably it would just be filtered because it's a /32 prefix. Anyway, it seems like it was added manually by hand, by administrator, so that was the first reason why such a problem happened. And to think what I'm talking about, there was not a single /32 prefix seen. There was any other site that was using SSSL, I mean HTTP to be accessed, was blocked same way in the same network.
AUDIENCE SPEAKER: Marco Schmidt from RIPE NCC. I have a question from the remote participant, from Marty from CloudFlare. It's related to what was just asked. Marty wrote: More than once I have received e‑mails from ISPs in the region complaining about of being unable to reach our network. The solution was to peer with with them directly. Do you think this is a motivation for local ISPs to extend their networks to main peering hubs and peer with content providers in order to get around the blocking?
PHILIPPE DUKE: Thank you so much for your question again. Something about peering, and when you have a transit which blocks the traffic to the destination, and probably it works, it works fine, and this is the good solution to overcome the problem. But you know that such solution may be expensive unless you have access to IXP where you want to peer with the network, you want to peer. Anyway, what I say for myself is that the best solution is just to get the contact to ISPs which have such, which have problem, which experience some problem in this kind of blockage and tell them to be more careful and then report the accident for them. I think it's easy to just fix the similar accidents they have and it will work fine. But, of course, peering is a good idea to overcome any kind of blockage.
AUDIENCE SPEAKER: Daniel Karrenberg, RIPE NCC. Thank you very much for this presentation that actually shows some experience of what's going on. Also, thank you for acknowledging our RIPE Atlas. I have no question for you; I have a comment to the comment that was made earlier about the bulk transfers of the RIPE database to the Russian Government or them asking.
I have the comment to the person that made that comment is, making a comment here has no effect. You have to go and change the RIPE NCC, or the RIPE policies regarding this, because the RIPE NCC can only treat the Russian Government as just as everybody else and use the policies that you guys make. So, if you really want to do something about it, go and change the policy. I personally think we should not do bulk transfers of the RIPE database any longer at all, but that's my personal opinion. Thank you.
AUDIENCE SPEAKER: Dmitry Kohmanyuk, Hostmaster. Can you go please to the slide where you mentioned the regional hijack. I think it was slide number three or four. Anyway, and while you are doing that. I want to ask you, when you discovered that ‑‑ when you discovered that, did that affect your customers in Ukraine?
PHILIPPE DUKE: I want to say that, for the time of testing, we didn't find the problem inside Ukraine.
AUDIENCE SPEAKER: Your peers in Ukraine or ‑‑
PHILIPPE DUKE: We didn't confirm it. We had complaints but it didn't confirm it. But what we found in this set of countries which ‑‑ this site of countries.
AUDIENCE SPEAKER: Yes, because the map doesn't show any Ukrainian territory...
PHILIPPE DUKE: It is, exactly. What cannot ‑‑ what we could not confirm, we didn't include it here. We just include here problems we confirmed at the time of testing, at the time we started testing. And personally, I don't like to talk about hypothesis, that it might have some problem. We just verified our hypothesis and find out what is really, where is the real problem. And when I say that any of these ISPs may get direct presentation through the mask of Internet exchange in our blockage, this is just my advice.
BRIAN NISBET: Okay. If there are no other questions. Thank you very much.
(Applause)
So, a couple of very last things. Please, as always, rate the talks. You can win a prize. Also, you have four minutes left to nominate yourself or be nominated by someone for the RIPE PC. We like you people who have new ideas. So, that's it. You have a three‑minute extended coffee break, so thank you all very much.
(Applause)
