Archives
Routing Working Group
Thursday, 19 November, 2015, at 9 a.m.:
JOAO DAMAS: Hello. Welcome to Thursday session in the morning Routing Working Group in this room. If you want the Cooperation Working Group, that is in the other room. So we have kind of packed tight agenda today, I would like to start with admintive and get it out of the way as soon as possible. The Chairs today for this Working Group are Rob, who is here in the first row, and myself, Joao Damas. So if you have any issues or suggestion about the Working Group, please feel free to contact us, preferably after the secretaries. We have several support staff are going to help us, of course the RIPE NCC staff that make it run smoothly, we even make it very hard for them. Our stenographers who make it easy for everyone to understand what is going on. For online and remote participation we have webcast run by Marco and Micheala, and thank Anand for taking the minutes, does a very good job about that. The minutes from RIPE 70, we formally usually approve them at the following meeting, this one. Does anyone have any issues with what is published? I guess not. So straight to the agenda. There are a few changes last minute, so all the talks are there in there, just in a different order. So the agenda, there are a few changes. Actually, the one you see there, Alexander is in second, which was the original order and we will start ‑‑ if you could come up, we will get this thing going.
LUCA SANI: So, good morning, I am Luca Sani, from Research Council of Italy and I am going to present you with Isolario. Our research interest is analysis of the Internet inter‑domain routing structure and usually this kind of analysis is carried out exploiting BGP data provided by route collector projects, PCH, route views. This kind of analysis ‑‑ it is also well‑known that it is far from being completely representative of the Internet inter‑domain routing structure. The main cause of these incomplete, the fact only a small amount of autonomous system are currently feeding one of these projects. One of the possible motivations of these participation may be not all network administrators are interested enough in sharing their information with these projects.
With the aim to make at least some of these network administrators to change their mind, we created this Isolario. Indeed, Isolario is a route collector project based on the give to be given, network administrator that decides to share his routing data with us, we will receive change set of services, in particular a realtime monitoring services of incoming BGP data into Isolario system.
The main aim of Isolario is to contribute to the completeness of the available public BGP data set. In this sense we are currently providing BGP data in MRT format like every other route collector project do and in the future we are planning to provide some information extracted from this data, for example, AS level topologies, AS characterisation and so on.
The starting point to implement realtime services is slight modification of the of the ‑‑ when BGP data arrives into Isolario system it is sent to dedicate I had module, dispatcher which splits the flow into two parts, one end data is enter to route collecting software, responsible for maintaining routing table per feeder, and the responsible for dumping periodically the data in MRT format. On the other hand it is sent to dedicated modules which implement the services.
The route collecting software is particularly important because it must also be able to respond to realtime queries coming from realtime applications, for example, it must be able to retrieve a portion of the routing table of a given feeder.
So this is the big picture on the system. Partial results computed on route collectors are aggregated where needed in the core of the system, and final results are provided to the user through our web server exploiting the web socket protocol. So, this means that when a user wants to use Isolario services to connect to the website, login, choose the service and then results will be shown to the user and on the browser as soon as they are ready.
So now, I am going to present you some services that are already available on Isolario website and some services that will be available soon. The services can be divided broadly into three categories: Realtime services and historic services and diagnostic services.
As the name say, realtime services are the services that allows a user to monitor realtime, BGP data coming into the Isolario system. The first service that we developed of this kind was the routing table viewer. With this service a user is able to insert a portion of IP space and see the evolution in time of the route that its feeder is announcing to Isolario to reach that portion of IP space. Results are shown in the form of a table and are correlated with different kind of statistics, for example, an interesting statistic may be the AS dependency which indicates the most important autonomous systems for that feeder in order to reach the inserted portion of IP space.
Another interesting thing that a network administrator may want be to be able to monitor is if and which routes are currently experiencing flap events and this is fed by another service, the realtime flap detector. A flap is detected by a sequence of events happening in a given time span. Again, the information displayed in the browser is correlated with some statistic, for example, the average number of flaps per second, as well as the distribution of a flap type, for example, if the flap is the consequence of different announcements or alternation of announcements that we don't accept them.
Maybe, the most interesting service is the subnet reachability service which enables a user to specify a portion of IP space and see in realtime the evolution of the routes that all the other feeder Isolario are using to reach that portion of space. For example, if you use this service inserting one of your subnets you will be able to monitor reachability. In this sense, the AS dependency for example, takes another meaning, because it indicates which autonomous systems are the most important for you in order to be reached by the rest of the Internet. So, of course, the more feeder is useful this kind of service.
In order to ease the visualisation of BGP data displayed in these application, recently we integrated it with the realtime version of BGPlay. BGPlay is well‑known tool for the visualisation of inter‑domain routing and has recently been released in its realtime version, thanks to working at RIPE NCC we managed to integrate it into this service.
So, basically, this is the main view of BGPlay. Red nodes represents the autonomous system reflecting the ‑‑ and then connected to the collector, in this case the feeder of Isolario and black nodes represent all the other autonomous systems. When a BGP announcement occurs the creation of a new path creating a set of nodes is animated and from now on each routing event involving that path will trigger animation specific to the event type, and assembling transition to the new status. Paths not involved in any routing change are represented by dashed line while paths involving ‑‑ one routing changed are represented by straight lines.
This approach I liked the difference between what is stable and what is unstable. And the version of BGPlay that we integrated in Isolario use as input data coming from our web socket stream, but since BG splay an OpenSource you can adapt it to take whatever input, to have more information about BGPlay you can visit the project website or ask Massimo, which he is here attending at the meeting.
Another class of available services on Isolario is the class of diagnostic services. These services exploit either realtime BGP data or collected BGP data in order to highlight anomalies for the user to be directly directed on Isolario website. For example, the alerting system enables a user to receive notifications whenever a routing event matching one of alarms happens, so using the alert system the user is able to set up different kinds of alarms, for example he may be want to be informed when his feeder is announcing to Isolario a route to a particular destination and passing through sequence of autonomous systems of interest. Or maybe when one of his networks is being announced by a non‑legitimate origin, notifications are sent to the user in different ways. If the user is connected to the Isolario they will be displayed in the browser, or they will be sent via e‑mail or again http to customer server.
On the other hand, the daily report is service which exploits all the collected BGP data from all the route collector projects in order to form deep analysis of the router domain status, in order to highlight anomalies that may go unnoticed. The daily report is a service which produces a document once per day containing information that is totally customable by the user. The user may want to include information from stability of routes and having data about the most unstable routes or the characterisation of the reached IP space by his feeders, or again, how the inter‑domain routing perceives his home networks.
And the last class of services that will be soon available is class of historic services. Again, these services exploit data collected by all route collector projects. In order to provide services that should ease the work of a network administrator in terms of troubleshooting, at least that the inter‑domain routing level. For example, these services will be the historic counterpart of realtime services, so, you will have historic route be table view as well as historic subnet, needs to help the administrator in his work at this level.
So in summary, this is what Isolario user can do using Isolario. He can check realtime if something is happening, checking the realtime applications. It can be ‑‑ he can be informed in realtime if something is happening, thanks to the alerting system. He can understand if something happened the day before reading the daily report, and can troubleshoot these anomalies soon with the historic services.
So, that's about all. I would like just to point out that Isolario is nonprofit research project and we are doing this to contribute the completeness of the public available BGP data set. So, if you want to participate, please do not hesitate to contact us. And I think that's all. If you have any questions, they are welcome.
(Applause)
JOAO DAMAS: So, any questions for Luca? I have one. Is the LAN to continue this project going on stage time for a long time or merge it?
LUCA SANI: Yes, our institution is support it.
JOAO DAMAS: Great. Thanks very much.
(Applause)
Next up is Alexander Azimov, please.
ALEXANDER AZIMOV: Good morning, I am head of network division at securitier labs and going to have a small talk its consequences of ‑‑ on our community and our vision of possible solution.
So, speaking about BGP, BGP is quite simple. So, it consists ‑‑ BGP decision process consists of a dozen of different attributes plus some configuration options, the flexibility it provides and it's cool to ‑‑ this flexibility of course is supported by a few documents. BGP was made extendible and there are a few extensions that we are waiting for, a good example is here is BGP Sec and we are waiting for it for a few years but we will never lose our hope. But do you ‑‑ any of you think that it is quite simple for a newcomer to get acquainted with this subject? Unfortunately, there is no simple way. But, at the same time, you don't need a lot of time to write down these four streams and get a running BGP session, and in case of Stab network it will work fine. So, this is the great BGP problem. The expectations of newcomers doesn't even nearly ‑‑ furthermore, it works fine for a while so this is most confusing. The problem occurs as soon as such newcomer tries to establish one more BGP session so he copies his previous and starts linking. ‑‑ leaking. We have very simple definition of route leak: Occurs when the route learns from provider or peer is announced to another provider or peer. And in this case, newcomers network of course would be affected by additional amount of traffic, but it will also affect our network too, and so from this point of time, this gap in expectations of newcomers becomes our problem.
And this gap have already grown into a very big problem. As you can see in the graph, every month thousands of prefixes are leaked, despite ‑‑ it's October ‑‑ the spike in October is a death leak when some newcomer have leaked full table were one provider to another. Have you mentioned that you have some kind of local service for ten minutes ‑‑ and I believe you can have a one reasonable question, who is the leaker? So, there is about 1,000 autonomous systems with bad designs configuration files that affect all of us, and more than half of them are newcomers, and we are not prepared, so the number of leaks grew up from 30,000 participants in 2010 to 50,000 participants at 2015 and there is no evidence that this trend will have any change in near future.
So, to fuel the situation, just imagine yourself on a highway, full of drivers that have never passed any examinations. Will you feel comfortable? I don't think so. So I believe we have only options how to overcome this problem:
First one is of course regulation. We could established BGP exams, we could have BGP police instead of BGP policy. Maybe we should establish BGP jails but I believe we have enough will to avoid this option.
Second option is to create a new BGP extension, but before starting to create we need to give yourself a question: What we expect from this extension? I believe that instead of, today, BGP flexibility to do everything you want, it should provide guidance, guidance to newcomers, to help them to provide ‑‑ to create a robust configs, and just as we have now built in protection against route loops in BGP we should also have a built in protection against routes. To achieve this neighbour roles, there are four simple roles that should feed all possible pairs of BGP links, cast, provide and internal links. At the edge of your network a role marker is is set and it's transferred through your network without any change, and when there is extra filtering to another autonomous systems this marker is used to automatically find out if the route was launched by a provider or peer then don't announce it to provider or peer. So that is all. We believe that this configuration options should be ‑‑ become mandatory, so without setting a role in config the BGP session should never become active, this guarantees the existence of a role but not its correctness.
To make it correct, we have also added information about the role in open using capabilities. There could be only three appropriate pairs of roles and if neighbour gets the wrong one it sends notification. This gives you an opportunity to control appropriate role of the newcomers, so it's just a backup, so ‑‑ you are able to control your neighbour in automated way.
We also propose a strict mode, by default if neighbour doesn't support roles the BGP will establish and there will be no filtering and no ‑ strict mode your router will send notification if the role is not set at your neighbour BGP session. This, I believe, should back mechanism of motivation to use this extension of BGP. And maybe, sometime later of course, these modes should be set as default.
So, let's take one more look at our newcomers config, we have added only one stream and now there is no leaks at all. So, what was my talk about? We propose a simple extension to BGP that should eliminate leaks that are made by mistakes. For are newcomers the gap between expectations is still be big but it will become less, for all older and wiser players it will give an opportunity to help newcomers in automated way and also, guarantee that the mistakes of foreign parties will stop affecting their network. I would like to highlight one more thing: This technology will not reveal any sensitive information about your business except to ‑‑ your neighbour and I believe your neighbour should know some details about your business with him.
So, here are some useful links. We have already implemented this idea as a BIRD routing Daemon, you are free to using it, of course ‑‑ use it, cooperate and also route it, it has full back up compatibility with current classic version of BGP. We are also going to collaborate with IETF but this will took ‑‑ take place in the near future. Thank you very much for listening.
(Applause)
AUDIENCE SPEAKER: Warren Kamary, Google. Gerard and Job Snijders wrote a draft recently which does something similar: By default routers should neither accept nor send routes until you have configured a policy, that seems to 99 percent of what you are trying to do with no real changes?
ALEXANDER AZIMOV: It's true, there is a draft that trying to force the route leaks, it was a concern to us first published at the middle of summer, and it is very interesting that we have started our work just at the same time before it was published. I have reached their last version of it very near but it's different. For example, there is no work with open messages. We have in some kinds different goals. In this route, the guys are trying to filter out leaks. We are trying to avoid them. This is some different goals. I believe that I will try to get in touch with these ‑‑ the authors of this as soon as possible and I believe that, together, the solution will be found.
AUDIENCE SPEAKER: I think Job is here somewhere, isn't he?
RANDY BUSH: IIJ. What this does is allow Brian Dixon's proposal for marking to actually work much more likely than the existing proposals. The difference is that if I am supposed to mark, oh, I am sending this to an upstream or to a peer, when I make the fat finger and send it the wrong place, guess what? I am going to mark it. Whereas negotiating it in BGP open means that both sides have to agree on the business relationship before the first route moves. The problem is that routing policy is sometimes on a per prefix basis, but what is interesting there is that the most common per prefix difference is when I am a global provider and I am in Amsterdam and I peer at AMS‑IX and I give Warren free European peering, European routes for free, and my global routes at a small. Almost all providers implement that today by multiple BGP sessions so that fits right in.
ALEXANDER AZIMOV: So it was not a question but thank you very much, Randy.
JOAO DAMAS: Any other questions? OK, thank you very much.
(Applause)
Next up we have Colin from the RIPE NCC.
COLIN PETRIE: Hi, good morning everyone. I work for the RIPE NCC and I am here to give some updates on the routing information service. It's just a few small updates on some things that we have been working on. One of them was that so we maintain the BGP dump utility which is MRT data parser for reading the RIS data. There is a few changes that we are making to it that may affect people who rely on the output format of the tool at the moment. We were adding support for some new types of data which were in the MRT specification but were never actually implemented in the tool. There is a few new features there that I will just skip through but just to let you know that if you are reading MRT files that contain these ‑‑ this data, you may have to adjust your tools that use BGP dump because the output format has now changed.
Just to skip through them. But this is what the output normally looks like. The first column indicates the type of data that is in the message, and basically there is now a bunch of new formats to tell you how to parse this. One of them is related to routes that are originated from routing collectors rather than received by them, and another one was support for having high resolution microsecond precision timed stamps on the messages. Then, there was another one that was related to a draft that had recently submitted to the IETF to add support for additional path support in BGP. And there was another option that was added to allow, to put put index that indicates for all the lines that are in the data, which ones come from the same packet, the same original BGP message, which is an optional flag that you can have at output.
Now, several of those, there are various different permutations, there is three main extra ones which gives you eight different combinations that the output format might now be in, the details of them are all there. If you ‑‑ if you are interested in the details, please download the slides, they give you all the information on that.
So, we just wanted to basically give everyone a headsup that we were adding support for all of these that weren't there before. If your tools rely on the data ‑‑ rely on the specific format that BGP dump outputs then you may need to update your tools.
Now, this actually led to a discussion internally about whether or not the current output format is a good idea, at the moment it's basically it's a compatibility output for something that was written about 15 years ago. And it stayed the same since then and we try and maintain it in roughly the same way but we did want to ask the question of whether or not it would be good idea to change the format and make it into something more modern and extensible. One of the ideas we had was to make it something like JSON output that then has a published schema with version numbers and things like that, which is easy to load into any modern programming language into a S son parser. This is an example of something similar which is the output of X A BGP which has a structure which mirrors the structure of a BGP packet as opposed to the existing output which is basically just a line by line text output which is easy to get on the command line but quite difficult to keep it to add and extend and adjust the format.
So, we were interested in any feedback as to whether or not people would like us to change it or whether they just want it to stay the same and don't break any existing tools.
Related to the extra support that we added in ‑‑ for the new type codes in BGP dump, one of them, as I said, was for messages that are actually originated by the routing collectors. Normally, the routing collector system only records messages that it receives from its peers but BGP is a bi‑directional protocol and we do send messages but those are never actually recorded. That means that we basically only have a one‑sided view of the BGP conversation, and one of the things that we were then thinking of was whether or not we should add support for recording the other side of ‑‑ of the conversation, so we have a complete record of the BGP transactions. And we would be interested to know whether anyone thinks that is useful or if it's just extra junk data that you don't care about and you just ignore anyway.
Now, another thing was the new RIS infrastructure that we had been developing just recently, now has three new route collectors available. One of them is in ‑‑ is RC 18 in Kath NIX in Barcelona, RC 20 in Swiss IX in Zurich and 21 in Paris and Marseille and the data for this is now available in RIPE Stat, it's available in various widgets and through the data APIs. You can see here it's got the new collectors here listed for the visibility statistics.
And the other I think that we wanted to ask about was, we had demoed ‑ dish demoed at the last RIPE meeting the new RIS architecture which has realtime streaming system that allows to you receive the BGP messages live. We wrote up an article about it to explain how the architecture works, and at the end of the article we asked for feedback on the streaming side of things. But basically we didn't really get much feedback on that so I thought I would take the opportunity to just ask again the same set of questions; again, if you want to check the slides, have a look or read the article. But we would appreciate it if you are able to give us feedback, if you do think that the streaming system is useful, how would you actually want it to work, what kind of system would you want, there is various sort of questions that we had about it, and we would love to get some input on that.
And that was basically it. We just wanted to share a few updates and if you have any questions about it, either at the mic or I am here for the rest of the week, please come and find me or send an e‑mail to myself or any of the mailing lists about this.
(Applause)
JOAO DAMAS: Any comments, questions?
AUDIENCE SPEAKER: Cava RIPE NCC. Just something related to the presentation as well because last meeting there was a question about expansion of RIS and there were a lot of support in the room. And we were thinking about moving this forward, but I have a few questions, basically two important questions which I will send them to the list but wanted first to get a feel from the room. We looked into the possibilities, we will definitely expand RIS anyway but that is just to cover a few areas which we know are not covered, for example, we don't have anything in Australia and New Zealand, for example. So we will add a few, up to maybe up to five new RIS collectors in well connected, ISPs, that is for sure. But what I understood from last time, that actually people want wanted a lot more and that brings two important issues, basically, brings up two important issues: One is it would be costly, especially storing all the data, which is fine, there is just a process which we have to prepare some cost forecasts, give them to the board, the board might approve them or ask the community either in a budget or separate vote, but it can be all done and we will do that. I just wanted to know what scale basically the Working Group thinks about the expansion; I mean, just a few more nodes and ISPs around the globe will be fine or you are thinking another 50 or 100 collectors, that is my first question. If I can have a show of hands ‑‑ I will send this to the list but I want to know do you think we, like, please raise your hand if you think we need more than 15 new collectors, let's say? Good. That settles ‑‑ I will send it to the list. That was one. And the second thing is, basically, I have been approached by few people saying that it's useful to have RIS collectors not only in ISPs or where you can get multiple peers but maybe even in an ISP where you can peer with one or two entities. That will change the whole model, and again, my question was, is this really something interesting because the model, RIS model, until now, was that we put ‑‑ we put them in the well connected places and get as many peerings as possible. I know that going to, for example, an ISP will give us different data, different view which might be useful but I don't know if the community really wants us to invest in that or not, so that is also another question. And I would love to see a show of hands if you basically think it's useful to also go to locations where we can peer with only one or two entities like ISPs?
JOAO DAMAS: Do you mean like try to go inside the ISP to have internal view of the routing or just be somewhere still get external view but only from an ISP?
AUDIENCE SPEAKER: Second one, yes. So anybody thinks that would be useful in the room? Good. That answers my questions, thank you very much.
JOAO DAMAS: Great, thank you.
(Applause)
And thank you, Colin.
So hopefully, the technical issues are OK. Can you come up, Ondrej.
ONDREJ FILIP: Good morning everybody. I will a little bit step back from the routing and I will talk about a router and one small router we have created in May. Before I will start just can you indicate me who does know anything about the Project Turris? I see, five, seven people. I will be a little bit quick then. This project was presented at RIPE 68 so if you are really interested in that, in the project, there is a video you can look at, started like two years ago and the fancy name of the project was project of shared cyber defence. What we meant by that, actually, we wanted to ‑‑ we have a company that is doing a lot of OpenSource stuff and research, and we know quite a lot about the ‑‑ network and wanted to know a bit more about the end user security, so what we did, we created roughly 1,000 pieces of home routers and wanted to give them to the end users and those routers run some probes, some data collectors, those report to us and we know a little bit more about what is happening at the edges of the network so we actually were trying to target three main goals: One was the security research, then of course when we are giving something to the end users we wanted to improve the security, so we hopefully gave them routers that are very good, that are secure and works very well; and with that, we wanted to improve the situation with the SO H O routers.
So we distributed as I said, 1,000 of them, and last year, or this year actually we distributed another 1,000 of them. We giving to people for free or one Czech crown, which is nothing, and with that, they have to run it for three years as a router for the main connection to the Internet. And the routers are quite good, it's quite powerful, so they can use it for some other purposes, it's not just a router, more a centre of the home, so they use it as ‑‑ run as some service in the bathroom or DDPT recorder or something like that, we wanted to make device that will be able to bring some value for longer period, so this is why we wanted to have devices that able one gigabit of traffic and using ‑‑ doing that, security analysis. The time ‑‑ the project started there was nothing like that on the market, so we started to create our own hardware and that how the router Turris was born actually, we created two versions of the router, one is called Turris 1.0 and one, not surprisingly, 1.1. There are no big differences, it's roughly the same hardware, the only difference is that 1.1 has use B 3 additional slots so it has more abilities but in terms of routing it's roughly the same, it's based on PowerPC processor and works very well and we are really happy with that.
So, what we are doing with that, I think the key feature of this router and what we believe makes secure is that it has instant updates, it updates automatically, whenever any like major threat appears, like Shellshock or whatever you think, there were a few of them, we could ‑‑ we were able to fix it in I think, hours and then ‑‑ rather than days, it was quick, so this router updates automatically, with did some ten major releases of Turris OS and look a lot of lessons from that because updating device, under your direct control it's not easy managing that but we worked quite quickly and still thousand people are connected so it's good thing.
Another thing which we were discussing when we started the project, because, you know, we don't want to touch people's privacy, we are not analysing what is happening on the LAN, local network inside the home. What we are only interested is the flows that go from to LAN to the Internet and on those flows we do some analysis. When we found out that somebody is doing something strange, for example, we see that somebody is skinning network from the local network we know there is something wrong and we usually try to inform the end user, hey, there is probably some virus, some worm in your device inside your LAN and the usual reply and which device is that? We tonight know, we decided not really touch that area. So we created a software called major dome mow which trance on the local part of the router and it collects where all the ‑‑ all those devices are communicating to, and with that, you can have rough picture what the device is doing. We created on purpose, for example, of the local smart TV case ‑‑ LG smart TV case and it was found out those TVs report to LG which programmes are looking at, it's quite interesting, you have a lot of devices and problem with those fancy name Internet of things you will have more of them, you should probably who they are communicating to, talking to and reporting to. So you can check it. This runs on the router, those information are not reported to us, this information is not reported to us but it stays in the router and you can use the local web interface to the router and see what are the results. So this is just an example, for example, of ‑‑ I think it's it's downloading a lot of e‑mail and it's communicating with Google and Amazon Cloud so probably some Android phone. And very interesting to see what other devices are behaving, what is your smart TV doing and what is, I don't know, sensor for something doing, you will see some unexpected results.
Another thing, and that is really related to security, it's very powerful device, so each of them can run honey pot and it can run honey pot foretell net and SSH so we have a lot, we collect information from. To make it easier for the users, if it runs on honeypot it's not run directly on the device but tunnelled to server cluster and then we can see on all devices what those guys are doing.
So this is example from, I think, August of, from my home, as you can see I saw quite a lot of attacks. This is an example how that Belgian guys was trying to attack my router, so we collect those information and we analyse the binaries that are sent to us and we are trying to track those BotNets. One example, one nice BotNet we found it's called ‑‑ consists from AS US routers. They are not using SSH for attacking telnet, that service is still alive, I was surprised and they are trying to log into your, whatever it is, into anything that replies on telnet. And they are trying some passwords and even on trivialial ones it was interesting triad minute admin and root root and login but they are trying non‑trivial passwords and they are trying, many of those devices are trying that so they are probably coordinated, they have some command and control centre and we found out about 32,000 of the devices so it's quite large BotNet, I don't know what that is good for and I don't know what is happened if the owner will decide they will attack something but it's quite interesting to track it.
Another things we do for tracking BotNets and trying to find out how they are related to ‑‑ to each other, is similar to ‑‑ similarity analysis, we collect fibre logs from those devices and data from the honey pot. So when you have such a large amount of data of course you have to do ‑‑ what usually do, we create some, from each attack you can create some vector based on the IP address, time, login and password credentials, they are trying ‑‑ and so on, and IP address, of course. And you have a very large vector which you can transform to some which is a vector and if you have two vectors there is an angle and if the angle is very, you know, close, is very small, it's close to one, then you see there is some similarity. And we done similarity on large amounts of data, we tried different kinds of data and with that we can see how those BotNets are related to how ‑‑ how those attacks are related. Quite interesting. We don't have time for results from this research, but it's very interesting research and you can see how many different BotNets is attacking here.
One more small thing and not very related to routing, one of the lessons we learned from the instant updates is that you have very powerful users that will play with the device it doesn't work, because even basics on the system, you think there, OK, so we said that is probably not the best way to go forward so for those users we introduced sort of virtualisation, created containers that can install on the devices and then they can run anything they want and play with that and we will not touch it so basically now we have like secure basis which is OpenWrt based and there is a container that you can play with so it's much better way how to deal with the automated updates with the powerful users, just something we did for those guys.
Some other outputs, we did so much security analysts, grey list of suspicious IP addresses, IP address that is we see some attacks from. We also do a lot of graphs on the web pages, so you can see how ‑‑ how the situation evolves, which ports are currently the most popular, similar to RIPE Atlas we measure response time of some selected Internet servers so we can see how the situation of the Internet evolves. We also check some SSL certificates, so we know if some certificates have changed of some important size or there is some middle attack and stuff like that. We measure connection speed, and of course we publish everything so if but it to Turris.cz website, you can see. Here is how the speed measurement looks like, we do passive measurements as well so the device is just looking at your one speed and checks which stream is flowing through the one port so you can see that on, I think it's October 16 I was downloading probably something big and you can see I was downloading in the speed of 40 megabits, which is roughly speed of my LAN so I know that my ISP is selling me what I really ordered.
This is just a pour trend, we can see 1,000 of attempts to connect to 21, a day, nothing surprising probably.
So, what is next? You know, we created those devices and ran very nice project and we distributed them mainly in the Czech Republic, and then many people presented us, can you give us that device, sell it to us? We said honestly, no, it's just a project it was meant to be in the Czech Republic, we cannot support anything outside. So, we cannot help you. But some companies were really interesting, for example, Sam knows doing speed control and research in European Union and many other countries, Comcast gave us RIS ‑‑ they like the project, thank you very much Comcast and we are quite experienced and now how to make those small boxes and we know there is not much OpenSource hardware in this and device is very open and has a lot of hardware connectors, it can be useful education and stuff like that. So we decided to make something smaller than the router Turris, something more price optimised and that is how the Project Turris light started, the idea was to create cheaper hardware and to give it for production cost to people, we are not for profit and there would be no agreement and no mandatory security research participation. Unfortunately, when we put all those features we thought that would be nice, the router is more powerful than the previous one and has more features so we decided not to call it light any probably and heavy would be probably good name, it's called Turris OMIA, it's for sale but just for covering the production costs, we are not a commercial company, and it's currently one of the most powerful routers, we have prototypes so we could measure that. It will be OpenSource software and hardware, able to provide one gigabit of traffic in small packets and it's a Linux based router so you can do anything you want, run, for example, another software recreated BIRD and it's complete, you know, BGP capable router.
So, this is how it looks: One major difference from it has SFP modules into that, it has ‑‑ this is how it's going to look in the plastic box. It's almost ready, we have 3D model, it's a little bit smaller. One gigabit of RAM so probably more than ‑‑ definitely more than in ‑‑ 4G bit of ‑‑ definitely enough space for anything you would put into, would like to put into. And it has five LAN ports and one port, all of them at gigabit speeds and the WAN port is thousand based SFP at the same speed. This is how it looks. This is ‑‑ this is the CPU which is 3 Internet interfaces, two of them connected to switch chip so 2 gig bits the connection between the switch chip and the CPU and this switch chip is cable to of doing VLAN and stuff like that, if you would like to separate it another one port it's easy, you create spread VLAN here and you have completely independent port for anything you want, or you can play however you want. And this one is the WAN port and it has thousand based T or SFP.
As I said, we believe it shouldn't be just routers so it has many other extension it is, 2 USB 3 slots, 3 mini PCL E express slots, two of them will be occupied by wi‑fi, but of course you don't have to, for five gigahertz and 2.4, one of the SIM socket attached so if you would like to push some LT modem you can do it of course. It has RTC chip with battery backup, validates use our own, Knot DNS resolver you need too far precise time that is why we pick up the time. We put some cryptographic chip there for better entropy and RNG, they generate, for example, certificates on that. And some for other extensions like GP I O pins, SP I, I 2 C, for people who understand those letters and would like to play. And the most important feature, the most popular in the previous Turris project ‑‑ it's very important feature of router, actually. There is 12 of them and ten of them have some purpose or at least some picket gram, two of them will be completely free for anything would you like to do with them. And many people, since they use it for strange things, like for signalling, I don't know, you should open Windows because there is not enough oxygen and stuff like that. Definitely, very handy feature.
It's quite quick. Those are the test from open ‑‑ we are at the top, we still switch on the extra hardware acceleration for cryptographic functions so this is just CPU. When you create something and you work on some project for a long time you think it's very important thing and maybe later you realise that nobody is interested in, so we said let's not do it this way, let's not create a bunch of those at the vices and then realise that nobody is interested in, so we created an Indigo campaign and the target was 100,000 dollars and it went really well because it was covered in 21 hours. So, definitely, there is some interest. We still continue the ‑‑ the campaign continues and it's going to finish in the middle of January. So, if you are interested, if you think it's a good hardware please subscribe and show the support. I don't want to make this commercial presentation but it's a not for profit project so if you think it's an interesting hardware please help us. And again, we are just covering the production costs, so not development or nothing like that, it's not for profit research. So that is all from my side. Thank you very much.
(Applause)
JOAO DAMAS: So any questions or comments for Ondrej? One coming up.
AUDIENCE SPEAKER: Mick O'Donovan, BT Ireland, I want to commend you on the work that you do and it's a great project, commentary more than anything.
JOAO DAMAS: I concur, it is an excellent project. I don't know if you plan to scale this infinitely, but at least this is all open course and eventually other manufacturers can pick it up.
ONDREJ SURY: Everything is OpenSource, we are going to publish everything like we do in all the other projects of course.
JOAO DAMAS: It's great to see if we can improve the general devices out there which are not so good usually.
AUDIENCE SPEAKER: Do you plan a version when you leave off the switch chip and only have ‑‑ port?
ONDREJ SURY: Yeah, we discussed that but there is an issue, if you want to ‑‑ produce some devices at reasonable price there must be at least some volume so making more versions at the beginning would be quite risky for us, we decided something that would probably fit by 90% of users, we can make it. And also, it's open hardware so if you think the a good idea just take your plans ‑‑ production plans and do it by yourself.
JEN LINKOVA: What is your status of IPv6 support? I just Googled and couldn't find anything reports on how do you deal with it?
ONDREJ SURY: Because we don't think it's foreign mention it any more. (Important to mention) IPv6 supported.
JOAO DAMAS: Great. Thank you very much.
(Applause)
So next up, we couldn't get Emile so we will have to be happy with Randy but he promised to give us two talks for the price of one, right? Two‑and‑a‑half, OK.
RANDY BUSH: So, you have had to do ‑‑ imagine me as Richard Barns now, now you can imagine me as Emile, about the same height, probably 15 kilos lighter, 30 years younger and much cuter.
Let's see. So, you really get two‑and‑a‑half talks for the price of one. This one is about BGP collector communities; in other words, what you as a peer with RIS or route views mark your routes, and the problem is, as researchers, we kind of like to know if you are giving us a full feed of, as you will ‑‑ as a customer, whether you are giving us peer‑only routes, whether you are giving us your internal /30s, too, or sorry, Jen,/126s. 126s. Yeah. So, because we kind of like to know what we are getting. So, extracting information from current RIS or route views is hell. So, trying to use the existing communities is pretty messy. This is what AT&T says they are sending. So, how AT&T marks their routes with, you know, their large aggregates and their routes from customers announced only to other customers, and peers, announced to customers and not peers, it just goes on and on. OK. This is ‑‑ oh, and note that their customer cone we can guess is about 48,000 and they are not all well‑marked. Here is Level 3, OK? And it says here is how I tag customer routes, here is how I do my own, and here is the difference. And if I'm a researcher, you know, the thing you might say is, well, I told you how I tag my routes, so, you go to all the different peers, all 100s of them, find out how they tag their routes, and then interpret that as you wish. Oh, by the way, and they change how they tag it occasionally. This doesn't scale. So what we are suggesting in an Internet draft, is just some communities, you tag your customer cone, external routes, in other words what you learn from peers or up‑streams or whatever, and internal routes, just in case you leak them to us the /30s and 126s or whatever. And we don't expect to you do this tomorrow, right? But it would be nice if over the next couple of years you moved towards it, so we don't have to guess. Right? It's really pretty stupid and simple. Even I can understand it.
So, the second free talk is wanted to compare some RPK origin validation versus route filters and this is done by a grad student, in Adelaide. He did me all the heavy lifting. Someone asked me what language I programme in and I said grad student. What is the difference in performance between RP Q origin validation and filtering with the IRR. So we have cache on a server in Dallas, a router, in this case it's a 12,000 and 6 with a PR P 3, EXA BGP, this shoves RPKI at it and lack LAN visit you had us in Tokyo. He took prefix sets from the Hurricane Electric customer closure, he extracted the RIB from route views Equinix so only HE customer closure was present, that is about 100,000 routes, and made custom RPKI data to match it. And made ‑‑ and HE actually publishes the IRR data. Shoved it up the router. Loaded the RPKI data, in 9.16, loaded the in the ACL took 39 MEG, RPKI data took 9.4 but they are about the same in processing time.
Second experiment: Actually, it was a third, I forget what the second was, I think it didn't work too well. Multiple BGP sessions; in other words, this router now has multiple peers, mainly five of them, sending about 700,000 routes, the routes were extracted from route views RIBs of various Tier1s, looked at the communities of the routes, see previous presentation on why that was great fun. And applied route policy, created from the prefixes, one prefix set entry per route for each peer. Generated the equivalent RPKI data, one ROA per announced. So the two should be commensurate.
13.4 seconds to load the RPKI, pretty much the same, looks pretty flat. 72.5 minutes to load the IRR data. Much more serious difference in memory use, both are pretty close as far as route processing time.
He tried a fourth experiment with a couple more peers and a couple more routes and the router crashed, reproduceably, and evenly a really wonderful way, not only did it crash but it scribbled all over its disc so we had to start from scratch with TFTP each time, I do not recommend this. It wasn't fun, especially since it's remote, OK?
So, now the third little talk is if we had this discussion on what is the taxonomy of bad routing garbage and so I started something on NANOG and this is the current state of play and you can contribute. A route leak is I receive the route and I sent it on to somebody who I shouldn't have sent it to, for business reasons. In other words, something I received from a transit I sent to another transit and significant received from a peer I sent to another peer, etc. A misorigination, I originate P when I don't own it. If I have done that intentionally, it's a hijack. But you better prove intent. It's impolite to call just normal stupid fat I think if aer hijack. And then something we are calling laundered which is I receive a prefix or some super set thereof, process it likely through my IGP and reoriginate it or parts of it, as my own. Telecom Malaysia. So on and so forth. I was shocked that we really didn't' have a common terminology for this stuff so, we are just trying to create one. Your comments and additions to this would be appreciated, the most discussion was about laundered. And that is unfortunately an American idiom for taking money off an illicit and producing it so it looks clean, when it isn't. And that is all she wrote. Questions?
(Applause)
JEN LINKOVA: Just a question. You classify hijack only as intention at misorigination not intentional leak?
RANDY BUSH: Yes, we could take and have the three categories and divide them by intent or no intent.
AUDIENCE SPEAKER: Warren: I was really fascinating by the processing time of the experiments you did. What are you counting as route processing time, is that from when you form the relationship to when it's all synced, or what?
RANDY BUSH: You mean the filter time ‑‑ the prefix filter time
AUDIENCE SPEAKER: Route processing time, is that ‑‑
RANDY BUSH: Ah, OK. That is a start to send a full stream timed end. And we eliminated RIB to FIB. Which is the classic trap. Right?
AUDIENCE SPEAKER: Peter he is letter from host server. For the communities that you want people to be using to tag the routes for their origin, how would you address in organisation ‑‑ yeah, exactly, for this, how would you address an organisation that has a 32‑bit ASN, should they use ‑‑ how should they tag?
RANDY BUSH: I don't know, we will fake it. Come contribute to the Internet draft.
The problem we have currently is, of course, you know, I am friends with these giant operators and I kind of work for one, I guess, and getting change is slow. So, that's the major thing, you know, how soon you are going to change, a couple of years if you will. Speaking of large operators.
RUEDIGER VOLK: I am really not happy if someone tries to interfere with the carefully set up system, system of what I am doing with my communities and how to clean the internal signalling clean kind of my stupid question is, well, to a large extent, in my opinion, some of the communities are actually just by agreement on peering basis ‑‑ well, OK, unfortunately the large guys usually dictates what the small guy has to do
RANDY BUSH: And the large girls.
RUEDIGER VOLK: OK. And I would not have the slightest problem if the collector AS would say, yes, the collector AS unifies what they want and I would actually not have that much of a problem of feeding the ‑‑ well, OK, accepting that dictate from a neighbouring collector, saying I should put in something into my name space that you defined, only makes sense if, well, this community and this signalling is actually not directed just to the collector but to the whole topology.
RANDY BUSH: You can reuse these however you wish. I think starting a project to describe how to do the whole topology, is going to be rather difficult.
RUEDIGER VOLK: Well, OK, no, when I am saying addressing the whole topology here, means well, you define a signal that is not just in the bi‑lateral relation between you as a collector and me as a large service provider, but you are asking me to tax stuff that ‑‑ well, are you asking me to send these communities to other people then just for collectors?
RANDY BUSH: No. You can of course, if you wish.
RUEDIGER VOLK: Yes, well OK, if you just asking and if you are just trying to standardise what the collectors want to see, my suggestion, quite clearly, would be, well, say ASN is the collectors AS
RANDY BUSH: That would be fine, or 666, it really makes no difference. Yeah, yeah, yeah. Fine. No problem.
RUEDIGER VOLK: For you as a researcher, if I did my own AS in there, of course if I sent that to Jen and Shane and I don't know who, and they propagate that to you, of course would you see more interesting stuff ‑‑
RANDY BUSH: I don't think I want to see that. But it's true, you can send it to me why my AS, I can always tell what AS you have got because of the peering with you, except of course that COP A is going to change the way M‑route works but that is another matter. It's been fun.
(Applause)
JOAO DAMAS: We have at least one item for AOB.
ROB EVANS: There is a couple of AOB items. Sander, are you around, do you want to ‑‑ if Dario is around who spoke in Anycast on Tuesday and wanted to mention something.
SANDER STEFFANN: So, Hi, good morning. Quick update on behalf of Address Policy. Yesterday, we discussed some policies around ‑‑ about ASNs and one of the things that came up is that there is still no BGP community for 32‑bit communities. So, we asked the room there if they wanted us to take this up with IETF and we got overwhelming positive response to that so I just want to inform that you on behalf of the Address Policy Working Group we will be in touch with IETF and to push this forward because it's one of the few things that is holding back full deployment of 32‑bit ASNs. Any questions?
(Applause)
ROB EVANS: And is Dario around? If not ‑‑ the presentation on Tuesday morning Dario was asking for people who are interested in the Anycasters project, to get in touch with him.
AUDIENCE SPEAKER: So, just a brief comment, I already contacted some of the people in the previous, the main talk in the previous section like Isolario, they are providing feed about BGP with possible filtering, it may be interesting for us. The point in talking to the mic is just to say without contacting each of you in peer to near Unicast mode which will make hundreds of e‑mail, I can just broadcast it over the air so if you are interested I am here and around, I drink coffee and we are close to the coffee break.
ROB EVANS: Thanks very much. One final thing at the next meeting it's my turn to stand down from chairing the Working Group so if you have ‑‑ if you are interested in being co‑chair, then please let João or myself know and we will try and sort it out the next time around. And with that, I think we are done and we are actually early for coffee which was not expected. Thank you.
