# SD-BROV: An Enhanced BGP Hijacking Protection with Route Validation in Software-Defined eXchange
## 4 Implementation and Evaluation
### L3-SDX/Controller Application  
In operation, the developed SDX controller application is co-operating with ONOS. After the peering session is activated, SDN-IP application then creates a Single-Point to Single-Point (SP2 SP) intent between two eBGP routers and BGP speaker to establish the datapath communication. On the next step, when a new BGP route is identified, it creates Multi-Point to Single-Point (MP2 SP) intent for all eBGP routers in the SDX and advises the best next-hop router towards the destination IP prefix. Finally, this process will establish a direct datapath for AS to carrying peering and transit traffic that traverses through the SDX.  
According to design, Routinator is responsible for downloading certificates and ROA from RIR's RPKI repository and store the information at local cache. The local cache should be updated periodically, including checking the repositories serial numbers, and determining whether it is synced. During the operation, once a new BGP route update event is detected by the SDN-IP application, it conducts ROV against RPKI cache in the Routinator in order to determine the validity and integrity of prefix and associated ASN before installing it to associated intents. For SDX members, the validation information can be obtained by sending HTTP GET method requests to the Routinator HTTP Server. The server will return three types of validity status for specify that route (i.e., valid, invalid, and not-found) to help SDX members setup their filters if needed, which are listed below:  
Figure 5: Physical network connection of the testbed.  
If the route origin ASN and the route prefix are covered in validation data, in the meantime, there is an exact match ROA in RPKI database, then this route is considered as \"valid\".
* If a route prefix is covered by a ROA record but the route origin ASN or the prefix length does not match as stated in the ROA record, the route is identified as \"invalid\".
* If a route prefix is not covered by a ROA record, it will be judged as \"unknown (not found)\".  
For instance, when there is an ROA record in the RPKI (182.176.19.0/24 belongs to AS17557). If AS17557 advertised a BGP route as stated in the ROA, the route will be valid. However, if it advertised a misconfigured route link 182.176.19.0/25, since this route is covered by an ROA record but with a different prefix length), the route is going to be recognized as invalid. Moreover, if AS17557 tried to advertise a route covered by other ROA record (for example, 115.186.169.0/24 that belongs to AS23674), this route is also going to be recognized as invalid. Nevertheless, if AS17557 attempted to advertise a route such as 192.168.200.0/24 that is not covered by any ROA records in the RPKI, this route should be classified as an unknown route. Figure 6 shows the logging information during the ROV progress. In the default policy of SDX application, only valid routes will trigger intent or datapath establishment. Note that MP2 SP will only be created if the route is identified as valid. For other results, there will be neither intent created nor datapath established for such a route.  
For further evaluation, Table 2 lists the results of experiment which was conducted for investigating the time cost of ROV process. According to the results, the number of routing entries is the reason for taking time. Nevertheless, the full table of IPv4 in global network includes more than 855,000 routing entries. The current prototyping system may take a long time to process RPKI validation when activating SD-BROV in SDX initially. The performance enhancement should be one of important topics in future work.