Presenter: Costin Raiciu
Middleboxes/Firewalls are deployed everywhere on the Internet, and they break the end-to-end principle making it hard to debug your networking problems. Content Provider Middleboxes (e.g., Google Global Cache) has problems with mobile clients, as a suboptimal content-cache server is kept when the host moves.
Thus, making middleboxes explicit will help to solve this, as the end-host is aware of the middlebox. Further, moving the endpoint of a connection will improve content provider's service quality for mobile clients. Any kind of mobility mechanism (MobileIP, LISP, shim6,...) allows to achieve the above.
With Multipath TCP, we can also achieve this. The advantage with MPTCP is that it has already deployment-success (cfr. Apple iOS7).
- Moving the middle of a connection: Using MPTCP's "ADD_ADDR"-message it is possible to redirect a connection through another middlebox.
- Moving the end of a connection: With the "ADD_ADDR"-message and some state-synchronization between the servers allows to move the end of a connection. State-synchronization through:
- VM migration - state is moved with the VM
- Moving before the application accepts the connection - So, no application-state to migrate. Allows for DoS-protection/load-balancing on a server.
Conclusion:
Connection acrobatics add flexibility to the Internet and is deployable today with MPTCP clients.
Q: You want to allow MitM-attacks:
A: Well, MitM is already there today.
Q: MPTCP is not absolutly necessary to achieve the redirection. Simply address-rewriting achieves the same.
A: Yes, any mobility-mechanism can be used.
Q: This seems like a hammer in the search for a nail - is it really necessary to make middleboxes explicit, and would a provider really want to expose its middleboxes?
A: If you have end-to-end encryption (TCPcrypt,....) and an ISP wants to redirect through a middlebox, you will need this explicit middlebox-redirection. This will move the "power" back to the end-user.
No comments:
Post a Comment