< draft-irtf-icnrg-ccnxmessages-09.txt   rfc8609.txt 
ICNRG M. Mosko Internet Research Task Force (IRTF) M. Mosko
Internet-Draft PARC, Inc. Request for Comments: 8609 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 Messages in TLV Format Content-Centric Networking (CCNx) Messages in TLV Format
draft-irtf-icnrg-ccnxmessages-09
Abstract Abstract
This document specifies the encoding of CCNx messages in a TLV packet Content-Centric Networking (CCNx) is a network protocol that uses a
format, including the TLV types used by each message element and the hierarchical name to forward requests and to match responses to
encoding of each value. The semantics of CCNx messages follow the requests. This document specifies the encoding of CCNx messages in a
encoding-independent CCNx Semantics specification. TLV packet format, including the TLV types used by each message
element and the encoding of each value. The semantics of CCNx
messages follow the encoding-independent CCNx Semantics
specification.
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 and has two full implementations currently in
active use, which 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/rfc8609.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Type-Length-Value (TLV) Packets . . . . . . . . . . . . . . . 5 3. Type-Length-Value (TLV) Packets . . . . . . . . . . . . . . . 5
3.1. Overall packet format . . . . . . . . . . . . . . . . . . 6 3.1. Overall Packet Format . . . . . . . . . . . . . . . . . . 7
3.2. Fixed Headers . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Fixed Headers . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Interest Fixed Header . . . . . . . . . . . . . . . . 8 3.2.1. Interest Fixed Header . . . . . . . . . . . . . . . . 9
3.2.1.1. Interest HopLimit . . . . . . . . . . . . . . . . 9 3.2.1.1. Interest HopLimit . . . . . . . . . . . . . . . . 9
3.2.2. Content Object Fixed Header . . . . . . . . . . . . . 9 3.2.2. Content Object Fixed Header . . . . . . . . . . . . . 9
3.2.3. InterestReturn Fixed Header . . . . . . . . . . . . . 9 3.2.3. Interest Return Fixed Header . . . . . . . . . . . . 10
3.2.3.1. InterestReturn HopLimit . . . . . . . . . . . . . 10 3.2.3.1. Interest Return HopLimit . . . . . . . . . . . . 10
3.2.3.2. InterestReturn Flags . . . . . . . . . . . . . . 10 3.2.3.2. Interest Return Flags . . . . . . . . . . . . . . 10
3.2.3.3. Return Code . . . . . . . . . . . . . . . . . . . 10 3.2.3.3. Return Code . . . . . . . . . . . . . . . . . . . 10
3.3. Global Formats . . . . . . . . . . . . . . . . . . . . . 10 3.3. Global Formats . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Pad . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Pad . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Organization Specific TLVs . . . . . . . . . . . . . 11 3.3.2. Organization-Specific TLVs . . . . . . . . . . . . . 12
3.3.3. Hash Format . . . . . . . . . . . . . . . . . . . . . 11 3.3.3. Hash Format . . . . . . . . . . . . . . . . . . . . . 12
3.3.4. Link . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.4. Link . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Hop-by-hop TLV headers . . . . . . . . . . . . . . . . . 13 3.4. Hop-by-Hop TLV Headers . . . . . . . . . . . . . . . . . 14
3.4.1. Interest Lifetime . . . . . . . . . . . . . . . . . . 14 3.4.1. Interest Lifetime . . . . . . . . . . . . . . . . . . 14
3.4.2. Recommended Cache Time . . . . . . . . . . . . . . . 14 3.4.2. Recommended Cache Time . . . . . . . . . . . . . . . 15
3.4.3. Message Hash . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Message Hash . . . . . . . . . . . . . . . . . . . . 16
3.5. Top-Level Types . . . . . . . . . . . . . . . . . . . . . 16 3.5. Top-Level Types . . . . . . . . . . . . . . . . . . . . . 17
3.6. CCNx Message . . . . . . . . . . . . . . . . . . . . . . 16 3.6. CCNx Message TLV . . . . . . . . . . . . . . . . . . . . 18
3.6.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 17 3.6.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.1.1. Name Segments . . . . . . . . . . . . . . . . . . 18 3.6.1.1. Name Segments . . . . . . . . . . . . . . . . . . 20
3.6.1.2. Interest Payload ID . . . . . . . . . . . . . . . 19 3.6.1.2. Interest Payload ID . . . . . . . . . . . . . . . 20
3.6.2. Message TLVs . . . . . . . . . . . . . . . . . . . . 20 3.6.2. Message TLVs . . . . . . . . . . . . . . . . . . . . 21
3.6.2.1. Interest Message TLVs . . . . . . . . . . . . . . 20 3.6.2.1. Interest Message TLVs . . . . . . . . . . . . . . 21
3.6.2.2. Content Object Message TLVs . . . . . . . . . . . 21 3.6.2.2. Content Object Message TLVs . . . . . . . . . . . 23
3.6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 23 3.6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.4. Validation . . . . . . . . . . . . . . . . . . . . . 23 3.6.4. Validation . . . . . . . . . . . . . . . . . . . . . 25
3.6.4.1. Validation Algorithm . . . . . . . . . . . . . . 23 3.6.4.1. Validation Algorithm . . . . . . . . . . . . . . 25
3.6.4.2. Validation Payload . . . . . . . . . . . . . . . 29 3.6.4.2. Validation Payload . . . . . . . . . . . . . . . 32
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
4.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 30 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
4.2. Interest Return Code Registry . . . . . . . . . . . . . . 30 4.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 33
4.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 31 4.2. Interest Return Code Registry . . . . . . . . . . . . . . 34
4.4. Top-Level Type Registry . . . . . . . . . . . . . . . . . 32 4.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 35
4.5. Name Segment Type Registry . . . . . . . . . . . . . . . 33 4.4. Top-Level Type Registry . . . . . . . . . . . . . . . . . 36
4.6. Message Type Registry . . . . . . . . . . . . . . . . . . 34 4.5. Name Segment Type Registry . . . . . . . . . . . . . . . 37
4.7. Payload Type Registry . . . . . . . . . . . . . . . . . . 35 4.6. Message Type Registry . . . . . . . . . . . . . . . . . . 37
4.8. Validation Algorithm Type Registry . . . . . . . . . . . 36 4.7. Payload Type Registry . . . . . . . . . . . . . . . . . . 38
4.9. Validation Dependent Data Type Registry . . . . . . . . . 37 4.8. Validation Algorithm Type Registry . . . . . . . . . . . 39
4.10. Hash Function Type Registry . . . . . . . . . . . . . . . 39 4.9. Validation-Dependent Data Type Registry . . . . . . . . . 40
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 4.10. Hash Function Type Registry . . . . . . . . . . . . . . . 40
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6.1. Normative References . . . . . . . . . . . . . . . . . . 43 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2. Informative References . . . . . . . . . . . . . . . . . 43 6.1. Normative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 6.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
This document specifies a Type-Length-Value (TLV) packet format and This document specifies a Type-Length-Value (TLV) packet format and
the TLV type and value encodings for CCNx messages. A full the TLV type and value encodings for CCNx messages. A full
description of the CCNx network protocol, providing an encoding-free description of the CCNx network protocol, providing an encoding-free
description of CCNx messages and message elements, may be found in description of CCNx messages and message elements, may be found in
[CCNSemantics]. CCNx is a network protocol that uses a hierarchical [RFC8569]. CCNx is a network protocol that uses a hierarchical name
name to forward requests and to match responses to requests. It does to forward requests and to match responses to requests. It does not
not use endpoint addresses, such as Internet Protocol. Restrictions use endpoint addresses; the Internet Protocol does. Restrictions in
in a request can limit the response by the public key of the a request can limit the response by the public key of the response's
response's signer or the cryptographic hash of the response. Every signer or the cryptographic hash of the response. Every CCNx
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]. Information-Centric Networking (ICN) protocols [RFC7927].
This document describes a TLV scheme using a fixed 2-byte T and a This document describes a TLV scheme using a fixed 2-byte T and a
fixed 2-byte L field. The rational for this choice is described in fixed 2-byte L field. The rational for this choice is described in
Section 5. Briefly, this choice avoids multiple encodings of the Section 5. Briefly, this choice avoids multiple encodings of the
same value (aliases) and reduces the work of a validator to ensure same value (aliases) and reduces the work of a validator to ensure
compliance. Unlike some uses of TLV in networking, the each network compliance. Unlike some uses of TLV in networking, each network hop
hop must evaluate the encoding, so even small validation latencies at must evaluate the encoding, so even small validation latencies at
each hop could add up to a large overall forwarding delay. For very each hop could add up to a large overall forwarding delay. For very
small packets or low throughput links, where the extra bytes may small packets or low-throughput links, where the extra bytes may
become a concern, one may use a TLV compression protocol, for example become a concern, one may use a TLV compression protocol, for
[compress] and [CCNxz]. example, [compress] and [CCNxz].
This document uses the terms CCNx Packet, CCNx Message, and CCNx
Message TLV. A CCNx Packet refers to the entire Layer 3 datagram as
specified in Section 3.1. A CCNx Message is the ABNF token defined
in the CCNx Semantics document [RFC8569]. A CCNx Message TLV refers
to the encoding of a CCNx Message as specified in Section 3.6.
This document specifies: This document specifies:
o The TLV packet format. o the CCNx Packet format,
o The overall packet format for CCNx messages. o the CCNx Message TLV format,
o The TLV types used by CCNx messages. o the TLV types used by CCNx messages,
o The encoding of values for each type. o the encoding of values for each type,
o Top level types that exist at the outermost containment. o top-level types that exist at the outermost containment,
o Interest TLVs that exist within Interest containment. o Interest TLVs that exist within Interest containment, and
o Content Object TLVs that exist within Content Object containment. o Content Object TLVs that exist within Content Object containment.
This document is supplemented by this document: This document is supplemented by these documents:
o Message semantics: see [CCNSemantics] for the protocol operation o [RFC8569], which covers message semantics and the protocol
regarding Interest and Content Object, including the Interest operation regarding Interest and Content Object, including the
Return protocol. Interest Return protocol.
o URI notation: see [CCNxURI] for the CCNx URI notation. o [CCNxURI], which covers the CCNx URI notation.
The type values in Section 4 represent the values in common usage The type values in Section 4 conform to the IANA-assigned numbers for
today. These values may change pending IANA assignments. All type the CCNx protocol. This document uses the symbolic names defined in
values are relative to their parent containers. For example, each that section. All TLV type values are relative to their parent
level of a nested TLV structure might define a "type = 1" with a containers. For example, each level of a nested TLV structure might
completely different meaning. In the following, we use the symbolic define a "type = 1" with a completely different meaning.
names defined in that section.
Packets are represented as 32-bit wide words using ASCII art. Due to Packets are represented as 32-bit wide words using ASCII art. Due to
the nested levels of TLV encoding and the presence of optional fields the nested levels of TLV encoding and the presence of optional fields
and variable sizes, there is no concise way to represent all and variable sizes, there is no concise way to represent all
possibilities. We use the convention that ASCII art fields enclosed possibilities. We use the convention that ASCII art fields enclosed
by vertical bars "|" represent exact bit widths. Fields with a by vertical bars "|" represent exact bit widths. Fields with a
forward slash "/" are variable bit widths, which we typically pad out forward slash "/" are variable bit widths, which we typically pad out
to word alignment for picture readability. to word alignment for picture readability.
The document represents the consensus of the ICN RG. It is the first The document represents the consensus of the ICN RG. It is the first
ICN protocol from the RG, created from the early CCNx protocol [nnc] ICN protocol from the RG, created from the early CCNx protocol [nnc]
with significant revision and input from the ICN community and RG with significant revision and input from the ICN community and RG
members. The draft has received critical reading by several members members. The document has received critical reading by several
of the ICN community and the RG. The authors and RG chairs approve members of the ICN community and the RG. The authors and RG chairs
of the contents. The document is sponsored under the IRTF and is not approve of the contents. The document is sponsored under the IRTF
issued by the IETF and is not an IETF standard. This is an and is not issued by the IETF and is not an IETF standard. This is
experimental protocol and may not be suitable for any specific an experimental protocol and may not be suitable for any specific
application and the specification may change in the future. application and 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.
2. Definitions 2. Definitions
o Name: A hierarchically structured variable length identifier. It These definitions summarize items defined in [RFC8569]. This
is an ordered list of path segments, which are variable length document defines their encodings.
o Name: A hierarchically structured variable-length identifier. It
is an ordered list of path segments, which are variable-length
octet strings. In human-readable form, it is represented in URI octet strings. In human-readable form, it is represented in URI
format as ccnx:/path/part. There is no host or query string. See format as "ccnx:/path/part". There is no host or query string.
[CCNxURI] for complete details. See [CCNxURI] for complete details.
o Interest: A message requesting a Content Object with a matching o Interest: A message requesting a Content Object with a matching
Name and other optional selectors to choose from multiple objects Name and other optional selectors to choose from multiple objects
with the same Name. Any Content Object with a Name and attributes with the same Name. Any Content Object with a Name and attributes
that matches the Name and optional selectors of the Interest is that matches the Name and optional selectors of the Interest is
said to satisfy the Interest. said to satisfy the Interest.
o Content Object: A data object sent in response to an Interest o Content Object: A data object sent in response to an Interest
request. It has an optional Name and a content payload that are request. It has an optional Name and a content payload that are
bound together via cryptographic means. bound together via cryptographic means.
3. Type-Length-Value (TLV) Packets 3. Type-Length-Value (TLV) Packets
We use 16-bit Type and 16-bit Length fields to encode TLV based We use 16-bit Type and 16-bit Length fields to encode TLV-based
packets. This provides 64K different possible types and value field packets. This provides 65,536 different possible types and value
lengths of up to 64KiB. With 64K possible types at each level of TLV field lengths of up to 64 KiB. With 65,536 possible types at each
encoding, there should be sufficient space for basic protocol types, level of TLV encoding, there should be sufficient space for basic
while also allowing ample room for experimentation, application use, protocol types, while also allowing ample room for experimentation,
vendor extensions, and growth. This encoding does not allow for application use, vendor extensions, and growth. This encoding does
jumbo packets beyond 64 KiB total length. If used on a media that not allow for jumbo packets beyond 64 KiB total length. If used on a
allows for jumbo frames, we suggest defining a media adapation media that allows for jumbo frames, we suggest defining a media
envelope that allows for multiple smaller frames. adaptation envelope that allows for multiple smaller frames.
+--------+------------------+---------------------------------------+
| Abbrev | Name | Description |
+--------+------------------+---------------------------------------+
| T_ORG | Vendor Specific | Information specific to a vendor |
| | Information | implementation (Section 3.3.2). |
| | | |
| T_PAD | Padding | Adds padding to a field (Section |
| | | 3.3.1). |
| | | |
| n/a | Experimental | Experimental use. |
+--------+------------------+---------------------------------------+
Table 1: Reserved TLV Types
There are several global TLV definitions that we reserve at all There are several global TLV definitions that we reserve at all
hierarchical contexts. The TLV types in the range 0x1000 - 0x1FFF hierarchical contexts. The TLV types in the range 0x1000 - 0x1FFF
are reserved for experimental use. The TLV type T_ORG is also are Reserved for Experimental Use. The TLV type T_ORG is also
reserved for vendor extensions ( see Section 3.3.2). The TLV type Reserved for Vendor Extensions (see Section 3.3.2). The TLV type
T_PAD is used to optionally pad a field out to some desired T_PAD is used to optionally pad a field out to some desired
alignment. alignment.
+--------+-------------------------+--------------------------------+ 1 2 3
| Abbrev | Name | Description |
+--------+-------------------------+--------------------------------+
| T_ORG | Vendor Specific | Information specific to a |
| | Information (Section | vendor implementation (see |
| | 3.3.2) | below). |
| | | |
| T_PAD | Padding (Section 3.3.1) | Adds padding to a field (see |
| | | below). |
| | | |
| n/a | Experimental | Experimental use. |
+--------+-------------------------+--------------------------------+
Table 1: Reserved TLV Types
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Type | Length | | Type | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 1: Type and Length encoding
The Length field contains the length of the Value field in octets. The Length field contains the length of the Value field in octets.
It does not include the length of the Type and Length fields. The It does not include the length of the Type and Length fields. The
length MAY be zero. Length MAY be zero.
TLV structures are nestable, allowing the Value field of one TLV TLV structures are nestable, allowing the Value field of one TLV
structure to contain additional TLV structures. The enclosing TLV structure to contain additional TLV structures. The enclosing TLV
structure is called the container of the enclosed TLV. structure is called the container of the enclosed TLV.
Type values are context-dependent. Within a TLV container, one may Type values are context dependent. Within a TLV container, one may
re-use previous type values for new context-dependent purposes. reuse previous type values for new context-dependent purposes.
3.1. Overall packet format 3.1. Overall Packet Format
Each packet includes the 8 byte fixed header, described below, Each CCNx Packet includes the 8-byte fixed header, described below,
followed by a set of TLV fields. These fields are optional hop-by- followed by a set of TLV fields. These fields are optional hop-by-
hop headers and the Packet Payload. hop headers and the Packet Payload.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Version | PacketType | PacketLength | | Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| PacketType specific fields | HeaderLength | | PacketType-specific fields | HeaderLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional Hop-by-hop header TLVs / / Optional hop-by-hop header TLVs /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ PacketPayload TLVs / / PacketPayload TLVs /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
The packet payload is a TLV encoding of the CCNx message, followed by Figure 2: Overall Packet Format
The PacketPayload of a CCNx Packet is the protocol message itself.
The Content Object Hash is computed over the PacketPayload only,
excluding the fixed and hop-by-hop headers, as those might change
from hop to hop. Signed information or similarity hashes should not
include any of the fixed or hop-by-hop headers. The PacketPayload
should be self-sufficient in the event that the fixed and hop-by-hop
headers are removed. See Message Hash (Section 3.4.3).
Following the CCNx Message TLV, the PacketPayload may include
optional Validation TLVs. optional Validation TLVs.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| CCNx Message TLV / | CCNx Message TLV /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV / / Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) / / Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
This document describes the Version "1" TLV encoding.
After discarding the fixed and hop-by-hop headers the remaining Figure 3: PacketPayload TLVs
After discarding the fixed and hop-by-hop headers, the remaining
PacketPayload should be a valid protocol message. Therefore, the PacketPayload should be a valid protocol message. Therefore, the
PacketPayload always begins with 4 bytes of type-length that PacketPayload always begins with 4 bytes of type-length that
specifies the protocol message (whether it is an Interest, Content specifies the protocol message (whether it is an Interest, Content
Object, or other message type) and its total length. The embedding Object, or other message type) and its total length. The embedding
of a self-sufficient protocol data unit inside the fixed and hop-by- of a self-sufficient protocol data unit inside the fixed and hop-by-
hop headers allows a network stack to discard the headers and operate hop headers allows a network stack to discard the headers and operate
only on the embedded message. It also de-couples the PacketType only on the embedded message. It also decouples the PacketType field
field -- which specifies how to forward the packet -- from the -- which specifies how to forward the packet -- from the
PacketPayload. PacketPayload.
The range of bytes protected by the Validation includes the CCNx The range of bytes protected by the Validation includes the CCNx
Message and the ValidationAlgorithm. Message TLV and the ValidationAlgorithm TLV.
The ContentObjectHash begins with the CCNx Message and ends at the The ContentObjectHash begins with the CCNx Message TLV and ends at
tail of the packet. the tail of the CCNx Packet.
3.2. Fixed Headers 3.2. Fixed Headers
CCNx messages begin with an 8 byte fixed header (non-TLV format). In Figure 2, the fixed header fields are:
The HeaderLength field represents the combined length of the Fixed
and Hop-by-hop headers. The PacketLength field represents the entire
Packet length from the first byte of Version to the last byte of the
packet.
A specific PacketType may assign meaning to the "PacketType specific
fields," which are otherwise reserved. For the three defined
PacketTypes (Interest, ContentObject, and InterestReturn), we define
those values in this document.
The PacketPayload of a CCNx packet is the protocol message itself.
The Content Object Hash is computed over the PacketPayload only,
excluding the fixed and hop-by-hop headers as those might change from
hop to hop. Signed information or Similarity Hashes should not
include any of the fixed or hop-by-hop headers. The PacketPayload
should be self-sufficient in the event that the fixed and hop-by-hop
headers are removed.
1 2 3 o Version: defines the version of the packet, which MUST be 1.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+
| PacketType specific fields | HeaderLength |
+---------------+---------------+---------------+---------------+
o Version: defines the version of the packet.
o HeaderLength: The length of the fixed header (8 bytes) and hop-by- o HeaderLength: The length of the fixed header (8 bytes) and hop-by-
hop headers. The minimum value MUST be "8". hop headers. The minimum value MUST be 8.
o PacketType: describes forwarder actions to take on the packet. o PacketType: describes forwarder actions to take on the packet.
o PacketLength: Total octets of packet including all headers (fixed o PacketLength: Total octets of packet including all headers (fixed
header plus hop-by-hop headers) and protocol message. header plus hop-by-hop headers) and protocol message.
o PacketType Specific Fields: specific PacketTypes define the use of o PacketType-specific Fields: specific PacketTypes define the use of
these bits. these bits.
The PacketType field indicates how the forwarder should process the The PacketType field indicates how the forwarder should process the
packet. A Request Packet (Interest) has PacketType PT_INTEREST, a packet. A Request Packet (Interest) has PacketType PT_INTEREST, a
Response (Content Object) has PacketType PT_CONTENT, and an Response (Content Object) has PacketType PT_CONTENT, and an Interest
InterestReturn has PacketType PT_RETURN. Return has PacketType PT_RETURN.
HeaderLength is the number of octets from the start of the packet HeaderLength is the number of octets from the start of the CCNx
(Version) to the end of the hop-by-hop headers. PacketLength is the Packet (Version) to the end of the hop-by-hop headers. PacketLength
number of octets from the start of the packet to the end of the is the number of octets from the start of the packet to the end of
packet. Both lengths have a minimum value of 8 (the fixed header the packet. Both lengths have a minimum value of 8 (the fixed header
itself). itself).
The PacketType specific fields are reserved bits whose use depends on The PacketType-specific fields are reserved bits whose use depends on
the PacketType. They are used for network-level signaling. the PacketType. They are used for network-level signaling.
3.2.1. Interest Fixed Header 3.2.1. Interest Fixed Header
If the PacketType is PT_INTEREST, it indicates that the PacketPayload If the PacketType is PT_INTEREST, it indicates that the packet should
should be processed as an Interest message. For this type of packet, be forwarded following the Interest pipeline in Section 2.4.4 of
the Fixed Header includes a field for a HopLimit as well as Reserved [RFC8569]. For this type of packet, the Fixed Header includes a
and Flags fields. The Reserved field MUST be set to 0 in an Interest field for a HopLimit as well as Reserved and Flags fields. The
- this field will be set to a return code in the case of an Interest Reserved field MUST be set to 0 in an Interest. There are currently
Return. There are currently no Flags defined, so this field MUST be no flags defined, so the Flags field MUST be set to 0.
set to 0.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Version | PT_INTEREST | PacketLength | | Version | PT_INTEREST | PacketLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| HopLimit | Reserved | Flags | HeaderLength | | HopLimit | Reserved | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 4: Interest Header
3.2.1.1. Interest HopLimit 3.2.1.1. Interest HopLimit
For an Interest message, the HopLimit is a counter that is For an Interest message, the HopLimit is a counter that is
decremented with each hop. It limits the distance an Interest may decremented with each hop. It limits the distance an Interest may
travel on the network. The node originating the Interest MAY put in travel on the network. The node originating the Interest MAY put in
any value - up to the maximum of 255. Each node that receives an any value up to the maximum of 255. Each node that receives an
Interest with a HopLimit decrements the value upon reception. If the Interest with a HopLimit decrements the value upon reception. If the
value is 0 after the decrement, the Interest MUST NOT be forwarded value is 0 after the decrement, the Interest MUST NOT be forwarded
off the node. off the node.
It is an error to receive an Interest with a 0 hop-limit from a It is an error to receive an Interest from a remote node with the
remote node. HopLimit field set to 0.
3.2.2. Content Object Fixed Header 3.2.2. Content Object Fixed Header
If the PacketType is PT_CONTENT, it indicates that the PacketPayload If the PacketType is PT_CONTENT, it indicates that the packet should
should be processed as a Content Object message. A Content Object be forwarded following the Content Object pipeline in Section 2.4.4
defines a Flags field, however there are currently no flags defined, of [RFC8569]. A Content Object defines a Flags field; however, there
so the Flags field must be set to 0. are currently no flags defined, so the Flags field must be set to 0.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Version | PT_CONTENT | PacketLength | | Version | PT_CONTENT | PacketLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Reserved | Flags | HeaderLength | | Reserved | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
3.2.3. InterestReturn Fixed Header Figure 5: Content Object Header
If the PacketType is PT_RETURN, it indicates that the PacketPayload 3.2.3. Interest Return Fixed Header
should be processed as a returned Interest message. The only
difference between this InterestReturn message and the original If the PacketType is PT_RETURN, it indicates that the packet should
Interest is that the PacketType is changed to PT_RETURN and a be processed following the Interest Return rules in Section 10 of
ReturnCode is is put into the ReturnCode field. All other fields are [RFC8569]. The only difference between this Interest Return message
unchanged from the Interest packet. The purpose of this encoding is and the original Interest is that the PacketType is changed to
to prevent packet length changes so no additional bytes are needed to PT_RETURN and a ReturnCode is put into the ReturnCode field. All
return an Interest to the previous hop. See [CCNSemantics] for a other fields are unchanged from the Interest packet. The purpose of
protocol description of this packet type. this encoding is to prevent packet length changes so no additional
bytes are needed to return an Interest to the previous hop.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Version | PT_RETURN | PacketLength | | Version | PT_RETURN | PacketLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| HopLimit | ReturnCode | Flags | HeaderLength | | HopLimit | ReturnCode | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
3.2.3.1. InterestReturn HopLimit Figure 6: Interest Return Header
This is the original Interest's HopLimit, as received. It is the 3.2.3.1. Interest Return HopLimit
value before being decremented at the current node (i.e. the received
value).
3.2.3.2. InterestReturn Flags This is the original Interest's HopLimit, as received before
decrement at the node sending the Interest Return.
3.2.3.2. Interest Return Flags
These are the original Flags as set in the Interest. These are the original Flags as set in the Interest.
3.2.3.3. Return Code 3.2.3.3. Return Code
The numeric value assigned to the return types is defined below. This section maps the Return Code name [RFC8569] to the TLV symbolic
This value is set by the node creating the Interest Return. name. Section 4.2 maps the symbolic names to numeric values. This
field is set by the node creating the Interest Return.
A return code of "0" MUST NOT be used, as it indicates that the A return code of "0" MUST NOT be used, as it indicates that the
returning system did not modify the Return Code field. returning system did not modify the Return Code field.
+-------------------------------------+-----------------------------+ +-------------------------------------+-----------------------------+
| Type | Return Type | | Return Type | Name in RFC 8569 |
+-------------------------------------+-----------------------------+ +-------------------------------------+-----------------------------+
| T_RETURN_NO_ROUTE | No Route | | T_RETURN_NO_ROUTE | No Route |
| | | | | |
| T_RETURN_LIMIT_EXCEEDED | Hop Limit Exceeded | | T_RETURN_LIMIT_EXCEEDED | Hop Limit Exceeded |
| | | | | |
| T_RETURN_NO_RESOURCES | No Resources | | T_RETURN_NO_RESOURCES | No Resources |
| | | | | |
| T_RETURN_PATH_ERROR | Path Error | | T_RETURN_PATH_ERROR | Path Error |
| | | | | |
| T_RETURN_PROHIBITED | Prohibited | | T_RETURN_PROHIBITED | Prohibited |
skipping to change at page 11, line 7 skipping to change at page 11, line 37
Table 2: Return Codes Table 2: Return Codes
3.3. Global Formats 3.3. Global Formats
This section defines global formats that may be nested within other This section defines global formats that may be nested within other
TLVs. TLVs.
3.3.1. Pad 3.3.1. Pad
The pad type may be used by protocols that prefer word-aligned data. The pad type may be used by sources that prefer word-aligned data.
The size of the word may be defined by the protocol. Padding 4-byte Padding 4-byte words, for example, would use a 1-byte, 2-byte, and
words, for example, would use a 1-byte, 2-byte, and 3-byte Length. 3-byte Length. Padding 8-byte words would use a (0, 1, 2, 3, 5, 6,
Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, 7)-byte Length. 7)-byte Length.
One MUST NOT pad inside a Name. Apart from that, a pad MAY be One MUST NOT pad inside a Name. Apart from that, a pad MAY be
inserted after any other TLV in the CCNx Message or in the Validation inserted after any other TLV in the CCNx Message TLV or in the
Dependent Data In the remainder of this document, we will not show ValidationAlgorithm TLV. In the remainder of this document, we will
optional pad TLVs. not show optional Pad TLVs.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_PAD | Length | | T_PAD | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ variable length pad MUST be zeros / / variable-length pad MUST be zeros /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
3.3.2. Organization Specific TLVs Figure 7: Pad Encoding
Organization specific TLVs (also known as Vendor TLVs) MUST use the 3.3.2. Organization-Specific TLVs
T_ORG type. The Length field is the length of the organization
Organization-specific TLVs (also known as Vendor TLVs) MUST use the
T_ORG type. The Length field is the length of the organization-
specific information plus 3. The Value begins with the 3 byte specific information plus 3. The Value begins with the 3 byte
organization number derived from the last three digits of the IANA organization number derived from the network byte order encoding of
Private Enterprise Numbers [EpriseNumbers], followed by the the IANA "Private Enterprise Numbers" registry [IANA-PEN], followed
organization specific information. by the organization-specific information.
A T_ORG MAY be used as a path segment in a Name, in which case it is A T_ORG MAY be used as a path segment in a Name. It is treated like
a regular path segment and is part of the regular name matching. any other path segment.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_ORG | Length (3+value length) | | T_ORG | Length (3+value length) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| PEN[0] | PEN[1] | PEN[2] | / | PEN[0] | PEN[1] | PEN[2] | /
+---------------+---------------+---------------+ + +---------------+---------------+---------------+ +
/ Vendor Specific Value / / Vendor Specific Value /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 8: Organization-Specific TLVs
3.3.3. Hash Format 3.3.3. Hash Format
Hash values are used in several fields throughout a packet. This TLV Hash values are used in several fields throughout a packet. This TLV
encoding is commonly embedded inside those fields to specify the encoding is commonly embedded inside those fields to specify the
specific hash function used and it's value. Note that the reserved specific hash function used and its value. Note that the reserved
TLV types are also reserved here for user-defined experimental TLV types are also reserved here for user-defined experimental
functions. functions.
The LENGTH field of the hash value MUST be less than or equal to the The LENGTH field of the hash value MUST be less than or equal to the
hash function length. If the LENGTH is less than the full length, it hash function length. If the LENGTH is less than the full length, it
is taken as the left LENGTH bytes of the hash function output. Only is taken as the left LENGTH bytes of the hash function output. Only
specified truncations are allowed, not arbitrary truncations. specified truncations are allowed, not arbitrary truncations.
This nested format is used because it allows binary comparison of This nested format is used because it allows binary comparison of
hash values for certain fields without a router needing to understand hash values for certain fields without a router needing to understand
a new hash function. For example, the KeyIdRestriction is bit-wise a new hash function. For example, the KeyIdRestriction is bit-wise
compared between an Interest's KeyIdRestriction field and a compared between an Interest's KeyIdRestriction field and a
ContentObject's KeyId field. This format means the outer field ContentObject's KeyId field. This format means the outer field
values do not change with differing hash functions so a router can values do not change with differing hash functions so a router can
still identify those fields and do a binary comparison of the hash still identify those fields and do a binary comparison of the hash
TLV without need to understand the specific hash used. An TLV without need to understand the specific hash used. An
alternative approach, such as using T_KEYID_SHA512-256, would require alternative approach, such as using T_KEYID_SHA512-256, would require
each router keep an up-to-date parser and supporting user-defined each router keeps an up-to-date parser and supporting user-defined
hash functions here would explode the parsing state-space. hash functions here would explode the parsing state-space.
A CCNx entity MUST support the hash type T_SHA-256. An entity MAY A CCNx entity MUST support the hash type T_SHA-256. An entity MAY
support the remaining hash types. support the remaining hash types.
+-----------+------------------------+ +-----------+------------------------+
| Abbrev | Lengths (octets) | | Abbrev | Lengths (octets) |
+-----------+------------------------+ +-----------+------------------------+
| T_SHA-256 | 32 | | T_SHA-256 | 32 |
| | | | | |
| T_SHA-512 | 64, 32 | | T_SHA-512 | 64, 32 |
| | | | | |
| n/a | Experimental TLV types | | n/a | Experimental TLV types |
+-----------+------------------------+ +-----------+------------------------+
Table 3: CCNx Hash Functions Table 3: CCNx Hash Functions
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_FOO | 36 | | T_FOO | 36 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_SHA512 | 32 | | T_SHA512 | 32 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ 32-byte hash value / / 32-byte hash value /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Example nesting inside type T_FOO Figure 9: Example nesting inside type T_FOO
3.3.4. Link 3.3.4. Link
A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}. A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}.
It is a general encoding that is used in both the payload of a It is a general encoding that is used in both the payload of a
Content Object with PayloadType = "Link" and in the KeyLink field in Content Object with PayloadType = "Link" and in a Content Object's
a KeyLocator. A Link is essentially the body of an Interest. KeyLink field. A Link is essentially the body of an Interest.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+ +---------------+---------------+---------------+---------------+
/ Mandatory CCNx Name / / Mandatory CCNx Name /
+---------------+---------------+-------------------------------+ +---------------+---------------+---------------+---------------+
/ Optional KeyIdRestriction / / Optional KeyIdRestriction /
+---------------------------------------------------------------+ +---------------+---------------+---------------+---------------+
/ Optional ContentObjectHashRestriction / / Optional ContentObjectHashRestriction /
+---------------------------------------------------------------+ +---------------+---------------+---------------+---------------+
3.4. Hop-by-hop TLV headers Figure 10: Link Encoding
3.4. Hop-by-Hop TLV Headers
Hop-by-hop TLV headers are unordered and meaning MUST NOT be attached Hop-by-hop TLV headers are unordered and meaning MUST NOT be attached
to their ordering. Three hop-by-hop headers are described in this to their ordering. Three hop-by-hop headers are described in this
document: document:
+-------------+-------------------+---------------------------------+ +-------------+--------------------+--------------------------------+
| Abbrev | Name | Description | | Abbrev | Name | Description |
+-------------+-------------------+---------------------------------+ +-------------+--------------------+--------------------------------+
| T_INTLIFE | Interest Lifetime | The time an Interest should | | T_INTLIFE | Interest Lifetime | The time an Interest should |
| | (Section 3.4.1) | stay pending at an intermediate | | | (Section 3.4.1) | stay pending at an |
| | | node. | | | | intermediate node. |
| | | | | | | |
| T_CACHETIME | Recommended Cache | The Recommended Cache Time for | | T_CACHETIME | Recommended Cache | The Recommended Cache Time for |
| | Time (Section | Content Objects. | | | Time (Section | Content Objects. |
| | 3.4.2) | | | | 3.4.2) | |
| | | | | | | |
| T_MSGHASH | Message Hash | The hash of the CCNx Message to | | T_MSGHASH | Message Hash | A cryptographic hash (Section |
| | (Section 3.4.3) | end of packet using Section | | | (Section 3.4.3) | 3.3.3). |
| | | 3.3.3 format. | +-------------+--------------------+--------------------------------+
+-------------+-------------------+---------------------------------+
Table 4: Hop-by-hop Header Types Table 4: Hop-by-Hop Header Types
Additional hop-by-hop headers are defined in higher level Additional hop-by-hop headers are defined in higher level
specifications such as the fragmentation specification. specifications such as the fragmentation specification.
3.4.1. Interest Lifetime 3.4.1. Interest Lifetime
The Interest Lifetime is the time that an Interest should stay The Interest Lifetime is the time that an Interest should stay
pending at an intermediate node. It is expressed in milliseconds as pending at an intermediate node. It is expressed in milliseconds as
an unsigned, network byte order integer. an unsigned integer in network byte order.
A value of 0 (encoded as 1 byte %x00) indicates the Interest does not A value of 0 (encoded as 1 byte 0x00) indicates the Interest does not
elicit a Content Object response. It should still be forwarded, but elicit a Content Object response. It should still be forwarded, but
no reply is expected and a forwarder could skip creating a PIT entry. no reply is expected and a forwarder could skip creating a PIT entry.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_INTLIFE | Length | | T_INTLIFE | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ / / /
/ Lifetime (length octets) / / Lifetime (Length octets) /
/ / / /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 11: Interest Lifetime Encoding
3.4.2. Recommended Cache Time 3.4.2. Recommended Cache Time
The Recommended Cache Time (RCT) is a measure of the useful lifetime The Recommended Cache Time (RCT) is a measure of the useful lifetime
of a Content Object as assigned by a content producer or upstream of a Content Object as assigned by a content producer or upstream
node. It serves as a guideline to the Content Store cache in node. It serves as a guideline to the Content Store cache in
determining how long to keep the Content Object. It is a determining how long to keep the Content Object. It is a
recommendation only and may be ignored by the cache. This is in recommendation only and may be ignored by the cache. This is in
contrast to the ExpiryTime (described in Section 3.6.2.2.2) which contrast to the ExpiryTime (described in Section 3.6.2.2.2) which
takes precedence over the RCT and must be obeyed. takes precedence over the RCT and must be obeyed.
Because the Recommended Cache Time is an optional hop-by-hop header Because the Recommended Cache Time is an optional hop-by-hop header
and not a part of the signed message, a content producer may re-issue and not a part of the signed message, a content producer may re-issue
a previously signed Content Object with an updated RCT without a previously signed Content Object with an updated RCT without
needing to re-sign the message. There is little ill effect from an needing to re-sign the message. There is little ill effect from an
attacker changing the RCT as the RCT serves as a guideline only. attacker changing the RCT as the RCT serves as a guideline only.
The Recommended Cache Time (a millisecond timestamp) is a network The Recommended Cache Time (a millisecond timestamp) is an unsigned
byte ordered unsigned integer of the number of milliseconds since the integer in network byte order that indicates the time when the
epoch in UTC of when the payload expires. It is a 64-bit field. payload expires (as the number of milliseconds since the epoch in
UTC). It is a 64-bit field.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_CACHETIME | 8 | | T_CACHETIME | 8 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ / / /
/ Recommended Cache Time / / Recommended Cache Time /
/ / / /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 12: Recommended Cache Time Encoding
3.4.3. Message Hash 3.4.3. Message Hash
Within a trusted domain, an operator may calculate the message hash Within a trusted domain, an operator may calculate the message hash
at a border device and insert that value into the hop-by-hop headers at a border device and insert that value into the hop-by-hop headers
of a message. An egress device should remove the value. This of a message. An egress device should remove the value. This
permits intermediate devices within that trusted domain to match permits intermediate devices within that trusted domain to match
against a ContentObjectHashRestriction without calculating it at against a ContentObjectHashRestriction without calculating it at
every hop. every hop.
The message hash is a cryptographic hash from the start of the CCNx The message hash is a cryptographic hash from the start of the CCNx
Message to the end of the packet. It is used to match against the Message TLV to the end of the packet. It is used to match against
ContentObjectHashRestriction (Section 3.6.2.1.2). The Message Hash the ContentObjectHashRestriction (Section 3.6.2.1.2). The Message
may be of longer length than an Interest's restriction, in which case Hash may be of longer length than an Interest's restriction, in which
the device should use the left bytes of the Message Hash to check case the device should use the left bytes of the Message Hash to
against the Interest's value. check against the Interest's value.
The Message Hash may only carry one hash type and there may only be The Message Hash may only carry one hash type and there may only be
one Message Hash header. one Message Hash header.
The Message Hash header is unprotected, so this header is only of The Message Hash header is unprotected, so this header is only of
practical use within a trusted domain, such as an operator's practical use within a trusted domain, such as an operator's
autonomous system. autonomous system.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_MSGHASH | (length + 4) | | T_MSGHASH | (length + 4) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| (hash type) | length | | hash type | length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ hash value / / hash value /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Message Hash Header Figure 13: Message Hash Header
3.5. Top-Level Types 3.5. Top-Level Types
The top-level TLV types listed below exist at the outermost level of The top-level TLV types listed below exist at the outermost level of
a CCNx protocol message. a CCNx Message TLV.
+----------------------+-------------------+------------------------+ +----------------------+------------+-------------------------------+
| Abbrev | Name | Description | | Abbrev | Name | Description |
+----------------------+-------------------+------------------------+ +----------------------+------------+-------------------------------+
| T_INTEREST | Interest (Section | An Interest | | T_INTEREST | Interest | An Interest MessageType. |
| | 3.6) | MessageType. | | | (Section | |
| | | | | | 3.6) | |
| T_OBJECT | Content Object | A Content Object | | | | |
| | (Section 3.6) | MessageType | | T_OBJECT | Content | A Content Object MessageType |
| | | | | | Object | |
| T_VALIDATION_ALG | Validation | The method of message | | | (Section | |
| | Algorithm | verification such as | | | 3.6) | |
| | (Section 3.6.4.1) | Message Integrity | | | | |
| | | Check (MIC), a Message | | T_VALIDATION_ALG | Validation | The method of message |
| | | Authentication Code | | | Algorithm | verification such as a |
| | | (MAC), or a | | | (Section | Message Integrity Check |
| | | cryptographic | | | 3.6.4.1) | (MIC), Message Authentication |
| | | signature. | | | | Code (MAC), or cryptographic |
| | | | | | | signature. |
| T_VALIDATION_PAYLOAD | Validation | The validation output, | | | | |
| | Payload (Section | such as the CRC32C | | T_VALIDATION_PAYLOAD | Validation | The validation output, such |
| | 3.6.4.2) | code or the RSA | | | Payload | as the CRC32C code or the RSA |
| | | signature. | | | (Section | signature. |
+----------------------+-------------------+------------------------+ | | 3.6.4.2) | |
+----------------------+------------+-------------------------------+
Table 5: CCNx Top Level Types Table 5: CCNx Top Level Types
3.6. CCNx Message 3.6. CCNx Message TLV
This is the format for the CCNx protocol message itself. The CCNx This is the format for the CCNx Message itself. The CCNx Message TLV
message is the portion of the packet between the hop-by-hop headers is the portion of the CCNx Packet between the hop-by-hop headers and
and the Validation TLVs. The figure below is an expansion of the the Validation TLVs. The figure below is an expansion of the "CCNx
"CCNx Message TLV" depicted in the beginning of Section 3. The CCNx Message TLV" depicted in the beginning of Section 3. The CCNx
message begins with MessageType and runs through the optional Message TLV begins with MessageType and runs through the optional
Payload. The same general format is used for both Interest and Payload. The same general format is used for both Interest and
Content Object messages which are differentiated by the MessageType Content Object messages which are differentiated by the MessageType
field. The first enclosed TLV of a CCNx Message is always the Name field. The first enclosed TLV of a CCNx Message TLV is always the
TLV. This is followed by an optional Message TLVs and an optional Name TLV, if present. This is followed by an optional Message TLVs
Payload TLV. and an optional Payload TLV.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| MessageType | MessageLength | | MessageType | MessageLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Name TLV (Type = T_NAME) | / Name TLV (Type = T_NAME) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional Message TLVs (Various Types) / / Optional Message TLVs (Various Types) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional Payload TLV (Type = T_PAYLOAD) / / Optional Payload TLV (Type = T_PAYLOAD) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
+-----------+-----------------+-------------------------------------+ Figure 14: CCNx Message TLV Encoding
| Abbrev | Name | Description |
+-----------+-----------------+-------------------------------------+
| T_NAME | Name (Section | The CCNx Name requested in an |
| | 3.6.1) | Interest or published in a Content |
| | | Object. |
| | | |
| T_PAYLOAD | Payload | The message payload. |
| | (Section 3.6.3) | |
+-----------+-----------------+-------------------------------------+
Table 6: CCNx Message Types +-----------+---------------+---------------------------------------+
| Abbrev | Name | Description |
+-----------+---------------+---------------------------------------+
| T_NAME | Name (Section | The CCNx Name requested in an |
| | 3.6.1) | Interest or published in a Content |
| | | Object. |
| | | |
| T_PAYLOAD | Payload | The message payload. |
| | (Section | |
| | 3.6.3) | |
+-----------+---------------+---------------------------------------+
Table 6: CCNx Message TLV Types
3.6.1. Name 3.6.1. Name
A Name is a TLV encoded sequence of segments. The table below lists A Name is a TLV encoded sequence of segments. The table below lists
the type values appropriate for these Name segments. A Name MUST NOT the type values appropriate for these name segments. A Name MUST NOT
include PAD TLVs. include Pad TLVs.
As described in CCNx Semantics [CCNSemantics], using the CCNx URI As described in CCNx Semantics [RFC8569], using the CCNx URI
[CCNxURI] notation, a T_NAME with 0 length corresponds to ccnx:/ (the [CCNxURI] notation, a T_NAME with zero length corresponds to "ccnx:/"
default route) and is distinct from a name with one zero length (the default route). The message grammar does not allow the first
segment, such as ccnx:/NAME=. In the TLV encoding, ccnx:/ name segment to have zero length in a CCNx Message TLV Name. In the
corresponds to T_NAME with 0 length, while ccnx:/NAME= corresponds to TLV encoding, "ccnx:/" corresponds to T_NAME with zero length.
T_NAME with 4 length and T_NAMESEGMENT with 0 length.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_NAME | Length | | T_NAME | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Name segment TLVs / / Name segment TLVs /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
+---------------+-------------------+-------------------------------+
| Symbolic Name | Name | Description | Figure 15: Name Encoding
+---------------+-------------------+-------------------------------+
| T_NAMESEGMENT | Name segment | A generic name Segment. | +---------------+-------------+-------------------------------------+
| | (Section 3.6.1.1) | | | Symbolic Name | Name | Description |
| | | | +---------------+-------------+-------------------------------------+
| T_IPID | Interest Payload | An identifier that represents | | T_NAMESEGMENT | Name | A generic name segment. |
| | ID (Section | the Interest Payload field. | | | segment | |
| | 3.6.1.2) | As an example, the Payload ID | | | (Section | |
| | | might be a hash of the | | | 3.6.1.1) | |
| | | Interest Payload. This | | | | |
| | | provides a way to | | T_IPID | Interest | An identifier that represents the |
| | | differentiate between | | | Payload ID | Interest Payload field. As an |
| | | Interests based on their | | | (Section | example, the Payload ID might be a |
| | | payloads without having to | | | 3.6.1.2) | hash of the Interest Payload. This |
| | | parse all the bytes of the | | | | provides a way to differentiate |
| | | payload itself; instead using | | | | between Interests based on their |
| | | only this Payload ID Name | | | | payloads without having to parse |
| | | segment. | | | | all the bytes of the payload |
| | | | | | | itself, and instead using only this |
| T_APP:00 - | Application | Application-specific payload | | | | Payload ID name segment. |
| T_APP:4096 | Components | in a name segment. An | | | | |
| | (Section 3.6.1.1) | application may apply its own | | T_APP:00 - | Application | Application-specific payload in a |
| | | semantics to the 4096 | | T_APP:4096 | Components | name segment. An application may |
| | | reserved types. | | | (Section | apply its own semantics to the 4096 |
+---------------+-------------------+-------------------------------+ | | 3.6.1.1) | reserved types. |
+---------------+-------------+-------------------------------------+
Table 7: CCNx Name Types Table 7: CCNx Name Types
3.6.1.1. Name Segments 3.6.1.1. Name Segments
4096 special application payload name segments are allocated. These 4096 special application payload name segments are allocated. These
have application semantics applied to them. A good convention is to have application semantics applied to them. A good convention is to
put the application's identity in the name prior to using these name put the application's identity in the name prior to using these name
segments. segments.
For example, a name like "ccnx:/foo/bar/hi" would be encoded as: For example, a name like "ccnx:/foo/bar/hi" would be encoded as:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| (T_NAME) | %x14 (20) | | (T_NAME) | 0x14 (20) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| (T_NAME_SEGMENT) | %x03 (3) | | (T_NAME_SEGMENT) | 0x03 (3) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| f o o |(T_NAME_SEGMENT) | f o o |(T_NAME_SEGMENT)
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | %x03 (3) | b | | | 0x03 (3) | b |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| a r | (T_NAME_SEGMENT) | | a r | (T_NAME_SEGMENT) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| %x02 (2) | h | i | | 0x02 (2) | h | i |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 16: Name Encoding Example
3.6.1.2. Interest Payload ID 3.6.1.2. Interest Payload ID
The InterestPayloadID is a name segment created by the origin of an The InterestPayloadID is a name segment created by the origin of an
Interest to represent the Interest Payload. This allows the proper Interest to represent the Interest Payload. This allows the proper
multiplexing of Interests based on their name if they have different multiplexing of Interests based on their name if they have different
payloads. A common representation is to use a hash of the Interest payloads. A common representation is to use a hash of the Interest
Payload as the InterestPayloadID. Payload as the InterestPayloadID.
As part of the TLV 'value', the InterestPayloadID contains a one As part of the Value of the TLV, the InterestPayloadID contains a
identifier of method used to create the InterestPayloadID followed by one-octet identifier of the method used to create the
a variable length octet string. An implementation is not required to InterestPayloadID followed by a variable-length octet string. An
implement any of the methods to receive an Interest; the implementation is not required to implement any of the methods to
InterestPayloadID may be treated only as an opaque octet string for receive an Interest; the InterestPayloadID may be treated only as an
purposes of multiplexing Interests with different payloads. Only a opaque octet string for the purposes of multiplexing Interests with
device creating an InterestPayloadID name segment or a device different payloads. Only a device creating an InterestPayloadID name
verifying such a segment need to implement the algorithms. segment or a device verifying such a segment needs to implement the
algorithms.
It uses the Section 3.3.3 encoding of hash values. It uses the encoding of hash values specified in Section 3.3.3.
In normal operations, we recommend displaying the InterestPayloadID In normal operations, we recommend displaying the InterestPayloadID
as an opaque octet string in a CCNx URI, as this is the common as an opaque octet string in a CCNx URI, as this is the common
denominator for implementation parsing. denominator for implementation parsing.
The InterestPayloadID, even if it is a hash, should not convey any The InterestPayloadID, even if it is a hash, should not convey any
security context. If a system requires confirmation that a specific security context. If a system requires confirmation that a specific
entity created the InterestPayload, it should use a cryptographic entity created the InterestPayload, it should use a cryptographic
signature on the Interest via the ValidationAlgorithm and signature on the Interest via the ValidationAlgorithm and
ValidationPayload or use its own methods inside the Interest Payload. ValidationPayload or use its own methods inside the Interest Payload.
skipping to change at page 20, line 30 skipping to change at page 21, line 40
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| MessageType | MessageLength | | MessageType | MessageLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Name TLV | | Name TLV |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional KeyIdRestriction TLV / / Optional KeyIdRestriction TLV /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
/ Optional ContentObjectHashRestriction TLV / / Optional ContentObjectHashRestriction TLV /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 17: Interest Message TLVs
+----------------+------------------------------+-------------------+ +----------------+------------------------------+-------------------+
| Abbrev | Name | Description | | Abbrev | Name | Description |
+----------------+------------------------------+-------------------+ +----------------+------------------------------+-------------------+
| T_KEYIDRESTR | KeyIdRestriction (Section | A Section 3.3.3 | | T_KEYIDRESTR | KeyIdRestriction (Section | A representation |
| | 3.6.2.1.1) | representation of | | | 3.6.2.1.1) | (as per Section |
| | | the KeyId | | | | 3.3.3) of the |
| | | KeyId |
| | | | | | | |
| T_OBJHASHRESTR | ContentObjectHashRestriction | A Section 3.3.3 | | T_OBJHASHRESTR | ContentObjectHashRestriction | A representation |
| | (Section 3.6.2.1.2) | representation of | | | (Section 3.6.2.1.2) | (as per Section |
| | | the hash of the | | | | 3.3.3) of the |
| | | hash of the |
| | | specific Content | | | | specific Content |
| | | Object that would | | | | Object that would |
| | | satisfy the | | | | satisfy the |
| | | Interest. | | | | Interest. |
+----------------+------------------------------+-------------------+ +----------------+------------------------------+-------------------+
Table 8: CCNx Interest Message TLV Types Table 8: CCNx Interest Message TLV Types
3.6.2.1.1. KeyIdRestriction 3.6.2.1.1. KeyIdRestriction
An Interest MAY include a KeyIdRestriction selector. This ensures An Interest MAY include a KeyIdRestriction selector. This ensures
that only Content Objects with matching KeyIds will satisfy the that only Content Objects with matching KeyIds will satisfy the
Interest. See Section 3.6.4.1.4.1 for the format of a KeyId. Interest. See Section 3.6.4.1.4.1 for the format of a KeyId.
3.6.2.1.2. ContentObjectHashRestriction 3.6.2.1.2. ContentObjectHashRestriction
An Interest MAY contain a ContentObjectHashRestriction selector. An Interest MAY contain a ContentObjectHashRestriction selector.
This is the hash of the Content Object - the self-certifying name This is the hash of the Content Object -- the self-certifying name
restriction that must be verified in the network, if an Interest restriction that must be verified in the network, if an Interest
carried this restriction. It is calculated from the beginning of the carried this restriction (see Message Hash (Section 3.4.3)). The
CCNx Message to the end of the packet. The LENGTH MUST be from one LENGTH MUST be from one of the allowed values for that hash (see
of the allowed values for that hash (see Section 3.3.3). Section 3.3.3).
The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of
length 32 bytes. length 32 bytes.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_OBJHASHRESTR | LENGTH+4 | | T_OBJHASHRESTR | (LENGTH+4) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| <hash type> | LENGTH | | hash type | LENGTH |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ LENGTH octets of hash / / LENGTH octets of hash /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 18: ContentObjectHashRestriction Encoding
3.6.2.2. Content Object Message TLVs 3.6.2.2. Content Object Message TLVs
The following message TLVs are currently defined for Content Objects: The following message TLVs are currently defined for Content Objects:
PayloadType (optional) and ExpiryTime (optional). PayloadType (optional) and ExpiryTime (optional).
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| MessageType | MessageLength | | MessageType | MessageLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Name TLV | | Name TLV |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional PayloadType TLV / / Optional PayloadType TLV /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
/ Optional ExpiryTime TLV / / Optional ExpiryTime TLV /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
+-------------+---------------------+-------------------------------+
| Abbrev | Name | Description | Figure 19: Content Object Message TLVs
+-------------+---------------------+-------------------------------+
| T_PAYLDTYPE | PayloadType | Indicates the type of Payload | +-------------+-------------+---------------------------------------+
| | (Section 3.6.2.2.1) | contents. | | Abbrev | Name | Description |
| | | | +-------------+-------------+---------------------------------------+
| T_EXPIRY | ExpiryTime (Section | The time at which the Payload | | T_PAYLDTYPE | PayloadType | Indicates the type of Payload |
| | 3.6.2.2.2) | expires, as expressed in the | | | (Section | contents. |
| | | number of milliseconds since | | | 3.6.2.2.1) | |
| | | the epoch in UTC. If | | | | |
| | | missing, Content Object may | | T_EXPIRY | ExpiryTime | The time at which the Payload |
| | | be used as long as desired. | | | (Section | expires, as expressed in the number |
+-------------+---------------------+-------------------------------+ | | 3.6.2.2.2) | of milliseconds since the epoch in |
| | | UTC. If missing, Content Object may |
| | | be used as long as desired. |
+-------------+-------------+---------------------------------------+
Table 9: CCNx Content Object Message TLV Types Table 9: CCNx Content Object Message TLV Types
3.6.2.2.1. PayloadType 3.6.2.2.1. PayloadType
The PayloadType is a network byte order integer representing the The PayloadType is an octet representing the general type of the
general type of the Payload TLV. Payload TLV.
o T_PAYLOADTYPE_DATA: Data (possibly encrypted) o T_PAYLOADTYPE_DATA: Data (possibly encrypted)
o T_PAYLOADTYPE_KEY: Key o T_PAYLOADTYPE_KEY: Key
o T_PAYLOADTYPE_LINK: Link o T_PAYLOADTYPE_LINK: Link
The Data type indicate that the Payload of the ContentObject is The Data type indicates that the Payload of the ContentObject is
opaque application bytes. The Key type indicates that the Payload is opaque application bytes. The Key type indicates that the Payload is
a DER encoded public key. The Link type indicates that the Payload a DER-encoded public key. The Link type indicates that the Payload
is one or more Link (Section 3.3.4). If this field is missing, a is one or more Links (Section 3.3.4). If this field is missing, a
"Data" type is assumed. Data type is assumed.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_PAYLDTYPE | Length | | T_PAYLDTYPE | 1 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| PayloadType / | PayloadType |
+---------------+ +---------------+
Figure 20: PayloadType Encoding
3.6.2.2.2. ExpiryTime 3.6.2.2.2. ExpiryTime
The ExpiryTime is the time at which the Payload expires, as expressed The ExpiryTime is the time at which the Payload expires, as expressed
by a timestamp containing the number of milliseconds since the epoch by a timestamp containing the number of milliseconds since the epoch
in UTC. It is a network byte order unsigned integer in a 64-bit in UTC. It is a network byte order unsigned integer in a 64-bit
field. A cache or end system should not respond with a Content field. A cache or end system should not respond with a Content
Object past its ExpiryTime. Routers forwarding a Content Object do Object past its ExpiryTime. Routers forwarding a Content Object do
not need to check the ExpiryTime. If the ExpiryTime field is not need to check the ExpiryTime. If the ExpiryTime field is
missing, the Content Object has no expressed expiration and a cache missing, the Content Object has no expressed expiration, and a cache
or end system may use the Content Object for as long as desired. or end system may use the Content Object for as long as desired.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_EXPIRY | 8 | | T_EXPIRY | 8 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ ExpiryTime / / ExpiryTime /
/ / / /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 21: ExpiryTime encoding
3.6.3. Payload 3.6.3. Payload
The Payload TLV contains the content of the packet. It MAY be of The Payload TLV contains the content of the packet. It MAY be of
zero length. If a packet does not have any payload, this field MAY zero length. If a packet does not have any payload, this field
be omitted, rather than carrying a zero length. SHOULD be omitted, rather than being of zero length.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_PAYLOAD | Length | | T_PAYLOAD | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Payload Contents / / Payload Contents /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 22: Payload Encoding
3.6.4. Validation 3.6.4. Validation
Both Interests and Content Objects have the option to include Both Interests and Content Objects have the option to include
information about how to validate the CCNx message. This information information about how to validate the CCNx Message. This information
is contained in two TLVs: the ValidationAlgorithm TLV and the is contained in two TLVs: the ValidationAlgorithm TLV and the
ValidationPayload TLV. The ValidationAlgorithm TLV specifies the ValidationPayload TLV. The ValidationAlgorithm TLV specifies the
mechanism to be used to verify the CCNx message. Examples include mechanism to be used to verify the CCNx Message. Examples include
verification with a Message Integrity Check (MIC), a Message verification with a Message Integrity Check (MIC), a Message
Authentication Code (MAC), or a cryptographic signature. The Authentication Code (MAC), or a cryptographic signature. The
ValidationPayload TLV contains the validation output, such as the ValidationPayload TLV contains the validation output, such as the
CRC32C code or the RSA signature. CRC32C code or the RSA signature.
An Interest would most likely only use a MIC type of validation - a An Interest would most likely only use a MIC type of validation -- a
crc, checksum, or digest. CRC, checksum, or digest.
3.6.4.1. Validation Algorithm 3.6.4.1. Validation Algorithm
The ValidationAlgorithm is a set of nested TLVs containing all of the The ValidationAlgorithm is a set of nested TLVs containing all of the
information needed to verify the message. The outermost container information needed to verify the message. The outermost container
has type = T_VALIDATION_ALG. The first nested TLV defines the has type = T_VALIDATION_ALG. The first nested TLV defines the
specific type of validation to be performed on the message. The type specific type of validation to be performed on the message. The type
is identified with the "ValidationType" as shown in the figure below is identified with the "ValidationType" as shown in the figure below
and elaborated in the table below. Nested within that container are and elaborated in the table below. Nested within that container are
the TLVs for any ValidationType dependent data, for example a Key Id, the TLVs for any ValidationType-dependent data -- for example, a Key
Key Locator etc. Id, Key Locator, etc.
Complete examples of several types may be found in Section 3.6.4.1.5 Complete examples of several types may be found in Section 3.6.4.1.5.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | ValidationAlgLength | | T_VALIDATION_ALG | ValidationAlgLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| ValidationType | Length | | ValidationType | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ ValidationType dependent data / / ValidationType-dependent data /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
+---------------+---------------------+-----------------------------+ Figure 23: Validation Algorithm Encoding
| Abbrev | Name | Description |
+---------------+---------------------+-----------------------------+ +-----------------+---------------+---------------------------------+
| T_CRC32C | CRC32C (Section | Castagnoli CRC32 (iSCSI, | | Abbrev | Name | Description |
| | 3.6.4.1.1) | ext4, etc.), with normal | +-----------------+---------------+---------------------------------+
| | | form polynomial 0x1EDC6F41. | | T_CRC32C | CRC32C | Castagnoli CRC32 (iSCSI, ext4, |
| | | | | | (Section | etc.) with normal form |
| T_HMAC-SHA256 | HMAC-SHA256 | HMAC (RFC 2104) using | | | 3.6.4.1.1) | polynomial 0x1EDC6F41. |
| | (Section 3.6.4.1.2) | SHA256 hash. | | | | |
| | | | | T_HMAC-SHA256 | HMAC-SHA256 | HMAC (RFC 2104) using SHA256 |
| T_RSA-SHA256 | RSA-SHA256 (Section | RSA public key signature | | | (Section | hash. |
| | 3.6.4.1.3) | using SHA256 digest. | | | 3.6.4.1.2) | |
| | | | | | | |
| EC-SECP-256K1 | SECP-256K1 (Section | Elliptic Curve signature | | T_RSA-SHA256 | RSA-SHA256 | RSA public-key signature using |
| | 3.6.4.1.3) | with SECP-256K1 parameters | | | (Section | SHA256 digest. |
| | | (see [ECC]). | | | 3.6.4.1.3) | |
| | | | | | | |
| EC-SECP-384R1 | SECP-384R1 (Section | Elliptic Curve signature | | T_EC-SECP-256K1 | SECP-256K1 | Elliptic Curve signature with |
| | 3.6.4.1.3) | with SECP-384R1 parameters | | | (Section | SECP-256K1 parameters (see |
| | | (see [ECC]). | | | 3.6.4.1.3) | [ECC]). |
+---------------+---------------------+-----------------------------+ | | | |
| T_EC-SECP-384R1 | SECP-384R1 | Elliptic Curve signature with |
| | (Section | SECP-384R1 parameters (see |
| | 3.6.4.1.3) | [ECC]). |
+-----------------+---------------+---------------------------------+
Table 10: CCNx Validation Types Table 10: CCNx Validation Types
3.6.4.1.1. Message Integrity Checks 3.6.4.1.1. Message Integrity Checks
MICs do not require additional data in order to perform the MICs do not require additional data in order to perform the
verification. An example is CRC32C that has a "0" length value. verification. An example is CRC32C that has a zero-length value.
3.6.4.1.2. Message Authentication Checks 3.6.4.1.2. Message Authentication Codes
MACs are useful for communication between two trusting parties who MACs are useful for communication between two trusting parties who
have already shared private keys. Examples include an RSA signature have already shared secret keys. An example is the HMAC algorithm.
of a SHA256 digest or others. They rely on a KeyId. Some MACs might A MAC uses the KeyId field to identify which shared secret is in use.
use more than a KeyId, but those would be defined in the future. The meaning of the KeyId is specific to the two parties involved and
could be simply an integer to enumerate keys. If a new MAC requires
an additional field, such as an Initialization Vector, that field
would need to be defined as part of the updated specification.
3.6.4.1.3. Signature 3.6.4.1.3. Signature
Signature type Validators specify a digest mechanism and a signing Signature type Validators specify a digest mechanism and a signing
algorithm to verify the message. Examples include RSA signature og a algorithm to verify the message. Examples include an RSA signature
SHA256 digest, an Elliptic Curve signature with SECP-256K1 on a SHA256 digest, an Elliptic Curve signature with SECP-256K1
parameters, etc. These Validators require a KeyId and a mechanism parameters, etc. These Validators require a KeyId and a mechanism
for locating the publishers public key (a KeyLocator) - optionally a for locating the publisher's public key (a KeyLocator) -- and
PublicKey or Certificate or KeyLink. optionally a PublicKey or Certificate or KeyLink.
3.6.4.1.4. Validation Dependent Data 3.6.4.1.4. Validation-Dependent Data
Different Validation Algorithms require access to different pieces of Different Validation Algorithms require access to different pieces of
data contained in the ValidationAlgorithm TLV. As described above, data contained in the ValidationAlgorithm TLV. As described above,
Key Ids, Key Locators, Public Keys, Certificates, Links and Key Names Key Ids, Key Locators, Public Keys, Certificates, Links, and Key
all play a role in different Validation Algorithms. Any number of Names all play a role in different Validation Algorithms. Any number
Validation Dependent Data containers can be present in a Validation of Validation-Dependent Data containers can be present in a
Algorithm TLV. Validation Algorithm TLV.
Following is a table of CCNx ValidationType dependent data types: Below is a table of CCNx ValidationType-dependent data types:
+-------------+-----------------------+-----------------------------+ +-------------+-----------------+-----------------------------------+
| Abbrev | Name | Description | | Abbrev | Name | Description |
+-------------+-----------------------+-----------------------------+ +-------------+-----------------+-----------------------------------+
| T_KEYID | SignerKeyId (Section | An identifier of the shared | | T_KEYID | SignerKeyId | An identifier of the shared |
| | 3.6.4.1.4.1) | secret or public key | | | (Section | secret or public key associated |
| | | associated with a MAC or | | | 3.6.4.1.4.1) | with a MAC or Signature. |
| | | Signature. | | | | |
| | | | | T_PUBLICKEY | Public Key | DER-encoded public key. |
| T_PUBLICKEY | Public Key (Section | DER encoded public key. | | | (Section | |
| | 3.6.4.1.4.2) | | | | 3.6.4.1.4.2) | |
| | | | | | | |
| T_CERT | Certificate (Section | DER encoded X509 | | T_CERT | Certificate | DER-encoded X.509 certificate. |
| | 3.6.4.1.4.3) | certificate. | | | (Section | |
| | | | | | 3.6.4.1.4.3) | |
| T_KEYLINK | KeyLink (Section | A CCNx Link object. | | | | |
| | 3.6.4.1.4.4) | | | T_KEYLINK | KeyLink | A CCNx Link object. |
| | | | | | (Section | |
| T_SIGTIME | SignatureTime | A millsecond timestamp | | | 3.6.4.1.4.4) | |
| | (Section 3.6.4.1.4.5) | indicating the time when | | | | |
| | | the signature was created. | | T_SIGTIME | SignatureTime | A millisecond timestamp |
+-------------+-----------------------+-----------------------------+ | | (Section | indicating the time when the |
| | 3.6.4.1.4.5) | signature was created. |
+-------------+-----------------+-----------------------------------+
Table 11: CCNx Validation Dependent Data Types Table 11: CCNx Validation-Dependent Data Types
3.6.4.1.4.1. KeyId 3.6.4.1.4.1. KeyId
The KeyId is the publisher key identifier. It is similar to a The KeyId for a signature is the publisher key identifier. It is
Subject Key Identifier from X509 [RFC 5280, Section 4.2.1.2]. It similar to a Subject Key Identifier from X.509 (see Section 4.2.1.2
should be derived from the key used to sign, such as from the SHA-256 of [RFC5280]). It should be derived from the key used to sign, such
hash of the key. It applies to both public/private key systems and as from the SHA-256 hash of the key. It applies to both public and
to symmetric key systems. private key systems and to symmetric key systems.
The KeyId is represented using the Section 3.3.3. If a protocol uses The KeyId is represented using the hash format in Section 3.3.3. If
a non-hash identifier, it should use one of the reserved values. an application protocol uses a non-hash identifier, it should use one
of the reserved values.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_KEYID | LENGTH+4 | | T_KEYID | LENGTH+4 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| <hash type> | LENGTH | | <hash type> | LENGTH |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ LENGTH octets of hash / / LENGTH octets of hash /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 24: KeyId Encoding
3.6.4.1.4.2. Public Key 3.6.4.1.4.2. Public Key
A Public Key is a DER encoded Subject Public Key Info block, as in an A Public Key is a DER-encoded Subject Public Key Info block, as in an
X509 certificate. X.509 certificate.
1 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_PUBLICKEY | Length | | T_PUBLICKEY | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Public Key (DER encoded SPKI) / / Public Key (DER-encoded SPKI) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 25: Public Key Encoding
3.6.4.1.4.3. Certificate 3.6.4.1.4.3. Certificate
A Certificate is a DER-encoded X.509 certificate. The KeyId
(Section 3.6.4.1.4.1) is derived from this encoding.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_CERT | Length | | T_CERT | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Certificate (DER encoded X509) / / Certificate (DER-encoded X.509) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 26: Certificate Encoding
3.6.4.1.4.4. KeyLink 3.6.4.1.4.4. KeyLink
A KeyLink type KeyLocator is a Link. A KeyLink type KeyLocator is a Link.
The KeyLink ContentObjectHashRestr, if included, is the digest of the The KeyLink ContentObjectHashRestr, if included, is the digest of the
Content Object identified by KeyLink, not the digest of the public Content Object identified by KeyLink, not the digest of the public
key. Likewise, the KeyIdRestr of the KeyLink is the KeyId of the key. Likewise, the KeyIdRestr of the KeyLink is the KeyId of the
ContentObject, not necessarily of the wrapped key. ContentObject, not necessarily of the wrapped key.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| T_KEYKINK | Length | | T_KEYLINK | Length |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
/ Link / / Link /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 27: KeyLink Encoding
3.6.4.1.4.5. SignatureTime 3.6.4.1.4.5. SignatureTime
The SignatureTime is a millisecond timestamp indicating the time at The SignatureTime is a millisecond timestamp indicating the time at
which a signature was created. The signer sets this field to the which a signature was created. The signer sets this field to the
current time when creating a signature. A verifier may use this time current time when creating a signature. A verifier may use this time
to determine whether or not the signature was created during the to determine whether or not the signature was created during the
validity period of a key, or if it occurred in a reasonable sequence validity period of a key, or if it occurred in a reasonable sequence
with other associated signatures. The SignatureTime is unrelated to with other associated signatures. The SignatureTime is unrelated to
any time associated with the actual CCNx Message, which could have any time associated with the actual CCNx Message, which could have
been created long before the signature. The default behavior is to been created long before the signature. The default behavior is to
always include a SignatureTime when creating an authenticated message always include a SignatureTime when creating an authenticated message
(e.g. HMAC or RSA). (e.g., HMAC or RSA).
SignatureTime is a network byte ordered unsigned integer of the SignatureTime is an unsigned integer in network byte order that
number of milliseconds since the epoch in UTC of when the signature indicates when the signature was created (as the number of
was created. It is a fixed 64-bit field. milliseconds since the epoch in UTC). It is a fixed 64-bit field.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| T_SIGTIME | 8 | | T_SIGTIME | 8 |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
/ SignatureTime / / SignatureTime /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 28: SignatureTime Encoding
3.6.4.1.5. Validation Examples 3.6.4.1.5. Validation Examples
As an example of a MIC type validation, the encoding for CRC32C As an example of a MIC-type validation, the encoding for CRC32C
validation would be: validation would be:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 4 | | T_VALIDATION_ALG | 4 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_CRC32C | 0 | | T_CRC32C | 0 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
As an example of a MAC type validation, the encoding for an HMAC Figure 29: CRC32C Encoding Example
As an example of a MAC-type validation, the encoding for an HMAC
using a SHA256 hash would be: using a SHA256 hash would be:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 40 | | T_VALIDATION_ALG | 40 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_HMAC-SHA256 | 36 | | T_HMAC-SHA256 | 36 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_KEYID | 32 | | T_KEYID | 32 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ KeyId / / KeyId /
/---------------+---------------+-------------------------------+ /---------------+---------------+-------------------------------+
As an example of a Signature type validation, the encoding for an RSA Figure 30: HMAC-SHA256 Encoding Example
public key signing using a SHA256 digest and Public Key would be:
As an example of a Signature-type validation, the encoding for an RSA
public-key signature using a SHA256 digest and Public Key would be:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 44 + Variable Length | | T_VALIDATION_ALG | 44 octets + Variable Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_RSA-SHA256 | 40 + Variable Length | | T_RSA-SHA256 | 40 octets + Variable Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_KEYID | 32 | | T_KEYID | 32 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ KeyId / / KeyId /
/---------------+---------------+-------------------------------+ /---------------+---------------+-------------------------------+
| T_PUBLICKEY | Variable Length (~ 160) | | T_PUBLICKEY | Variable Length (~160 octets)|
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Public Key (DER encoded SPKI) / / Public Key (DER-encoded SPKI) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 31: RSA-SHA256 Encoding Example
3.6.4.2. Validation Payload 3.6.4.2. Validation Payload
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_VALIDATION_PAYLOAD | ValidationPayloadLength | | T_VALIDATION_PAYLOAD | ValidationPayloadLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Type-dependent data / / Type-dependent data /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 32: Validation Payload Encoding
The ValidationPayload contains the validation output, such as the The ValidationPayload contains the validation output, such as the
CRC32C code or the RSA signature. CRC32C code or the RSA signature.
4. IANA Considerations 4. IANA Considerations
This section details each kind of protocol value that can be This section details each kind of CCNx protocol value that can be
registered. Each type registry can be updated by incrementally registered. Each type registry can be updated by incrementally
expanding the type space, i.e., by allocating and reserving new expanding the type space, i.e., by allocating and reserving new
types. As per [RFC5226] this section details the creation of the types. As per [RFC8126], this section details the creation of the
"CCNx Registry" and several sub-registries. "Content-Centric Networking (CCNx)" registry and several
subregistries.
+----------+---------------+
| Property | Value |
+----------+---------------+
| Name | CCNx Registry |
| | |
| Abbrev | CCNx |
+----------+---------------+
Registry Creation
4.1. Packet Type Registry 4.1. Packet Type Registry
The following packet types should be allocated. A PacketType MUST be IANA has created the "CCNx Packet Types" registry and allocated the
1 byte. New packet types are allocated via "RFC Required" action. packet types described below. The registration procedure is RFC
Required. The Type value is 1 octet. The range is 0x00-0xFF.
+----------------+----------------------+
| Property | Value |
+----------------+----------------------+
| Name | Packet Type Registry |
| | |
| Parent | CCNx Registry |
| | |
| Review process | RFC Required |
| | |
| Syntax | 1 octet |
+----------------+----------------------+
Registry Creation
+------+-------------+----------------------------------+ +------+-------------+----------------------------------+
| Type | Name | Reference | | Type | Name | Reference |
+------+-------------+----------------------------------+ +------+-------------+----------------------------------+
| %x00 | PT_INTEREST | Fixed Header Types (Section 3.2) | | 0x00 | PT_INTEREST | Fixed Header Types (Section 3.2) |
| | | | | | | |
| %x01 | PT_CONTENT | Fixed Header Types (Section 3.2) | | 0x01 | PT_CONTENT | Fixed Header Types (Section 3.2) |
| | | | | | | |
| %x02 | PT_RETURN | Fixed Header Types (Section 3.2) | | 0x02 | PT_RETURN | Fixed Header Types (Section 3.2) |
+------+-------------+----------------------------------+ +------+-------------+----------------------------------+
Packet Type Namespace Packet Types
4.2. Interest Return Code Registry 4.2. Interest Return Code Registry
The following InterestReturn code types should be allocated. IANA has created the "CCNx Interest Return Code Types" registry and
allocated the Interest Return code types described below. The
+----------------+------------------------+ registration procedure is Specification Required. The Type value is
| Property | Value | 1 octet. The range is 0x00-0xFF.
+----------------+------------------------+
| Name | Interest Return Code |
| | |
| Parent | CCNx Registry |
| | |
| Review process | Specification Required |
| | |
| Syntax | 1 octet |
+----------------+------------------------+
Registry Creation
+------+---------------------------------------+--------------------+ +------+---------------------------------------+--------------------+
| Type | Name | Reference | | Type | Name | Reference |
+------+---------------------------------------+--------------------+ +------+---------------------------------------+--------------------+
| %x00 | Reserved | | | 0x00 | Reserved | |
| | | | | | | |
| %x01 | T_RETURN_NO_ROUTE | Fixed Header Types | | 0x01 | T_RETURN_NO_ROUTE | Fixed Header Types |
| | | (Section 3.2.3.3) | | | | (Section 3.2.3.3) |
| | | | | | | |
| %x02 | T_RETURN_LIMIT_EXCEEDED | Fixed Header Types | | 0x02 | T_RETURN_LIMIT_EXCEEDED | Fixed Header Types |
| | | (Section 3.2.3.3) | | | | (Section 3.2.3.3) |
| | | | | | | |
| %x03 | T_RETURN_NO_RESOURCES | Fixed Header Types | | 0x03 | T_RETURN_NO_RESOURCES | Fixed Header Types |
| | | (Section 3.2.3.3) | | | | (Section 3.2.3.3) |
| | | | | | | |
| %x04 | T_RETURN_PATH_ERROR | Fixed Header Types | | 0x04 | T_RETURN_PATH_ERROR | Fixed Header Types |
| | | (Section 3.2.3.3) | | | | (Section 3.2.3.3) |
| | | | | | | |
| %x05 | T_RETURN_PROHIBITED | Fixed Header Types | | 0x05 | T_RETURN_PROHIBITED | Fixed Header Types |
| | | (Section 3.2.3.3) | | | | (Section 3.2.3.3) |
| | | | | | | |
| %x06 | T_RETURN_CONGESTED | Fixed Header Types | | 0x06 | T_RETURN_CONGESTED | Fixed Header Types |
| | | (Section 3.2.3.3) | | | | (Section 3.2.3.3) |
| | | | | | | |
| %x07 | T_RETURN_MTU_TOO_LARGE | Fixed Header Types | | 0x07 | T_RETURN_MTU_TOO_LARGE | Fixed Header Types |
| | | (Section 3.2.3.3) | | | | (Section 3.2.3.3) |
| | | | | | | |
| %x08 | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types | | 0x08 | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types |
| | | (Section 3.2.3.3) | | | | (Section 3.2.3.3) |
| | | | | | | |
| %x09 | T_RETURN_MALFORMED_INTEREST | Fixed Header Types | | 0x09 | T_RETURN_MALFORMED_INTEREST | Fixed Header Types |
| | | (Section 3.2.3.3) | | | | (Section 3.2.3.3) |
+------+---------------------------------------+--------------------+ +------+---------------------------------------+--------------------+
Interest Return Type Namespace CCNx Interest Return Types
4.3. Hop-by-Hop Type Registry 4.3. Hop-by-Hop Type Registry
The following hop-by-hop types should be allocated. IANA has created the "CCNx Hop-by-Hop Types" registry and allocated
the hop-by-hop types described below. The registration procedure is
+----------------+--------------------------+ RFC Required. The Type value is 2 octets. The range is
| Property | Value | 0x0000-0xFFFF.
+----------------+--------------------------+
| Name | Hop-by-Hop Type Registry |
| | |
| Parent | CCNx Registry |
| | |
| Review process | RFC Required |
| | |
| Syntax | 2 octet TLV type |
+----------------+--------------------------+
Registry Creation
+---------------+-------------+-------------------------------------+ +---------------+-------------+-------------------------------------+
| Type | Name | Reference | | Type | Name | Reference |
+---------------+-------------+-------------------------------------+ +---------------+-------------+-------------------------------------+
| %x0000 | Reserved | | | 0x0000 | Reserved | |
| | | | | | | |
| %x0001 | T_INTLIFE | Hop-by-hop TLV headers (Section | | 0x0001 | T_INTLIFE | Hop-by-hop TLV headers (Section |
| | | 3.4) | | | | 3.4) |
| | | | | | | |
| %x0002 | T_CACHETIME | Hop-by-hop TLV headers (Section | | 0x0002 | T_CACHETIME | Hop-by-hop TLV headers (Section |
| | | 3.4) | | | | 3.4) |
| | | | | | | |
| %x0003 | T_MSGHASH | Hop-by-hop TLV headers (Section | | 0x0003 | T_MSGHASH | Hop-by-hop TLV headers (Section |
| | | 3.4) | | | | 3.4) |
| | | | | | | |
| %x0004 - | Reserved | | | 0x0004 - | Reserved | |
| %x0007 | | | | 0x0007 | | |
| | | | | | | |
| %x0FFE | T_PAD | Pad (Section 3.3.1) | | 0x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | | | | | |
| %x0FFF | T_ORG | Organization-Specific TLVs (Section | | 0x0FFF | T_ORG | Organization-Specific TLVs (Section |
| | | 3.3.2) | | | | 3.3.2) |
| | | | | | | |
| %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | | 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+-------------+-------------------------------------+ +---------------+-------------+-------------------------------------+
Hop-by-Hop Type Namespace CCNx Hop-by-Hop Types
4.4. Top-Level Type Registry 4.4. Top-Level Type Registry
The following top-level types should be allocated. IANA has created the "CCNx Top-Level Types" registry and allocated
the top-level types described below. The registration procedure is
+----------------+-------------------------+ RFC Required. The Type value is 2 octets. The range is
| Property | Value | 0x0000-0xFFFF.
+----------------+-------------------------+
| Name | Top-Level Type Registry |
| | |
| Parent | CCNx Registry |
| | |
| Review process | RFC Required |
| | |
| Syntax | 2 octet TLV type |
+----------------+-------------------------+
Registry Creation
+--------+----------------------+-------------------------------+ +--------+----------------------+-------------------------------+
| Type | Name | Reference | | Type | Name | Reference |
+--------+----------------------+-------------------------------+ +--------+----------------------+-------------------------------+
| %x0000 | Reserved | | | 0x0000 | Reserved | |
| | | | | | | |
| %x0001 | T_INTEREST | Top-Level Types (Section 3.5) | | 0x0001 | T_INTEREST | Top-Level Types (Section 3.5) |
| | | | | | | |
| %x0002 | T_OBJECT | Top-Level Types (Section 3.5) | | 0x0002 | T_OBJECT | Top-Level Types (Section 3.5) |
| | | | | | | |
| %x0003 | T_VALIDATION_ALG | Top-Level Types (Section 3.5) | | 0x0003 | T_VALIDATION_ALG | Top-Level Types (Section 3.5) |
| | | | | | | |
| %x0004 | T_VALIDATION_PAYLOAD | Top-Level Types (Section 3.5) | | 0x0004 | T_VALIDATION_PAYLOAD | Top-Level Types (Section 3.5) |
+--------+----------------------+-------------------------------+ +--------+----------------------+-------------------------------+
Top-Level Type Namespace CCNx Top-Level Types
4.5. Name Segment Type Registry 4.5. Name Segment Type Registry
The following name segment types should be allocated. IANA has created the "CCNx Name Segment Types" registry and allocated
the name segment types described below. The registration procedure
+----------------+----------------------------+ is Specification Required. The Type value is 2 octets. The range is
| Property | Value | 0x0000-0xFFFF.
+----------------+----------------------------+
| Name | Name Segment Type Registry |
| | |
| Parent | CCNx Registry |
| | |
| Review process | Specification Required |
| | |
| Syntax | 2 octet TLV type |
+----------------+----------------------------+
Registry Creation
+--------------+------------------+---------------------------------+ +--------------+------------------+---------------------------------+
| Type | Name | Reference | | Type | Name | Reference |
+--------------+------------------+---------------------------------+ +--------------+------------------+---------------------------------+
| %x0000 | Reserved | | | 0x0000 | Reserved | |
| | | | | | | |
| %x0001 | T_NAMESEGMENT | Name (Section 3.6.1) | | 0x0001 | T_NAMESEGMENT | Name (Section 3.6.1) |
| | | | | | | |
| %x0002 | T_IPID | Name (Section 3.6.1) | | 0x0002 | T_IPID | Name (Section 3.6.1) |
| | | | | | | |
| %x0010 - | Reserved | Used in other drafts | | 0x0010 - | Reserved | RFC 8609 |
| %x0013 | | | | 0x0013 | | |
| | | | | | | |
| %x0FFF | T_ORG | Organization-Specific TLVs | | 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) | | | | (Section 3.3.2) |
| | | | | | | |
| %x1000 - | T_APP:00 - | Application Components (Section | | 0x1000 - | T_APP:00 - | Application Components (Section |
| %x1FFF | T_APP:4096 | 3.6.1) | | 0x1FFF | T_APP:4096 | 3.6.1) |
+--------------+------------------+---------------------------------+ +--------------+------------------+---------------------------------+
Name Segment Type Namespace CCNx Name Segment Types
4.6. Message Type Registry 4.6. Message Type Registry
The following CCNx message segment types should be allocated. IANA has created the "CCNx Message Types" registry and registered the
message segment types described below. The registration procedure is
+----------------+-----------------------+ RFC Required. The Type value is 2 octets. The range is
| Property | Value | 0x0000-0xFFFF.
+----------------+-----------------------+
| Name | Message Type Registry |
| | |
| Parent | CCNx Registry |
| | |
| Review process | RFC Required |
| | |
| Syntax | 2 octet TLV type |
+----------------+-----------------------+
Registry Creation
+---------------+----------------+----------------------------------+ +---------------+----------------+----------------------------------+
| Type | Name | Reference | | Type | Name | Reference |
+---------------+----------------+----------------------------------+ +---------------+----------------+----------------------------------+
| %x0000 | T_NAME | Message Types (Section 3.6) | | 0x0000 | T_NAME | Message Types (Section 3.6) |
| | | | | | | |
| %x0001 | T_PAYLOAD | Message Types (Section 3.6) | | 0x0001 | T_PAYLOAD | Message Types (Section 3.6) |
| | | | | | | |
| %x0002 | T_KEYIDRESTR | Message Types (Section 3.6) | | 0x0002 | T_KEYIDRESTR | Message Types (Section 3.6) |
| | | | | | | |
| %x0003 | T_OBJHASHRESTR | Message Types (Section 3.6) | | 0x0003 | T_OBJHASHRESTR | Message Types (Section 3.6) |
| | | | | | | |
| %x0005 | T_PAYLDTYPE | Content Object Message Types | | 0x0005 | T_PAYLDTYPE | Content Object Message Types |
| | | (Section 3.6.2.2) | | | | (Section 3.6.2.2) |
| | | | | | | |
| %x0006 | T_EXPIRY | Content Object Message Types | | 0x0006 | T_EXPIRY | Content Object Message Types |
| | | (Section 3.6.2.2) | | | | (Section 3.6.2.2) |
| | | | | | | |
| %x0007 - | Reserved | Used in other RFC drafts | | 0x0007 - | Reserved | RFC 8609 |
| %x000C | | | | 0x000C | | |
| | | | | | | |
| %x0FFE | T_PAD | Pad (Section 3.3.1) | | 0x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | | | | | |
| %x0FFF | T_ORG | Organization-Specific TLVs | | 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) | | | | (Section 3.3.2) |
| | | | | | | |
| %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | | 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+----------------+----------------------------------+ +---------------+----------------+----------------------------------+
CCNx Message Type Namespace CCNx Message Types
4.7. Payload Type Registry 4.7. Payload Type Registry
The following payload types should be allocated. IANA has created the "CCNx Payload Types" registry and allocated the
payload types described below. The registration procedure is
+----------------+----------------------------------+ Specification Required. The Type value is 1 octet. The range is
| Property | Value | 0x00-0xFF.
+----------------+----------------------------------+
| Name | PayloadType Registry |
| | |
| Parent | CCNx Registry |
| | |
| Review process | Specification Required |
| | |
| Syntax | Variable length unsigned integer |
+----------------+----------------------------------+
Registry Creation
+------+--------------------+-----------------------------------+ +------+--------------------+-----------------------------------+
| Type | Name | Reference | | Type | Name | Reference |
+------+--------------------+-----------------------------------+ +------+--------------------+-----------------------------------+
| %x00 | T_PAYLOADTYPE_DATA | Payload Types (Section 3.6.2.2.1) | | 0x00 | T_PAYLOADTYPE_DATA | Payload Types (Section 3.6.2.2.1) |
| | | | | | | |
| %x01 | T_PAYLOADTYPE_KEY | Payload Types (Section 3.6.2.2.1) | | 0x01 | T_PAYLOADTYPE_KEY | Payload Types (Section 3.6.2.2.1) |
| | | | | | | |
| %x02 | T_PAYLOADTYPE_LINK | Payload Types (Section 3.6.2.2.1) | | 0x02 | T_PAYLOADTYPE_LINK | Payload Types (Section 3.6.2.2.1) |
+------+--------------------+-----------------------------------+ +------+--------------------+-----------------------------------+
Payload Type Namespace CCNx Payload Types
4.8. Validation Algorithm Type Registry 4.8. Validation Algorithm Type Registry
The following validation algorithm types should be allocated. Note: IANA has created the "CCNx Validation Algorithm Types" registry and
registration requires public specification of the algorithm. allocated the validation algorithm types described below. The
registration procedure is Specification Required. The Type value is
+----------------+------------------------------------+ 2 octets. The range is 0x0000-0xFFFF.
| Property | Value |
+----------------+------------------------------------+
| Name | Validation Algorithm Type Registry |
| | |
| Parent | CCNx Registry |
| | |
| Review process | Specification Required |
| | |
| Syntax | 2 octet TLV type |
+----------------+------------------------------------+
Registry Creation
+---------------+---------------+-----------------------------------+
| Type | Name | Reference |
+---------------+---------------+-----------------------------------+
| %x0000 | Reserved | |
| | | |
| %x0001 | Unassigned | |
| | | |
| %x0002 | T_CRC32C | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| %x0003 | Unassigned | |
| | | |
| %x0004 | T_HMAC-SHA256 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| %x0005 | T_RSA-SHA256 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| %x0006 | EC-SECP-256K1 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| %x0007 | EC-SECP-384R1 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| %x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | |
| %x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| %x1000-%x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+---------------+-----------------------------------+
Validation Algorithm Type Namespace
4.9. Validation Dependent Data Type Registry +---------------+-----------------+---------------------------------+
| Type | Name | Reference |
+---------------+-----------------+---------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0002 | T_CRC32C | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0004 | T_HMAC-SHA256 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0005 | T_RSA-SHA256 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0006 | T_EC-SECP-256K1 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0007 | T_EC-SECP-384R1 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+-----------------+---------------------------------+
The following validation dependent data types should be allocated. CCNx Validation Algorithm Types
+----------------+-----------------------------------------+ 4.9. Validation-Dependent Data Type Registry
| Property | Value |
+----------------+-----------------------------------------+
| Name | Validation Dependent Data Type Registry |
| | |
| Parent | CCNx Registry |
| | |
| Review process | RFC Required |
| | |
| Syntax | 2 octet TLV type |
+----------------+-----------------------------------------+
Registry Creation IANA has created the "CCNx Validation-Dependent Data Types" registry
and allocated the validation-dependent data types described below.
The registration procedure is RFC Required. The Type value is 2
octets. The range is 0x0000-0xFFFF.
+---------------+----------------+----------------------------------+ +---------------+----------------+----------------------------------+
| Type | Name | Reference | | Type | Name | Reference |
+---------------+----------------+----------------------------------+ +---------------+----------------+----------------------------------+
| %x0000 | Reserved | | | 0x0000 | Reserved | |
| | | |
| %x0001 - | Unassigned | |
| %x0008 | | |
| | | | | | | |
| %x0009 | T_KEYID | Validation Dependent Data | | 0x0009 | T_KEYID | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) | | | | (Section 3.6.4.1.4) |
| | | | | | | |
| %x000A | T_PUBLICKEYLOC | Validation Dependent Data | | 0x000A | T_PUBLICKEYLOC | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) | | | | (Section 3.6.4.1.4) |
| | | | | | | |
| %x000B | T_PUBLICKEY | Validation Dependent Data | | 0x000B | T_PUBLICKEY | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) | | | | (Section 3.6.4.1.4) |
| | | | | | | |
| %x000C | T_CERT | Validation Dependent Data | | 0x000C | T_CERT | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) | | | | (Section 3.6.4.1.4) |
| | | | | | | |
| %x000D | T_LINK | Validation Dependent Data | | 0x000D | T_LINK | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) | | | | (Section 3.6.4.1.4) |
| | | | | | | |
| %x000E | T_KEYLINK | Validation Dependent Data | | 0x000E | T_KEYLINK | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) | | | | (Section 3.6.4.1.4) |
| | | | | | | |
| %x000F | T_SIGTIME | Validation Dependent Data | | 0x000F | T_SIGTIME | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) | | | | (Section 3.6.4.1.4) |
| | | | | | | |
| %x0FFF | T_ORG | Organization-Specific TLVs | | 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) | | | | (Section 3.3.2) |
| | | | | | | |
| %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | | 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+----------------+----------------------------------+ +---------------+----------------+----------------------------------+
Validation Dependent Data Type Namespace CCNx Validation-Dependent Data Types
4.10. Hash Function Type Registry 4.10. Hash Function Type Registry
The following CCNx hash function types should be allocated. Note: IANA has created the "CCNx Hash Function Types" registry and
registration requires public specification of the algorithm. allocated the hash function types described below. The registration
procedure is Specification Required. The Type value is 2 octets.
+----------------+-----------------------------+ The range is 0x0000-0xFFFF.
| Property | Value |
+----------------+-----------------------------+
| Name | Hash Function Type Registry |
| | |
| Parent | CCNx Registry |
| | |
| Review process | Specification Required |
| | |
| Syntax | 2 octet TLV type |
+----------------+-----------------------------+
Registry Creation
+---------------+-----------+---------------------------------------+ +---------------+-----------+---------------------------------------+
| Type | Name | Reference | | Type | Name | Reference |
+---------------+-----------+---------------------------------------+ +---------------+-----------+---------------------------------------+
| %x0000 | Reserved | | | 0x0000 | Reserved | |
| | | | | | | |
| %x0001 | T_SHA-256 | Hash Format (Section 3.3.3) | | 0x0001 | T_SHA-256 | Hash Format (Section 3.3.3) |
| | | | | | | |
| %x0002 | T_SHA-512 | Hash Format (Section 3.3.3) | | 0x0002 | T_SHA-512 | Hash Format (Section 3.3.3) |
| | | | | | | |
| %x0FFF | T_ORG | Organization-Specific TLVs (Section | | 0x0FFF | T_ORG | Organization-Specific TLVs (Section |
| | | 3.3.2) | | | | 3.3.2) |
| | | | | | | |
| %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | | 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+-----------+---------------------------------------+ +---------------+-----------+---------------------------------------+
CCNx Hash Function Type Namespace CCNx Hash Function Types
5. Security Considerations 5. Security Considerations
The CCNx protocol is a layer 3 network protocol, which may also The CCNx protocol is a Layer 3 network protocol, which may also
operate as an overlay using other transports, such as UDP or other operate as an overlay using other transports such as UDP or other
tunnels. It includes intrinsic support for message authentication tunnels. It includes intrinsic support for message authentication
via a signature (e.g. RSA or elliptic curve) or message via a signature (e.g., RSA or elliptic curve) or Message
authentication code (e.g. HMAC). In lieu of an authenticator, it Authentication Code (e.g., HMAC). In lieu of an authenticator, it
may instead use a message integrity check (e.g. SHA or CRC). CCNx may instead use a Message Integrity Check (e.g., SHA or CRC). CCNx
does not specify an encryption envelope, that function is left to a does not specify an encryption envelope; that function is left to a
high-layer protocol (e.g. [esic]). high-layer protocol (e.g., Encrypted Sessions in CCNx [esic]).
The CCNx message format includes the ability to attach MICs (e.g. The CCNx Packet format includes the ability to attach MICs (e.g.,
SHA-256 or CRC), MACs (e.g. HMAC), and Signatures (e.g. RSA or SHA-256 or CRC), MACs (e.g., HMAC), and Signatures (e.g., RSA or
ECDSA) to all packet types. This does not mean that it is a good ECDSA) to all packet types. Because Interest packets can be sent at
idea to use an arbitrary ValidationAlgorithm, nor to include will, an application should carefully select when to use a given
computationally expensive algorithms in Interest packets, as that ValidationAlgorithm in an Interest to avoid DoS attacks. MICs, for
could lead to computational DoS attacks. Applications should use an example, are inexpensive and could be used as desired, whereas MACs
and Signatures are more expensive and their inappropriate use could
open a computational DoS attack surface. Applications should use an
explicit protocol to guide their use of packet signatures. As a explicit protocol to guide their use of packet signatures. As a
general guideline, an application might use a MIC on an Interest to general guideline, an application might use a MIC on an Interest to
detect unintentionally corrupted packets. If one wishes to secure an detect 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 a Layer 3 protocol, this document does not describe how one
arrives at keys or how one trusts keys. The CCNx content object may arrives at keys or how one trusts keys. The CCNx content object may
include a public key embedded in the object or may use the include a public key embedded in the object or may use the
PublicKeyLocator field to point to a public key (or public key PublicKeyLocator field to point to a public key (or public-key
certificate) that authenticates the message. One key exchange certificate) that authenticates the message. One key exchange
specification is CCNxKE [ccnxke] [mobile], which is similar to the specification is CCNxKE [ccnxke] [mobile], which is similar to the
TLS 1.3 key exchange except it is over the CCNx layer 3 messages. TLS 1.3 key exchange except it is over the CCNx Layer 3 messages.
Trust is beyond the scope of a layer-3 protocol protocol and left to Trust is beyond the scope of a Layer 3 protocol and is 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 [ccnxke])
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.
This document uses a type-length-value (TLV) encoding. We chose to This document 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 variable-
fields to accomodate a wide gamut of values while trying to be byte- length L fields to accommodate a wide gamut of values while trying to
efficient. Our TLV encoding uses a fixed length 2-byte T and 2-byte be byte efficient. Our TLV encoding uses a fixed length 2-byte T and
L. Using a fixed-length T and L field solves two problems. The 2-byte L. Using fixed-length T and L fields solves two problems.
first is aliases. If one is able to encode the same value, such as The first is aliases. If one is able to encode the same value, such
0x2 and 0x02, in different byte lengths then one must decide if they as 0x02 and 0x0002, in different byte lengths, then one must decide
mean the same thing, if they are different, or if one is illegal. If if they mean the same thing, if they are different, or if one is
they are different, then one must always compare on the buffers not illegal. If they are different, then one must always compare on the
the integer equivalents. If one is illegal, then one must validate buffers not the integer equivalents. If one is illegal, then one
the TLV encoding -- every field of every packet at every hop. If must validate the TLV encoding -- every field of every packet at
they are the same, then one has the second problem: how to specify every hop. If they are the same, then one has the second problem:
packet filters. For example, if a name has 6 name components, then how to specify packet filters. For example, if a name has 6 name
there are 7 T's and 7 L's, each of which might have up to 4 components, then there are 7 T fields and 7 L fields, each of which
representations of the same value. That would be 14 fields with 4 might have up to 4 representations of the same value. That would be
encodings each, or 1001 combinations. It also means that one cannot 14 fields with 4 encodings each, or 1001 combinations. It also means
compare, for example, a name via a memory function as one needs to that one cannot compare, for example, a name via a memory function,
consider that any embedded T or L might have a different format. 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
[CCNSemantics] to avoid certain types of attacks. Unlike NDN, CCNx [RFC8569] 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
they want and the content store (and every forward hop) can easily Store (and every forward hop) can easily verify that the content
verify that the content matches the request. In the signature matches the request. In the signature restricted case (which is
verified case (often used for initial manifest discovery), the often used for initial manifest discovery), the requester only knows
requester only knows the KeyId that signed the content. It is this the KeyId that signed the content. This case 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 according to the PublicKeyLocator. However,
not, however, a burden we wish to impose on the forwarder. A user- that is not a burden we wish to impose on the forwarder. A user-
level cache could also rely on out-of-band attestation, such as the level cache could also rely on out-of-band attestation, such as the
cache operator only inserting content that it knows has the correct cache operator only inserting content that it knows has the correct
signature. 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, and it could cause backward compatibility problems if the
hash type is updated. hash type is updated.
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 for
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].
6. References 6. References
6.1. Normative References 6.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>.
6.2. Informative References 6.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- 2015, <http://new.named-data.net/wp-content/uploads/2015/
content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf>. 12/ndn-0036-1-ndn-ace.pdf>.
[CCNSemantics]
Mosko, M., Solis, I., and C. Wood, "CCNx Semantics
(Internet draft)", 2018, <https://www.ietf.org/id/draft-
irtf-icnrg-ccnxsemantics-09.txt>.
[ccnxke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange [ccnxke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange
Protocol Version 1.0", 2017, Protocol Version 1.0", Work in Progress, draft-wood-icnrg-
<https://www.ietf.org/archive/id/draft-wood-icnrg- ccnxkeyexchange-02, March 2017.
ccnxkeyexchange-02.txt>.
[CCNxURI] Mosko, M. and C. Wood, "The CCNx URI Scheme (Internet [CCNxURI] 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>.
[CCNxz] Mosko, M., "CCNxz TLV Header Compression Experimental [CCNxz] Mosko, M., "CCNxz TLV Header Compression Experimental
Code", 2016-2018, <https://github.com/PARC/CCNxz>. Code", commit f1093a2, March 2018,
<https://github.com/PARC/CCNxz>.
[compress] [compress] Mosko, M., "Header Compression for TLV-based Packets",
Mosko, M., "Header Compression for TLV-based Packets", ICNRG Interim Meeting, 2016,
2016, <https://datatracker.ietf.org/meeting/interim-2016- <https://datatracker.ietf.org/meeting/interim-2016-icnrg-
icnrg-02/materials/slides-interim-2016-icnrg-2-7>. 02/materials/slides-interim-2016-icnrg-2-7>.
[ECC] Certicom Research, "SEC 2: Recommended Elliptic Curve [ECC] Certicom Research, "SEC 2: Recommended Elliptic Curve
Domain Parameters", 2010, Domain Parameters", 2010,
<http://www.secg.org/sec2-v2.pdf>. <http://www.secg.org/sec2-v2.pdf>.
[EpriseNumbers]
IANA, "IANA Private Enterprise Numbers", 2015,
<http://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.
[IANA-PEN] IANA, "Private Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers>.
[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, 2017,
<http://dl.ifip.org/db/conf/networking/ <http://dl.ifip.org/db/conf/networking/
networking2017/1570334964.pdf>. networking2017/1570334964.pdf>.
[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 (CoNEXT
'09), 2009, <http://dx.doi.org/10.1145/1658939.1658941>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
IANA Considerations Section in RFCs", RFC 5226, Housley, R., and W. Polk, "Internet X.509 Public Key
DOI 10.17487/RFC5226, May 2008, <https://www.rfc- Infrastructure Certificate and Certificate Revocation List
editor.org/info/rfc5226>. (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., [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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Semantics", RFC 8569,
DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>.
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: mmosko@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. 300 change blocks. 
902 lines changed or deleted 857 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/