doc: Add RFC documents

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]
+