Implementing Geo-Blocking and Spoofing Protection in Multi-Domain Software Defined Interconnects

Motivated by recent attacks like the Australian census website meltdown in 2016, this paper proposes a system for high-level specification and synthesis of intents for Geo-Blocking and IP Spoofing protection at a Software Defined Interconnect. In contrast to todays methods that use expensive custom hardware and/or manual configuration, our solution allows the operator to specify high-level intents, which are automatically compiled to flow-level rules and pushed into the interconnect fabric. We define a grammar for specifying the security policies, and a compiler for converting these to connectivity rules. We prototype our system on the open-source ONOS Controller platform, demonstrate its functionality in a multi-domain SDN fabric interconnecting legacy border routers, and evaluate its performance and scalability in blocking DDoS attacks.


Introduction
Distributed Denial-of-Service (DDoS) a acks on web-based services are escalating -our motivation in this work comes from the recent meltdown of the Australian Census web-site in August 2016 [2], which is believed to have been caused by large-scale o -shore DDoS a acks, leaving millions of Australians unable to access the web-site on census night, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro t or commercial advantage and that copies bear this notice and the full citation on the rst page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permi ed. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior speci c permission and/or a fee. Request  and becoming a national embarrassment for the Australian Bureau of Statistics (ABS). When the ABS in response sought to geo-block access to the census site to limit it to Australians, the complexities of manual con guration (white-listing of allowed IP blocks) became apparent, with necessary support services (like DNS) failing and the site being down for several more days. is paper therefore explores the feasibility of automating the process of con guring security, by requiring the user to specify only high-level policies that are dynamically compiled down to enforceable forwarding rules in the data-plane.
In this paper we focus speci cally on geo-blocking and IP address spoo ng. Geo-blocking is an e ective way of restricting access to the service (loosely) to a geographical boundary, thereby limiting the ability of a ackers outside this boundary to bring down the service. e boundary can be speci ed in terms of the country code or AS numbers, which then need to be translated into a set of IP pre xes.
is set can be large, and manual con guration of these prexes into border routers (or special security appliances like PacketViper [10]) can be expensive and error-prone. Further, a ackers can spoof IP addresses, making it di cult to identify legitimate from illegitimate tra c. In this paper therefore we also tackle IP address spoo ng, using a minimalistic approach that only accepts tra c originating from a domain if that domain advertises that pre x in its BGP control plane. Domains have an incentive to participate in this so as to reduce their liability for (re ection) a acks originating from their network. We believe that this combination of geo-blocking and source IP address spoo ng is an e ective (though by no means comprehensive) way to protect critical web-services. e skills required to implement, operate, and maintain security-related access control lists (ACLs) can be prohibitive for small entities (including government agencies), and therefore we advocate that they only specify their security requirements in terms of high-level policies, such as the region they want to geo-block their service to. e natural place to implement the security data ltering is the (public or private) Internet exchange point (IXP), which inter-connects the domain to other domains -the IXP carries both the dataplane and control-plane tra c for all domains, and therefore has both visibility and expertise to execute security intents. Further, the IXP can "scrub" the tra c in its fabric so the XDOMO'17, April 23, 2017, Belgrade, Serbia Himal Kumar †, Anu Mercian * , Sujata Banerjee , Craig Russell , Vijay Sivaraman † malicious tra c does not even need to enter the domain under a ack, protecting its access link resources. Recent advances in so ware de ned networking (SDN) technology enable data-plane forwarding rules to be consistent with the control plane updates, enabling the realization of new security capabilities as envisaged in SDX [14]. Our own previous work in [18] has built and deployed an SDN-based multidomain inter-connect that is operational across six research institutions in Australia -our work in this paper extends the capability of this Australia-wide SDN testbed to include the security use-cases developed in this paper. Our speci c contributions are: • We develop a geo-blocking and spoof-protection solution comprising a grammar for specifying high-level intents and compilation to low-level ow-rules; • We architect and implement our solution as an SDN application on the ONOS Controller platform, coupled with live BGP information and geo-mapping services; • We evaluate our system using real hardware and trafc in terms of its correctness, responsiveness, and scalability to a large number of ow-rules. e rest of the paper is organized as follows: §2 presents relevant background on SDXs, intent frameworks and security at modern IXPs. §3 and §4 talks about the policy grammar and system architecture respectively. Our compiler algorithm is described in §5 and §6 presents IP Spoofing prevention. Our system is evaluated in §7 and paper is concluded in §8.

