1

On the State of the Inter-domain and Intra-domainRouting Security

Mingwei ZhangUniversity of Oregon, Eugene, OR, USA

Email: mingwei@cs.uoregon.edu

Abstract—Routing is a key component for buildingan interconnected network architecture. There are inter-domain and intra-domain routing protocols. The inter-domain routing protocol has experienced increasinglyfrequent anomalies, such as IP prefix hijackings, routeleaks, or impact from large-scale disruptive routing events.The intra-domain routing also suffers from various attacksoriginated from within an autonomous system, such astopology manipulation and host-based flooding attack.Security upgrades to the existing protocols and accuratedetection mechanisms have therefore been proposed andexperienced. In this study, we conduct a comprehensivesurvey on the existing security mechanisms for both inter-domain and intra-domain routing protocols. For inter-domain routing protocol, we study the de facto protocol –Border Gateway Protocol (BGP). For intra-domain routingprotocol, we investigate the recent software-domain net-working paradigm and the OpenFlow protocol. For eachrouting protocol, we investigate both attack preventionsolutions and attack detection solutions. We summarizethe strengths and weaknesses of every existing solution,and discuss the missing gaps that need further research.

I. INTRODUCTION

The Internet consists of many domains, each of whichhas autonomous control over its own networking in-frastructure. Such domains are also called AutonomousSystems (ASes). People designed routing protocols toconnect hosts and routers within one domain and ex-change information between domains. The routing pro-tocols can be categorized into inter-domain and intra-domain protocols. The inter-domain routing protocolsaim to exchange routing information between domains,allowing each domain to decide the routes toward anydestinations on the Internet. The de facto routing proto-col for inter-domain routing is Border Gateway Protocol(BGP) [1]. The intra-domain protocols exchange reach-ability between different networking devices within onedomain (AS). Traditional intra-domain routing protocolsinclude RIP [2], OSPF [3], IS-IS [4], EIGRP [5], etc. Therecently emerged new routing paradigm, the software-defined networking (SDN) [6] and OpenFlow [7] are

Fig. 1: An example of inter-domain and intra-domainrouting.

quickly getting adopted due to their features such asprogrammability, unified interface, and centralized con-trol mechanisms. Network operators can also implementtraditional routing protocols on a SDN platform. Suchfeatures make SDN and OpenFlow more preferable tothe traditional protocols. Fig. 1 shows an example ofinter-domain and intra-domain routing, where machineA talks to machine B, and the traffic travels through aset of routers. The routing from router 1 to 4 is withinAS1 and is intra-domain routing; while the routing fromrouter 4 to 7 is inter-domain routing.

As the Internet relies on the routing protocols forits normal operations, it is very important to ensurethe routing protocols are secure against security threats.Unfortunately, neither intra-domain nor inter-domainrouting protocols are bulletproof against various threats.In this report, we closely examine the security propertiesand the existing security solutions of both protocols.Specifically, we examine BGP as the main inter-domainrouting protocol, and examine SDN and OpenFlow asthe representative of the intra-domain routing protocol.

Regarding the security for inter-domain routing, orig-inally BGP was not designed to carry many securityproperties. The Internet experienced a number of inter-domain anomalies such as IP prefix hijackings, large-scale route leaks, or Internet “earthquakes” caused by

2

various reasons. BGP is designed with the assumptionthat everyone on the Internet does not act maliciously,and it lacks sufficient verification mechanisms for theupdate messages. However, such an assumption doesnot hold anymore in today’s Internet. Numerous routingincidents show that even some Internet providers atnational level conduct malicious activities on the Internetand pose severe security and privacy threats to Internetusers [8], [9], [10], [11].

Regarding the security for intra-domain routing, SDNalso suffers from severe security problems. SDN archi-tecture consists of the end-hosts, switches, controllers,and applications, and each component could suffer fromsecurity attacks. The applications running on top of thecontrollers may encompass security loopholes or mali-cious exploits; the controllers can be made unavailableto legitimate needs when receiving a large number offake requests; the switches can be compromised to actmaliciously when forwarding traffic; and the end-hostscan also exploit the loophole in OpenFlow and disruptthe SDN controllers.

In investigating BGP and SDN security solutions, wefocus on analyzing their strengths and weaknesses, aswell as their deployment status on the Internet. We cate-gorize the security solutions into two general categories:the attack prevention solutions and the attack detectionsolutions (Fig. 2). The attack prevention solutions aimto proactively stop potential attacks through securityupgrade of either the protocol design or the protocoloperations. Meanwhile, the attack detection solutionsaim to reactively detect abnormal events regarding theoperation of the protocols, providing triggers for timelyreaction to such events. The attack prevention mecha-nisms for BGP have been heavily studied for a long time.However, none of these mechanisms has been largelydeployed to date, leaving the Internet still vulnerable tothe inter-domain routing attacks. On the contrary, sinceSDN is still young, the majority of the SDN securitywork look at attack prevention, with the attack detectionfor SDN less explored.

This report is organized as follows. We survey theexisting BGP attack prevention solutions in section III,and review the main BGP attack detection mechanismsin section IV. In section V, we look at the solutionsthat try to secure the SDN architecture and operations.Section VI is then focused on how SDN can be appliedto solve other security problems. At last, in section VIIwe summarize the survey and discuss some related issuesabout the security of Internet routing.

Fig. 2: Internet routing security taxonomy.

II. BACKGROUND

Internet routing security has been a hot research topicssince late 1990s. There are many related projects that tryto improve the security of the Internet routing, from theinter-domain (BGP) and intra-domain (SDN) perspec-tives. In this section, we provide some background ofthe BGP and SDN security research in general.

A. BGP Security

The Internet started with only a few connected net-works for research and military purposes. Until late1980s, there was no clear definition of the autonomoussystems (ASes). This lack of domain-level hierarchyhindered the scalability of the Internet. In 1989, thefirst version of Border Gateway Protocol (BGP) wasproposed. BGP clearly defines the concept of AS andthe operations between ASes for exchanging routing in-formation. Since then, the Internet started the exponentialexpansion.

However, the BGP is not perfectly secure. In 1998,Labvotiz et al. first studied the instability of the Internetrouting. This paper is one of the earliest papers thatstudied the vulnerabilities of the Internet. Researchersalso discovered two major attacks that can severely dis-rupt the Internet: prefix hijacking and AS path spoofing.Fig. 3 shows the examples of these two attacks. Since2000, there were many projects focused on preventingsuch attacks on BGP (Fig. 4): S-BGP [12] in 2000,soBGP [13] in 2002, IRV [14] in 2003, SPV [15] in2004, psBGP [16] in 2005. These projects showed thatBGP operations can be secured with upgrades of theprotocol and the operations.

However, all of these projects relied on certain infras-tructure to distribute the routing information securely. Itwas not until the establishment of Resource Public KeyInfrastructure (RPKI) in early 2010s do the BGP securityprojects have such a reliable infrastructure to submit andaccess verifiable routing information. With the deploy-ment of RPKI, BGPsec was then proposed and quickly

3

(a) An example of a BGP prefix hijacking attack (b) An example of a BGP AS path spoofing attack

Fig. 3: Examples of BGP prefix hijacking and AS path spoofing attacks

S-BGP

soBGP

IRV

SPV

psBGP

RPKI

BGPsec

2000 2005 2010Year

Fig. 4: Timeline of the major BGP attack preventionprojects.

being deployed. Unfortunately, the deployment rate ofRPKI and BGPsec is still far from sufficient to date.With the low deployment rate, the aforementioned BGPattack prevention solutions cannot effectively prevent thestop the attacks on BGP. As a result, it is very importantfor people to be able to detect and react to the attacksquickly and accurately.

B. SDN Security

Software-defined networking is a very new networkingtechnology, and has not yet been recognized as the defacto approach for intra-domain routing. However, webelieve SDN is the future of the intra-domain routing.First, it is fully compatible with all the traditional intra-domain routing protocols. Using the centralized approachfor controlling the network, a network operator can im-plement any existing or new routing protocols as appli-cations running on the controller. Second, the separationof the control logic and forwarding actions makes SDNcan not only achieve the goal of the traditional routingprotocols but also many other new tasks. These featuresmake SDN very popular among the large networks,where the operators require maximum flexibilities ofthe networking functionalities as well as the centralizedmanagement over the entire network.

In terms of security, researchers have discovered sev-eral new attacks on SDN. In section V, we examinethe main security solutions against the attacks. However,

there are also many security aspects that are yet to bestudied. Instead of securing SDN itself, there are severalprojects that use SDN for securing the Internet, suchas conducting anomaly detection or defending againstDDoS attacks. In section VI, we also investigates theapplications of SDN on solving other security problemsof the Internet.

III. BGP ATTACK PREVENTION

The design of Border Gateway Protocol (BGP) wasbased on the assumption that all the autonomous systems(ASes) are trustworthy. The assumption no longer holdsas we have seen an increasing frequent appearance ofthe malicious attacks on the Internet carried out by ASesthat exploit the loopholes in BGP. The current version ofBGP allows ASes to announce origination of any prefixeswithout authentication (Fig. 3a), propagate routes withmanipulated path information(Fig. 3b), or even send outentirely forged routing information. Due to the lackof verifiable global routing information, an AS cannoteffectively verify the information received from otherASes, and can only rely on its own knowledge aboutthe legitimacy of the updates, which has proven to beineffective by the repeated occurrences of the maliciousattacks and misconfigurations.

Researchers have proposed multiple solutions rang-ing from cryptographic to multi-party collaborative ap-proaches to securing the BGP operations and preventingthe attacks entirely. In the following subsections, we in-troduce the design and core ideas of the majority optionsof attack prevention mechanisms. For each mechanism,we also discuss its essential drawbacks and its deploya-bility. At last, we discuss the overall future of the attackprevention mechanisms.

A. Overview

From the main technology used, the main attackprevention system can be categorized into three types:

4

method control-plane crypto-based overhead data source path origin deploymentBGPSec [9], [12], [17] X X high PKI X X XsoBGP [13] X X high peer X XpsBGP [16] X X high peer XSPV [15] X X low registry XListen & Whisper [18] X X medium peer X XRAVS [19] X X low peer X XIRR X low registry X XIRV [14] X medium peer X XGTSM [20] low N/A XTCP MD5 Sig. [21] low N/A XIPSEC [22] medium N/A X

TABLE I: BGP Attack Prevention Mechanisms

1) control-plane cryptographic approaches,2) control-plane non-cryptographic approaches, and3) data-plane-based approaches.

The control-plane approaches aim to secure the control-plane information exchanged among ASes, while thedata-plane approaches focus on securing the communi-cation channel between the BGP routers. The control-plane-based solutions can also be coarsely categorizedinto cryptographic and non-cryptographic approaches.Table I lists the current main BGP attack preventionsystems. The method column represents the name ofevery attack prevention mechanism; the control-planecolumn indicates if the method mainly operates onthe control-plane; the crypto-based column shows if amethod applies cryptographic approaches or not; theoverhead column represents the operational cost of eachmechanism, ranging from low to high; the data sourcecolumn indicates the type of data sources used by thesemethods; the path and origin columns show that whetherthe approach can secure the AS paths and prefix originof the BGP updates respectively; and the deploymentcolumn shows if the method is currently being deployed,regardless of the deployment ratio.

B. Prevention Without Cryptography from the ControlPlane

We start our survey for BGP attack prevention meth-ods by investigating the prevention mechanisms that donot heavily depend on cryptographic methods. Specif-ically, we examine two main methods in this area: theInternet Routing Registry (IRR), and Inter-domain RouteValidation (IRV). IRR uses centralized trusted databasesto maintain and offer access of correct routing informa-tion; IRV enables active queries for the correctness ofBGP updates, trusting each AS to provide the accuraterouting information about itself. In this following sub-section, we closely investigate theses two methods andanalyze their strengths and weaknesses.

1) Internet Routing Registry (IRR): People first builtthe Internet Routing Registry (IRR) to serve as generalrepositories of routing information, connectivity, androuting policies. IRR consists of several databases wherenetwork operators publish their routing policies and an-nouncements so that other network operators can utilizethe data. The information includes ASes’ relationshipswith other ASes, the routes learned and propagated fromother ASes, the preferences if multiple routes exist, etc.Such information is structured into data objects usingthe Routing Policy Specification Language (RPSL) [23],[24]. Network operators can verify each BGP updateagainst the known routing information obtained fromIRR databases.

However, IRR suffers from out-of-date information.The information in IRR databases may be accurate atthe time of submission, but this may not be true by thetime users access the information. The organizations donot have enough motivation to keep their IRR recordsup to date, especially for those ASes that update routinginformation frequently. Users of IRR information thuscannot confidently decide if the suspicious BGP updatescontains anomalous information or simply newer legiti-mate information. Despite the weakness, researchers stilluse IRR on various topics [25], [26], [27], [28]. Signaoset al. even evaluated the efficacy of using the inaccurateIRR and claimed that it is still very helpful [29]. How-ever, such weakness makes IRR less reliable in termsof verifying BGP information. As a result, people haveto seek other approaches to obtaining authentic BGPinformation.

