idnits 2.17.1 draft-muscariello-intarea-hicn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 308: '... SHOULD be globally routable. The d...' RFC 2119 keyword, line 317: '...ts. The segment MUST be indexed in th...' RFC 2119 keyword, line 461: '... MUST index packets by full name, i....' RFC 2119 keyword, line 508: '... the next-hop MAY be selected by us...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 431 has weird spacing: '...mediate node ...' -- The document date (June 07, 2018) is 2147 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 709 == Missing Reference: 'N' is mentioned on line 608, but not defined == Missing Reference: 'NumberOfEntries' is mentioned on line 716, but not defined == Unused Reference: 'RFC0793' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC1081' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'RFC1624' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-mapme' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-terminology' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'WLD' is defined on line 860, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1081 (Obsoleted by RFC 1225) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-07 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-07 == Outdated reference: A later version (-05) exists of draft-irtf-icnrg-mapme-00 == Outdated reference: A later version (-08) exists of draft-irtf-icnrg-terminology-00 Summary: 5 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area WG L. Muscariello 3 Internet-Draft G. Carofiglio 4 Intended status: Informational J. Auge 5 Expires: December 9, 2018 M. Papalini 6 Cisco Systems Inc. 7 June 07, 2018 9 Hybrid Information-Centric Networking 10 draft-muscariello-intarea-hicn-00 12 Abstract 14 This documents describes the hybrid information-centric networking 15 (hICN) architecture for IPv6. The specifications describe a way to 16 implement information-networking functionalities into IPv6. The 17 objective is to use IPv6 without creating overlays with a new packet 18 format as an additional encapsulation. The intent of the present 19 design is to introduce some IPv6 routers in the network with 20 additional packet processing operations to implement ICN functions. 21 Moreover, the current design is tightly integrated into IPv6 to allow 22 easy interconnection to IPv6 networks with the additional design 23 objective to exploit existing IPv6 protocols as much as possible as 24 they are, or extend them where needed. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 9, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. End-points . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.2.1. Name prefix . . . . . . . . . . . . . . . . . . . . . 7 65 2.2.2. Name Suffix . . . . . . . . . . . . . . . . . . . . . 8 66 2.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8 67 2.3.1. Interest Packet . . . . . . . . . . . . . . . . . . . 8 68 2.3.2. Data Packet . . . . . . . . . . . . . . . . . . . . . 9 69 2.4. Packet cache . . . . . . . . . . . . . . . . . . . . . . 12 70 2.5. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 12 71 2.5.1. Interest Path . . . . . . . . . . . . . . . . . . . . 12 72 2.5.2. Data Path . . . . . . . . . . . . . . . . . . . . . . 14 73 3. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 18 78 6.2. Informative References . . . . . . . . . . . . . . . . . 19 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 81 1. Introduction 83 The objective of this document is to describe hybrid ICN, a network 84 protocol that integrates ICN in IPv6, at a minimum cost in terms of 85 required modifications in end-points and routers and in a way to 86 guarantee transparent interconnection with IP without using overlays. 88 The ICN reference design used in this document is CCNx as described 89 in [I-D.irtf-icnrg-ccnxsemantics] and [I-D.irtf-icnrg-ccnxmessages]. 90 IPv6 is used as described in [RFC8200]. 92 There are some basic design principles behind the hICN architecture 93 that are implemented by the design reported below that can be 94 summarized as follows: 96 o (i) the network can transport many different kinds of applications 97 as IPv6, i.e. hICN can serve content-distribution or real-time 98 applications, to cite examples with very different requirements. 99 hICN is not a content-distribution network; 101 o (ii) it provides connection-less and location independent 102 communications by identifying data with unique global names, 103 instead of naming network interfaces (locator) or end-hosts (end- 104 host identifiers) as in LISP [RFC6830]. 106 o (iii) data is retrieved by an end-point by issuing requests and a 107 node accepts a data packet from an ingress interface if and only 108 if at least one matching request packet is stored in the local 109 cache of the node, otherwise the data packet is dropped; 111 o (iv) basic security services are provided by the architecture: 112 authenticity of the data producer and data integrity. A 113 cryptographic signature over a security envelop is computed by the 114 producer (using its own private key) and must be verified by the 115 consumer (using the producer's public key). The security envelop 116 can be as small as a single data packet or cover groups of packets 117 using the technique of the transport manifest [MAN]. 119 2. Architecture 120 +---------------------+ 121 | | Data packets 122 | End-host | +-----------+ +-----------+ 123 | +-------> | | | | 124 | +------------+ | | IPv6 | | hICN | 125 | | Producer | +-----------+ router +----------+ router | 126 | | end-point | | | | | | 127 | +------------+ | <------+ +----+------+ +------+----+ 128 | | | | 129 +---------------------+ Interest | | 130 packets | | 131 | | 132 | | 133 | | 134 +----+------+ +----+------+ 135 | | | | 136 | hICN | | IPv6 | 137 +----------------+ router +------------+ network | 138 + ^ | | | | | 139 | | | +-----------+ +--------+--+ 140 | | | | 141 v | | | 142 | | | 143 +---------------------+ Interest packets | 144 | +------------+ | +--------> +-----------+ | 145 | | Consumer | | | | | 146 | | end-point | +-----------------------+ hICN +-----+ 147 | +------------+ | | router | 148 | | <-------+ | | 149 | End-host | +-----------+ 150 | | Data packets 151 +---------------------+ 153 Figure 1: General overview of an hICN end-to-end communication. 155 The communication model described in this document covers the 156 transport and the network layer. 158 The network layer includes the forwarding plane only and does not 159 consider the routing plane. hICN network layer is about using the 160 IPv6 FIB to determine a next hop router to forward requests or using 161 a local packet cache to determine if an incoming request can be 162 satisfied locally. The hICN forwarding plane takes care of 163 forwarding replies by using information stored in cached requests. 164 The packet pipeline of an hICN node always includes a lookup in a 165 packet cache for both requests and replies. The packet cache is a 166 mandatory component that is added to the usual IPv6 packet processing 167 pipeline. Requests and replies carry an immutable data name end-to- 168 end, in packet header fields as described in the following sections. 169 Moreover, requests and replies carry locators as mutable packet 170 header fields. A locator, i.e. an interface identifier, is changed 171 every time a packet is sent to another hICN node. A detailed 172 description of how locators are modified along the path between end- 173 points is reported in the following sections. 175 It is assumed that existing routing protocols, working for IPv6, 176 should be reused as much as possible as they are. Improvements to 177 existing routing protocols are out of scope and might be developed in 178 other documents to better exploit features made available by the hICN 179 forwarding plane. For instance, hICN forwarding plane can take 180 advantage of the ability of a routing protocol to provide multiple 181 routes for a given destination or more generally compute routes for 182 destinations that are multi-instantiated [MIR]. This topic is 183 important but out of scope for this document. 185 The hICN network architecture can run on top of any link-layer that 186 supports IPv6. hICN data names are globally routable names which are 187 visible to the transport layer end-points. Conversely, the transport 188 layer has no visibility of addresses of network interfaces. The 189 network layer forwards two kind of protocol data units: the request 190 and the reply, called interest and data packets. 192 The hICN network layer offers a communication service to the 193 transport layer in the end-points by means of a local unidirectional 194 channel that we call local or application face. This channel is used 195 by the transport layer to send requests and receive replies or to 196 send replies upon receptions of requests. 198 A transport end-point is always bound to a unidirectional channel 199 that is used to either send data or receive data. The former end- 200 point is called data producer while the latter data consumer. The 201 producer end-point produces data under a location independent name, 202 which is an IPv6 prefix. A consumer end-point fetches data by using 203 the non ambiguous name as provided by the producer. The producer 204 end-point is responsible for managing the usage of the prefix in 205 terms of provisioning, association to applications and its 206 revocation. 208 The transport end-point offers two kinds of services to applications: 209 a producer and a consumer service. The service is instantiated in 210 the application by opening communication sockets with an API to 211 perform basic transport service operations: allocation, 212 initialization, configuration, data transmission and reception. 214 The producer and consumer sockets can implement different types of 215 services such as stream or datagram, reliable or unreliable. In all 216 cases all transport services are connection-less, meaning that a 217 producer transport service produces named data in a socket memory 218 that is accessible by any valid request coming from one or multiple 219 consumers. The consumer, on the other hand, retrieve named data 220 using location independent names which are not tied to any interface 221 identifier (also called locator). This transport model allows to 222 implement reliable consumer mobility without any special mobility 223 management protocol. hICN supports communication of multi-homed end- 224 hosts without any special treatment in the transport layer. The hICN 225 network layer can also implement robust usage of multi-path 226 forwarding in IPv6 networks as balanced request/reply flows self- 227 stabilize network congestion see [CCN],[NDN], [RAQ] . 229 A data packet is an IPv6 packet with a transport layer header 230 carrying data from an application that produces data. An interest 231 packet is an IPv6 packet with a transport layer header and is used to 232 unambiguously fetch a data packet from a producer end point. 234 2.1. End-points 236 In hICN we introduce two new kinds of endpoints: the producer and the 237 consumer. We identify two kind of communication sockets each with a 238 specific API: the producer and consumer sockets. These socket types 239 are designed to exchange data in a multi-point to multi-point manner. 240 In (h)ICN we have the same concept that is applied to a network where 241 memories are distributed across the communication path. The first 242 memory in the path is the production buffer of the producer end-point 243 that forges Data Packets and copies them into a shared memory 244 isolated into a namespace. Consumer sockets can retrieve data from 245 such memory by using the (h)ICN network layer. The model just 246 described is an inter-process communication example (IPC) that 247 requires data to cross a communication network by using a transport 248 protocol. 250 The way consumers and producers synchronize depends on application 251 requirements and the transport layer exposes a variety of services: 252 stream/datagram, reliable/unreliable, with or without latency budgets 253 etc. Independently of the specif requirements of the applications, 254 producer sockets always perform data segmentation from the upper 255 layer into Data Packets, as well as compute digital signatures on the 256 packet security envelop. This envelop can also be computed across a 257 group of packets, by including a cryptographic hash of each packet 258 into the transport manifest, and eventually signing only such 259 manifest. 261 The consumer socket, on the other end, always performs reassembly of 262 Data Packets, hash integrity verification and signature verification. 263 This is common to all architectures in (h)ICN. The usual assumption 264 is that the producer socket uses an authentic-able identity while 265 using namespaces that it has been assigned. The end-point must be 266 able to manage the mapping of her identity and the allocated 267 namespace by issuing digital certificates about the mapping. The 268 consumer end-point must retrieve the associated certificate to 269 perform the basic operations. It is out of scope for this document 270 how to design and implement a scalable system to perform such 271 certificate operations. 273 A detailed description of transport end-points is out of scope for 274 this document. 276 2.2. Naming 278 In hICN, two name components are defined: the name prefix and the 279 name suffix. The name prefix is used to identify an application 280 object, a service or in general an application level source of data 281 in the network. This is incarnated by a listening socket that binds 282 to the name prefix. The name suffix is used to index segmented data 283 within the scope of the name prefix used by the application. 285 For instance an RTP [RFC3550] source with a given SSRC can be mapped 286 into a name prefix. Single RTP sequence numbers can be mapped into 287 name suffixes. For example an HTTP server can listen to a name 288 prefix to serve HTTP requests. An HTTP reply with large payload with 289 require the transport layer to segment the application data unit 290 according to an MTU. Name suffixes are used to index each segment in 291 the socket stream. 293 More details about how to use hICN to transport HTTP or RTP will be 294 given in a different document. 296 2.2.1. Name prefix 298 The format of an hICN name prefix is the following: 300 | 64 bits | 64 bits | 301 +--------------------------------+-------------------------------+ 302 | routable prefix | data identifier | 303 +----------------------------------------------------------------+ 305 Figure 2: hICN IPv6 name prefix. 307 It is composed of a routable IPv6 /64 prefix as per [RFC3587] which 308 SHOULD be globally routable. The data identifier is encoded in 64 309 bits. An application can use several identifiers if needed. 311 From the description given above, the name prefix is a location 312 independent name encoded in an IPv6 address. 314 2.2.2. Name Suffix 316 The name suffix is used by the transport layer protocol to index 317 segments. The segment MUST be indexed in the end-points and in the 318 network with the same suffix. This implies that there is one 319 transport segment per IP packet and that IP fragmentation is not 320 allowed. It is up to the producer end-point to determine how to 321 perform segmentation depending on the use case. An MTU path 322 discovery protocol for hICN is out of scope of this document and 323 additional work is required to extend existing protocols or design 324 new ones. 326 | 32 bits | 327 +----------------------------- 328 | name suffix | 329 +----------------------------- 331 Figure 3: hICN name suffix. 333 2.3. Packet Format 335 Two protocol data units are defined below: the interest (request) and 336 the data (reply). 338 They are composed of a network and transport header. The transport 339 header is the same for both packet types while the network header is 340 slightly different. 342 2.3.1. Interest Packet 343 0 1 2 3 344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 |Version| Traffic Class | Flow Label | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Payload Length | Next Header | Hop Limit | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 + + 352 | | 353 + Source Address + 354 | | 355 + + 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 + + 360 | | 361 + Name Prefix + 362 | | 363 + + 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Interest Packet Header Format 368 Figure 4: IPv6 interest packet L3 header. 370 Source Address: 128-bit address of the originator of the packet 371 (possibly not the end-host but a previous hICN node). 373 Name Prefix: 128-bit name prefix of the intended service. 375 2.3.2. Data Packet 376 0 1 2 3 377 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |Version| Traffic Class | Flow Label | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Payload Length | Next Header | Hop Limit | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 + + 385 | | 386 + Name Prefix + 387 | | 388 + + 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 + + 393 | | 394 + Source Address + 395 | | 396 + + 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Interest Packet Header Format 401 Figure 5: IPv6 data packet L3 header. 403 Name Prefix: 128-bit name prefix of the intended service. 405 Source Address: 128-bit address of the destination of the packet 406 (possibly not the end-host but the next hICN node). 408 0 1 2 3 409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Source Port | Destination Port | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Name Suffix | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Path Label | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Data | Time |M|A|S|R|S|F| Loss Detection | 418 | Offset| Scale |A|C|I|S|Y|I| and Recovery | 419 | | |N|K|G|T|N|N| | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Checksum | Lifetime | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 6: Transport header for data and interest packets. 426 Name Suffix: 32-bit name-suffix of the packet 427 (possibly not the end-host but a previous hICN node). 429 Path Label: 32-bit label used to carry an encoding of the path 430 between the consumer and data responder, be it an 431 intermediate node or the producer end-point. 433 Time Scale: 6-bit natural number in the range 1-64 used as a scaling 434 factor for time calculations. If not null it is used 435 to scale lifetime. 437 Manifest: flag to indicate the packet carries a transport manifest 438 in the payload. 440 Signature: flag to indicate the packet carries an authentication 441 header with a signature. Interest packet do not carry 442 signatures. 444 Loss Detection: 16-bit natural number used to implement data 445 and Recovery sequencing on per adjacency basis to detect an 446 recover losses using the mechanism WLDR described 447 in {{WLD}}. 449 Lifetime: 16-bit unsigned integer to carry the packet lifetime in 450 milliseconds. 452 Checksum: Updated using RFC 1624. 454 The following sections describe the components of an hICN node and 455 the packet processing operations. 457 2.4. Packet cache 459 The packet cache is a router local memory used to temporarily store 460 requests and reply. The simplest incarnation of the packet cache 461 MUST index packets by full name, i.e. the concatenation of the name 462 prefix and suffix. Insertion and deletion of packets in the cache is 463 described below. 465 2.5. Forwarding 467 The forwarding path in hICN is composed of two components: the 468 interest and data path. Requests and replies are processed at the 469 hICN node in a different way. Both forwarding paths require a packet 470 cache to be incorporated into the router. The cache is used to 471 temporarily store requests and replies for a relatively short amount 472 of time. 474 By caching a request in an hICN node, the reply can be transmitted 475 back to the right nodes as the source address field in the interest 476 contains the interface identifier of the hICN node having transmitted 477 the request. Replies are optionally cached if needed. 479 This means that the interest forwarding path is based on lookups in 480 the IP FIB just like any other IP packet, with the additional 481 processing due to a cache lookup to check if the actual reply is 482 already present in the local cache for expedited reply. 484 On the other hand, data packet forwarding is similar to label 485 swapping [RFC3031], being the packet name identifier (prefix plus 486 suffix) the forwarding label. The next hop for the reply in transit 487 is indeed selected by using information in a cached matching request. 489 The name prefix in the packet header is never modified along the path 490 for both requests and replies, while the locator, i.e. the interface 491 identifier written in the source or destination address field, for 492 interest or data packets respectively, is modified at the egress of 493 the router as reported below. 495 2.5.1. Interest Path 497 At the router ingress the incoming interest packet I is parsed to 498 obtain the name prefix and the name suffix. An exact match look up 499 is made in the packet cache using the full packet name as key. Based 500 on the outcome of the lookup the following options are possible: 502 1. at least one match is found. 504 1.1. If one match is a data packet D, other matches are ignored, 505 and D is prepared for transmission by setting D's 506 destination address with I's source address. D is passed to the 507 egress to further processing before transmission. For instance 508 the next-hop MAY be selected by using the router IPv6 FIB 509 (longest prefix match). The IPv6 FIB lookup MIGHT be saved in 510 case the next-hop can be derived directly from information 511 previously derived by processing the incoming interest packet I. 512 I is eventually dropped. 514 1.2. There is one or multiple matches and all are interest 515 packets. 517 * One matching interest has the same source address and I is 518 classified as duplicate and further processed as duplicate. 520 * Matching interest packets have different source addresses and 521 I is classified as filtered and stored in the cache. 523 2. a match is not found and I passed to the egress for further 524 processing to determine the next-hop by using the router IP FIB. 526 Notice that the destination address field in the interest packet is 527 polymorphic as it has two different types based on the data 528 structured it is looked-up against. It has the type of a location 529 independent name while used to find a match in the packet cache and 530 it has an address prefix type to find the next-hop in the IPv6 FIB. 531 Polymorphism is transparent for the forwarding plane while it has 532 several implications in the control plane. 534 Packet Cache 535 RX +------------+ 536 Interest | | Translation Operation 537 +---------> Data Hit | IPv6Hdr(Data).DstAddr:= IPv6Hdr(Interest).SrcAddr 538 TX | + | 539 Data | | | 540 <---------+ <----+ | 541 +------------+ 543 Figure 7: The interest packet hits a matching data packet in the 544 packet cache. 546 +----------------+ +--------+ 547 Interest | | | | Egress NIC 548 +-------> Data Miss +--->+ IP FIB |+-----> 549 | | | | Translation Operation 550 | Interest Miss | | | IPv6Hdr(Interest).SrcAddr:= NIC.Addr 551 | | | | 552 +----------------+ +--------+ 554 Figure 8: The interest packet finds no match in the packet cache and 555 is processed to find a next-hop. 557 Same src addr 558 Packet Cache +-----------+ 559 +--------------+ | Duplicate | 560 Interest | | +-----^-----+ 561 +-------> Data Miss | | 562 | Interet Hit+-------------->-+ 563 | | | 564 +--------------+ | 565 +-----v-----+ 566 |Filtered | 567 +-----------+ 568 Different src addr 570 Figure 9: The interest packet hits an interest packet in the packet 571 cache. 573 2.5.2. Data Path 575 At the router ingress the incoming data packet D is parsed to obtain 576 the name prefix and the name suffix. An exact match look up is made 577 in the packet cache using the full packet name as key. Based on the 578 outcome of the lookup the following options are possible: 580 1. one or multiple matching interest packets are found 1.1. The 581 data packet D is cloned to have as many copies as the number of 582 matching interests including D. The destination address field of 583 each copy of D is set with the source address field of each 584 interest packet. All copies are passed to the egress to further 585 processing before transmission in order to find each data 586 packet's next-hop. 588 2. No matching is an interest packet and the D is dropped. 590 RX 591 Data +-----------+ 592 +--------> | Interest | 593 | Hit | 594 | + | 595 +-----------+ 596 | 597 | 598 | 599 | Translation Operation 600 | +------> 601 | | IPv6Hdr(Data[1]).DstAddr:=IPv6Hdr(Interest[1]).SrcAddr 602 | | TX Data[1] 603 +-----> | 604 | ... 605 | 606 | 607 | IPv6Hdr(Data[N]).DstAddr:=IPv6Hdr(Interest[N]).SrcAddr 608 | TX Data[N] 609 +------> 611 Figure 10: The data packet hits an interest packet in the packet 612 cache. 614 RX Packet Cache 615 Data +------------------+ Drop Data 616 +---------->+ Interest Miss +------> 617 | OR Data hit | 618 +------------------+ 620 Figure 11: The data packet is drop in case no interest match is found 621 in the packet cache. 623 3. Security 625 hICN inherits ICN data-centric security model: integrity, data-origin 626 authenticity and confidentiality are tied to the content rather than 627 to the channel. 628 Integrity and data-origin authenticity are provided through a digital 629 signature computed by the producer and included in each data packet. 630 Integrity and data-origin authenticity qre provided in two ways using 631 two approaches: the first one based on IP Authenticated Header 632 [RFC4302] and the second one based on transport manifests. Notice 633 that the IP AH is not used as an IPv6 extension header as it is 634 appended after the transport header. However the choice of the IP AH 635 has been made in order to exploit existing protocol implementations 636 in the end-points. 638 When using IP AH, the signature is computed over 640 o (i)IP or extension header fields either immutable in transit or 641 that are predictable in value upon arrival at the consumer, 643 o (ii) the AH header with the signature field set to zero. We 644 recall that in hICN the destination header field is not immutable 645 nor predictable and must be set to zero for the signature 646 computation. We also point out the AH in placed after the TCP 647 header in order to prevent any kind of filtering from network 648 devices such as middleboxes. 650 0 1 2 3 651 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Next Header | Payload Len | ValidAlg | | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Timestamp | 656 | | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 / / 659 / KeyID / 660 / / 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 / / 663 / Signature / 664 / / 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Figure 12: The IP authentication header appended after the transport 668 header to carry packet signatures. 670 ValidAlg: 8-bit index to indicate which validation algorithm 671 must be used to verify the signature. 673 Timestamp: 64-bit time stamp that indicates the validity of the 674 signature. 676 KeyID: 256-bit key identifier. 678 Signature: Variable length field that carries the cryotographic 679 signature of the security envelope. 680 It is 128 bytes for RSA-1024, 256 bytes for RSA-2048, 681 56 bytes for EDCSA 192, 72 bytes for ECDSA 256. 683 The transport manifest is a L4 entity computed at the producer which 684 contains the list of names of a group of data packets to convey to 685 the consumer. hICN cryptographic hashes of data packets are then 686 computed instead of signatures. The hashes are computed on immutable 687 fields as explained above when using the IP AH. Moreover, the 688 manifest must be signed to guarantee a level of security equivalent 689 to packet-wise signatures. 691 hICN is oblivious of the trust model adopted by consumers and works 692 with any of the existing proposals. 694 0 1 2 3 695 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 |Version| MType |HashAlg|NextStr| Flags |NumberOfEntries| 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | | 700 + + 701 | | 702 + Prefix + 703 | | 704 + + 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Name-suffix[1] | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Hash Value[1] | 710 | | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 . . . 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Name-suffixv[NumberOfEntries] | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Hash Value [NumberOfEntries] | 717 | | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Figure 13: The transport manifest, generated by the producer end- 721 point for the consumer end-point, contains names, integrity hashes 722 and is signed with the producer end-point private key 724 Version: 8-bit index to indicate which validation algorithm 725 must be used to verify the signature. 727 MType: 64-bit time stamp that indicates the validity of the 728 signature. 730 HashAlg: 256-bit key identifier. 732 NextStr: Encode an operator use to predict the name-suffix 733 sequence 735 Flags: Flags. 737 NumberOfEntries: 8-bit field that encodes the number of packets indexed 738 in the manifest. 740 Name-prefix: 128-bit field carrying the name-prefix common to all 741 packets indexed in the manifest. 743 Name-suffix: 32-bit field carrying the name-suffix. 745 Hash-value: 256-bit field carrying the SHA-256 hash of the packet 746 security envelop. 748 4. IANA Considerations 750 There are no IANA considerations in this specification. 752 5. Acknowledgements 754 The authors would like to thank David Ward, David Oran, Paul Polakos, 755 Mark Townsley, Mauro Sardara and Alberto Compagno for suggestions on 756 how to improve the architecture and the current document. 758 6. References 760 6.1. Normative References 762 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 763 RFC 793, DOI 10.17487/RFC0793, September 1981, 764 . 766 [RFC1081] Rose, M., "Post Office Protocol: Version 3", RFC 1081, 767 DOI 10.17487/RFC1081, November 1988, 768 . 770 [RFC1624] Rijsinghani, A., Ed., "Computation of the Internet 771 Checksum via Incremental Update", RFC 1624, 772 DOI 10.17487/RFC1624, May 1994, 773 . 775 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 776 Label Switching Architecture", RFC 3031, 777 DOI 10.17487/RFC3031, January 2001, 778 . 780 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 781 Jacobson, "RTP: A Transport Protocol for Real-Time 782 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 783 July 2003, . 785 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 786 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 787 August 2003, . 789 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 790 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 791 2006, . 793 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 794 DOI 10.17487/RFC4302, December 2005, 795 . 797 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 798 Locator/ID Separation Protocol (LISP)", RFC 6830, 799 DOI 10.17487/RFC6830, January 2013, 800 . 802 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 803 (IPv6) Specification", STD 86, RFC 8200, 804 DOI 10.17487/RFC8200, July 2017, 805 . 807 6.2. Informative References 809 [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 810 Briggs, N., and R. Braynard, "Networking named content", 811 Proceedings of the 5th international conference on 812 Emerging networking experiments and technologies - 813 CoNEXT '09, DOI 10.1145/1658939.1658941, 2009. 815 [I-D.irtf-icnrg-ccnxmessages] 816 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 817 Format", draft-irtf-icnrg-ccnxmessages-07 (work in 818 progress), March 2018. 820 [I-D.irtf-icnrg-ccnxsemantics] 821 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 822 draft-irtf-icnrg-ccnxsemantics-07 (work in progress), 823 March 2018. 825 [I-D.irtf-icnrg-mapme] 826 Auge, J., Carofiglio, G., Muscariello, L., and M. 827 Papalini, "MAP-Me : Managing Anchorless Mobility in 828 Content Centric Networking", draft-irtf-icnrg-mapme-00 829 (work in progress), March 2018. 831 [I-D.irtf-icnrg-terminology] 832 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 833 D., and C. Tschudin, "Information-Centric Networking 834 (ICN): CCN and NDN Terminology", draft-irtf-icnrg- 835 terminology-00 (work in progress), December 2017. 837 [MAN] Baugher, M., Davie, B., Narayanan, A., and D. Oran, "Self- 838 verifying names for read-only named data", 2012 839 Proceedings IEEE INFOCOM Workshops, 840 DOI 10.1109/infcomw.2012.6193505, March 2012. 842 [MIR] Garcia-Luna-Aceves, J., Martinez-Castillo, J., and R. 843 Menchaca-Mendez, "Routing to Multi-Instantiated 844 Destinations: Principles, Practice, and Applications", 845 IEEE Transactions on Mobile Computing Vol. 17, pp. 846 1696-1709, DOI 10.1109/tmc.2017.2734658, July 2018. 848 [NDN] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., claffy, 849 k., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 850 "Named data networking", ACM SIGCOMM Computer 851 Communication Review Vol. 44, pp. 66-73, 852 DOI 10.1145/2656877.2656887, July 2014. 854 [RAQ] Carofiglio, G., Gallo, M., Muscariello, L., Papalini, M., 855 and , "Optimal multipath congestion control and request 856 forwarding in Information-Centric Networks", 2013 21st 857 IEEE International Conference on Network Protocols (ICNP), 858 DOI 10.1109/icnp.2013.6733576, October 2013. 860 [WLD] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 861 N., and X. Zeng, "Leveraging ICN In-network Control for 862 Loss Detection and Recovery in Wireless Mobile networks", 863 Proceedings of the 2016 conference on 3rd ACM Conference 864 on Information-Centric Networking - ACM-ICN '16, 865 DOI 10.1145/2984356.2984361, 2016. 867 Authors' Addresses 869 Luca Muscariello 870 Cisco Systems Inc. 872 Email: lumuscar@cisco.com 874 Giovanna Carofiglio 875 Cisco Systems Inc. 877 Email: gcarofig@cisco.com 879 Jordan Auge 880 Cisco Systems Inc. 882 Email: augjorda@cisco.com 884 Michele Papalini 885 Cisco Systems Inc. 887 Email: mpapal@cisco.com