diff options
Diffstat (limited to 'doc/rfc/rfc8569.txt')
| -rw-r--r-- | doc/rfc/rfc8569.txt | 2243 |
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc8569.txt b/doc/rfc/rfc8569.txt new file mode 100644 index 0000000..3baa4f0 --- /dev/null +++ b/doc/rfc/rfc8569.txt @@ -0,0 +1,2243 @@ + + + + + + +Internet Research Task Force (IRTF) M. Mosko +Request for Comments: 8569 PARC, Inc. +Category: Experimental I. Solis +ISSN: 2070-1721 LinkedIn + C. Wood + University of California Irvine + July 2019 + + + Content-Centric Networking (CCNx) Semantics + +Abstract + + This document describes the core concepts of the Content-Centric + Networking (CCNx) architecture and presents a network protocol based + on two messages: Interests and Content Objects. It specifies the set + of mandatory and optional fields within those messages and describes + their behavior and interpretation. This architecture and protocol + specification is independent of a specific wire encoding. + + The protocol also uses a control message called an Interest Return, + whereby one system can return an Interest message to the previous hop + due to an error condition. This indicates to the previous hop that + the current system will not respond to the Interest. + + This document is a product of the Information-Centric Networking + Research Group (ICNRG). The document received wide review among + ICNRG participants. Two full implementations are in active use and + have informed the technical maturity of the protocol specification. + + + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 1] + +RFC 8569 CCNx Semantics July 2019 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the consensus of the + Information-Centric Networking Research Group of the Internet + Research Task Force (IRTF). Documents approved for publication by + the IRSG are not candidates for any level of Internet Standard; see + Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8569. + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 2] + +RFC 8569 CCNx Semantics July 2019 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 + 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 + 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.1. Message Grammar . . . . . . . . . . . . . . . . . . . . . 10 + 2.2. Consumer Behavior . . . . . . . . . . . . . . . . . . . . 14 + 2.3. Publisher Behavior . . . . . . . . . . . . . . . . . . . 15 + 2.4. Forwarder Behavior . . . . . . . . . . . . . . . . . . . 16 + 2.4.1. Interest HopLimit . . . . . . . . . . . . . . . . . . 16 + 2.4.2. Interest Aggregation . . . . . . . . . . . . . . . . 17 + 2.4.3. Content Store Behavior . . . . . . . . . . . . . . . 19 + 2.4.4. Interest Pipeline . . . . . . . . . . . . . . . . . . 19 + 2.4.5. Content Object Pipeline . . . . . . . . . . . . . . . 20 + 3. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 3.1. Name Examples . . . . . . . . . . . . . . . . . . . . . . 23 + 3.2. Interest Payload ID . . . . . . . . . . . . . . . . . . . 23 + 4. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 23 + 5. Content Object Hash . . . . . . . . . . . . . . . . . . . . . 24 + 6. Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7. Hashes . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 8. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 8.1. Validation Algorithm . . . . . . . . . . . . . . . . . . 25 + 8.2. Message Integrity Codes . . . . . . . . . . . . . . . . . 26 + 8.3. Message Authentication Codes . . . . . . . . . . . . . . 26 + 8.4. Signature . . . . . . . . . . . . . . . . . . . . . . . . 26 + 9. Interest to Content Object Matching . . . . . . . . . . . . . 28 + 10. Interest Return . . . . . . . . . . . . . . . . . . . . . . . 29 + 10.1. Message Format . . . . . . . . . . . . . . . . . . . . . 30 + 10.2. ReturnCode Types . . . . . . . . . . . . . . . . . . . . 31 + 10.3. Interest Return Protocol . . . . . . . . . . . . . . . . 32 + 10.3.1. No Route . . . . . . . . . . . . . . . . . . . . . . 32 + 10.3.2. HopLimit Exceeded . . . . . . . . . . . . . . . . . 33 + 10.3.3. Interest MTU Too Large . . . . . . . . . . . . . . . 33 + 10.3.4. No Resources . . . . . . . . . . . . . . . . . . . . 33 + 10.3.5. Path Error . . . . . . . . . . . . . . . . . . . . . 33 + 10.3.6. Prohibited . . . . . . . . . . . . . . . . . . . . . 33 + 10.3.7. Congestion . . . . . . . . . . . . . . . . . . . . . 34 + 10.3.8. Unsupported Content Object Hash Algorithm . . . . . 34 + 10.3.9. Malformed Interest . . . . . . . . . . . . . . . . . 34 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 13.2. Informative References . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + + + +Mosko, et al. Experimental [Page 3] + +RFC 8569 CCNx Semantics July 2019 + + +1. Introduction + + This document describes the principles of the CCNx architecture. It + describes a network protocol that uses a hierarchical name to forward + requests and to match responses to requests. It does not use + endpoint addresses, such as Internet Protocol. Restrictions in a + request can limit the response by the public key of the response's + signer or the cryptographic hash of the response. Every CCNx + forwarder along the path does the name matching and restriction + checking. The CCNx protocol fits within the broader framework of + Information-Centric Networking (ICN) protocols [RFC7927]. This + document concerns the semantics of the protocol and is not dependent + on a specific wire encoding. The CCNx Messages [RFC8609] document + describes a type-length-value (TLV) wire-protocol encoding. This + section introduces the main concepts of CCNx, which are further + elaborated in the remainder of the document. + + The CCNx protocol derives from the early ICN work by Jacobson, et al. + [nnc]. Jacobson's version of CCNx is known as the 0.x version ("CCNx + 0.x"), and the present work is known as the 1.0 version ("CCNx 1.0"). + There are two active implementations of CCNx 1.0. The most complete + implementation is Community ICN (CICN) [cicn], a Linux Foundation + project hosted at fd.io. Another active implementation is CCN-lite + [ccn-lite], with support for Internet of Things (IoT) systems and the + RIOT operating system. CCNx 0.x formed the basis of the Named Data + Networking (NDN) [ndn] university project. + + The current CCNx 1.0 specification diverges from CCNx 0.x in a few + significant areas. The most pronounced behavioral difference between + CCNx 0.x and CCNx 1.0 is that CCNx 1.0 has a simpler response + processing behavior. In both versions, a forwarder uses a + hierarchical longest prefix match of a request name against the + forwarding information base (FIB) to send the request through the + network to a system that can issue a response. A forwarder must then + match a response's name to a request's name to determine the reverse + path and deliver the response to the requester. In CCNx 0.x, the + Interest name may be a hierarchical prefix of the response name, + which allows a form of Layer 3 (L3) content discovery. In CCNx 1.0, + a response's name must exactly equal a request's name. Content + discovery is performed by a higher-layer protocol. + + The selector protocol "CCNx Selectors" [selectors] is an example of + using a higher-layer protocol on top of the CCNx 1.0 L3 to perform + content discovery. The selector protocol uses a method similar to + the original CCNx 0.x techniques without requiring partial name + matching of a response to a request in the forwarder. + + + + + +Mosko, et al. Experimental [Page 4] + +RFC 8569 CCNx Semantics July 2019 + + + This document represents the consensus of the Information-Centric + Networking Research Group (ICNRG). It is the first ICN protocol from + the RG, created from the early CCNx protocol [nnc] with significant + revision and input from the ICN community and RG members. This + document has received critical reading by several members of the ICN + community and the RG. The authors and RG chairs approve of the + contents. This document is sponsored under the IRTF, is not issued + by the IETF, and is not an IETF standard. This is an experimental + protocol and may not be suitable for any specific application. The + specification may change in the future. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +1.2. Architecture + + We describe the architecture of the network in which CCNx operates + and introduce certain terminology from [terminology]. The detailed + behavior of each component and message grammar is in Section 2. + + A producer (also called a "publisher") is an endpoint that + encapsulates content in Content Objects for transport in the CCNx + network. A producer has a public/private keypair and signs (directly + or indirectly) the Content Objects. Usually, the producer's KeyId + (hash of the public key) is well known or may be derived from the + producer's namespace via standard means. + + A producer operates within one or more namespaces. A namespace is a + name prefix that is represented in the forwarding information base + (FIB). This allows a request to reach the producer and fetch a + response (if one exists). + + The FIB is a table that tells a forwarder where to send a request. + It may point to a local application, a local cache or Content Store, + or to a remote system. If there is no matching entry in the FIB, a + forwarder cannot process a request. The detailed rules on name + matching to the FIB are given in Section 2.4.4. An endpoint has a + FIB, though it may be a simple default route. An intermediate system + (i.e., a router) typically has a much larger FIB. A core CCNx + forwarder, for example, would know all the global routes. + + + + + + +Mosko, et al. Experimental [Page 5] + +RFC 8569 CCNx Semantics July 2019 + + + A consumer is an endpoint that requests a name. It is beyond the + scope of this document to describe how a consumer learns of a name or + publisher KeyId; higher-layer protocols built on top of CCNx handle + those tasks, such as search engines or lookup services or well-known + names. The consumer constructs a request, called an Interest, and + forwards it via the endpoint's FIB. The consumer should get back + either a response (called a Content Object) that matches the Interest + or a control message (called an Interest Return) that indicates the + network cannot handle the request. + + There are three ways to detect errors in Interest handling. An + Interest Return is a network control message that indicates a low- + level error like "no route" or "out of resources". If an Interest + arrives at a producer, but the producer does not have the requested + content, the producer should send an application-specific error + message (e.g., a "not found" message). Finally, a consumer may not + receive anything; in which case, it should timeout and, depending on + the application, retry the request or return an error to the + application. + +1.3. Protocol Overview + + The goal of CCNx is to name content and retrieve the content from the + network without binding it to a specific network endpoint. A routing + system (specified separately) populates the FIB tables at each CCNx + router with hierarchical name prefixes that point towards the content + producers under that prefix. A request finds matching content along + those paths, in which case a response carries the data, or, if no + match is found, a control message indicates the failure. A request + may further refine acceptable responses with a restriction on the + response's signer and the cryptographic hash of the response. The + details of these restrictions are described below. + + The CCNx name is a hierarchical series of name segments. Each name + segment has a type and zero or more bytes. Matching two names is + done as a binary comparison of the type and value, and is done + segment by segment. The human-readable form is defined under a URI + scheme "ccnx:" [ccnx-uri], though the canonical encoding of a name is + a series of pairs (type, octet string). There is no requirement that + any name segment be human readable or UTF-8. The first few segments + in a name will be matched against the FIB, and a routing protocol may + put its own restrictions on the routable name components (e.g., a + maximum length or character-encoding rules). In principle, name + segments and names have unbounded length, though in practice they are + limited by the wire encoding and practical considerations imposed by + a routing protocol. Note that in CCNx, name segments use binary + comparison, whereas in a URI, the authority uses a case-insensitive + hostname (due to DNS). + + + +Mosko, et al. Experimental [Page 6] + +RFC 8569 CCNx Semantics July 2019 + + + The CCNx name, as used by the forwarder, is purposefully left as a + general octet-encoded type and value without any requirements on + human readability and character encoding. The reason for this is + that we are concerned with how a forwarder processes names. We + expect that applications, routing protocols, or other higher layers + will apply their own conventions and restrictions on the allowed name + segment types and name segment values. + + CCNx is a request and response protocol that fetches chunks of data + using a name. The integrity of each chunk may be directly asserted + through a digital signature or Message Authentication Code (MAC), or, + alternatively, indirectly via hash chains. Chunks may also carry + weaker Message Integrity Codes (MICs) or no integrity protection + mechanism at all. Because provenance information is carried with + each chunk (or larger indirectly protected block), we no longer need + to rely on host identities, such as those derived from TLS + certificates, to ascertain the chunk legitimacy. Therefore, data + integrity is a core feature of CCNx; it does not rely on the data + transmission channel. There are several options for data + confidentiality, discussed later. + + This document only defines the general properties of CCNx names. In + some isolated environments, CCNx users may be able to use any name + they choose and either inject that name (or prefix) into a routing + protocol or use other information foraging techniques. In the + Internet environment, there will be policies around the formats of + names and assignments of names to publishers, though those are not + specified here. + + The key concept of CCNx is that a subjective name is + cryptographically bound to a fixed payload. These publisher- + generated bindings can therefore be cryptographically verified. A + named payload is thus the tuple {{Name, ExtraFields, Payload, + ValidationAlgorithm}, ValidationPayload}, where all fields in the + inner tuple are covered by the validation payload (e.g., signature). + Consumers of this data can check the binding integrity by recomputing + the same cryptographic hash and verifying the digital signature in + ValidationPayload. + + In addition to digital signatures (e.g., RSA), CCNx also supports + message authentication codes (e.g., Hashed Message Authentication + Code (HMAC)) and message integrity codes (e.g., Cyclic Redundancy + Checks (CRC)). To maintain the cryptographic binding, there should + be at least one object with a signature or authentication code, but + not all objects require it. For example, a first object with a + signature could refer to other objects via a hash chain, a Merkle + tree, or a signed manifest. The later objects may not have any + + + + +Mosko, et al. Experimental [Page 7] + +RFC 8569 CCNx Semantics July 2019 + + + validation and rely purely on the references. The use of an + integrity code (e.g., CRC) is intended for detecting accidental + corruption in an Interest. + + CCNx specifies a network protocol around Interests (request messages) + and Content Objects (response messages) to move named payloads. An + Interest includes the Name field, which identifies the desired + response, and optional matching restrictions. Restrictions limit the + possible matching Content Objects. Two restrictions exist: the Key + ID restriction (KeyIdRestr) and Content Object Hash restriction + (ContentObjectHashRestr). The first restriction on the KeyId limits + responses to those signed with a ValidationAlgorithm KeyId field + equal to the restriction. The second is the Content Object Hash + restriction, which limits the response to one where the cryptographic + hash of the entire named payload is equal to the restriction. + Section 9 fully explains how these restrictions limit matching of a + Content Object to an Interest. + + The hierarchy of a CCNx name is used for routing via the longest + matching prefix in a forwarder. The longest matching prefix is + computed name segment by name segment in the hierarchical name, where + each name segment must be exactly equal to match. There is no + requirement that the prefix be globally routable. Within a + deployment, any local routing may be used, even one that only uses a + single flat (nonhierarchical) name segment. + + Another concept of CCNx is that there should be flow balance between + Interest messages and Content Object messages. At the network level, + an Interest traveling along a single path should elicit no more than + one Content Object response. If some node sends the Interest along + more than one path, that node should consolidate the responses such + that only one Content Object flows back towards the requester. If an + Interest is sent broadcast or multicast on a multiple-access media, + the sender should be prepared for multiple responses unless some + other media-dependent mechanism like gossip suppression or leader + election is used. + + As an Interest travels the forward path following the FIB, it + establishes state at each forwarder such that a Content Object + response can trace its way back to the original requester(s) without + the requester needing to include a routable return address. We use + the notional Pending Interest Table (PIT) as a method to store state + that facilitates the return of a Content Object. + + The notional PIT stores the last hop of an Interest plus its Name + field and optional restrictions. This is the data required to match + a Content Object to an Interest (see Section 9). When a Content + + + + +Mosko, et al. Experimental [Page 8] + +RFC 8569 CCNx Semantics July 2019 + + + Object arrives, it must be matched against the PIT to determine which + entries it satisfies. For each such entry, at most one copy of the + Content Object is sent to each listed last hop in the PIT entries. + + An actual PIT is not mandated by this specification. An + implementation may use any technique that gives the same external + behavior. There are, for example, research papers that use + techniques like label switching in some parts of the network to + reduce the per-node state incurred by the PIT [dart]. Some + implementations store the PIT state in the FIB, so there is not a + second table. + + If multiple Interests with the same {Name, [KeyIdRestr], + [ContentObjectHashRestr]} tuple arrive at a node before a Content + Object matching the first Interest comes back, they are grouped in + the same PIT entry and their last hops are aggregated (see + Section 2.4.2). Thus, one Content Object might satisfy multiple + pending Interests in a PIT. + + In CCNx, higher-layer protocols are often called "name-based + protocols" because they operate on the CCNx name. For example, a + versioning protocol might append additional name segments to convey + state about the version of payload. A content discovery protocol + might append certain protocol-specific name segments to a prefix to + discover content under that prefix. Many such protocols may exist + and apply their own rules to names. They may be layered with each + protocol encapsulating (to the left) a higher layer's name prefix. + + This document also describes a control message called an Interest + Return. A network element may return an Interest message to a + previous hop if there is an error processing the Interest. The + returned Interest may be further processed at the previous hop or + returned towards the Interest origin. When a node returns an + Interest, it indicates that the previous hop should not expect a + response from that node for the Interest, i.e., there is no PIT entry + left at the returning node for a Content Object to follow. + + There are multiple ways to describe larger objects in CCNx. + Aggregating L3 Content Objects into larger objects is beyond the + scope of this document. One proposed method, File-Like ICN + Collection (FLIC) [flic], uses a manifest to enumerate the pieces of + a larger object. Manifests are, themselves, Content Objects. + Another option is to use a convention in the Content Object name, as + in the CCNx Chunking [chunking] protocol where a large object is + broken into small chunks and each chunk receives a special name + component indicating its serial order. + + + + + +Mosko, et al. Experimental [Page 9] + +RFC 8569 CCNx Semantics July 2019 + + + At the semantic level, described in this document, we do not address + fragmentation. One experimental fragmentation protocol, BeginEnd + Fragments [befrags], uses a multipoint PPP-style technique for use + over L2 interfaces with the specification for CCNx Messages [RFC8609] + in TLV wire encoding. + + With these concepts, the remainder of the document specifies the + behavior of a forwarder in processing Interest, Content Object, and + Interest Return messages. + +2. Protocol + + This section defines the grammar of a CCNx Message (Interest, Content + Object, or Interest Return). It then presents typical behaviors for + a consumer, a publisher, and a forwarder. In the forwarder section, + there are detailed descriptions about how to handle the forwarder- + specific topics, such as HopLimit and Content Store, along with + detailed processing pipelines for Interest and Content Object + messages. + +2.1. Message Grammar + + The CCNx Message ABNF [RFC5234] grammar is shown in Figure 1. The + grammar does not include any encoding delimiters, such as TLVs. + Specific wire encodings are given in a separate document. If a + Validation section exists, the Validation Algorithm covers from the + Body (BodyName or BodyOptName) through the end of the ValidationAlg + section. The InterestLifetime, CacheTime, and Return Code fields + exist outside of the validation envelope and may be modified. + + HashType, PayloadType, and Private Enterprise Number (PEN) need to + correspond to IANA values registered in the "CCNx Hash Function + Types" and "CCNx Payload Types" registries [ccnx-registry], as well + as the "Private Enterprise Numbers" registry [eprise-numbers], + respectively. + + The various fields, in alphabetical order, are defined as: + + AbsTime: Absolute times are conveyed as the 64-bit UTC time in + milliseconds since the epoch (standard POSIX time). + + CacheTime: The absolute time after which the publisher believes + there is low value in caching the Content Object. This is a + recommendation to caches (see Section 4). + + Cert: Some applications may wish to embed an X.509 certificate to + both validate the signature and provide a trust anchor. The Cert + is a DER-encoded X.509 certificate. + + + +Mosko, et al. Experimental [Page 10] + +RFC 8569 CCNx Semantics July 2019 + + + ConObjField: These are optional fields that may appear in a Content + Object. + + ConObjHash: The value of the Content Object Hash, which is the + SHA256-32 over the message from the beginning of the body to the + end of the message. Note that this coverage area is different + from the ValidationAlg. This value SHOULD NOT be trusted across + domains (see Section 5). + + ContentObjectHashRestr: The Content Object Hash restriction. A + Content Object must hash to the same value as the restriction + using the same HashType. The ContentObjectHashRestr MUST use + SHA256-32. + + ExpiryTime: An absolute time after which the Content Object should + be considered expired (see Section 4). + + Hash: Hash values carried in a Message carry a HashType to identify + the algorithm used to generate the hash followed by the hash + value. This form is to allow hash agility. Some fields may + mandate a specific HashType. + + HashType: The algorithm used to calculate a hash, which must + correspond to one of the IANA "CCNx Hash Function Types" + [ccnx-registry]. + + HopLimit: Interest messages may loop if there are loops in the + forwarding plane. To eventually terminate loops, each Interest + carries a HopLimit that is decremented after each hop and no + longer forwarded when it reaches zero. See Section 2.4. + + InterestField: These are optional fields that may appear in an + Interest message. + + KeyId: An identifier for the key used in the ValidationAlg. See + Validation (Section 8) for a description of how it is used for + MACs and signatures. + + KeyIdRestr: The KeyId Restriction. A Content Object must have a + KeyId with the same value as the restriction. + + KeyLink: A Link (see Section 6) that names how to retrieve the key + used to verify the ValidationPayload (see Section 8). + + Lifetime: The approximate time during which a requester is willing + to wait for a response, usually measured in seconds. It is not + strongly related to the network round-trip time, though it must + necessarily be larger. + + + +Mosko, et al. Experimental [Page 11] + +RFC 8569 CCNx Semantics July 2019 + + + Name: A name is made up of a nonempty first segment followed by zero + or more additional segments, which may be of 0 length. Name + segments are opaque octet strings and are thus case sensitive if + encoding UTF-8. An Interest MUST have a Name. A Content Object + MAY have a Name (see Section 9). The segments of a name are said + to be complete if its segments uniquely identify a single Content + Object. A name is exact if its segments are complete. An + Interest carrying a full name is one that specifies an exact name + and the Content Object Hash restriction of the corresponding + Content Object. + + Payload: The message's data, as defined by PayloadType. + + PayloadType: The format of the Payload field. If missing, assume + Data type (T_PAYLOADTYPE_DATA) [ccnx-registry]. Data type means + the payload is opaque application bytes. Key type + (T_PAYLOADTYPE_KEY [ccnx-registry]) means the payload is a DER- + encoded public key or X.509 certificate. Link type + (T_PAYLOADTYPE_LINK [ccnx-registry]) means it is one or more Links + (see Section 6). + + PublicKey: Some applications may wish to embed the public key used + to verify the signature within the message itself. The PublickKey + is DER encoded. + + RelTime: A relative time, measured in milliseconds. + + ReturnCode: States the reason an Interest message is being returned + to the previous hop (see Section 10.2). + + SigTime: The absolute time (UTC milliseconds) when the signature was + generated. The signature time only applies to the validation + algorithm; it does not necessarily represent when the validated + message was created. + + Vendor: Vendor-specific opaque data. The Vendor data includes the + IANA Private Enterprise Numbers [eprise-numbers], followed by + vendor-specific information. CCNx allows vendor-specific data in + most locations of the grammar. + + Message = Interest / ContentObject / InterestReturn + Interest = IntHdr BodyName [Validation] + IntHdr = HopLimit [Lifetime] *Vendor + ContentObject = ConObjHdr BodyOptName [Validation] + ConObjHdr = [CacheTime / ConObjHash] *Vendor + InterestReturn= ReturnCode Interest + BodyName = Name Common + BodyOptName = [Name] Common + + + +Mosko, et al. Experimental [Page 12] + +RFC 8569 CCNx Semantics July 2019 + + + Common = *Field [Payload] + Validation = ValidationAlg ValidationPayload + + Name = FirstSegment *Segment + FirstSegment = 1*OCTET / Vendor + Segment = *OCTET / Vendor + + ValidationAlg = (RSA-SHA256 / EC-SECP-256K1 / EC-SECP-384R1 / + HMAC-SHA256 / CRC32C) *Vendor + ValidationPayload = 1*OCTET + PublicAlg = KeyId [SigTime] [KeyLink] [PublicKey] [Cert] + RSA-SHA256 = PublicAlg + EC-SECP-256K1 = PublicAlg + EC-SECP-384R1 = PublicAlg + HMAC-SHA256 = KeyId [SigTime] [KeyLink] + CRC32C = [SigTime] + + AbsTime = 8OCTET ; 64-bit UTC msec since epoch + CacheTime = AbsTime + ConObjField = ExpiryTime / PayloadType + ConObjHash = Hash + ExpiryTime = AbsTime + Field = InterestField / ConObjField / Vendor + Hash = HashType 1*OCTET + HashType = 2OCTET ; IANA "CCNx Hash Function Types" + HopLimit = OCTET + InterestField = KeyIdRestr / ContentObjectHashRestr + KeyId = Hash + KeyIdRestr = Hash + KeyLink = Link + Lifetime = RelTime + Link = Name [KeyIdRestr] [ContentObjectHashRestr] + ContentObjectHashRestr = Hash + Payload = *OCTET + PayloadType = OCTET ; IANA "CCNx Payload Types" + PublicKey = *OCTET ; DER-encoded public key + Cert = *OCTET ; DER-encoded X.509 Certificate + RelTime = 1*OCTET ; msec + ReturnCode = OCTET ; see Section 10.2 + SigTime = AbsTime + Vendor = PEN *OCTET + PEN = 1*OCTET ; IANA "Private Enterprise Number" + + Figure 1: CCNx Message ABNF Grammar + + + + + + + +Mosko, et al. Experimental [Page 13] + +RFC 8569 CCNx Semantics July 2019 + + +2.2. Consumer Behavior + + To request a piece of content for a given {Name, [KeyIdRest], + [ContentObjectHashRestr]} tuple, a consumer creates an Interest + message with those values. It MAY add a validation section, + typically only a CRC32C. A consumer MAY put a Payload field in an + Interest to send additional data to the producer beyond what is in + the name. The name is used for routing and may be remembered at each + hop in the notional PIT to facilitate returning a Content Object; + storing large amounts of state in the name could lead to high memory + requirements. Because the payload is not considered when forwarding + an Interest or matching a Content Object to an Interest, a consumer + SHOULD put an Interest Payload ID (see Section 3.2) as part of the + name to allow a forwarder to match Interests to Content Objects and + avoid aggregating Interests with different payloads. Similarly, if a + consumer uses a MAC or a signature, it SHOULD also include a unique + segment as part of the name to prevent the Interest from being + aggregated with other Interests or satisfied by a Content Object that + has no relation to the validation. + + The consumer SHOULD specify an InterestLifetime, which is the length + of time the consumer is willing to wait for a response. The + InterestLifetime is an application-scale time, not a network round- + trip time (see Section 2.4.2). If not present, the InterestLifetime + will use a default value (2 seconds). + + The consumer SHOULD set the Interest HopLimit to a reasonable value + or use the default 255. If the consumer knows the distances to the + producer via routing, it SHOULD use that value. + + A consumer hands off the Interest to its first forwarder, which will + then forward the Interest over the network to a publisher (or + replica) that may satisfy it based on the name (see Section 2.4). + + Interest messages are unreliable. A consumer SHOULD run a transport + protocol that will retry the Interest if it goes unanswered, up to + the InterestLifetime. No transport protocol is specified in this + document. + + The network MAY send to the consumer an Interest Return message that + indicates the network cannot fulfill the Interest. The ReturnCode + specifies the reason for the failure, such as no route or congestion. + Depending on the ReturnCode, the consumer MAY retry the Interest or + MAY return an error to the requesting application. + + + + + + + +Mosko, et al. Experimental [Page 14] + +RFC 8569 CCNx Semantics July 2019 + + + If the content was found and returned by the first forwarder, the + consumer will receive a Content Object. The consumer uses the + following set of checks to validate a received Content Object: + + o The consumer MUST ensure the Content Object is properly formatted. + + o The consumer MUST verify that the returned Content Object matches + one or more pending Interests as per Section 9. + + o If the Content Object is signed, the consumer SHOULD + cryptographically verify the signature as per Section 8. If it + does not have the corresponding key, it SHOULD fetch the key, such + as from a key resolution service or via the KeyLink. + + o If the signature has a SigTime, the consumer MAY use that in + considering if the signature is valid. For example, if the + consumer is asking for dynamically generated content, it should + expect the SigTime not to be before the time the Interest was + generated. + + o If the Content Object is signed, the consumer SHOULD assert the + trustworthiness of the signing key to the namespace. Such an + assertion is beyond the scope of this document, though one may use + traditional PKI methods, a trusted key resolution service, or + methods like [trust]. + + o The consumer MAY cache the Content Object for future use, up to + the ExpiryTime if present. + + o The consumer MAY accept a Content Object off the wire that is + expired. A packet Content Object may expire while in flight; + there is no requirement that forwarders drop expired packets in + flight. The only requirement is that Content Stores, caches, or + producers MUST NOT respond with an expired Content Object. + +2.3. Publisher Behavior + + This document does not specify the method by which names populate a + FIB table at forwarders (see Section 2.4). A publisher is either + configured with one or more name prefixes under which it may create + content or it chooses its name prefixes and informs the routing layer + to advertise those prefixes. + + When a publisher receives an Interest, it SHOULD: + + o Verify that the Interest is part of the publisher's namespace(s). + + + + + +Mosko, et al. Experimental [Page 15] + +RFC 8569 CCNx Semantics July 2019 + + + o If the Interest has a Validation section, verify it as per + Section 8. Usually an Interest will only have a CRC32C, unless + the publisher application specifically accommodates other + validations. The publisher MAY choose to drop Interests that + carry a Validation section if the publisher application does not + expect those signatures, as this could be a form of computational + denial of service. If the signature requires a key that the + publisher does not have, it is NOT RECOMMENDED that the publisher + fetch the key over the network unless it is part of the + application's expected behavior. + + o Retrieve or generate the requested Content Object and return it to + the Interest's previous hop. If the requested content cannot be + returned, the publisher SHOULD reply with an Interest Return or a + Content Object with application payload that says the content is + not available; this Content Object should have a short ExpiryTime + in the future or not be cacheable (i.e., an expiry time of 0). + +2.4. Forwarder Behavior + + A forwarder routes Interest messages based on a Forwarding + Information Base (FIB), returns Content Objects that match Interests + to the Interest's previous hop, and processes Interest Return control + messages. It may also keep a cache of Content Objects in the + notional Content Store table. This document does not specify the + internal behavior of a forwarder, only these and other external + behaviors. + + In this document, we will use two processing pipelines: one for + Interests and one for Content Objects. Interest processing is made + up of checking for duplicate Interests in the PIT (see + Section 2.4.2), checking for a cached Content Object in the Content + Store (see Section 2.4.3), and forwarding an Interest via the FIB. + Content Store processing is made up of checking for matching + Interests in the PIT and forwarding to those previous hops. + +2.4.1. Interest HopLimit + + Interest looping is not prevented in CCNx. An Interest traversing + loops is eventually discarded using the hop-limit field of the + Interest, which is decremented at each hop traversed by the Interest. + + A loop may also terminate because the Interest is aggregated with its + previous PIT entry along the loop. In this case, the Content Object + will be sent back along the loop and eventually return to a node that + already forwarded the content, so it will likely not have a PIT entry + anymore. When the content reaches a node without a PIT entry, it + + + + +Mosko, et al. Experimental [Page 16] + +RFC 8569 CCNx Semantics July 2019 + + + will be discarded. It may be that a new Interest or another looped + Interest will return to that same node, in which case the node will + return a cached response to make a new PIT entry, as below. + + The HopLimit is the last resort method to stop Interest loops where a + Content Object chases an Interest around a loop and where the + intermediate nodes, for whatever reason, no longer have a PIT entry + and do not cache the Content Object. + + Every Interest MUST carry a HopLimit. An Interest received from a + local application MAY have a 0 HopLimit, which restricts the Interest + to other local sources. + + When an Interest is received from another forwarder, the HopLimit + MUST be positive, otherwise the forwarder will discard the Interest. + A forwarder MUST decrement the HopLimit of an Interest by at least 1 + before it is forwarded. + + If the decremented HopLimit equals 0, the Interest MUST NOT be + forwarded to another forwarder; it MAY be sent to a local publisher + application or serviced from a local Content Store. + + A RECOMMENDED HopLimit-processing pipeline is below: + + o If Interest received from a remote system: + + * If received HopLimit is 0, optionally send Interest Return + (HopLimit Exceeded), and discard Interest. + + * Otherwise, decrement the HopLimit by 1. + + o Process as per Content Store and Aggregation rules. + + o If the Interest will be forwarded: + + * If the (potentially decremented) HopLimit is 0, restrict + forwarding to the local system. + + * Otherwise, forward as desired to local or remote systems. + +2.4.2. Interest Aggregation + + Interest aggregation is when a forwarder receives an Interest message + that could be satisfied by the response to another Interest message + already forwarded by the node, so the forwarder suppresses forwarding + the new Interest; it only records the additional previous hop so a + Content Object sent in response to the first Interest will satisfy + both Interests. + + + +Mosko, et al. Experimental [Page 17] + +RFC 8569 CCNx Semantics July 2019 + + + CCNx uses an Interest aggregation rule that assumes the + InterestLifetime is akin to a subscription time and is not a network + round-trip time. Some previous aggregation rules assumed the + lifetime was a round-trip time, but this leads to problems of + expiring an Interest before a response comes if the RTT is estimated + too short or interfering with an Automatic Repeat reQuest (ARQ) + scheme that wants to retransmit an Interest but a prior Interest + overestimated the RTT. + + A forwarder MAY implement an Interest aggregation scheme. If it does + not, then it will forward all Interest messages. This does not imply + that multiple, possibly identical, Content Objects will come back. A + forwarder MUST still satisfy all pending Interests, so one Content + Object could satisfy multiple similar Interests, even if the + forwarder did not suppress duplicate Interest messages. + + A RECOMMENDED Interest aggregation scheme is: + + o Two Interests are considered "similar" if they have the same Name, + KeyIdRestr, and ContentObjectHashRestr, where a missing optional + field in one must be missing in the other. + + o Let the notional value InterestExpiry (a local value at the + forwarder) be equal to the receive time plus the InterestLifetime + (or a platform-dependent default value if not present). + + o An Interest record (PIT entry) is considered invalid if its + InterestExpiry time is in the past. + + o The first reception of an Interest MUST be forwarded. + + o A second or later reception of an Interest similar to a valid + pending Interest from the same previous hop MUST be forwarded. We + consider these a retransmission request. + + o A second or later reception of an Interest similar to a valid + pending Interest from a new previous hop MAY be aggregated (not + forwarded). If this Interest has a larger HopLimit than the + pending Interest, it MUST be forwarded. + + o Aggregating an Interest MUST extend the InterestExpiry time of the + Interest record. An implementation MAY keep a single + InterestExpiry time for all previous hops or MAY keep the + InterestExpiry time per previous hop. In the first case, the + forwarder might send a Content Object down a path that is no + longer waiting for it, in which case the previous hop (next hop of + the Content Object) would drop it. + + + + +Mosko, et al. Experimental [Page 18] + +RFC 8569 CCNx Semantics July 2019 + + +2.4.3. Content Store Behavior + + The Content Store is a special cache that is an integral part of a + CCNx forwarder. It is an optional component. It serves to repair + lost packets and handle flash requests for popular content. It could + be prepopulated or use opportunistic caching. Because the Content + Store could serve to amplify an attack via cache poisoning, there are + special rules about how a Content Store behaves. + + 1. A forwarder MAY implement a Content Store. If it does, the + Content Store matches a Content Object to an Interest via the + normal matching rules (see Section 9). + + 2. If an Interest has a KeyId restriction, then the Content Store + MUST NOT reply unless it knows the signature on the matching + Content Object is correct. It may do this by external knowledge + (i.e., in a managed network or system with prepopulated caches) + or by having the public key and cryptographically verifying the + signature. A Content Store is NOT REQUIRED to verify signatures; + if it does not, then it treats these cases like a cache miss. + + 3. If a Content Store chooses to verify signatures, then it MAY do + so as follows. If the public key is provided in the Content + Object itself (i.e., in the PublicKey field) or in the Interest, + the Content Store MUST verify that the public key's hash is equal + to the KeyId and that it verifies the signature (see + Section 8.4). A Content Store MAY verify the digital signature + of a Content Object before it is cached, but it is not required + to do so. A Content Store SHOULD NOT fetch keys over the + network. If it cannot or has not yet verified the signature, it + should treat the Interest as a cache miss. + + 4. If an Interest has a Content Object Hash restriction, then the + Content Store MUST NOT reply unless it knows the matching Content + Object has the correct hash. If it cannot verify the hash, then + it should treat the Interest as a cache miss. + + 5. It must obey the cache control directives (see Section 4). + +2.4.4. Interest Pipeline + + 1. Perform the HopLimit check (see Section 2.4.1). + + 2. If the Interest carries a validation, such as a MIC or a + signature with an embedded public key or certificate, a forwarder + MAY validate the Interest as per Section 8. A forwarder SHOULD + NOT fetch keys via a KeyLink. If the forwarder drops an Interest + + + + +Mosko, et al. Experimental [Page 19] + +RFC 8569 CCNx Semantics July 2019 + + + due to failed validation, it MAY send an Interest Return + (Section 10.3.9). + + 3. Determine if the Interest can be aggregated as per Section 2.4.2. + If it can be, aggregate and do not forward the Interest. + + 4. If forwarding the Interest, check for a hit in the Content Store + as per Section 2.4.3. If a matching Content Object is found, + return it to the Interest's previous hop. This injects the + Content Store as per Section 2.4.5. + + 5. Look up the Interest in the FIB. Longest Prefix Match (LPM) is + performed name segment by name segment (not byte or bit). It + SHOULD exclude the Interest's previous hop. If a match is found, + forward the Interest. If no match is found or the forwarder + chooses not to forward due to a local condition (e.g., + congestion), it SHOULD send an Interest Return message as per + Section 10. + +2.4.5. Content Object Pipeline + + 1. It is RECOMMENDED that a forwarder that receives a Content Object + check that the Content Object came from an expected previous hop. + An expected previous hop is one pointed to by the FIB or one + recorded in the PIT as having had a matching Interest sent that + way. + + 2. A Content Object MUST be matched to all pending Interests that + satisfy the matching rules (see Section 9). Each satisfied + pending Interest MUST then be removed from the set of pending + Interests. + + 3. A forwarder SHOULD NOT send more than one copy of the received + Content Object to the same Interest previous hop. It may happen, + for example, that two Interests ask for the same Content Object + in different ways (e.g., by name and by name and KeyId), and that + they both come from the same previous hop. It is normal to send + the same Content Object multiple times on the same interface, + such as Ethernet, if it is going to different previous hops. + + 4. A Content Object SHOULD only be put in the Content Store if it + satisfied an Interest (and passed rule #1 above). This is to + reduce the chances of cache poisoning. + + + + + + + + +Mosko, et al. Experimental [Page 20] + +RFC 8569 CCNx Semantics July 2019 + + +3. Names + + A CCNx name is a composition of name segments. Each name segment + carries a label identifying the purpose of the name segment, and a + value. For example, some name segments are general names and some + serve specific purposes such as carrying version information or the + sequencing of many chunks of a large object into smaller, signed + Content Objects. + + There are three different types of names in CCNx: prefix, exact, and + full names. A prefix name is simply a name that does not uniquely + identify a single Content Object, but rather a namespace or prefix of + an existing Content Object name. An exact name is one that uniquely + identifies the name of a Content Object. A full name is one that is + exact and is accompanied by an explicit or implicit ConObjHash. The + ConObjHash is explicit in an Interest and implicit in a Content + Object. + + Note that a forwarder does not need to know any semantics about a + name. It only needs to be able to match a prefix to forward + Interests and match an exact or full name to forward Content Objects. + It is not sensitive to the name segment types. + + The name segment labels specified in this document are given in + Table 1. Name Segment is a general name segment, typically occurring + in the routable prefix and user-specified content name. Interest + Payload ID is a name segment to identify the Interest's payload. + Application Components are a set of name segment types reserved for + application use. + + + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 21] + +RFC 8569 CCNx Semantics July 2019 + + + +-------------+-----------------------------------------------------+ + | Type | Description | + +-------------+-----------------------------------------------------+ + | Name | A generic name segment that includes arbitrary | + | Segment | octets. | + | | | + | Interest | An octet string that identifies the payload carried | + | Payload ID | in an Interest. As an example, the Payload ID | + | | might be a hash of the Interest Payload. This | + | | provides a way to differentiate between Interests | + | | based on the payload solely through a name segment | + | | without having to include all the extra bytes of | + | | the payload itself. | + | | | + | Application | An application-specific payload in a name segment. | + | Components | An application may apply its own semantics to these | + | | components. A good practice is to identify the | + | | application in a name segment prior to the | + | | application component segments. | + +-------------+-----------------------------------------------------+ + + Table 1: CCNx Name Segment Types + + At the lowest level, a forwarder does not need to understand the + semantics of name segments; it need only identify name segment + boundaries and be able to compare two name segments (both label and + value) for equality. The forwarder matches names segment by segment + against its forwarding table to determine a next hop. + + + + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 22] + +RFC 8569 CCNx Semantics July 2019 + + +3.1. Name Examples + + This section uses the CCNx URI [ccnx-uri] representation of CCNx + names. Note that as per the message grammar, an Interest must have a + Name with at least one name segment that must have at least 1 octet + of value. A Content Object must have a similar name or no name at + all. The FIB, on the other hand, could have 0-length names (a + default route), or a first name segment with no value, or a regular + name. + + +--------------------------+----------------------------------------+ + | Name | Description | + +--------------------------+----------------------------------------+ + | ccnx:/ | A 0-length name, corresponds to a | + | | default route. | + | | | + | ccnx:/NAME= | A name with 1 segment of 0 length, | + | | distinct from ccnx:/. | + | | | + | ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first | + | | segment is of type NAME and the second | + | | segment is of type APP:0. | + +--------------------------+----------------------------------------+ + + Table 2: CCNx Name Examples + +3.2. Interest Payload ID + + An Interest may also have a Payload field that carries state about + the Interest but is not used to match a Content Object. If an + Interest contains a payload, the Interest name should contain an + Interest Payload ID (IPID). The IPID allows a PIT entry to correctly + multiplex Content Objects in response to a specific Interest with a + specific payload ID. The IPID could be derived from a hash of the + payload or could be a Globally Unique Identifier (GUID) or a nonce. + An optional Metadata field defines the IPID field so other systems + can verify the IPID, such as when it is derived from a hash of the + payload. No system is required to verify the IPID. + +4. Cache Control + + CCNx supports two fields that affect cache control. These determine + how a cache or Content Store handles a Content Object. They are not + used in the fast path; they are only used to determine if a Content + Object can be injected onto the fast path in response to an Interest. + + The ExpiryTime is a field that exists within the signature envelope + of a Validation Algorithm. It is the UTC time in milliseconds after + + + +Mosko, et al. Experimental [Page 23] + +RFC 8569 CCNx Semantics July 2019 + + + which the Content Object is considered expired and MUST no longer be + used to respond to an Interest from a cache. Stale content MAY be + flushed from the cache. + + The Recommended Cache Time (RCT) is a field that exists outside the + signature envelope. It is the UTC time in milliseconds after which + the publisher considers the Content Object to be of low value to + cache. A cache SHOULD discard it after the RCT, though it MAY keep + it and still respond with it. A cache MAY also discard the Content + Object before the RCT time; there is no contractual obligation to + remember anything. + + This formulation allows a producer to create a Content Object with a + long ExpiryTime but short RCT and keep republishing the same signed + Content Object over and over again by extending the RCT. This allows + a form of "phone home" where the publisher wants to periodically see + that the content is being used. + +5. Content Object Hash + + CCNx allows an Interest to restrict a response to a specific hash. + The hash covers the Content Object message body and the validation + sections, if present. Thus, if a Content Object is signed, its hash + includes that signature value. The hash does not include the fixed + or hop-by-hop headers of a Content Object. Because it is part of the + matching rules (see Section 9), the hash is used at every hop. + + There are two options for matching the Content Object Hash + restriction in an Interest. First, a forwarder could compute for + itself the hash value and compare it to the restriction. This is an + expensive operation. The second option is for a border device to + compute the hash once and place the value in a header (ConObjHash) + that is carried through the network. The second option, of course, + removes any security properties from matching the hash, so it SHOULD + only be used within a trusted domain. The header SHOULD be removed + when crossing a trust boundary. + +6. Link + + A Link is the tuple {Name, [KeyIdRestr], [ContentObjectHashRestr]}. + The information in a Link comprises the fields of an Interest that + would retrieve the Link target. A Content Object with PayloadType of + "Link" is an object whose payload is one or more Links. This tuple + may be used as a KeyLink to identify a specific object with the + certificate-wrapped key. It is RECOMMENDED to include at least one + of either KeyId restriction or Content Object Hash restriction. If + neither restriction is present, then any Content Object with a + matching name from any publisher could be returned. + + + +Mosko, et al. Experimental [Page 24] + +RFC 8569 CCNx Semantics July 2019 + + +7. Hashes + + Several protocol fields use cryptographic hash functions, which must + be secure against attack and collisions. Because these hash + functions change over time, with better ones appearing and old ones + falling victim to attacks, it is important that a CCNx protocol + implementation supports hash agility. + + In this document, we suggest certain hashes (e.g., SHA-256), but a + specific implementation may use what it deems best. The normative + CCNx Messages [RFC8609] specification should be taken as the + definition of acceptable hash functions and uses. + +8. Validation + +8.1. Validation Algorithm + + The Validator consists of a ValidationAlgorithm that specifies how to + verify the message and a ValidationPayload containing the validation + output, e.g., the digital signature or MAC. The ValidationAlgorithm + section defines the type of algorithm to use and includes any + necessary additional information. The validation is calculated from + the beginning of the CCNx Message through the end of the + ValidationAlgorithm section (i.e., up to but not including the + validation payload). We refer to this as the validation region. The + ValidationPayload is the integrity value bytes, such as a MAC or + signature. + + The CCNx Message Grammar (Section 2.1) shows the allowed validation + algorithms and their structure. In the case of a Vendor algorithm, + the vendor may use any desired structure. A Validator can only be + applied to an Interest or a Content Object, not an Interest Return. + An Interest inside an Interest Return would still have the original + validator, if any. + + The grammar allows multiple Vendor extensions to the validation + algorithm. It is up to the vendor to describe the validation region + for each extension. A vendor may, for example, use a regular + signature in the validation algorithm, then append a proprietary MIC + to allow for in-network error checking without using expensive + signature verification. As part of this specification, we do not + allow for multiple Validation Algorithm blocks apart from these + vendor methods. + + + + + + + + +Mosko, et al. Experimental [Page 25] + +RFC 8569 CCNx Semantics July 2019 + + +8.2. Message Integrity Codes + + If the validation algorithm is CRC32C, then the validation payload is + the output of the CRC over the validation region. This validation + algorithm allows for an optional signature time (SigTime) to + timestamp when the message was validated (calling it a "signature" + time is a slight misnomer, but we reuse the same field for this + purpose between MICs, MACs, and signatures). + + MICs are usually used with an Interest to avoid accidental in-network + corruption. They are usually not used on Content Objects because the + objects are either signed or linked to by hash chains, so the CRC32C + is redundant. + +8.3. Message Authentication Codes + + If the validation algorithm is HMAC-SHA256, then the validation + payload is the output of the HMAC over the validation region. The + validation algorithm requires a KeyId and allows for a signature time + (SigTime) and KeyLink. + + The KeyId field identifies the shared secret used between two parties + to authenticate messages. These secrets SHOULD be derived from a key + exchange protocol such as [ccnx-ke]. The KeyId, for a shared secret, + SHOULD be an opaque identifier not derived from the actual key; an + integer counter, for example, is a good choice. + + The signature time is the timestamp when the authentication code was + computed and added to the messages. + + The KeyLink field in a MAC indicates how to negotiate keys and should + point towards the key exchange endpoint. The use of a key + negotiation algorithm is beyond the scope of this specification, and + a key negotiation algorithm is not required to use this field. + +8.4. Signature + + Signature-validation algorithms use public key cryptographic + algorithms such as RSA and the Elliptic Curve Digital Signature + Algorithm (ECDSA). This specification and the corresponding wire + encoding [RFC8609] only support three specific signature algorithms: + RSA-SHA256, EC-SECP-256K1, and EC-SECP-384R1. Other algorithms may + be added in through other documents or by using experimental or + vendor-validation algorithm types. + + + + + + + +Mosko, et al. Experimental [Page 26] + +RFC 8569 CCNx Semantics July 2019 + + + A signature that is public key based requires a KeyId field and may + optionally carry a signature time, an embedded public key, an + embedded certificate, and a KeyLink. The signature time behaves as + normal to timestamp when the signature was created. We describe the + use and relationship of the other fields here. + + It is not common to use embedded certificates, as they can be very + large and may have validity periods different than the validated + data. The preferred method is to use a KeyLink to the validating + certificate. + + The KeyId field in the ValidationAlgorithm identifies the public key + used to verify the signature. It is similar to a Subject Key + Identifier from X.509 (Section 4.2.1.2 of [RFC5280]). We define the + KeyId to be a cryptographic hash of the public key in DER form. All + implementations MUST support the SHA-256 digest as the KeyId hash. + + The use of other algorithms for the KeyId is allowed, and it will not + cause problems at a forwarder because the forwarder only matches the + digest algorithm and digest output and does not compute the digest + (see Section 9). It may cause issues with a Content Store, which + needs to verify the KeyId and PublicKey match (see Section 2.4.3); + though in this case, it only causes a cache miss and the Interest + would still be forwarded to the publisher. As long as the publisher + and consumers support the hash, data will validate. + + As per Section 9, a forwarder only matches the KeyId to a KeyId + restriction. It does not need to look at the other fields such as + the public key, certificate, or KeyLink. + + If a message carries multiples of the KeyId, public key, certificate, + or KeyLink, an endpoint (consumer, cache, or Content Store) MUST + ensure that any fields it uses are consistent. The KeyId MUST be the + corresponding hash of the embedded public key or certificate public + key. The hash function to use is the KeyId's HashType. If there is + both an embedded public key and a certificate, the public keys MUST + be the same. + + A message SHOULD NOT have both a PublicKey and a KeyLink to a public + key, as that is redundant. It MAY have a PublicKey and a KeyLink to + a certificate. + + A KeyLink in a first Content Object may point to a second Content + Object with a DER-encoded public key in the PublicKey field and an + optional DER-encoded X.509 certificate in the payload. The second + Content Object's KeyId MUST equal the first object's KeyId. The + second object's PublicKey field MUST be the public key corresponding + to the KeyId. That key must validate both the first and second + + + +Mosko, et al. Experimental [Page 27] + +RFC 8569 CCNx Semantics July 2019 + + + object's signature. A DER-encoded X.509 certificate may be included + in the second object's payload and its embedded public key MUST match + the PublicKey. It must be issued by a trusted authority, preferably + specifying the valid namespace of the key in the distinguished name. + The second object MUST NOT have a KeyLink; we do not allow for + recursive key lookup. + +9. Interest to Content Object Matching + + A Content Object satisfies an Interest if and only if (a) the Content + Object name, if present, exactly matches the Interest name, (b) the + ValidationAlgorithm KeyId of the Content Object exactly equals the + Interest KeyId restriction, if present, and (c) the computed Content + Object Hash exactly equals the Interest Content Object Hash + restriction, if present. + + The KeyId and KeyIdRestr use the Hash format (see Section 2.1). The + Hash format has an embedded HashType followed by the hash value. + When comparing a KeyId and KeyIdRestr, one compares both the HashType + and the value. + + The matching rules are given by this predicate, which, if it + evaluates true, means the Content Object matches the Interest. Ni = + Name in the Interest (may not be empty), Ki = KeyIdRestr in the + Interest (may be empty), and Hi = ContentObjectHashRestr in the + Interest (may be empty). Likewise, No, Ko, and Ho are those + properties in the Content Object, where No and Ko may be empty; Ho + always exists (it is an intrinsic property of the Content Object). + For binary relations, we use "&" for AND and "|" for OR. We use "E" + for the EXISTS (not empty) operator and "!" for the NOT EXISTS + operator. + + As a special case, if the Content Object Hash restriction in the + Interest specifies an unsupported hash algorithm, then no Content + Object can match the Interest, so the system should drop the Interest + and MAY send an Interest Return to the previous hop. In this case, + the predicate below will never get executed because the Interest is + never forwarded. If the system is using the optional behavior of + having a different system calculate the hash for it, then the system + may assume all hash functions are supported and leave it to the other + system to accept or reject the Interest. + + (!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi) + + As one can see, there are two types of attributes one can match. The + first term depends on the existence of the attribute in the Content + Object while the next two terms depend on the existence of the + attribute in the Interest. The last term is the "Nameless Object" + + + +Mosko, et al. Experimental [Page 28] + +RFC 8569 CCNx Semantics July 2019 + + + restriction that states that if a Content Object does not have a + Name, then it must match the Interest on at least the Hash + restriction. + + If a Content Object does not carry the Content Object Hash as an + expressed field, it must be calculated in network to match against. + It is sufficient within an autonomous system to calculate a Content + Object Hash at a border router and carry it via trusted means within + the autonomous system. If a Content Object ValidationAlgorithm does + not have a KeyId, then the Content Object cannot match an Interest + with a KeyId restriction. + +10. Interest Return + + This section describes the process whereby a network element may + return an Interest message to a previous hop if there is an error + processing the Interest. The returned Interest may be further + processed at the previous hop or returned towards the Interest + origin. When a node returns an Interest, it indicates that the + previous hop should not expect a response from that node for the + Interest, i.e., there is no PIT entry left at the returning node. + + The returned message maintains compatibility with the existing TLV + packet format (a fixed header, optional hop-by-hop headers, and the + CCNx Message body). The returned Interest packet is modified in only + two ways: + + o The PacketType is set to Interest Return to indicate a Feedback + message. + + o The ReturnCode is set to the appropriate value to signal the + reason for the return. + + The specific encodings of the Interest Return are specified in + [RFC8609]. + + A forwarder is not required to send any Interest Return messages. + + A forwarder is not required to process any received Interest Return + message. If a forwarder does not process Interest Return messages, + it SHOULD silently drop them. + + The Interest Return message does not apply to a Content Object or any + other message type. + + + + + + + +Mosko, et al. Experimental [Page 29] + +RFC 8569 CCNx Semantics July 2019 + + + An Interest Return message is a 1-hop message between peers. It is + not propagated multiple hops via the FIB. An intermediate node that + receives an Interest Return may take corrective actions or may + propagate its own Interest Return to previous hops as indicated in + the reverse path of a PIT entry. + +10.1. Message Format + + The Interest Return message looks exactly like the original Interest + message with the exception of the two modifications mentioned above. + The PacketType is set to indicate the message is an Interest Return, + and the reserved byte in the Interest header is used as a Return + Code. The numeric values for the PacketType and ReturnCodes are in + [RFC8609]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 30] + +RFC 8569 CCNx Semantics July 2019 + + +10.2. ReturnCode Types + + This section defines the Interest Return ReturnCode introduced in + this RFC. The numeric values used in the packet are defined in + [RFC8609]. + + +----------------------+--------------------------------------------+ + | Name | Description | + +----------------------+--------------------------------------------+ + | No Route (Section | The returning forwarder has no route to | + | 10.3.1) | the Interest name. | + | | | + | HopLimit Exceeded | The HopLimit has decremented to 0 and | + | (Section 10.3.2) | needs to forward the packet. | + | | | + | Interest MTU too | The Interest's MTU does not conform to the | + | large (Section | required minimum and would require | + | 10.3.3) | fragmentation. | + | | | + | No Resources | The node does not have the resources to | + | (Section 10.3.4) | process the Interest. | + | | | + | Path error (Section | There was a transmission error when | + | 10.3.5) | forwarding the Interest along a route (a | + | | transient error). | + | | | + | Prohibited (Section | An administrative setting prohibits | + | 10.3.6) | processing this Interest. | + | | | + | Congestion (Section | The Interest was dropped due to congestion | + | 10.3.7) | (a transient error). | + | | | + | Unsupported Content | The Interest was dropped because it | + | Object Hash | requested a Content Object Hash | + | Algorithm (Section | restriction using a hash algorithm that | + | 10.3.8) | cannot be computed. | + | | | + | Malformed Interest | The Interest was dropped because it did | + | (Section 10.3.9) | not correctly parse. | + +----------------------+--------------------------------------------+ + + Table 3: Interest Return Reason Codes + + + + + + + + + +Mosko, et al. Experimental [Page 31] + +RFC 8569 CCNx Semantics July 2019 + + +10.3. Interest Return Protocol + + This section describes the forwarder behavior for the various Reason + codes for Interest Return. A forwarder is not required to generate + any of the codes, but if it does, it MUST conform to this + specification. + + If a forwarder receives an Interest Return, it SHOULD take these + standard corrective actions. A forwarder is allowed to ignore + Interest Return messages, in which case its PIT entry would go + through normal timeout processes. + + o Verify that the Interest Return came from a next hop to which it + actually sent the Interest. + + o If a PIT entry for the corresponding Interest does not exist, the + forwarder should ignore the Interest Return. + + o If a PIT entry for the corresponding Interest does exist, the + forwarder MAY do one of the following: + + * Try a different forwarding path, if one exists, and discard the + Interest Return, or + + * Clear the PIT state and send an Interest Return along the + reverse path. + + If a forwarder tries alternate routes, it MUST ensure that it does + not use the same path multiple times. For example, it could keep + track of which next hops it has tried and not reuse them. + + If a forwarder tries an alternate route, it may receive a second + Interest Return, possibly of a different type than the first Interest + Return. For example, node A sends an Interest to node B, which sends + a No Route return. Node A then tries node C, which sends a + Prohibited Interest Return. Node A should choose what it thinks is + the appropriate code to send back to its previous hop. + + If a forwarder tries an alternate route, it should decrement the + Interest Lifetime to account for the time spent thus far processing + the Interest. + +10.3.1. No Route + + If a forwarder receives an Interest for which it has no route, or for + which the only route is back towards the system that sent the + Interest, the forwarder SHOULD generate a "No Route" Interest Return + message. + + + +Mosko, et al. Experimental [Page 32] + +RFC 8569 CCNx Semantics July 2019 + + + How a forwarder manages the FIB table when it receives a No Route + message is implementation dependent. In general, receiving a No + Route Interest Return should not cause a forwarder to remove a route. + The dynamic routing protocol that installed the route should correct + the route, or the administrator who created a static route should + correct the configuration. A forwarder could suppress using that + next hop for some period of time. + +10.3.2. HopLimit Exceeded + + A forwarder MAY choose to send HopLimit Exceeded messages when it + receives an Interest that must be forwarded off system and the + HopLimit is 0. + +10.3.3. Interest MTU Too Large + + If a forwarder receives an Interest whose MTU exceeds the prescribed + minimum, it MAY send an "Interest MTU Too Large" message, or it may + silently discard the Interest. + + If a forwarder receives an "Interest MTU Too Large" response, it + SHOULD NOT try alternate paths. It SHOULD propagate the Interest + Return to its previous hops. + +10.3.4. No Resources + + If a forwarder receives an Interest and it cannot process the + Interest due to lack of resources, it MAY send an Interest Return. A + lack of resources could mean the PIT is too large or that there is + some other capacity limit. + +10.3.5. Path Error + + If a forwarder detects an error forwarding an Interest, such as over + a reliable link, it MAY send a Path-Error Interest Return indicating + that it was not able to send or repair a forwarding error. + +10.3.6. Prohibited + + A forwarder may have administrative policies, such as access control + lists (ACLs), that prohibit receiving or forwarding an Interest. If + a forwarder discards an Interest due to a policy, it MAY send a + Prohibited Interest Return to the previous hop. For example, if + there is an ACL that says "/example/private" can only come from + interface e0, but the forwarder receives one from e1, the forwarder + must have a way to return the Interest with an explanation. + + + + + +Mosko, et al. Experimental [Page 33] + +RFC 8569 CCNx Semantics July 2019 + + +10.3.7. Congestion + + If a forwarder discards an Interest due to congestion, it MAY send a + Congestion Interest Return to the previous hop. + +10.3.8. Unsupported Content Object Hash Algorithm + + If a Content Object Hash restriction specifies a hash algorithm the + forwarder cannot verify, the Interest should not be accepted and the + forwarder MAY send an Interest Return to the previous hop. + +10.3.9. Malformed Interest + + If a forwarder detects a structural or syntactical error in an + Interest, it SHOULD drop the Interest and MAY send an Interest Return + to the previous hop. This does not imply that any router must + validate the entire structure of an Interest. + +11. IANA Considerations + + This document has no IANA actions. + +12. Security Considerations + + The CCNx protocol is an L3 network protocol, which may also operate + as an overlay using other transports such as UDP or other tunnels. + It includes intrinsic support for message authentication via a + signature (e.g., RSA or elliptic curve) or message authentication + code (e.g., HMAC). In lieu of an authenticator, it may instead use a + message integrity check (e.g., SHA or CRC). CCNx does not specify an + encryption envelope; that function is left to a high-layer protocol + (e.g., [esic]). + + The CCNx message format includes the ability to attach MICs (e.g., + CRC32C), MACs (e.g., HMAC), and signatures (e.g., RSA or ECDSA) to + all packet types. This does not mean that it is a good idea to use + an arbitrary ValidationAlgorithm, nor to include computationally + expensive algorithms in Interest packets, as that could lead to + computational DoS attacks. Applications should use an explicit + protocol to guide their use of packet signatures. As a general + guideline, an application might use a MIC on an Interest to detect + unintentionally corrupted packets. If one wishes to secure an + Interest, one should consider using an encrypted wrapper and a + protocol that prevents replay attacks, especially if the Interest is + being used as an actuator. Simply using an authentication code or + signature does not make an Interest secure. There are several + examples in the literature on how to secure ICN-style messaging + [mobile] [ace]. + + + +Mosko, et al. Experimental [Page 34] + +RFC 8569 CCNx Semantics July 2019 + + + As an L3 protocol, this document does not describe how one arrives at + keys or how one trusts keys. The CCNx Content Object may include a + public key or certificate embedded in the object or may use the + KeyLink field to point to a public key or certificate that + authenticates the message. One key-exchange specification is CCNxKE + [ccnx-ke] [mobile], which is similar to the TLS 1.3 key exchange + except it is over the CCNx L3 messages. Trust is beyond the scope of + an L3 protocol and left to applications or application frameworks. + + The combination of an ephemeral key exchange (e.g., CCNxKE [ccnx-ke]) + and an encapsulating encryption (e.g., [esic]) provides the + equivalent of a TLS tunnel. Intermediate nodes may forward the + Interests and Content Objects but have no visibility inside. It also + completely hides the internal names in those used by the encryption + layer. This type of tunneling encryption is useful for content that + has little or no cacheability, as it can only be used by someone with + the ephemeral key. Short-term caching may help with lossy links or + mobility, but long-term caching is usually not of interest. + + Broadcast encryption or proxy re-encryption may be useful for content + with multiple uses over time or many consumers. There is currently + no recommendation for this form of encryption. + + The specific encoding of messages will have security implications. + [RFC8609] uses a type-length-value (TLV) encoding. We chose to + compromise between extensibility and unambiguous encodings of types + and lengths. Some TLV encodings use variable-length "T" and + variable-length "L" fields to accommodate a wide gamut of values + while trying to be byte efficient. Our TLV encoding uses a fixed- + length 2-byte "T" and 2-byte "L". Using a fixed-length "T" and "L" + field solves two problems. The first is aliases. If one is able to + encode the same value, such as %x02 and %x0002, in different byte + lengths, then one must decide if they mean the same thing, if they + are different, or if one is illegal. If they are different, then one + must always compare on the buffers, not the integer equivalents. If + one is illegal, then one must validate the TLV encoding, every field + of every packet at every hop. If they are the same, then one has the + second problem: how to specify packet filters. For example, if a + name has 6 name components, then there are 7 T's and 7 L's, each of + which might have up to 4 representations of the same value. That + would be 14 fields with 4 encodings each, or 1001 combinations. It + also means that one cannot compare, for example, a name via a memory + function as one needs to consider that any embedded "T" or "L" might + have a different format. + + The Interest Return message has no authenticator from the previous + hop. Therefore, the payload of the Interest Return should only be + used locally to match an Interest. A node should never forward that + + + +Mosko, et al. Experimental [Page 35] + +RFC 8569 CCNx Semantics July 2019 + + + Interest Payload as an Interest. It should also verify that it sent + the Interest in the Interest Return to that node and not allow anyone + to negate Interest messages. + + Caching nodes must take caution when processing Content Objects. It + is essential that the Content Store obey the rules outlined in + Section 2.4.3 to avoid certain types of attacks. CCNx 1.0 has no + mechanism to work around an undesired result from the network (there + are no "excludes"), so if a cache becomes poisoned with bad content, + it might cause problems retrieving content. There are three types of + access to content from a Content Store: unrestricted, signature + restricted, and hash restricted. If an Interest has no restrictions, + then the requester is not particular about what they get back, so any + matching cached object is OK. In the hash-restricted case, the + requester is very specific about what they want and the Content Store + (and every forward hop) can easily verify that the content matches + the request. In the signature-restricted case (often used for + initial manifest discovery), the requester only knows the KeyId that + signed the content. It is this case that requires the closest + attention in the Content Store to avoid amplifying bad data. The + Content Store must only respond with a Content Object if it can + verify the signature; this means either the Content Object carries + the public key inside it or the Interest carries the public key in + addition to the KeyId. If that is not the case, then the Content + Store should treat the Interest as a cache miss and let an endpoint + respond. + + A user-level cache could perform full signature verification by + fetching a public key or certificate according to the KeyLink. That + is not, however, a burden we wish to impose on the forwarder. A + user-level cache could also rely on out-of-band attestation, such as + the cache operator only inserting content that it knows has the + correct signature. + + The CCNx grammar allows for hash-algorithm agility via the HashType. + It specifies a short list of acceptable hash algorithms that should + be implemented at each forwarder. Some hash values only apply to end + systems, so updating the hash algorithm does not affect forwarders; + they would simply match the buffer that includes the type-length-hash + buffer. Some fields, such as the ConObjHash, must be verified at + each hop, so a forwarder (or related system) must know the hash + algorithm; it could cause backward compatibility problems if the hash + type is updated. [RFC8609] is the authoritative source for per- + field-allowed hash types in that encoding. + + A CCNx name uses binary matching whereas a URI uses a case- + insensitive hostname. Some systems may also use case-insensitive + matching of the URI path to a resource. An implication of this is + + + +Mosko, et al. Experimental [Page 36] + +RFC 8569 CCNx Semantics July 2019 + + + that human-entered CCNx names will likely have case or non-ASCII + symbol mismatches unless one uses a consistent URI normalization to + the CCNx name. It also means that an entity that registers a CCNx + routable prefix, say "ccnx:/example.com", would need separate + registrations for simple variations like "ccnx:/Example.com". Unless + this is addressed in URI normalization and routing protocol + conventions, there could be phishing attacks. + + For a more general introduction to ICN-related security concerns and + approaches, see [RFC7927] and [RFC7945]. + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +13.2. Informative References + + [ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, + "NDN-ACE: Access Control for Constrained Environments over + Named Data Networking", NDN Technical Report NDN-0036, + December 2015, <http://new.named-data.net/ + wp-content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf>. + + [befrags] Mosko, M. and C. Tschudin, "ICN "Begin-End" Hop by Hop + Fragmentation", Work in Progress, draft-mosko-icnrg- + beginendfragment-02, December 2016. + + [ccn-lite] Tschudin, C., et al., "CCN-lite", University of Basel, + 2011-2019, <http://ccn-lite.net>. + + [ccnx-ke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange + Protocol Version 1.0", Work in Progress, draft-wood-icnrg- + ccnxkeyexchange-02, March 2017. + + [ccnx-registry] + IANA, "Content-Centric Networking (CCNx)", + <https://www.iana.org/assignments/ccnx>. + + + + + +Mosko, et al. Experimental [Page 37] + +RFC 8569 CCNx Semantics July 2019 + + + [ccnx-uri] Mosko, M. and C. Wood, "The CCNx URI Scheme", Work in + Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016. + + [chunking] Mosko, M., "CCNx Content Object Chunking", Work in + Progress, draft-mosko-icnrg-ccnxchunking-02, June 2016. + + [cicn] FD.io, "Community ICN (CICN)", February 2017, + <https://wiki.fd.io/index.php?title=Cicn&oldid=7191>. + + [dart] Garcia-Luna-Aceves, J. and M. Mirzazad-Barijough, "A + Light-Weight Forwarding Plane for Content-Centric + Networks", International Conference on Computing, + Networking, and Communications (ICNC), + DOI 10.1109/ICCNC.2016.7440637, February 2016, + <https://arxiv.org/pdf/1603.06044.pdf>. + + [eprise-numbers] + IANA, "IANA Private Enterprise Numbers", + <https://www.iana.org/assignments/enterprise-numbers>. + + [esic] Mosko, M. and C. Wood, "Encrypted Sessions In CCNx + (ESIC)", Work in Progress, draft-wood-icnrg-esic-01, + September 2017. + + [flic] Tschudin, C. and C. Wood, "File-Like ICN Collection + (FLIC)", Work in Progress, draft-tschudin-icnrg-flic-03, + March 2017. + + [mobile] Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in + Content-Centric Networks", IFIP Networking Conference + (IFIP Networking) and Workshops, + DOI 10.23919/IFIPNetworking.2017.8264861, June 2017, + <https://dl.ifip.org/db/conf/networking/ + networking2017/1570334964.pdf>. + + [ndn] UCLA, "Named Data Networking", 2019, + <https://www.named-data.net>. + + [nnc] Jacobson, V., Smetters, D., Thornton, J., Plass, M., + Briggs, N., and R. Braynard, "Networking Named Content", + Proceedings of the 5th International Conference on + Emerging Networking Experiments and Technologies, + DOI 10.1145/1658939.1658941, December 2009, + <https://dx.doi.org/10.1145/1658939.1658941>. + + + + + + + +Mosko, et al. Experimental [Page 38] + +RFC 8569 CCNx Semantics July 2019 + + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <https://www.rfc-editor.org/info/rfc5234>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <https://www.rfc-editor.org/info/rfc5280>. + + [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., + Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, + "Information-Centric Networking (ICN) Research + Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, + <https://www.rfc-editor.org/info/rfc7927>. + + [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., + and G. Boggia, "Information-Centric Networking: Evaluation + and Security Considerations", RFC 7945, + DOI 10.17487/RFC7945, September 2016, + <https://www.rfc-editor.org/info/rfc7945>. + + [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric + Networking (CCNx) Messages in TLV Format", RFC 8609, + DOI 10.17487/RFC8609, July 2019, + <https://www.rfc-editor.org/info/rfc8609>. + + [selectors] + Mosko, M., "CCNx Selector Based Discovery", Work in + Progress, draft-mosko-icnrg-selectors-01, May 2019. + + [terminology] + Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, + D., and C. Tschudin, "Information-Centric Networking + (ICN): CCN and NDN Terminology", Work in Progress, + draft-irtf-icnrg-terminology-04, June 2019. + + [trust] Tschudin, C., Uzun, E., and C. Wood, "Trust in + Information-Centric Networking: From Theory to Practice", + 25th International Conference on Computer Communication + and Networks (ICCCN), DOI 10.1109/ICCCN.2016.7568589, + August 2016, <https://doi.org/10.1109/ICCCN.2016.7568589>. + + + + + + + + +Mosko, et al. Experimental [Page 39] + +RFC 8569 CCNx Semantics July 2019 + + +Authors' Addresses + + Marc Mosko + PARC, Inc. + Palo Alto, California 94304 + United States of America + + Phone: +01 650-812-4405 + Email: marc.mosko@parc.com + + + Ignacio Solis + LinkedIn + Mountain View, California 94043 + United States of America + + Email: nsolis@linkedin.com + + + Christopher A. Wood + University of California Irvine + Irvine, California 92697 + United States of America + + Phone: +01 315-806-5939 + Email: woodc1@uci.edu + + + + + + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 40] + |