2) Inter-domain Route Validation (IRV): In the globalregistry model used by IRR, ASes do not have enoughmotivation to update a third-party registry of regardingtheir routing information. To address this shortcoming,Goodell et al. proposed the Inter-domain Route Vali-dation (IRV) [14] architecture that extends the existingmodel into per-AS routing registry. IRV provides out-of-band verification information using a query-based ap-

5

proach. It defines an information distribution protocol forASes to exchange routing data with each other withoutthe involvement of a third party. Each IRV-enabled ASimplements an IRV server that stores all local routinginformation. The routers that receive BGP updates canquery the IRV servers of the ASes on the path to validatethe information. Upon receiving a query, the IRV serverwill respond based on its local policy. Since every IRVserver resides within each AS, the information can bekept up-to-date with minimum cost.

IRV also has a set of issues that were not specified inthe paper. First, the discovery of an IRV server withinan AS is not clear. A querying AS does not necessarilyknow every IRV servers’ IP addresses. However, theauthors did not introduce any mechanism for an AS todiscover the IP addresses of other ASes’ IRV servers,Second, the message authentication of the IRV query andreply was not specified, leaving it possible for attackersto forge illegitimate IRV messages. Third, in partialdeployment scenarios where only a set of ASes on theInternet enables IRV, a querying AS can only verify aportion of the AS path.

C. Prevention with Cryptography from the Control Plane

The majority of the BGP attack prevention systems tryto secure the assets (prefix origin and AS paths) throughcryptographic approaches. The main argument behindthis is that there are hardly any trustworthy verificationsources that an AS could refer to, leaving fewer optionsbut to establish and use cryptographically-secured datasources. In this subsection, we survey the main attackprevention solutions that use cryptographic approaches.To date, BGPsec is the only BGP security upgradethat has been deployed on the Internet. Though thedeployment rate is still bleak, we could foresee a betterscenario in near the future. In the rest of this subsection,we look at other attack prevention solutions proposedprior to BGPsec, but not deployed on the Internet.

1) RAVS: Kim et al. proposed a solution with veri-fiable search called Identity-based Registry with Au-thorized and Verifiable Search (RAVS) [19]. RAVSfeatures the following capabilities that out-performs theIRR method. First, it enables public key exchange cryp-tographically transform the AS number to the public keyof each AS. This allows every AS to easily authenticateitself to the RAVS system without requiring a globallydeployed public-key infrastructure. Second, RAVS usesSearch Permission Generator to control search permis-sions based on AS credentials. Only the authorized ASescan query the registry. Third, every search result canbe verified cryptographically. All entries in the RAVS

Fig. 5: An example of querying RPKI for prefixownership information.

database are signed with the private key of the ownerASes, allowing other ASes to verify them with the publickey of the owner ASes. Such scheme allows RAVSto provide verifiable routing information to the ASes.Unfortunately, RAVS has never been adopted on theInternet.

2) RPKI: As another attempt to construct a trustwor-thy database for routing information, people proposedand built Resource Public Key Infrastructure (RPKI).The main purpose of RPKI is to provide a centralizedrepository for all resource-related information with cryp-tographic protection. One of the main types of resourceis the ownership information of IP prefixes.

As discussed in section III-A, one of the main threatstoward the Internet routing is prefix hijacking (Fig. 3a).Exploiting the lack of verification mechanism in BGPprotocol design, the attackers can send announcementsto claim the ownership of any prefixes, or to change theAS-level path toward a target prefix. In an ideal scenariowhere every AS on the Internet knows the legitimateowner of every IP prefix, forged announcements fromthe attackers will not be propagated. However, in realworld scenarios, it is hard, if not impossible, to obtain thecorrect and up-to-date prefixes ownership information.

RPKI is a public key infrastructure specifically de-signed to store and provide information of the resources(or assets of ASes) on the Internet. RPKI is not intendedto replace the current IRR system, but to provide extrasecurity property for the information. For example, whenan BGP router received an announcement of a prefixB originated from AS X , the router can query RPKIrepository (or a local cache) for the ownership informa-tion of this prefix, and then verify the correctness of theinformation (Fig. 5). The result could be valid, invalid,or unknown. Based on the verification result and localsecurity policy, the receiving router can then make therouting decision. Wahlisch et al. [30], [31] describedthe procedure of detecting suspicious prefix ownershipchanges, and Huston et al. [9] also provided a morecomprehensive description of RPKI architecture and itsusage.

However, RPKI is also facing a number of problems.The first problem is the scaling issue. To date, RPKI

6

Fig. 6: An BGPsec AS path protection example.

only covers less than 10% of the IP space. Through aset of calculation, Osterweil et al. estimated that the sizeof RPKI with full deployment will consist of 650,000encrypted objects [32], which will incur a more than 4day time overhead for a full synchronization. If considerthe key rollover cases, the overhead would be evenhigher. The second problem is that RPKI system itselfcan also be abused to take down prefixes. The revocationof any objects does not need any acknowledgement fromthe current prefix owner [33]. In [34], Heilman et al.proposed a set of countermeasures to maintain countableRPKI operations with explicit acknowledge responses forevery potential damaging operations. Nonetheless, RPKIis still considered to be the best information source forBGP security mechanisms.

3) BGPsec: With RPKI protecting the prefix origininformation, BGPsec (originally S-BGP) is proposed tofurther ensure that the path toward any prefixes is alsoprotected [9], [12], [17]. First, in every BGP updateannouncing a new AS path to a prefix, the path segmentsin the AS path are protected with a signature fromeach hop along the path that the update propagated. Arouter receiving a BGP update can check the signature-packed “BGPsec Path” attribute. Each signature anyhop appends also contains a “Subject Key Identifier”that uniquely represents a router or AS’s identity inthe RPKI, which the receiving party can use to verifythe signature. Fig. 61 shows an example where AS1originates an update for prefix 10.0.1.0/24, propagatesthe update to AS2, and AS2 propagates it to AS3. Oneach propagation, the AS in question will sign the ASpath content. The receiving AS (AS3) can validate allthe signatures from every AS on the path and validatethe entire AS path.

BGPsec is considered the best and most practical

1http://www.cisco.com/web/about/ac123/ac147/archived issues/ipj 14-2/142 bgp.html

solutions toward securing BGP; however, it still facesseveral challenges. Lychev et al. argued that with the un-avoidable stage of partial deployment, BGPsec provides“only meagre benefits over origin authentication whenthese popular policies are used” [35]. To accommodateits legacy next-hop routers, a router running BGPsechas to downgrade its protocol to legacy BGP, and thuslose all the cryptographic protections provided by theprevious hops. Once the downgrade happened at onehop along the propagation, previous signed signatureswill no longer be available to the downstream ASes,neither can the downstream entities continue to useBGPsec to partially sign the path. In [36], Li et al.presented two types of attacks that work even whenBGPsec fully deployed: the wormhole attack and themole attack. The wormhole attack shows that BGPseccannot tell or defend fake BGP links created by tunneledBGP sessions. With the help from the others, an attackercan effectively announce a totally legitimate path to thetarget victim with shorter path length. The mole attackexploits the fact that some ISP would rent IP prefixesfrom its provider and not utilize them with a defaultforwarding path in place. An attack could exploit suchsituations by simply sending traffic to the unutilizedprefixes to generate a loop of traffic. Such loop of trafficcan eventually saturate the link between the victim ASand its provider.

4) Other Cryptographic Solutions: As discussed pre-viously, the only BGP security upgrade that has beendeployed to date is BGPsec. There are several othersolutions proposed before BGPsec that have not beenadopted, including soBGP [37], psBGP [16], andSPV [15]. Unfortunately, none of these approaches havebeen widely deployed to date. We investigate thesemethods and in the rest of this section.

In 2003, White et al. [37], [13] proposed soBGP thatuses cryptographic certificates to prevent forged prefixorigin announcements and invalid AS path updates. Ev-ery AS that deploys soBGP should obtain an “EntityC-ert” certificate to authenticate its own identity to others.To secure the prefix origin information, soBGP usescryptographic certificates, “AuthCert”s, to provide ver-ifiable announcement of prefix ownerships. To announcethe ownership of a prefix, an AS needs to obtain an“AuthCert” from a trusted third party. The AS can thenannounce the prefix with the corresponding “AuthCert”attached to the update, and sign the announcement withits own private key. A receiving router can verify theannouncement by validating the signatures of the updateand the “AuthCert” attached. To enable the validation ofthe AS path updates, soBGP requires all enabled ASesto broadcast AS relationship information using another

7

certificate, “ASPolicyCert”. The relationship informationof an AS includes the identities of neighbor ASes, andthe policy for each neighbor AS. An “ASpolicyCert”essentially asserts the feasibility of an AS to forwardtraffic to other ASes. Each soBGP enabled AS will buildits own Internet topology based on the “ASPolicyCert”obtained from the broadcast, and then validate the ASpath updates against this topology. For example, ASA must first announce that it connects to AS B using“ASPolicyCert” before it can propagate any BGP updatescontaining the link between A and B..

Comparing to BGPsec or BGPsec, the advantage ofsoBGP is the relatively low overhead. After building thetopology and the prefix ownership information, an AScan then validate all BGP updates using its own datawithout active query even during partial deployment.However, the solution relies on the assumption thatASes can reliably distribute (or broadcast) the policyinformation as well as the identity information of theASes (such as the public keys of the ASes). Without areliable information distribution mechanism like RPKI,soBGP is not able to deploy on the Internet.

In 2005, Wan et al. introduced Pretty Secure BGP(psBGP) [16] that utilizes a decentralized trust modelfor verifying IP prefix ownership. To announce theownership of a prefix, an AS needs to send out anownership assertion signed with its own public keyand distribute to its neighbor ASes. When receiving anassertion, an AS will decide whether to propagate suchassertion to its neighbors based on its own judgment.The number of assertions from the prefix owner andits peers indicates its level of authenticity. Similar toBGPsec, the path verification is done by validating a setof signatures attached by the ASes along the propagationpaths. Different from BGPsec, psBGP allows partial pathsignatures using a confidence value for the validation,which reflects how likely a path is valid.

psBGP is essentially built upon a AS-level reputationsystem, which assumes the infeasibility of construct-ing a hierarchical PKI system for resource assertions.However, the reputation system would result in inde-terministic decisions in many cases. The verification ofthe AS paths in BGP updates is also dependent on thedecision logic of the confidence system, and potentiallycould be manipulated by the resourceful attackers. Thus,psBGP could be applied as a secondary route verificationmechanism, but not a reliable method preventing therouting attacks.

In 2004, Hu and Sirbu introduced Secure Path Vector(SPV) [15], proposing to use symmetric cryptographyto secure the BGP updates. The main goal of SPV isto secure BGP updates against AS path fabrications, in-

cluding forging whole AS paths or modifying partial ASpath segments. SPV uses tree-authenticated hash valuesfor AS path validation. First, the prefix owners needsto have the knowledge of the private key associate withthe prefix. The distribution of the prefixes’ public/privatekeys is proposed to done in places like ICANN. Then,the prefix originator announces the prefixes with a set ofone-time signatures together with the private keys forthem. During each propagation, the sending AS signitself into the ASPATH using the private key for thesignature. The receiving AS can verify the ASPATHwith all the one-time signatures through a hash-treestyle authentication. Since the private keys was used andremoved, the attacker cannot recreate the key and thuscannot replace a previous AS number with its own. Toensure the security of the constructed verification tree,SPV requires the originator periodically re-announce theprefixes.

Comparing to the BGPsec, the authors claim thatSPV achieves significantly performance improvementby changing nested digital signature authentication withhash-tree-authentication. The performance improvementcomes from the computational complexity differencebetween symmetric and asymmetric cryptography usedin SPV and BGPsec. Though with some performanceimprovement against BGPsec, SPV still suffers somesevere problems. First, the re-announcement frequencycould greatly affect the overall traffic and computationalload on the BGP routers, which was not taken intoconsideration in their evaluation. Second, the “epochs”of verification trees require a higher level of time-synchronization. Also, as discovered in [38], SPV cannotfully protect BGP against route forgery and eavesdrop-ping.

D. Prevention from the Data Plane

There are some other methods that prevent attacksfrom data-plane level, including IPSEC, TCP MD5 field,and Generalized TTL Security Mechanism (GTSM).These methods focus on protecting the data-plane com-munications between different routers, and are BGPcontent agnostic.

TCP MD5 Signature Option [21] is a light-weightmethod to protect the integrity of the packets. In the caseof BGP operations, TCP MD5 signature could preventEach communication will start with a generation ofsecrets between the two parties. Then they will sendthe TCP packets with a MD5 signature of the packetusing the secret. When receives a packet, the router willcalculate the MD5 signature and compare it with theone attached in the packet. Without the correct secret,

8

the signatures will not match. Therefore, an attackercannot easily impersonate another router using forgedBGP packets.

