Antichi, G

Castro, I

Chiesa, M

Dietzel, C

Fernandes, EL

Kopp, D

English

Apollo (Cambridge)

SDN-enabled Traffic Engineering and AdvancedBlackholing at IXPsChristoph DietzelTU Berlin / DE-CIXchristoph@inet.tu-berlin.deGianni AntichiUniversity of Cambridgegianni.antichi@cl.cam.ac.ukIgnacio CastroQueen Mary, University Londoni.castro@qmul.ac.ukEder L FernandesQueen Mary, University Londone.leao@qmul.ac.ukMarco ChiesaUniversité catholique de Louvainmarco.chiesa@uclouvain.beDaniel KoppDE-CIXdaniel.kopp@de-cix.netABSTRACTWhile the clean slate approach proposed by Software De-fined Networking (SDN) promises radical changes in thestagnant state of network management, SDN innovation hasnot gone beyond the intra-domain level. For the inter-domainecosystem to benefit from the advantages of SDN, InternetExchange Points (IXPs) are the ideal place: a central inter-connection hub through which a large share of the Inter-net can be affected. In this demo, we showcase the EN-DEAVOUR platform: a new software defined exchange ap-proach readily deployable in commercial IXPs. We demon-strate here our implementations of traffic engineering andDistributed Denial of Service mitigation, as well as how mem-ber networks cash in on the advanced SDN-features of EN-DEAVOUR, typically not available in legacy networks.CCS Concepts•Networks→ Network design principles; Routing proto-cols; Programmable networks; Network management;KeywordsSoftware Defined Networking, Internet eXchange Points1. INTRODUCTIONBy facilitating Autonomous System (AS) interconnection,Internet eXchange Points (IXPs) are a critical element in theInternet ecosystem [1, 2]. IXPs provide a simple layer-2switching fabric to which members connect and exchangetraffic with other collocated ASes. Once a peering arrange-ment is established, IXP members rely on the Border Gate-way Protocol (BGP), the de-facto standard inter-domain rout-ing protocol, to exchange routing information.Because of this central role, IXPs are the ideal place toinnovate the inter-domain ecosystem. The limited size ofIXPs, in terms of deployed equipment and geographical dis-tribution, eases the physical migration towards novel net-work architectures and infrastructure. Furthermore, it is typ-ically in the interest of the IXPs to offer services that go be-yond simple layer-2 connectivity. For instance, many IXPsalready operate route servers, which simplify peering by al-lowing IXP members to peer with other ASes via a singleBGP session to a route server. Facing a continuous trafficgrowth in their networks, IXPs have a strong economic in-centive to embrace innovation to reduce operating costs.This demo showcases the ongoing effort within the EN-DEAVOUR project By deploying Software Defined Network-ing (SDN) at IXPs, ENDEAVOUR aims to create a flexibleSDN ecosystem that supports a service marketplace com-posed of data centers, networked applications, and the un-derlying interconnection fabric. The ENDEAVOUR archi-tecture advances existing work on SDXs [5] by providing anSDX architecture deployable in single and multi-hop topolo-gies, as well as by proposing use cases that benefit not onlythe IXP members, but also IXP management itself. Fig-ure 1 depicts the rich architecture that we envision as IXPstransition to SDN. At the data plane level, programmableSDN switches forward traffic according to fine-grained for-warding and filtering rules generated by the control plane(i.e., the SDX controller) in accordance to declarative high-level goals established by applications. In this scenario, anumber of different applications can be instantiated to ac-complish various use cases (e.g., Traffic Engineering, Ad-vanced Blackholing). The SDX controller then translatesthese goals into rules and programs the data plane throughthe southbound interface, i.e., OpenFlow. In this demo, weadvance the high-level ideas of ENDEAVOUR [3] with thedemonstration of our implementation for SDN-enabled Traf-fic Engineering and Advanced Blackholing.Traffic Engineering (TE) allows network operators to ex-press their routing policies. At IXPs, member ASes that ex-change large traffic volumes, typically demand connectionsthrough multiple ports (e.g., multiple 100GE). These ASesideally employ TE to load-balance traffic through these portsand minimize congestion while attaining high port utiliza-tion. The outcome depends on an interplay between the in-Programmable fabricApplicationsAdvancedBlackholingTraffic  EngineeringNorthbound  InterfaceRoute  serverSouthbound  InterfaceCongestionReportingAS  BAS  A…BGPData  plane  &  Monitoring  APIsSDXAPIsSDX  ControllerFigure 1: Rich architecture of an SDN-enabled IXP.bound TE policies of the traffic receiver and the outboundTE policies of the originator. As of today, well-known limi-tations of BGP restrict what network operators can achieve.Operators must resort to indirect BGP configuration mech-anisms, e.g., AS path prepending, communities, and/or se-lective announcements. This problem is particularly acuteat IXPs where the wide range of independent and inconsis-tent peering policies might clash. Resolving such conflictsis a manual, and thus error-prone, process which may leadto further inconsistencies.Blackholing allows networks to counter the frequent Dis-tributed Denial of Service (DDoS) attacks that ASes face.Legacy blackholing allows an AS to request neighbors todrop packets towards a certain IP prefix. Unfortunately, theapproach is rather deficient: it has not the adequate granu-larity (exclusively destination-based) and fails to distinguishbetween legitimate and malicious traffic: all packets des-tined for the blackholed IP prefix are dropped, thus discon-necting its upstream networks [4].2. DEMONSTRATION DESCRIPTIONWhile past SDX examples, such as [5], consider IXP topolo-gies with a single hop, ENDEAVOUR extends previous ef-forts to work in multi-hop topologies, where members areconnected to edge switches and the traffic is aggregated withmultiple core switches. This is a fairly common configura-tion, as the DE-CIX and AMS-IX examples show. The im-plementation distributes the member’s policies across the re-spective edge switches. While outbound policies are presentonly in the respective participant edges, inbound policies areinstalled in every edge switch because the decision processoccurs in the first hop. When the edge resolves the next hop,a labeling mechanism encodes the path of the packet to fol-low in the fabric. We showcase the ENDEAVOUR capabili-ties with a virtual environment created on Mininet.2.1 SDN-enabled Traffic EngineeringSDN improves Traffic Engineering operations at IXPs bygoing beyond the exclusively IP destination-based approachof BGP. As we show in this demo, SDN allows networksto steer traffic flows according to layer 2-4 attributes. Thedemonstration of the SDN-enabled Traffic Engineering fea-tures four IXP members connected to different edge switchesin an edge-core-edge topology. Members have outbound andinbound policies configured. We show the fine-grained sys-tem capabilities over a multi-hop architecture, by enablingan outbound policy to direct traffic on port 80 to a designatedmember. By leveraging the ENDEAVOUR monitoring capa-bilities, graphical statistics are displayed to show that trafficflows accordingly to the established polices.2.2 Advanced BlackholingSDN helps to overcome the mentioned limitations in black-holing by allowing operators to specify fine-grained droppolicies and automating the blackholing process, hence re-ducing response time and overhead. The IXP can providean interface, e.g., an API, for the members to express theirprecise drop rules and have them automatically implementedas an attack is detected. The IXP can also provide insightsin the blackholed traffic by monitoring it through the Open-Flow counters. While some traffic might still be uninten-tionally blackholed, OpenFlow rate-limiting capabilities canalleviate the problem by limiting the traffic (based on spe-cific header fields) towards the attacked members.This demo demonstrates Advanced Blackholing in a topol-ogy setup comprising three IXP members connected to theIXP’s fabric. Initially, we show a set of traffic flows. Overtime, one member activates a set of different blackholingpolicies, affecting traffic destined to the destination port 53.The policies are translated into flow rules which are then in-stalled within the IXP fabric, as a result; matching trafficflows are discarded. In contrast to commodity blackholing,the blackholed traffic is still visible. Finally, the installedrules are removed and the traffic returns to its initial pattern.Videos are available at https://youtu.be/6_adVvSJ7FAand https://youtu.be/enm_17jbEvs.Acknowledgments: This research is (in part) supported byEuropean Union’s Horizon 2020 research and innovation pro-gramme under the ENDEAVOUR project (grant agreement644960).3. REFERENCES[1] B. Ager, N. Chatzis, A. Feldmann, N. Sarrar, S. Uhlig, andW. Willinger. Anatomy of a Large European IXP. In SIGCOMM.ACM, 2012.[2] I. Castro, J. C. Cardona, S. Gorinsky, and P. Francois. Remote Peering:More Peering without Internet Flattening. In CoNEXT. ACM, 2014.[3] M. Chiesa, C. Dietzel, G. Antichi, et al. Inter-domain NetworkingInnovation on Steroids: Empowering IXPs with SDN Capabilities.IEEE Communications Magazine, 54(10):102–108, 2016.[4] C. Dietzel, A. Feldmann, and T. King. Blackholing at IXPs: On theEffectiveness of DDoS Mitigation in the Wild. In PAM, 2016.[5] A. Gupta, R. MacDavid, R. Birkner, M. Canini, N. Feamster,J. Rexford, and L. Vanbever. An Industrial-Scale Software DefinedInternet Exchange Point. In NSDI. USENIX, 2016.

SDN-enabled traffic engineering and advanced blackholing at IXPs

https://www.repository.cam.ac.uk/bitstream/handle/1810/279203/sdn-te.pdf?sequence=1&isAllowed=y

SDN-enabled traffic engineering and advanced blackholing at IXPs

Abstract

Similar works

Full text

Available Versions

Apollo (Cambridge)