SiegeBreaker: An SDN Based Practical Decoy Routing System
Piyush Kumar Sharma, Devashish Gosain, Himanshu Sagar, Chaitanya Kumar, Aneesh Dogra, Vinayak Naik, H. B. Acharya, Sambuddho Chakravarty
https://censorbib.nymity.ch/#Sharma2020a
Presentation video
https://github.com/Piyush825/SiegeBreaker
This paper is about a decoy routing design called SiegeBreaker. What makes it different from other systems is that it is implemented using software-defined networking (SDN), with a modular design that reduces the traffic inspection load on routers and makes it easy for the proxy server to see only the subset of traffic that is intended for decoy routing. SiegeBreaker is a flow-blocking system: the decoy router is installed as a serial element at an ISP and decides forwarding for each packet, based on whether the packet is part of a covert decoy routing flow. SiegeBreaker therefore questions the design maxim of other systems like TapDance and Conjure, that decoy routing systems must avoid flow blocking to be realistically deployable. The position of the authors is that software-defined networking is fast, reliable, and cost-effective enough to make a flow-blocking design tenable.
Software-defined networking divides the task of routing between a controller and switches. The controller, capable of generic though relatively low-speed computation, sets network policy; the switches carry out the policy set by the controller using their high-speed flow tables. The SiegeBreaker protocol begins with the client sending a message to the SDN controller over an unblockable channel (the prototype uses email). The message contains the IP address of the overt destination and the TCP Initial Sequence Number that the client plans to use in its future decoy routing session. On receiving the client’s message, the SDN controller configures its switches to divert TCP connections that have a matching Initial Sequence Number and destination IP address back to the controller itself. The controller inspects all such diverted packets, until it observes a TCP SYN packet with the previously registered Initial Sequence Number and a subsequent TLS handshake. Then the controller updates the switches’ flow rules to forward the remainder of the connection to a secret proxy—the controller does not participate in the protocol after this point. The secret proxy resets the TCP connection with the covert destination (spoofing the client’s source IP address) and sends proof back to the client that the decoy routing session has begun. The client then carries on a proxy session with the secret proxy, tunneled in TLS using a newly negotiated master key.
An important aspect of the design is that the SDN controller, which is the slower, general-purpose component, is involved only at the beginning of the protocol, and thereafter is disengaged, with the bulk of the session being handled by high-speed switches. This speed, however, comes at a cost: without additional care, the secret proxy will not have the same TCP/IP fingerprint as the overt destination; and because the secret proxy bypasses its local kernel to spoof the destination IP address of the client, it must emulate TCP algorithms such as congestion control in userspace. Another benefit of SiegeBreaker is that the secret proxy, which forwards client traffic to the covert destination, is a separate component from the SDN infrastructure that is responsible for identifying decoy routing flows. This allows for flexible trust relationships; for example, an ISP might trust a third party to operate a secret proxy for decoy routing users, but not trust the third party to inspect every flow on the ISP’s premises. The ISP can run the SDN components, which see everything, and selectively forward only those flows that are confirmed to be decoy routing to the secret proxy. The authors provide suggestions for how existing decoy routing systems could adopt a similar modularization in Appendix A.2.
The authors give a prototype implementation, using the Ryu SDN controller and an HP 3500 yl switch, and test it in a lab environment, with induced non-decoy-routing background load of 15 Gbps or 50000 parallel HTTP connections. The performance of transfers under SiegeBreaker is very similar to direct TCP connections, after a few seconds for bootstrapping.
Thanks to Piyush Kumar Sharma for commenting on a draft of this summary.