idnits 2.17.1 draft-muscariello-intarea-hicn-02.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 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 (June 06, 2019) is 1785 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 744 == Missing Reference: 'N' is mentioned on line 641, but not defined == Missing Reference: 'NumberOfEntries' is mentioned on line 751, but not defined == Unused Reference: 'WLD' is defined on line 915, 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: December 8, 2019 M. Papalini 6 Cisco Systems Inc. 7 June 06, 2019 9 Hybrid Information-Centric Networking 10 draft-muscariello-intarea-hicn-02 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 8, 2019. 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 [I-D.irtf-icnrg-ccnxsemantics] and [I-D.irtf-icnrg-ccnxmessages]. 92 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 o (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 o (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 o (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 o (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. 166 The network layer includes the forwarding plane only and does not 167 consider the routing plane. hICN network layer is about using the 168 IPv6 FIB to determine a next hop router to forward requests or using 169 a local packet cache to determine if an incoming request can be 170 satisfied locally. The hICN forwarding plane takes care of 171 forwarding replies by using information stored in cached requests. 172 The packet pipeline of an hICN node always includes a lookup in a 173 packet cache for both requests and replies. The packet cache is a 174 mandatory component that is added to the usual IPv6 packet processing 175 pipeline. Requests and replies carry an immutable data name end-to- 176 end, in packet header fields as described in the following sections. 177 Moreover, requests and replies carry locators as mutable packet 178 header fields. A locator, i.e. an interface identifier, is changed 179 every time a packet is sent to another hICN node. A detailed 180 description of how locators are modified along the path between end- 181 points is reported in the following sections. 183 It is assumed that existing routing protocols, working for IPv6, 184 should be reused as much as possible as they are. Improvements to 185 existing routing protocols are out of scope and might be developed in 186 other documents to better exploit features made available by the hICN 187 forwarding plane. For instance, hICN forwarding plane can take 188 advantage of the ability of a routing protocol to provide multiple 189 routes for a given destination or more generally compute routes for 190 destinations that are multi-instantiated [MIR]. This topic is 191 important but out of scope for this document. 193 The hICN network architecture can run on top of any link-layer that 194 supports IPv6. hICN data names are globally routable names which are 195 visible to the transport layer end-points. Conversely, the transport 196 layer has no visibility of addresses of network interfaces. The 197 network layer forwards two kind of protocol data units: the request 198 and the reply, called interest and data packets. 200 The hICN network layer offers a communication service to the 201 transport layer in the end-points by means of a local unidirectional 202 channel that we call local or application face. This channel is used 203 by the transport layer to send requests and receive replies or to 204 send replies upon receptions of requests. 206 A transport end-point is always bound to a unidirectional channel 207 that is used to either send data or receive data. The former end- 208 point is called data producer while the latter data consumer. The 209 producer end-point produces data under a location independent name, 210 which is an IPv6 prefix. A consumer end-point fetches data by using 211 the non ambiguous name as provided by the producer. The producer 212 end-point is responsible for managing the usage of the prefix in 213 terms of provisioning, association to applications and its 214 revocation. 216 The transport end-point offers two kinds of services to applications: 217 a producer and a consumer service. The service is instantiated in 218 the application by opening communication sockets with an API to 219 perform basic transport service operations: allocation, 220 initialization, configuration, data transmission and reception. 222 The producer and consumer sockets can implement different types of 223 services such as stream or datagram, reliable or unreliable. In all 224 cases all transport services are connection-less, meaning that a 225 producer transport service produces named data in a socket memory 226 that is accessible by any valid request coming from one or multiple 227 consumers. The consumer, on the other hand, retrieve named data 228 using location independent names which are not tied to any interface 229 identifier (also called locator). This transport model allows to 230 implement reliable consumer mobility without any special mobility 231 management protocol. hICN supports communication of multi-homed end- 232 hosts without any special treatment in the transport layer. The hICN 233 network layer can also implement robust usage of multi-path 234 forwarding in IPv6 networks as balanced request/reply flows self- 235 stabilize network congestion see [CCN],[NDN], [RAQ] . 237 A data packet is an IPv6 packet with a transport layer header 238 carrying data from an application that produces data. An interest 239 packet is an IPv6 packet with a transport layer header and is used to 240 unambiguously fetch a data packet from a producer end point. 242 2.1. End-points 244 In hICN we introduce two new kinds of endpoints: the producer and the 245 consumer. We identify two kind of communication sockets each with a 246 specific API: the producer and consumer sockets. These socket types 247 are designed to exchange data in a multi-point to multi-point manner. 248 In (h)ICN we have the same concept that is applied to a network where 249 memories are distributed across the communication path. The first 250 memory in the path is the production buffer of the producer end-point 251 that forges Data Packets and copies them into a shared memory 252 isolated into a namespace. Consumer sockets can retrieve data from 253 such memory by using the (h)ICN network layer. The model just 254 described is an inter-process communication example (IPC) that 255 requires data to cross a communication network by using a transport 256 protocol. 258 The way consumers and producers synchronize depends on application 259 requirements and the transport layer exposes a variety of services: 260 stream/datagram, reliable/unreliable, with or without latency budgets 261 etc. Independently of the specific requirements of the applications, 262 producer sockets always perform data segmentation from the upper 263 layer into Data Packets, as well as compute digital signatures on the 264 packet security envelop. This envelop can also be computed across a 265 group of packets, by including a cryptographic hash of each packet 266 into the transport manifest, and eventually signing only such 267 manifest. 269 The consumer socket, on the other end, always performs reassembly of 270 Data Packets, hash integrity verification and signature verification. 271 This is common to all architectures in (h)ICN. The usual assumption 272 is that the producer socket uses an authentic-able identity while 273 using namespaces that it has been assigned. The end-point must be 274 able to manage the mapping of her identity and the allocated 275 namespace by issuing digital certificates about the mapping. The 276 consumer end-point must retrieve the associated certificate to 277 perform the basic operations. It is out of scope for this document 278 how to design and implement a scalable system to perform such 279 certificate operations. 281 A detailed description of transport end-points is out of scope for 282 this document. A detailed description of transport end-points is out 283 of scope for this document but more details can be found in [TRA]. 285 2.2. Naming 287 In hICN, two name components are defined: the name prefix and the 288 name suffix. The name prefix is used to identify an application 289 object, a service or in general an application level source of data 290 in the network. This is incarnated by a listening socket that binds 291 to the name prefix. The name suffix is used to index segmented data 292 within the scope of the name prefix used by the application. 294 For instance an RTP [RFC3550] source with a given SSRC can be mapped 295 into a name prefix. Single RTP sequence numbers can be mapped into 296 name suffixes. For example an HTTP server can listen to a name 297 prefix to serve HTTP requests. An HTTP reply with large payload with 298 require the transport layer to segment the application data unit 299 according to an MTU. Name suffixes are used to index each segment in 300 the socket stream. 302 More details about how to use hICN to transport HTTP or RTP will be 303 given in a different document. 305 2.2.1. Name prefix 307 The format of an hICN name prefix is the following: 309 | 64 bits | 64 bits | 310 +--------------------------------+-------------------------------+ 311 | routable prefix | data identifier | 312 +----------------------------------------------------------------+ 314 Figure 2: hICN IPv6 name prefix. 316 It is composed of a routable IPv6 /64 prefix as per [RFC3587] which 317 SHOULD be globally routable. The data identifier is encoded in 64 318 bits. An application can use several identifiers if needed. 320 From the description given above, the name prefix is a location 321 independent name encoded in an IPv6 address. 323 2.2.2. Name Suffix 325 The name suffix is used by the transport layer protocol to index 326 segments. The segment MUST be indexed in the end-points and in the 327 network with the same suffix. This implies that there is one 328 transport segment per IP packet and that IP fragmentation is not 329 allowed. Extension to allow secure fragmentation are possible, such 330 as [FRA] but they are out of scope for this document. It is up to 331 the producer end-point to determine how to perform segmentation 332 depending on the use case. An MTU path discovery protocol for hICN 333 is out of scope of this document and additional work is required to 334 extend existing protocols or design new ones. 336 | 32 bits | 337 +----------------------------- 338 | name suffix | 339 +----------------------------- 341 Figure 3: hICN name suffix. 343 2.3. Packet Format 345 Two protocol data units are defined below: the interest (request) and 346 the data (reply). 348 They are composed of a network and transport header. The transport 349 header is the same for both packet types while the network header is 350 slightly different. 352 2.3.1. Interest Packet 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 |Version| Traffic Class | Flow Label | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Payload Length | Next Header | Hop Limit | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 + + 362 | | 363 + Source Address + 364 | | 365 + + 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 + + 370 | | 371 + Name Prefix + 372 | | 373 + + 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Interest Packet Header Format 378 Figure 4: IPv6 interest packet L3 header. 380 Source Address: 128-bit address of the originator of the packet 381 (possibly not the end-host but a previous hICN node). 383 Name Prefix: 128-bit name prefix of the intended service. 385 2.3.2. Data Packet 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |Version| Traffic Class | Flow Label | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Payload Length | Next Header | Hop Limit | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 + + 395 | | 396 + Name Prefix + 397 | | 398 + + 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | | 402 + + 403 | | 404 + Source Address + 405 | | 406 + + 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Interest Packet Header Format 411 Figure 5: IPv6 data packet L3 header. 413 Name Prefix: 128-bit name prefix of the intended service. 415 Source Address: 128-bit address of the destination of the packet 416 (possibly not the end-host but the next hICN node). 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Source Port | Destination Port | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Name Suffix | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Path Label | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Data | Time |M|A|S|R|S|F| Loss Detection | 428 | Offset| Scale |A|C|I|S|Y|I| and Recovery | 429 | | |N|K|G|T|N|N| | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Checksum | Lifetime | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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|R|S|F| Loss Detection | 476 | Offset| Scale |A|C|I|S|Y|I| and Recovery | 477 | | |N|K|G|T|N|N| | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Checksum | Lifetime | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 7: Transport header for data and interest packets using UDP 483 header. 485 Both transport headers can be used to carry name suffix information. 487 The following sections describe the components of an hICN node and 488 the packet processing operations. 490 2.4. Packet cache 492 The packet cache is a router local memory used to temporarily store 493 requests and reply. The simplest incarnation of the packet cache 494 MUST index packets by full name, i.e. the concatenation of the name 495 prefix and suffix. Insertion and deletion of packets in the cache is 496 described below. 498 2.5. Forwarding 500 The forwarding path in hICN is composed of two components: the 501 interest and data path. Requests and replies are processed at the 502 hICN node in a different way. Both forwarding paths require a packet 503 cache to be incorporated into the router. The cache is used to 504 temporarily store requests and replies for a relatively short amount 505 of time. 507 By caching a request in an hICN node, the reply can be transmitted 508 back to the right nodes as the source address field in the interest 509 contains the interface identifier of the hICN node having transmitted 510 the request. Replies are optionally cached if needed. 512 This means that the interest forwarding path is based on lookups in 513 the IP FIB just like any other IP packet, with the additional 514 processing due to a cache lookup to check if the actual reply is 515 already present in the local cache for expedited reply. 517 On the other hand, data packet forwarding is similar to label 518 swapping [RFC3031], being the packet name identifier (prefix plus 519 suffix) the forwarding label. The next hop for the reply in transit 520 is indeed selected by using information in a cached matching request. 522 The name prefix in the packet header is never modified along the path 523 for both requests and replies, while the locator, i.e. the interface 524 identifier written in the source or destination address field, for 525 interest or data packets respectively, is modified at the egress of 526 the router as reported below. 528 2.5.1. Interest Path 530 At the router ingress the incoming interest packet I is parsed to 531 obtain the name prefix and the name suffix. An exact match look up 532 is made in the packet cache using the full packet name as key. Based 533 on the outcome of the lookup the following options are possible: 535 1. at least one match is found. 537 1.1. If one match is a data packet D, other matches are ignored, 538 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 and 588 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 packet 604 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 found 654 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. 661 Integrity and data-origin authenticity are provided through a digital 662 signature computed by the producer and included in each data packet. 663 Integrity and data-origin authenticity are provided in two ways using 664 two approaches: the first one based on IP Authenticated Header 665 [RFC4302] and the second one based on transport manifests. Notice 666 that the IP AH is not used as an IPv6 extension header as it is 667 appended after the transport header. However the choice of the IP AH 668 has been made in order to exploit existing protocol implementations 669 in the end-points. 671 When using IP AH, the signature is computed over 673 o (i)IP or extension header fields either immutable in transit or 674 that are predictable in value upon arrival at the consumer, 676 o (ii) the AH header with the signature field set to zero. We 677 recall that in hICN the destination header field is not immutable 678 nor predictable and must be set to zero for the signature 679 computation. We also point out the AH in placed after the TCP 680 header in order to prevent any kind of filtering from network 681 devices such as middleboxes. 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Next Header | Payload Len | ValidAlg | | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Timestamp | 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 / / 692 / KeyID / 693 / / 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 / / 696 / Signature / 697 / / 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 Figure 13: The IP authentication header appended after the transport 701 header to carry packet signatures. 703 ValidAlg: 8-bit index to indicate which validation algorithm 704 must be used to verify the signature. 706 Timestamp: 64-bit time stamp that indicates the validity of the 707 signature. 709 KeyID: 256-bit key identifier. 711 Signature: Variable length field that carries the cryptographic 712 signature of the security envelope. 713 It is 128 bytes for RSA-1024, 256 bytes for RSA-2048, 714 56 bytes for EDCSA 192, 72 bytes for ECDSA 256. 716 The transport manifest is a L4 entity computed at the producer which 717 contains the list of names of a group of data packets to convey to 718 the consumer. hICN cryptographic hashes of data packets are then 719 computed instead of signatures. The hashes are computed on immutable 720 fields as explained above when using the IP AH. Moreover, the 721 manifest must be signed to guarantee a level of security equivalent 722 to packet-wise signatures. When the producer uses the manifest data 723 packets do not carry the AH which is carried by the transport 724 manifest only. 726 hICN is oblivious of the trust model adopted by consumers and works 727 with any of the existing proposals. 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 |Version| MType |HashAlg|NextStr| Flags |NumberOfEntries| 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | | 735 + + 736 | | 737 + Prefix + 738 | | 739 + + 740 | | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Name-suffix[1] | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Hash Value[1] | 745 | | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 . . . 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Name-suffixv[NumberOfEntries] | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Hash Value [NumberOfEntries] | 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 14: The transport manifest, generated by the producer end- 756 point for the consumer end-point, contains names, integrity hashes 757 and is signed with the producer end-point private key 759 Version: 8-bit index to indicate which validation algorithm 760 must be used to verify the signature. 762 MType: 64-bit time stamp that indicates the validity of the 763 signature. 765 HashAlg: 256-bit key identifier. 767 NextStr: Encode an operator use to predict the name-suffix 768 sequence 770 Flags: Flags. 772 NumberOfEntries: 8-bit field that encodes the number of packets indexed 773 in the manifest. 775 Name-prefix: 128-bit field carrying the name-prefix common to all 776 packets indexed in the manifest. 778 Name-suffix: 32-bit field carrying the name-suffix. 780 Hash-value: 256-bit field carrying the SHA-256 hash of the packet 781 security envelop. 783 4. The End-host model and End-to-End considerations 785 In hICN the end-host model is very similar to a regular IPv6 end-host 786 with some extensions. An end-host is capable of opening consumer and 787 producer transport end-points, one to receive data and one to send 788 data under a given name prefix. The end-host continues to identify 789 interfaces using IPv6 addresses (locators or routing locators, RLOCs, 790 using LISP terminology), just like any IPv6 router. In addition to 791 that, transport end-points bind to location-independent names, 792 similar to LISP end-point identifiers (EIDs). However, instead of 793 using name prefixes to identify end-hosts only, in hICN a name prefix 794 is used to identifity a data source. 796 There is an analogy between IPv6 multicast and the hICN data 797 forwarding path for one-to-many communications, as the IPv6 multicast 798 group address identifies data that group members receive from a 799 single sender. Notice that in hICN a data packet transmission stores 800 the identifiers in the source address field while in IPv6 multicast 801 it is stored in the destination address field. 803 Theres is also an analogy between IPv6 anycast and the hICN interest 804 forwarding path, where multiple interfaces make use of the same IPv6 805 (anycast) address. Multiple instances of the same applications can 806 then run at different end-points to eventually reply to the same 807 request. 809 An hICN network node behaves as an end-host consumer end-point for 810 the upstream producer end-point as all replies are forced to flow 811 back to the same hICN that transmitted the requests. An hICN network 812 node may be able to reply to a request on behalf of a end-point 813 producer, in that case that hICN node behaves as an end-host for the 814 consumer end-point. 816 5. IANA Considerations 818 There are no IANA considerations in this specification. 820 6. Acknowledgements 822 The authors would like to thank David Ward, David Oran, Paul Polakos, 823 Mark Townsley, Mauro Sardara and Alberto Compagno for suggestions on 824 how to improve the architecture and the current document. 826 7. References 828 7.1. Normative References 830 [I-D.irtf-icnrg-ccnxmessages] 831 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 832 Format", draft-irtf-icnrg-ccnxmessages-09 (work in 833 progress), January 2019. 835 [I-D.irtf-icnrg-ccnxsemantics] 836 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 837 draft-irtf-icnrg-ccnxsemantics-10 (work in progress), 838 January 2019. 840 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 841 Requirement Levels", BCP 14, RFC 2119, 842 DOI 10.17487/RFC2119, March 1997, 843 . 845 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 846 Label Switching Architecture", RFC 3031, 847 DOI 10.17487/RFC3031, January 2001, 848 . 850 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 851 Jacobson, "RTP: A Transport Protocol for Real-Time 852 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 853 July 2003, . 855 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 856 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 857 August 2003, . 859 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 860 DOI 10.17487/RFC4302, December 2005, 861 . 863 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 864 Locator/ID Separation Protocol (LISP)", RFC 6830, 865 DOI 10.17487/RFC6830, January 2013, 866 . 868 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 869 (IPv6) Specification", STD 86, RFC 8200, 870 DOI 10.17487/RFC8200, July 2017, 871 . 873 7.2. Informative References 875 [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 876 Briggs, N., and R. Braynard, "Networking named content", 877 Proceedings of the 5th international conference on 878 Emerging networking experiments and technologies - 879 CoNEXT '09, DOI 10.1145/1658939.1658941, 2009. 881 [FRA] Mosko, M. and C. Wood, "Secure Fragmentation for Content 882 Centric Networking", 2015 IEEE 12th International 883 Conference on Mobile Ad Hoc and Sensor Systems, 884 DOI 10.1109/mass.2015.51, October 2015. 886 [MAN] Baugher, M., Davie, B., Narayanan, A., and D. Oran, "Self- 887 verifying names for read-only named data", 2012 888 Proceedings IEEE INFOCOM Workshops, 889 DOI 10.1109/infcomw.2012.6193505, March 2012. 891 [MIR] Garcia-Luna-Aceves, J., Martinez-Castillo, J., and R. 892 Menchaca-Mendez, "Routing to Multi-Instantiated 893 Destinations: Principles, Practice, and Applications", 894 IEEE Transactions on Mobile Computing Vol. 17, pp. 895 1696-1709, DOI 10.1109/tmc.2017.2734658, July 2018. 897 [NDN] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., claffy, 898 k., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 899 "Named data networking", ACM SIGCOMM Computer 900 Communication Review Vol. 44, pp. 66-73, 901 DOI 10.1145/2656877.2656887, July 2014. 903 [RAQ] Carofiglio, G., Gallo, M., Muscariello, L., Papalini, M., 904 and S. Wang, "Optimal multipath congestion control and 905 request forwarding in Information-Centric Networks", 2013 906 21st IEEE International Conference on Network 907 Protocols (ICNP), DOI 10.1109/icnp.2013.6733576, October 908 2013. 910 [TRA] Sardara, M., Muscariello, L., and A. Compagno, "A 911 transport layer and socket API for (h)ICN", Proceedings of 912 the 5th ACM Conference on Information-Centric Networking - 913 ICN '18, DOI 10.1145/3267955.3267972, 2018. 915 [WLD] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 916 N., and X. Zeng, "Leveraging ICN In-network Control for 917 Loss Detection and Recovery in Wireless Mobile networks", 918 Proceedings of the 2016 conference on 3rd ACM Conference 919 on Information-Centric Networking - ACM-ICN '16, 920 DOI 10.1145/2984356.2984361, 2016. 922 Authors' Addresses 924 Luca Muscariello 925 Cisco Systems Inc. 927 Email: lumuscar@cisco.com 929 Giovanna Carofiglio 930 Cisco Systems Inc. 932 Email: gcarofig@cisco.com 934 Jordan Auge 935 Cisco Systems Inc. 937 Email: augjorda@cisco.com 939 Michele Papalini 940 Cisco Systems Inc. 942 Email: mpapal@cisco.com