Related Work
SDXs [14] [13] have been used for doing tra c engineering and load balancing. Geo-Blocking is a relatively new topic with few expensive solutions such as Packet Viper [10]. Very few solutions [14] [20] have a empted to leverage SDXs, but have not considered Geo-Blocking intents holistically, which is the novelty of our proposed solution. Most of the IP spoo ng solutions like "Network Ingress Filtering" [7] are implemented in a distributed network and can also be reused in a centralized network. Also, black-holing at an exchange point [19] has also been talked about as a way to prevent DDoS a ack and implement ne grained policies using Open ow matches in the fabric. Our previous work CASToR [18] have talked about SDX policies to switch tra c between private and public clouds. A recent work Propane [21] talks about automating BGP con gurations in the network devices using high level abstract language and BGP security has also been talked about recently in [15]. Also, intent based networking is not new and many intent-frameworks [11] [16] and compilers [12] [17] have been proposed in the past.

Geo-Block Policies and Grammar
We develop a high level abstract language speci cation to easily express Geo-Blocking intents or policies in a human readable language. We develop the following structure of a single Geo-Block policy: def e def keyword is used to de ne the policy with a unique associated ID. e policy contains following a ributes as shown above: • Source: Sources can be a combination of standard country codes (e.g AU, US), AS numbers and IP prexes, all separated by commas. ey represent the places from where the tra c is originating.
• Destination: It refers to the domain, AS number or IP pre xes of the services to which the tra c is destined to. is is typically whole or a part of the network of the entity who is passing the Geo-Block policy. E.g. An IXP customer. • Classi er: ese are the network classi ers to restrict the destination space to speci c port numbers or protocols. is eld is not mandatory. • Exceptions: ese refer to the essential services, domains or areas which should not be blocked. It is a crucial part of the policy as some essential services like DNS which lies within the source Geo-area domain may not be blocked. (E.g. Global DNS servers like Google). Other exceptions may include trusted entities like Amazon or Microso Cloud as they may be in use for the functioning of services of the customer passing Geo-Block policies. It may also include speci c IP pre xes which are being used to manage or control any of the destination services. • Time: is is the time for which the Geo-Block policy should remain active and can be in nite which will require to withdraw the policy manually using the ID provided.
Implementing Geo-Blocking and Spoofing Protection in Multi-Domain So ware Defined Interconnects XDOMO'17, April 23, 2017, Belgrade, Serbia • Action: is ENUM action refers to the creation of white-listed or black-listed model. is is the default action for the rest of the tra c which is not mentioned in the Geo-Block policy. If the default action is ALLOW, the sources listed in the policy will be blocked and the rest of the tra c will not be a ected whereas if the default action is BLOCK, all tra c will be blocked except the sources mentioned in the policy.
Exceptions are always allowed. We can see how easily a Geo-Block policy could be expressed using an abstract high level grammar. To realize the same level of details and to implement it in the network is a complex process. If we were to block a country of source, it will require pu ing rules corresponding to all the IP prexes geographically contained within that country. e IP pre xes can range from few hundreds to thousands and maintaining them in the network devices manually is tedious and close to impossible. is process is highly manual and is prone to human errors as some con guration or exceptions may be neglected or missed by the administrator. e challenge is even higher when an operator detects a DDoS a ack on their network and needs to implement these policies using low level rules in the network elements in a very short period. Clearly, implementing a Geo-Block security policy manually in the network can be a nightmare and is the reason why current solutions are not that e ective or are very costly. Automating the whole process and expressing the policies and requirements at an abstract level reduces manual complexity, rules out errors and substantially decreases response time while increasing the accurateness.

System Design and Architecture
Our Geo-Blocking System is built on our CASToR platform, described in the next subsection, and make use of the ONOS controller. Fig. 1 shows the high level architecture of the Geo-Block system and related components. Figure consists of an IXP switching fabric being dynamically programmed by the ONOS controller using Open ow as per the intent and ows passed by CASToR and Geo-Block application.
ere is a route server as in a traditional exchange point for receiving BGP control plane information and advertising it back to all the IXP customers. We make use of BGPMon [3] standard application which peers with the route server and outputs BGP updates in easy to parse XML format which is read by the Geo-Block application.
is information is used by the Geo-Block application to prevent IP spoo ng as described in the next section. e SQLite database is used by the application to maintain the mapping of Geo areas (E.g. Countries), Domains, AS numbers to IP pre xes.

