1. MobilityFirst Future Internet Architecture Project Project Update – Part I Oakland FIA Meeting, May 2011 Contact: D. Raychaudhuri WINLAB, Rutgers University Technology Centre of NJ 671 Route 1, North Brunswick, NJ 08902, USA ray@winlab.rutgers.edu

2. MobilityFirst Summary May 2011 MobilityFirst Project: Collaborating Institutions (LEAD) + Also industrial R&D collaborations with AT&T Labs, Bell Labs, NTT DoCoMo,, Toyota ITC, NEC, Ericsson and others D. Raychaudhuri, M. Gruteser, W. Trappe, R, Martin, Y. Zhang, I. Seskar, K. Nagaraja, S. Nelson S. Bannerjee W. Lehr Z. Morley Mao B. Ramamurthy G. Chen X. Yang, R. RoyChowdhury A. Venkataramani, J. Kurose, D. Towsley M. Reiter Project Funded by the US National Science Foundation (NSF)

3. Architecture Summary

4. MobilityFirst Summary May 2011 INTERNET 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 Wireless Edge Network Wireless Edge Network INTERNET ~1B server/PC’s, ~700M smart phones ~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors ~2010 ~2020 Wireless Edge Network Wireless Edge Network

5. MobilityFirst Summary May 2011 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..)

6. MobilityFirst Summary May 2011 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

7. MobilityFirst Summary May 2011 Architecture Concepts: Name-Address Separation 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 Globally Unique Flat Identifier (GUID) John’s _laptop_1 Sue’s_mobile_2 Server_1234 Sensor@XYZ Media File_ABC Host Naming Service Network Sensor Naming Service Content Naming Service Global Name Resolution Service Network address Net1.local_ID Net2.local_ID Context Naming Service Taxis in NB

8. MobilityFirst Summary May 2011 Architecture Concepts: Global Name Resolution Service 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 AP Global Name- Address Resolution Service Data Plane Host GUID Network – NA2 Network – NA1 NA1 Registration update Mobile node trajectory Initial registration Name, Context_ID or Content_ID Network Address Host GUID NA2 Decentralixed name services Hosted by subset of ~100,000+ Gatway routers in network

9. MobilityFirst Summary May 2011 Architecture Concepts: Storage-Aware Routing (GSTAR) 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.. Storage Router Low BW cellular link Mobile Device trajectory High BW WiFi link Temporary Storage at Router Initial Routing Path Re-routed path For delivery Sample CNF routing result PDU

10. MobilityFirst Summary May 2011 Architecture Concepts: Segmented Transport 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. Storage Router Low BW cellular link Segmented (Hop-by-Hop TP) Optical Router (no storage) PDU Hop #1 Hop #2 Hop #3 Hop #4 Temporarily Stored PDU BS GID/Service Hdr Mux Hdr Net Address Hdr Data Frag 1 Data Frag 2 Data Frag n …… Hop-by-Hop Transport More details of TP layer fragments with addl mux header

11. MobilityFirst Summary May 2011 Architecture Concepts: Context Aware Delivery 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 Mobile Device trajectory Context = geo-coordinates & first_responder Send (context, data) Context-based Multicast delivery Context GUID Global Name Resolution service ba123 341x Context Naming Service NA1:P7, NA1:P9, NA2,P21,..

12. MobilityFirst Summary May 2011 Protocol Design: Packet Headers and Forwarding with Hybrid GIUD/NetAddr Hybrid scheme in which packet headers contain both the object name (GUID) and topological address (NA) routing NA header used for “fast” path, with fallback to GUID resolution where needed Enables flexibility for multicast, anycast and other late binding services GUID/Service Header GID-Address Mapping Routing Table GUIDNA xz1756.. Net 1194 GUID/Service Header NA Header Dest NA Path Net 123 Net11, net2,.. GUID –based forwarding (slow path) Network Address Based Routing (fast path) Name-GID Mapping NameGUID server@winlabxy17519bbd GID/Service Header NA Header Data Object (100B-1GB) PDU with GUID Header only PDU with GUID and NA headers GUID/Public Key Hash SID (Service Identifier) GUID Header Components Optional list of NA’s -Destination NA -Source route -Intermediate NA -Partial source route

