Based in Athens, Greece
Articles
Likes on articles
Vasileios Kotronis is the CTO and co-founder of Code BGP, a startup offering a real-time BGP security and observability platform. As a former Postdoctoral researcher, he has contributed to the ARTEMIS OSS (funded partly by RIPE Community Projects Fund) involving the real-time detection and mitigation of BGP hijacks. He holds a PhD from ETH Zurich, from the former Communication Systems Group. His main professional interests include: Internet Routing, Software Defined Networking, Internet Measurements and Network Security and Engineering.
• 8 min read
RIS Live is a reliable, well-designed, operationally robust API that provides a real-time view of BGP updates. In this article, the team from Code BGP talk through the RIS Live features that have helped them build a platform capable of detecting and resolving BGP issues in seconds
• 10 min read
Internet Exchange Points (IXPs) originally aimed to keep local traffic local and reduce dependence on third parties. However, ever-increasing traffic volumes create pressure for denser and more diverse peering that challenges the traditional IXP model. A fundamental shift in peering practices is R…
• 6 min read
In this article we present a prototype web portal, which demonstrates the deployment of RIPE Atlas probes within eyeball networks based on Internet user population estimates per Autonomous System Number (ASN) per country.
Showing 3 article(s)
“Would you be able to present ARTEMIS on SwiNOG 36 (www.swinog.ch) in November?”
Thank you for the invitation! We will check within the group and will get back to you Steven. Just let us know about related information (place/time/etc.) and deadlines to check availability etc. We will be also present in RIPE79 to give a lightning talk and some demos, so we will be also happy to meet you there and maybe discuss more on this.
“Effectiveness of recovering from attack on an allocated prefix, for example of a /24, is dependent on others collaborating as well (mitigation method 2 above). Does not this defy the concept of having a self contained and self reliant mitigation strategy? If the upstream providers do not permit advertising more specific prefixes and also do not collaborate, what would be the option then to thwart an attack?”
This is a correct observation. We have identified two possible mitigation options: prefix deaggregation, where feasible (e.g., complying to filtering rules), and BGP advertisement outsourcing, using a similar model as the one used by DDoS mitigation services (as described in our ToN paper). Focusing on self-contained-only strategies, that do not employ third parties (therefore excluding outsourcing), we would welcome more ideas besides deaggregation. I think that filtering issues could be bypassed using special communities agreed between the victim and e.g., its upstream provider(s), so that the defense mechanism can work for the duration of the incident. Would you have more feedback on such mechanisms? Thanks again for the very useful remark!
“The impact is far higher than 1% BGPStream alone detected 13935 incidents There are 64409 ASN numbers activated on the Internet as at May 2019 Probability of attack is # of ASN / # of incidence ~ 13935/64409 ~ 21% chance you will be impacted by an attack BGP Hijacks are happening all the time and most operators are not aware of it. Operators are willing to Pay for DDoS and Security Filtering but not for routing validation that is impacting their traffic before it gets to this infrastructure? ARTEMIS does not actually neutralize an attack and being an open source toolset has little continued assurance of business SLA. Whilst price may be an issue, how is that ranked against business continuity? The importance placed by the research paper for this ranked issues none of which an open source tool can provide a) Effectiveness of Mitigation (awareness is not mitigation) b) Fast Mitigation (RIPE/Routeviews/BGPSteam are all 5-15 minutes out of date, detection needs to be < 3 minutes) c) Ease of Operating / Troubleshooting... <> open source, who's going to take your support ticket for bug? d) Low Cost.. I guess it depends on the Value, a US service provider lost $60Mil USD as a result of a Route Leak.. is cost an issue now? e) Ease of Installation... <> opensource this is a starting point only ... etc etc. The real question is how does ARTEMIS address the whole ASN network vs a single prefix”
Dear Martin, thank you for your comment. I did not get what you mean by the 1% impact, could you please elaborate? ARTEMIS allows for real-time detection of an attack, enabling automatic mitigation. In the current open-source code we have a wrapper for operators to plug-in their own scripts (e.g., Ansible, etc.) to configure routers in case of such attacks. ARTEMIS itself can be configured to mitigate, and we are working heavily on providing more wrappers and interfaces to be able to talk to multiple router types (currently only the wrapper/trigger is available in the open-source version). Regarding the issues you mention: a) Effectiveness of Mitigation --> Please check section 6 of our ToN paper (https://arxiv.org/pdf/1801.01085.pdf) b) Fast Mitigation --> RIPE RIS offers real-time streaming. As well as the public beta BMP feed of BGPStream, and the exaBGP interface to local routers is also real-time. c) Ease of Operating / Troubleshooting --> We are considering commercialization options in this context. More information soon! Till then, we are doing our best to address bugs on GitHub, using the "issue" primitive (you can check the list of resolved issues and added features). d) Low Cost --> Apparently yes, see Fig. 3b and 3k of https://arxiv.org/pdf/1801.02918.pdf It seems that despite the high impact of these attacks, the problem persists and available tools and mechanisms are not able to fully counter this. By the way, I think that in your comment the cost of the tool itself is confused with the cost of an actual attack, which of course can be very high. e) Ease of Installation --> I agree, and as described above we are looking at commercialization options around open-source. However, we will in any case try to maintain and deliver a high-quality open-source software to assist the community detect such incidents in real-time. For more feedback/questions please contact the dev team using the information of https://github.com/FORTH-ICS-INSPIRE/artemis , we would be happy to answer them. For example, regarding the ASN vs single prefix question, we are working on automating parts of the configuration process of ARTEMIS, making it easier for the operator to set up ARTEMIS for large networks.
“Great work! My feeling is that BGP Hijacking appears to happen more and more often lately, although it's hard to measure. One comment however in relation to this statement: "In our work, we show that the existing public monitoring infrastructure can enable live detection of all impactful hijacking events. In fact, while a hijacker can employ several means to achieve a stealthy — that is, invisible to BGP monitors — hijack, this can be achieved only at the cost of limited impact (less than 1-2% of AS-level pollution)." While it would be nice if this was the case, consider this scenario where the AS-level pollution is low and the impact high: Leak IP-space that belongs to an authoritative DNS provider of choice to the provider of a large public DNS resolver. Currently there exist quite a few large "managed" authoritative DNS providers, and also quite a few large public DNS resolvers. Hijacking can happen quite easily if the public DNS resolver peers at an IX where the authoritative provider does not. It would also not be hard to select an IX where BGPMON and the like have no visibility.”
We thank you Wouter for the comment. Such targeted attacks are a concern; still the impact on the AS-level Internet in terms of IP routing remains limited even in this case, while this hijack compromises an application-layer mechanism (DNS). However, we acknowledge that this can be done, and one of our intentions is to push for getting more monitors out there to eradicate the possibility of a missed attack. Note that in this case, the authoritative DNS provider has an incentive of having enough monitors out there, especially "close" to the well-known public DNS resolvers, including in potential IXes where they peer (e.g., using the route server). Also, it has an incentive to use ARTEMIS to monitor its own -precious- prefixes which if hijacked, could lead to the situation you are describing. We are further looking into data-plane-based solutions to cover the cases where the control-plane may fail to see such a targeted (limited on the AS-level but with high impact in practice) attack.
Showing 4 comment(s)