Presentation is loading. Please wait.

Presentation is loading. Please wait.

25/1/20101 Lecture 2: Evolutionary and Revolutionary Approaches D.Sc. Arto Karila Helsinki Institute for Information Technology (HIIT)

Similar presentations


Presentation on theme: "25/1/20101 Lecture 2: Evolutionary and Revolutionary Approaches D.Sc. Arto Karila Helsinki Institute for Information Technology (HIIT)"— Presentation transcript:

1 25/1/20101 Lecture 2: Evolutionary and Revolutionary Approaches D.Sc. Arto Karila Helsinki Institute for Information Technology (HIIT) arto.karila@hiit.fi T-110.6120 – Special Course on Data Communications Software: Publish/Subscribe Internetworking www.psirp.org

2 25/1/20102 Contents 1. 1. Evolutionary approaches 2. 2. Some more revolutionary approaches 3. 3. Networking Named Content – Van Jacobson’s CCN project (Content-Centric Networking)

3 25/1/20103 Evolutionary Approaches 1. 1. IPv6 2. 2. IPSEC 3. 3. Mobile IP 4. 4. HIP 5. 5. DiffServ 6. 6. DHT

4 25/1/20104 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)

5 25/1/20105 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  IPv6 really only solves the exhaustion of Internet address space

6 25/1/20106 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

7 25/1/20107 Encapsulating Security Payload (IPv4) Original IPv4 Header Security Parameter Index (SPI) Sequence Number Coverage of Authentication UDP/TCP Header Data Padding Pad Len Next Hdr Authentication Data Coverage of Confidentiality ESP Header ESP Payload ESP Trailer

8 25/1/20108 Encapsulating Security Payload (IPv6) ESP Payload Hop-by-Hop Extensions Security Parameter Index (SPI) Sequence Number Coverage of Authentication End-to-End Extensions Data Padding Authentication Data Coverage of Confidentiality ESP Header ESP Trailer Original IPv6 Header UDP/TCP Header

9 25/1/20109 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

10 25/1/201010 Mobility Example:Mobile IP Triangular Routing Home Agent Correspondent Host Foreign Agent Mobile Host Ingress filtering causes problems for IPv4 (home address as source), IPv6 uses CoA so not a problem. Solutions: (reverse tunnelling) or route optimization Foreign agent left out of MIPv6. No special support needed with IPv6 autoconfiguration DELAY! Care-of-Address (CoA) Source: Professor Sasu Tarkoma

11 25/1/201011 Ingress Filtering Home Agent Correspondent Host Packet from mobile host is deemed "topologically incorrect“ (as in source address spoofing) With ingress filtering, routers drop source addresses that are not consistent with the observed source of the packet Source: Professor Sasu Tarkoma

12 25/1/201012 Reverse Tunnelling Home Agent Correspondent Host Router Mobile Host DELAY! Firewalls and ingress filtering no longer a problem Two-way tunneling leads to overhead and increased congestion Firewalls and ingress filtering no longer a problem Two-way tunneling leads to overhead and increased congestion Source: Professor Sasu Tarkoma Care-of-Address (CoA)

13 25/1/201013 Mobile IPv6 Route Optimization Home Agent Correspondent Host Router Mobile Host MH sends a binding update to CH when it receives a tunnelled packet. CH sends packets using routing header First, a Return Routability test to CH. CH sends home test and CoA test packets. When MH receives both, It sends the BU with the Kbm key. Secure tunnel (ESP) Source: Professor Sasu Tarkoma

14 25/1/201014 Differences btw MIPv6 and MIPv4   In MIPv6 no FA is needed (no infrastructure change)   Address auto-configuration helps in acquiring CoA   MH uses CoA as the source address in foreign link, so no problems with ingress filtering   Option headers and neighbor discovery of IPv6 protocol are used to perform mobility functions   128-bit IP addresses help deployment of mobile IP in large environments   Route optimization is supported by header options Source: Professor Sasu Tarkoma

15 25/1/201015 Extension Headers Mobility Header Upper Layer headers Data MH CN to MNMN to CN MN, HA, and CN for Binding MH Type in Mobility Header: Binding Update, Binding Ack, Binding Err, Binding refresh Source: Chittaranjan Hota, Computer Networks II lecture 22.10.2007

16 25/1/201016 HIP  Host Identity Protocol (HIP, RFC4423) 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)

17 25/1/201017 HIP Architecture

18 25/1/201018 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 infohttp://infrahip.hiit.fi

