Скачать презентацию www psirp org Lecture 2 Evolutionary and Revolutionary Скачать презентацию www psirp org Lecture 2 Evolutionary and Revolutionary

b0de79885e369671536ce7a56c1dce8f.ppt

  • Количество слайдов: 60

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

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

Evolutionary Approaches 1. 2. 3. 4. 5. 6. IPv 6 IPSEC Mobile IP HIP Evolutionary Approaches 1. 2. 3. 4. 5. 6. IPv 6 IPSEC Mobile IP HIP Diff. Serv DHT 25/1/2010 3

IPv 6 Ø IPv 6 was born in 1995 after long work Ø There IPv 6 Ø IPv 6 was born in 1995 after long work Ø There are over 30 IPv 6 -related RFCs Ø The claimed improvements in IPv 6 are: l l l l 25/1/2010 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) 4

IPv 6 Ø Major operating systems and many ISPs support IPv 6 Ø The IPv 6 Ø Major operating systems and many ISPs support IPv 6 Ø The use of IPv 6 is slowly increasing in Europe and North America but more rapidly in Asia Ø In China, CERNET 2 runs IPv 6, interconnecting 25 points of presence in 20 cities with 2. 5 and 10 Gbps links Ø IPv 6 really only solves the exhaustion of Internet address space 25/1/2010 5

IPSEC Ø IPSEC is the IP-layer security solution of the Internet to be used IPSEC Ø IPSEC is the IP-layer security solution of the Internet to be used with IPv 4 and IPv 6 Ø 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 25/1/2010 6

Encapsulating Security Payload (IPv 4) Original IPv 4 Header Security Parameter Index (SPI) Sequence Encapsulating Security Payload (IPv 4) Original IPv 4 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 25/1/2010 ESP Header ESP Trailer 7

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

Mobile IPv 4 Ø Basic l l l concepts: Mobile Node (MN) Correspondent Node Mobile IPv 4 Ø Basic l l l concepts: Mobile Node (MN) Correspondent Node (CN) Home Agent (HA) Foreign Agent (FA) Care-of-Address (Co. A) Ø Problems: l l Firewalls and ingress filtering Triangular routing 25/1/2010 9

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

Ingress Filtering Packet from mobile host is deemed 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 25/1/2010 Source: Professor Sasu Tarkoma 11

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

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

Differences btw MIPv 6 and MIPv 4 Ø Ø Ø In MIPv 6 no Differences btw MIPv 6 and MIPv 4 Ø Ø Ø In MIPv 6 no FA is needed (no infrastructure change) Address auto-configuration helps in acquiring Co. A MH uses Co. A as the source address in foreign link, so no problems with ingress filtering Option headers and neighbor discovery of IPv 6 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 25/1/2010 Source: Professor Sasu Tarkoma 14

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

HIP Ø Host Identity Protocol (HIP, RFC 4423) defines a new global Internet name HIP Ø Host Identity Protocol (HIP, RFC 4423) 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) 25/1/2010 16

HIP Architecture 25/1/2010 17 HIP Architecture 25/1/2010 17

HIP Ø HIs are self-certifying (public keys) Ø HIP is a fairly simple technique 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: l l Security Mobility Multi-homing IPv 4/IPv 6 interoperation Ø HIP is ready for large-scale deployment Ø See http: //infrahip. hiit. fi for more info 25/1/2010 18

Base exchange • Based on the SIGMA family of key exchange protocols Select precomputed Base exchange • Based on the SIGMA family of key exchange protocols Select precomputed R 1. Prevent Do. S. Minimal state kept at responder! Does not protect against replay Diffiestandard authenticated attacks. Source: Dr. Pekka Nikander Initiator Responder Hellman key exchange for session key generation I 1 R 1 solve puzzle HIT , HIT or NULL HIT , [HIT , puzzle, DH , HI ] I 2 [HIT , solution, DH , {HI }] R 2 I R I R R R sig I [HIT , authenticator] I R I sig verify, authenticate, replay protection User data messages ESP protected TCP/UDP, no explicit HIP header 25/1/2010 19

HIP Mobility Ø Mobility 25/1/2010 is easy – retaining the SA for ESP 20 HIP Mobility Ø Mobility 25/1/2010 is easy – retaining the SA for ESP 20

HIP in Combining IPv 4 and IPv 6 Ø An early demo seen at HIP in Combining IPv 4 and IPv 6 Ø An early demo seen at L. M. Ericsson Finland (source: Petri Jokela, LMF) IPv 4 access network WWW Proxy HIP CN Internet HIP MN Music Server 25/1/2010 21

Diff. Serv Ø Ø Ø Differentiated Services (Diff. Serv, RFC 2474) redefines the To. Diff. Serv Ø Ø Ø Differentiated Services (Diff. Serv, RFC 2474) redefines the To. S octet of the IPv 4 packet or Traffic Class octet of IPv 6 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 Diff. Serv is stateless (like IP) and scales Service Profiles can be defined by ISP for customers and by transit providers for ISPs Diff. Serv is very easily deployable and could enable well working Vo. IP and real-time video Unfortunately, it is not used between operators 25/1/2010 22