4.1
e CASToR-ONOS Platform e Geo-Block application is built as an add-on on top of CASToR [18] which is our interconnect application wri en on ONOS [9] controller. ONOS provides a high availability, Figure 1. Geo-Block Architecture carrier grade SDN controller platform and its Intent framework [8] provides many low level connectivity intents to easily program the data plane. CASToR application wri en over ONOS provides the facility of con guring the IXP customers and provisioning of the control plane as well as the data plane connectivity amongst all IXP members through a simple web interface. CASToR is now a part of the o cial release of ONOS.

Geo-Block Application
e Geo-Block application consists of two main components: • Policy Parser: It is used to parse and break down the high level policies into lower level components of the policy. e application exposes a REST API to accept the high level policies in the form of a string as described in the previous section. Our parser integrates an e ective language parsing tool ANTLR [1] which is used to de ne a grammar and break down the intents into di erent components such as blocking, connectivity and exception policies. is information is then used by the compiler as stated next.
• Compiler: It takes the low level policy and parsed components from the parser and translates them into ONOS intents and nally into ow level rules which can be installed into the switching fabric. is process is detailed in the compiler algorithm section.

Geo-Block Database
is essential database holds thousands of entries and mappings used for translating the Geo country codes, domains, AS numbers to the corresponding IP pre xes. e database is implemented using SQLite and a Django back-end framework [4] supporting the necessary REST APIs for querying the database. e geographical IP pre x ownership data is provided by a trusted source Maxmind [6] and can be synced on a per weekly or monthly basis. Some of the data was also collected from Hurricane Electric BGP toolkit [5]. e Django Back-end implementation also provides con gurable APIs which can be used to add extra data to the database manually by the administrator which is speci c to its customers. For E.g.-Exceptions and global DNS servers IP addresses and pre xes can be added manually and updated on a regular basis very easily.

Compiler Algorithm
e compiler is responsible for translating the high level policies into low level network ow rules which can be installed into the switching fabric to realize the intent. Fig. 2 shows a detailed owchart of the compilation process and is explained below: • e Policy Parser in the Geo-Block application receives the intents and parse them into useful tokens which can be mapped into JAVA classes and objects. e source and exception tokens are queried to get their corresponding IP pre xes from the database using REST APIs. New lower level policies are formulated using the IP pre xes which contains set of sources, destination and network classi ers. From here, exceptions are separated from the policies and are treated separately.
• Exceptions are always allowed. erefore, they are converted into ONOS connectivity intents and are ultimately translated to network ow rules. • If the default action was BLOCK, which means everything except the sources provided in the policy should be blocked, connectivity intents and ow rules are created to allow those sources to the destination. • If the default action was ALLOW, the sources speci ed needs to be blocked and everything else is allowed. e blocking ow objectives are created at the egress on the device where the customer passing the policy is located. Location info of the customers is provided by CASToR. A suitable destination match is selected -If the destination is a subset of customer's network, IP pre xes supplied in the destination are used as a match. If the destination is whole of the customer, only destination MAC is required and reduces number of ow rules. • IP spoo ng ltering rules are also created using the BGP information received through BGPMon. ese IP spoo ng ltering rules are regularly updated whenever there is a new BGP update which is shown in the ow chart as 'Live BGP Trigger'. IP spoo ng is described in detail in the following section.

IP Spoo ng prevention
IP spoo ng can be used to bypass the Geo-Blocking solution to a certain extent. ough, a full proof IP spoo ng prevention solution is not realistic, Ingress Filtering is o en used as a precaution in many data centers and routers. We implement ingress ltering to prevent IP spoo ng and make the Geo-Blocking solution more e ective. An IP-Spoo ng policy can be wri en and passed in the following format: def spoof protect (Policy Id) { Customer = [IP address of the Border Router] } Customer requesting the IP spoo ng protection service will provide the IP address of its Border Router using which it is connecting to the exchange. A er passing this policy, a direct customer of the IXP will only be able to send tra c with source IP address which belongs to it and are advertised Implementing Geo-Blocking and Spoofing Protection in Multi-Domain So ware Defined Interconnects XDOMO'17, April 23, 2017, Belgrade, Serbia at the IXP using BGP. is BGP control plane information is made available by BGPMon who peers with the route servers to get all the BGP updates and pass them to the Geo-Block application in an XML format. is is used to create ltering rules at the ingress of each direct IXP customer who asks for the IP spoo ng policy or service perhaps at a cost.
is is bene cial, as it saves the customer from the liability of originating an IP spoo ng a ack. For E.g. consider the scenario in Fig. 3. Figure 3. IP Spoo ng scenario C1 and C2 are two direct IXP customers in the same geographical area, say Australia (AU). A acker is present outside AU and is connecting via an ISP (Internet Service Provider) peering at the exchange. C1 passes a Geo-Block policy blocking all tra c coming to it from outside AU. If the a acker is able to compromise some machines (bots) in C2's network, it can use them to originate malicious tra c with spoofed IP sources belonging to C1. is technique could be used in launching a DNS re ection DDoS a ack on C1. However, if the IP spoo ng rules are implemented, C2 will not be able to originate any spoofed tra c as it will only be allowed to send tra c with sources being advertised by it using BGP. Hence, all spoofed tra c will be dropped at the ingress point of C2 at the IXP. is could save C2 from being liable of originating an a ack. ough this ltering is very e ective, it is not full proof as it can be overridden in IP Pre x hijack situations. is technique will also fail if the a acker itself spoofs the addresses of C1 (Victim) as ISP will not have much interest in implementing and paying for the ingress ltering on its side.