19 25/1/201019 Base exchange InitiatorResponder I1HIT I, HIT R or NULL R1HIT I, [HIT R, puzzle, DH R, HI R ] sig I2[HIT I, HIT R, solution, DH I,{HI I }] sig R2[HIT I, HIT R, authenticator] sig ESP protected TCP/UDP, no explicit HIP header User data messages solve puzzle verify, authenticate, replay protection draft-ietf-hip-base-02.txt, draft-jokela-hip-esp-00.txt Based on the SIGMA family of key exchange protocols standard authenticated Diffie- Hellman key exchange for session key generation Select precomputed R1. Prevent DoS. Minimal state kept at responder! Does not protect against replay attacks. Source: Dr. Pekka Nikander

20 25/1/201020 HIP Mobility  Mobility is easy – retaining the SA for ESP

21 25/1/201021 HIP in Combining IPv4 and IPv6 IPv4 access network Internet HIP MN Music Server WWW Proxy HIP CN  An early demo seen at L.M. Ericsson Finland (source: Petri Jokela, LMF)

22 25/1/201022 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

23 25/1/201023 DHT) 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)

24 25/1/201024 DHT  The principle of Distribute Hash Table (source: Wikipedia)

25 25/1/201025 Contents 1. 1. Evolutionary approaches 2. 2. Some more revolutionary approaches 3. 3. Networking Named Content – Van Jacobson’s CCN project (Content-Centric Networking)

26 25/1/201026 Some More Revolutionary Approaches 1. 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. 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

27 25/1/201027 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

28 25/1/201028 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   An OSPF-like routing protocol (with network map) is assumed for recovering from routing failures   Global ROFL-ring for inter-domain routing

29 25/1/201029 DONA   DONA replaces the hierarchical DNS namespace with a cryptographic, self- certifying namespace for naming data   This enables totally 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

30 25/1/201030 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 has os the principal’s public key and L is a locally unique label   Name resolution by Resolution Handlers, primitives: FIND(P:L), REGISTER(P:L)

31 25/1/201031 Contents 1. 1. Evolutionary approaches 2. 2. Some more revolutionary approaches 3. 3. Networking Named Content – Van Jacobson’s CCN project (Content-Centric Networking)

32 25/1/201032 Networking Named Content   Based on and pictures borrowed from: 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.

33 25/1/201033 Host-Centric Networking   In 1960’s and 1970’s – resource sharing   Computers, disk drives, tape drives, printers etc. needed to be shared   This lead into a communication model with two machines – one using and one providing resources over the network   IP packets with source and destination   Most of the traffic is TCP connections

34 25/1/201034 Content-Centric Networking (CCN)   In 2009 alone 500 exabytes (5 x 10 20 B) of content created (source: RFC 5401)   Users are interested in what content – not where it is   CCN – a communication architecture built on named data   “Address” names content – not location   Preserve the design decisions that make TCP/IP simple, robust and scalable

35 25/1/201035 TCP/IP and CCN Protocol Stacks   From IP to chunks of named content   Only layer 3 requires universal agreement

36 25/1/201036 Interest and Data packets   There are two types of CCN packets: Interest packets Data packets

37 25/1/201037 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

38 25/1/201038 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)

39 25/1/201039 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

40 25/1/201040 CCN Forwarding Engine

41 25/1/201041 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

42 25/1/201042 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

43 25/1/201043 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

44 25/1/201044 Naming   CCN is based on hierarchical, aggregatable names at least partly meaningful to humans   The name notation used is like URI

45 25/1/201045 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

46 25/1/201046 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

47 25/1/201047 Intra-Domain Routing   An example of intra-domain routing

48 25/1/201048 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

49 25/1/201049 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)

50 25/1/201050 Trust Establishment   Associating name spaces with public keys

51 25/1/201051 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 don’t really tell us anything about the scalability of the design

52 25/1/201052 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

53 25/1/201053 Voice over CCN – Automatic Failover

54 25/1/201054 Content Distribution

55 25/1/201055 Throughput

56 25/1/201056 Comparing CCN and HTTP

57 25/1/201057 Comparing CCN and HTTPS

58 25/1/201058 Merits of CCN   Very 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

59 25/1/201059 Concerns about CCN   The simple hierarchical (URI-like) naming scheme is also a limitation   Will CCN scale to 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   Are the performance measurements made with only a couple of hosts convincing?   Security architecture looks very conventional

60 25/1/201060 Thank you for your attention! Questions? Comments?


Download ppt "25/1/20101 Lecture 2: Evolutionary and Revolutionary Approaches D.Sc. Arto Karila Helsinki Institute for Information Technology (HIIT)"

Similar presentations


Ads by Google