IPSEC [22] is a suite of protocols that operate atthe IP level to secure the communications between end-hosts. It is a relatively heavy-weight toolkit comparingto the MD5 option. The suites include the cryptographicprotection on both the packet header and the packetcontent. Using IPSEC, a router could talk with the peerswithout being vulnerable to eavesdropping or packetmanipulation. However, the processing overhead of usingIPSEC to detect malicious packets is much higher thanMD5 [39]. This high computational overhead could beexploited for conducting denial of service attack. Anattacker can send a large volume of forged IPSECpackets to overload a BGP router, and thus downgradeor even disrupt the normal operations of the router.

The Generalized TTL Security Mechanism(GTSM) [20] is another type of security methodthat protects the communication from topologicalperspective. Knowing the distance of a BGP peer router,GTSM configures each BGP packet with TTL to be255. Any inbound packets with TTL less than specificthreshold will be discarded. In the case of directlypeered BGP routers, any incoming packets with TTL of254 or less should be discarded. This method effectivelyprotects the BGP session from the potential intrusions.However, in the case of remote peering, the BGP routersare not directly connected and forcing TTL restrictioncould affect the legitimate connections if any routingchanges happen.

IV. BGP ATTACK DETECTION

Ideally, with full deployment of some aforementionedmethods such as BGPsec, the inter-domain routing couldbe fully secured. However, it has been shown that noneof the security solutions is bulletproof against attacks.Besides, the cost of operations, the uncertainty about theeffectiveness, and the lack of motivation also hinderedthe overall deployment progress. Before a more secureBGP security solution is widely deployed on the Internet,network operators and users have to keep fighting withthe existing and new security concerns of BGP. Inparticular, it is important to be able to detect all kindsof attacks and react to them timely. Table II presents ataxonomy of the current solutions on BGP attack detec-tion. From their data sources, we categorize the solutionsinto three types: control-plane-based mechanisms, data-plane-based mechanisms, and hybrid mechanisms whereboth control-plane and data-plane information is utilizedto obtain a higher detection accuracy.

The majority of the solutions are control-plane basedin that they obtain the input data from the control-planemessage collectors or through querying on third-partyrepositories. We define the passive monitoring solutionsas the methods that detect attacks by passively collectingand processing the control-plane information. On thecontrary, the active monitoring solutions require activequeries to third-party registries and construct knowledgedatabases from different data sources.

In this section, we survey the major inter-domainrouting attack detection methods, including the control-plane, data-plane, hybrid methods and a number of attackverification mechanisms as well. We summarize eachmethod and describe their key idea, strength, weakness,performance, and their relationship with other methods.

A. Passive Monitoring from the Control-Plane

Most BGP attack detection solutions monitor anddetect attacks by passively listening to the control-planeinformation. Based on the types of attacks they try todetect, these attack detection solutions can further becategorized into prefix hijacking detection solutions andBGP dynamics attack detection solutions. The prefixhijacking detection solutions examine each individualprefix path updates and detect suspicious changes ofpaths toward or origination of specific prefixes. On theother hand, rather than focusing on each individualprefix, the BGP dynamics anomaly detection solutionsdetect unusual changes of routing dynamics on theInternet. Such changes may indicate the impact fromlarge-scale disruptive events for Internet routing. In thissubsection, we will look at the detection solutions onboth types.

1) Prefix Hijacking Detection: Lad et al. introducedthe prefix hijack alert system [53], i.e., PHAS. Theauthors argue that the prefix owner is the only one whocan accurately distinguish between legitimate changesand prefix hijackings. Thus, PHAS was designed toprovide the prefix owners the quick notifications on anysuspicious prefix origin changes. PHAS uses a registra-tion system that allows the prefix owners to obtain theinformation about any changes to the prefix origins. Theauthors use the concept of origin set to accommodate thetraffic engineering needs for the users. Each origin setconsists of a set of origins observed from the monitorswithin a time window t. Any changes to the origin setwill trigger alerts to the users. The authors also men-tioned several modifications to the algorithm to reducethe total amount of the notifications to the subscribers.Overall, PHAS is a simple solution to detect AS originchanges and relies on the prefix owners to determine the

9

method control-plane data-plane anomalyactive passive active passive verification

NeighborWatch [29] X XTERRAIN [40] X XsubMOAS [25] X XKruegel et al. 2003 [41] X X XBuddyguard [42] XI-Seismograph [43] XGeo-location [44] XArgus [45], [46] X X XWavelet [47], [48] XBGP-lens [49] XBGPeye [50] XConcurrency-based [51] XMachine-learning-based [52] XPHAS [53] XPGBGP [54] Xrcc [55] X XTopology-based [56] XTAMP [57] XListen and Whisper [18] X X XHost-signature based [58] X X XHop-distance based [59] XiSPY [60] XCrowd-based [61] XLDC [62] XPurgePromote [63]

TABLE II: Taxonomy of the attack detection methods

natures of the changes. Though easy to implement anddeploy, the notification could be only useful and verifiedby the prefix owners. This method also fails to detect anymalicious AS path segment changes other than the prefixorigin changes. For example, any AS path shorteningattempts by the attacker will not be detected by PHAS,allowing the attackers to “steal” the traffic to the prefixeswithout changing the originating ASes.

Pretty Good BGP (PGBGP) solution in [54]was another attempt to detect suspicious prefix originchanges by building and utilizing a prefix-origin bindingdatabase. During the training phase of consecutive hdays, the system learns from a router’s routing tablefor all existing prefixes and their originating ASes. Allthe prefix-origin pairs will be accepted by PGBGP andlogged into a database. During the operational phase, allthe new prefix-origin pairs unseen before will be labeledas suspicious for a period of s. If the route stays inthe RIB after a period of s, the route will be labeledas normal and logged into the database. A suspiciouspath should have the lowest priority in the path selectionof a PGBGP-enabled router. Thus, a suspicious path’spropagation will be delayed for at least a period of s.Comparing to PHAS, PGBGP further protects BGP bydelaying suspicious updates rather than just generatingnotifications. Similar to PHAS, this solution does not

consider the AS path forgery attacks. The quarantinemechanism also potentially poses a long delay for anylegitimate change of prefix origin. Considering the chainof delay along the propagation, the overhead is not negli-gible, making this method less favorable for deployment.

Qiu et al. proposed a control-plane-only detectionmechanism that looks further beyond the prefix-ASbinding, and consider AS-AS pairs as another importantmetric [56]. The basic observation is that the prefixand origin AS bindings and the peering ASes bindingsare relatively stable over time. The authors believe thatthe prefix ownership and topological information learnedfrom the BGP RIB table can be applied to identify bogusroutes. For each path change, the system will look atthe prefix-origin pair and the directional AS-AS pairs.Only when both types of bindings have been seen beforecan this change be valid. Similarly, the Argus systemproposed by Xiang et al. also uses the prefix-AS andAS-AS bindings to detect suspicious BGP updates.

There are two main problems for both methods. First,both methods rely on the assumption that there are noattacks during training period. However, there is no reli-able way to identify training period without any attacks.If there are attack updates during the training period,these updates will not be identified as suspicious duringmonitoring periods. Second, it requires a long trainingperiod for the methods to build a relatively complete

10

database for prefix-AS and AS-AS bindings. Study byRexford et al. shows that the vast majority of prefixes ofthe popular websites have the update interval of five ormore days on average [64]. To capture the BGP updatesof such prefixes, the systems need to have training periodfor weeks or even month. This significantly increases thetime overhead of running these detection systems.

Li et al. [42] introduced a system called Buddyguard,applying the “buddies” concept in detecting maliciousprefix origin changes. Instead of looking at the prefix-ASrelationship, Buddyguard tries to search for connectionsbetween prefixes. The main observation is that wheneverthere is a path update of a prefix, there are some otherprefixes that will also have new paths around the similartime. They call these prefixes the “buddies” of the targetprefix, and found that there are fate-sharing proper-ties among theses prefixes. By using the best “buddy”candidates, Buddyguard can detect unusual changes ofthe path toward the target prefix if the changes donot come with the changes to the buddies. Buddyguardsystem is resilient against intelligent adversaries thattry countermeasures to avoid detection. To counter thedetection from Buddyguard, a prefix hijacker needs tosimultaneously hijack the majority of the buddies of thetarget prefixes, which would be impractical given thatany prefix would have at least hundreds of buddies fromdifferent ASes.

Khare et al. in [51] described a mechanism that detectsanomalies that involve hijacking of multiple prefixessimultaneously. Their basic observation is that “simul-taneously originating prefixes of many other networksis highly likely to be a real hijack.” They developeda scheme that detects “concurrent” hijacks by compar-ing the previous knowledge of prefix origins with thesimultaneous announcements. The system first collectssome basic knowledge about the prefix ownerships usingRouteViews [65], then look for the ASes that offendingthe ownerships within a small time window. They dis-covered about 5 to 20 such events each year from 2003to 2010, and confirmed overall 53 events from 2008 to2010 through direct emails with the network operators.However, this method is limited to detect only the eventswith multiple simultaneous hijackings. An attacker canavoid the detection by targeting only a small amountof prefixes at a time. This method also assume that thetraining period is clean from any attacks, which could befalse in many cases. Besides, this method also does notconsider the AS path manipulation, where the attackerscan hijack traffic by announcing forged shorter AS pathstoward the target prefix. These limitations greatly narrowthe application scenarios of this method.

2) Routing Dynamics Anomaly Detection:Researchers also look at the dynamics of BGP and tryto detect abnormal changes from a global perspective.Zhang et al. [47] applies wavelet transformation tocapture the normal status of BGP dynamics. Wavelettransformation can reveal the temporal structures insignals carried by the dynamics of BGP streams: theindividual updates could be viewed as high-frequencysignals, and the group (or bursty) updates could beviewed as low-frequency signals. By using clusteringalgorithms on top of the wavelet representation, theproposed system can reveal different categories of theBGP dynamics. Using the learned clusters, the systemcould detect any outliers that does not fit into thenormal clusters and thus detect the anomalies. Similarly,Yuan et al. [48] applied the same wavelet-basedapproach for BGP dynamics anomaly detection. Theyassigned deviation score to indicate local noisy levelsand the outliers. Prakash et al. [49] used wavelettransformation to create the “tornado” and “clothline”figures to visually represent the BGP dynamics anddetect anomalies.

In [43], Li et al. introduced an Internet monitoring sys-tem, I-seismograph, that goes beyond hijackings and in-clude all different kinds of events. The system collects allprefixes updates and look for various attributes of BGPupdates such as withdrawal-announcement-duplicates(WAs), announcement-announcement-duplicates (AAs)for prefixes. The attributes are then aggregated todatabins for each minute during training and monitoringperiods, each represented by a 10-dimension data vector.To train the normality model, the system uses all thevectors collected during the training phase and derive themajority cluster from a hierarchical clustering procedure.Databins in the cluster collectively represent the normalvalues for the ten attributes. During monitoring phase,the system will compare databins of very minute duringthe phase with the trained normality model and calculatethe deviation vector of each database. This mechanismdetects large-scale anomalies that generate a global im-pact on BGP.

B. Active Monitoring from the Control Plane

In this subsection, we survey a set of monitoringmechanisms that apply active monitoring for attack de-tection. The active monitoring approaches require activequeries to third-party registries and construct knowledgedatabases from different data sources. Different frompassive monitoring approaches, active monitoring ap-proaches do not need to process BGP information fromthe past for training.

11

Siganos et al. [29] argued that the IRR informationcan still be a good data source to use, despite itsnegative reputation in information correctness and updatefrequency. The authors systematically examined all theIRR databases, and used them as the main data sourcetheir proposed attack detection system (NeighborhoodWatch). The experiment revealed 0 to 3 flags per hour,infrequent enough for administrators to act on them whenthey show up. With careful processing, the informationobtained from the IRR registries is enough for detection.The authors also observed that with more attention toimprove the registry information, the security of BGProuting can be greatly enhanced with the existing registrybased algorithms. As another observation, the authorsalso found that the reaction time for a large-scale eventis as long as hours.

Schlamp et al. proposed to use IRR data and end-hostsinformation in the target IP blocks to detect subprefixhijacking attacks [25]. A subprefix hijacking is morecomplicated to detect since usually there is no BGPannouncement for that specific prefix before. In thispaper, the authors utilized IRR data to obtain prefixownership information and construct AS-level topology.Both the ownership information and topology can beused to determine illegitimate sub-prefix path changes.To further confirm the sub-prefix hijackings, the authorscompares the fingerprints of the machines within the sub-prefix obtained from different periods. An inconsistentcomparison result shows the changes of the physical ma-chines within the network. The authors assume that theweb-servers’ IP addresses are stable, and the SSL/TLScertificates could be used as the fingerprints to identifythe servers. During the training period, system obtainthe public keys of a set of HTTPS web servers reside inthe target sub-prefix. When suspicious changes detected,the system will probe HTTPS servers within the prefixand compare the obtained certificates. An inconsistentcomparison results indicates an ongoing prefix hijacking.The methodology proposed by the authors, especiallythe certificate comparison metric is novel in the attackdetection field. However, running such a system requiresa constant Internet-wide traffic scanning, which would berather hard if not impossible in real-world cases. Theweb-server operators also conduct certificate rolloversfrom time to time for security reasons, which wouldresult in false positive of the detection results.