Prototype Evaluation
We tested our prototype Geo-Block application in a laboratory testbed as shown in Fig. 4. e testbed emulated an SDN enabled exchange point and consisted of a single Open-Flow switch (NoviFlow NS1132), a controller running ONOS and the Geo-Block application, a single route server and three connected routers (peers) to represent autonomous systems that interconnect at the exchange point. e controller and the route server were hosted in virtual machines on commodity servers while the border routers of the three peers used were Cisco 3800 series. For test tra c we used a Spirent TestCenter equipped with a 12-port Hypermetrics CM 10/100/1000 module and rmware version 4.24.1026. e Spirent generator acted as both a tra c source and sink and allowed us to very accurately measure performance metrics such as throughput, loss and latency for multiple concurrent ows and generate tra c up to line rate. e capacity of each link between the border routers and the NoviFlow switch is shown in the Figure. With this setup we were able to replicate, to a reasonable approximation, the Australian Census a ack. We assumed that the Census website and associated infrastructure were accessed via AS 1 while a ack tra c in the form of a DDoS was sourced from outside Australia via AS 3. e legitimate tra c originating within Australia was sourced from AS 2. All tra c originated in AS 2 and AS 3 and was destined for AS 1 where the Census website is located. With the Spirent we used a combination of public source IP addresses to emulate hosts from within Australia and hosts external to Australia. e gure shows the total tra c rates from sources outside and inside Australia together with the combined rate. Initially the outside tra c rate was approximately 80 Mb/s and the inside rate 500 Mb/s. In this case, the link connecting AS 1 is not oversubscribed and there is no packet loss. At some time between 100 and 200s we initiated a DDoS a ack by increasing the outside Australia tra c rate to 500 Mb/s thus driving the utilization of the link connecting AS 1 to 100%.
ere was still no loss of the legitimate tra c so we then increased the DDoS rate to 1 Gbps at approximately 300s. e gure clearly shows that the link to AS 1 became congested and consequently the legitimate tra c streams experienced loss rates of 30-35% on an average, demonstrating that with no mitigation the DDoS a ack was succeeding.
We then invoked the Geo-Block policy in which the controller sent ow table updates to the switch to drop all packets with source addresses from outside Australia.
is resulted in approximately six thousand rules being installed in the switch pipeline that allowed only packets with source XDOMO'17, April 23, 2017, Belgrade, Serbia Himal Kumar †, Anu Mercian * , Sujata Banerjee , Craig Russell , Vijay Sivaraman † Figure 5. Data Tra c Plot addresses corresponding to Australian IP pre xes and all other packets were dropped. e result of this policy can be seen in the gure just before the 500s time marker. e DDoS tra c from outside Australia reduced to zero, the legitimate tra c from within Australia recovered back to 500 Mb/s with no loss and the Census service was fully available again. Our system was responsive and scaled to thousands of ows that were pushed to the switch in no time.

Conclusion
SDXs o er be er programmability and control over the switching fabric and can be used for a wide variety of usecases. In this paper, we studied two new use cases of Geo-Blocking and IP Spoo ng and developed a system on an Open Source platform to implement it. We demonstrated that a simple yet e ective automated Geo-Blocking solution can help in prevention of DDoS a acks and eliminate extraneous tra c with a very low response time. We validated our architecture and implementation using experimentation with a practical scenario on real hardware and systems. e developed system will be open-sourced and made available as an add-on to the CASToR application of ONOS in its next o cial release.