idnits 2.17.1 draft-muscariello-intarea-hicn-04.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 33 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 441 has weird spacing: '...mediate node ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (20 May 2020) is 1427 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 742 == Missing Reference: 'N' is mentioned on line 641, but not defined == Missing Reference: 'NumberOfEntries' is mentioned on line 749, but not defined == Unused Reference: 'WLD' is defined on line 924, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 7 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. Augé 5 Expires: 21 November 2020 M. Papalini 6 M. Sardara 7 Cisco Systems Inc. 8 20 May 2020 10 Hybrid Information-Centric Networking 11 draft-muscariello-intarea-hicn-04 13 Abstract 15 This document describes the hybrid information-centric networking 16 (hICN) architecture for IPv6. The specifications describe a way to 17 implement information-networking functionalities into IPv6. The 18 objective is to use IPv6 without creating overlays with a new packet 19 format as an additional encapsulation. The intent of the present 20 design is to introduce some IPv6 routers in the network with 21 additional packet processing operations to implement ICN functions. 22 Moreover, the current design is tightly integrated into IPv6 to allow 23 easy interconnection to IPv6 networks with the additional design 24 objective to exploit existing IPv6 protocols as much as possible as 25 they are, or extend them where needed. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 21 November 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 62 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. End-points . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.2.1. Name prefix . . . . . . . . . . . . . . . . . . . . . 7 66 2.2.2. Name Suffix . . . . . . . . . . . . . . . . . . . . . 8 67 2.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8 68 2.3.1. Interest Packet . . . . . . . . . . . . . . . . . . . 8 69 2.3.2. Data Packet . . . . . . . . . . . . . . . . . . . . . 9 70 2.4. Packet cache . . . . . . . . . . . . . . . . . . . . . . 12 71 2.5. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 12 72 2.5.1. Interest Path . . . . . . . . . . . . . . . . . . . . 13 73 2.5.2. Data Path . . . . . . . . . . . . . . . . . . . . . . 14 74 3. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 4. The End-host model and End-to-End considerations . . . . . . 18 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 80 7.2. Informative References . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 The objective of this document is to describe hybrid ICN, a network 86 protocol that integrates ICN in IPv6, at a minimum cost in terms of 87 required modifications in end-points and routers and in a way to 88 guarantee transparent interconnection with IP without using overlays. 89 Extensions for IPv4 exist but are out of scope for this document. 91 The ICN reference design used in this document is CCNx as described 92 in [RFC8569] and [RFC8609]. IPv6 is used as described in [RFC8200]. 94 There are some basic design principles behind the hICN architecture 95 that are implemented by the design reported below that can be 96 summarized as follows: 98 * (i) the network can transport many different kinds of applications 99 as IPv6, i.e. hICN can serve content-distribution or real-time 100 applications, to cite examples with very different requirements. 101 hICN is not a content-distribution network; 103 * (ii) it provides connection-less and location independent 104 communications by identifying data with unique global names, 105 instead of naming network interfaces (locator) or end-hosts (end- 106 host identifiers) as in LISP [RFC6830]. 108 * (iii) data is retrieved by an end-point by issuing requests and a 109 node accepts a data packet from an ingress interface if and only 110 if at least one matching request packet is stored in the local 111 cache of the node, otherwise the data packet is dropped; 113 * (iv) basic security services are provided by the architecture: 114 authenticity of the data producer and data integrity. A 115 cryptographic signature over a security envelop is computed by the 116 producer (using its own private key) and must be verified by the 117 consumer (using the producer's public key). The security envelop 118 can be as small as a single data packet or cover groups of packets 119 using the technique of the transport manifest [MAN]. 121 1.1. Notational Conventions 123 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 124 document. It's not shouting; when these words are capitalized, they 125 have a special meaning as defined in [RFC2119]. 127 2. Architecture 128 +---------------------+ 129 | | Data packets 130 | End-host | +-----------+ +-----------+ 131 | +-------> | | | | 132 | +------------+ | | IPv6 | | hICN | 133 | | Producer | +-----------+ router +----------+ router | 134 | | end-point | | | | | | 135 | +------------+ | <------+ +----+------+ +------+----+ 136 | | | | 137 +---------------------+ Interest | | 138 packets | | 139 | | 140 | | 141 | | 142 +----+------+ +----+------+ 143 | | | | 144 | hICN | | IPv6 | 145 +----------------+ router +------------+ network | 146 + ^ | | | | | 147 | | | +-----------+ +--------+--+ 148 | | | | 149 v | | | 150 | | | 151 +---------------------+ Interest packets | 152 | +------------+ | +--------> +-----------+ | 153 | | Consumer | | | | | 154 | | end-point | +-----------------------+ hICN +-----+ 155 | +------------+ | | router | 156 | | <-------+ | | 157 | End-host | +-----------+ 158 | | Data packets 159 +---------------------+ 161 Figure 1: General overview of an hICN end-to-end communication. 163 The communication model described in this document covers the 164 transport and the network layer. Additional details can be found in 165 [HCN] with additional analysis 167 The network layer includes the forwarding plane only and does not 168 consider the routing plane. hICN network layer is about using the 169 IPv6 FIB to determine a next hop router to forward requests or using 170 a local packet cache to determine if an incoming request can be 171 satisfied locally. The hICN forwarding plane takes care of 172 forwarding replies by using information stored in cached requests. 173 The packet pipeline of an hICN node always includes a lookup in a 174 packet cache for both requests and replies. The packet cache is a 175 mandatory component that is added to the usual IPv6 packet processing 176 pipeline. Requests and replies carry an immutable data name end-to- 177 end, in packet header fields as described in the following sections. 178 Moreover, requests and replies carry locators as mutable packet 179 header fields. A locator, i.e. an interface identifier, is changed 180 every time a packet is sent to another hICN node. A detailed 181 description of how locators are modified along the path between end- 182 points is reported in the following sections. 184 It is assumed that existing routing protocols, working for IPv6, 185 should be reused as much as possible as they are. Improvements to 186 existing routing protocols are out of scope and might be developed in 187 other documents to better exploit features made available by the hICN 188 forwarding plane. For instance, hICN forwarding plane can take 189 advantage of the ability of a routing protocol to provide multiple 190 routes for a given destination or more generally compute routes for 191 destinations that are multi-instantiated [MIR]. This topic is 192 important but out of scope for this document. 194 The hICN network architecture can run on top of any link-layer that 195 supports IPv6. hICN data names are globally routable names which are 196 visible to the transport layer end-points. Conversely, the transport 197 layer has no visibility of addresses of network interfaces. The 198 network layer forwards two kinds of protocol data units: the request 199 and the reply, called interest and data packets. 201 The hICN network layer offers a communication service to the 202 transport layer in the end-points by means of a local unidirectional 203 channel that we call local or application face. This channel is used 204 by the transport layer to send requests and receive replies or to 205 send replies upon receptions of requests. 207 A transport end-point is always bound to a unidirectional channel 208 that is used to either send data or receive data. The former end- 209 point is called data producer while the latter data consumer. The 210 producer end-point produces data under a location independent name, 211 which is an IPv6 prefix. A consumer end-point fetches data by using 212 the non ambiguous name as provided by the producer. The producer 213 end-point is responsible for managing the usage of the prefix in 214 terms of provisioning, association to applications and its 215 revocation. 217 The transport end-point offers two kinds of services to applications: 218 a producer and a consumer service. The service is instantiated in 219 the application by opening communication sockets with an API to 220 perform basic transport service operations: allocation, 221 initialization, configuration, data transmission and reception. 223 The producer and consumer sockets can implement different types of 224 services such as stream or datagram, reliable or unreliable. In all 225 cases all transport services are connection-less, meaning that a 226 producer transport service produces named data in a socket memory 227 that is accessible by any valid request coming from one or multiple 228 consumers. The consumer, on the other hand, retrieve named data 229 using location independent names which are not tied to any interface 230 identifier (also called locator). This transport model allows to 231 implement reliable consumer mobility without any special mobility 232 management protocol. hICN supports communication of multi-homed end- 233 hosts without any special treatment in the transport layer. The hICN 234 network layer can also implement robust usage of multi-path 235 forwarding in IPv6 networks as balanced request/reply flows self- 236 stabilize network congestion see [CCN],[NDN], [RAQ] . 238 A data packet is an IPv6 packet with a transport layer header 239 carrying data from an application that produces data. An interest 240 packet is an IPv6 packet with a transport layer header and is used to 241 unambiguously fetch a data packet from a producer end point. 243 2.1. End-points 245 In hICN we introduce two new kinds of endpoints: the producer and the 246 consumer. We identify two kind of communication sockets each with a 247 specific API: the producer and consumer sockets. These socket types 248 are designed to exchange data in a multi-point to multi-point manner. 249 In (h)ICN we have the same concept that is applied to a network where 250 memories are distributed across the communication path. The first 251 memory in the path is the production buffer of the producer end-point 252 that forges Data Packets and copies them into a shared memory 253 isolated into a namespace. Consumer sockets can retrieve data from 254 such memory by using the (h)ICN network layer. The model just 255 described is an inter-process communication example (IPC) that 256 requires data to cross a communication network by using a transport 257 protocol. 259 The way consumers and producers synchronize depends on application 260 requirements and the transport layer exposes a variety of services: 261 stream/datagram, reliable/unreliable, with or without latency budgets 262 etc. Independently of the specific requirements of the applications, 263 producer sockets always perform data segmentation from the upper 264 layer into Data Packets, as well as compute digital signatures on the 265 packet security envelop. This envelop can also be computed across a 266 group of packets, by including a cryptographic hash of each packet 267 into the transport manifest, and eventually signing only such 268 manifest. 270 The consumer socket, on the other end, always performs reassembly of 271 Data Packets, hash integrity verification and signature verification. 272 This is common to all architectures in (h)ICN. The usual assumption 273 is that the producer socket uses an authentic-able identity while 274 using namespaces that it has been assigned. The end-point must be 275 able to manage the mapping of her identity and the allocated 276 namespace by issuing digital certificates about the mapping. The 277 consumer end-point must retrieve the associated certificate to 278 perform the basic operations. It is out of scope for this document 279 how to design and implement a scalable system to perform such 280 certificate operations. 282 A detailed description of transport end-points is out of scope for 283 this document. A detailed description of transport end-points is out 284 of scope for this document but more details can be found in [TRA]. 286 2.2. Naming 288 In hICN, two name components are defined: the name prefix and the 289 name suffix. The name prefix is used to identify an application 290 object, a service or in general an application level source of data 291 in the network. This is incarnated by a listening socket that binds 292 to the name prefix. The name suffix is used to index segmented data 293 within the scope of the name prefix used by the application. 295 For instance an RTP [RFC3550] source with a given SSRC can be mapped 296 into a name prefix. Single RTP sequence numbers can be mapped into 297 name suffixes. For example an HTTP server can listen to a name 298 prefix to serve HTTP requests. An HTTP reply with large payload with 299 require the transport layer to segment the application data unit 300 according to an MTU. Name suffixes are used to index each segment in 301 the socket stream. 303 More details about how to use hICN to transport HTTP or RTP will be 304 given in a different document. 306 2.2.1. Name prefix 308 The format of an hICN name prefix is the following: 310 | 64 bits | 64 bits | 311 +--------------------------------+-------------------------------+ 312 | routable prefix | data identifier | 313 +----------------------------------------------------------------+ 315 Figure 2: hICN IPv6 name prefix. 317 It is composed of a routable IPv6 /64 prefix as per [RFC3587] which 318 SHOULD be globally routable. The data identifier is encoded in 64 319 bits. An application can use several identifiers if needed. 321 From the description given above, the name prefix is a location 322 independent name encoded in an IPv6 address. 324 2.2.2. Name Suffix 326 The name suffix is used by the transport layer protocol to index 327 segments. The segment MUST be indexed in the end-points and in the 328 network with the same suffix. This implies that there is one 329 transport segment per IP packet and that IP fragmentation is not 330 allowed. Extension to allow secure fragmentation are possible, such 331 as [FRA] but they are out of scope for this document. It is up to 332 the producer end-point to determine how to perform segmentation 333 depending on the use case. An MTU path discovery protocol for hICN 334 is out of scope of this document and additional work is required to 335 extend existing protocols or design new ones. 337 | 32 bits | 338 +----------------------------- 339 | name suffix | 340 +----------------------------- 342 Figure 3: hICN name suffix. 344 2.3. Packet Format 346 Two protocol data units are defined below: the interest (request) and 347 the data (reply). 349 They are composed of a network and transport header. The transport 350 header is the same for both packet types while the network header is 351 slightly different. 353 2.3.1. Interest Packet 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |Version| Traffic Class | Flow Label | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Payload Length | Next Header | Hop Limit | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | | 362 + + 363 | | 364 + Source Address + 365 | | 366 + + 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 + + 371 | | 372 + Name Prefix + 373 | | 374 + + 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Interest Packet Header Format 379 Figure 4: IPv6 interest packet L3 header. 381 Source Address: 128-bit address of the originator of the packet 382 (possibly not the end-host but a previous hICN node). 384 Name Prefix: 128-bit name prefix of the intended service. 386 2.3.2. Data Packet 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |Version| Traffic Class | Flow Label | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Payload Length | Next Header | Hop Limit | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 + + 396 | | 397 + Name Prefix + 398 | | 399 + + 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 + + 404 | | 405 + Destination Address + 406 | | 407 + + 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Data Packet Header Format 412 Figure 5: IPv6 data packet L3 header. 414 Name Prefix: 128-bit name prefix of the intended service. 416 Source Address: 128-bit address of the destination of the packet 417 (possibly not the end-host but the next hICN node). 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Source Port | Destination Port | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Name Suffix | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Path Label | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Data | Time |M|A|S|x|x|x| Loss Detection | 429 | Offset| Scale |A|C|I|x|x|x| and Recovery | 430 | | |N|K|G|x|x|x| | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Checksum | Lifetime | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 6: Transport header for data and interest packets. 436 Name Suffix: 32-bit name-suffix of the packet 437 (possibly not the end-host but a previous hICN node). 439 Path Label: 32-bit label used to carry an encoding of the path 440 between the consumer and data responder, be it an 441 intermediate node or the producer end-point. 443 Time Scale: 6-bit natural number in the range 1-64 used as a scaling 444 factor for time calculations. If not null it is used 445 to scale lifetime. 447 Manifest: flag to indicate the packet carries a transport manifest 448 in the payload. 450 Signature: flag to indicate the packet carries an authentication 451 header with a signature. Interest packet do not carry 452 signatures. 454 Loss Detection: 16-bit natural number used to implement data 455 and Recovery sequencing on per adjacency basis to detect an 456 recover losses using the mechanism WLDR described 457 in {{WLD}}. 459 Lifetime: 16-bit unsigned integer to carry the packet lifetime in 460 milliseconds. 462 Checksum: Updated using RFC 1624. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Source Port | Destination Port | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Length | Checksum | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Name Suffix | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Path Label | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Data | Time |M|A|S|x|x|x| Loss Detection | 476 | Offset| Scale |A|C|I|x|x|x| and Recovery | 477 | | |N|K|G|x|x|x| | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Checksum | Lifetime | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 7: Transport header for data and interest packets using 482 UDP header. 484 Both transport headers can be used to carry name suffix information. 486 The following sections describe the components of an hICN node and 487 the packet processing operations. 489 2.4. Packet cache 491 The packet cache is a router local memory used to temporarily store 492 requests and reply. The simplest incarnation of the packet cache 493 MUST index packets by full name, i.e. the concatenation of the name 494 prefix and suffix. Insertion and deletion of packets in the cache is 495 described below. 497 2.5. Forwarding 499 The forwarding path in hICN is composed of two components: the 500 interest and data path. Requests and replies are processed at the 501 hICN node in a different way. Both forwarding paths require a packet 502 cache to be incorporated into the router. The cache is used to 503 temporarily store requests and replies for a relatively short amount 504 of time. 506 By caching a request in an hICN node, the reply can be transmitted 507 back to the right nodes as the source address field in the interest 508 contains the interface identifier of the hICN node having transmitted 509 the request. Replies are optionally cached if needed. 511 This means that the interest forwarding path is based on lookups in 512 the IP FIB just like any other IP packet, with the additional 513 processing due to a cache lookup to check if the actual reply is 514 already present in the local cache for expedited reply. 516 On the other hand, data packet forwarding is similar to label 517 swapping [RFC3031], being the packet name identifier (prefix plus 518 suffix) the forwarding label. The next hop for the reply in transit 519 is indeed selected by using information in a cached matching request. 521 The name prefix in the packet header is never modified along the path 522 for both requests and replies, while the locator, i.e. the interface 523 identifier written in the source or destination address field, for 524 interest or data packets respectively, is modified at the egress of 525 the router as reported below. 527 2.5.1. Interest Path 529 At the router ingress the incoming interest packet I is parsed to 530 obtain the name prefix and the name suffix. An exact match look up 531 is made in the packet cache using the full packet name as key. Based 532 on the outcome of the lookup the following options are possible: 534 1. at least one match is found. 536 1.1. If one match is a data packet D, other matches are ignored, 537 and D is prepared for transmission by setting D's 539 destination address with I's source address. D is passed to the 540 egress to further processing before transmission. For instance 541 the next-hop MAY be selected by using the router IPv6 FIB 542 (longest prefix match). The IPv6 FIB lookup MIGHT be saved in 543 case the next-hop can be derived directly from information 544 previously derived by processing the incoming interest packet I. 545 I is eventually dropped. 547 1.2. There is one or multiple matches and all are interest 548 packets. 550 * One matching interest has the same source address and I is 551 classified as duplicate and further processed as duplicate. 553 * Matching interest packets have different source addresses and 554 I is classified as filtered and stored in the cache. 556 2. a match is not found and I passed to the egress for further 557 processing to determine the next-hop by using the router IP FIB. 559 Notice that the destination address field in the interest packet is 560 polymorphic as it has two different types based on the data 561 structured it is looked-up against. It has the type of a location 562 independent name while used to find a match in the packet cache and 563 it has an address prefix type to find the next-hop in the IPv6 FIB. 564 Polymorphism is transparent for the forwarding plane while it has 565 several implications in the control plane. 567 Packet Cache 568 RX +------------+ 569 Interest | | Translation Operation 570 +---------> Data Hit | IPv6Hdr(Data).DstAddr:= IPv6Hdr(Interest).SrcAddr 571 TX | + | 572 Data | | | 573 <---------+ <----+ | 574 +------------+ 576 Figure 8: The interest packet hits a matching data packet in the 577 packet cache. 579 +----------------+ +--------+ 580 Interest | | | | Egress NIC 581 +-------> Data Miss +--->+ IP FIB |+-----> 582 | | | | Translation Operation 583 | Interest Miss | | | IPv6Hdr(Interest).SrcAddr:= NIC.Addr 584 | | | | 585 +----------------+ +--------+ 587 Figure 9: The interest packet finds no match in the packet cache 588 and is processed to find a next-hop. 590 Same src addr 591 Packet Cache +-----------+ 592 +--------------+ | Duplicate | 593 Interest | | +-----^-----+ 594 +-------> Data Miss | | 595 | Interest Hit +-------------->-+ 596 | | | 597 +--------------+ | 598 +-----v-----+ 599 |Filtered | 600 +-----------+ 601 Different src addr 603 Figure 10: The interest packet hits an interest packet in the 604 packet cache. 606 2.5.2. Data Path 608 At the router ingress the incoming data packet D is parsed to obtain 609 the name prefix and the name suffix. An exact match look up is made 610 in the packet cache using the full packet name as key. Based on the 611 outcome of the lookup the following options are possible: 613 1. one or multiple matching interest packets are found 1.1. The 614 data packet D is cloned to have as many copies as the number of 615 matching interests including D. The destination address field of 616 each copy of D is set with the source address field of each 617 interest packet. All copies are passed to the egress to further 618 processing before transmission in order to find each data 619 packet's next-hop. 621 2. No matching is an interest packet and the D is dropped. 623 RX 624 Data +-----------+ 625 +--------> | Interest | 626 | Hit | 627 | + | 628 +-----------+ 629 | 630 | 631 | 632 | Translation Operation 633 | +------> 634 | | IPv6Hdr(Data[1]).DstAddr:=IPv6Hdr(Interest[1]).SrcAddr 635 | | TX Data[1] 636 +-----> | 637 | ... 638 | 639 | 640 | IPv6Hdr(Data[N]).DstAddr:=IPv6Hdr(Interest[N]).SrcAddr 641 | TX Data[N] 642 +------> 644 Figure 11: The data packet hits an interest packet in the packet 645 cache. 647 RX Packet Cache 648 Data +------------------+ Drop Data 649 +---------->+ Interest Miss +------> 650 | OR Data hit | 651 +------------------+ 653 Figure 12: The data packet is drop in case no interest match is 654 found in the packet cache. 656 3. Security 658 hICN inherits ICN data-centric security model: integrity, data-origin 659 authenticity and confidentiality are tied to the content rather than 660 to the channel. Integrity and data-origin authenticity are provided 661 through a digital signature computed by the producer and included in 662 each data packet. Integrity and data-origin authenticity are 663 provided in two ways using two approaches: the first one based on IP 664 Authenticated Header [RFC4302] and the second one based on transport 665 manifests. Notice that the IP AH is not used as an IPv6 extension 666 header as it is appended after the transport header. However the 667 choice of the IP AH has been made in order to exploit existing 668 protocol implementations in the end-points. 670 When using IP AH, the signature is computed over 671 * (i)IP or extension header fields either immutable in transit or 672 that are predictable in value upon arrival at the consumer, 674 * (ii) the AH header with the signature field set to zero. We 675 recall that in hICN the destination header field is not immutable 676 nor predictable and must be set to zero for the signature 677 computation. We also point out the AH in placed after the TCP 678 header in order to prevent any kind of filtering from network 679 devices such as middleboxes. 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Next Header | Payload Len | ValidAlg | | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Timestamp | 687 | | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 / / 690 / KeyID / 691 / / 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 / / 694 / Signature / 695 / / 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Figure 13: The IP authentication header appended after the 699 transport header to carry packet signatures. 701 ValidAlg: 8-bit index to indicate which validation algorithm 702 must be used to verify the signature. 704 Timestamp: 64-bit time stamp that indicates the validity of the 705 signature. 707 KeyID: 256-bit key identifier. 709 Signature: Variable length field that carries the cryptographic 710 signature of the security envelope. 711 It is 128 bytes for RSA-1024, 256 bytes for RSA-2048, 712 56 bytes for EDCSA 192, 72 bytes for ECDSA 256. 714 The transport manifest is a L4 entity computed at the producer which 715 contains the list of names of a group of data packets to convey to 716 the consumer. hICN cryptographic hashes of data packets are then 717 computed instead of signatures. The hashes are computed on immutable 718 fields as explained above when using the IP AH. Moreover, the 719 manifest must be signed to guarantee a level of security equivalent 720 to packet-wise signatures. When the producer uses the manifest data 721 packets do not carry the AH which is carried by the transport 722 manifest only. 724 hICN is oblivious of the trust model adopted by consumers and works 725 with any of the existing proposals. 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 |Version| MType |HashAlg|NextStr| Flags |NumberOfEntries| 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | | 733 + + 734 | | 735 + Prefix + 736 | | 737 + + 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Name-suffix[1] | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Hash Value[1] | 743 | | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 . . . 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Name-suffix[NumberOfEntries] | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Hash Value [NumberOfEntries] | 750 | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Version: 8-bit index to indicate which validation algorithm 753 must be used to verify the signature. 755 MType: 64-bit time stamp that indicates the validity of the 756 signature. 758 HashAlg: 256-bit key identifier. 760 NextStr: Encode an operator use to predict the name-suffix 761 sequence 763 Flags: Flags. 765 NumberOfEntries: 8-bit field that encodes the number of packets indexed 766 in the manifest. 768 Name-prefix: 128-bit field carrying the name-prefix common to all 769 packets indexed in the manifest. 771 Name-suffix: 32-bit field carrying the name-suffix. 773 Hash-value: 256-bit field carrying the SHA-256 hash of the packet 774 security envelop. 776 Figure 14: The transport manifest, generated by the producer end- 777 point for the consumer end-point, contains names, integrity 778 hashes and is signed with the producer end-point private key 780 4. The End-host model and End-to-End considerations 782 In hICN the end-host model is very similar to a regular IPv6 end-host 783 with some extensions. An end-host is capable of opening consumer and 784 producer transport end-points, one to receive data and one to send 785 data under a given name prefix. The end-host continues to identify 786 interfaces using IPv6 addresses (locators or routing locators, RLOCs, 787 using LISP terminology), just like any IPv6 router. In addition to 788 that, transport end-points bind to location-independent names, 789 similar to LISP end-point identifiers (EIDs). However, instead of 790 using name prefixes to identify end-hosts only, in hICN a name prefix 791 is used to identify a data source. 793 There is an analogy between IPv6 multicast and the hICN data 794 forwarding path for one-to-many communications, as the IPv6 multicast 795 group address identifies data that group members receive from a 796 single sender. Notice that in hICN a data packet transmission stores 797 the identifiers in the source address field while in IPv6 multicast 798 it is stored in the destination address field. 800 Theres is also an analogy between IPv6 anycast and the hICN interest 801 forwarding path, where multiple interfaces make use of the same IPv6 802 (anycast) address. Multiple instances of the same applications can 803 then run at different end-points to eventually reply to the same 804 request. 806 An hICN network node behaves as an end-host consumer end-point for 807 the upstream producer end-point as all replies are forced to flow 808 back to the same hICN that transmitted the requests. An hICN network 809 node may be able to reply to a request on behalf of a end-point 810 producer, in that case that hICN node behaves as an end-host for the 811 consumer end-point. 813 5. IANA Considerations 815 There are no IANA considerations in this specification. 817 6. Acknowledgements 819 The authors would like to thank David Ward, David Oran, Paul Polakos, 820 Mark Townsley and Alberto Compagno for suggestions on how to improve 821 the architecture and the current document. 823 7. References 825 7.1. Normative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, 829 DOI 10.17487/RFC2119, March 1997, 830 . 832 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 833 Label Switching Architecture", RFC 3031, 834 DOI 10.17487/RFC3031, January 2001, 835 . 837 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 838 Jacobson, "RTP: A Transport Protocol for Real-Time 839 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 840 July 2003, . 842 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 843 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 844 August 2003, . 846 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 847 DOI 10.17487/RFC4302, December 2005, 848 . 850 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 851 Locator/ID Separation Protocol (LISP)", RFC 6830, 852 DOI 10.17487/RFC6830, January 2013, 853 . 855 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 856 (IPv6) Specification", STD 86, RFC 8200, 857 DOI 10.17487/RFC8200, July 2017, 858 . 860 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 861 Networking (CCNx) Semantics", RFC 8569, 862 DOI 10.17487/RFC8569, July 2019, 863 . 865 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 866 Networking (CCNx) Messages in TLV Format", RFC 8609, 867 DOI 10.17487/RFC8609, July 2019, 868 . 870 7.2. Informative References 872 [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 873 Briggs, N., and R. Braynard, "Networking named content", 874 DOI 10.1145/1658939.1658941, Proceedings of the 5th 875 international conference on Emerging networking 876 experiments and technologies - CoNEXT '09, 2009, 877 . 879 [FRA] Mosko, M. and C. Wood, "Secure Fragmentation for Content 880 Centric Networking", DOI 10.1109/mass.2015.51, 2015 IEEE 881 12th International Conference on Mobile Ad Hoc and 882 Sensor Systems, October 2015, 883 . 885 [HCN] Carofiglio, G., Muscariello, L., Augé, J., Papalini, M., 886 Sardara, M., and A. Compagno, "Enabling ICN in the 887 Internet Protocol", DOI 10.1145/3357150.3357394, 888 Proceedings of the 6th ACM Conference on Information- 889 Centric Networking, September 2019, 890 . 892 [MAN] Baugher, M., Davie, B., Narayanan, A., and D. Oran, "Self- 893 verifying names for read-only named data", 894 DOI 10.1109/infcomw.2012.6193505, 2012 Proceedings IEEE 895 INFOCOM Workshops, March 2012, 896 . 898 [MIR] Garcia-Luna-Aceves, J., Martinez-Castillo, J., and R. 899 Menchaca-Mendez, "Routing to Multi-Instantiated 900 Destinations: Principles, Practice, and Applications", 901 DOI 10.1109/tmc.2017.2734658, IEEE Transactions on Mobile 902 Computing Vol. 17, pp. 1696-1709, July 2018, 903 . 905 [NDN] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., claffy, 906 k., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 907 "Named data networking", DOI 10.1145/2656877.2656887, ACM 908 SIGCOMM Computer Communication Review Vol. 44, pp. 66-73, 909 July 2014, . 911 [RAQ] Carofiglio, G., Gallo, M., Muscariello, L., Papalini, M., 912 and S. Wang, "Optimal multipath congestion control and 913 request forwarding in Information-Centric Networks", 914 DOI 10.1109/icnp.2013.6733576, 2013 21st IEEE 915 International Conference on Network Protocols (ICNP), 916 October 2013, . 918 [TRA] Sardara, M., Muscariello, L., and A. Compagno, "A 919 transport layer and socket API for (h)ICN", 920 DOI 10.1145/3267955.3267972, Proceedings of the 5th ACM 921 Conference on Information-Centric Networking, September 922 2018, . 924 [WLD] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 925 N., and X. Zeng, "Leveraging ICN In-network Control for 926 Loss Detection and Recovery in Wireless Mobile networks", 927 DOI 10.1145/2984356.2984361, Proceedings of the 2016 928 conference on 3rd ACM Conference on Information-Centric 929 Networking - ACM-ICN '16, 2016, 930 . 932 Authors' Addresses 934 Luca Muscariello 935 Cisco Systems Inc. 937 Email: lumuscar@cisco.com 939 Giovanna Carofiglio 940 Cisco Systems Inc. 942 Email: gcarofig@cisco.com 944 Jordan Augé 945 Cisco Systems Inc. 947 Email: augjorda@cisco.com 949 Michele Papalini 950 Cisco Systems Inc. 952 Email: micpapal@cisco.com 954 Mauro Sardara 955 Cisco Systems Inc. 957 Email: msardara@cisco.com