[00:00.000 --> 00:11.840]  Hello. Thank you for coming. I'm very happy to see lots of people here. I hope you will
[00:11.840 --> 00:19.760]  enjoy my presentation. So, I'm Pavel and I will talk about DDoS detection using opensource
[00:19.760 --> 00:29.560]  tool. So, first of all, why and why I'm talking here. I'm software engineer. I got formal
[00:29.560 --> 00:34.800]  educational software engineer and since the beginning of my career, I started working on
[00:34.800 --> 00:40.680]  opensource and my first programming language was quite unusual, I would say. It was Pearl. So,
[00:40.680 --> 00:45.800]  not fortunately choice for so many people, but for me it was a way into industry. So,
[00:45.800 --> 00:51.480]  I worked it for domain name register. I worked it for cloud compute company. I worked it for
[00:51.480 --> 00:58.960]  internet exchange. And finally, I got a job for global CDN provider and I ended up working in
[00:58.960 --> 01:07.240]  cyber security. So, what I'm doing now, I'm in charge of development of cyber security product
[01:07.240 --> 01:15.120]  for network security and this product is called Fastnetmon. So, I would like to start from brief
[01:15.120 --> 01:22.520]  description what is Fastnetmon. Fastnetmon is an application. So, it's the very first thing to
[01:22.520 --> 01:28.800]  clarify. It's cross-platform application and when I'm saying cross-platform, I mean Linux,
[01:28.800 --> 01:34.920]  macros, free BSD, open BSD. It's not yet on Windows, but it's still. And main purpose of
[01:34.920 --> 01:41.400]  Fastnetmon is DDoS detection for networks. From technical perspective, Fastnetmon is implemented
[01:41.400 --> 01:48.120]  using modern C++. Back in time, it was quite interesting story when Fastnetmon was started.
[01:48.120 --> 01:55.360]  But very, very first version of it in 2013 was implemented in C++ 11. But because of compilers
[01:55.360 --> 02:02.320]  in some way, not so very modern distribution, we had to move back to C++ 98. Since then,
[02:02.320 --> 02:08.560]  we still support modern versions. No way to like, no reason to maintain compatibility
[02:08.560 --> 02:13.920]  is very outdated stuff. And now it's like, it's really good fancy C++. It's kind of C++
[02:13.920 --> 02:23.360]  actually enjoy hacking, creating, and like changing if you prefer to do so. And I know
[02:23.360 --> 02:27.480]  this feeling. When you hear about new stuff which may be relevant for you, that's the
[02:27.480 --> 02:32.440]  first urge to maybe, should I try it now? Immediately. Because what is the point of
[02:32.440 --> 02:35.680]  documentation? What's the point to hear my presentation? If you can just install it right
[02:35.680 --> 02:40.880]  now? It did very long. It was very long journey. And I would like to thank you all for our
[02:40.880 --> 02:48.920]  maintainers and who made it actually possible that Fastnetmon has so many distributions.
[02:48.920 --> 02:53.840]  For almost every single popular distribution, I used mostly for server environment and production
[02:53.840 --> 02:58.640]  environment, you may install Fastnetmon on just single command. So, it will start right
[02:58.640 --> 03:06.600]  now if you prefer. And if for some reasons, your distribution have no latest distortion
[03:06.600 --> 03:12.440]  Fastnetmon or you want to just install it, you know, for some distribution is not covered
[03:12.440 --> 03:20.160]  by or official packages, there is installation tool. Let's go forward. Because most of the
[03:20.160 --> 03:25.520]  time we talk about what our tools and our products can do. I would like to start from
[03:25.520 --> 03:30.880]  unusual angle. I would like to highlight what we can do because it's important. Because
[03:30.880 --> 03:37.920]  there are so many tools for DDoS detection. There are so many angles of DDoS detection.
[03:37.920 --> 03:42.560]  It's detection of the part. It's mitigation part. It can be implemented on premise and
[03:42.560 --> 03:47.400]  in cloud. And before we go into details what we are doing, we need to highlight what we
[03:47.400 --> 03:55.800]  are not doing. And if you have any issues with your website or your blog, I'm sorry,
[03:55.800 --> 04:02.360]  we can help you. It's not the point of Fastnetmon. It may indirectly help your carrier or service
[04:02.360 --> 04:08.200]  provider. But for your case, it's better to use cloud services because it's not that
[04:08.200 --> 04:12.360]  complicated to move site around. Because normally if you're not talking about really
[04:12.360 --> 04:16.440]  enormous size, it's quite easy to move on to content delivery network and then coverage
[04:16.440 --> 04:25.240]  from DDoS. And if you have some issues with DDoS when you play in your Xbox or PlayStation
[04:25.240 --> 04:31.720]  also, I'm sorry, we cannot help you. This is decided at this slide because we have too
[04:31.720 --> 04:36.080]  many questions. And I think it's one of the real serious problems in modern days because
[04:36.080 --> 04:45.200]  you cannot play because of DDoS. And if you use managed service provider, it may be public
[04:45.200 --> 04:51.040]  cloud, it may be private cloud. And when I say managed, it means that somebody in charge
[04:51.040 --> 04:55.600]  of keeping your service running. And it's in this case, it's very unlikely that you
[04:55.600 --> 05:01.520]  have access for your network. I mean, administrative level of access. It's a bit change policy,
[05:01.520 --> 05:05.800]  inspire policy, change or alter configuration. And in this case, it's better to escalate
[05:05.800 --> 05:14.120]  to your service provider like call for help. We have some problems. Help us. And finally,
[05:14.120 --> 05:18.720]  what Fastnetmon can help you? Fastnetmon here is not to protect specific service. Fastnetmon
[05:18.720 --> 05:23.720]  here to protect your network. And when I'm saying to protect network, it has very different
[05:23.720 --> 05:28.280]  meaning from protecting specific entity. Main purpose of Fastnetmon to keep up time of all
[05:28.280 --> 05:32.960]  network in general. And when I'm saying in general, it means that keep it running for
[05:32.960 --> 05:42.480]  99% of customers, eyeball services behind the specific network. And I'll explain how
[05:42.480 --> 05:49.560]  we can do it. What kind of attacks we can protect your network from? Again, there are
[05:49.560 --> 05:54.760]  so many types of attacks. There are like so many opinions about classification of attack.
[05:54.760 --> 05:58.760]  I'm not going to go into details about what the kinds of DDoS attacks. I would like to
[05:58.760 --> 06:06.360]  focus it from well described OSI model approach. So what we can help you? We can help you with
[06:06.360 --> 06:13.080]  IPv4 and IPv6 at the same time. If you still use IPv4, please don't. Please move away
[06:13.080 --> 06:19.160]  from it. And in terms of layers of OSI model, we can help you only with levels L3 and level
[06:19.160 --> 06:25.000]  4. And if you have some specific ideas, what is the option to filter out traffic using
[06:25.000 --> 06:32.120]  like HTTP or two or three protocol encrypted by a TLS, it's better guess to try to just
[06:32.120 --> 06:36.960]  present it like suricata because fastnet one is a little bit out of scope. Because main
[06:36.960 --> 06:41.760]  purpose of fastnet is to detect volumetric DDoS attack. And when I say volumetric, it
[06:41.760 --> 06:48.000]  means at least hundreds of megabits, but mostly in general case for every size of DDoS in
[06:48.000 --> 06:53.080]  modern day, it's around 8 gigabits. And in some cases, it's exceptionally high, it's
[06:53.080 --> 06:57.400]  maybe hundreds of gigabits. But on average, it's like just few gigabits. And this purpose
[06:57.400 --> 07:05.200]  of fastnet to take this kind of attack. So what is the very first step when we assume
[07:05.200 --> 07:13.000]  that network is under DDoS? Because when I'm saying assume, can we say for sure is it DDoS?
[07:13.000 --> 07:18.160]  Because in so many cases, how we actually can absorb DDoS attack against our network?
[07:18.160 --> 07:23.120]  Like you check your phone, it's not working. Like your website is not working. You check
[07:23.120 --> 07:27.720]  like laptop in your office. And for some reason, something doesn't work as expected or customers
[07:27.720 --> 07:36.080]  calling you. And first step is to confirm that actually DDoS. Because it may be not DDoS,
[07:36.080 --> 07:41.040]  it may be fire alarm in your data center. Why it's extremely important that it's actually
[07:41.040 --> 07:46.040]  DDoS? Because it may be something different. And in case of fire, it's way more important
[07:46.040 --> 07:52.920]  and way more different kind of actions to remedy the DDoS detection. And if you know
[07:52.920 --> 07:58.120]  by accident that some people, your colleagues working in data center right now, and it's
[07:58.120 --> 08:03.480]  like the same timeline, you receive a call from customer like, something doesn't work,
[08:03.480 --> 08:09.880]  it's very unlikely that it's DDoS. It's maybe caused by misconfiguration, because there
[08:09.880 --> 08:17.680]  are so many ways how we can figure down time in our networks. And okay, we covered most
[08:17.680 --> 08:24.160]  of the sources which can cause network DDoS, network down time, but actually DDoS. And
[08:24.160 --> 08:30.640]  look, even this one, it's not DDoS. This one is, it can cause havoc. It can bring down
[08:30.640 --> 08:37.600]  all cities, countries, data centers. But it's still not DDoS. And what is how we can say
[08:37.600 --> 08:46.640]  like, this one's for sure DDoS. And graphs. The only way to be 100% sure it's graphs.
[08:46.640 --> 08:52.400]  And by looking on this graph, if you know like, okay, my network generates like 100,000
[08:52.400 --> 08:58.240]  packet per second, like 100 gigabits. And if you can see spikes by 20 gigabits, it's
[08:58.240 --> 09:04.760]  very unlikely it is caused by something normal. It's very likely it is DDoS. So it's first
[09:04.760 --> 09:09.080]  level of remediation, at first level, how fast that one can help you. Fast that one can
[09:09.080 --> 09:15.120]  say for sure, in this kind of dashboard, that you are under DDoS. And then you can action
[09:15.120 --> 09:20.640]  it appropriately because you are well prepared. You know what you can do. And what we can
[09:20.640 --> 09:27.720]  do in this case. Fast that one provides lots of different dashboards. And main benefit of
[09:27.720 --> 09:33.120]  those dashboards is that they're built not on physical level of network. Because when
[09:33.120 --> 09:38.480]  I'm saying physical level of network, I mean a port counter, slow for specific interface,
[09:38.480 --> 09:43.000]  slow for specific router. And what fast that one can do, it's more of a review of your
[09:43.000 --> 09:49.280]  network from logical level. When I say logical level, it's more from networks, prefixes,
[09:49.280 --> 09:55.080]  specific services. And in this case, fast that one can provide a required amount of
[09:55.080 --> 09:59.320]  granularity. It's like total traffic for your network. In this case, you can see total
[09:59.320 --> 10:03.840]  income and in case of any spikes here, you may see it almost immediately. It's one of
[10:03.840 --> 10:09.440]  the benefits of fast net money. It's not historical data. It's data which actually was just received
[10:09.440 --> 10:18.040]  from your routers. It's almost real time data. And so in the same case, again, from logical
[10:18.040 --> 10:23.000]  perspective, it's not the, instead of seeing what is the load for specific interface on
[10:23.000 --> 10:28.880]  my router, you can see information about how much traffic you have for specific prefix.
[10:28.880 --> 10:33.840]  And you will aware what kind of service is running in specific prefix. And so you can
[10:33.840 --> 10:39.880]  understand something wrong with this specific prefix. And again, the latest level of granularity
[10:39.880 --> 10:45.120]  you may find even traffic for per host because you may know that for specific prefix, you
[10:45.120 --> 10:49.680]  just have two services, very important services running. And then you can check what is the
[10:49.680 --> 10:54.240]  load for example. And you can see immediately again in real time, what's wrong? If you can
[10:54.240 --> 11:00.760]  see spike for this specific service, okay, we found victim, sadly. And fast net money
[11:00.760 --> 11:06.560]  on graphic capabilities include complete support for influx DB graph it and plenty of graph
[11:06.560 --> 11:11.640]  and a dashboard. I would like to send to community for contributing so many great dashboards
[11:11.640 --> 11:16.760]  because when we started this idea, we implemented a few of them, quite basic ones, but community
[11:16.760 --> 11:21.200]  did really great job by doing plenty of them. And actually, most of them are way better
[11:21.200 --> 11:28.760]  than our official dashboards. And what is the source of this data? Is it AI or something
[11:28.760 --> 11:35.280]  different? No. So we receive this information from our test or switches in your network.
[11:35.280 --> 11:40.880]  And from perspective of protocols, we support almost all available protocols in market.
[11:40.880 --> 11:45.960]  And of course, one of the most popular on its net flow, it's IP fix as flow. And in case
[11:45.960 --> 11:51.200]  of last resort, if you have no an athlete, but net flow or IP fix in your network, you
[11:51.200 --> 11:57.480]  can try to use port mirror for all cases fast and one can handle a really significant amount
[11:57.480 --> 12:02.600]  of traffic. And there are plenty of confirmed deployments of fast net money exceeding at
[12:02.600 --> 12:11.160]  least two terabits of capacity in total. So after you got all information, you may check
[12:11.160 --> 12:16.000]  it manually. For example, again, right at this moment, this fast net money will see what
[12:16.000 --> 12:21.080]  is your total load? What is load for specific network? What is the load for specific cost?
[12:21.080 --> 12:27.000]  And for small networks are like, you may find immediately what is the victim? Because in
[12:27.000 --> 12:31.640]  case of small network, you know, okay, I have 12 services move between and you can check
[12:31.640 --> 12:42.880]  one by one. Can we do it for DDoS detection? And this one is just the not very precise
[12:42.880 --> 12:49.520]  map of United Kingdom. And you can see there are lots of interconnections. It's not the
[12:49.520 --> 12:55.200]  largest country of planet, but you can see amount of interconnections. It's incredible.
[12:55.200 --> 13:00.560]  Even for medium sized internet service provider or telecom providers, they may cover at least
[13:00.560 --> 13:07.360]  multiple countries. And you can see amount, even towns, even regions is incredible. And
[13:07.360 --> 13:13.720]  if you talk about networks covering like multiple European countries or multiple countries in
[13:13.720 --> 13:20.320]  maybe, for example, Asia, it's incredible amount of locations, incredible amount of entities.
[13:20.320 --> 13:25.160]  You cannot check like, is it, for example, you are, we are under DDoS, you know for sure.
[13:25.160 --> 13:31.120]  Let's check every single one plus million city in Europe. We cannot do it manually.
[13:31.120 --> 13:35.920]  It's just impossible. Every single time from moving from large cities, we need to move
[13:35.920 --> 13:40.840]  to regions. Then we need to check household by household because this specific attack
[13:40.840 --> 13:47.400]  might begin specific person playing like Fortnite game in this specific building. You cannot
[13:47.400 --> 13:53.080]  do it manually, unfortunately. If they move a little bit to data centers, data center
[13:53.080 --> 13:58.640]  normally, as we can make here, it's single building, maybe huge building, but it's still
[13:58.640 --> 14:02.840]  just one building. It's not like, it's not scattered over like continent. It's not scattered
[14:02.840 --> 14:09.040]  over like a thousandth of kilometers. Is it easy to find out? No, unfortunately, because
[14:09.040 --> 14:14.160]  sadly in data center, you may have more entities, more potential big teams of DDoS than actually
[14:14.160 --> 14:21.400]  for large telecom networks. What we can do? Of course, as I mentioned, you can manually
[14:21.400 --> 14:27.280]  check every single host available in network because we already got pretty great dashboard
[14:27.280 --> 14:33.000]  and we have real time data coming from your routers. What is the logic? What is the way
[14:33.000 --> 14:38.480]  how we can actually find that? Again, we have data about what is a bandwidth for specific
[14:38.480 --> 14:43.360]  network? What is a packet rate for specific network? We can check every single host in
[14:43.360 --> 14:48.200]  our network and find out. Again, in case of data center and large telecom networks, it's
[14:48.200 --> 14:53.320]  impossible to do it manually. That's the reason how Fastnetone can help you. Fastnetone can
[14:53.320 --> 15:01.000]  do it for you and it can do it really fast. For almost all protocol support by Fastnet
[15:01.000 --> 15:06.320]  mode, we can offer detection time in less than five seconds. It's not about Fastnetone
[15:06.320 --> 15:11.040]  can say, look, you're under DDoS because it may be clear from graphs. At this point
[15:11.040 --> 15:16.280]  of time, Fastnetone can find out what is a specific service in your network which is
[15:16.280 --> 15:22.520]  under attack right now. We will have this information in five seconds. Why it's important,
[15:22.520 --> 15:28.120]  like five seconds? Why? Can we wait a little bit? Have a cup of tea or coffee and wait?
[15:28.120 --> 15:32.240]  Unfortunately, we cannot. That's the main problem because back in time, when I started
[15:32.240 --> 15:41.400]  working with DDoS attacks, it was around 2008. You can wait for around half hour when DDoS
[15:41.400 --> 15:45.920]  attack starts from something like 10 megabits, maybe 15 megabits, 100 megabits. You may
[15:45.920 --> 15:51.760]  have a cup of coffee, wait a little bit, 20, something like 50 megabits, 100 megabits.
[15:51.760 --> 15:57.480]  It's growing. Now, what we can see, attack and escalate from 100 megabits to tens of
[15:57.480 --> 16:04.320]  gigabits in like few seconds. And human being, unfortunately, I had to admit, cannot handle
[16:04.320 --> 16:10.400]  it so fast. We need some machines because people who actually run DDoS, they have lots
[16:10.400 --> 16:16.200]  of automation. And without having automation in place, we cannot defend it. So Fastnetone
[16:16.200 --> 16:20.160]  provides this option for you. And instead of checking every single host in your network
[16:20.160 --> 16:24.520]  manually, because it's still an option, you can verify. When you receive reports from
[16:24.520 --> 16:28.800]  Fastnetone, you can check graphs. Like, is it DDoS? Is it looking like DDoS? Because
[16:28.800 --> 16:35.040]  Fastnetone inside, it uses very simple rules. Like, if specific host in my network generates
[16:35.040 --> 16:40.200]  more than 5 gigabits of bandwidth, and if specific host in my network generates more
[16:40.200 --> 16:48.720]  than 100,000 packets per second, it's clearly DDoS. And after detection, what we can do,
[16:48.720 --> 16:55.720]  and very first step, which is available for every single carrier on this planet, unfortunately,
[16:55.720 --> 17:02.200]  it's free. This thing called BGP Blackhole. BGP Blackhole needs a little bit more clarification
[17:02.200 --> 17:08.400]  how it works. And because of name, you may guess, if you put something into Blackhole,
[17:08.400 --> 17:15.760]  you'll never see it again. And that's the point. And how Fastnetone can help and can
[17:15.760 --> 17:19.320]  rely on BGP Blackhole to stop DDoS from network.
[17:19.320 --> 17:25.840]  In the beginning of my presentation, I mentioned that Fastnetone here to protect your network,
[17:25.840 --> 17:32.360]  not specific service. And it's really important, because BGP Blackhole can be described in
[17:32.360 --> 17:37.160]  many words, because it's quite a complicated abstraction. But I would call it, it's like
[17:37.160 --> 17:43.720]  religion sacrifice made by network engineers to keep their network running. Why am I saying
[17:43.720 --> 17:49.880]  sacrifice? Because at this point of time, we know, for example, for our network, we
[17:49.880 --> 17:56.640]  have 20,000 hosts. Let's imagine every single host, it's residential building somewhere
[17:56.640 --> 18:03.760]  in Europe. And we know for sure, we are receiving DDoS right now. And our service degraded.
[18:03.760 --> 18:09.440]  Our customers calling us. Our site doesn't work. Nothing works fine. And we can find
[18:09.440 --> 18:14.800]  out what is the victim of this specific attack using Fastnetone. And we know specific host,
[18:14.800 --> 18:20.520]  which is IPv4 or IPv6, which is a target of this DDoS attack. And what we need to do using
[18:20.520 --> 18:28.280]  BGP Blackhole, we need to stop all traffic from coming to this specific host. Which means
[18:28.280 --> 18:34.000]  if effectively disabling and unplugging this specific customer or service from the internet.
[18:34.000 --> 18:41.640]  And that's how BGP Blackhole works. It's not about like firewall, which may block attackers.
[18:41.640 --> 18:50.000]  In this case, we literally manually, voluntarily block target or attack. Just to save our network.
[18:50.000 --> 18:57.120]  And that's only purpose of Fastnetone to stop it and do it automatically for you. So and
[18:57.120 --> 19:05.560]  after you stop it, and you can see it exactly on this diagram. So we maintain the uptime
[19:05.560 --> 19:11.560]  of network. And everything is skipped working by sacrificing just one host on your network.
[19:11.560 --> 19:16.200]  And it doesn't mean that you just block it and go away sending it. I can email to customer,
[19:16.200 --> 19:20.280]  look, we block at your service. We can help you. Sorry. There are so many ways how you
[19:20.280 --> 19:26.360]  can actually keep this host running. But again, before you apply some actions, create plan,
[19:26.360 --> 19:31.560]  what we can do, maybe you can call some specific providers to provide defense for it. You may
[19:31.560 --> 19:42.040]  just, sorry. So you need to have some actions and better to apply these kind of actions
[19:42.040 --> 19:48.000]  in quiet environment. Instead of having to deal with 20,000 of calling customers every
[19:48.000 --> 19:54.960]  single like minute, you may block specific target, you may keep uptime of your network
[19:54.960 --> 19:59.440]  back. And your, when your network is back to operation in quiet environment and way
[19:59.440 --> 20:03.960]  quieter environment, nobody yelling to you, nobody calling you, decide other like cup
[20:03.960 --> 20:09.680]  of coffee or tea, what is option, what we can do for this specific customer. And then
[20:09.680 --> 20:15.800]  how Fastnetone can help you. And since beginning when Fastnetone was built, it was open source
[20:15.800 --> 20:20.840]  from very first version. And a lot of features, I just explained it, they weren't invented
[20:20.840 --> 20:26.800]  by our master plan or roadmap. They were part of community request. We receive it at GitHub
[20:26.800 --> 20:31.080]  because of look, there is an option. I have a problem and I would like to solve it. So
[20:31.080 --> 20:36.440]  since beginning Fastnetone was community driven project. And we have lots of community channels,
[20:36.440 --> 20:40.400]  how you can cooperate with us, how you can share your stories, how you can ask questions.
[20:40.400 --> 20:53.240]  And please join all of them and I will help you to answer your questions. Thank you.
[20:53.240 --> 21:08.360]  Anybody has questions? Hi, thanks a lot, quite interesting. So I just wanted to ask you if
[21:08.360 --> 21:12.960]  you ever felt the need to extend the way you collect data with other protocols, like for
[21:12.960 --> 21:22.000]  example, any flavor of open config specifications or eventually BMP instead of BGP?
[21:22.000 --> 21:27.880]  That's a great question. So question was, is it possible to use protocols like open BMP
[21:27.880 --> 21:33.840]  or open con to feed more information to Fastnetone? In current generation of Fastnetone detection
[21:33.840 --> 21:38.240]  tools, we mostly rely on traffic telemetry protocols, which actually carries part of
[21:38.240 --> 21:43.280]  network packet. It's maybe header of network packet or it may be some meta information
[21:43.280 --> 21:47.920]  about source port, source IP, destination for destination IP. And we don't use data
[21:47.920 --> 21:52.880]  about BGP directly. The only way how we can actually interact with BGP is that we have
[21:52.880 --> 21:59.200]  internal BGP demand based on go BGP, which actually injects information and announces
[21:59.200 --> 22:04.120]  routers to your network. So we have no backward integration from network. So we have no way
[22:04.120 --> 22:10.120]  how we can learn information from your network. But because we offer different APIs, we offer
[22:10.120 --> 22:15.040]  different ways to automate and run callback scripts instead of just running BGP, you can
[22:15.040 --> 22:19.600]  run your own Python script and then you can rely on information from third party source
[22:19.600 --> 22:23.560]  and come by this information and make decisions using this information.
[22:23.560 --> 22:28.320]  I was merely asking because for example, with the GNMI, you can have like a sort of retraction
[22:28.320 --> 22:34.200]  on the network. So you can, based according to what you're receiving using IPv6, for example,
[22:34.200 --> 22:37.440]  you can have like an action directly on routers, for example.
[22:37.440 --> 22:43.840]  Yes. This is one of the ways how we can actually use so-called callback scripts because when
[22:43.840 --> 22:49.560]  fastnet on detects attack, it can run specific script. It may be base script, Python script,
[22:49.560 --> 22:53.400]  Perl script. And in this script, you will have access to basic information about attack
[22:53.400 --> 22:57.800]  and information. What is the target? What is like host target? What is the type of attack?
[22:57.800 --> 23:02.960]  What is the prefix target? And then using any like automation protocol, you can run actions
[23:02.960 --> 23:08.160]  on routers. And because of most of the routers, they have, there are no specific, like, there
[23:08.160 --> 23:11.320]  are no standard way how we can inject this kind of information for every single vendor
[23:11.320 --> 23:17.040]  available on market. And we decide to move these attacks to more communities, so to implement
[23:17.040 --> 23:21.040]  it on your own. And if you implement it, share this community.
[23:21.040 --> 23:32.040]  One second. Can you do a BGP flow spec to, like, black hole?
[23:32.040 --> 23:40.000]  That's a good question. So, back in time, we had BGP flow spec support based on exa-BGP,
[23:40.000 --> 23:45.040]  but it was, like, pure C-level quality of implementation because it was just literally
[23:45.040 --> 23:53.040]  hard called at least for DNS and SSDP amplification, but it worked well. So, the only, but unfortunately
[23:53.040 --> 23:57.480]  because of complexity of working as API of exa-BGP using flow spec protocol, we decided
[23:57.480 --> 24:02.000]  to remove this capability. And now the only way how you can actually inject flow spec
[24:02.000 --> 24:07.560]  rules, like, because you can implement black hole using flow spec, you can run it using
[24:07.560 --> 24:15.560]  go-BGP command line from callback scripts of faster one.
[24:15.560 --> 24:25.560]  Okay. Thank you. Any more questions? No. Thank you very much.
[24:25.560 --> 24:33.560]  Thank you for your time.