Kruegel et al. [41] proposed to validate AS pathupdates based on topological and geographical informa-tion. The method classifies the ASes into “core” and“periphery” nodes based on their degree of connectivityin the AS topology. By removing the core nodes inthe topology, the methods can generate a topology with

Fig. 7: An example of detecting BGP anomalous pathswith topological and geographical information.

clusters of periphery nodes. The authors claimed thatthe geographical distances between ASes within a singlecluster are small. The author proposed that a valid ASpath must satisfy the following two requirements. First,the AS path may only contain one single subsequenceof core ASes, conforming to the valley-free routingprinciple from Gao et al. [66]. Second, the peripheryASes must be either in one cluster or on the edgethat connects two clusters. This means for an AS toreach another AS in a different cluster, this AS has totravel through a set of ASes that connects the clusters.The AS link jumps across multiple clusters would looksuspicious, and thus will not be automatically accepted.

In [40] Sriram et al. proposed a comprehensive eval-uation framework, TERRAIN (Testing and Evaluationof Routing Robustness in Assurable Inter-domain Net-working), that compares the existing algorithms for BGPattack detection. TERRAIN investigates the performanceof both active and passive monitoring attack detectionmethods. The authors proposed to enhance the activemonitoring algorithms by validating the consistency ofthe data objects in the registry. They assigned the fol-lowing four labels onto the registry entries based onthe information consistency across data objects: fullyconsistent, only prefix information consistent, only prefixorigination consistent, or not consistent. Based on eachdomain’s security policy, the operators can then decidehow to use the labeled information entries.

The authors also proposed an enhanced passive mon-itoring algorithm. The algorithm classifies prefixes intostable and unstable types based on the frequency of up-dates observed during training period. When suspiciouschanges to the prefixes are detected, the algorithm willdecide the quarantine period length for the suspiciousupdates based on the type of the prefixes, assigninglonger quarantine time to the changes for stable prefixes.To achieve the best accuracy, the authors propose tocombine the enhanced passive and active monitoringapproaches as a hybrid solution.

12

C. Passive Monitoring from the Data Plane

We have discussed plenty of mechanisms that utilizedifferent types of control-plane information to detectanomalies of inter-domain routing. There are also anumber of solutions that use only the data-plane infor-mation to detect inter-domain routing anomalies. Onetype of these data-plane-based solutions is the passivemonitoring solutions. A passive monitoring solution uti-lizes data-plane information obtained through passivemonitoring to detect routing anomalies, which does notneed to send any query or probing packets during theprocedure. In the following subsection, we survey thestate-of-the-art passive monitoring solutions.

Liu et al. proposed a system [62] that detects prefixhijackings by traffic load distribution changes (LDC).LDC monitors the data-plane traffic load distributionfrom any sources on the Internet to the target prefixand detect unusual load shifts. The load distribution isdefined as the ratio between the total number of ASpaths that pass through any specific node and the totalnumber of AS paths available toward target prefix. Theauthors used a clustering algorithm to define the normalload patterns for each prefix at each AS. Any significantdeviation of the traffic load on any AS will trigger alertto notify a potential prefix hijacking. LDC requires atleast one monitor to be deployed at the provider of thetarget prefix to be able to detect anomalies of the prefix,which limits the deployability of this method.

Subramanian et al. designed the Listen algorithm [18]to detect routing anomalies using prefix reachability in-formation obtained through passive monitoring from thedata plane. It passively listens to all the TCP flows, andcherry-picks the segments that are specifically relatedto the establishment of a TCP connection. If Listenobserves more than N incomplete TCP flows within anyspecific prefix, and within a predefined time period T ,then it will alert the operators of the prefix (Fig. 8a). Aflow is incomplete if it begins with a TCP SYN packetbut never receives any SYN-ACK responses. To furtherreduce the amount of false positives, Listens applies twoadditional actions to verify the aliveness of any TCPflow. First, it can actively drop random packets froma specific TCP flow, and observe the retransmission ofthose dropped packets. If no retransmission is observed,it will raise alarm. Second, it can also passively samplethe traffic for a specific flow and observe the ratio ofthe retransmission. If more than 50% of the packets areretransmitted, it will also raise alarm. The two extra stepsprevent adversary from faking a TCP flow. However, thisapproach relies on a main assumption that the detectionsystem is able to listen to the traffic of the monitored

prefix. This assumption requires that the system has tobe deployed at an AS (or ASes) where it carries a largeportion of the traffic toward the monitored traffic. Thisrequirement significantly hurts the deployability of thismethod.

Hiran et al. in [61] proposed a passive data-planeanomaly detection system that applies crowd-sourcingapproach for information gathering. Each end-host thatparticipate in the detection framework will collect round-trip time (RTT) information about all the IPs it interactswith. The information will be shared with other hoststo create a larger picture of the RTTs from and todifferent parts of the Internet. Using the aggregatedRTT information, the system can visualize and detectsuspicious RTT changes of any IPs over time. Theproblem with this method is that RTT is highly sensitiveto any network changes and the nature of the detectedanomalies could be non-malicious. The authors alsoacknowledged that this method should only be usedas a supplementary evidence for the attack detectionmethods. Another problem is that the system requiresparticipations from many end-hosts, which could be veryhard to achieve. There is no clear motivation for end-hosts to participate, and the overhead would go up whenthe nodes become larger.

D. Active Monitoring from the Data Plane

Other than passively monitoring the traffic from thedata plane, there are other BGP attack detection methodsthat apply active probing from the data plane to detectanomalies. Comparing to passive monitoring approaches,the active monitoring approaches only need to conductactive probing at a number of external vantage points,and do not need to have access to the traffic informationof the monitored prefix.

Zheng et al. proposed a distance-based attack detec-tion system from the data plane [59]. The authors definethe distance between two networks as the count of hops(or routers) a packet travels from one network to theother. The system detects the suspicious changes of thedistances from a set of vantage points to the monitoredprefix. For every prefix, the system selects a set ofthe best vantage points that are topologically dispersedfrom each other. The system continuously monitors thedistance from every vantage point to the target prefix.When a suspicious network distance change is detected,the system will then further verify the detection results.During the training phase, the system selects a set of“reference points” of the target prefix, which are differentprefixes that are topologically close to the target prefix.The data-plane path from the vantage points to the

13

reference points should be similar to the path toward thetarget prefix. Upon a potential hijacking is detected, thesystem probes the target prefix as well as the referencepoints of the prefix. If the paths to the prefix and toits reference points deviate significantly, then the systemconfirms the hijacking and alert the users. The authorssuggest that the system can use the prefixes for the directprovider of the monitored prefix as reference points.However, an adversary can also hijack the referencepoints as well to avoid detection. The authors did notfurther investigate how the system should properly locatethe reference points.

iSPY [60] is another data-plane based attack detectionsystem proposed by Zhang et al. that detects the prefixhijackings that reduce the reachability of the victimprefixes. An iSPY system runs within the monitoredprefix, and sends probing messages (such as ping mes-sages) from the monitored prefix to a number of externalnetworks. When there is no attack, iSPY expects toreceive all the return messages of the probes it sends.During an prefix hijacking event, if a external is affectedby the attack, the reply to the iSPY’s probing messagewill arrive at the attacker’s network, thus iSPY will notbe able to receive it (Fig. reffig:bgp-detection-ispy). Ifthe loss of return messages exceeds a threshold, iSPYwill alert the prefix owner of a potential prefix hijacking.

However, there are three problems of this method.First, the unreachability from external network does notnecessarily indicate prefix hijacking. There are manyother types of events can also cause the reply of a iSPYprobing cannot return, such as routing disruption, linkfailure, packet loss, etc. Second, to protect one prefix,the iSPY system for this prefix needs to send probesto about 3000 external networks, which leads to highnetwork overhead. Moreover, iSPY fails to detect prefixinterception attack, where the attacker hijacks the prefixand then continue to forward all the traffic to the victim.In this type of attack, the victim prefix does not losereachability from any external network, and the iSPYprobing packets will return as usual. As a result, iSPYwill not be able to detect such an attack.

Xiang et al. proposed Argus [46], an active data-plane probing system that can verify detected routinganomalies. As discussed in section IV-A1, Argus appliesa simple approach that alerts users of unseen originor AS path segments for the monitored prefix. Argusthen proposed a data-plane-based active probing systemto verify the detection results (Fig. reffig:bgp-detection-argus). The verification system consists of multiple viewpoints deployed across the Internet, and the view pointsare divided into the ones that see the “anomalous”updates, and the one that do not for specific event. Argus

(a) An example of Listen detectingloss of reachability through passive

listening to TCP messages.

(b) An example of iSPY detectingloss of reachability from within the

victim AS.

(c) An example of Argus detectingloss of reachability from external

ASes.

Fig. 8: Example of the prefix hijacking detectionmethod for Listen, iSPY, and Argus.

sends out ping messages to the monitored prefix from allthe view points, collects the probing replies from bothtypes of view points, and gathers the results into twovectors. Argus then calculates the correlation coefficientbetween the two vectors, the value of which ranges from-1 and 1. If the result is close to 1, it means mostview points that see the updates cannot successfullyping the prefix, while the ones that do not see theupdates can still get ping responses back. This caseshows a strong evidence of a blackhole prefix hijacking.On the contrary, if the result is close to -1, it meansmost view points that do not see the update cannot getthe response back. This indicates that the updates were

14

most likely related to route migration, and should not bemalicious. The verification mechanism of Argus takes abig step on differentiating the legitimate changes frommalicious ones. However, this could still only applies tothe blackhole attacks where the attackers would drop thehijacked packets. In case of intercepting attack, wherethe attacker will eventually forward the hijacked trafficto the victim prefix, Argus cannot detect any changes inthe probing results due to the fact that the reachabilityto the prefix remains the same.

Similarly, Hu et al. designed an active fingerprintingmechanism to verify attack detection results [58]. Uponthe detection of a potential hijacking, the system willactively probe a set of end-hosts within the target prefixfrom multiple vantage points. The probing procedure willobtain the fingerprint information such as host OS prop-erties, IP identifiers, TCP timestamps, ICMP timestamps,etc. The system then compares the fingerprints of thesame set of end-hosts from different vantage points. Ifresults between different vantage points are different, itis very likely that the prefix was hijacked. To obtainhigh accuracy, this system needs deploy a large numberof vantage points from different ASes, avoiding thesituation where all the vantage points are affected by thehijack. This requirement puts high deployment overheadon this system. The other problem of this method isthat the probing messages may not get through to thetarget prefix from certain vantage points. Some ASesput restrictions on the probing messages and sometimesfilter out such messages. This could also cause inconsis-tencies in the probing results, which does not necessarilyindicate a prefix hijacking.

V. SECURITY OF SOFTWARE-DEFINED NETWORKING

Software-defined networking (SDN) is a recentparadigm for intra-domain networking. Traditionally,each domain (or AS) runs its own set of routing algo-rithms on top of a number of devices from different ven-dors with different implementation. The heterogeneousnature of the devices and their software complicatesthe management of the intra-domain networking. Forexample, a network operator has to communicate withrouting devices using different vendor-specific interfaces.To unify the control of networking devices, SDN sepa-rates the control plane and the data plane. The SDNcontroller processes control-plane messages and makesrouting decisions based on local routing policies, andthe switches forward the traffic based on the forwardingrules decided by the controller. The separation simplifiesthe design of the data-plane devices, i.e., the switches,and provides more flexibilities for control-plane policies.

Fig. 9: Software-defined networking basic architecture.

There are several proposed protocols to unify the com-munication between a controller and switches, such asOpenFlow[7], OVSDB[67], ForCES[68], and POF[69].These protocols define the messages between a controllerand switches and provide implementation specificationsfor SDN switch manufacturers. Among these protocols,OpenFlow [7] is the most popular and widely deployed.We will use OpenFlow as the default SDN control-planeprotocol in the following sections.

There are four types of components in an SDN en-vironment (Fig.9): end-hosts, switches, controllers, andapplications running on the controllers. The end-hostsare the machines and servers connected to the SDNswitches. The SDN switches forward the traffic to andfrom their connected end-hosts. Every SDN switch isconnected to one SDN controller, from which the switchcan learn the forwarding rules for each traffic flow.When an incoming flow does not match any forwardingrule of a switch, the switch will send a query to itscontroller and ask for the actions on this flow. A SDNcontroller is a centralized network management entitythat runs the SDN applications and communicates withthe switches. When receiving a flow query from a switch,a controller will respond to the switch with one or moreforwarding rules that match the flow and contain a setof actions on the flow, such as dropping the packets orforwarding the traffic to a specific port on the switch. Theresponses are decided by the SDN applications runningon the controller. SDN applications are the control-planesoftware that contain all the routing policies and generateforwarding rules for the switches of an SDN network.

