160 likes | 248 Views
Middleboxes No Longer Considered Harmful. Michael Walfish et al. Presented by Steve Ko. Some part of the slides are from the original authors’ slides. Outline. Motivation DOA Overview DOA Details Pros and Cons Firewall Example NAT Example Conclusion. Motivation.
E N D
Middleboxes No Longer Considered Harmful Michael Walfish et al. Presented by Steve Ko • Some part of the slides are from the original authors’ slides
Outline • Motivation • DOA Overview • DOA Details • Pros and Cons • Firewall Example • NAT Example • Conclusion
Motivation • E2E Argument VS. Middleboxes • End-to-end argument • No application-intelligence in the network • Strict layering • Middleboxes • Successful, but ad-hoc • Many problems (NAT, firewall…) • Compromise?
DOA Overview • DOA == Delegation-Oriented Architecture • Position • Let the network do the routing and take out middleboxes out of the network. • Let’s send requests to the middleboxes.
DOA Overview (cont.) • Instead of doing things in the middle, DOA allows to do things explicitly by requests. • DOA adds an indirection layer between IP and TCP/UDP. • Applications don’t use IP anymore, but use different IDs used by DOA. • DOA provides an IP resolution mechanism (ID-IP mappings). • In order to resolve an IP, a packet should go through (multiple) middleboxes.
body source EID IP hdr transport hdr destination EID DOA hdr DOA Details • Every node has a globally-unique ID. • Applications send packets with IDs, not IPs. • An ID is (eventually) resolved into an IP through a separate infrastructure (e.g. DHT). • Packet format
Source EID: es IP: is DHT Delegate IP: j Process <eh, j> LOOKUP(eh) DOA j End-host EID: eh IP: ih body IP is j transport transport DOA es eh DOA es eh DOA Packet DOA Details (cont.) • Simplest Case
DOA eseh DOA ese2eh body body IP is j IP jk DOA Details (cont.) • More complex case DHT LOOKUP(eh) Source EID: es IP: is <eh,e1e2> Delegate IP: k LOOKUP(e1) <e1, j> <e2, k> End-host EID: eh IP: ih LOOKUP(e2) Delegate IP: j
DOA Details (cont.) • Source routing over an overlay of middleboxes. • The last middlebox knows how to reach the final destination.
Pros and Cons • Pros • Middleboxes don’t sit in the middle. They become Internet services (hence, “delegated”). • Middleboxes are not ad-hoc anymore. • Middleboxes can be deployed easily (relatively). • Cons • Applications should be re-written (including DNS) • Latency is a big problem (TCP problem?)
Firewall Source EID: es IP: is eh (ih, Rules) End-host eFW Sign (MAC) Network Stack eh eFW j EID: eFW j j es [eFW eh] is Verify <eFW, j> <eh, eFW> DHT es eh j ih EID: eh ih Firewall Example • Off-path firewall
Firewall Example (cont.) • Firewalls are delegated to other machines. • It can be a firewall service provider. • Destinations have one simple rule (authenticated by the firewall).
es ed es ed is is 5.1.9.9 10.1.1.3 ed 10.1.1.3 5.1.9.9 10.1.1.3 10.1.1.1 Source EID: es IP: is 5.1.9.9 Destination EID: ed ed DHT NAT NATed network NAT Example • Reincarnated NAT
NAT Example (cont.) • Outside machines can initiate connections. • A same port can be used by many machines inside.
Conclusion • DOA provides an architecture for middleboxes. • It enables “middlebox services”. • It reduces harmful effects of current middleboxes.
Discussion • NAT & firewall, what else? • Will there be more middleboxes in the future?