Transcript pptx

15-849: Hot Topics in Networking
Four Next Generation Architectures
Srinivasan Seshan
1
Key Questions
• How do these proposals differ in
addressing similar problems?
• Routing
• Addressing
• Service interface
• Security
• Economics/Policy
• Mobility
• Naming
2
Key Questions
• What are the key hurdles for each project?
• Scalability
• Difficult scenarios/usage models
• Inherent complexity
• Handling real-world incentives/economics
• Evolution from current network
3
Key Questions
• Do you believe in basic motivations of
each project?
• Do we really need a new Internet arch?
• If so, how do we deploy this?
• What about IPv6?
4
NSF Programs
• Stagnation
• 100x100  Clean Slate Design
• PlanetLab
• Overcoming the Internet Impasse through
Virtualization  GENI
• FIND  FIA (aka FIND phase 2)
• Phase 1 – 50 “small” projects
• Phase 2 – 4 large “integrative” projects
•
•
•
•
Named Data Networking
MobilityFirst
NEBULA
eXpressive Internet Architecture
5
Named Data Networking
• In the beginning...
– First applications strictly focused on host-to-host
interprocess communication:
• Remote login, file transfer, ...
– Internet was built around this host-to-host model.
– Architecture is well-suited for communication between
pairs of stationary hosts.
• ... while today
– Vast majority of Internet usage is data retrieval and
service access.
– Users care about the content and are oblivious to
location. They are often oblivious as to delivery time:
• Fetching headlines from CNN, videos from YouTube, TV
from Tivo
• Accessing a bank account at www.bank.com.
6
To the beginning...
• What if you could re-architect the way
“bulk” data transfer applications
worked
• HTTP
• FTP
• Email
• etc.
• ... knowing what we know now?
7
Google…
Biggest content source
Third largest ISP
Level(3)
Global
Crossing
Google
8
source: ‘ATLAS’ Internet Observatory 2009 Annual Report’, C. Labovitz et.al.
1995 - 2007:
Textbook Internet
2009:
Rise of the
Hyper Giants
9
source: ‘ATLAS’ Internet Observatory 2009 Annual Report’, C. Labovitz et.al.
What does the network look like…
ISP
ISP
10
What should the network look
like…
ISP
ISP
11
Communication vs. Distribution
12
CCN Model
•
•
•
•
Packets say ‘what’ not ‘who’ (no src or dst)
communication is to local peer(s)
upstream performance is measurable
memory makes loops impossible
13
Context Awareness?
• Like IP, CCN imposes no semantics on names.
• ‘Meaning’ comes from application, institution and
global conventions:
/parc.com/people/van/presentations/CCN
/parc.com/people/van/calendar/freeTimeForMeet
ing
/thisRoom/projector
/thisMeeting/documents
/nearBy/available/parking
/thisHouse/demandReduction/2KW
14
CCN Names/Security
/nytimes.com/web/frontPage/v20100415/s0/0x3fdc96a4...
signature
0x1b048347
key
⎧
⎪
⎨
⎧
⎧
⎪
⎪
⎪
⎨ ⎨ ⎩
nytimes.com/web/george/desktop public key
⎪
⎩
Signed by nytimes.com/web/george
⎪
⎩
Signed by nytimes.com/web
Signed by nytimes.com
• Per-packet signatures using public key
• Packet also contain link to public key
15
Names Route Interests
• FIB lookups are longest match (like IP
prefix lookups) which helps guarantee
log(n) state scaling for globally
accessible data.
• Although CCN names are longer than
IP identifiers, their explicit structure
allows lookups as efficient as IP’s.
• Since nothing can loop, state can be
approximate (e.g., bloom filters).
16
CCN node model
17
CCN node model
get
/parc.com/videos/WidgetA.mpg/
v3/s2
P
/parc.com/videos/WidgetA.mpg/v3/s2
0
18
Flow/Congestion Control
• One Interest pkt  one data packet
• All xfers are done hop-by-hop – so no
need for congestion control
• Sequence numbers are part of the
name space
19
What about connections/VoIP?
• Key challenge - rendezvous
• Need to support requesting ability to
request content that has not yet been
published
• E.g., route request to potential
publishers, and have them create the
desired content in response
20
21
Trust in NDN
22
MobilityFirst
• Fundamental change in design goals and assumptions
•
•
•
•
~10B+ mobile/wireless end-points as “first-class” Internet devices
Mobility as the norm for end-points and access networks
Wireless access – varying link BW/quality, multiple radios, disconnections
Stronger security/trust requirements due to:
•
•
•
•
open radio medium
need for dynamic trust association for mobile devices/users
increased privacy concerns (e.g. location tracking)
greater potential for network failure
• Mobile applications involve location/content/context and energy
constraints
• Technology has also changed a lot in the ~40 yrs since IP was
designed
• Moore’s law improvements in computing and storage (~5-6 orders-ofmagnitude gain in cost performance since 1970)
• Edge/core disparity, fast fiber but continuing shortage of radio spectrum
23
MobilityFirst
• Clean-slate protocol design that directly addresses the problems of
mobility at scale, while also strengthening the trust model
•
•
•
•
End-point and network mobility at scale
Intrinsic properties of wireless medium
More stringent security/trust requirements
Special needs of emerging mobile applications
• Fixed internet access is treated as a special case of the more
general design
• Although the “sweet spot” of our protocol is wireless/mobile, we
believe that our design provides important benefits to fixed
network applications
•
•
•
•
Security/trust
Robustness
Fault tolerance
Context/content
24
Goals
1.
2.
3.
4.
5.
6.
Host + network mobility
No global root of trust
Intentional data receipt
Byzantine robustness
Content addressability
Evolvable network
25
Additional Design Principles
1.
2.
3.
4.
5.
6.
7.
Visibility and choice
Usability
Manageability
Simplicity
Regulability
Commercializability
Technology-awareness
26
MobilityFirst Architecture
27
Protocol Stack
28
Name-Address Separation
29
Name Resolution
30
Storage Aware Routing
31
Security
1. Public keys global identifiers for hosts & networks; forms basis
for:
•
•
•
•
Ensuring accountability of traffic
Ubiquitous access-control infrastructure
Robust routing protocols
Preventing address hijacking
2. Support deployment of policies that constrain the traffic that
a network or node receives
• In the limit, a “default-disconnected” posture
3. No single globally trusted root for naming or addressing
• Opens naming to innovation to combat naming-related abuses
• Removes obstacles to adoption of secure routing protocols
4. Systematically consider Trusted Computing Base of designs
• Promote TCB reduction technologies (e.g., Byzantine fault
tolerance)
32
NEBULA
• NEBULA is an architecture for the cloud-based future Internet
• More secure and reliable
• Deployable and evolvable
• Truly clean slate
• Availability: At risk of network outages
• Security:
• Poor endpoint authentication
• HIPAA policy restrictions not expressible with existing routing
protocols
• Consistency:
• Communications end--‐point focused, not data focused
• Cloud systems have embraced weak consistency (CAP Theorem)
33
Architecture
34
Network Security
• The “big I” Internet Is federated:
• Policies must be enforced across realms (e.g.,
DDoS)
• NEBULA addresses problems at right
places:
• Extensibility+Policy: new control plane
• Policy Enforcement: new data plane
• Availability: high-performance, redundantpath core with high‐availability core routers
35
NDP
36
NEBULA Virtual and Extensible
Network Techniques (NVENT)
37
NEBULA Core (NCore)
38
XIA Vision
We envision a future Internet that:
• Is trustworthy
• Security broadly defined is the biggest challenge
• Supports long-term evolution of usage models
• Including host-host, content retrieval, services, …
• Supports long term technology evolution
• Not just for link technologies, but also for storage and
computing capabilities in the network and end-points
• Allows all actors to operate effectively
• Despite differences in roles, goals and incentives
39
Today’s Internet
Src: Client IP
Dest: Server IP
TCP
Client IP
Server IP
• Client retrieves document from a specific web server
• But client mostly cares about correctness of content, timeliness
• Specific server, file name, etc. are not of interest
• Transfer is between wrong principals
• What if the server fails?
• Optimizing transfer using local caches is hard
• Need to use application-specific overlay or transparent proxy – bad!
40
eXpressive Internet Architecture
Src: Client ID
Dest: Content ID
PDA
Content
• Client expresses communication intent for content explicitly
• Network uses content identifier to retrieve content from appropriate
location
• How does client know the content is correct?
• Intrinsic security! Verify content using self-certifying id:
hash(content) = content id
• How does source know it is talking to the right client?
• Intrinsic security! Self-certifying host identifiers
41
A Bit More Detail …
Dest: Service ID
Content Name?
Dest: Client ID
Content ID
Dest: Content ID
Flexible Trust
Management
Diverse
Communicating
Entities
Anywhere
Intrinsic
Security
42
Hash( ) = CID?
XIA Transformational Ideas
P1: Evolvable Set of Principals
• Identifying the intended communicating
entities reduces complexity and overhead
• No need to force all communication at a lower
level (hosts), as in today’s Internet
• Allows the network to evolve
Content
a581fe9 ...
Services
d9389fa …
Host
024e881 …
Future
Entities
39c0348 …
43
P2: Security as Intrinsic as Possible
• Security properties are a direct result of the
design of the system
• Do not rely on correctness of external
configurations, actions, data bases
• Malicious actions can be easily identified
Content
a581fe9 ...
Services
d9389fa …
Host
024e881 …
Future
Entities
39c0348 …
44
P3: Narrow Waist for
Trust Management
• Ensure that the inputs to the intrinsically secure
system match the trust assumptions and intensions
of the user
• Certificate authorities, reputation, personal, …
• Narrow waist allows leveraging diverse mechanisms
for trust management
Declaration of
Independence
Trust
Management
043e49af3890dd327134389a90cd2199
45
P4: Narrow Waist for All Principals
• Extends today’s host-based narrow waist to all
principals: hosts, services, content, …
• Defines the API between the principals and
the network protocol mechanisms
XIA adds evolvability
at the waist:
IP: Evolvability of:
Applications
Link technologies
Applications
Evolving
set of principals
Link technologies
46
P5: All other Network Functions are
Explicit Services
• DNS, firewalls, …
• Causes problems in IP
• Covers all functions not part of the narrow
waist
• XIA provides a principal type for services
• Keeps the architecture simple and easy to
reason about
47
XIA: eXpressive Internet
Architecture
• Each communication operation expresses
the intent of the operation
• Also: explicit trust management, APIs among
actors
• XIA is a single inter-network in which all
principals are connected
• Not a collection of architectures implemented
through, e.g., virtualization, overlays
• Not based on a “preferred” principal (host,
content), that has to support all
communication
48
Users
Applications
Services
Host
Support
Content
Support
Services
Support
eXpressive Internet Protocol
Intrinsic
Security
…
Trustworthy Network Operation
Network-Network User-Network
XIA Components and Interactions
49
What Applications
Does XIA Support
• Since XIA supports host-based
communication, today’s applications continue
to work
• Will benefit from the intrinsic security properties
• New applications can express the right
principal
• Can also specify other principals (host based) as
fallbacks
• Content-centric applications
• Explicit reliance on network services
• Mobile users
• As yet unknown usage models
50