13. MobilityFirst Summary May 2011 Use Cases: GUID/Address Routing Scenarios – Dual Homing The combination of GUID and network address helps to support new mobility related services including multi-homing, anycast, DTN, context, location … Dual-homing scenario below allows for multiple NA:PA’s per name Data Plane GUID DATA Send data file to “Alice’s laptop” Net 1 Net 7 Current network addresses provided by GNRS; NA1:PA22 ; NA7:PA13 GUID NA1:PA22; NA7:PA13 DATA GUID NA1:PA22; NA7:PA13 DATA Router bifurcates PDU to NA1 & NA7 (no GUID resolution needed) Dual-homed mobile device GUID NetAddr= NA7.PA13 DATA GUID NetAddr= NA1.PA22 DATA Alice’s laptop GUID = xxx

14. MobilityFirst Summary May 2011 Use Cases: GUID/Address Routing Scenarios – Handling Disconnection Intermittent disconnection scenario below uses GUID based redirection (late binding) by router to new point of attachment Data Plane GUID DATA GUID NetAddr= NA1.PA7 DATA Send data file to “Alice’s laptop” Mobility Trajectory Disconnected Region Net 1 Net 7 Current network address provided by GNRS; NA1 – network part; PA9 – port address GUID NetAddr= NA1.PA9 - Delivery failure DATA GUID DAT A PDU Stored in router - GUID resolution for redirection GUID NetAddr= NA7.PA3 Successful redelivery after connection DATA

15. MobilityFirst Summary May 2011 Use Cases: GUID/Address Routing Scenarios – Multicast/Anycast/Geocast Multicast scenario below also uses GUID Network Address resolution (late- binding) at a router closer to destination (..GUID tunnel) GUID DATA GUID = mcast group NetAddr= NA1 DATA Send data file to “WINLAB students” Late GUID addr Binding at NA1 Net 1 Net 7 Intermediate network address NA1 provided by GNRS NetAddr=NA1:PA1,PA2,PA9; NA7,PA22 GUID DATA NetAddr=NA1,PA1 NetAddr=NA1,PA2 NetAddr=NA7,PA22 Port 1 Port 2 Port 22

16. MobilityFirst Summary May 2011 Public keys addresses for hosts & networks; forms basis for  Ensuring accountability of traffic  Ubiquitous access-control infrastructure  Secure routing; no address hijacking Emphasis on achieving robust performance under network stress or failure  Byzantine fault tolerance as a goal  Transform malicious attacks into benign failure  Performance observability (in management plane) Intentional receipt policies at networks and end-user nodes  Every MF node can revert to GUID level to check authenticity, add filters,.. No globally trusted root for naming or addressing  Opens naming to innovation to combat naming-related abuses  Removes obstacles to adoption of secure routing protocols Security Considerations:

17. MobilityFirst Summary May 2011 Privacy Considerations: Public keys as addresses enable their use as pseudonyms  Can be changed frequently by end-users to interfere with profiling  Flat-label PKI addresses provide an additional layer of routing privacy Openness in naming & addressing introduces competition on grounds of privacy  E.g., enable retrieval of mappings in a privacy-preserving way Virtual service provider framework can optionally provide enhanced support for privacy  E.g., constant-rate traffic between routers to defeat traffic analysis Route transparency and selection supports user choice on privacy grounds

18. MobilityFirst Summary May 2011 Security Considerations: Trust Model NET NA1 NET NA7 NET NA33 NA 51 NA 99 NA 14 NA 88 Network Naming Service A Network Naming Service B GNRS Aggregate NA166: NA14, NA88, NA 33 Host Naming Service X Content Naming Service Y Context Naming Service Y Other Naming Services TBD Secure InterNetwork Routing Protocol Secure Host Name Service Lookup Secure GNRS Update Secure Network Name Service Lookup Secure Data Path Protocol Name assignment & certification services (..can incorporate various kinds of trust including CA, group membership, reputation, etc GUID = public Key GUID NA binding Public Key object and network names enable us to build secure protocols for each interface shown

19. MobilityFirst Summary May 2011 Security: Specific MobilityFirst Challenges Achieving Byzantine robustness objectives Securing the Global Name Resolution Service Balancing location privacy while providing access to authorized applications Trust model for dynamic network formation (mobile platforms, ad hoc nets, DTN, etc.) DDoS attacks exploiting context/multicast services In-network storage and computing attacks Wireless PHY or mobility attacks on access network resources

20. MobilityFirst Summary May 2011 Project Website http://mobilityfirst.rutgers.edu