Open wkrp opened 3 years ago
itshaadi
commented
3 years ago I don't see how individuals can deploy this solution? you can't just deploy a switch in the real world. they simulated an environment where they had full control over it. you don't have that kind of power in the real world, you can't change the rules of the game. maybe if they had implemented the "Flow Table" in eBPF then it would have been more accessible for individuals.
wkrp
commented
3 years ago I don't see how individuals can deploy this solution?
It's true that SiegeBreaker is not something that an individual can deploy, but that's in common with all decoy routing / refraction networking systems. They all require cooperation with an ISP. That's how these systems can be blocking-resistant without any secret information. The censor knows that the ISP's routers are being used for decoy routing, but the ISP routes a mix of both circumvention and (mostly) non-circumvention traffic. The censor cannot distinguish which is which, so it cannot block the circumvention without also blocking everything else going through the routers. Blocking resistance comes from the assumption that it is costly for the censor block so much non-circumventing traffic.
A person could set up their own decoy router on a host they control, but then it wouldn't have any blocking resistance. 100% of the traffic to the personal decoy router would be circumvention, so once it was discovered, the censor could block it with essentially zero cost. Any blocking resistance the decoy router would have would only come from keeping the router secret, which is not how decoy routing is meant to work. A decoy router you set up yourself is not really any different than a simple TLS proxy you set up yourself.
The requirement to involve an ISP is a big hurdle, but actual deployment of refraction networking has been done:
I asked the authors of the SiegeBreaker paper if they had approached any ISPs, and if they had, what was the reaction. They said that they had not, because the ISPs in India are known to work so closely with government information controllers that they see it as a lost cause in that country.
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.