Unfortunately, all the four types of components couldbe compromised and used for launching attacks. TheSDN applications may encompass security loopholesor malicious exploits from outside the network; thecontroller could be compromised by malicious operatorsto degrade the performance of the network; the switches

15

SDN Security

Attack

Prevention

Attack

Detection

Switch-based

Attacks

Application-based

Attacks

Host-based

Attacks

Controller-based

Attacks

Fig. 10: Security solutions taxonomy forsoftware-defined networking.

can be compromised to act maliciously when forwardingtraffic; and malicious end-hosts can also exploit the loop-holes in OpenFlow and disrupt the SDN controllers. Themajority of the efforts on securing SDN focus on dis-covering security loopholes and designing mechanismsto prevent them from happening. We can categorizethe security mechanisms for SDN by the types of theattacks to prevent, i.e., the solutions against end-host-based, switch-based, controller-based, or application-based attacks. In the following subsections, we discussthe threats that come from each type of the components,and survey the existing solutions toward the threats.

A. Securing SDN against Malicious Controllers

An SDN controller is the brain of an SDN networkand hosts the applications and communicates with theswitches. Whereas people focused more on the appli-cations that run on the controller, the controller itselfcould also be compromised. A malicious controller couldessentially take over the control of the entire network,thus requiring serious attention from the research andindustry communities.

Matsumoto et al. described a system called Fleetthat defends SDN networks against compromised con-trollers [70]. The authors define the compromised con-trollers as the ones that are controlled by maliciousadministrators. The authors state that malicious ad-ministrators can apply erroneous configurations on thecontrollers, the misconfigurations can then degrade theperformance of a network or even disrupt the normaloperation of the network. To defend against this attack,the authors assume that there are multiple controllersin the SDN network, and in order for a controller toinstall a new rule on an SDN switch, it needs to obtainacknowledgements from the other controllers. Fleet usesShamir’s secret sharing scheme [71] to ensure that atleast k out of n controllers need to validate the rule(Fig. 11). An SDN switch in this system needs to verifythe rule before installing it. On the other hand, an

Fig. 11: An example of Fleet preventing maliciouscontroller from sending out SDN rules.

attacker needs to compromise at least k controllers tomodify forwarding rules in an SDN network. However,the requirement of multiple controllers in the SDN net-work makes Fleet impractical in many networks. Thereare many SDN controller software that only supportsingle controller setup for a network, such as NOX [72],POX [73], Floodlight [74], or Ryu [75]. The authorsalso assume that all the controllers share the same set ofconfigurations and policies, which makes the multiple-controller setup less cost-effective.

B. Securing SDN against Malicious Applications

The threats can also come from the applicationsrunning on the controllers. There are increasingly moreapplications designed and shipped to various SDN con-trollers. However, the qualities and the management ofthe applications are still in question. Different appli-cations may generate the rules that overlap with eachother or even with conflicting forwarding actions. Similarto software security, it is not easy to implement andenforce strong security policies during the design ofSDN applications. Thus, the controller or third-partysecurity auditors needs to monitor the operations of theSDN applications to ensure that these applications do notproduce conflicting forwarding rules.

Canini et al. proposed a tool called NICE to uncoverbugs in OpenFlow programs through modeling checkingand symbolic execution [76]. The authors showed thatan OpenFlow application that works correctly most ofthe time can misbehave under certain states. To uncoverbugs in OpenFlow applications, NICE applies modelingchecking [77] to explore system execution paths, and

16

apply symbolic execution to reduce the space of inputs.Through model checking, NICE is able to locate erro-neous states and find out the root causes. Combiningwith symbolic execution, the computational overhead ofexploring all possible states is largely reduced. Basedon the exploration results, NICE further provides a setof APIs for users to express their desired correctnessproperties of the programs. Verifying the states withthe correctness properties, NICE can produce verifica-tion results for any given OpenFlow application. Sim-ilarly, ConfigChecker [78] and FlowCheker [79] en-code OpenFlow flow tables into binary decision diagram(BDD) and use model checking to verify the securityproperties. They convert the forwarding rules on switchesinto boolean expressions to build the binary decisiondiagram. With the constructed BDD, the system runsqueries using computation tree logic to detect conflictsamong rules.

Porras et al. proposed FortNOX, a security enforce-ment kernel for the NOX controller [72], to proactivelydetect application conflicts [80]. Instead of looking ateach flow rule individually, FortNOX converts the similarrules into alias set according to their inter-dependency.The FortNOX then detects conflicting alias sets ratherthan individual rules. With this level of abstraction, Fort-NOX is able to largely reduce the overhead for detectingconflicts, and is able to detect conflicts for 1000 rulesin less than 10 ms. To resolve the conflicts, FortNOXprioritizes different applications with the concept ofauthorization level. The rules generated by applicationswith a higher authorization level will be applied whenthere is a conflict.

FlowVisor [81] provides a way to split a physicalnetwork into multiple virtual networks, each with a ded-icated controller. By splitting the network into smallerslices, each controller may only control a subset ofdevices based on the topology design. Each slice ofthe network is a logically independent virtual network,and operators utilize any previously mentioned securitymechanisms to further secure this virtual network. Theslicing of networks provides extra scalability and securityfeatures for the SDN controllers and applications.

FlowGuard [82] is a firewall framework for SDNnetworks that can detect and resolve firewall policyviolations in real time. The authors categorize the se-curity policy violations into two types: entire violationand partial violation. If all possible flows covered by aflow rule were against a firewall policy, the flow ruleis an entire violation; otherwise it is a partial violation.Based on different types of violation, FlowGuard definedmultiple methods, as opposed to a simple pass/dropdecision, including dependency breaking for resolving

legitimate but overlapping rules; update rejecting forresolving entire violations rules; and packet blockingfor resolving partial violation rules. Unlike FortNOX’sproactive verification approach, FlowGuard is able toverify new flows in real time. Evaluation showed thatFlowGuard can check tens of thousands of new flows inmilliseconds.

NetPlumber [83] detects policy violations from agraph perspective. It applies header space analysis (HSA)to construct rule dependency graph called “plumbinggraph.” In this graph, a node represents a forwardingrule, and an edge represents the dependency between therules. NetPlumber maintains an up-to-date dependencygraph and uses it to determine security policy violations.NetPlumber incrementally updates the graph on eachrelevant change of the network, such as adding a newrule, deleting rules, link status changes, or modificationof forwarding tables. The incremental updating schemeenables NetPlumber to conduct violation detection in realtime. NetPlumber also includes a high-level descriptivelanguage for users to express their security policies.NetPlumber translates the policies from the descriptivelanguage into forwarding rules for deployment. Overall,NetPlumber extends the original HSA method, and en-ables real-time detection and descriptive languages forexpressing policies.

VeriFlow [84] verifies the OpenFlow rules againstthe security policies using a graph approach. VeriFlowsummarize the forwarding flows into equivalence classeswhich represent sets of flows with identical forwardingactions. Utilizing the equivalence classes, VeriFlow caneffectively confine the search space for conflicting rules.VeriFlow generates a forwarding graph for each equiva-lence class, showing how packets matched by this classwill be forwarded throughout the network. Based on theforwarding graphs, VeriFlow further provides interfacesfor the users to query about the reachability, loop-freeness, rule consistencies of the network. The contentof the queries depends on the specific applications ortasks. Similar to NetPlumber, VeriFlow also adopts theincremental updating mechanism for the graphs to en-able real-time verifications. The authors assume that theexisting rules are benign during the equivalence classesbuilding phase. The policy violations could thus stayundetected if they exist before VeriFlow starts running.

C. Securing SDN against Malicious Switches

SDN switches are responsible for forwarding all thetraffic in an SDN network. It is thus important to makesure that the switches operate correctly and consistently.However, due to the differences in implementations,

17

SDN switches from different vendors may behave dif-ferently on the same input. Switches can also be com-promised and conduct various malicious actions.

Kuzniar et al. presented a testing framework for SDNswitches called SOFT that can detect inconsistenciesbetween different OpenFlow implementations [85]. Theauthors proposed to use symbolic execution [86], [87],[88], [89] to explore input spaces systematically acrossmultiple OpenFlow switches. SOFT can construct se-quences of test inputs that cover all possible execu-tions for each OpenFlow switch. The system will thencompare the running results from different agents toidentify inconsistencies. This paper is the first to presenta systematical and comprehensive method for verifyingSDN switch software.

Chi et al. proposed a system to detect compromisedswitches [90]. The authors first defined the followingfour types of misbehaviors of a compromised switch:

• incorrect forwarding that forwards traffic flows toincorrect ports;

• duplicate forwarding that duplicates traffic flows tomultiple ports;

• packet manipulating that modifies content of thepackets;

• traffic weight adjusting that alters traffic priorities.

This paper introduced two algorithms that detect for-warding anomalies and weight adjusting anomalies. Thetwo algorithms use the same “active probing” idea.The controller constructs special flow rules (or “honeyrules”), installs them on SDN switches, and sends outprobing packets that match the rules. The switch can thendetect the switches on the forwarding path that behavedifferently than the expected correct forwarding behav-ior. The system can apply these two algorithms to detectincorrect forwarding and weight adjusting. However, theduplicate forwarding and packet manipulation were notdiscussed in the paper.

D. Securing SDN against Malicious End-hosts

In software-defined networking environment, the end-hosts could also be malicious. The hosts can eitherexploit the switch-controller communication mechanismto flood the controller, or forge control-plane messagesto deceive the controllers and influence the networktopology. In this subsection, we will look at both anglesand review the related works.

1) Host-based Flooding Attack: Shin et al. introducedthe AVANT-GUARD system that protects the SDNcontroller from end-host-based control-plane saturationattack [91]. As previously discussed, the SDN switches

information to the control plane with a specific command. The con-trol plane then decides whether to allow migration of this session.If so, the connection is transitioned to the migration stage.

Migration Stage: During the migration stage, the CM moduleinitiates a TCP connection handshake with the connection’s desti-nation host. If the host responds with a TCP SYN/ACK packet,the data plane finalizes this session by sending a TCP ACK packetto the host. The data plane also reports this information (i.e., es-tablishment of a TCP session with a real target host) to the controlplane. If the data plane fails to establish the TCP session with des-tination hosts (due to an unavailable host or closed port), this resultwill also be reported to the control plane.

Relay Stage: After the data plane successfully establishes a TCPsession with a real target host, it enters the relay stage where it re-lays all TCP data packets between a connection source and desti-nation as occurs during normal TCP sessions.

Example Connection Migration Scenario: To illustrate con-nection migration, consider the interaction shown in Figure 5. Ifthe data plane receives a TCP SYN packet from the host A (1) andthis packet does not match an existing flow rule in the device, it au-tomatically responds with a TCP SYN/ACK packet to host A (2).Then, if host A sends a TCP ACK packet to complete this TCPsession (3), the switch knows that a TCP session is successfully es-tablished, and it reports this event to the control plane. Then, thecontrol plane decides whether to allow the connection to migrateon to the real destination host (i.e., host B). Assuming the connec-tion is allowed, the control plane activates a flow rule with what wepropose as the Migrate action. When a migrate action rule is re-ceived by the data plane it initiates a TCP connection to host B (6)and completes the connection (7, 8). If the migration is successful,the device notifies the control plane of this event (9). Finally, thecontrol plane inserts a Relay action into the data plane, causing itto relay all packets between host A and B. At this time, the deviceneed not add a new rule; rather, it only needs to change the actionfield of the existing flow rule. Hence, the rule will be changed from(A-1) to (A-2). Operations 1-3 represent the classification stage;4-5 and 9-10 denote the reporting stages, 6-8 refer to the migrationstage, and 11-12 refer to the relay stage.

(1) TCP SYN(2) TCP SYN/ACK

(3) TCP ACK

(6) TCP SYN(7) TCP SYN/ACK

(8) TCP ACK

(4) (5) (9) (10)

(11) TCP ACKTCP DATA

(12) TCP ACKTCP DATA

A-1: A --> B: Migrate

A-2: A --> B: Relay

Data Plane

Classification Stage

Relay Stage Relay Stage

Migration Stage

Report StageReport Stage

Control Plane

A B

Figure 5: Example connection migration scenario

Impact on Control Plane Saturation: Connection migrationoffers an immediate benefit for maintaining control operations inthe presence of well-known adversarial models that engage in bothspoofed and non-spoofed attacks against an OpenFlow network. Inthe context of spoofed flooding attacks (e.g., spoofed TCP SYNfloods that may saturate the control plane with bogus connectionrequests), all such flow requests are nullified at the classificationstage. For non-spoofed connection floods (e.g., those that mayarise from an aggressive scanner), connection migration converts

the OpenFlow network into a whitehole network [9]. From thesource’s perspective, all probes to the ports and IP address rangesof the OpenFlow network appear to produce a TCP handshake re-sponse, hindering the source from knowing which IP and port com-binations are actually alive.