Distributed Hash Table (DHT) Ø Ø Ø Ø Distributed Hash Table (DHT) is a 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 Bit. Torrent 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) 25/1/2010 23

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

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

Some More Revolutionary Approaches 1. ROFL M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, 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 25/1/2010 26

ROFL Ø ROFL routes directly on host identities, leaving aside the locations of the 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: l l 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 25/1/2010 27

ROFL Ø Three classes of hosts: l l l Ø Ø Ø Routers Stable ROFL Ø Three classes of hosts: l l l Ø Ø Ø 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 25/1/2010 28

DONA Ø DONA replaces the hierarchical DNS namespace with a cryptographic, selfcertifying namespace for DONA Ø DONA replaces the hierarchical DNS namespace with a cryptographic, selfcertifying 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 25/1/2010 29

DONA Ø Strict separation between naming (persistence and authenticity) and name resolution (availability) Ø 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) 25/1/2010 30

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

Networking Named Content Ø Based on and pictures borrowed from: Jacobson, V. ; Smetters, 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 5 th ACM International Conference on Emerging Networking Experiments and Technologies (Co. NEXT 2009); 2009 December 1 -4; Rome, Italy. NY: ACM; 2009; 1 -12. 25/1/2010 32

Host-Centric Networking Ø In 1960’s and 1970’s – resource sharing Ø Computers, disk drives, 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 25/1/2010 33

Content-Centric Networking (CCN) Ø In 2009 alone 500 exabytes (5 x 1020 B) of Content-Centric Networking (CCN) Ø In 2009 alone 500 exabytes (5 x 1020 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 25/1/2010 34

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

Interest and Data packets Ø There l l are two types of CCN packets: Interest and Data packets Ø There l l are two types of CCN packets: Interest packets Data packets 25/1/2010 36

CCN Node Model Ø There l l are two types of CCN packets: Interest CCN Node Model Ø There l l 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 Content. Name in the Interest is a prefix of that in the Data 25/1/2010 37

CCN Node Model Ø Hierarchical name space (cmp w/ URI) Ø When a packet 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: l l l Forwarding Information Base (FIB) Content Store (buffer memory) Pending Interest Table (PIT) 25/1/2010 38

CCN Node Model Ø FIB allows a list of outgoing interfaces – multiple sources 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 upstream => 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 25/1/2010 39

CCN Forwarding Engine 25/1/2010 40 CCN Forwarding Engine 25/1/2010 40

CCN Node Model When an Interest packet arrives, longest-match lookup is done on its CCN Node Model When an Interest packet arrives, longest-match lookup is done on its Content. Name Ø Content. Store match is preferred over a PIT match, preferred over a FIB match Ø l l Matching Data packet in Content. Store => 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 25/1/2010 41

CCN Transport Ø CCN transport is designed to operate on unreliable packet delivery services 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 25/1/2010 42

Reliability and Flow Control Ø Flow balance allows for efficient communication between machines with 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 25/1/2010 43

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

Naming and Sequencing Ø An Interest can specify the content exactly Ø Content names 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 25/1/2010 45

Intra-Domain Routing Ø Like IPv 4 and IPv 6 addresses, CCN Content. Names are Intra-Domain Routing Ø Like IPv 4 and IPv 6 addresses, CCN Content. Names are aggregateable and routed based on longest match Ø However, Content. Names 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 25/1/2010 46

Intra-Domain Routing Ø An 25/1/2010 example of intra-domain routing 47 Intra-Domain Routing Ø An 25/1/2010 example of intra-domain routing 47

Inter-Domain Routing Ø The current BGP version has the equivalent of the IGP TLV 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 CCNcapable domain on the paths towards those domains Ø Therefore, it is possible to deploy CCN in the existing BGP infrastructure 25/1/2010 48

Content-Based Security Ø In CCN, the content itself (rather than its path) is protected 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) 25/1/2010 49

Trust Establishment Ø Associating 25/1/2010 name spaces with public keys 50 Trust Establishment Ø Associating 25/1/2010 name spaces with public keys 50

Evaluation Ø The CCN architecture described has been implemented and evaluated Ø Voice over 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 25/1/2010 51

Voice over CCN Ø Ø Ø Secure Voice over CCN was implemented using Linphone 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 25/1/2010 52

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

Content Distribution 25/1/2010 54 Content Distribution 25/1/2010 54

Throughput 25/1/2010 55 Throughput 25/1/2010 55

Comparing CCN and HTTP 25/1/2010 56 Comparing CCN and HTTP 25/1/2010 56

Comparing CCN and HTTPS 25/1/2010 57 Comparing CCN and HTTPS 25/1/2010 57

Merits of CCN Ø Very understandable scheme Ø Shown to work also with streamed 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 25/1/2010 58

Concerns about CCN The simple hierarchical (URI-like) naming scheme is also a limitation Ø Concerns about CCN The simple hierarchical (URI-like) naming scheme is also a limitation Ø Will CCN scale to billions of nodes? Ø l l 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 Ø 25/1/2010 59

Thank you for your attention! Questions? Comments? Thank you for your attention! Questions? Comments?