MobilityFirst Future Internet Architecture ProjectProject Update – Part IOakland 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

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. LehrZ. Morley Mao

B. Ramamurthy

G. ChenX. Yang, R. RoyChowdhury

A. Venkataramani, J. Kurose, D. Towsley

M. Reiter

Project Funded by the US National Science Foundation (NSF)

Architecture Summary

MobilityFirst Summary May 2011

INTERNET 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

WirelessEdge Network

WirelessEdge Network

INTERNET INTERNET

~1B server/PC’s, ~700M smart phones

~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors

~2010~2020

WirelessEdge Network

WirelessEdge Network

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..)

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

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 NamingService

Network

SensorNamingService

ContentNamingService

Global Name Resolution Service

Network addressNet1.local_ID

Net2.local_ID

ContextNamingService

Taxis in NB

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

Registrationupdate

Mobile nodetrajectory

Initialregistration

Name, Context_ID or Content_ID Network Address

Host GUID

NA2

Decentralixed name servicesHosted by subset of ~100,000+ Gatway routers in network

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

MobileDevicetrajectory

High BW WiFi link

TemporaryStorage atRouter

Initial Routing Path

Re-routed pathFor delivery

Sample CNF routing result

PDU

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 #4TemporarilyStored PDU

BS

GID/Service Hdr

Mux Hdr

Net Address Hdr

Data Frag 1

Data Frag 2

Data Frag n

……

Hop-by-HopTransport

More details ofTP layer fragmentswith addl mux header

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

MobileDevicetrajectory

Context = geo-coordinates & first_responder

Send (context, data)

Context-basedMulticast delivery

ContextGUID

Global Name Resolution service

ba123341x

ContextNamingService

NA1:P7, NA1:P9, NA2,P21, ..

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

GUID NA

xz1756.. Net 1194

GUID/ServiceHeader

NA Header

Dest NA Path

Net 123 Net11, net2, ..

GUID –based forwarding(slow path)

Network Address Based Routing(fast path)

Name-GID Mapping

Name GUID

server@winlab xy17519bbdGID/ServiceHeader

NA Header

Data Object(100B-1GB)

PDU with GUIDHeader only

PDU with GUIDand NA headers

GUID/Public Key Hash

SID(ServiceIdentifier)

GUID Header Components

Optional list of NA’s- Destination NA- Source route - Intermediate NA- Partial source route

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

GUIDNA1:PA22; NA7:PA13

DATA

GUIDNA1:PA22; NA7:PA13

DATA

Router bifurcates PDU to NA1 & NA7(no GUID resolution needed)

Dual-homed mobile device

GUIDNetAddr= NA7.PA13

DATA

GUIDNetAddr= NA1.PA22

DATA

Alice’s laptopGUID = xxx

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

GUIDNetAddr= NA1.PA7

DATA

Send data file to “Alice’s laptop”

MobilityTrajectory

DisconnectedRegion

Net 1

Net 7

Current network address provided by GNRS;NA1 – network part; PA9 – port address

GUIDNetAddr= NA1.PA9- Delivery failure

DATA

GUID

DATA

PDU Stored in router- GUID resolution for redirection

GUIDNetAddr= NA7.PA3Successful redelivery after connection

DATA

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= mcastgroup

NetAddr= NA1

DATA

Send data file to “WINLAB students”

Late GUID <-> addrBinding at NA1

Net 1

Net 7

Intermediate network address NA1provided 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

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:

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

MobilityFirst Summary May 2011

Security Considerations: Trust Model

NET NA1

NET NA7

NET NA33

NA 51 NA 99

NA 14

NA 88

NetworkNamingService

A

NetworkNaming Service

B

GNRS

Aggregate NA166: NA14, NA88, NA 33

HostNamingService

X

ContentNamingService

Y

ContextNamingService

Y

OtherNamingServices

TBD

Secure InterNetworkRouting Protocol

SecureHostName

ServiceLookup

SecureGNRSUpdate

SecureNetwork

NameServiceLookup

SecureData PathProtocol

Name assignment& certification services (..canincorporatevarious kinds oftrust 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

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

MobilityFirst Summary May 2011

Project Website

http://mobilityfirst.rutgers.edu