idnits 2.17.00 (12 Aug 2021) /tmp/idnits52139/draft-irtf-icnrg-terminology-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2020) is 848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Netinf' is mentioned on line 803, but not defined == Missing Reference: 'PSIRP' is mentioned on line 810, but not defined == Missing Reference: 'MobilityFirst' is mentioned on line 793, but not defined == Missing Reference: 'RICE' is mentioned on line 842, but not defined == Missing Reference: 'CFN' is mentioned on line 776, but not defined == Missing Reference: 'LessonsLearned' is mentioned on line 787, but not defined == Missing Reference: 'SchematizingTrust' is mentioned on line 847, but not defined == Missing Reference: 'I-D.irtf-icnrg-disaster' is mentioned on line 781, but not defined == Missing Reference: 'NDNTLV' is mentioned on line 800, but not defined == Missing Reference: 'RFC7476' is mentioned on line 817, but not defined == Missing Reference: 'RFC7927' is mentioned on line 823, but not defined == Missing Reference: 'RFC7933' is mentioned on line 829, but not defined == Missing Reference: 'RFC7945' is mentioned on line 836, but not defined == Unused Reference: 'RFC8609' is defined on line 769, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG B. Wissingh 3 Internet-Draft TNO 4 Intended status: Informational C. Wood 5 Expires: July 20, 2020 University of California Irvine 6 A. Afanasyev 7 Florida International University 8 L. Zhang 9 UCLA 10 D. Oran 11 Network Systems Research & Design 12 C. Tschudin 13 University of Basel 14 January 17, 2020 16 Information-Centric Networking (ICN): CCNx and NDN Terminology 17 draft-irtf-icnrg-terminology-08 19 Abstract 21 Information Centric Networking (ICN) is a novel paradigm where 22 network communications are accomplished by requesting named content, 23 instead of sending packets to destination addresses. Named Data 24 Networking (NDN) and Content-Centric Networking (CCNx) are two 25 prominent ICN architectures. This document provides an overview of 26 the terminology and definitions that have been used in describing 27 concepts in these two implementations of ICN. While there are other 28 ICN architectures, they are not part of the NDN and CCNx concepts and 29 as such are out of scope for this document. This document is a 30 product of the Information-Centric Networking Research Group (ICNRG). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 20, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. A Sketch of the Big Picture of ICN . . . . . . . . . . . . . 3 68 3. Terms by category . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Generic terms . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. Terms related to ICN Nodes . . . . . . . . . . . . . . . 6 71 3.3. Terms related to the Forwarding plane . . . . . . . . . . 7 72 3.4. Terms related to Packet Types . . . . . . . . . . . . . . 11 73 3.5. Terms related to Name Types . . . . . . . . . . . . . . . 12 74 3.6. Terms related to Name Usage . . . . . . . . . . . . . . . 13 75 3.7. Terms related to Data-Centric Security . . . . . . . . . 15 76 4. Semantics and Usage . . . . . . . . . . . . . . . . . . . . . 16 77 4.1. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 16 78 4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 16 79 4.3. Lookup Service . . . . . . . . . . . . . . . . . . . . . 16 80 4.4. Database Access . . . . . . . . . . . . . . . . . . . . . 16 81 4.5. Remote Procedure Call . . . . . . . . . . . . . . . . . . 16 82 4.6. Publish/Subscribe . . . . . . . . . . . . . . . . . . . . 17 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 7.1. Informational References . . . . . . . . . . . . . . . . 17 87 7.2. Bibliography . . . . . . . . . . . . . . . . . . . . . . 18 88 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 Information-centric networking (ICN) is an architecture to evolve the 94 Internet infrastructure from the existing host-centric design to a 95 data-centric architecture, where accessing data by name becomes the 96 essential network primitive. The goal is to let applications refer 97 to data independently of their location or means of transportation, 98 which enables native multicast delivery, ubiquitous in-network 99 caching and replication of data objects. 101 As the work on this topic continues to evolve, many new terms are 102 emerging. The goal of this document is to collect the key terms with 103 a corresponding definition as they are used in the CCNx and NDN 104 projects. Other ICN projects such as [Netinf], [PSIRP], or 105 [MobilityFirst] are not covered and may be the subject of other 106 documents. 108 To help provide context for the individual defined terms, in this 109 document we first sketch the bigger picture of an ICN network by 110 introducing the basic concepts and identifying the major components 111 of the architecture in Section 2, after which, in Section 3, ICN 112 related terms are listed by different categories. Readers should be 113 aware that in this organization some terms may be used in other 114 definitions before they themselves are defined. 116 While this terminology document describes both confidentiality and 117 integrity-related terms, it should be noted that ICN architectures 118 like NDN and CCNx generally do not provide data confidentiality, 119 which is treated in these architectures as an application layer 120 concern. 122 This document represents the consensus of the Information-Centric 123 Networking Research Group (ICNRG). It has been reviewed extensively 124 by the Research Group (RG) members active in the specific areas of 125 work covered by the document. It is not an IETF product and is not 126 intended for standardization in the IETF. 128 2. A Sketch of the Big Picture of ICN 130 In networking terms, an ICN is a delivery infrastructure for named 131 data. For other complementing views see Section 4. 133 requestor zero or more data sources or 134 (node) forwarding nodes replica nodes 135 | | ... | |...| 136 | Interest(n) | | Interest(n) | | 137 | --------------> | | ---------------> | | 138 | | | -------------------> | 139 | | | | | 140 | | | Data([n],c,[s]) | | 141 | | | <--------------- | | 142 | | | <------------------- | 143 | Data([n],c,[s]) | | | | 144 | <-------------- | | | | 146 Figure 1: Request-Reply Protocol of ICN networking. Legend: n=name, 147 c=content, s=signature. 149 The following list describes the basic ICN concepts needed to discuss 150 the implementation of this service abstraction. 152 *Request-Reply Protocol (Interest and Data Packet)*: 154 An ICN's lookup service is implemented by defining two types of 155 network packet formats: Interest packets that request content by 156 name, and Data packets that carry the requested content. The 157 returned Data packet must match the request's parameters (e.g., 158 having a partially or fully matching name). If the request is 159 ambiguous and several Data packets would satisfy the request, the 160 ICN network returns only one matching Data packet (thus achieving 161 flow balance between Interest and Data packets over individual 162 layer 2 interfaces). 164 *Packet and Content Names*: 166 Without a strong cryptographic binding between the name of a Data 167 packet and its content, Data packet names would be useless for 168 fetching specific content. In ICN, verification of a Data 169 packet's name-to-content binding is achieved through cryptographic 170 means, either by (1) a cryptographic signature that explicitly 171 binds an application-chosen name to a Data packet's content, or 172 (2) relying on an implicit name (cryptographic hash of the Data 173 packet with or without application-chosen name) that the data 174 consumer obtained through other means. 176 *Data Authenticity and Encryption*: 178 Any data consumer or network element can (in principle) validate 179 the authenticity of a Data packet by verifying its cryptographic 180 name-to-content binding. Note that data authenticity is distinct 181 from data trustworthiness, though the two concepts are related. A 182 packet is authentic if it has a valid name-to-content binding, but 183 it may still be unwise to "trust" the content for any particular 184 purpose. 186 *Trust*: 188 Data authenticity is distinct from data trustworthiness, though 189 the two concepts are related. A packet is authentic if it has a 190 valid name-to-content binding. A packet is trustworthy, i.e., it 191 comes from a reputable or trusted origin, if this binding is valid 192 in the context of a trust model. The trust model provides 193 assurance that the name used for a given piece of content is 194 appropriate for the value of the content. Section 6 discusses 195 this further. 197 *Segmenting and Versioning*: 199 An ICN network will be engineered for some packet size limit. As 200 application-level data objects will often be considerably larger, 201 objects must be segmented into multiple Data packets. The names 202 for these Data packets can, for example, be constructed by 203 choosing one application-level object name to which a different 204 suffix is added for each segment. The same method can be used to 205 handle different versions of an application-level object by 206 including a version number in the name of the overall object. 208 *Packet and Frame*: 210 NDN and CCNx introduce Protocol Data Units (PDUs) which typically 211 are larger than the maximum transmission unit of the underlying 212 networking technology. We refer to PDUs as packets and the 213 (potentially fragmented) packet parts that traverse MTU-bound 214 layer 2 interfaces as frames. Handling layer 2 technologies which 215 lead to fragmentation of ICN packets is done inside the ICN 216 network and is not visible at the service interface. 218 *ICN Node*: 220 A node within an ICN network can fulfill the role of a data 221 producer, a data consumer, and/or a forwarder for Interest and 222 Data packets. When a forwarder has connectivity to neighbor 223 nodes, it performs Interest and Data packet forwarding in real 224 time. It can also behave as a store and forward node, carrying an 225 Interest or Data packet for some time before forwarding it to next 226 node. An ICN node may also run routing protocols to assist its 227 Interest forwarding decisions. 229 *Forwarding Plane*: 231 The canonical way of implementing packet forwarding in an ICN 232 network relies on three data structures that capture a node's 233 state: a Forwarding Interest Table (FIB), a Pending Interest 234 Table (PIT), and a Content Store (CS). It also utilizes Interest 235 forwarding strategies which take input from both FIB and 236 measurements to make Interest forwarding decisions. When a node 237 receives an Interest packet, it checks its CS and PIT to find a 238 matching entry; if no match is found, the node records the 239 Interest in its PIT and forwards the Interest to the next hop(s) 240 towards the requested content, based on the information in its 241 FIB. 243 3. Terms by category 245 3.1. Generic terms 247 *Information-Centric Networking (ICN)*: 249 A networking architecture that retrieves Data packets as response 250 to Interest packets. Content-Centric Networking (CCNx 1.x) and 251 Named Data Networking (NDN) are two realizations (designs) of an 252 ICN architecture. 254 *Data packet Immutability*: 256 After a data packet is created, the cryptographic signature 257 binding the name to the content ensures that if either the content 258 or the name changes, that change will be detected and the packet 259 discarded. If the content carried in a data packet is intended to 260 be mutable, versioning of the name should be used, so that each 261 version uniquely identifies an immutable instance of the content. 262 This allows disambiguation of various versions of content such 263 that coordination among the various instances in a distributed 264 system can be achieved. 266 3.2. Terms related to ICN Nodes 268 *ICN Interface*: 270 A generalization of the network interface that can represent a 271 physical network interface (ethernet, wifi, bluetooth adapter, 272 etc.), an overlay inter-node channel (IP/UDP tunnel, etc.), or an 273 intra-node inter-process communication (IPC) channel to an 274 application (unix socket, shared memory, intents, etc.). 276 Common aliases include: face. 278 *ICN Consumer*: 280 An ICN entity that requests Data packets by generating and sending 281 out Interest packets towards local (using intra-node interfaces) 282 or remote (using inter-node interfaces) ICN Forwarders. 284 Common aliases include: consumer, information consumer, data 285 consumer, consumer of the content. 287 *ICN Producer*: 289 An ICN entity that creates Data packets and makes them available 290 for retrieval. 292 Common aliases include: producer, publisher, information 293 publisher, data publisher, data producer. 295 *ICN Forwarder*: 297 An ICN entity that implements stateful forwarding. 299 Common aliases include: ICN router. 301 *ICN Data Mule*: 303 An ICN entity that temporarily stores and potentially carries an 304 Interest or Data packet before forwarding it to next ICN entity. 305 Note that such ICN data mules do not have all the properties of 306 data mules as employed in the Delay Tolerant Networking (DTN) 307 [RFC4838] specifications. 309 3.3. Terms related to the Forwarding plane 311 *Stateful forwarding*: 313 A forwarding process that records incoming Interest packets in the 314 PIT and uses the recorded information to forward the retrieved 315 Data packets back to the consumer(s). The recorded information 316 can also be used to measure data plane performance, e.g., to 317 adjust interest forwarding strategy decisions. 319 Common aliases include: ICN Data plane, ICN Forwarding. 321 *Forwarding strategy*: 323 A module of the ICN stateful forwarding (ICN data) plane that 324 implements a decision on where/how to forward the incoming 325 Interest packet. The forwarding strategy can take input from the 326 Forwarding Information Base (FIB), measured data plane performance 327 parameters, and/or use other mechanisms to make the decision. 329 Common aliases include: Interest forwarding strategy. 331 *Upstream (forwarding)*: 333 Forwarding packets in the direction of Interests (i.e., Interests 334 are forwarded upstream): consumer, router, router, ..., producer. 336 *Downstream (forwarding)*: 338 Forwarding packets in the opposite direction of Interest 339 forwarding (i.e., Data and Interest Nacks are forwarded 340 downstream): producer, router, ..., consumer(s). 342 *Interest forwarding*: 344 A process of forwarding Interest packets using the Names carried 345 in the Interests. In case of Stateful forwarding, this also 346 involves creating an entry in the PIT. The forwarding decision is 347 made by the Forwarding Strategy. 349 *Interest aggregation*: 351 A process of combining multiple Interest packets with the same 352 Name and additional restrictions for the same Data into a single 353 PIT entry. 355 Common aliases include: Interest collapsing. 357 *Data forwarding*: 359 A process of forwarding the incoming Data packet to the 360 interface(s) recorded in the corresponding PIT entry (entries) and 361 removing the corresponding PIT entry (entries). 363 *Satisfying an Interest*: 365 An overall process of returning content that satisfies the 366 constraints imposed by the Interest, most notably a match in the 367 provided Name. 369 *Interest match in FIB (longest prefix match)*: 371 A process of finding a FIB entry with the longest Name (in terms 372 of Name components) that is a prefix of the specified Name. See 373 Section 3.5 for terms related to name prefixes 375 *Interest match in PIT (exact match)*: 377 A process of finding a PIT entry that stores the same Name as 378 specified in the Interest (including Interest restrictions, if 379 any). 381 *Data match in PIT (all match)*: 383 A process of finding (a set of) PIT entries that can be satisfied 384 with the specified Data packet. 386 *Interest match in CS (any match)*: 388 A process of finding an entry in router's Content Store that can 389 satisfy the specified Interest. 391 *Pending Interest Table (PIT)*: 393 A database that records received and not yet satisfied Interests 394 with the interfaces from where they were received. The PIT can 395 also store interfaces to where Interests were forwarded, and 396 information to assess data plane performance. Interests for the 397 same Data are aggregated into a single PIT entry. 399 *Forwarding Information Base (FIB)*: 401 A database that contains a set of prefixes, each prefix associated 402 with one or more faces that can be used to retrieve Data packets 403 with Names under the corresponding prefix. The list of faces for 404 each prefix can be ranked, and each face may be associated with 405 additional information to facilitate forwarding strategy 406 decisions. 408 *Content Store (CS)*: 410 A database in an ICN router that provides caching. 412 *In-network storage*: 414 An optional process of storing a Data packet within the network 415 (opportunistic caches, dedicated on/off path caches, and managed 416 in-network storage systems), so it can satisfy an incoming 417 Interest for this Data packet. The in-network storages can 418 optionally advertise the stored Data packets in the routing plane. 420 *Opportunistic caching*: 422 A process of temporarily storing a forwarded Data packet in the 423 router's memory (RAM or disk), so it can be used to satisfy future 424 Interests for the same Data, if any. 426 Common aliases include: on-path in-network caching 428 *Managed caching*: 430 A process of temporarily, permanently, or scheduled storing of a 431 selected (set of) Data packet(s). 433 Common aliases include: off-path in-network storage 435 *Managed in-network storage*: 437 An entity acting as an ICN publisher that implements managed 438 caching. 440 Common aliases include: repository, repo 442 *ICN Routing plane*: 444 An ICN protocol or a set of ICN protocols to exchange information 445 about Name space reachability. 447 *ICN Routing Information Base (RIB)*: 449 A database that contains a set of prefix-face mappings that are 450 produced by running one or multiple routing protocols. The RIB is 451 used to populate the FIB. 453 3.4. Terms related to Packet Types 455 *Interest packet*: 457 A network-level packet that expresses the request for a data 458 packet using either an exact name or a name prefix. An Interest 459 packet may optionally carry a set of additional restrictions 460 (e.g., Interest selectors). An Interest may be associated with 461 additional information to facilitate forwarding and can include 462 Interest lifetime, hop limit, forwarding hints, labels, etc. In 463 different ICN designs, the set of additional associated 464 information may vary. 466 Common aliases include: Interest, Interest message, information 467 request 469 *Interest Nack*: 471 A packet that contains the Interest packet and optional 472 annotation, which is sent by the ICN Router to the interface(s) 473 the Interest was received from. Interest Nack is used to inform 474 downstream ICN nodes about inability to forward the included 475 Interest packet. The annotation can describe the reason. 477 Common aliases include: network NACK, Interest return. 479 *Data packet*: 481 A network-level packet that carries payload, uniquely identified 482 by a name, and is directly secured through cryptographic signature 483 mechanisms. 485 Common aliases include: data, data object, content object, 486 content object packet, data message, named data object, named 487 data. 489 *Link*: 491 A type of Data packet whose body contains the Name of another Data 492 packet. This inner Name is often a Full Name, i.e., it specifies 493 the Packet ID of the corresponding Data packet, but this is not a 494 requirement. 496 Common aliases include: pointer. 498 *Manifest*: 500 A type of Data packet that contains Full Name Links to one or more 501 Data Packets. Manifests group collections of related Data packets 502 under a single Name. Manifests allow both large Data objects to 503 be conveniently split into individual Content Objects under one 504 name, and to represent sets of related Content Objects as a form 505 of "directory". Manifests have the additional benefit of 506 amortizing the signature verification cost for each Data packet 507 referenced by the inner Links. Manifests typically contain 508 additional metadata, e.g., the size (in bytes) of each linked Data 509 packet and the cryptographic hash digest of all Data contained in 510 the linked Data packets. 512 3.5. Terms related to Name Types 514 *Name*: 516 A Data packet identifier. An ICN name is hierarchical (a sequence 517 of name components) and usually is semantically meaningful, making 518 it expressive, flexible and application-specific (akin to a HTTP 519 URL). A Name may encode information about application context, 520 semantics, locations (topological, geographical, hyperbolic, 521 etc.), a service name, etc. 523 Common aliases include: data name, interest name, content name. 525 *Name component*: 527 A sequence of bytes and optionally a numeric type representing a 528 single label in the hierarchical structured name. 530 Common aliases include: name segment (as in CCNx). 532 *Packet ID*: 534 A unique cryptographic identifier for a Data packet. Typically, 535 this is a cryptographic hash digest of a data packet (such as 536 SHA256 [RFC6234]), including its name, payload, meta information, 537 and signature. 539 Common aliases include: implicit digest. 541 *Selector*: 543 A mechanism (condition) to select an individual Data packet from a 544 collection of Data packets that match a given Interest that 545 requests data using a prefix or exact Name. 547 Common aliases include: interest selector, restrictor, interest 548 restrictor. 550 *Nonce*: 552 A field of an Interest packet that transiently names an Interest 553 instance (instance of Interest for a given name). Note: the 554 specifications defining nonces in NDN do not necessarily satisfy 555 all the properties of nonces as discussed in [RFC4949]. 557 *Exact Name*: 559 A name that is encoded inside a Data packet and which typically 560 uniquely identifies this Data packet. 562 *Full Name*: 564 An exact Name with the Packet ID of the corresponding Data packet. 566 *Prefix Name*: 568 A Name that includes a partial sequence of Name components 569 (starting from the first one) of a Name encoded inside a Data 570 packet. 572 Common aliases include: prefix. 574 3.6. Terms related to Name Usage 576 *Naming conventions*: 578 A convention, agreement, or specification for the Data packet 579 naming. a Naming convention structures a namespace. 581 Common aliases include: Naming scheme, ICN naming scheme, 582 namespace convention. 584 *Hierarchically structured naming*: 586 The naming scheme that assigns and interprets a Name as a sequence 587 of labels (Name components) with hierarchical structure without an 588 assumption of a single administrative root. A structure provides 589 useful context information for the Name. 591 Common aliases include: hierarchical naming, structured naming. 593 *Flat naming*: 595 The naming scheme that assigns and interprets a Name as a single 596 label (Name component) without any internal structure. This can 597 be considered a special (or degenerate) case of structured names. 599 *Segmentation*: 601 A process of splitting large application content into a set of 602 uniquely named data packets. When using hierarchically structured 603 names, each created data packet has a common prefix and an 604 additional component representing the segment (chunk) number. 606 Common aliases include: chunking. 608 *Versioning*: 610 A process of assigning a unique Name to the revision of the 611 content carried in the Data packet. When using a hierarchically 612 structured Name, the version of the Data packet can be carried in 613 a dedicated Name component (e.g., prefix identifies data, unique 614 version component identifies the revision of the data). 616 *Fragmentation*: 618 A process of splitting PDUs into Frames so that they can be 619 transmitted over a layer 2 interface with a smaller MTU size. 621 3.7. Terms related to Data-Centric Security 623 *Data-Centric Security*: 625 A security property associated with the Data packet, including 626 data (Data-Centric) integrity, authenticity, and optionally 627 confidentiality. These security properties stay with the data 628 packet regardless where it is stored and how it is retrieved. 630 Common aliases include: directly securing data packet 632 *Data Integrity* 634 A cryptographic mechanism to ensure the consistency of the Data 635 packet bits. The Data integrity property validates that the Data 636 packet content has not been corrupted during transmission, e.g., 637 over lossy or otherwise unreliable paths, or been subject to 638 deliberate modification. 640 *Data Authenticity* 642 A cryptographic mechanism to ensure trustworthiness of a Data 643 packet, based on a selected (e.g., by a consumer/producer) trust 644 model. Typically, data authenticity is assured through the use of 645 asymmetric cryptographic signatures (e.g., RSA, ECDSA), but can 646 also be realized using symmetric signatures (e.g., HMAC) within 647 trusted domains. 649 *Data Confidentiality* 651 A cryptographic mechanism to ensure secrecy of a Data packet. 652 Data confidentiality includes separate mechanisms: content 653 confidentiality and Name confidentiality 655 *Content Confidentiality* 657 A cryptographic mechanism to prevent an unauthorized party to get 658 access to the plain-text payload of a Data packet. Can be 659 realized through encryption (symmetric, asymmetric, hybrid) and 660 proper distribution of the decryption keys to authorized parties. 662 *Name Confidentiality* 664 A cryptographic mechanism to prevent an observer of Interest-Data 665 exchanges (e.g., intermediate router) from gaining detailed meta 666 information about the Data packet. This mechanism can be realized 667 using encryption (same as content confidentiality) or obfuscation 668 mechanisms. 670 4. Semantics and Usage 672 The terminology described above is the manifestation of intended 673 semantics of NDN and CCNx operations (what do we expect the network 674 to do?). In this section we summarize the most commonly proposed use 675 cases and interpretations. 677 4.1. Data Transfer 679 The networking view of NDN and CCNx is that the request/reply 680 protocol implements a basic, unreliable data transfer service for 681 single, named packets. 683 4.2. Data Transport 685 Data transfer can be turned into a data transport service for 686 application-level objects by additional logic. This transport logic 687 must understand and construct the series of names needed to 688 reassemble the segmented object. Various flavors of transport can be 689 envisaged (reliable, streaming, mailbox, etc). 691 4.3. Lookup Service 693 In a more distributed systems view of the basic request/reply 694 protocol, NDN and CCNx provide a distributed lookup service: given a 695 key value (=name), the service will return the corresponding value. 697 4.4. Database Access 699 A lookup service can be turned into a database access protocol by 700 using the namespace structure to specify names as access keys into a 701 database. A name prefix therefore stands for a collection or table 702 of a database, while the rest of the name specifies the query 703 expression to be executed. 705 4.5. Remote Procedure Call 707 The names as defined in this document for Interests and Data can 708 refer to Remote Procedure call functions, their input arguments, and 709 their results. For a comprehensive view of how to construct RPC or 710 other remote invocation systems, see the ACM ICN paper on [RICE]. 711 These capabilities can be further extended into a full distributed 712 computing infrastructure, such as that proposed in the ACM ICN paper 713 [CFN]. 715 4.6. Publish/Subscribe 717 The names as defined in this document for Interests and Data can 718 refer to data collections to be subscribed and individual data 719 objects to be published in a Publish-Subscribe application 720 architecture. For a fully-worked example of how to construct such an 721 ICN-based system, see the ACM ICN paper [LessonsLearned]. 723 5. IANA Considerations 725 There are no IANA considerations related to this document. 727 6. Security Considerations 729 While the terms defined in this specification do not in and of 730 themselves present new security considerations, the architectures 731 which utilize the terms most certainly do. Readers should look at 732 those specifications (e.g. [RFC8569], [NDN]) where various security 733 considerations are addressed in detail. 735 Some of the terms in this document use the words "trust", 736 "trustworthy", or "trust model". We intend that these have their 737 colloquial meanings, however much work on trust, and specifically on 738 trust schemas for ICN architectures has been published in the last 739 few years. For example, it is useful to look at [SchematizingTrust] 740 for more information on the approachs taken to formalize notions of 741 trust for current NDN and CCNx systems. 743 7. References 745 7.1. Informational References 747 [NDN] NDN team, , "Named Data Networking", various, 748 . 750 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 751 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 752 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 753 April 2007, . 755 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 756 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 757 . 759 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 760 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 761 DOI 10.17487/RFC6234, May 2011, . 764 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 765 Networking (CCNx) Semantics", RFC 8569, 766 DOI 10.17487/RFC8569, July 2019, . 769 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 770 Networking (CCNx) Messages in TLV Format", RFC 8609, 771 DOI 10.17487/RFC8609, July 2019, . 774 7.2. Bibliography 776 [CFN] Krol, m., Mastorakis, S., Kutscher, D., and D. Oran, 777 "Compute First Networking: Distributed Computing meets 778 ICN, in ACM ICN'19", DOI 10.1145/3357150.3357395, 2019, 779 . 781 [I-D.irtf-icnrg-disaster] 782 Seedorf, J., Arumaithurai, M., Tagami, A., Ramakrishnan, 783 K., and N. Blefari-Melazzi, "Research Directions for Using 784 ICN in Disaster Scenarios", draft-irtf-icnrg-disaster-04 785 (work in progress), February 2019. 787 [LessonsLearned] 788 Nichols, K., "Lessons Learned Building a Secure Network 789 Measurement Framework using Basic NDN, in ACM ICN'19", 790 DOI 10.1145/3357150.3357397, 2019, . 793 [MobilityFirst] 794 Raychaudhuri, D., Nagaraja, K., and V. Venkataramani, 795 "MobilityFirst: a robust and trustworthy mobility-centric 796 architecture for the future internet, in ACM SIGMOBILE, 797 Volume 16, Issue 3", DOI 10.1145/2412096.2412098, July 798 2012, . 800 [NDNTLV] NDN Project Team, , "NDN Packet Format Specification", 801 2016, . 803 [Netinf] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., 804 Ahlgren, B., and K. Holger, "Network of Information 805 (NetInf) - An information-centric networking architecture, 806 in Computer Communications, Volume 36, Issue 7", 807 DOI 10.1016/j.comcom.2013.01.009, April 2013, 808 . 810 [PSIRP] Trossen, D., Tuononen, J., Xylomenos, G., Sarela, M., 811 Zahemszky, A., Nikander, P., and T. Rinta-aho, "From 812 Design for Tussle to Tussle Networking: PSIRP Vision and 813 Use Cases", 2008, 814 . 817 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 818 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 819 "Information-Centric Networking: Baseline Scenarios", 820 RFC 7476, DOI 10.17487/RFC7476, March 2015, 821 . 823 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 824 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 825 "Information-Centric Networking (ICN) Research 826 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 827 . 829 [RFC7933] Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C., 830 Azgin, A., Liu, W., Mueller, C., Detti, A., Corujo, D., 831 Wang, J., Montpetit, M., and N. Murray, "Adaptive Video 832 Streaming over Information-Centric Networking (ICN)", 833 RFC 7933, DOI 10.17487/RFC7933, August 2016, 834 . 836 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 837 and G. Boggia, "Information-Centric Networking: Evaluation 838 and Security Considerations", RFC 7945, 839 DOI 10.17487/RFC7945, September 2016, 840 . 842 [RICE] Krol, m., Habak, K., Kutscher, D., and D. Oran, "RICE: 843 remote method invocation in ICN, in ACM ICN'18", 844 DOI 10.1145/3267955.3267956, 2018, 845 . 847 [SchematizingTrust] 848 Yu, Y., Afanasyev, A., Clark, D., Claffy, kc., Jacobson, 849 V., and L. Zhang, "Schematizing Trust in Named Data 850 Networking, in ACM ICN'15", DOI 0.1145/2810156.2810170, 851 2015, . 853 Appendix A. Acknowledgments 855 Marc Mosko provided much guidance and helpful precision in getting 856 these terms carefully formed and the definitions precise. Marie-Jose 857 Montpetit did a thorough IRSG review, which helped a lot to improve 858 the text. Further comments during the IRSG Poll from Stephen 859 Farrell, Ari Keraenen, Spencer Dawkins, Carsten Bormann, and Brian 860 Trammell further improved the document. Additional helpful comments 861 were received as part of IESG conflict review from Mirja Kuehlewind 862 and Benjamin Kaduk. 864 Authors' Addresses 866 Bastiaan Wissingh 867 TNO 869 EMail: bastiaan.wissingh@tno.nl 871 Christopher A. Wood 872 University of California Irvine 874 EMail: woodc1@uci.edu 876 Alex Afanasyev 877 Florida International University 879 EMail: aa@cs.fiu.edu 881 Lixia Zhang 882 UCLA 884 EMail: lixia@cs.ucla.edu 886 David Oran 887 Network Systems Research & Design 889 EMail: daveoran@orandom.net 891 Christian Tschudin 892 University of Basel 894 EMail: christian.tschudin@unibas.ch