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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/