470 likes | 698 Views
T-110.6120 – Special Course on Data Communications Software: Publish/Subscribe Internetworking. Evolution vs. Revolution. Arto Karila Aalto-HIIT arto.karila@hiit.fi. Evolution vs. revolution. The Internet has evolved from the 1970’s and with no big changes since 1993
E N D
T-110.6120 – Special Course on Data Communications Software: Publish/Subscribe Internetworking Evolution vs. Revolution Arto Karila Aalto-HIIT arto.karila@hiit.fi T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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) T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
Original IPv4 Header Security Parameter Index (SPI) ESP Header Sequence Number Coverage of Authentication UDP/TCP Header ESP Payload Coverage ofConfidentiality Data Padding Pad Len Next Hdr ESP Trailer Authentication Data Encapsulating Security Payload (IPv4) T-110.6120: Publish/Subscribe Internetworking
Original IPv6 Header Hop-by-Hop Extensions Security Parameter Index (SPI) ESP Header Sequence Number Coverage of Authentication End-to-End Extensions UDP/TCP Header ESP Payload Coverage ofConfidentiality Data Padding ESP Trailer Authentication Data Encapsulating Security Payload (IPv6) T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
DELAY! Mobile IP Triangular Routing Ingress filtering causes problems for IPv4 (home address as source), IPv6 uses CoA so not a problem . Solutions: (reverse tunnelling) or route optimization Correspondent Host Foreign agent left out of MIPv6. No special support needed with IPv6 autoconfiguration Foreign Agent Home Agent Care-of-Address (CoA) Mobile Host Source: Professor Sasu Tarkoma T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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) T-110.6120: Publish/Subscribe Internetworking
HIP Architecture Source: http://infrahip.hiit.fi T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
I1 HITI, HITR or NULL R1 HITI, [HITR, puzzle, DHR, HIR]sig I2 [HITI, HITR, solution, DHI,{HII}]sig R2 [HITI, HITR, authenticator]sig ESP protected TCP/UDP, no explicit HIP header 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 not protect against replay attacks. Initiator Responder standard authenticated Diffie-Hellman key exchange for session key generation solve puzzle verify, authenticate, replay protection User data messages T-110.6120: Publish/Subscribe Internetworking
HIP Mobility • Mobility is easy – retaining the SA for ESP T-110.6120: Publish/Subscribe Internetworking
IPv4 access Internet network WWW Proxy HIP CN HIP MN Music Server HIP in Combining IPv4 and IPv6 • An early demo seen at L.M. Ericsson Finland (source: Petri Jokela, LMF) T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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) T-110.6120: Publish/Subscribe Internetworking
DHT The principle of Distributed Hash Table (source: Wikipedia) T-110.6120: Publish/Subscribe Internetworking
Some More Revolutionary Approaches • ROFLM. 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 • DONAT. 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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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) T-110.6120: Publish/Subscribe Internetworking
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! T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
TCP/IP and CCN Protocol Stacks Source: Van Jacobson, PARC, 2009 T-110.6120: Publish/Subscribe Internetworking
Interest and Data packets • There are two types of CCN packets: • Interest packets • Data packets Source: Van Jacobson, PARC, 2009 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
CCN Node Model • Hierarchical name space (cmp w/ URI) • When a packet arrives on a face a longest-match lookup is made • Forwarding engine with 3 data structures: • Forwarding Information Base (FIB) • Content Store (buffer memory) • Pending Interest Table (PIT) T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
CCN Forwarding Engine Source: Van Jacobson, PARC, 2009 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
Intra-Domain Routing An example of intra-domain routing Source: Van Jacobson, PARC, 2009 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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) T-110.6120: Publish/Subscribe Internetworking
Trust Establishment Associating name spaces with public keys Source: Van Jacobson, PARC, 2009 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking
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 T-110.6120: Publish/Subscribe Internetworking