Future Internet Architecture

1. Future Internet Architecture CSC/ECE 573, Section 001 Fall 2012

2. Recent Trend in Internet Research • “Internet architecture was last visited 40 years ago” • Does not necessarily mean it is broken • In fact it is spectacularly not broken • BUT: • Simplicity • Unified view • Evolvability • Maintainability • NSF-sposored FIND and FIA programs • Quick (partial) tour of some FIND and FIA projects • (Apologies to concerned people for mangling) • Other initiatives elsewhere, e.g. FIRE in Europe

3. Virtualization • Diversified Internet Architecture • Jon Turner, Patrick Crowley, Sergey Gorinsky, John Lockwood • Enable diverse metanetworks within common substrate • Objectives • enable diverse metanetworks to co-exist • allow introduction of new network architectures at any time • stimulate development of applications

4. Bulk-Data Transfer • Within Virtualization • Sergey Gorinsky • Bottomline - ideal transport layer for bulk-data application is different from established wisdom in transport layer, and cannot be obtained by simple tweaks of current transport layers

5. Service Architectures • Services Architectures –Network Intermediaries and End-to-end Abstractions • Dan Duchamp, Tilman Wolf • Session Layer Management of Network Intermediaries - Dan Duchamp • Bottomline - transport layer connections should be long-lived, virtual connections, and application flows should be managed as session layer contexts

6. Foreseen Philosophical Problems • Unambitious: just what we don’t need—another hack to the socket/TCP/IP model • Network is still pretty dumb: should know more about session semantics? • If L5 handles end-to-end delivery semantics, what does L4 do?

7. Relation to FIND/GENI • Yes, it’s true—L5 is just a tweak, not a new architecture • But: gives a concrete base for experiments with certain architectural issues: • What is a service? Where is it implemented? Who really provides it—network or host? • State management • Semantics/protocol for control signaling between end system & intermediary • Mapping of function to layers

8. Questions • What services should the network provide? • Should the network offer service at the application level rather than at the datagram level? • Should anybody be allowed to provide services or not (and thus reduce potential for spam, phishing, spyware, etc.)? • Will ease/speed of new service deployment be as important in the future as it has been in the past? Will the rate increase or decrease?

9. Questions (cont.) • Capitalists would like to know: how should accounting/billing work? • Should we construct a network that could, for example, bill per page view? • Socialists would like to know: how can "undesirable uses" of the Internet be limited? • What is the appropriate position for network architects to take regarding the design of censor-able, tap-able, spy-able Internet? • What is the right technical tradeoff point between (1) a "civilized" appropriately-governable Internet, and (2) an Internet permitted "free expression"?

10. End-Middle-End • End-Middle-End, EME IRTF Research group • Paul Francis • Essential idea: E2E model pushes all policy, access, etc. to the edges, but this is not practical. Sometimes you just have to put some processing in the middle • Need an architecture that allows all stakeholders in a connection to: • Know what is going on • Assert their policies: Access control, Steering, Security, Transport

11. Secure Routing • Threats and lessons • Z Morley Mao • New routing services could enable network security services

12. Q & A • Questions to consider • What role should routing play to mitigate against data-plane attacks? • How should data plane filtering be better integrated with control plane filtering (packet filters with route filters)? • What is the role of management plane for routing and data-plane? • How do we enforce networks to practice good network configurations?

13. Source Controlled Routes • Security implications of source routing etc. • Xiowei Yang • Secure routing depends on source routes • But security is the #1 reason to disable source routes • How we can reconcile these two

14. Conclusion Choose paths knowing entities on the paths • The desirable goals • Byzantine-tolerant, accountability, availability, economic incentives, overhead, QoS, manageability… • The right balance of control and exposure • Source-controlled routing  Source routing option in IPv4 or Routing header in IPv6 Deflect without Knowing the paths No control Explicitly list the routers

15. Market-Enabling Architecture • John Musacchio, Jean Walrand, Venkat Ananthram, Galina Schwartz, Shyam Parekh • User should be offered choice between network services and informed of benefits, then the market can play itself out • Security could be achieved by “security insurance” provided by Certification Agency