In the case of the flow-rule-flooding problem in the data plane,connection migration addresses this concern through its adoption ofstateless TCP handshaking with SYN cookies. Because the SYNcookie algorithm does not require any state management, a devicedoes not need to store any flow rules for failed or malicious TCPconnection attempts. It can reduce the effect of flow-rule-floodingproblem. Because of this, connection migration enhances an Open-Flow network’s resilience and scalability to network flooding at-tacks.

Collecting TCP Session Information: Based on informationfrom access tables in the data plane, the control plane acquires twoimportant attributes from each source that contacts the network:(i) the number of all connection attempts, captured in the accesstable (defined as A1) and (ii) the number of established connectionsrecorded within the connection migration report (defined as A2).Analysis of the ratio of failed TCP connections of a peer (A1 - A2)and the number of established TCP connections (A2) can often beused to detect various flooding and probing behavior.

3.2.1 Delayed Connection MigrationKnowledgeable adversaries may infer the use of connection mi-

gration and attempt to produce flooding packets by establishingmany real TCP sessions. They can use multiple processes, threads,or many zombie PCs to generate fake TCP connections. However,for some protocols, such as HTTP, in which the client is expectedto send the first data packet, we can extend connection migration toincorporate delayed connection migration. Here, we operate a vari-ant of connection migration in which the key difference is that theclassifying stage will delay the transition to the reporting stage un-til it receives the client’s TCP data packet. This scenario is shownin Figure 6. As shown in Figure 6, the data plane delays the report-ing time (5) until it receives more evidence (i.e., data packet) froma TCP session initiator (4).

(1) TCP SYN(2) TCP SYN/ACK

(3) TCP ACK

(7) TCP SYN(8) TCP SYN/ACK

(9) TCP ACK

(5) (6) (10)(11)

(4) TCP ACKTCP DATA (12) TCP ACK

TCP DATA

A-1: A --> B: Migrate

A-2: A --> B: Relay

Data Plane

Report Stage Report Stage

Classification Stage Migration Stage

Relay Stage

A B

Control Plane

Figure 6: Example delayed connection migration scenario

3.3 Actuating TriggersWe propose to extend OpenFlow with actuating triggers which

enable the data plane to asynchronously report network status andpayload information to the control plane. In addition, actuatingtriggers can be used to activate a flow rule under some predefinedconditions to help the control plane manage network flows with-out delays. The actuating trigger consists of four main operations.First, the control plane needs to define a traffic statistic conditionunder which notification is warranted. Second, the control plane

Fig. 12: Example connection migration scenario ofAVANT-GUARD (figure from [91])

send any unmatched packets to the controller for han-dling. The control-plane saturation attack exploits thismechanism to generate a large amount of query messagesusing TCP SYN flood mechanism. First, an attackerfloods the SDN switches with unique and unmatchedTCP SYN packets. Each packet will trigger the switchto generate a query message to the controller. As aresult, a large volume of query messages will arriveat and eventually overload the controller. To stop theflood, AVANT-GUARD acts as a proxy between switchand the controller, and reply the TCP SYN packetson behalf of the destination end-hosts. Only when theTCP connection is fully established (i.e., the senderand receiver both acknowledged the connection) willAVANT-GUARD forward the query to the controllerand then migrate the connection to the true destinationmachines. Fig. 12 shows an example of this procedurewhere machine A tries to initiate a TCP connection withmachine B. AVANT-GUARD first establishes the con-nection with machine A and then migrate the connectionto B when the TCP handshakes are complete.

However, AVANT-GUARD suffers from the follow-ing problems. First, the proxy-style behavior requires aswitch to have a large memory space to cache the con-nection status for every flow before the TCP connectionis complete. The overhead of caching connections underflooding attack could be prohibitive. Second, the solutiononly deals with the TCP SYN flood attacks and the othertypes of attack are still not handled.

Wang et al. introduced FloodGuard to solvethe control-plane saturation attacks in a proactivemanor [92]. The authors proposed a static programanalyzer to proactively generate flow rules to ensurethe major functionality of the network work. If attacktraffic manages to bypass the proactive rules, the pack-ets will again trigger control-plane message floods. Inthis case, FloodGuard will generate rules to forwardpackets to a data-plane cache server and limit the rateof PACKET IN messages. The FloodGuard provides

18

a more generic protection against various attacks withthe proactive rule generation. However, the rate-limitingapproach of processing traffic will significantly slowdown the overall traffic speed, and trigger high memoryand storage overhead to cache the data-plane floodingtraffic.

2) Host-based Control Message Forgery Attack:Hong et al. in [93] presented two types of new networktopology poisoning attacks, and proposed a system, To-poGuard, to secure the SDN control plane against suchattacks. The first type of attack is host-location hijackingattack, where the hijacker forges packets to deceive thecontroller to believe that the victim has relocated to thehijacker’s location, and thus hijacks all the traffic towardthe victim. Specifically, the controller uses Host TrackingService (HTS) to keep track of the hosts in the network,and identifies the hosts using a set of known identifiers(MAC, IP, VLAN ID, etc.). An attacker can forge packetswith the same identifiers of the victim, and convince theHTS that the host is now in a new location. To stopsuch attacks, TopoGuard forces the controller to verifythe change of location from the connected switch. For achange of location to be valid, the controller must firstreceive a Port Down packet from the switch previouslyconnected to the host. TopoGuard also actively probesthe host’s previous location to ensure that the originallocation is indeed not being used.

The second type of attack is host-based link fab-rication attack. The controller dynamically discoversthe topology of the network using LLDP (Link LayerDiscovery Protocol) packets sent from the switches. Theattacker exploits two facts here to conduct a link fab-rication attack. First, the switch will forward the wholepacket to controller as a query message when a new flowdoes not match any rule. Second, the controller doesnot have authentication for accepting the LLDP packets.The attacker then could forge a LLDP packets with faketopology information and send it to the switch. With acarefully designed packet header, the forged packets willbe forwarded to the controller, and the controller willaccept the LLDP packets. TopoGuard proposes to stopthis type of attack by dropping all the LLDP packetsfrom end-hosts. The end-hosts can be identified by thetraffic types. However, this method cannot handle thecases where the attacker stays “quiet” before the attack,in which case the TopoGuard does not know whether theport is connected to a host or a switch. The assumptionof the lack of authentication for LLDP packets alsodoes not hold for many modern controller software (e.g.,OpenDaylight [94]).

Dhawan et al. proposed SPHINX that also tries tosecure the topological information on the controller [95].

SPHINX is an attack detection application that sitsbetween the SDN controller and SDN switches. It aimsto construct a trust-worthy topology graph, or “flowgraph”, by using only messages from the controller,and detect anomalous messages from the SDN switches.The authors believe that only the OpenFlow messagessent from the controller are trustworthy. Thus, SPHINXconstructs the flow graph using only the “FLOW MOD”messages sent from the controller. Any changes causedby untrusted entities, or changes that violate administra-tive policies will trigger alerts to the users.

VI. SECURITY USING SOFTWARE-DEFINED

NETWORKING

Via the separation of control-plane and data-plane,SDN provides flexibilities for the operators or appli-cations to fully control the packet forwarding in acentralized way. This new routing management paradigmenables a set of new security applications using SDN.In particular, there are two major directions where usingSDN can help the existing security practices: traffic mon-itoring and traffic filtering. SDN enables easier trafficmonitoring over the entire network, and can improvethe effectiveness of the current traffic anomaly detectionsystems. With a unified control-plane protocol, SDNalso boosts traffic filtering capability within one AS oracross multiple ASes, which is specifically beneficial inthe defense against distributed denial-of-service (DDoS)attacks. In this section, we investigate security mecha-nisms that use SDN on both traffic anomaly detectionand DDoS defense.

A. SDN for Anomaly Detection

The basic idea for software-defined networking, orprogrammable networking, has been discussed longbefore the development of OpenFlow. Casado et al.proposed a centralized traffic management architecturecalled Ethane [96] that can conduct fine-grained flowlevel policy enforcement. Similar to the current SDNarchitecture, Ethane’s architecture consists of end-hosts,Ethane switches, and an Ethane controller (Fig. 13). Thecontroller accepts the policy inputs from the operatorsand translates high-level policies to switch-level rulesand enforces the rules at the Ethane switches. To initiatea flow from within an Ethane network, a user needs tofirst authenticate itself to the controller. On detecting anew flow, an Ethane switch asks the controller to decidethe forwarding actions, then installs a flow rule basedon the reply from the controller. Despite its innovativearchitecture, Ethane is limited to only addressing the

19

Fig. 13: Architecture of Ethane (figure from [96])

problems of user authentication and forwarding rulegeneration.

Mehdi et al. studied the feasibility of porting theexisting anomaly detection systems into SDN environ-ment [97]. Traditionally, the anomaly detection systems(ADS) are designed to run on dedicated machines andhave no direct influence on networking. As the net-working devices become more intelligent, the authorsproposed to study whether the traditional ADS couldbe ported onto the SDN environment. In this work, theauthors mainly focused on comparing the performanceof deploying SDN-based ADS at different locations:home, small office home office (SOHO), or ISP. Specif-ically, they studied four different popular algorithms:threshold random walk with credit based rate limit-ing [98], regular rate limiting [99], [100], maximumentropy detector [101], and NETAD [102]. The authorsfirst showed the feasibility of running all four algorithmsin an SDN environment. The authors then collected datafrom real networks and compared the performance ofthese algorithms at different locations. The evaluationsshowed that deploying the solutions at home environ-ment would have the highest detection rate and the fastestprocessing speed. However, this work does not comparethe performance with the same solutions deployed onthe traditional network environments, thus weakening themotivation of this work. This work also did not take intoconsideration the deployment cost at home environment.

To enable SDN for more general network securityapplications, Shin et al. proposed FRESCO [103], aprogramming framework for security applications inSDN environment. It provides a set of reusable modulesas a library and enables developers to create securityfunctions quickly and easily. The security functionsinclude firewalls, scan detectors, intrusion detection sys-tems, etc. FRESCO also provides APIs to enable legacyapplications to trigger the security modules. This capa-bility allows FRESCO to work with existing security

applications such as deep packet inspection (DPI) boxeswith minimum changes of the code. The authors demon-strated several applications generated using FRESCOand showed that FRESCO introduces reasonable over-head. However, FRESCO itself does not directly addressany existing security problems.

B. SDN for DDoS Defense

The distributed denial-of-service (DDoS) attacks havebeen troubling the Internet for more than a decadenow. With the fast development of SDN technology,researchers started to develop DDoS defense solutionsfor the SDN environments. Compared to using thetraditional networking scheme, using SDN for DDoSdefense has many benefits. First, SDN allows operatorsto describe the DDoS defense logics in a standard wayusing OpenFlow [7] with no vendor-specific interfacesrequired. Using unified communication protocol allowsoperators to deploy DDoS defense rules on any Open-Flow enabled devices with little compatibility concern.Second, the centralized control of SDN architecture en-ables operators to quickly modify the network topologiesand forwarding rules of the entire network with mini-mum efforts. Third, multiple DDoS defense solutions caneasily work together with the help of SDN. For example,SDN can enforce traffic flow to go through specific pathsor equipments, and enable different defense componentsto process the traffic in a specific order. For example,a solution could require the traffic first flow through ageneric traffic filter, then a deep-packet-inspection box,then a rate-limiting cache, and finally the destination.Overall, the SDN technology allows network operatorsto have much more flexibility without sacrificing theforwarding speed. In this section, we look at severalDDoS defense solutions that utilize SDN as their mainnetworking architecture.

Giotis et al. introduced a system that utilizesSDN to enhance the traditional DDoS defense solu-tions [104]. Traditionally, the Remote Triggered Black-Hole (RTBH) [105] method is used to automaticallypropagate blacklist flow rules for stopping unwanted traf-fic. RTBH uses BGP to exchange filtering information,and alters the next hop address of a matched prefix toachieve the black-holing goal. Because RTBH relies onBGP, it can only filter traffic on per-prefix level. RTBHis also limited to only dropping the matched traffic.To address the problems and utilizing the capabilityof SDN network, the authors proposed to modify theRTBH behavior, forwarding the matched traffic to aSDN network instead of dropping, and letting the SDNnetwork to further process the traffic. By doing so, the

20

system separates the traffic steering and traffic filteringprocedures, and enables the usages of SDN withoutlargely changing the existing protocols. There are threecomponents in the system: an anomaly detection systemthat triggers RTBH function, the RTBH function thatforwards the traffic to a SDN network, and the miti-gation functions used in the SDN network for filteringunwanted traffic. The system differentiate DDoS trafficfrom benign traffic using a bidirectional count sketchalgorithm. The algorithm counts the packets and detectsthe highly asymmetric communication patterns, whichthe DDoS traffic usually has. Overall, the system is ableto utilize SDN for filtering unwanted traffic with the helpof BGP RTBH.

