contact: d . raychaudhuri winlab, rutgers university technology centre of nj
DESCRIPTION
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 [email protected]. - PowerPoint PPT PresentationTRANSCRIPT
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
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