16. Service Choice Users offered real-time choice: “red”and “blue” “Red”and “blue” not specified to users in detail ISP incentivized to improve along dimensions that matter Unlike ATM, IntServ, DiffServ, service definitions not standardized John Musacchio

17. Internet Today – Security Inadequacy Users do not bear full cost of poor computer maintenance ANALOGY • Drivers do not bear full cost of reckless driving. • Liability insurance incentivizes drivers to be careful. Zzzz John Musacchio

18. Markets for Security Example: Users pay to be certified by a Certification Agency (CA) CA takes on liability for attacks traced back to user CA incentivized to encourage users to take due care $ Zzzz OS Update Antivirus Update John Musacchio

19. User Controlled Routes • Economic implications, this time • Xiaowei Yang • User choice in routing stimulates competition and competition fosters innovation • User choice may preserve the competitiveness in the backbone market, and reward innovative providers • Effectively, similar to Market-Enabling Architecture proposal

20. Contract Switching • A “paradigm shift” from packet-switching • Aparna Gupta, Shivkumar Kalyanaraman, Murat Yuksel • Contracts formed, create labels • Incentives compared at switching points • Appropriately switched • Effectively, virtual ckt-switching with attached financial / economic information • (caveat: over-simplification?) • Also, provide user with techno-economic choice • In this case, also providers

21. Postcards from the Edge • Roy Yates, DipankarRaychaudhuri, Sanjoy Paul, James Kurose • Cache-and-forward • Reliable hop-by-hop transport of large files • Push-pull architecture for opportunistic delivery of files both to and from the wired network • Enhanced naming to provide location information for mobile terminals • Distributed caching of popular content to make peer-to-peer file sharing a first-class service and to enable efficient reliable multicast.

22. Architectural Support for Selectively-Connected End Systems • Mark Allman, Vern Paxson, Ken Christensen, Bruce Nordman • Enable an energy-efficient future Internet • Baked-in assumption of always-on • Fate sharing • Soft-state • E2E • Study how architecture should change for real current devices • Proxy, “limbo”, assistant

23. Economic Viability • On the Economic Viability of Network Architectures • Roch Guerin, KartikHosanagar, Andrew Odlyzko, Zhi-Li Zhang • Focus: what will happen to the Internet and its economics while clean-slate architectures are being deployed? Assess chances of success, economic impact of various architectures

24. Background and Motivation • We are embarking in far-reaching explorations of new technology alternatives for tomorrow’s Internet • But clean-slate does not mean “green field” • There is a behemoth of an incumbent to deal with, and it’s far from standing still • The eventual relevance and success of new alternatives is not just a function of technical superiority • Economic aspects are likely to be equally, if not more important • What can we do to explore the economic viability of emerging “Next Generation Internet” alternatives? 24

25. Project Scope • Three main thrust areas for assessing the economic viability of new network architectures • Investigate and quantify the potential benefits of key proposed architectural features • Virtualization, integration, diversity • Explore when and why the existence of a formidable incumbent can affect the emergence of new technologies • Develop models that account for how the openness and flexibility of an architecture can foster the adoption of new technology, and its ultimate success 25

26. App App App App App App m11 m13 Transport Transport Cross- Service Tuning silo & service mgmt m21 m21 Network m31 m31 Data Link m43 Physical Tuning strategies, hints Composability Constraints m62 m61 Physical Channels Physical Channels SILO: A Reconstructed Protocol Stack m11 m31 m21 m42 m62

27. Stratified Network - Graded Entry “Transport in layers, control and secure across layers” Single Point of Policy and Certification Control Agent Generic Authentication Portable Configuration Need-based per-flow stacks Redundant Path Delivery ??? (Future Service) Composable Service with Control Interface Smooth integration of evolving security A Big Picture Presentation to NSF Oct 07 by SILO Team

28. Things Not Discussed Much • Billing & accountability: • Future network could have forms of billing that tie fine-grained user actions to $$ • E.g., QoS, services accessed • This will necessarily drive notions of identity, accountability • DoS becomes $$ from end sources • Is there anything we can assume (or anti-assume) in this regard?

29. Things Not Discussed Much, con’t • DRM: • Inevitable this will spill over into the network? • Implications for content inspection, caching? • Infrastructure threats beyond DoS: • Theft-of-service, theft-of-customer

