1. Michael Walfish, Jeremy Stribling, Maxwell Krohn, Hari Balakrishnan, Robert Morris, and Scott Shenker * 7 December 2004 MIT Computer Science and AI Lab * UC Berkeley and ICSI IRIS Project Middleboxes No Longer Considered Harmful

2. The Problem Middlebox: interposed entity doing more than IP forwarding (NAT, firewall, cache, …) Not in harmony with the Internet architecture No unique identifiers and on-path blocking:  Barrier to innovation  Workarounds add complexity 10.1.1.4 NAT B Host A New traffic class Firewall Host D C

3. Reactions to the Problem Our goal: Architectural extension in which: Middleboxes first-class Internet citizens Harmful effects reduced, good effects kept New functions arise Purist: can’t live with middleboxes Pragmatist: can’t live without middleboxes Pluralist (us): purist, pragmatist both right

4. DOA: Delegation-Oriented Architecture Architectural extension to Internet. Core properties: 1. Restore globally unique identifiers for hosts 2. Let receivers, senders invoke (and revoke) off- path boxes: delegation primitive NAT Host A Firewall Host D 10.1.1.4 0xf12312 B C

5. Outline I.DOA (Delegation-Oriented Architecture) II.Uses of DOA III.Related Work / Conclusion

6. Globally Unique Identifiers for Hosts Location-independent, flat, big namespace Hash of a public key These are called EIDs (e.g., 0xf12abc…) Carried in packets DOA hdr IP hdr transport hdr body source EID destination EID

7. Delegation Primitive Let hosts invoke, revoke off-path boxes Receiver-invoked: sender resolves receiver’s EID to  An IP address or  An EID or sequence of EIDs DOA header has destination stack of EIDs Sender-invoked: push EID onto this stack IP hdr transport hdr body source EID destination EID stack

8. DOA in a Nutshell Delegate IP: j End-host EID: e h IP: i h j DHT LOOKUP( e h ) Process Source EID: e s IP: i s End-host replies to source by resolving e s Authenticity, performance: discussed in the paper DOA Packet IP i s j transport body DOA e s e h DOA transport DOA e s e h

9. A Bit More About DOA Incrementally deployable. Requires:  Changes to hosts and middleboxes  No changes to IP routers (design requirement)  Global resolution infrastructure for flat IDs Recall core properties:  Topology-independent, globally unique identifiers  Let end-hosts invoke and revoke middleboxes Recall goals: reduce harmful effects, permit new functions

10. I.DOA (Delegation-Oriented Architecture) II.Uses of DOA Off-path firewall Reincarnated NAT III.Related Work / Conclusion Outline:

11. Off-path Firewall e h  (i h, Rules) Network Stack isis jeses [e FW e h ] ihih j eses eheh eheh e FW j DHT Source EID: e s IP: i s Firewall End-host ihih j EID: e FW EID: e h Sign (MAC) Verify

12. Off-path Firewall: Benefits Simplification for end-users who want it  Instead of a set of rules, one rule:  “Was this packet vetted by my FW provider?” Firewall can be anywhere, leading to:  Third-party service providers  Possible market for such services  Providers keeping abreast of new applications DOA enables this; doesn’t mandate it.

13. Reincarnated NAT End-to-end communication Port fields not overloaded  Especially useful when NATs are cascaded isis 5.1.9.9 eses eded eded NATed network DHT Source EID: e s IP: i s Destination EID: e d isis 10.1.1.3 eses eded 5.1.9.9 10.1.1.1 10.1.1.3 NAT e d  10.1.1.3

14. Outline: I.DOA (Delegation-Oriented Architecture) II.Uses of DOA III.Related Work / Conclusion

15. Related Work Location/identity split  HIP, FARA, Nimrod, and others Problems from private address realms  IPv6  IPNL, IETF activity (STUN), and others Both of the above  TRIAD, UIP, i3

16. Summary and Conclusion DOA’s goals: architectural extension to:  Reduce middleboxes’ badness + keep goodness DOA’s properties:  Topology-independent, globally unique host ids  Let end-hosts invoke off-path boxes DOA lets users, admins outsource functions  Competitive market in managed services  Can reconcile the purist and the pragmatist Delegation: new property, not new philosophy

17. Appendix Slides

18. Why Does DOA Use... Topology-independent identifiers?  Delegation required  So EIDs need to be “resolvable”  So topology-independence natural Flat identifiers?  Hash of a public key is useful DHTs?  Opportunism; DHTs not fundamental

19. Why Doesn’t DOA Use... 1. IPv6 addresses instead of EIDs?  IPv6 addresses encode attachment point  For delegation to work, EID must be resolved 2. IPv6 addresses and EIDs?  It could  But we think some IPv4 networks will persist  So our focus here was on IPv4 networks 3. Human-friendly DNS names instead of EIDs?  Hash of a public key is useful

20. But NATs are Supposed to Hide Identity True (in some cases) But note: EIDs topology-independent, potentially anonymous If you really don’t want host identities:  You don’t want DOA  You’re willing to deal with the negative effects of NATs and firewalls

21. Can’t Off-Path Boxes Also Be Intolerant? Yes. But under DOA: Intolerance no longer part of physical path  End-host/admin can revoke box  End-host/admin can change boxes Third-party providers can specialize  Which helps avoid unwarranted intolerance Application-specific functions can be moved out of the network

22. Security and Integrity Terminology: EID resolves to e-record Requirements:  Only EID owner can update e-record  Given e-record and EID, anyone must be able to check that the EID owner created the e-record To achieve these properties:  EID = hash(pubkey)  e-record holds pubkey and signature

23. Security and Integrity, Cont’d EID source routing: does not inherit IP source routing difficulties b/c receivers don’t reverse routes to reply to senders Source EIDs can be spoofed  But today’s source IP addresses can be spoofed  Detectable under two-way communication: Host A EID: e a IP: i a Server EID: f IP: j Host B EID: e b IP: i b ibib j ebeb f

24. Latency Terminology: EID resolves to e-record DOA adds RTTs:  DNS lookup: hostname  EID  DHT lookup: EID  e-record  lookup required for receiver to reply to sender To deal with the extra latency:  TTL-based e-record caching by senders  Beehive’s [RS04] proactive, model-driven caching  Cache e-record and EID in DNS  Initiating host could send its e-record

25. Incremental Deployment Host can see if prospective peer is DOA- enabled via DNS lookup on EID_RR If DOA host is behind a non-DOA NAT:  The host delegates its EID to a waypoint on the global Internet  The waypoint sends packets destined to the end-host over UDP or over TCP through the NAT  Might require a new port namespace, as in UIP Applications need to be relinked or ported