Lim et al. presented a system that can mitigate theDDoS attack and protect the desired services throughresource migration [106]. When a DDoS is detected, thesystem provides new IPs for the servers under protectionand redirects legitimate traffic to the new addresses. Thesystem applies CAPTCHA [107] (or RECAPTCHA) toprevent the bots from knowing the new IPs. In the meantime, the system measures the frequency of accessingthe protected resources for each client, and marks theclients with high access frequency as bots. All thetraffic from the clients marked as bots will be dropped.However, there are several problems that this solutiondid not address. First, the system can only work withHTTP server scenario, where the redirection can be doneautomatically with explicit HTTP redirecting command.For other types of applications, such as FTP or SSH, theredirection of traffic will require modification of codeon all clients. Second, the CAPTCHA methods cannoteffectively stop bots from knowing the new addresses ofthe protected server. It requires only one manual accessto learn the new addresses, and the attackers can quicklyreconfigure the bots to attack the new addresses.

To provide a more proactive defense solution againstDDoS attack, Jafarian et al. proposed a moving targettechnique called OpenFlow Random Host Mutation(OF-RHM) [108]. OF-RHM randomly and frequentlymutates the IP addresses of the end-hosts to prevent at-tackers from learning the IP assignments of the network.To enable the transparent mutation, OF-RHM systemkeeps the original IP of the end-hosts and associates eachhost with a random virtual IP. When a flow enters thenetwork, OF-RHM translates the destination IP from thereal IP to the virtual IP. When a flow leaves the network,OF-RHM also translates the source IP from the virtualIP to the real IP. Moreover, the system ensures highmutation rate and randomness on virtual IP assignments.However, this system implicitly assumes that the networkhas a large range of unused IP addresses to use, which

could be impractical in real-world cases, especially underthe IPv4 address depletion situation.

VII. CONCLUSION

In this report, we examined the security problemsfor the inter-domain and intra-domain routing protocols,and surveyed the existing solutions. Specifically, wefocused on Border Gateway Protocol (BGP) for inter-domain routing, and software-defined networking (SDN)for intra-domain routing. We investigate both BGP andSDN security solutions, with a focus on their strengthsand weaknesses as well as their deployment status onthe Internet.

We categorized the security solutions into two generalcategories: the attack prevention solutions and the attackdetection solutions. The attack prevention solutions aimto proactively stop potential attacks through securityupgrades of the protocol design or operations. Mean-while, the attack detection solutions aim to reactivelydetect abnormal events regarding the operation of theprotocols in order to trigger timely reaction to suchevents. The attack prevention mechanisms for BGP havebeen heavily studied [8], [9], [10], [11]. To date, noneof these mechanisms has been largely deployed to date,leaving the Internet still vulnerable to the inter-domainrouting attacks. We focused on examining the attackdetection mechanisms for BGP, which most of the recentBGP security work have concentrated on. On the otherhand, since SDN is still young, the majority of the SDNsecurity work look at attack prevention, with less onattack detection.

For inter-domain routing (i.e., BGP), we surveyedattack preventions solutions of three types: the control-plane-based cryptographic approaches, the control-plane-based non-cryptographic approaches, and the data-plane-based approaches. However, the majority of the thesesolutions have not been adopted on the Internet, mak-ing the accurate detection of attacks more important.For existing attack detection mechanisms for BGP, wecategorize them by their main methods: some detectionsystems use active probing to acquire information, whilethe others rely on passive monitoring. Based on theinformation source, the attack detection systems canbe also categorized into control-plane-based, data-plane-based, or hybrid mechanisms. Compared to the attackprevention mechanisms, the attack detection systemsusually incur much less overhead and easier to deploy,making them more preferable in real-world deploymentscenarios.

For intra-domain routing (i.e., SDN), we mainly exam-ined the security mechanisms from two perspectives: the

21

methods that secure the SDN itself, and the applicationsof SDN on solving other network security problems.Based on the types of attacks, we investigated the secu-rity solutions that protect SDN against attacks originatedfrom SDN controllers, applications, switches and end-hosts. We also reviewed how researchers have utilizedSDN to defend against other network security problems.However, because SDN is a new development in intra-domain routing, the overall security of SDN or usingSDN is still at its early stage and many works remain tobe done. Especially, while there are plenty of work onanomaly detection of BGP, little has been investigatedon SDN anomaly detection.

ACKNOWLEDGEMENT

I would like to thank my research advisor ProfessorJun Li for his expert advice and encouragement through-out the whole research, as well as Professor Reza Rejaieand Professor Hank Childs for their insightful guidanceon the writing the report.

This material is based upon work supported by theUSA National Science Foundation under Grant No.CNS-1118101. Any opinions, findings, and conclusionsor recommendations expressed in this material are thoseof the authors and do not necessarily reflect the viewsof the National Science Foundation.

REFERENCES

[1] Y. Rekhter, T. Li, and S. Hares, “A border gateway protocol4 (bgp-4),” Tech. Rep., 2005.

[2] G. S. Malkin, “RIP version 2,” 1998.[3] J. Moy, “OSPF version 2,” 1997.[4] D. Oran, “OSI IS-IS intra-domain routing protocol,” 1990.[5] R. Albrightson, J. Garcia-Luna-Aceves, and J. Boyle,

“EIGRP–A fast routing protocol based on distance vectors,”Interop 94, 1994.

[6] N. McKeown, “Software-defined networking,” INFOCOMkeynote talk, vol. 17, no. 2, pp. 30–32, 2009.

[7] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar,L. Peterson, J. Rexford, S. Shenker, and J. Turner, “Openflow:enabling innovation in campus networks,” ACM SIGCOMMComputer Communication Review, vol. 38, no. 2, pp. 69–74,2008.

[8] K. Butler, T. R. Farley, P. McDaniel, and J. Rexford, “A surveyof BGP security issues and solutions,” Proceedings of theIEEE, vol. 98, no. 1, pp. 100–122, Jan. 2010.

[9] G. Huston and R. Bush, “Securing BGP with BGPSec,”Internet Protocol Journal, vol. 14, no. 2, pp. 2–13, 2011.

[10] S. Goldberg, “Why is it taking so long to secure internetrouting,” Education for Health, vol. 15, no. 3, pp. 291–293,2002.

[11] H. Shiravi, A. Shiravi, and A. a. Ghorbani, “A survey ofvisualization systems for network security,” IEEE Transactionson Visualization and Computer Graphics, vol. 18, no. 8, pp.1313–1329, Aug. 2012.

[12] S. Kent, C. Lynn, and K. Seo, “Secure Border GatewayProtocol (S-BGP),” IEEE Journal on Selected Areas in Com-munications, vol. 18, no. 4, pp. 582–592, 2000.

[13] R. White and R. White, “Deployment Considerations forsecure origin BGP (soBGP),” 2003.

[14] G. Goodell, W. Aiello, T. Griffin, J. Ioannidis, P. Mcdaniel, andA. Rubin, “Working Around BGP : An Incremental Approachto Improving Security and Accuracy of Interdomain Routing,”The Annual Network and Distributed Systems Security Sym-posium (NDSS), 2003.

[15] Y.-c. Hu and M. Sirbu, “SPV : Secure Path Vector Routingfor Securing BGP,” ACM SIGCOMM, pp. 179–192, 2004.

[16] T. Wan, E. Kranakis, and P. Van Oorschot, “Pretty Secure BGP( psBGP ),” Annual Network and Distribution Systems SecuritySymposium (NDSS), no. February, pp. 1–23, 2005.

[17] M. Lepinski, “Bgpsec protocol specification,” 2015.[18] L. Subramanian, V. Roth, I. Stoica, S. Shenker, and R. H. Katz,

“Listen and whisper: Security mechanisms for BGP,” 2004.[19] E.-y. Kim, K. Nahrstedt, L. Xiao, and K. Park, “Identity-based

Registry For Secure Interdomain Routing,” ACM Conferenceon Computer and Communications Security (CCS), pp. 321–331, 2006.

[20] V. Gill, J. Heasley, and D. Meyer, “The Generalized TTLSecurity Mechanism (GTSM),” Request For Comments (RFC),no. 3682, pp. 1–16, 2004.

[21] A. Heffernan, “Protection of BGP Sessions via the TCP MD5Signature Option,” Request For Comments (RFC), no. 2385,1998.

[22] S. Kent and R. Atkinson, “Security Architecture for theInternet Protocol,” no. 2401, pp. 1–101, 1998.

[23] C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens,D. Meyer, T. Bates, D. Karrenberg, and M. Terpstra, “RoutingPolicy Specification Language (RPSL),” Tech. Rep., 1999.

[24] L. Blunk, J. Damas, F. Parent, and A. Robachevsky, “RoutingPolicy Specification Language next generation (RPSLng),”Tech. Rep., 2005.

[25] J. Schlamp, R. Holz, O. Gasser, A. Korsten, Q. Jacquemart,G. Carle, and E. Biersack, “Investigating the Nature of RoutingAnomalies: Closing in on Subprefix Hijacking Attacks,” inTraffic Monitoring and Analysis, ser. Lecture Notes in Com-puter Science, M. Steiner, P. Barlet-Ros, and O. Bonaventure,Eds. Springer International Publishing, 2015, vol. 9053, pp.173–187.

[26] P. Vervier, O. Thonnard, and M. Dacier, “Mind your blocks:On the stealthiness of malicious BGP hijacks,” no. February,pp. 8–11, 2015.

[27] G. Siganos and M. Faloutsos, “Analyzing BGP policies:methodology and tool,” Proceedings of IEEE INFOCOM,2004.

[28] ——, “A Blueprint for Improving the Robustness of InternetRouting,” 2005. [Online]. Available: http://www.cs.ucr.edu/

[29] ——, “Neighborhood watch for Internet routing: Can we im-prove the robustness of Internet routing today?” Proceedingsof IEEE INFOCOM, pp. 1271–1279, 2007.

[30] M. Wahlisch, O. Maennel, and T. C. Schmidt, “Towardsdetecting BGP route hijacking using the RPKI,” ACM SIG-COMM Computer Communication Review, vol. 42, no. 4, p.103, 2012.

[31] M. Wahlisch, F. Holler, T. C. Schmidt, and J. H. Schiller,“Updates from the Internet Backbone:An RPKI/TRT RouterImplementation, Measurements, and Analysis,” Network andDistributed System Security Symposium (NDSS), pp. 1–11.

[32] E. Osterweil, T. Manderson, R. White, and D. McPherson,“Sizing estimates for a fully deployed RPKI,” Verisign Labs,Tech. Rep., 2012.

[33] D. Cooper, E. Heilman, K. Brogle, L. Reyzin, and S. Goldberg,“On the risk of misbehaving RPKI authorities,” Proceedingsof ACM Workshop on Hot Topics in Networks (HotNets), pp.1–7, 2013.

22

[34] E. Heilman and S. Goldberg, “From the Consent of the Routed: Improving the Transparency of the RPKI,” Sigcomm 2014,pp. 51–62, 2014.

[35] R. Lychev, S. Goldberg, and M. Schapira, “BGP Security inPartial Deployment Is the Juice Worth the Squeeze?” ACMSIGCOMM, pp. 171–182, 2013.

[36] Q. Li, Y.-C. Hu, and X. Zhang, “Even rockets cannot makepigs fly sustainably: Can bgp be secured with bgpsec?” 2014.

[37] R. White, “Securing BGP through secure origin BGP(soBGP),” Business Communications Review, vol. 33, no. 5,pp. 47–53, 2003.

[38] B. Raghavan, S. Panjwani, and A. Mityagin, “Analysis ofthe SPV secure routing protocol,” ACM SIGCOMM ComputerCommunication Review, vol. 37, no. 2, p. 29, 2007.

[39] “HP-UX IPSec vA.03.00 Performance and Sizing WhitePaper,” http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=4164811&docId=emr na-c02035735,2009, [Online].

[40] K. Sriram, O. Borchert, O. Kim, P. Gleichmann, and D. Mont-gomery, “A Comparative analysis of BGP anomaly detectionand robustness algorithms,” Proceedings of Cybersecurity Ap-plications and Technology Conference for Homeland Security(CATCH), pp. 25–38, 2009.

[41] C. Kruegel, D. Mutz, W. Robertson, and F. Valeur, “Topology-based detection of anamolous BGP messages,” Recent Ad-vances in Intrusion Detection, vol. 6, 2003.

[42] J. Li, T. Ehrenkranz, and P. Elliott, “Buddyguard: A buddysystem for fast and reliable detection of ip prefix anomalies,” inIEEE International Conference on Network Protocols (ICNP).IEEE, 2012, pp. 1–10.

[43] J. Li and S. Brooks, “I-seismograph: Observing and measuringinternet earthquakes,” in Proceedings of IEEE INFOCOM.IEEE, 2011, pp. 2624–2632.

[44] G. Theodoridis, O. Tsigkas, and D. Tzovaras, “A Novel Unsu-pervised Method for Securing BGP Against Routing Hijacks,”vol. 62, pp. 353–358, 2010.

[45] X. Shi, Y. Xiang, Z. Wang, X. Yin, and J. Wu, “Detectingprefix hijackings in the internet with argus,” Proceedings ofthe 2012 ACM conference on Internet measurement conference(IMC), p. 15, 2012.

