Transcript MobilityFirst_FIA_Oakland_Summary_5.11

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]
MobilityFirst Project: Collaborating Institutions
(LEAD)
D. Raychaudhuri, M. Gruteser, W. Trappe,
R, Martin, Y. Zhang, I. Seskar,
K. Nagaraja, S. Nelson
M. Reiter
A. Venkataramani, J. Kurose, D. Towsley
S. Bannerjee
W. Lehr
Z. Morley Mao
B. Ramamurthy
X. Yang, R. RoyChowdhury
G. Chen
Project Funded by the US National Science Foundation (NSF)
MobilityFirst Summary
+ Also industrial R&D collaborations with AT&T Labs,
Bell Labs, NTT DoCoMo,, Toyota ITC, NEC, Ericsson and others
May 2011
Architecture Summary
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
MobilityFirst Summary
~2020
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, nonrepudiation, ..) 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


Fast global name resolution service (GNRS)



High-level services for managing content, context, network trust, etc
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
Sue’s_mobile_2

Server_1234
John’s _laptop_1

User name, device ID, content, context,
AS name, and so on
 Multiple domain-specific naming
services


Host
Naming
Service
Media File_ABC
Taxis in NB
Sensor@XYZ
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service
for GUID  NA mappings
Global Name Resolution Service
Network
Hybrid GUID/NA approach

Both name/address headers in PDU
 “Fast path” when NA is available
 GUID resolution, late binding option
MobilityFirst Summary
Net2.local_ID
Network address
Net1.local_ID
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
Host GUID
Registration
update
NA2
Network – NA2
Mobile node
trajectory
Data Plane
AP
Network – NA1
Host GUID
Initial
registration
Global NameAddress Resolution
Service
Decentralixed name services
Hosted by subset of ~100,000+
Gatway routers in network
NA1
Name, Context_ID or Content_ID
MobilityFirst Summary
Network Address
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..
Temporary
Storage at
Router
Initial Routing Path
Low BW
cellular link
Re-routed path
For delivery
Mobile
Device
trajectory
PDU
Storage
Router
High BW
WiFi link
MobilityFirst Summary
Mayresult
2011
Sample CNF routing
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.
PDU
Segmented (Hop-by-Hop TP)
Hop #3
Hop #1
BS
Hop #2
Hop #4
Temporarily
Stored PDU
Low BW
cellular link
Storage
Router
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
Data
Frag 2
……
Data
Frag n
Net Address Hdr
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
Context = geo-coordinates & first_responder
Send (context, data)
Context
Naming
Service
Global Name
Resolution service
Context
GUID
NA1:P7, NA1:P9, NA2,P21, ..
ba123
341x
Context-based
Multicast delivery
Mobile
Device
trajectory
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
Name-GID Mapping
Name
GUID
server@winlab
xy17519bbd
GUID/Service
Header
PDU with GUID
Header only
Data Object
(100B-1GB)
GUID –based forwarding
(slow path)
Optional list of NA’s
- Destination NA
- Source route
- Intermediate NA
- Partial source route
GID-Address Mapping
GUID
NA
xz1756..
GID/Service
Header
Net 1194
GUID/Service
Header
NA Header
NA Header
PDU with GUID
and NA headers
Routing Table
Dest NA
Net 123
Path
Net11, net2, ..
GUID Header Components
GUID/Public Key
Hash
MobilityFirst Summary
SID
(Service
Identifier)
Network Address Based Routing
(fast path)
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
GUID
NA1:PA22; NA7:PA13
Router bifurcates PDU to NA1 & NA7
(no GUID resolution needed)
GUID
DATA
NetAddr= NA1.PA22
Net
1
Alice’s laptop
GUID = xxx
Data Plane
Net 7
Dual-homed
mobile device
DATA
DATA
GUID
NetAddr= NA7.PA13
GUID
NA1:PA22; NA7:PA13
DATA
GUID
Send data file to “Alice’s laptop”
MobilityFirst Summary
Current network addresses provided by GNRS;
NA1:PA22 ; NA7:PA13
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
GUID
NetAddr= NA1.PA9
- Delivery failure
PDU Stored in router
- GUID resolution for redirection
DAT
A
GUID
Mobility
Trajectory
Net
1
Data Plane
Disconnected
Region
Net 7
DATA
GUID
DATA
NetAddr= NA1.PA7
GUID
DATA
GUID
Send data file to “Alice’s laptop”
MobilityFirst Summary
Current network address provided by GNRS;
NA1 – network part; PA9 – port address
NetAddr= NA7.PA3
Successful redelivery after connection
May 2011
Use Cases: GUID/Address Routing
Scenarios – Multicast/Anycast/Geocast

Multicast scenario below also uses GUID <-> Network Address resolution (latebinding) at a router closer to destination (..GUID tunnel)
DATA
NetAddr=NA1,PA1
GUID
NetAddr=NA1:PA1,PA2,PA9; NA7,PA22
NetAddr=NA1,PA2
Late GUID <-> addr
Binding at NA1
Port 1
Port 2
Net 1
Net 7
Port 22
DATA
GUID
= mcast
group
NetAddr=NA7,PA22
NetAddr= NA1
DATA
GUID
Send data file to “WINLAB students”
MobilityFirst Summary
Intermediate network address NA1
provided by GNRS
May 2011
Security Considerations:

Public keys addresses for hosts & networks; forms basis for




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


Ensuring accountability of traffic
Ubiquitous access-control infrastructure
Secure routing; no address hijacking
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
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


Virtual service provider framework can optionally provide
enhanced support for privacy


E.g., enable retrieval of mappings in a privacy-preserving way
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
Host
Naming
Service
X
Content
Naming
Service
Y
Context
Naming
Service
Y
Other
Naming
Services
TBD
Network
Naming
Service
B
GNRS
GUID = public Key
Secure
GNRS
Update
Name assignment
& certification
services (..can
incorporate
various kinds of
trust including
CA, group
membership,
reputation, etc
Secure
Network
Name
Service
Lookup
GUID <-> NA
binding
Secure
Host
Name
Service
Lookup
Network
Naming
Service
A
NET NA7
Secure InterNetwork
Routing Protocol
NET NA1
NET NA33
NA 14
Aggregate NA166:
NA14, NA88, NA 33
NA 88
NA 51
NA 99
Secure
Data Path
Protocol
MobilityFirst Summary
Public Key object and network names enable us to build secure protocols for each interface shown 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
MobilityFirst Summary
May 2011