Plenary session 4 p.m.
Tuesday 21st May 2019:
BRIAN NISBET: Hello. Before we start with the last plenary session of the afternoon, just very briefly as is traditional, the PC elections for this particular meeting, we have two seats up, we have three candidates, and they will now briefly introduce themselves and then the voting which is live on the front page of RIPE 78 you can go in and sign in with your RIPE access account and vote. So first of all Francisca
SPEAKER: My term as PC member is up with this meeting and I would love to rerun because it was a lot of fun, it felt to be a good contribution to the community to actually leverage the knowledge that I have with a scientific and operational background to be able to judge a lot of presentation we have got and I think we succeeded to make very good plenary programme for this meeting so I would love to continue that work. Thank you.
(Applause)
SPEAKER: Henrik: And I would like to join the PC because it's a very good programme and we need to keep on doing great programmes. I have done a lot of presentations over a lot of years so I think I have a lot of input on somehow we can improve some of the presentations and make everything better. Even better than it is now.
SPEAKER: Jelte Jansen: If I am elected I promise I will not stop until we call a DNS patch Tuesday. But before that, I ‑‑ I have been on the Programme Committee before and I loved it and I want to do it again and I think the programme this year is brilliant. Maybe even too much DNS and I don't believe that I would say that, but I would like to see it as good as it is now and maybe even better. Thank you.
(Applause)
BRIAN NISBET: Okay. So, yeah, you can go to RIPE 78 .net, there is a vote now button the ‑‑ they are there, you have to sign in with the RIPE NCC access account and you have until tomorrow afternoon ‑‑ sorry, today is Tuesday, isn't it? That's very important. Linear time. You have until Thursday afternoon and we will announce it on Friday morning. Cool, thank you all very much.
(Applause)
PAVEL LUNIN: Good afternoon, ladies and gentlemen. We are going to open the next plenary session and the first talk is on open source lawful intercept by Richard Nelson from the University of Waikato.
RICHARD NELSON: Thank you. I am university academic but this is not a research presentation. This talk is about a project that really came out or driven by the service provider community in New Zealand. So nobody does lawful intercept for fun or for profit, it always starts with the legislation. We all know that governments around the world have been passing legislation to solve cyber security, and this is the New Zealand government's effort in that regard. This piece of legislation affectionately known as TICSA. TICSA is an act in four parts but the requirements on service providers come out of parts 2 and parts 3. Part 3 is the security bit, that's the bit where one of our mobile operators has come into trouble with recently because they proposed to build their 5G network with a certain Chinese vendor's equipment, but most of the requirements for this project came out of part 2, and part 2 of specifies that network operators with more than 4,000 customers in New Zealand are required to deploy lawful intercept capability. Part 3 does have some bearing because it also specifies that the lawful intercept capability has to pass the security check in in the Act.
When it was passed in 2013, the particular technical requirements of the lawful intercept capability were not included; they were left for regulation, so that they could be updated later, and also of note is there was no provision for the government to fund any of that lawful intercept capability, unlike in Australia where the government does pay for it, in New Zealand the entire cost was left to the network operator.
So nearly four years after the act, the regulations were passed in August 2017. The regulations specified that the ‑‑ the capability had to comply with the ETSI standards, that is not rale surprise. The ETSI standards are apparently used everywhere except the USA and Russia and they have some key advantages for law enforcement community. They provide for near realtime streaming of the captured data so that, for instance, the police can listen to voice conversations while they are happening and hopefully pre‑empt some sort of illegal activity. They provide a ‑‑ require encoding of the captured intercept so that the material can later be used as evidence in the ‑‑ in courts, and they also require capture of metadata associated with the capture.
Eight days after the regulations were published, a bloke called Dave mill from a service provider called inspire .net which is a regional service provider in the north island, noticed that the police had also published those requirements on their website, the police are the registrar and are required to ensure that all of the service providers are meeting their obligations. So Dave posted a message to the ‑‑ in the NOG mailing list to find out what other ISPs were planning to do. He got a whole bunch of responses, a lot of them off‑list so you summarised back and it actually turned out there wasn't a whole lot of planning taking place at all. In defence of the ISPs the New Zealand Gazette is not actually required reading for a service provider and they had had four years in which the police actually did just accept P Caps because there was no other specification of what they had to do ‑‑ so it came as a surprise to a lot of people. But coming back to Dave's query, he really wanted to know whether they were planning to spend lot and lots of money or whether they had some other solution in mind. The discussion went on for a while on list, there was a bit of a search for existing open source solutions and people found hints that things had been tried but nobody could find anything that had really happened. As the discussion went on, the idea of collaboration came up, it turns out that lawful intercept is not really a competitive advantage for any of the service providers and they felt that working together would be, you know, something of a good idea.
So at that point, I put up my hand, or at least I put up a collective hand of the research group that I run. Now, in New Zealand, we are quite well‑known; I am a trustee of the network operators' group and I have worked on various projects with most of the service providers staff who have actually been involved in the discussion on the list. So, a lot of people were quite accepting that this was something we could do, and so the hard thing was persuading ourselves it was something we could do because at that point in time we didn't really know a whole lot about lawful intercept and what the requirements were and also if we were potentially going to put software that we wrote into, you know, production within a bunch of service providers, we had to be pretty sure that we were going to deliver something that was ‑‑ that works or otherwise going to do our reputation a whole lot of harm. Since that time, we have also been attacked publically for our competency actually on the NZ NOG list because that was kind of okay because it was pretty clear that the person attacking us was trying to sell their own sort of systems. However, having come to the other side of the world, it turns out ‑‑ I assume not everybody has in fact heard of us so I thought it might be worth reiterating who we are. The WAND group has been around for over 20 years, started by trying to build hardware to capture traffic, that was spun off into a company which is still making and high performance capture systems from New Zealand. We have done a lot of work on actually capturing traffic and publishing those traces, I checked a few days ago and quite a large part of our traces are in fact still avail on the RIPE Labs site, and we did develop software to do that.
We have also done quite a lot of research based on those captured traces. And these are a few examples of papers we have published. The last one possibly is interesting, we managed to capture a trace in one place and stream it to another place and we kept that going for 15 months without losing any packets. To do this, you know, the software has to be reliable and very accurate, not only in terms of what it does capture but in terms of what it removes from the capture as well, because we need to protect the privacy of the users of the network traffic that we are capturing.
This stuff is a little bit older. But at the time that we started considering this in late 2017, we were working with the CAIDA group at U C San Diego, the CAIDA group have a traditional class A address that is effectively unused and they advertise that to the Internet and collect a lot of unsolicited traffic. In a world where security is kind of important but data sets can be hard to come by, there is quite a lot of researchers that would like to make use of that and we saw a classic example of that with Matthias this morning. So, CAIDA are redeveloping this infrastructure so they are upgrading the speed and writing new software to capture the traffic, to process it, to produce summaries and add meta data and store it all reliably and stream it across for other researchers to have access to.
And our role or at least the role of one of my programmers, a guy called Shane, has been to write the pieces of software to do just that. So at the time I had a programmer who was ‑‑ whose working in the space and at a conceptual level was doing all the same things that were required for lawful intercept, and more importantly, another project he was working on was coming to the end so he had some space and was ‑‑ had the capability to take on this project and actually do something.
So, Dave and I worked together. We put together a group of companies who were prepared to stump up some cash to pay for the development time, pay for Shane's time to work on it. Most of these are service providers who have obligations and needed to do something. One or two of them are not, and were just contributing to the contract ‑‑ to the project.
At this point, the issue of licensing of the software came up. I'd love to tell you that we were all taking a strong ethical stance to maintain the transparency of the lawful intercept process, but the reality was a bit more complex than that; some of us were very keen on the Open Source ethics, but the major funders, particularly the guy who was underwriting it initially, was more concerned with ensuring that the software was going to maintain ‑‑ remain free and available, whatever happened to us in the research group when we wrote it. And quite frankly, the university was quite happy that it was Open Source because it meant managing the intellectual property rights amongst this very large group became a really simple problem.
So, as we heard in the last session, sometimes the hardest problem with a project is finding a name, unfortunately in this case it turned out to be quite straightforward. So we registered the domain and we put up a simple static web page and that made the project official.
The first thing we had to do was decide which actual standards we were going to implement. So along with the base standards specifications, we were going to implement the layer 3, the IP handover because it's required for ISPs, and we are implementing the so‑called multi media standards because in actual fact that covers voice‑over IP. We are not implementing the Layer 2 specification because the way the New Zealand market works, it's not required for Layer 2 operators. And we are also not implementing the e‑mail specification because very few ISPs still maintain an e‑mail infrastructure.
There are also standards that cover mobile networks. We are not going there. And there are standards that cover legacy ISDN and pot services and that ‑‑ they seem to be going away so we are not going there either.
Then Shane had to work out what we were really going to implement. In New Zealand, when are a law enforcement agency want to have an intercept initiated they provide legal document called a warrant, and the warrant specifies an intercept to be served on a person. It's then up to the service provider to associate that person with some customer identifier that they use, and they ‑‑ into that information is configuration into the OpenLI provisioner. The architecture, when we were implementing this, there was no other systems we could go out and look at to get ideas of what we were doing so this was all based pretty much on a reading of the standards. The provisioner configures the other elements, the collector is associated somewhere so that it can connect the metadata which, in our case, is the SIP signalling traffic and radius traffic and it uses those records to associate particular IP addresses and particularly IT SP sessions with the customer, and it collects all the data and encodes it and passes it off to the mediator. The mediator combines the streams of the metadata and the data and it stands up a secure connection which in this case is normally an IPsec tunnel to the law enforcement agency and passes the packets. Because the ISP may need to scale to cover geographic areas or improve the capacity, we can support multiple collectors.
Because it's supposed to be a cost‑effective, we were aiming typical one new commodity servers and we used our standard development environment rather than aiming for some new languages. This basically saves us a lot of time and it turns out Shane really enjoys coding in C so we have Linux, C and a library we call Libtrace.
Libtrace is the library that sort of encapsulates a lot of experience we have had with capturing traffic. It really started as a way to stop new developers making the mistakes of making assumptions about specific Layer 2 or IP versions or forgetting about things like fragmentation and TCP options. So it deals with all those things and provides an API for accessing them, it can read from files and from interfaces. And it's being developed ‑‑ rewritten a number of times over the years to be as high performance as possible while still maintaining a per packet processing capability, and that turned out to be exactly we what we needed for lawful intercept.
Performance is of course important. A couple of our supporters of the number 2 and number 3 largest ISPs in New Zealand and they have the potential requirement to stand up multiple captures at the same time, multiple intercepts at the same time and we are entering an environment where gigabit consumer connections are becoming the default and 10 gigabit connections have been trialed and for the evidence reasons we have the requirement not to drop any packets. So we were aiming for multiple gigabits per second of loss packet capture.
Fortunately, Libtrace is designed for high performance, it supports the load balancing features of that so we have ended up with extremely parallel capture, multiple collectors and multiple interfaces and multiple streams per capture interface and that means we can distribute the traffic across lots of CPUs to improve the performance. However, spreading it across lots of threads has a price, it becomes really difficult to maintain sequence numbering that has to be consistent and it's quite hard to associate or synchronise sessions when you are basing those on captured data from the metadata packets.
The solution to having too many threads, of course, is to add more threads, and so we have ended up with solution with a very complex thing, including a large pool of ASN 1 encoding threads because that turns tout object the real bottleneck in the whole thing. So, testing on our not completely up to date hardware in the lab gives us about half a million packets per second of encoding and we still think we can improve on that.
Late last year, we declared version 1.0. At that point, we felt that, well at that point we had reached all the ‑‑ delivered on all the promises that we made to the sponsors when they stumped up the money at the beginning of the project. And the software was really to be used for by ISPs to meet their obligations and perform lawful intercept.
There was one more promise that we'd made, which was to and an under source licence, it's now GitHub and it's licensed on the GPL version 3.
To make it easier to install, we have also packaged it. At the moment, we have also packaged all the dependencies, at the moment it's available in apps format but we working on that that and hopefully, thank should be available quite soon.
So it's deployed. Dave inspire has become our reference, reference deployment. He has talked about quite a bit about what he has done publically and discovered that the sky didn't fall down. We know he has been ‑‑ T ICS A part 3 security approval and received that and he has also ‑‑ we were involved in integrate testing between inspire and the police and the police have confirmed that it works with their systems and does everything that they require.
Other ISPs have not been quite so public about what they are actually doing but we do know from the support requests that we have received and feature requests that quite a ‑‑ several of them are actively going through the process of deploying OpenLI to meet their requirements, although sometimes a progress slows down, it turns out this is not always the highest priorities busy network engineers. In fact, I would say we have talked to two‑thirds of the ISPs who are required to implement lawful intercept and I am pretty sure almost all of them are in fact going to go with OpenLI. We even know there is a couple of consultants who have talked to us who have been employed specifically to implement it for ISPs in New Zealand. We don't totally know which ISPs, though.
The police seem to have been very happy, as I said, they have the responsibility of making sure everybody actually has met their obligations and they have been as supportive as they possibly can be while acknowledging that they are required to also maintain a vendor‑neutral stance. But we know they are pleased because generally this year ‑‑ January this year they gave, that's Dave in the centre and Shane on the right ‑‑ they gave them both awards for their contributions to security in New Zealand. It's also noticeable that at the same meeting they changed the rhetoric from encouraging people to work out what they were going to do, to reminding ISPs that they are actually quite large penalties under the act if they don't actually go ahead and deploy the stuff.
So we haven't stood still, we have received more funding, notably from the Internet Society in New Zealand, and we have kept working. Now, obviously, as we deploy it we have had bug reports and we have fixed those as fast as we can. We have built a proper test infrastructure so we can continue testing ‑‑ fixing bugs and adding new features and detect when we have regressions and in software. As part of the security a bunch of internal security improvements and auditability were requested and most of those have now been implemented. The next thing is disc backed buffering, at the moment if your connection to the law enforcement agency goes down, OpenLI will fill up the memory that is available but fairly quickly things will start to go pear‑shaped, by adding a disbacked buffer we should be able to cope with much longer outages. We are still working on performance improvements. The main target is to change the set of encoding rules we use. Currently using distinguished which give a format which was good for testing but can be variable length which makes things pretty slow. So we are going to the basic encoding rules or add that as an option. And we had a bunch of requests from ISPs about specific enhancements to allow them or improve the way they can integrate it within their networks.
So there is the links. It's an active Open Source project. The code is all there. And we welcome pool requests. Thank you.
(Applause)
CHAIR: Thank you, Richard. Are there any questions for him?
JIM REID: This is great work, I think you guys done a great job here and think it's a very interesting toolset. A couple of questions. Are you just using this for intercept of voice‑over IP traffic or is it for any other kind of web deleted activity like, for example, http or chat sessions or whatever, or is it primarily voice communication that you are looking for?
RICHARD NELSON: So we have implemented both, there is two standards and they can request it. So it will do voice‑over IP or it will do just everything.
JIM REID: Okay.
RICHARD NELSON: Without any filtering.
JIM REID: Horrible question: What is TLS 1.3 going to do to all of this?
RICHARD NELSON: The good thing about this is that we have to maintain the chain of evidence, which means we are not allowed to change anything, so we don't decrypt anything.
JIM REID: Okay.
RICHARD NELSON: That is the police's job, not my problem.
JIM REID: A very diplomatic answer, thank you.
AUDIENCE SPEAKER: Chris, I work for Google but this is really not a Google question. So I haven't had to deploy a lawful intercept in a US global ISP but for US things. It's a gigantic pain in the butt and all of the options you have are really horrible. So mostly it's in things like management infrastructure for it is pretty crappy, like oh, it's always a /32 only, you have a /29 for a customer, you can only have 32 in the config. Oh great. Being able to do ‑‑ things like intercept anything more than two or three megabits per second isn't really feasible in the deployed gear unless you send people the site to actually split fibers and having done that for four years.
RICHARD NELSON: Right. So, I think what you are saying is that it's a problem. Is there a particular question?
AUDIENCE SPEAKER: Sorry, I didn't ‑‑ and I didn't look at your code or the interface, but it would be great if sort of a more network‑centric view of the problem space were possible. In other words, like you put in a specific user, and get either their address or their net block applied to the config system. And I didn't see if it's capture cards like deployed on split links or are you just using the lawful intercept capabilities in the deployed gear?
RICHARD NELSON: So, that's kind of external to the software. It's up to the ISP to choose how they want to get the traffic to us. At the moment, most people are ‑‑ there is a variety of things are going on. We are adding the lawful intercept capabilities for some of the gear because that's been requested at the moment, Juniper being really big in New Zealand so we are going to support them. And some of the smaller providers use ‑‑ that is a standard interface. We can ‑‑ at the moment, the assumption is that, you know, we will just provide the traffic for the user but we will look at all of the SIP traffic and all of the radius traffic. At the moment, there is a variety of identifiers that you can use to identify a customer and it can be done dynamically by looking at the radius feeds as well and working out what's assigned at the moment, and yes, it can be net blocks or ‑‑ and we don't make assumptions like that.
In terms of speed you mentioned a few megabits per second. We can do approximately four or five gigabits and we think we can supply traffic faster than any law enforcement agency can receive it in New Zealand.
AUDIENCE SPEAKER: It's not ‑‑ it's the collection side that's the problem. I haven't done this in ten years but the limitations were on the collection side on the device. A Cisco box can only give me 15K PPS across all cards and it's a shared PPS so like now all of a sudden when I hand this to law enforcement, this might be all the packets, who knows? Good luck in court.
RICHARD NELSON: For us that's not our problem.
AUDIENCE SPEAKER: That's why I was asking about the collection ‑‑
RICHARD NELSON: There is a variety of solutions people are deploying and it's up to them to choose a solution and negotiate it with the police.
AUDIENCE SPEAKER: From ‑ security. I have a question about the Open Source aspect because I think it's really great that you are doing this as Open Source for the transparency reasons. Have you seen a push for the law enforcement agencies to also open up their code or do it as Open Source? Because we are wasting a lot of public money doing commercial systems.
RICHARD NELSON: The law enforcement agencies that we have dealt with won't tell us anything about anything that they have got on their side. You know, testing interoperability testing is a real problem in this space. It's to do with the issue of encryption, they are trying build systems that they believe can break encryption, they do not want to indicate to anybody what the capabilities that they have might or might not be so they won't tell anybody anything, as far as I can tell.
CHAIR: One last quick question.
SANDER STEFFANN: You said you were looking at Juniper and Microtech. I actually did the Cisco side a couple of years ago and figured out all the SNMP crap you need to do to get it to work. If you want any help with that, I will be happy to help out.
RICHARD NELSON: That would be really great, just send us an e‑mail, thanks.
CHAIR: Thank you, Richard.
(Applause)
And our next speaker is Alexander Isavnin from the Internet Protection Society who will talk about the Russian regulation update on routing control.
ALEXANDER ISAVNIN: Hello, I will give you an approach from another part of the world. So Russia is a big new country, it was created as independent entities after the fall of Soviet Union. So we have regulations and our Internet regulated since that times.
And how to regulate Internet, just copy and paste telephony regulations, just copy and paste regulations from and even it's not working, it doesn't matter. In Russia we have, for example, licences for service ‑‑ nobody know what it is but licence exist. By the way, why I am presenting here, I used to be a network engineer, but laws in Russian companies think that everything is prohibited and they lose free will when see people in ranks so I had to study regulation just to be able to explain to my bosses that we can do this easily some way.
Back. Internet in Russia is regulated as public services network. So like all your telephone your network is regulated. ITU unfortunately have no special regulations for Internet as a public services network, so no, by law there is no regulator document written on this, but the idea is still working.
It brings some possibilities for end users, they have more protections than just ordinary customer protections, and also network operators have a bit more protection than just commercial companies providing services. Well, a little reference to previous presentation. In Russia we have lawful intercept which works as bulk wiretapping and it's done on account ‑‑ in the beginning of 90s the ministry of interior came and said we are developing country, we have no money, let operators pay for lawful intercept temporary. Okay, now operators pay for all regulator changes. And unlike previous presentation, when we have seen there were ‑‑ goes to operator. In Russia operator works as a black box. Our law enforcement agencies doesn't believe operators, they think they are just the same criminal groups as anothers. So, operators does not control everything. All done by black boxes mostly.
Lately, mostly in 2011, 2012, new regulation was approved, it was in the name of protecting content ‑‑ it was not working successfully for the purposes intended but work at state level censorship and also done on account of operators. We have automated control of blocking, it works in transparency so operators can be fined easily.
A lot of regulation was developed for interests of law enforcement agencies. Operators must retain more data, have street identification of users. Provide a test for law enforcement agencies, to have billing systems for ‑‑ to let them see all registration data and everything else. More so‑called Yarovaya, introduces requirement for operators to store telecommunication messages, whatever it means, nowadays for one month, in five years or four ‑‑ for half of year to let law enforcement agencies get back and see what users have done. And again, everything on account of operators.
Suddenly I think it was during package approval regulators noticed that providing commercial access to Internet is not ‑‑ does not cover all subjects which provide something Internet, it does not cover hosters. So introduced a lot of new regulatory subjects, for example information distribution intermediaries who got responsibilities slightly ‑‑ operators, for example to communicate with law enforcement agencies have data retention and provide information about users.
Also search engines are regulated for content blocking purposes. Some of regulator attempt in Russia have failed. For years, Russian government tried to regulate distribution of number resources like IP addresses and names, they were trying to find ways to ITU but was not successful. Many, many years ago there was an attempt and there is a RIPE document in RIPE store to create something like national Internet registry, I think like this was ‑‑ this attempt was cancelled. Also, in Russia there was attempt to create regulations like current upload filters in European Union but that had to be download filters so operators had to determine copyrighted content and automatically get fee from end user. This thing was failed.
A lot of attempts to ‑‑ domain which was run by independent NGO, was made in regulator levels, it was not successful.
So now we have a law called "sovereign Internet", not called this officially it's called something like amendments to telecommunication law and to information, information technologies and information security laws. Publically stated motivation was an aggressive US strategy. I have read the strategy, it's not an aggressive and it's not aggressive against Russia. The final thing is the proposers, the parliament, during presentation of this law was not able to spell routing and firewall in Russian correctly, not authors of this law, they present it for some other interests.
The fact that it is said that United States hacked virtual machines of servers placed outside of Russia and used by ‑‑ there was a public and this law was introduced very fast as a reaction to such activity.
So, what brings this sovereign Internet laws? For the first time in Russian regulation and I think in regulation in other worlds, the autonomous system number holders are regulated. So, if you ‑‑ if previously you had to sell your services, somehow, and getting money and only in this case you needed telecommunication licence, this regulations, if you own a network, if ‑‑ and if you have autonomous system number, that does not mean that you need to provide services. You fall under regulation of this law. Also, that monitoring and control centre for the Internet is being created. That's not very usual and not in the main idea of Internet having the single control centre.
So, what obligations for AS holders, holders of AS numbers? The full rules of routing set by regulator, apply corrections to routing if regulators ask them; resolve domain names using only approved by regulator equipment; follow continuity rules ‑ well, actually, the whole legislation ‑‑ whole intention for this regulations is provide continued and stability for Russian Internet in case of outsiders attacks. So, autonomous system number holders have to continually follow the rules. They had to execute orders issued to control centre. I think orders related to routing for sure. They had to use only registered IXPs, so these regulations uses registries of Internet changes; they had to report to regulator autonomous system numbers, routing policy, equipment, they are using for domain names resolution and provide all information about network equipment and network infrastructure; also, if your autonomous system number holder, now you have to install lawful intercept equipment, which is called SORM and provide all information traditional operators had to provide to law enforcement agencies. And well that was very popular thing among ‑‑ for foreign journalists, you may be selected to participate in security stability continuity trainings.
Very unusual set up of obligations for autonomous system number holders.
This law sets only frameworks. We were reading this law and counted more than 30 regulator documents and by‑laws need to be redone by different entities, government itself, ministry of telecommunications and regulators, some of such documents related to security and need to be agreed with federal security agency. And legislations states enforce as the 1st November of this year, but since no work has started at least publically, Russia pretends to be European country, so all regulator documents and orders of governments need to be first published, publically discussed and only then they can take in force.
More regulator subjects introduced by this law. First of all, Internet Exchange point, Internet Exchange point need to register somehow. It also must connect only entities which comply to this law so installed lawful equipment, and also, Internet Exchange point must comply requirements security requirements and stability requirements which will be said by regulator and security regulator. National domain names system is being introduced. One of this part is a list of domains of special interest and another one I have mentioned it, requirements for domain resolution equipment, hardware, software, whatever else. More information needs to be provided about cross‑border telecommunication systems. Now Russia have requirement for licensing construction works of telecommunication line through Russian border. Now, a lot more information need to be provided.
And the discussion also especially at human right communities about, is about special technical security measures, so special equipment which had to be installed by operators on international links between operators which will ensure security and stability, but people think that we must affect more, that at most it will be effective transition system because current blocking system is not works well.
More questions about how the state will execute this law. We don't know yet because regulator documents need to be redone but it might be enforced routing registry, like most proposers in Russia was talking for years and at a RIPE meeting in Copenhagen I was worrying about works which run from these things. Maybe BGP, something else. Maybe Russian post will send an order via snail mail.
Possible negative impact: Internet is successful in self‑regulation. Since, well more ‑‑ at 1986, until new multi gigabit DDoS attacks, Internet keeps sustainability, it works as whole and successfully, maybe sometimes could not work, but with controlled centre, it appears that one single point of failure could appear.
At the time of implementation of content blocking system, we seeing some of blockings were leaking and some routing register. This law allows government to interrupt business processes, the invisible free market which let grow Russian Internet will be approved. Actually Russian Internet, until last year, was the second biggest Internet in the world by routing entities. First was US, second was Russia and third was Brazil. Now with introduction of set of new regulation, in Russia, Brazil overtakes. The growth of Russian Internet have stopped and Brazil overtake Russia.
In telecommunication law, in Russia and I think in all the other telecommunications telephony laws, there was a special article named "public network management in emergency situation". Now, emergency situation replaced by "special cases" so it will not been really emergency, for Internet and telephone it would be controlled. Of the first document that government shut down of Internet governmental shut down was also done in Russia under this article. But there are some bonuses for operators. It is said that the responsibility before customers in case of outages caused by control centres is waived, and technical security measures, special equipment for ensuring stability and security and maybe censorship, in some cases will be installed not on operator's account but on account of the state.
Well, you listen to me. And you might ask a question how Russian Internet survive? Well, this European principle from ‑‑ does not work in Russia. Severity of Russian laws is compensated by non‑obligation of execution. And no, really. it's very popular Russian saying. I just tried to translate it. And you should mention that Russian laws are not written to be enforced but they're written to make you guilty, just to make a great source for corruption for officials law enforcement and others.
Some notes of budgeting. For years, Russian regulator and Ministry of telecommunication dreamed to repeat some job done by RIPE NCC. They will ‑‑ they want to know everything about routing, they want to know everything about IP addresses and autonomous system numbers usage. Most of this drop is effectively done by self regulator organisation, RIPE NCC and when looking on how much that work could cost you may book at a budget of RIPE NCC, this is proposed budget for the first year for creation of control centre. So you may compare numbers, I think, but RIPE NCC is much more effective, even and much more costly in Netherlands.
Why it's important for you: Russia is ahead of regulation of the Internet, ahead of the whole world because you see New Zealand created requirements for lawful intercept in 2013. We have it, I think, since 1993, so if Russia have done it your government may decide it also can repeat it.
Internet is global, we have seen that attempts of blocking content in some countries have leaked outside and caused some disruptions. And yes, you can't immigrate your from this planet, Russia is your neighbourhood. So you have good neighbourhood anyway. So if you have more questions, please ask now and maybe well ‑‑ I am available the whole week. So, questions?
PAVEL LUNIN: Questions? No questions. It's clear.
(Applause)
We are going to ‑‑ going ahead to the lightning talks and the next speaker is Shane Kerr, the RIPE NCC are not the routing police, yet.
SHANE KERR: All right. Good afternoon everyone. We have seen some presentations about ‑‑ from actual police and about controlling things going on in the Internet. And this is a lightning talk just to raise awareness about some discussion that's going on in the Anti‑Abuse Working Group.
So first of all, let me preface this to say that I am going to be talking about policy proposals that I didn't make. I haven't talked to the proposers of these. I haven't talked to people that have been involved in the discussion very much. I had to apologise to one of the co‑chairs of the Anti‑Abuse Working Group for not consulting in advance. But I think this is really important for the whole community to be aware of. So I decided to just throw it in as a possible lightning talk and here we are.
So, this is about policy proposal 2019‑03, which is titled "BGP Hijacking is a RIPE Policy Violation". And you can click on these links on the slides and read the full text of the policy proposal yourself, you can also follow a link to find the very long threads on the policy discussion list, the anti‑abuse list for this policy being discussed.
So in summary, my understanding is that it's a way to try fight this abusive behaviour of people hijacking routes, and the way that it's done is, basically, that RIPE NCC already has a contract with each of the LIRs which says you have to follow the RIPE policies. And this attempts to leverage that existing contract by modifying the policies to say that hijacking is a violation of that, and then the RIPE NCC would be empowered to basically punish people for violating the terms of their contract if they did the hijacking. So that's the idea.
And there's a few corner cases around how this is supposed to work, like how do you know that a hijack has happened; it involves creating some kind of outside consulting people to verify or advise the RIPE NCC. It's a little bit vague and also quite specific in other ways. Now, you can imagine, if you know anything at all about the Anti‑Abuse Working Group or the RIPE community in general, the kind of friendly, open, transparent conversation which happened after that. Of course, everyone immediately started attacking people saying they are acting in bad faith, saying they don't know what they are talking about, attacking people's character, and making all kind of wild accusations and so on. What did I say? Anyway. So here is a summary of some of the threads that happened there. People were saying: Is this even possible, how do you know if a hijacking has occurred? Even if you are able to identify these things will it help because there is going to be a time delay and these are very time sensitive? Is it legal? Like, does the RIPE NCC have the power to make these kind of changes? And what is the role of the community?
As I said, there is this notion there is going to be this outside group of people consulting on it, and there is the questions about this is obviously going to put a lot of burden on the RIPE NCC beyond what it already does in terms of its existing activities, will the regulators of the world and the governments allow this kind of ad hoc justice that is arising out of the community?
On the other hand, there is this abusive behaviour on the Internet and we are supposed to be bottom‑up Internet self‑governance, self‑regulation, if we are not self‑regulating, is there a danger the governments are going to do something if we don't do this? This is a small summary of all the discussion that has been going on here.
And the reason I wanted to have this lightning talk is because I think that the discussion here and outcome of this discussion could matter for everyone in this room and far beyond, even though the discussion is being held in the Anti‑Abuse Working Group it's ‑‑ the impacts are not limited to that set. It certainly touches anyone who is interested in routing, this is ‑‑ I mean it comes out of the routing world. People in measurement because again the question is how do we measure this and know it's happening. It currently affects the RIPE NCC Services Working Group because there is going to be a cost to this and policy and staff and things like that. It also affects cooperation but ‑‑ because at least of all the discussions that I pointed to earlier in terms of regulators and governments and of course police and other kind of law enforcement agencies and things like that. And this discussion, in my mind, gets us to some central issues about our community and what we are doing here, who is RIPE, who is the RIPE NCC? What are the rights and responsibilities of everyone involved here, the LIRs, RIPE NCC itself, us as people involved in these policy discussions.
So, I don't want to discuss the policy at all here, but I think it's important that everyone be aware. If you have time, I highly recommend going to the Anti‑Abuse Working Group, if not go ahead and check it out online on the mailing list.
Now, since I submitted this lightning talk, there was another policy proposal sent to the Anti‑Abuse Working Group, 2019‑04 called the "Validation of the abuse mailbox" which is again an Anti‑Abuse Working Group discussion and again we saw the predictable chaos of people think that is crazy idea and we have to do something. And I am seeing almost the exact same outline of the discussion going on in the separate discussion, and I think part of it's coming because there's a disconnect between the wider anti‑abuse community and the sort of industry group that is the RIPE NCC, membership based, and part of it is because maybe we have reached to the point where all the assumptions that we made about what we can and can't do and how we should be governing ourselves, are starting to break and maybe things are different now than they were 20 or 30 years ago.
Anyway, that's it.
CHAIR: Thank you.
(Applause)
We have exactly three‑and‑a‑half minutes for questions. Lightning talks are ten minutes including questions.
AUDIENCE SPEAKER: Author of policy proposals. Thank you for alerting the people because I think it's interesting to get as much people as possible involved in this discussion, thank you.
SHANE KERR: Sure. You are welcome.
SANDER STEFFANN: I think it's important that we have these discussions because I am pretty sure law enforcement will do something, if the economic impact, the social impact the Internet has on everything is quite important, so I think they will do something. I don't think it's the place of the RIPE NCC to start playing police. But we have to find some way because we need ‑‑ my personal feeling is, I think we need to help law enforcement do their job so they don't mess with our job. But it's a ‑‑ it's a rough idea, it's not a solution.
SHANE KERR: Just a quick comment: I have tried very not to put any of my own opinions in these slides. So I apologise if it seems like if I am saying something is good or bad. This is just a wakup call.
RUEDIGER VOLK: Sander, you are calling for actionism, that's a really bad idea in direction. And, yes, well, okay, cooperating with law enforcement, my understanding of German law is that messing around with the routing system quite certainly is a punishable action, kind of the question whether law enforcement is actually able to deal with it is an interesting question and I doubt that this community is able to do the job of the law enforcement better than the law enforcement. What this community ought to do is to attack the problems on the technical side, and for you I would like to ask, you were saying, well okay, something like that sounded, you were kind of saying well okay, this chaotic approach of stuff seems to be a characteristic of the whole abuse dealing community, is that true?
SHANE KERR: Yes.
RUEDIGER VOLK: Well okay, then we should really send them back.
SHANE KERR: Although maybe Brian has words ‑‑ I think we are out of time.
CHAIR: 28 seconds.
BRIAN NISBET: Co‑share of the Anti‑Abuse Working Group. Thank you for the wonderful ad for our Working Group session at 9:00 in this room on Thursday morning. And also the great summary of the discussion, you know, I will be contracting you for that work. But also please remember that if it isn't on the mailing list, it doesn't happen, so that's where the discussion needs to take place. But we will be discussing it on Thursday morning and there will be more information on the mailing list as well. But this is a really important thing and thank you so much for raising it in the plenary.
SHANE KERR: Thanks. See you at the discussion on Thursday everyone.
(Applause)
CHAIR: Thank you. Just to remember lightning talks are ten minutes, if there are five minutes of questions and there are five minutes of talking. Our next speaker is Sander Steffann from the NOG alliance. He is going to speak about that of course.
SANDER STEFFANN: Thank you. So, what are we doing? We want ‑‑ we looked at what was happening with NOGs all over the world and we were like, okay, there's so many things that they could use help with, let's do something. So, we started a new foundation called The Global NOG Alliance to help network operators and NOGs to organise good events, simulate communities, stuff like that.
So, nice logo, Global NOG Alliance. So who are we? The current board initialal is the Chair, I am currently the treasurer and secretary, which is kind of useful since we are registered in the Netherlands as a foundation so it's useful to have a Dutch person on the board. Rene Fichtmuller who is a board member and extremely active in contacting NOGs and finding out what they need, helping them out, looking for solutions.
So, what are we doing? We are supporting NOGs all the around the world and encouraging cooperation, but also we are looking at common things that ‑‑ like every NOG is reinventing the wheel at some point, so we are looking at, okay, how can we just solve this once so that people don't need to spend a lot of time with all the technicalities of running a NOG.
So we are bringing together network operators and the thing we started with, the first question we got was, we want to organise a NOG but you need to have a website which is usually word press and you need to install security updates and all of this is detracting us from the actual community work we are trying to do, so could you help us host a website and host the tools that we can use, for example, for called for papers, agenda planning, all that kind of stuff. So that's what we started doing, and currently we have GRNOG and the Angola NOG, and a group called the Women in Tech in Gambia who are ‑‑ who asked us to help them out. So those are the current groups that we are helping out with, with this. And yet we are looking to ‑‑ we are not look ‑‑ we are really doing everything bottom‑up. So we are not going oh we have this, use this, we are really looking at, okay, what needs are there, what can we do and then when we see that something is a common need we try and define a solution. That way if somebody wants to start a new NOG we can hand them, with the experience we have, we have a basic set, we can customise it for you and get them up and running as quickly as possible.
So, with all this, of course working with all these NOGs we gather a lot of information so we are ‑‑ we are looking at spreading that, and making sure that NOGs can learn from each other. Some NOGs are in really isolated places. Last year I was in Sudan and it's very difficult for them to travel because of all the economic embargoes, it's very difficult for people to go there. So basically they are kind of disconnected so just helping them, informing them, these are the things that are going on in the world, is already helping them and advising them on what speakers and what subjects would be interesting for them, can help them. So, all of these things we are trying to do. We are trying to get some best practices, how to run an event, which things have we tried and what worked and didn't work, just to make it a lot easier to run a NOG.
And like I said, we are trying to find some common problems and solutions for those. For example, called for papers, what tools do you use to send the call for papers to get people to upload their drafts, have the Programme Committee work with them. So already we are talking to different people, like also the RIPE NCC because they developed the Programme Committee tool for this community and see if we can make that useful for the wider community and also other NOGs use that and benefit from that.
And places where tools are not available, we are looking at what we can develop or how we can piece it together from existing components to do stuff like single sign‑on for all of these tools so it's easier to use, all these kind of things. So, we are really just looking for places where we can help out.
So, that's what we are doing. Sounds good, right? I mean, for me, I usually ‑‑ it's a no‑brainer. Like, these things, people can use some help, and whether you install a event management tool once or 50 times, you know, doesn't matter that much. So for us it's really easy, we just install it and everybody can benefit.
So, what we did, we registered as a foundation in the Netherlands. We are working with some NOGs to identify what they need, hosting it for them, and basically any, any NOG anywhere in the world that wants us to help them, we are there.
At the moment, we have exactly zero funding, only the money I personally put in because I thought it was important to do. So we are looking for sponsors to do a bit more Open Source development, developing tools, helping people build their communities.
So, like I said, we don't have any funding yet. We would like some to provide better tools, better services to all these NOGs. Also, help them find training material. There is a lot of stuff available so we are not looking at writing new training material but looking at helping NOGs find the right material for their needs.
So, how could you help? Provide input, give advice, share knowledge, Open Source development actually we are looking at some tools. And like I said, we try to do single sign‑on integrate everything to make them easy to use so definitely can use some help there. If anybody wants to provide sponsorship that would be great. And of course motivation, like speak up, let us know what we can help with.
And this is our e‑mail address. And please help us out. We are trying to do a good thing.
(Applause)
AUDIENCE SPEAKER: Hello. Costas on behalf of the GRNOG board. We want to thank you for this effort. We are one of the three initial NOGs. We are not there yet in terms of our needs, we don't have necessary tools yet, but we really hope this takes off and we really wish that you are here five years from now, as you said. Thank you very much.
SANDER STEFFANN: Thank you.
PAVEL LUNIN: Is there anything that has already been done?
SANDER STEFFANN: We have some done website design, web list hosting, we are hosting so those things are already going on, we actually only got founded like in January or February of this year, so we are still in the start‑up process but yeah, those are the things we have already done and that we are currently deploying.
PAVEL LUNIN: Okay. Thank you.
AUDIENCE SPEAKER: Colin ‑‑ I think this is a great initiative. I had a look in your website. Do you have list of all of the countries where you are active or all of the NOGs you are liaising with?
SANDER STEFFANN: Just the three I just mentioned, so it's ‑‑ like I said, we are just starting, but we definitely will, and if you are looking at all the NOGs that exist, RIPE NCC actually has a really useful list of the existing NOGs. But for us we just started with those three.
AUDIENCE SPEAKER: Wonderful, best of luck.
PAVEL LUNIN: Thank you.
SANDER STEFFANN: Thank you very much.
(Applause)
PAVEL LUNIN: Brian Nisbet on RIPE diversity.
Amanda: Joint effort.
BRIAN NISBET: I am Brian
AUDIENCE SPEAKER: I am Amanda.
BRIAN NISBET: And we are currently the two representatives of the RIPE diversity task force who are up on stage right now. For those of you who may not be familiar, the task force was formed a number of years ago, we are an open task force so the mailing list is open, anyone can join and contribute and the whole idea is to increase the diversity of RIPE community, RIPE meetings, the mailing lists, all of those things, across all of the intersectional areas of diversity that we want to improve our community.
So, the main piece we are talking about today is the new version of the Code of Conduct that we want to present to the community for your input and ultimately, hopefully, for your approval. So, the open ‑‑ the open task force, we have been reviewing the existing code of conduct. We want to look at that and widen the scope and strengthen the text. We have had lots of really great input already and the Code of Conduct, 2.0 as we are calling it at the moment ensures that all the people at the meetings on the mailing lists are aware of their expected behaviour, are aware of the consequences that a violation results in, and proposes a Code of Conduct response team to take the dealing with those hopefully very rare infractions away from the sort of nebulous groups that it is at the moment and make sure it's not down to the NCC or the Working Group chairs or other kind of things in a very kind of unregulated, for want of a better word, manner.
AMANDA: Also we currently have RIPE meeting trusted. And this is very different in scope so the trusted contacts have been in place for quite a few meetings now, and and that is like a safe space to talk about the things that maybe are ‑‑ people are experiencing at the meeting but they don't currently have a mandate to ‑‑ to have consequences if there is a violation.
BRIAN NISBET: And none of this changes the fundamental philosophy of where we have been going with the Code of Conduct over the last few years. It really is just improving it and best common practice and Sascha came on board in Amsterdam really and the last meeting and have provided huge amounts of really great input along with a few other people, for this, to kind of bring it up to where the best common practice with codes of conduct are.
So, again, the goals don't change, we are still looking at the Code of Conduct. Expanding the text to try and make it crystal clear insofar as is possible with these things because we don't want anyone to say I didn't know. But again, the flip‑side of that is we want people to be able to read it and clearly understand how open the community is and how welcome everybody is because again that's the purpose of a Code of Conduct. It's a big placard saying we want everyone to come, everyone is welcome, and this is a space in which we can interact in a safe way.
So, I think ‑‑ yes, I mean, and this is what we want to say. We have got the next steps. We are going to ask the community for comments. We are not ‑‑ and I am going to say this out loud because we are a community that tends this way ‑‑ we are not looking for line‑by‑line wordsmithing of the document, but we are looking for comments, nor are we saying this is in violet, we are going to send out the URL which is there and you can download the slides and see it now, of the current draft, which is on the RIPE website and then take the comments and incorporate them, see where we are with that, work out some more of the process around the Code of Conduct team, ask for volunteers for that team as well and, ideally, aim to have things in place for RIPE 79. We are a little bit behind on where we wanted to be timewise but the aim is top the new Code of Conduct in place for RIPE 79. And that's kind of it, really.
So I will go back. So I will leave that URL up there. But it is the ‑‑ the slides are there and we are going to send it to the RIPE list in the near future.
CHAIR: Thanks.
BRIAN NISBET: I know none of you have seen it yet, but if you have any comments or if anyone wants to suddenly volunteer to help, then this is an awesome moment to do so.
AUDIENCE SPEAKER: Maybe it's more common that it was based on existing policies that have been in place in multiple conferences before.
BRIAN NISBET: Yes. As we said, this is definitely best common practice across a variety of conferences and events.
AMANDA: So specifically the Jango Code of Condut was one of the ones that was looked at and the right the docs communities, that's where Sascha has a lot of work and the a lot of the content has been based on.
AUDIENCE SPEAKER: Malcolm Hutty, for disclosure I have participated in some of the discussions of the diversity task force on the subject. I think that etc. A great idea to be, A clear that people need to speak in the way that is respectful and avoids the kind of bad behaviours that would want people not to be part of this community. In terms, however, of how the current draft achieves that I think it was open to the criticism that some of the statements as to what is acceptable, do not give any meaningful clarity or guidance to either people that are participating or to those that have to adjudicate on complaints. They are essentially ‑‑ I think it's open to the criticism that some of those standards are really so woolly as to be really pretty irretrievably subjective and that much more could be done to turn it into something that really guided both sets of parties. That would be the first comment.
The second comment is in terms of process. The proposed process says that either those that are the victim of alleged violation or anyone else, should be able to make an anonymous complaint to the response team, but the code does not set out any expectation, well requirement, for clarity to be given to the person about whom the complaint has been made that would enable them to engage in any meaningful fashion with the response team on that complaint. It rather simply contemplates that the response team would make a decision and then tell the person who was the subject of the complaint what's going to happen to them as a result. That's what's set out at the moment; that maybe is not what is intended but that's there in writing. I think that process could be developed more fully so to allow for a meaningful discussion and prevent the possibility that the Code of Conduct itself could be used as a vehicle for harassment.
AMANDA: Great feedback, thank you. I think that the text or I am pretty sure the text says the Code of Conduct team would investigate the complaint, so I would imagine that that would involve engaging with the person who reported it and if it's anonymous it usually will come in some form of online communication or they might just state that they do not want to be identified. So, if we need to make that more explicit in the text then we can certainly do that.
MALCOLM HUTTY: I would suggest that it is normally considered best practice in grievance disciplinary matters that it is a requirement on those that are sitting in judgement to engage with the person who is the subject of that complaint, in advance of making a decision, to give clarity as to what it is that they are said to have done, as well as in how that is said to infringe against the established norms. And to give them a clear opportunity to be heard before a decision is taken. None of that is now currently reflected in this code.
AMANDA: Okay. Can you also share this on the list?
MALCOLM HUTTY: Certainly.
PETER KOCH: I have two questions, one is I followed the link and I think I missed the red line version of the text. Is that because the text changes are so overwhelming that it wouldn't help or could you provide one?
AMANDA: It's a completely new page so the existing Code of Conduct is there and then there is an additional page with the new conduct; it's not a track changes.
BRIAN NISBET: I think as you say,Peter, it is a very large ‑‑ philosophically conceptually from the same place but the text was written wholly newly rather than as a modification of the previous text. The previous text is very short, so there isn't a red‑line version, is the short anwer.
PETER KOCH: So that brings me to my second question, on the process. So we do have a PDP for policies that govern RIPE. We have been talking about them. Can anybody enlighten me on how this particular Code of Conduct or whatever changes it is undergoing is supposed to come into effect governing the behaviour of, I think at least the attendees of the RIPE meeting?
BRIAN NISBET: I think again, I suppose what we have said is, we are going to put this out, we have discussed this with Hans Petter, who seems ‑‑ and he can obviously answer for himself and make sure he is okay ‑‑ but broadly happy with the approach we are taking at the moment, which is that the task force will present this to the RIPE list and to the plenary for discussion and input. But he is behind you, so maybe he can give a better answer than I can right now in regards to that.
HANS PETTER HOLEN: RIPE chair, and thank you, Peter, for raising that point because I think that's an important point for this community to think about, what document should go to the PDP. And this document is definitely something that falls into a category that needs a formal process before approval. So one way of thinking of this is that this is actually in discussion phase at the task force list, if you are interested in participating in that discussion join the task force and take part in that discussion. When there is the stage where you think it is stable then we call for consensus and we do that on a wider scale.
Same kind of process that we followed for the RIPE chair document discussions as well. And maybe this is the start of actually writing down that this is the process that we should follow, also for this kind of documents, not only the IP Address Policy documents. But we kind of have a situation here that we have a transition to do it like I am sort of saying no, but waving my hands. But we haven't kind of written it down with check marks yet.
AMANDA: Thank you.
DANIEL KARRENBERG: I might sound like a broken record but I think once that process has actually evolved, this should become a RIPE document.
AMANDA: Thanks, Daniel.
CHAIR: Okay. Thank you, Brian and Amanda.
(Applause)
And before we end this session, let me remind you that we have two parallel sessions here from 6:00 to 7:00, the first one is the RACI session at main room, this same room. The second one is the BoF of the RIPE chair selection process, it's in the side room, and this evening we have the networking evening at 9:00. The buses will leave the hotel at 8:45 and return every 30 minutes from 11:00 to 1:00. Please rate the talks and vote for the candidates and enjoy your stay here.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