30. Things Not Discussed Much, con’t • For new services, how to validate/audit that it’s fully/correctly provided? • …. in the presence of adversaries • For both this and forms of network inspection, how to conduct these • At varying semantic levels • With non-global knowledge?

31. Things Not Discussed Much, con’t • Interdependence between security and management • What sort of security can management services themselves draw upon … • … given that they have to work when things (including security mechanisms) are broken?

32. Things Not Discussed Much, con’t • What about leveraging mutual aid and the fact that there are many more benign actual users than malicious ones? • E.g., collaborative filtering, aggregated/shared analysis • E.g., mechanisms for our friends / social networks to help us in times of overload or uncertainty • “In the real world, selective trust is what makes society work”

33. Things That Gave Me Pause • Some assumptions that security issues could be addressed external to an effort • True: for pinpoint crypto ~ securing a session • False: for system properties / vulnerabilities • How do we best address this division? • Distributed algorithms for which • Adversarial inputs not under consideration • These differ from failures / misconfigurations • Or assumed readily thwarted (e.g., crypto)

34. Things We Should Work Out Soon • Identity building blocks • Assumptions about trusted hardware • Maybe: role of billing / accountability • Capture: • Spectrum of properties being assumed • Spectrum of properties being provided • And for these, what “buy-in” costs / assumptions do they entail?

35. Summary F I N D • 1.5 day Meeting at WINLAB, Rutgers University, May 29-30 • 5 groups: 3 FIND projects and 2 external groups with projects in related space • Transient Network Architecture (TNA) -- CNRI/UNM: Henry Jerez • Day After Network (DAN) --- UIUC: Robin Kravets • Postcards from the Edge: A Cache and Forward Architecture – Rutgers & UMASS: Roy Yates, Sanjoy Paul, Dipankar Raychoudhuri and Jim Kurose • SPINDLE/DTN – BBN: Rajesh Krishnan • Ambient Networks – EU (Ericsson): Lars Lundgren • Goal: explore synergies, identify gaps, define a comprehensive project in the area • Agenda: • 20-30 min talk from each of the 5 groups • Look for Similarities and Synergies • Use of GENI:  What kind of experimental facility (say in GENI) be most valuable to instantiate the specific research project   • Identify open issues/"holes" • Summary of results to be presented at FIND meeting • Detailed agenda, slides, etc. posted at: • http://gaia.cs.umass.edu/rutgers_FIND_meeting

36. ChoiceNet Architecture  Envisions new fundamental high-level entities and interactions  “Economy Plane” to allow alternative representation at all levels  Direct to consumer: funnel reward to each actual provider  Coarse grain: service/transport/path choices  Fine grain: modulation / transcoding algorithm choices  innovation  “Use Plane” for actually using/running purchased service  “Measurement Plane” creating third-party verification opportunities  Measurement plane relevant for wireless  Richer measurement in network than typical netw. management  Network itself can be sensor for CPS  Location, timestamp enriched, correlated information  All become more difficult, yet more necessary, for networks with large number of moving nodes Encourage Alternatives Vote with Your Wallet Know What Happened

37. MobilityFirst Vision: Mobility as the key driver for the future Internet • Historic shift from PC’s to mobile computing and embedded devices… • ~4 B cell phones vs. ~1B Internet-connected PC’s in 2010 • Mobile data growing exponentially – Cisco white paper predicts >1exabyte per month (surpassing wired PC traffic) by 2012 • Sensor deployment just starting, ~5-10B units by 2020 ~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors ~1B server/PC’s, ~700M smart phones Wireless Edge Network INTERNET INTERNET Wireless Edge Network ~2010 ~2020

38. MobilityFirst : High-Level Design Goals Mobility-centric design Migration of 10B network-attached objects (devices, content, users, …) Robustness in presence of channel impairments & disconnections Support for network mobility & dynamic network-of-networks formation Socket API’s designed explicitly for mobility use cases: multicast, anycast, context- or location-aware delivery, etc. (…service innovation at the edge) Strong security and privacy Standard security services (authentication, secrecy, confidentiality, non-repudiation, ..) built into architecture Resistance to common IP network attacks, e.g. address hijacking, DDoS, .. Network protocols designed to be resilient against failures/attacks No single root of trust, flexible trust domains/mechanisms No per-flow state, low control overhead No signaling, reduced end-to-end chatter (back to packet switching basics..)

