A Layered Naming Architecture for the Internet

1. A Layered Naming Architecture for the Internet Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, Michael Walfish IRIS Project [NSF]

2. Architectural Discontents in Today’s Internet • Lack of features • End-to-end QoS, host control over routing, end-to-end multicast,… • Lack of protection and accountability • Denial-of-service (DoS) • Architecture is brittle (fragile)

3. Architectural Brittleness • Hosts are tied to IP addresses • Mobility and multi-homing pose problems • Services are tied to hosts • A service is more than just one host: replication, migration, composition • Packets might require processing at intermediaries before reaching destination • “Middleboxes” (NATs, firewalls, …)

4. Naming Can Help • Our thesis: proper naming can cure some ills • Layered naming provides layers of indirection and shielding • Many proposals advocate large-scale, overarching architectural change • Routers, end-hosts, services • Our proposal: • Changes “only” hosts and name resolution • Synthesis of much previous work

5. Internet Naming is Host-Centric • Two global namespaces: DNS and IP addresses • These namespaces are host-centric • IP addresses: network location of host • DNS names: domain of host • Both closely tied to an underlying structure • Motivated by host-centric applications

6. The Trouble with Host-Centric Names • Host-centric names are fragile • If a name is based on mutable properties of its referent, it is fragile • Example: If Joe’s Web page www.berkeley.edu/~hippie moves to www.wallstreetstiffs.com/~yuppie, Web links to his page break • Fragile names constrain movement • IP addresses are not stable host names • DNS URLs are not stable data names

7. Key Architectural Questions • Which entities should be named? • What should names look like? • What should names resolve to?

8. Name Services and Hosts Separately • Service identifiers (SIDs) are host-independent data names • End-point identifiers (EIDs) are location-independent host names • Protocols bind to names, and resolve them • Apps should use SIDs as data handles • Transport connections should bind to EIDs Binding principle: Names should bind protocols onlyto relevant aspects of underlying structure

9. Application Use SID as handle App session Bind to EID Transport IP hdr EID TCP SID … IP The Naming Layers User-level descriptors(e.g., search) App-specific search/lookup returns SID App session Resolves SID to EIDOpens transport conns Transport Resolves EID to IP IP

10. Key Architectural Questions • Which entities should be named? • What should names look like? • What should names resolve to?

11. SIDs and EIDs should be Flat0xf436f0ab527bac9e8b100afeff394300 Stable-name principle: A stable name should not impose restrictions on the entity it names • Flat names impose no structure on entities • Structured names stable only if name structure matches natural structure of entities • Can be resolved scalably using, e.g., DHTs • Flat names can be used to name anything • Once you have a large flat namespace, you never need other global “handles”

12. Flat Names Enable Flexible Migration • SID abstracts all object reachability information • Objects: any granularity (files, directories) • Benefit: Links (referrers) don’t break Domain H HTTP GET: /docs/pub.pdf 10.1.2.3 <A HREF= http://f012012/pub.pdf >here is a paper</A> /docs/ HTTP GET: /~user/pubs/pub.pdf Domain Y 20.2.4.6 (10.1.2.3,80, /docs/) /~user/pubs/ (20.2.4.6,80, /~user/pubs/) ResolutionService

13. Flat Names are a Two-Edged Sword • Global resolution infrastructure needed • Perhaps as “managed DHT” infrastructure • Lack of local name control • Lack of locality • Not user-friendly • User-level descriptors are human-friendly

14. Key Architectural Questions • Which entities should be named? • What should names look like? • What should names resolve to?

15. Delegation • Names usually resolve to “location” of entity • Packets might require processing at intermediaries before reaching destination • Such processing today violates layering • Only element identified by packet’s IP destination should inspect higher layers Delegation principle: A network entity should be able to direct resolutions of its name not only to its ownlocation, but also to chosen delegates

16. Packet structure (dests only) ipf EID d TCP hdr Firewall EID f IP ipf Delegation Enables Architecturally-Sound Intermediaries Resolution svc EID d IP ipd EID s • Delegate can be anywhere in the network, not necessarily on the IP path to d (ipd) • SID/EID can resolve to sequence of delegates

17. ipv EID eidv TCPSID v data SID ms msg Spam/virus filterSID v,EID eidv, IP ipv Application-Layer Intermediaries Resolution svc fmid is SID for composed service EID s Mail serverSID ms Goal: Email to user must traversespam filter en route to mail server

18. Related Work • Most direct inspiration: HIP + i3 + SFR • Prototype: Delegation-Oriented Arch. (DOA) • EID proposals: Nimrod, HIP, Peernet • Mobility/multihoming: Mobile IP, IPv6, Migrate • Intermediaries: IPNL, TRIAD, UIP, P6P, MIDCOM • SID-like proposals: URNs, Globe, ONH • Other architecture proposals • PIP, Nimrod, IPv6, Active Networks, … • FARA, Smart Packets, Network Pointers, Predicate Routing, Role-based Architecture

19. Take-Home Points • Flat names are now plausible • Two flat naming layers fix brittleness • SIDs and EIDs • Delegation is a powerful primitive

20. The Future? • With flat SID/EID + delegation: • Like hosts, data becomes first-class entity • Middleboxes gracefully accommodated • IP will continue to be a rigid infrastructure • But naming is more malleable and can reduce architectural brittleness • Deployment requires • Changes to hosts • Global resolution infrastructure