[46] Y. Xiang, Z. Wang, X. Yin, and J. Wu, “Argus: An accurateand agile system to detecting IP prefix hijacking,” Proceedingsof International Conference on Network Protocols (ICNP), pp.43–48, 2011.

[47] J. Zhang, J. Rexford, and J. Feigenbaum, “Learning-basedanomaly detection in BGP updates,” in Proceedings of the2005 ACM SIGCOMM workshop on Mining network data.ACM, 2005, pp. 219–220.

[48] L. Yuan, J. Mai, and C.-N. Chuah, “Bgp anomaly detectionusing wavelet analysis,” University of California, Davis, Tech.Rep., 2004.

[49] B. A. Prakash, N. Valler, D. Andersen, M. Faloutsos, andC. Faloutsos, “BGP-lens: Patterns and Anomalies in InternetRouting Updates,” Kdd, pp. 1315–1323, 2009.

[50] S. T. Teoh, S. Ranjan, A. Nucci, and C.-N. Chuah, “BGP eye:A new Visualization Tool for Real-time Detection and Anal-ysis of BGP Anomalies,” in Proceedings of the InternationalSymposium on Visualization for Computer Security (VizSec),2006, p. 81.

[51] V. Khare, Q. Ju, and B. Zhang, “Concurrent prefix hijacks: Oc-currence and impacts,” in Proceedings of the ACM conferenceon Internet measurement conference (IMC). ACM, 2012, pp.29–36.

[52] N. M. Al-Rousan and L. Trajkovic, “Machine learning modelsfor classification of BGP anomalies,” 2012 IEEE 13th In-

ternational Conference on High Performance Switching andRouting (HPSR), vol. 513, pp. 103–108, 2012.

[53] M. Lad, D. Massey, D. Pei, and Y. Wu, “PHAS: A prefixhijack alert system,” Proceedings of USENIX Security, 2006.

[54] J. Karlin, S. Forrest, and J. Rexford, “Pretty good BGP:Improving BGP by cautiously adopting routes,” Proceedings- International Conference on Network Protocols (ICNP), pp.290–299, 2006.

[55] N. Feamster, N. Feamster, H. Balakrishnan, and H. Balakrish-nan, “Detecting BGP configuration faults with static analysis,”Proceedings of Networked Systems Design and Implementation(NSDI), pp. 49–56, 2005.

[56] J. Qiu, L. Gao, S. Ranjan, and A. Nucci, “Detecting bogusBGP route information: Going beyond prefix hijacking,” Pro-ceedings of the 3rd International Conference on Security andPrivacy in Communication Networks (SecureComm), vol. 1,pp. 381–390, 2007.

[57] T. Wong, V. J. V. Jacobson, and C. Alaettinoglu, “Internetrouting anomaly detection and visualization,” InternationalConference on Dependable Systems and Networks, pp. 172–181, 2005.

[58] X. Hu and Z. M. Mao, “Accurate real-time identification of IPprefix hijacking,” Proceedings - IEEE Symposium on Securityand Privacy, no. 2, pp. 3–17, May 2007.

[59] C. Zheng, L. Ji, D. Pei, J. Wang, and P. Francis, “A light-weight distributed scheme for detecting ip prefix hijacks inreal-time,” ACM SIGCOMM Computer Communication Re-view, vol. 37, no. 4, p. 277, Oct. 2007.

[60] Z. Zhang, Y. Zhang, Y. C. Hu, Z. M. Mao, and R. Bush,“iSPY: Detecting IP Prefix Hijacking on My Own Zheng,”ACM SIGCOMM, p. 327, 2008.

[61] R. Hiran, N. Carlsson, and N. Shahmehri, “Crowd-basedDetection of Routing Anomalies on the Internet,” Computerand Network Security (CNS), 2015.

[62] Y. Liu, J. Su, and R. K. C. Chang, “LDC: Detecting BGP prefixhijacking by load distribution change,” Proceedings of IEEEInternational Parallel and Distributed Processing SymposiumWorkshops (IPDPSW), pp. 1197–1203, 2012.

[63] Z. Zhang, Y. Zhang, Y. C. Hu, and Z. M. Mao, “Practicaldefenses against BGP prefix hijacking,” Proceedings of theACM CoNEXT Conference, p. 1, 2007.

[64] J. Rexford, J. Wang, Z. Xiao, and Y. Zhang, “BGP routingstability of popular destinations,” Proceedings of the secondACM SIGCOMM Workshop on Internet measurment workshop- IMW ’02, p. 197, 2002.

[65] D. Meyer et al., “University of Oregon Route Views Project,”2005.

[66] L. Gao, “On inferring autonomous system relationships inthe Internet,” IEEE/ACM Transactions on Networking (ToN),vol. 9, no. 6, pp. 733–745, 2001.

[67] B. Pfaff and B. Davie, “The open vSwitch database manage-ment protocol,” 2013.

[68] E. Haleplidis, S. Denazis, O. Koufopavlou, D. Lopez,D. Joachimpillai, J. Martin, J. H. Salim, and K. Pentikousis,“ForCES applicability to SDN-enhanced NFV,” in EuropeanWorkshop on Software Defined Networks (EWSDN). IEEE,2014, pp. 43–48.

[69] H. Song, “Protocol-oblivious forwarding: Unleash the powerof SDN through a future-proof forwarding plane,” in Pro-ceedings of the ACM SIGCOMM workshop on Hot topics insoftware-defined networking (HotSDN). ACM, 2013, pp. 127–132.

[70] S. Matsumoto, S. Hitz, and A. Perrig, “Fleet : Defending SDNsfrom Malicious Administrators,” pp. 103–108, 2014.

[71] A. Shamir, “How to share a secret,” Communications of theACM, vol. 22, no. 11, pp. 612–613, 1979.

23

[72] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McK-eown, and S. Shenker, “NOX: towards an operating systemfor networks,” ACM SIGCOMM Computer CommunicationReview, vol. 38, no. 3, pp. 105–110, 2008.

[73] “POX,” http://www.noxrepo.org/pox/about-pox/, [Online].[74] “FloodLight,” http://www.projectfloodlight.org/floodlight/,

[Online].[75] “Ryu,” http://osrg.github.io/ryu/, [Online].[76] M. Canini, D. Venzano, P. Peresini, D. Kostic, and J. Rexford,

“A NICE Way to Test OpenFlow Applications,” USENIXSymposium on Networked Systems Design and Implementation(NSDI), 2012.

[77] R. Jhala and R. Majumdar, “Software model checking,” ACMComputing Surveys (CSUR), vol. 41, no. 4, p. 21, 2009.

[78] E. Al-Shaer and S. Al-Haj, “FlowChecker: ConfigurationAnalysis and Verification of Federated OpenFlow Infrastruc-tures,” Proceedings of the ACM workshop on Assurable andusable security configuration (SafeConfig), p. 37, 2010.

[79] E. Al-Shaer and M. N. Alsaleh, “ConfigChecker: A tool forcomprehensive security configuration analytics,” Symposiumon Configuration Analytics and Automation, pp. 1–2, 2011.

[80] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson,and G. Gu, “A security enforcement kernel for OpenFlownetworks,” p. 121, 2012.

[81] R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller, M. Casado,N. McKeown, and G. Parulkar, “Flowvisor: A network virtual-ization layer,” OpenFlow Switch Consortium, Tech. Rep, 2009.

[82] H. Hu, W. Han, G. Ahn, and Z. Zhao, “FLOWGUARD:building robust firewalls for software-defined networks,” Pro-ceedings of the ACM SIGCOMM workshop on Hot topics insoftware-defined networking (HotSDN), 2014.

[83] P. Kazemian, M. Change, and H. Zheng, “Real Time NetworkPolicy Checking Using Header Space Analysis,” USENIXSymposium on Networked Systems Design and Implementation(NSDI), pp. 1–13, 2013.

[84] A. Khurshid, W. Zhou, M. Caesar, and P. Godfrey, “Veriflow:verifying network-wide invariants in real time,” ACM SIG-COMM Computer Communication Review, vol. 42, no. 4, pp.467–472, 2012.

[85] M. Kuzniar, P. Peresini, M. Canini, D. Venzano, and D. Kostic,“A SOFT way for OpenFlow switch interoperability testing,”Proceedings of the International conference on Emergingnetworking experiments and technologies, pp. 265–276, 2012.

[86] J. C. King, “A new approach to program testing,” in ACMSIGPLAN Notices, vol. 10, no. 6. ACM, 1975, pp. 228–233.

[87] S. Bucur, V. Ureche, C. Zamfir, and G. Candea, “Parallelsymbolic execution for automated real-world software testing,”in Proceedings of the sixth conference on Computer systems.ACM, 2011, pp. 183–198.

[88] C. Cadar, D. Dunbar, and D. R. Engler, “KLEE: Unas-sisted and Automatic Generation of High-Coverage Tests forComplex Systems Programs,” in Proceedings of the USENIXSymposium on Operating Systems Design and Implementation,vol. 8, 2008, pp. 209–224.

[89] V. Chipounov, V. Kuznetsov, and G. Candea, “The S2Eplatform: Design, implementation, and applications,” ACMTransactions on Computer Systems (TOCS), vol. 30, no. 1,p. 2, 2012.

[90] P.-w. Chi, C.-t. Kuo, J.-w. Guo, and C.-l. Lei, “How toDetect a Compromised SDN Switch,” Proceedings of theIEEE Conference on Network Softwarization (NetSoft), pp. 1–6, 2015.

[91] S. Shin, V. Yegneswaran, P. Porras, and G. Gu, “Avant-guard:Scalable and vigilant switch flow management in software-defined networks,” in Proceedings of the 2013 ACM SIGSAC

conference on Computer & communications security. ACM,2013, pp. 413–424.

[92] H. Wang, L. Xu, and G. Gu, “FloodGuard: A DoS AttackPrevention Extension in Software-Defined Networks,” AnnualIEEE/IFIP International Conference on Dependable Systemsand Networks (DSN), 2015.

[93] S. Hong, X. Lei, H. Wang, and G. Gu, “Poisoning NetworkVisibility in Software-Defined Networks: New Attacks andCountermeasures,” pp. 8–11, 2015.

[94] “OpenDaylight,” https://www.opendaylight.org/, [Online].[95] M. Dhawan, R. Poddar, K. Mahajan, and V. Mann, “SPHINX:

Detecting security attacks in software-defined networks,” inProceedings of the Network and Distributed System Security(NDSS) Symposium, 2015.

[96] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown,and S. Shenker, “Ethane: Taking Control of the Enterprise,”ACM SIGCOMM Computer Communication Review, vol. 37,no. 4, p. 1, 2007.

[97] S. A. Mehdi, J. Khalid, and S. A. Khayam, “Revisiting Traf-fic Anomaly Detection using Software Defined Networking,”Entropy, vol. 6961, pp. 1–20, 2011.

[98] J. Jung, S. E. Schechter, and A. W. Berger, “Fast Detection ofScanning Worm Infections,” System, pp. 1–14, 2004.

[99] M. M. Williamson, “Throttling Viruses: Restricting propaga-tion to defeat malicious mobile code,” in Proceedings of theComputer Security Applications Conference, no. HPL-2002-172, 2002, pp. 61–68.

[100] J. Twycross and M. M. Williamson, “Implementing and Test-ing a Virus Throttle,” Proceedings of the USENIX SecuritySymposium, no. August, pp. 285–294, 2003.

[101] Y. Gu, A. McCallum, and D. Towsley, “Detecting Anomaliesin Network Traffic Using Maximum Entropy Estimation,” inProceedings of the ACM SIGCOMM Conference on InternetMeasurement, 2005, p. 32.

[102] M. V. Mahoney, “Network traffic anomaly detection based onpacket bytes,” Proceedings of the ACM symposium on Appliedcomputing (SAC), p. 346, 2003.

[103] S. Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu, andM. Tyson, “FRESCO: Modular Composable Security Servicesfor Software-Defined Networks.” vol. 2, no. February, 2013.

[104] K. Giotis, G. Androulidakis, and V. Maglaris, “LeveragingSDN for Efficient Anomaly Detection and Mitigation onLegacy Networks,” European Workshop on Software DefinedNetworks, pp. 85–90, 2014.

[105] D. Turk, “Configuring BGP to block Denial-of-Service at-tacks,” 2004.

[106] S. Lim, J. Ha, H. Kim, Y. Kim, and S. Yang, “A SDN-oriented DDoS blocking scheme for botnet-based attacks,”International Conference on Ubiquitous and Future Networks(ICUFN), pp. 63–68, 2014.

[107] L. Von Ahn, M. Blum, N. J. Hopper, and J. Langford,“Captcha: Using hard ai problems for security,” in Advancesin CryptologyEUROCRYPT. Springer, 2003, pp. 294–311.

[108] J. Jafarian, E. Al-Shaer, and Q. Duan, “Openflow random hostmutation: transparent moving target defense using softwaredefined networking,” pp. 127–132, 2012.