Transcript Evolution vs Revolution

T-110.6120 – Special Course on Data
Communications Software:
Publish/Subscribe Internetworking
Evolution vs. Revolution
Arto Karila
Aalto-HIIT
[email protected]
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
1
Evolution vs. revolution
• The Internet has evolved from the 1970’s and with no
big changes since 1993
• This has led into a stagnated situation where it is very
hard to make changes to the core protocols
• It the Internet was redesigned from scratch, it would
probably be very different from what the current
Internet has evolved to
• Various clean-slate solutions are current research
topics and some of them may lead into a new Internet
• It is possible that all the protocol layers, including the
Internet Protocol, will change
• However, any new solution will have to operate as
overlay on the existing IP infrastructure to succeed
• The publish/subscribe paradigm (pub/sub) is one of
the most promising new paradigms
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
2
Some evolutionary approaches
A brief look at some evolutionary solutions
proposed to the Internet’s shortcomings:
• IPv6
• IPSEC
• Mobile IP (v4 and v6)
• HIP
• DiffServ
• DHT
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
3
IPv6
• IPv6 was born in 1995 after long work
• There are over 30 IPv6-related RFCs
• The claimed improvements in IPv6 are:
– Large 128-bit address space
– Stateless address auto-configuration
– Multicast support
– Mandatory network layer security (IPSEC)
– Simplified header processing by routers
– Efficient mobility (no triangular routing)
– Extensibility (extension headers)
– Jumbo packets (up to 4 GB)
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
4
IPv6
• Major operating systems and many ISPs
support IPv6
• The use of IPv6 is slowly increasing in Europe
and North America but more rapidly in Asia
• In China, CERNET 2 runs IPv6, interconnecting
25 points of presence in 20 cities with 2.5 and
10 Gbps links, with each PoP providing
1 to 10 Gbps speeds to an access network
(http://www.cernet2.edu.cn)
• IPv6 really only solves the exhaustion of
Internet address space
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
5
IPSEC
• IPSEC is the IP-layer security solution of the
Internet to be used with IPv4 and IPv6
• Authentication Header (AH) only protects the
integrity of an IP packet
• Encapsulating Security Payload (ESP) also
ensures confidentiality of the data
• IPSEC works within a Security Association (SA)
set up between two IP addresses
• ISAKMP (Internet Security Association and Key
Management Protocol) is a very complicated
framework for SA mgmt
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
6
Encapsulating Security Payload (IPv4)
Original IPv4 Header
Security Parameter Index (SPI)
Sequence Number
Coverage of
Authentication
UDP/TCP Header
Coverage of
Confidentiality
ESP
Payload
Data
Padding
Pad Len
Next Hdr
Authentication Data
2011-09-13 AK
ESP
Header
T-110.6120: Publish/Subscribe Internetworking
ESP
Trailer
7
Encapsulating Security Payload (IPv6)
Original IPv6 Header
Hop-by-Hop Extensions
Security Parameter Index (SPI)
Sequence Number
Coverage of
Authentication
End-to-End Extensions
UDP/TCP Header
Coverage of
Confidentiality
ESP
Payload
Data
Padding
Authentication Data
2011-09-13 AK
ESP
Header
T-110.6120: Publish/Subscribe Internetworking
ESP
Trailer
8
Mobile IPv4
• Basic concepts:
– Mobile Node (MN)
– Correspondent Node (CN)
– Home Agent (HA)
– Foreign Agent (FA)
– Care-of-Address (CoA)
• Problems:
– Firewalls and ingress filtering
– Triangular routing
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
9
Mobile IP Triangular Routing
Ingress filtering causes problems for IPv4
(home address as source), IPv6 uses CoA
so not a problem . Solutions:
Correspondent
(reverse tunnelling) or
Host
route optimization
Foreign agent left
out of MIPv6. No special
support needed with
IPv6 autoconfiguration
DELAY!
Foreign Agent
Home Agent
Care-of-Address (CoA)
Mobile Host
2011-09-13 AK
Source: Professor Sasu Tarkoma
T-110.6120: Publish/Subscribe Internetworking
10
Ingress Filtering
Packet from mobile host is deemed "topologically
incorrect“ (as in source address spoofing)
Correspondent Host
Home Agent
With ingress filtering, routers drop source addresses that are
not consistent with the observed source of the packet
Source: Professor Sasu Tarkoma
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
11
HIP
• Host Identity Protocol (HIP, RFC4423 & others)
defines a new global Internet name space
• The Host Identity name space decouples the
name and locator roles, both of which are
currently served by IP addresses
• The transport layer now operates on Host
Identities instead of IP addresses
• The network layer uses IP addresses as pure
locators (not as names or identifiers)
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
12
HIP Architecture
Source:
http://infrahip.hiit.fi
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
13
HIP
• HIs are self-certifying (public keys)
• HIP is a fairly simple technique based on IPSEC
ESP and HITs (128-bit HI hashes)
• It addresses several major issues:
– Security
– Mobility
– Multi-homing
– IPv4/IPv6 interoperation
• HIP is ready for large-scale deployment
• See http://infrahip.hiit.fi for more info
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
14
Base exchange
• Based on the SIGMA family of key exchange protocols
Source: Dr. Pekka Nikander
Select precomputed R1. Prevent DoS.
Minimal state kept at responder!
Does notstandard
protect against
replay Diffieattacks.
authenticated
Initiator
solve
puzzle
Responder
Hellman key exchange for
session key generation
I1
HIT , HIT or NULL
R1
HIT , [HIT , puzzle, DH , HI ]
I2
[HIT , HIT , solution, DH ,{HI }]
R2
I
R
I
R
I
R
R
R sig
I
I sig
[HIT , HIT , authenticator]
I
R
sig
verify,
authenticate,
replay protection
User data messages
ESP protected TCP/UDP, no explicit HIP header
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
15
HIP Mobility
• Mobility is easy – retaining the SA for ESP
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
16
HIP in Combining IPv4 and IPv6
• An early demo seen at L.M. Ericsson Finland
(source: Petri Jokela, LMF)
IPv4
access
network
WWW Proxy
HIP CN
Internet
HIP MN
IPv6
access
network
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
Music Server
17
DiffServ
• Differentiated Services (DiffServ, RFC 2474)
redefines the ToS octet of the IPv4 packet or
Traffic Class octet of IPv6 as DS
• The first 6 bits of the DS field are used as
Differentiated Services Code Point (DSCP)
defining the Per-Hop Behavior of the packet
• DiffServ is stateless (like IP) and scales
• Service Profiles can be defined by ISP for
customers and by transit providers for ISPs
• DiffServ is very easily deployable and could
enable well working VoIP and real-time video
• Unfortunately, it is not used between operators
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
18
Distributed Hash Table (DHT)
• Distributed Hash Table (DHT) is a service for
storing and retrieving key-value pairs
• There is a large number of peer machines
• Single machines leaving or joining the network
have little effect on its operation
• DHTs can be used to build e.g. databases (new
DNS), or content delivery systems
• BitTorrent is using a DHT
• The real scalability of DHT is still unproven
• All of the participating hosts need to be trusted
(at least to some extent)
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
19
DHT
The principle of Distributed Hash Table
(source: Wikipedia)
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
20
Some More Revolutionary Approaches
1.
ROFL
M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan,
I. Stoica, and S. Shenker,
ROFL: Routing on Flat Labels,
In ACM SIGCOMM, Sep. 2006, pp. 363–374
2.
DONA
T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy,
K. H. Kim, S. Shenker, and I. Stoica,
A Data-Oriented (and Beyond) Network Architecture, In SIGCOMM ’07:
Proceedings of the 2007 conference on Applications, technologies,
architectures, and protocols for computer communications,
New York, NY, USA, 2007, pp. 181-192
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
21
ROFL
• ROFL routes directly on host identities,
leaving aside the locations of the hosts
• Self-certifying identifiers (tied to public keys)
• Create a network layer with no locations
• Advantages:
– No new infrastructure (no name resolution)
– Packet delivery only depends on the data
path
– Simpler allocation of identifiers
(just need to ensure uniqueness)
– Access control based on identifiers
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
22
ROFL
• Three classes of hosts:
– Routers
– Stable hosts
– Ephemeral hosts
• Each ID is resident to its Hosting Router (the
host’s first-hop router)
• The hosts form a two-way ring – each with
pointers to its successor and predecessor
• There can be shorter routes cached
• OSPF-like routing protocol (w/ network map) is
assumed for recovering from routing failures
• Global ROFL-ring for inter-domain routing
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
23
DONA
• DONA replaces the hierarchical DNS
namespace with a cryptographic, self-certifying
namespace for naming data
• This enables entirely distributed namespace
control
• The namespace is not totally flat but consists of
two parts: the principal’s identifier and a label
• This two-tier hierarchy helps make DONA
scalable
• Clean-slate naming and name resolution
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
24
DONA
• Strict separation between
naming (persistence and authenticity) and
name resolution (availability)
• Each principal has a public-key pair
• Each datum (or any other named entity) is
associated with a principal
• Names of the form P:L (Principal:Label), where
P is a cryptographic hash of the principal’s
public key and L is a locally unique label
• Name resolution by Resolution Handlers,
primitives: FIND(P:L), REGISTER(P:L)
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
25
Networking Named Content
• Based on: Van Jacobson, V.; Smetters, D. K.;
Thornton, J. D.; Plass, M. F.; Briggs, N.; Braynard, R.
Networking named content. Proceedings of the 5th
ACM International Conference on Emerging
Networking Experiments and Technologies (CoNEXT
2009); 2009 December 1-4; Rome, Italy. NY: ACM; 2009;
1-12.
http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.pdf
Warm thanks to Van for providing the figures and
allowing me to use them!
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
26
Content-Centric Networking (CCN)
• CCN – a communication architecture
built on named data
• “Address” named content – not location
• Preserve the design decisions that make
TCP/IP simple, robust and scalable
• From IP to chunks of named content
• Only layer 3 requires universal agreement
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
27
TCP/IP and CCN Protocol Stacks
Source: Van Jacobson, PARC, 2009
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
28
Interest and Data packets
• There are two types of CCN packets:
– Interest packets
– Data packets
Source: Van Jacobson, PARC, 2009
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
29
CCN Node Model
• There are two types of CCN packets:
– Interest packets
– Data packets
• Consumer broadcasts its Interest over all
available connectivity
• Data is transmitted only in response to and
Interest and consumes that Interest
• Data satisfies an Interest if ContentName in the
Interest is a prefix of that in the Data
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
30
CCN Node Model
• Hierarchical name space (cmp w/ URI)
• When a packet arrives on a face a longestmatch lookup is made
• Forwarding engine with 3 data structures:
– Forwarding Information Base (FIB)
– Content Store (buffer memory)
– Pending Interest Table (PIT)
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
31
CCN Node Model
• FIB allows a list of outgoing interfaces –
multiple sources of data
• Content Store w/ LRU or LFU replacement
• PIT keeps track of Interest forwarded up-stream
=> Data can be sent downstream
• Interest packets are routed upstream – Data
packets follow the same path down
• Each PIT entry is a “bread crumb” marking the
path and is erased after it’s been used
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
32
CCN Forwarding Engine
Source: Van Jacobson, PARC, 2009
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
33
CCN Node Model
• When an Interest packet arrives, longest-match
lookup is done on its ContentName
• ContentStore match is preferred over a PIT
match, preferred over a FIB match
– Matching Data packet in ContentStore =>
send it out on the Interest arrival face
– Else, if there is an exact-match PIT entry =>
add the arrival face to the PIT entry’s list
– Else, if there is a matching FIB entry =>
send the Interest up-stream towards the data
– Else => discard the Interest packet
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
34
CCN Transport
• CCN transport is designed to operate on
unreliable packet delivery services
• Senders are stateless
• Receivers keep track of unsatisfied Interests
and ask again after a time-out
• The receiver’s strategy layer is responsible
for retransmission, selecting faces, limiting
the number of unsatisfied Interests, priority
• One Interest retrieves at most one Data
packet => flow balance
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
35
Reliability and Flow Control
• Flow balance allows for efficient
communication between machines with
highly different speeds
• It is possible to overlap data and requests
• In CCN, all communication is local and flow
balance is maintained over each hop
• This leads into end-to-end flow control
without any end-to-end mechanisms
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
36
Naming
• CCN is based on hierarchical, aggregatable names at
least partly meaningful to humans
• The name notation used is like URI
Source: Van Jacobson, PARC, 2009
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
37
Naming and Sequencing
• An Interest can specify the content exactly
• Content names can contain automatically
generated endings used like sequence #s
• The last part of the name is incremented for the
next chunk (e.g. a video frame)
• The names form a tree which is traversed in
preorder
• In this way, the receiver can ask for the
next Data packet in his Interest packet
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
38
Intra-Domain Routing
• Like IPv4 and IPv6 addresses, CCN
ContentNames are aggregateable and routed
based on longest match
• However, ContentNames are of varying length
and longer than IP addresses
• The TLV (Type Label Value) of OSPF or
IS-IS can distribute CCN content prefixes
• Therefore, CCN Interest/Data forwarding can
be built on existing infrastructure without any
modification to the routers
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
39
Intra-Domain Routing
An example of intra-domain routing
Source: Van Jacobson, PARC, 2009
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
40
Inter-Domain Routing
• The current BGP version has the equivalent of
the IGP TLV mechanism
• Through this mechanism, it is possible to
learn which domains serve Interests in some
prefix and what is the closest CCN-capable
domain on the paths towards those domains
• Therefore, it is possible to deploy CCN in the
existing BGP infrastructure
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
41
Content-Based Security
• In CCN, the content itself (rather than its path)
is protected
• One can retrieve the content from the closest
source and validate it
• All content is digitally signed
• Signed info includes hash of the public key
used for signing
• We still need some kind of a Public Key
Infrastructure (PKI)
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
42
Trust Establishment
Associating name spaces with public keys
Source: Van Jacobson, PARC, 2009
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
43
Evaluation
• The CCN architecture described has been
implemented and evaluated
• Voice over CCN and Content Distribution were
tested with small networks
• The results are interesting but not alone
convincing regarding the scalability of the
design
• There still are some fundamental questions that
remain unanswered
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
44
Voice over CCN
• Secure Voice over CCN was implemented using
Linphone 3.0 and its performance evaluated
• Caller encodes SIP INVITE as CCN name and
sends it as an interest
• On receipt of the INVITE, the callee generates a
signed Data packet with the INVITE name as its
name and the SIP response as its payload
• From the SIP messages, the parties derive
paired name prefixes under which they write
RTP packets
• There is a separate paper on Voice over CCN
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
45
Merits of CCN
• Very simple and understandable scheme
• Shown to work also with streamed media
• Clever reuse of existing mechanisms
• Easy to implement based on current routing
software
• Easy to deploy on existing routing protocols
and IP networks
• Easy, human-readable naming scheme
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
46
Concerns about CCN
• The simple hierarchical (URI-like) naming
scheme is built deep into the design
• Will it scale to hundreds of billions of nodes?
– Flooding
(send out through all available faces)
– Flow balance – an Interest for every Data
– How large can the FIB grow (soft state)?
– Data takes the same (possibly non-optimal)
path as Interest – assuming two-way links
• Are the performance measurements made with
only a couple of hosts convincing?
• Security architecture looks quite conventional
2011-09-13 AK
T-110.6120: Publish/Subscribe Internetworking
47