# SD-BROV: An Enhanced BGP Hijacking Protection with Route Validation in Software-Defined eXchange
## 3 SD-BROV: An SDX-Based BGP Route Origin Validation
### From IXP to SD-BROV  
Since SDX is motivated to solve control capability with SDN Internet by focusing on how operators tackle these problems and show the easy-to-use applications [11], inbound traffic engineering, wide-area server load-balancing, application-specific peering, and specific traffic redirection through the middle box are the insight capabilities of SDX. For instance, AtlanticWave-SDX [19] is an SDX application that supports on-demand virtual circuit provisioning and bandwidth calendaring. For another, Google Espresso [20] is a centralized application-aware traffic engineering instance that enables host-based packet processing to offload Internet-scale routing to end-hosts with multiple strategies. To migrate legacy IXP to SD-BROV (i.e., SDX with BGP route origin validation capability), there are several issues should be considered:  
**SDN Switches/SDX Fabric:** In recent times, Layer 2 based switching fabric [21] is evolving from simple LAN-based connection into WAN-based one. Meanwhile, it is common to utilize IP/MPLS [22] protocols over multiple sites, mapping to assigned optical fiber circuit as well. In contrast, for improving the performance of router with only Layer 3 connection, an alternative solution is to use Virtual Extensible Local Area Network (VXLAN [23]) to enable BGP tunnels. Since VXLAN tunnel is able to span across multiple sites over devices and connections, such an \"SDX Fabric\" can be easily utilized as a virtual network infrastructure. Based on the above points, deploying distributed IXP fabric over several routing facilities with SDN technologies (see Figure 3) is a good choice to gain more benefits from flexibility and resilience in the hybrid Layer 2 and Layer 3 architecture.  
**SDN Controller:** In an exchange point that enables SDN [24], the SDN controller allows SDN switches to match on a variety of header fields (not just destination prefix), performing a range of actions (not just forwarding), and offers direct control over the data  
Figure 3: The operation scenario of SDX Virtual Fabric.  
plane in SDX. Controller applications should manage dataplane switches and integrate routing policies of multiple ASes to a coherent policy set in SDX. By doing this, SDX is able to perform better traffic forwarding by applying fabric-style management through the global view in the SDN controller. Furthermore, in order to apply policy based on global knowledge, SDX should collect and maintain BGP routes, and all SDX participants only need to interact with RS in SDX to receive trusted ones. Moreover, the SDN controller also collects the routes advertised by participating ASes, selecting the best route for each prefix, and re-advertises the best route to SDX participants.  
**Route Validation in SDX:** For large-scale facility, filtering in IX is a critical task [16]. There are basically three peering policies (i.e., open, selective, and restrictive) for IX members, and IX members use open policy in peering operation by default. Hence, peering sessions are usually overwhelming with multilateral interconnection, so an unconstrained routing leak at a route server could easily cause the problem, while with RPKI, prefix lists can be replaced with a single configuration statement pointing to a local RPKI validator--or more than one if multiple values are required for redundancy. Since SDX relies on the SDN controller to manage inter-domain routing, it means before applying BGP routes into the forwarding path, SDX would have a chance to make sure that specific AS owns their IP prefixes indeed. Nevertheless, to implement this process, gaining the controllability of high-level abstraction in datapath (e.g., flow and intent) is required.