# TOAR: Toward Resisting AS-Level Adversary Correlation Attacks Optimal Anonymous Routing
## 4 Design of TOAR
### Programmable Interface for Anonymous Routing  
To create and run applications, a software defined programmable interface abstraction is designed for each participating AS, extending support for end-to-end routing while avoiding conflicts with the global routing system. Through software defined, programmable interfaces that support inter-domain communication in SDN, the negotiation and confirmation of end-to-end routing are facilitated. Each AS integrates the programmable interface along with traditional routing functions. Based on the requirements of anonymous services, the ASes publicly expose their interfaces, allowing users such as other ASes to query policies and negotiate routes. Users can select the next hop from a set of available exits, achieving end-to-end routing control.  
The software defined programmable interface, as shown in Figure 4, allows users to query and confirm routing decisions. It enables SDN controllers to manage and program network paths based on application policies and routing protocols. SDN applications and routing protocols are integrated into the SDN controller, which dynamically generatesforwarding rules based on application requirements and network conditions. AS\({}_{v}\) and AS\({}_{u}\) are neighboring ASes, and they exchange routing information via routing protocols such as BGP, which can be enhanced by segment routing for more flexible path control.  
```
0:\(G\), \(r_{1}^{f},r_{1+1}^{f}r_{1}^{b},r_{1+1}^{b},k_{max}\)
0:\(r\)
```  
**Algorithm 2** Iterative optimal search routing algorithm  
When it is necessary to protect privacy-sensitive information within domains, each AS domain must not disclose private information, including routing selection policies, pricing strategies, and exit policies. Therefore, in the process of establishing end-to-end routing, the user needs to check whether the route they wish to establish complies with the policies of each AS domain. The interaction process for inter-domain route selection is shown in Figure 5. For a given end-to-end route \(r=[v_{1},v_{2},\ldots,v_{n}]\), the user queries the ASes along the route in reverse order. First, they query \(AS_{n}\), and if an agreement is reached, the user  
Figure 4: Software defined inter-domain programmable interface.  
can query about the route \(AS_{n-1}\). Then, they query \(AS_{n-2}\), continuing this process until the user's own AS domain \(AS_{1}\) is returned, completing the selection of an end-to-end route. The user ultimately confirms the optimal route \(r\) in the same reverse manner. Separating the route query and confirmation processes prevents the user from facing the price cost for routes not actually used.  
The route queries generated by the user are divided into remote queries and local queries. In a remote query, the user sends a query request to the AS to check whether the selected route complies with the policy, and the result is cached locally. Remote queries are a time-consuming and costly operation. If the route policy exists at the time of the query request, a local query is conducted, and the result is retrieved from the local cache instead.