39. MobilityFirst Summary: Protocol Highlights Separation of naming and addressing Clear distinction between identify of network-attached endpoint and net addr Name (GUID) = “self-certifying” public key; address = flat NA Multiplicity of name assignment and trust management services – encourages specialization & competition High-level services for managing content, context, network trust, etc Fast global name resolution service (GNRS) Integral part of network protocol, resolves GUID  NA in ~100 ms Hybrid GUID/NA routing with self-defining packets NA routing for fast path; late binding GUID routing for advanced services Multicast/anycast as the norm with unicast as special case In-network storage and computing options at routers Seamless integration of switching, storage and DTN modes Hop-by-hop (or segment-by-segment) transport vs. end-to-end TCP

40. Architecture Concepts: Name-Address Separation Sue’s_mobile_2 Server_1234 Media File_ABC Taxis in NB Sensor@XYZ John’s _laptop_1 Host Naming Service Sensor Naming Service Context Naming Service Content Naming Service Globally Unique Flat Identifier (GUID) Global Name Resolution Service Network • Separation of names (ID) from network addresses (NA) • Globally unique name (GUID) for network attached objects • User name, device ID, content, context, AS name, and so on • Multiple domain-specific naming services • Global Name Resolution Service for GUID  NA mappings • Hybrid GUID/NA approach • Both name/address headers in PDU • “Fast path” when NA is available • GUID resolution, late binding option Net2.local_ID Network address Net1.local_ID

41. Architecture Concepts: Global Name Resolution Service Host GUID Registration update NA2 Network – NA2 Mobile node trajectory Data Plane AP Network – NA1 Initial registration Global Name-Address Resolution Service Decentralixed name services Hosted by subset of ~100,000+ Gatway routers in network Host GUID NA1 Network Address Name, Context_ID or Content_ID • Fast Global Name Resolution a central feature of architecture • GUID <-> network address & port number (also called “locator”) mappings • Distributed service, possibly hosted directly on routers • Fast updates ~50-100 ms to support dynamic mobility • Service can scale to ~10B names via P2P/DHT techniques, Moore’s law

42. Architecture Concepts: Storage-Aware Routing (GSTAR) Temporary Storage at Router Initial Routing Path Low BW cellular link Re-routed path For delivery Mobile Device trajectory PDU Storage Router Storage aware (CNF, generalized DTN) routing exploits in-network storage to deal with varying link quality and disconnection Routing algorithm adapts seamlessly adapts from switching (good path) to store-and-forward (poor link BW/disconnected) Storage has benefits for wired networks as well.. High BW WiFi link Sample CNF routing result

43. Architecture Concepts: Segmented Transport PDU Segmented (Hop-by-Hop TP) Hop #3 BS Hop #1 Hop #2 Hop #4 Temporarily Stored PDU Low BW cellular link Storage Router Data Frag n Data Frag 2 Optical Router (no storage) Hop-by-Hop Transport GID/Service Hdr Mux Hdr More details of TP layer fragments with addl mux header Data Frag 1 …… Segment-by-segment transport between routers with storage, in contrast to end-to-end TCP used today Unit of transport (PDU) is a content file or max size fragment Hop TP provides improved throughput for time-varying wireless links, and also helps deal with disconnections Also supports content caching, location services, etc. Net Address Hdr

44. Architecture Concepts: Context Aware Delivery Context = geo-coordinates & first_responder Send (context, data) Context Naming Service Global Name Resolution service NA1:P7, NA1:P9, NA2,P21, .. Context GUID ba123 341x Context-based Multicast delivery Mobile Device trajectory • Context-aware network services supported by MF architecture • Dynamic mapping of structured context or content label by global name service • Context attributes include location, time, person/group, network state • Context naming service provides multicast GUID – mapped to NA by GNRS • Similar mechanism used to handle named content

45. Summary • Many threads of research focusing on architectural issues • “Architecture” at various levels and granularities • Some common concerns recur • Security, accountability • Economics, non-monopoly, choice • Wireless, mobility • Aggregation, scalability • Consensus on problems that need to be dealt with, if not solutions