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