idnits 2.17.1 draft-muscariello-intarea-hicn-03.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 440 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 (October 30, 2019) is 1640 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 743 == Missing Reference: 'N' is mentioned on line 640, but not defined == Missing Reference: 'NumberOfEntries' is mentioned on line 750, but not defined == Unused Reference: 'WLD' is defined on line 914, 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 (~~), 6 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: May 2, 2020 M. Papalini 6 Cisco Systems Inc. 7 October 30, 2019 9 Hybrid Information-Centric Networking 10 draft-muscariello-intarea-hicn-03 12 Abstract 14 This document 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 May 2, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 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 . . . . . . . . . . . . . . . . . . . . . . 15 74 3. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4. The End-host model and End-to-End considerations . . . . . . 19 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 80 7.2. Informative References . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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. 90 The ICN reference design used in this document is CCNx as described 91 in [RFC8569] and [RFC8609]. IPv6 is used as described in [RFC8200]. 93 There are some basic design principles behind the hICN architecture 94 that are implemented by the design reported below that can be 95 summarized as follows: 97 o (i) the network can transport many different kinds of applications 98 as IPv6, i.e. hICN can serve content-distribution or real-time 99 applications, to cite examples with very different requirements. 100 hICN is not a content-distribution network; 102 o (ii) it provides connection-less and location independent 103 communications by identifying data with unique global names, 104 instead of naming network interfaces (locator) or end-hosts (end- 105 host identifiers) as in LISP [RFC6830]. 107 o (iii) data is retrieved by an end-point by issuing requests and a 108 node accepts a data packet from an ingress interface if and only 109 if at least one matching request packet is stored in the local 110 cache of the node, otherwise the data packet is dropped; 112 o (iv) basic security services are provided by the architecture: 113 authenticity of the data producer and data integrity. A 114 cryptographic signature over a security envelop is computed by the 115 producer (using its own private key) and must be verified by the 116 consumer (using the producer's public key). The security envelop 117 can be as small as a single data packet or cover groups of packets 118 using the technique of the transport manifest [MAN]. 120 1.1. Notational Conventions 122 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 123 document. It's not shouting; when these words are capitalized, they 124 have a special meaning as defined in [RFC2119]. 126 2. Architecture 127 +---------------------+ 128 | | Data packets 129 | End-host | +-----------+ +-----------+ 130 | +-------> | | | | 131 | +------------+ | | IPv6 | | hICN | 132 | | Producer | +-----------+ router +----------+ router | 133 | | end-point | | | | | | 134 | +------------+ | <------+ +----+------+ +------+----+ 135 | | | | 136 +---------------------+ Interest | | 137 packets | | 138 | | 139 | | 140 | | 141 +----+------+ +----+------+ 142 | | | | 143 | hICN | | IPv6 | 144 +----------------+ router +------------+ network | 145 + ^ | | | | | 146 | | | +-----------+ +--------+--+ 147 | | | | 148 v | | | 149 | | | 150 +---------------------+ Interest packets | 151 | +------------+ | +--------> +-----------+ | 152 | | Consumer | | | | | 153 | | end-point | +-----------------------+ hICN +-----+ 154 | +------------+ | | router | 155 | | <-------+ | | 156 | End-host | +-----------+ 157 | | Data packets 158 +---------------------+ 160 Figure 1: General overview of an hICN end-to-end communication. 162 The communication model described in this document covers the 163 transport and the network layer. 165 The network layer includes the forwarding plane only and does not 166 consider the routing plane. hICN network layer is about using the 167 IPv6 FIB to determine a next hop router to forward requests or using 168 a local packet cache to determine if an incoming request can be 169 satisfied locally. The hICN forwarding plane takes care of 170 forwarding replies by using information stored in cached requests. 171 The packet pipeline of an hICN node always includes a lookup in a 172 packet cache for both requests and replies. The packet cache is a 173 mandatory component that is added to the usual IPv6 packet processing 174 pipeline. Requests and replies carry an immutable data name end-to- 175 end, in packet header fields as described in the following sections. 176 Moreover, requests and replies carry locators as mutable packet 177 header fields. A locator, i.e. an interface identifier, is changed 178 every time a packet is sent to another hICN node. A detailed 179 description of how locators are modified along the path between end- 180 points is reported in the following sections. 182 It is assumed that existing routing protocols, working for IPv6, 183 should be reused as much as possible as they are. Improvements to 184 existing routing protocols are out of scope and might be developed in 185 other documents to better exploit features made available by the hICN 186 forwarding plane. For instance, hICN forwarding plane can take 187 advantage of the ability of a routing protocol to provide multiple 188 routes for a given destination or more generally compute routes for 189 destinations that are multi-instantiated [MIR]. This topic is 190 important but out of scope for this document. 192 The hICN network architecture can run on top of any link-layer that 193 supports IPv6. hICN data names are globally routable names which are 194 visible to the transport layer end-points. Conversely, the transport 195 layer has no visibility of addresses of network interfaces. The 196 network layer forwards two kinds of protocol data units: the request 197 and the reply, called interest and data packets. 199 The hICN network layer offers a communication service to the 200 transport layer in the end-points by means of a local unidirectional 201 channel that we call local or application face. This channel is used 202 by the transport layer to send requests and receive replies or to 203 send replies upon receptions of requests. 205 A transport end-point is always bound to a unidirectional channel 206 that is used to either send data or receive data. The former end- 207 point is called data producer while the latter data consumer. The 208 producer end-point produces data under a location independent name, 209 which is an IPv6 prefix. A consumer end-point fetches data by using 210 the non ambiguous name as provided by the producer. The producer 211 end-point is responsible for managing the usage of the prefix in 212 terms of provisioning, association to applications and its 213 revocation. 215 The transport end-point offers two kinds of services to applications: 216 a producer and a consumer service. The service is instantiated in 217 the application by opening communication sockets with an API to 218 perform basic transport service operations: allocation, 219 initialization, configuration, data transmission and reception. 221 The producer and consumer sockets can implement different types of 222 services such as stream or datagram, reliable or unreliable. In all 223 cases all transport services are connection-less, meaning that a 224 producer transport service produces named data in a socket memory 225 that is accessible by any valid request coming from one or multiple 226 consumers. The consumer, on the other hand, retrieve named data 227 using location independent names which are not tied to any interface 228 identifier (also called locator). This transport model allows to 229 implement reliable consumer mobility without any special mobility 230 management protocol. hICN supports communication of multi-homed end- 231 hosts without any special treatment in the transport layer. The hICN 232 network layer can also implement robust usage of multi-path 233 forwarding in IPv6 networks as balanced request/reply flows self- 234 stabilize network congestion see [CCN],[NDN], [RAQ] . 236 A data packet is an IPv6 packet with a transport layer header 237 carrying data from an application that produces data. An interest 238 packet is an IPv6 packet with a transport layer header and is used to 239 unambiguously fetch a data packet from a producer end point. 241 2.1. End-points 243 In hICN we introduce two new kinds of endpoints: the producer and the 244 consumer. We identify two kind of communication sockets each with a 245 specific API: the producer and consumer sockets. These socket types 246 are designed to exchange data in a multi-point to multi-point manner. 247 In (h)ICN we have the same concept that is applied to a network where 248 memories are distributed across the communication path. The first 249 memory in the path is the production buffer of the producer end-point 250 that forges Data Packets and copies them into a shared memory 251 isolated into a namespace. Consumer sockets can retrieve data from 252 such memory by using the (h)ICN network layer. The model just 253 described is an inter-process communication example (IPC) that 254 requires data to cross a communication network by using a transport 255 protocol. 257 The way consumers and producers synchronize depends on application 258 requirements and the transport layer exposes a variety of services: 259 stream/datagram, reliable/unreliable, with or without latency budgets 260 etc. Independently of the specific requirements of the applications, 261 producer sockets always perform data segmentation from the upper 262 layer into Data Packets, as well as compute digital signatures on the 263 packet security envelop. This envelop can also be computed across a 264 group of packets, by including a cryptographic hash of each packet 265 into the transport manifest, and eventually signing only such 266 manifest. 268 The consumer socket, on the other end, always performs reassembly of 269 Data Packets, hash integrity verification and signature verification. 270 This is common to all architectures in (h)ICN. The usual assumption 271 is that the producer socket uses an authentic-able identity while 272 using namespaces that it has been assigned. The end-point must be 273 able to manage the mapping of her identity and the allocated 274 namespace by issuing digital certificates about the mapping. The 275 consumer end-point must retrieve the associated certificate to 276 perform the basic operations. It is out of scope for this document 277 how to design and implement a scalable system to perform such 278 certificate operations. 280 A detailed description of transport end-points is out of scope for 281 this document. A detailed description of transport end-points is out 282 of scope for this document but more details can be found in [TRA]. 284 2.2. Naming 286 In hICN, two name components are defined: the name prefix and the 287 name suffix. The name prefix is used to identify an application 288 object, a service or in general an application level source of data 289 in the network. This is incarnated by a listening socket that binds 290 to the name prefix. The name suffix is used to index segmented data 291 within the scope of the name prefix used by the application. 293 For instance an RTP [RFC3550] source with a given SSRC can be mapped 294 into a name prefix. Single RTP sequence numbers can be mapped into 295 name suffixes. For example an HTTP server can listen to a name 296 prefix to serve HTTP requests. An HTTP reply with large payload with 297 require the transport layer to segment the application data unit 298 according to an MTU. Name suffixes are used to index each segment in 299 the socket stream. 301 More details about how to use hICN to transport HTTP or RTP will be 302 given in a different document. 304 2.2.1. Name prefix 306 The format of an hICN name prefix is the following: 308 | 64 bits | 64 bits | 309 +--------------------------------+-------------------------------+ 310 | routable prefix | data identifier | 311 +----------------------------------------------------------------+ 313 Figure 2: hICN IPv6 name prefix. 315 It is composed of a routable IPv6 /64 prefix as per [RFC3587] which 316 SHOULD be globally routable. The data identifier is encoded in 64 317 bits. An application can use several identifiers if needed. 319 From the description given above, the name prefix is a location 320 independent name encoded in an IPv6 address. 322 2.2.2. Name Suffix 324 The name suffix is used by the transport layer protocol to index 325 segments. The segment MUST be indexed in the end-points and in the 326 network with the same suffix. This implies that there is one 327 transport segment per IP packet and that IP fragmentation is not 328 allowed. Extension to allow secure fragmentation are possible, such 329 as [FRA] but they are out of scope for this document. It is up to 330 the producer end-point to determine how to perform segmentation 331 depending on the use case. An MTU path discovery protocol for hICN 332 is out of scope of this document and additional work is required to 333 extend existing protocols or design new ones. 335 | 32 bits | 336 +----------------------------- 337 | name suffix | 338 +----------------------------- 340 Figure 3: hICN name suffix. 342 2.3. Packet Format 344 Two protocol data units are defined below: the interest (request) and 345 the data (reply). 347 They are composed of a network and transport header. The transport 348 header is the same for both packet types while the network header is 349 slightly different. 351 2.3.1. Interest Packet 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |Version| Traffic Class | Flow Label | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Payload Length | Next Header | Hop Limit | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 + + 361 | | 362 + Source Address + 363 | | 364 + + 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 + + 369 | | 370 + Name Prefix + 371 | | 372 + + 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Interest Packet Header Format 377 Figure 4: IPv6 interest packet L3 header. 379 Source Address: 128-bit address of the originator of the packet 380 (possibly not the end-host but a previous hICN node). 382 Name Prefix: 128-bit name prefix of the intended service. 384 2.3.2. Data Packet 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |Version| Traffic Class | Flow Label | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Payload Length | Next Header | Hop Limit | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 + + 394 | | 395 + Name Prefix + 396 | | 397 + + 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | 401 + + 402 | | 403 + Destination Address + 404 | | 405 + + 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Data Packet Header Format 410 Figure 5: IPv6 data packet L3 header. 412 Name Prefix: 128-bit name prefix of the intended service. 414 Source Address: 128-bit address of the destination of the packet 415 (possibly not the end-host but the next hICN node). 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Source Port | Destination Port | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Name Suffix | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Path Label | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Data | Time |M|A|S|R|S|F| Loss Detection | 427 | Offset| Scale |A|C|I|S|Y|I| and Recovery | 428 | | |N|K|G|T|N|N| | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Checksum | Lifetime | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 6: Transport header for data and interest packets. 435 Name Suffix: 32-bit name-suffix of the packet 436 (possibly not the end-host but a previous hICN node). 438 Path Label: 32-bit label used to carry an encoding of the path 439 between the consumer and data responder, be it an 440 intermediate node or the producer end-point. 442 Time Scale: 6-bit natural number in the range 1-64 used as a scaling 443 factor for time calculations. If not null it is used 444 to scale lifetime. 446 Manifest: flag to indicate the packet carries a transport manifest 447 in the payload. 449 Signature: flag to indicate the packet carries an authentication 450 header with a signature. Interest packet do not carry 451 signatures. 453 Loss Detection: 16-bit natural number used to implement data 454 and Recovery sequencing on per adjacency basis to detect an 455 recover losses using the mechanism WLDR described 456 in {{WLD}}. 458 Lifetime: 16-bit unsigned integer to carry the packet lifetime in 459 milliseconds. 461 Checksum: Updated using RFC 1624. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Source Port | Destination Port | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Length | Checksum | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Name Suffix | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Path Label | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Data | Time |M|A|S|R|S|F| Loss Detection | 475 | Offset| Scale |A|C|I|S|Y|I| and Recovery | 476 | | |N|K|G|T|N|N| | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Checksum | Lifetime | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 7: Transport header for data and interest packets using UDP 482 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 538 destination address with I's source address. D is passed to the 539 egress to further processing before transmission. For instance 540 the next-hop MAY be selected by using the router IPv6 FIB 541 (longest prefix match). The IPv6 FIB lookup MIGHT be saved in 542 case the next-hop can be derived directly from information 543 previously derived by processing the incoming interest packet I. 544 I is eventually dropped. 546 1.2. There is one or multiple matches and all are interest 547 packets. 549 * One matching interest has the same source address and I is 550 classified as duplicate and further processed as duplicate. 552 * Matching interest packets have different source addresses and 553 I is classified as filtered and stored in the cache. 555 2. a match is not found and I passed to the egress for further 556 processing to determine the next-hop by using the router IP FIB. 558 Notice that the destination address field in the interest packet is 559 polymorphic as it has two different types based on the data 560 structured it is looked-up against. It has the type of a location 561 independent name while used to find a match in the packet cache and 562 it has an address prefix type to find the next-hop in the IPv6 FIB. 563 Polymorphism is transparent for the forwarding plane while it has 564 several implications in the control plane. 566 Packet Cache 567 RX +------------+ 568 Interest | | Translation Operation 569 +---------> Data Hit | IPv6Hdr(Data).DstAddr:= IPv6Hdr(Interest).SrcAddr 570 TX | + | 571 Data | | | 572 <---------+ <----+ | 573 +------------+ 575 Figure 8: The interest packet hits a matching data packet in the 576 packet cache. 578 +----------------+ +--------+ 579 Interest | | | | Egress NIC 580 +-------> Data Miss +--->+ IP FIB |+-----> 581 | | | | Translation Operation 582 | Interest Miss | | | IPv6Hdr(Interest).SrcAddr:= NIC.Addr 583 | | | | 584 +----------------+ +--------+ 586 Figure 9: The interest packet finds no match in the packet cache and 587 is processed to find a next-hop. 589 Same src addr 590 Packet Cache +-----------+ 591 +--------------+ | Duplicate | 592 Interest | | +-----^-----+ 593 +-------> Data Miss | | 594 | Interest Hit +-------------->-+ 595 | | | 596 +--------------+ | 597 +-----v-----+ 598 |Filtered | 599 +-----------+ 600 Different src addr 602 Figure 10: The interest packet hits an interest packet in the packet 603 cache. 605 2.5.2. Data Path 607 At the router ingress the incoming data packet D is parsed to obtain 608 the name prefix and the name suffix. An exact match look up is made 609 in the packet cache using the full packet name as key. Based on the 610 outcome of the lookup the following options are possible: 612 1. one or multiple matching interest packets are found 1.1. The 613 data packet D is cloned to have as many copies as the number of 614 matching interests including D. The destination address field of 615 each copy of D is set with the source address field of each 616 interest packet. All copies are passed to the egress to further 617 processing before transmission in order to find each data 618 packet's next-hop. 620 2. No matching is an interest packet and the D is dropped. 622 RX 623 Data +-----------+ 624 +--------> | Interest | 625 | Hit | 626 | + | 627 +-----------+ 628 | 629 | 630 | 631 | Translation Operation 632 | +------> 633 | | IPv6Hdr(Data[1]).DstAddr:=IPv6Hdr(Interest[1]).SrcAddr 634 | | TX Data[1] 635 +-----> | 636 | ... 637 | 638 | 639 | IPv6Hdr(Data[N]).DstAddr:=IPv6Hdr(Interest[N]).SrcAddr 640 | TX Data[N] 641 +------> 643 Figure 11: The data packet hits an interest packet in the packet 644 cache. 646 RX Packet Cache 647 Data +------------------+ Drop Data 648 +---------->+ Interest Miss +------> 649 | OR Data hit | 650 +------------------+ 652 Figure 12: The data packet is drop in case no interest match is found 653 in the packet cache. 655 3. Security 657 hICN inherits ICN data-centric security model: integrity, data-origin 658 authenticity and confidentiality are tied to the content rather than 659 to the channel. 660 Integrity and data-origin authenticity are provided through a digital 661 signature computed by the producer and included in each data packet. 662 Integrity and data-origin authenticity are provided in two ways using 663 two approaches: the first one based on IP Authenticated Header 664 [RFC4302] and the second one based on transport manifests. Notice 665 that the IP AH is not used as an IPv6 extension header as it is 666 appended after the transport header. However the choice of the IP AH 667 has been made in order to exploit existing protocol implementations 668 in the end-points. 670 When using IP AH, the signature is computed over 672 o (i)IP or extension header fields either immutable in transit or 673 that are predictable in value upon arrival at the consumer, 675 o (ii) the AH header with the signature field set to zero. We 676 recall that in hICN the destination header field is not immutable 677 nor predictable and must be set to zero for the signature 678 computation. We also point out the AH in placed after the TCP 679 header in order to prevent any kind of filtering from network 680 devices such as middleboxes. 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Next Header | Payload Len | ValidAlg | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Timestamp | 688 | | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 / / 691 / KeyID / 692 / / 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 / / 695 / Signature / 696 / / 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 Figure 13: The IP authentication header appended after the transport 700 header to carry packet signatures. 702 ValidAlg: 8-bit index to indicate which validation algorithm 703 must be used to verify the signature. 705 Timestamp: 64-bit time stamp that indicates the validity of the 706 signature. 708 KeyID: 256-bit key identifier. 710 Signature: Variable length field that carries the cryptographic 711 signature of the security envelope. 712 It is 128 bytes for RSA-1024, 256 bytes for RSA-2048, 713 56 bytes for EDCSA 192, 72 bytes for ECDSA 256. 715 The transport manifest is a L4 entity computed at the producer which 716 contains the list of names of a group of data packets to convey to 717 the consumer. hICN cryptographic hashes of data packets are then 718 computed instead of signatures. The hashes are computed on immutable 719 fields as explained above when using the IP AH. Moreover, the 720 manifest must be signed to guarantee a level of security equivalent 721 to packet-wise signatures. When the producer uses the manifest data 722 packets do not carry the AH which is carried by the transport 723 manifest only. 725 hICN is oblivious of the trust model adopted by consumers and works 726 with any of the existing proposals. 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |Version| MType |HashAlg|NextStr| Flags |NumberOfEntries| 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | | 734 + + 735 | | 736 + Prefix + 737 | | 738 + + 739 | | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Name-suffix[1] | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Hash Value[1] | 744 | | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 . . . 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Name-suffix[NumberOfEntries] | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Hash Value [NumberOfEntries] | 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Figure 14: The transport manifest, generated by the producer end- 755 point for the consumer end-point, contains names, integrity hashes 756 and is signed with the producer end-point private key 758 Version: 8-bit index to indicate which validation algorithm 759 must be used to verify the signature. 761 MType: 64-bit time stamp that indicates the validity of the 762 signature. 764 HashAlg: 256-bit key identifier. 766 NextStr: Encode an operator use to predict the name-suffix 767 sequence 769 Flags: Flags. 771 NumberOfEntries: 8-bit field that encodes the number of packets indexed 772 in the manifest. 774 Name-prefix: 128-bit field carrying the name-prefix common to all 775 packets indexed in the manifest. 777 Name-suffix: 32-bit field carrying the name-suffix. 779 Hash-value: 256-bit field carrying the SHA-256 hash of the packet 780 security envelop. 782 4. The End-host model and End-to-End considerations 784 In hICN the end-host model is very similar to a regular IPv6 end-host 785 with some extensions. An end-host is capable of opening consumer and 786 producer transport end-points, one to receive data and one to send 787 data under a given name prefix. The end-host continues to identify 788 interfaces using IPv6 addresses (locators or routing locators, RLOCs, 789 using LISP terminology), just like any IPv6 router. In addition to 790 that, transport end-points bind to location-independent names, 791 similar to LISP end-point identifiers (EIDs). However, instead of 792 using name prefixes to identify end-hosts only, in hICN a name prefix 793 is used to identify a data source. 795 There is an analogy between IPv6 multicast and the hICN data 796 forwarding path for one-to-many communications, as the IPv6 multicast 797 group address identifies data that group members receive from a 798 single sender. Notice that in hICN a data packet transmission stores 799 the identifiers in the source address field while in IPv6 multicast 800 it is stored in the destination address field. 802 Theres is also an analogy between IPv6 anycast and the hICN interest 803 forwarding path, where multiple interfaces make use of the same IPv6 804 (anycast) address. Multiple instances of the same applications can 805 then run at different end-points to eventually reply to the same 806 request. 808 An hICN network node behaves as an end-host consumer end-point for 809 the upstream producer end-point as all replies are forced to flow 810 back to the same hICN that transmitted the requests. An hICN network 811 node may be able to reply to a request on behalf of a end-point 812 producer, in that case that hICN node behaves as an end-host for the 813 consumer end-point. 815 5. IANA Considerations 817 There are no IANA considerations in this specification. 819 6. Acknowledgements 821 The authors would like to thank David Ward, David Oran, Paul Polakos, 822 Mark Townsley, Mauro Sardara and Alberto Compagno for suggestions on 823 how to improve the architecture and the current document. 825 7. References 827 7.1. Normative References 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, 831 DOI 10.17487/RFC2119, March 1997, 832 . 834 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 835 Label Switching Architecture", RFC 3031, 836 DOI 10.17487/RFC3031, January 2001, 837 . 839 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 840 Jacobson, "RTP: A Transport Protocol for Real-Time 841 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 842 July 2003, . 844 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 845 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 846 August 2003, . 848 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 849 DOI 10.17487/RFC4302, December 2005, 850 . 852 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 853 Locator/ID Separation Protocol (LISP)", RFC 6830, 854 DOI 10.17487/RFC6830, January 2013, 855 . 857 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 858 (IPv6) Specification", STD 86, RFC 8200, 859 DOI 10.17487/RFC8200, July 2017, 860 . 862 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 863 Networking (CCNx) Semantics", RFC 8569, 864 DOI 10.17487/RFC8569, July 2019, 865 . 867 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 868 Networking (CCNx) Messages in TLV Format", RFC 8609, 869 DOI 10.17487/RFC8609, July 2019, 870 . 872 7.2. Informative References 874 [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 875 Briggs, N., and R. Braynard, "Networking named content", 876 Proceedings of the 5th international conference on 877 Emerging networking experiments and technologies - 878 CoNEXT '09, DOI 10.1145/1658939.1658941, 2009. 880 [FRA] Mosko, M. and C. Wood, "Secure Fragmentation for Content 881 Centric Networking", 2015 IEEE 12th International 882 Conference on Mobile Ad Hoc and Sensor Systems, 883 DOI 10.1109/mass.2015.51, October 2015. 885 [MAN] Baugher, M., Davie, B., Narayanan, A., and D. Oran, "Self- 886 verifying names for read-only named data", 2012 887 Proceedings IEEE INFOCOM Workshops, 888 DOI 10.1109/infcomw.2012.6193505, March 2012. 890 [MIR] Garcia-Luna-Aceves, J., Martinez-Castillo, J., and R. 891 Menchaca-Mendez, "Routing to Multi-Instantiated 892 Destinations: Principles, Practice, and Applications", 893 IEEE Transactions on Mobile Computing Vol. 17, pp. 894 1696-1709, DOI 10.1109/tmc.2017.2734658, July 2018. 896 [NDN] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., claffy, 897 k., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 898 "Named data networking", ACM SIGCOMM Computer 899 Communication Review Vol. 44, pp. 66-73, 900 DOI 10.1145/2656877.2656887, July 2014. 902 [RAQ] Carofiglio, G., Gallo, M., Muscariello, L., Papalini, M., 903 and S. Wang, "Optimal multipath congestion control and 904 request forwarding in Information-Centric Networks", 2013 905 21st IEEE International Conference on Network 906 Protocols (ICNP), DOI 10.1109/icnp.2013.6733576, October 907 2013. 909 [TRA] Sardara, M., Muscariello, L., and A. Compagno, "A 910 transport layer and socket API for (h)ICN", Proceedings of 911 the 5th ACM Conference on Information-Centric Networking - 912 ICN '18, DOI 10.1145/3267955.3267972, 2018. 914 [WLD] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 915 N., and X. Zeng, "Leveraging ICN In-network Control for 916 Loss Detection and Recovery in Wireless Mobile networks", 917 Proceedings of the 2016 conference on 3rd ACM Conference 918 on Information-Centric Networking - ACM-ICN '16, 919 DOI 10.1145/2984356.2984361, 2016. 921 Authors' Addresses 923 Luca Muscariello 924 Cisco Systems Inc. 926 Email: lumuscar@cisco.com 928 Giovanna Carofiglio 929 Cisco Systems Inc. 931 Email: gcarofig@cisco.com 933 Jordan Auge 934 Cisco Systems Inc. 936 Email: augjorda@cisco.com 937 Michele Papalini 938 Cisco Systems Inc. 940 Email: mpapal@cisco.com