diff options
Diffstat (limited to 'doc/rfc/rfc8609.txt')
| -rw-r--r-- | doc/rfc/rfc8609.txt | 2579 |
1 files changed, 2579 insertions, 0 deletions
diff --git a/doc/rfc/rfc8609.txt b/doc/rfc/rfc8609.txt new file mode 100644 index 0000000..1ff4d72 --- /dev/null +++ b/doc/rfc/rfc8609.txt @@ -0,0 +1,2579 @@ + + + + + + +Internet Research Task Force (IRTF) M. Mosko +Request for Comments: 8609 PARC, Inc. +Category: Experimental I. Solis +ISSN: 2070-1721 LinkedIn + C. Wood + University of California Irvine + July 2019 + + + Content-Centric Networking (CCNx) Messages in TLV Format + +Abstract + + Content-Centric Networking (CCNx) is a network protocol that uses a + hierarchical name to forward requests and to match responses to + requests. This document specifies the encoding of CCNx messages in a + 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 + 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 + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the consensus of the + Information-Centric Networking Research Group of the Internet + Research Task Force (IRTF). Documents approved for publication by + the IRSG are not candidates for any level of Internet Standard; see + Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8609. + + + + + +Mosko, et al. Experimental [Page 1] + +RFC 8609 CCNx TLV July 2019 + + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 + 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Type-Length-Value (TLV) Packets . . . . . . . . . . . . . . . 5 + 3.1. Overall Packet Format . . . . . . . . . . . . . . . . . . 7 + 3.2. Fixed Headers . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.1. Interest Fixed Header . . . . . . . . . . . . . . . . 9 + 3.2.1.1. Interest HopLimit . . . . . . . . . . . . . . . . 9 + 3.2.2. Content Object Fixed Header . . . . . . . . . . . . . 9 + 3.2.3. Interest Return Fixed Header . . . . . . . . . . . . 10 + 3.2.3.1. Interest Return HopLimit . . . . . . . . . . . . 10 + 3.2.3.2. Interest Return Flags . . . . . . . . . . . . . . 10 + 3.2.3.3. Return Code . . . . . . . . . . . . . . . . . . . 10 + 3.3. Global Formats . . . . . . . . . . . . . . . . . . . . . 11 + 3.3.1. Pad . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.3.2. Organization-Specific TLVs . . . . . . . . . . . . . 12 + 3.3.3. Hash Format . . . . . . . . . . . . . . . . . . . . . 12 + 3.3.4. Link . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.4. Hop-by-Hop TLV Headers . . . . . . . . . . . . . . . . . 14 + 3.4.1. Interest Lifetime . . . . . . . . . . . . . . . . . . 14 + 3.4.2. Recommended Cache Time . . . . . . . . . . . . . . . 15 + 3.4.3. Message Hash . . . . . . . . . . . . . . . . . . . . 16 + 3.5. Top-Level Types . . . . . . . . . . . . . . . . . . . . . 17 + 3.6. CCNx Message TLV . . . . . . . . . . . . . . . . . . . . 18 + 3.6.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 19 + 3.6.1.1. Name Segments . . . . . . . . . . . . . . . . . . 20 + 3.6.1.2. Interest Payload ID . . . . . . . . . . . . . . . 20 + 3.6.2. Message TLVs . . . . . . . . . . . . . . . . . . . . 21 + 3.6.2.1. Interest Message TLVs . . . . . . . . . . . . . . 21 + 3.6.2.2. Content Object Message TLVs . . . . . . . . . . . 23 + 3.6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 25 + 3.6.4. Validation . . . . . . . . . . . . . . . . . . . . . 25 + 3.6.4.1. Validation Algorithm . . . . . . . . . . . . . . 25 + 3.6.4.2. Validation Payload . . . . . . . . . . . . . . . 32 + + + +Mosko, et al. Experimental [Page 2] + +RFC 8609 CCNx TLV July 2019 + + + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 4.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 33 + 4.2. Interest Return Code Registry . . . . . . . . . . . . . . 34 + 4.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 35 + 4.4. Top-Level Type Registry . . . . . . . . . . . . . . . . . 36 + 4.5. Name Segment Type Registry . . . . . . . . . . . . . . . 37 + 4.6. Message Type Registry . . . . . . . . . . . . . . . . . . 37 + 4.7. Payload Type Registry . . . . . . . . . . . . . . . . . . 38 + 4.8. Validation Algorithm Type Registry . . . . . . . . . . . 39 + 4.9. Validation-Dependent Data Type Registry . . . . . . . . . 40 + 4.10. Hash Function Type Registry . . . . . . . . . . . . . . . 40 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 44 + 6.2. Informative References . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 + +1. Introduction + + This document specifies a Type-Length-Value (TLV) packet format and + the TLV type and value encodings for CCNx messages. A full + description of the CCNx network protocol, providing an encoding-free + description of CCNx messages and message elements, may be found in + [RFC8569]. CCNx is a network protocol that uses a hierarchical name + to forward requests and to match responses to requests. It does not + use endpoint addresses; the Internet Protocol does. Restrictions in + a request can limit the response by the public key of the response's + signer or the cryptographic hash of the response. Every CCNx + forwarder along the path does the name matching and restriction + checking. The CCNx protocol fits within the broader framework of + Information-Centric Networking (ICN) protocols [RFC7927]. + + This document 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 + Section 5. Briefly, this choice avoids multiple encodings of the + same value (aliases) and reduces the work of a validator to ensure + compliance. Unlike some uses of TLV in networking, each network hop + must evaluate the encoding, so even small validation latencies at + each hop could add up to a large overall forwarding delay. For very + small packets or low-throughput links, where the extra bytes may + become a concern, one may use a TLV compression protocol, for + 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. + + + +Mosko, et al. Experimental [Page 3] + +RFC 8609 CCNx TLV July 2019 + + + This document specifies: + + o the CCNx Packet format, + + o the CCNx Message TLV format, + + o the TLV types used by CCNx messages, + + o the encoding of values for each type, + + o top-level types that exist at the outermost containment, + + o Interest TLVs that exist within Interest containment, and + + o Content Object TLVs that exist within Content Object containment. + + This document is supplemented by these documents: + + o [RFC8569], which covers message semantics and the protocol + operation regarding Interest and Content Object, including the + Interest Return protocol. + + o [CCNxURI], which covers the CCNx URI notation. + + The type values in Section 4 conform to the IANA-assigned numbers for + the CCNx protocol. This document uses the symbolic names defined in + that section. All TLV type values are relative to their parent + containers. For example, each level of a nested TLV structure might + define a "type = 1" with a completely different meaning. + + 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 + and variable sizes, there is no concise way to represent all + possibilities. We use the convention that ASCII art fields enclosed + by vertical bars "|" represent exact bit widths. Fields with a + forward slash "/" are variable bit widths, which we typically pad out + to word alignment for picture readability. + + 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] + with significant revision and input from the ICN community and RG + members. The document has received critical reading by several + members of the ICN community and the RG. The authors and RG chairs + approve of the contents. The document is sponsored under the IRTF + and is not issued by the IETF and is not an IETF standard. This is + an experimental protocol and may not be suitable for any specific + application and the specification may change in the future. + + + + +Mosko, et al. Experimental [Page 4] + +RFC 8609 CCNx TLV July 2019 + + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Definitions + + These definitions summarize items defined in [RFC8569]. This + 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 + format as "ccnx:/path/part". There is no host or query string. + See [CCNxURI] for complete details. + + o Interest: A message requesting a Content Object with a matching + Name and other optional selectors to choose from multiple objects + with the same Name. Any Content Object with a Name and attributes + that matches the Name and optional selectors of the Interest is + said to satisfy the 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 + bound together via cryptographic means. + +3. Type-Length-Value (TLV) Packets + + We use 16-bit Type and 16-bit Length fields to encode TLV-based + packets. This provides 65,536 different possible types and value + field lengths of up to 64 KiB. With 65,536 possible types at each + level of TLV encoding, there should be sufficient space for basic + protocol types, while also allowing ample room for experimentation, + application use, vendor extensions, and growth. This encoding does + not allow for jumbo packets beyond 64 KiB total length. If used on a + media that allows for jumbo frames, we suggest defining a media + adaptation envelope that allows for multiple smaller frames. + + + + + + + + + + + +Mosko, et al. Experimental [Page 5] + +RFC 8609 CCNx TLV July 2019 + + + +--------+------------------+---------------------------------------+ + | 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 + hierarchical contexts. The TLV types in the range 0x1000 - 0x1FFF + are Reserved for Experimental Use. The TLV type T_ORG is also + 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 + alignment. + + 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 + +---------------+---------------+---------------+---------------+ + | Type | Length | + +---------------+---------------+---------------+---------------+ + + Figure 1: Type and Length encoding + + 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 + Length MAY be zero. + + TLV structures are nestable, allowing the Value field of one TLV + structure to contain additional TLV structures. The enclosing TLV + structure is called the container of the enclosed TLV. + + Type values are context dependent. Within a TLV container, one may + reuse previous type values for new context-dependent purposes. + + + + + + + + + + + + +Mosko, et al. Experimental [Page 6] + +RFC 8609 CCNx TLV July 2019 + + +3.1. Overall Packet Format + + Each CCNx Packet includes the 8-byte fixed header, described below, + followed by a set of TLV fields. These fields are optional hop-by- + hop headers and the Packet Payload. + + 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 + +---------------+---------------+---------------+---------------+ + | Version | PacketType | PacketLength | + +---------------+---------------+---------------+---------------+ + | PacketType-specific fields | HeaderLength | + +---------------+---------------+---------------+---------------+ + / Optional hop-by-hop header TLVs / + +---------------+---------------+---------------+---------------+ + / PacketPayload TLVs / + +---------------+---------------+---------------+---------------+ + + 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. + + 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 + +---------------+---------------+---------------+---------------+ + | CCNx Message TLV / + +---------------+---------------+---------------+---------------+ + / Optional CCNx ValidationAlgorithm TLV / + +---------------+---------------+---------------+---------------+ + / Optional CCNx ValidationPayload TLV (ValidationAlg required) / + +---------------+---------------+---------------+---------------+ + + 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 always begins with 4 bytes of type-length that + specifies the protocol message (whether it is an Interest, Content + Object, or other message type) and its total length. The embedding + + + +Mosko, et al. Experimental [Page 7] + +RFC 8609 CCNx TLV July 2019 + + + 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 + only on the embedded message. It also decouples the PacketType field + -- which specifies how to forward the packet -- from the + PacketPayload. + + The range of bytes protected by the Validation includes the CCNx + Message TLV and the ValidationAlgorithm TLV. + + The ContentObjectHash begins with the CCNx Message TLV and ends at + the tail of the CCNx Packet. + +3.2. Fixed Headers + + In Figure 2, the fixed header fields are: + + o Version: defines the version of the packet, which MUST be 1. + + o HeaderLength: The length of the fixed header (8 bytes) and hop-by- + hop headers. The minimum value MUST be 8. + + o PacketType: describes forwarder actions to take on the packet. + + o PacketLength: Total octets of packet including all headers (fixed + header plus hop-by-hop headers) and protocol message. + + o PacketType-specific Fields: specific PacketTypes define the use of + these bits. + + The PacketType field indicates how the forwarder should process the + packet. A Request Packet (Interest) has PacketType PT_INTEREST, a + Response (Content Object) has PacketType PT_CONTENT, and an Interest + Return has PacketType PT_RETURN. + + HeaderLength is the number of octets from the start of the CCNx + Packet (Version) to the end of the hop-by-hop headers. PacketLength + is the number of octets from the start of the packet to the end of + the packet. Both lengths have a minimum value of 8 (the fixed header + itself). + + The PacketType-specific fields are reserved bits whose use depends on + the PacketType. They are used for network-level signaling. + + + + + + + + + +Mosko, et al. Experimental [Page 8] + +RFC 8609 CCNx TLV July 2019 + + +3.2.1. Interest Fixed Header + + If the PacketType is PT_INTEREST, it indicates that the packet should + be forwarded following the Interest pipeline in Section 2.4.4 of + [RFC8569]. For this type of packet, the Fixed Header includes a + field for a HopLimit as well as Reserved and Flags fields. The + Reserved field MUST be set to 0 in an Interest. There are currently + no flags defined, so the Flags field MUST be set to 0. + + 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 + +---------------+---------------+---------------+---------------+ + | Version | PT_INTEREST | PacketLength | + +---------------+---------------+---------------+---------------+ + | HopLimit | Reserved | Flags | HeaderLength | + +---------------+---------------+---------------+---------------+ + + Figure 4: Interest Header + +3.2.1.1. Interest HopLimit + + For an Interest message, the HopLimit is a counter that is + decremented with each hop. It limits the distance an Interest may + 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 + Interest with a HopLimit decrements the value upon reception. If the + value is 0 after the decrement, the Interest MUST NOT be forwarded + off the node. + + It is an error to receive an Interest from a remote node with the + HopLimit field set to 0. + +3.2.2. Content Object Fixed Header + + If the PacketType is PT_CONTENT, it indicates that the packet should + be forwarded following the Content Object pipeline in Section 2.4.4 + of [RFC8569]. A Content Object defines a Flags field; however, there + are currently no flags defined, so the Flags field must be set to 0. + + 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 + +---------------+---------------+---------------+---------------+ + | Version | PT_CONTENT | PacketLength | + +---------------+---------------+---------------+---------------+ + | Reserved | Flags | HeaderLength | + +---------------+---------------+---------------+---------------+ + + Figure 5: Content Object Header + + + +Mosko, et al. Experimental [Page 9] + +RFC 8609 CCNx TLV July 2019 + + +3.2.3. Interest Return Fixed Header + + If the PacketType is PT_RETURN, it indicates that the packet should + be processed following the Interest Return rules in Section 10 of + [RFC8569]. The only difference between this Interest Return message + and the original Interest is that the PacketType is changed to + PT_RETURN and a ReturnCode is put into the ReturnCode field. All + other fields are unchanged from the Interest packet. The purpose of + 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 + 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 | + +---------------+---------------+---------------+---------------+ + | HopLimit | ReturnCode | Flags | HeaderLength | + +---------------+---------------+---------------+---------------+ + + Figure 6: Interest Return Header + +3.2.3.1. Interest Return HopLimit + + 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. + +3.2.3.3. Return Code + + This section maps the Return Code name [RFC8569] to the TLV symbolic + 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 + returning system did not modify the Return Code field. + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 10] + +RFC 8609 CCNx TLV July 2019 + + + +-------------------------------------+-----------------------------+ + | Return Type | Name in RFC 8569 | + +-------------------------------------+-----------------------------+ + | T_RETURN_NO_ROUTE | No Route | + | | | + | T_RETURN_LIMIT_EXCEEDED | Hop Limit Exceeded | + | | | + | T_RETURN_NO_RESOURCES | No Resources | + | | | + | T_RETURN_PATH_ERROR | Path Error | + | | | + | T_RETURN_PROHIBITED | Prohibited | + | | | + | T_RETURN_CONGESTED | Congested | + | | | + | T_RETURN_MTU_TOO_LARGE | MTU too large | + | | | + | T_RETURN_UNSUPPORTED_HASH_RESTRICTI | Unsupported ContentObjectHa | + | ON | shRestriction | + | | | + | T_RETURN_MALFORMED_INTEREST | Malformed Interest | + +-------------------------------------+-----------------------------+ + + Table 2: Return Codes + +3.3. Global Formats + + This section defines global formats that may be nested within other + TLVs. + +3.3.1. Pad + + The pad type may be used by sources that prefer word-aligned data. + Padding 4-byte words, for example, would use a 1-byte, 2-byte, and + 3-byte Length. Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, + 7)-byte Length. + + One MUST NOT pad inside a Name. Apart from that, a pad MAY be + inserted after any other TLV in the CCNx Message TLV or in the + ValidationAlgorithm TLV. In the remainder of this document, we will + not show optional Pad TLVs. + + + + + + + + + + +Mosko, et al. Experimental [Page 11] + +RFC 8609 CCNx TLV July 2019 + + + 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 + +---------------+---------------+---------------+---------------+ + | T_PAD | Length | + +---------------+---------------+---------------+---------------+ + / variable-length pad MUST be zeros / + +---------------+---------------+---------------+---------------+ + + Figure 7: Pad Encoding + +3.3.2. Organization-Specific TLVs + + 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 + organization number derived from the network byte order encoding of + the IANA "Private Enterprise Numbers" registry [IANA-PEN], followed + by the organization-specific information. + + A T_ORG MAY be used as a path segment in a Name. It is treated like + any other path segment. + + 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 + +---------------+---------------+---------------+---------------+ + | T_ORG | Length (3+value length) | + +---------------+---------------+---------------+---------------+ + | PEN[0] | PEN[1] | PEN[2] | / + +---------------+---------------+---------------+ + + / Vendor Specific Value / + +---------------+---------------+---------------+---------------+ + + Figure 8: Organization-Specific TLVs + +3.3.3. Hash Format + + Hash values are used in several fields throughout a packet. This TLV + encoding is commonly embedded inside those fields to specify the + specific hash function used and its value. Note that the reserved + TLV types are also reserved here for user-defined experimental + functions. + + 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 + is taken as the left LENGTH bytes of the hash function output. Only + specified truncations are allowed, not arbitrary truncations. + + + + + +Mosko, et al. Experimental [Page 12] + +RFC 8609 CCNx TLV July 2019 + + + This nested format is used because it allows binary comparison of + hash values for certain fields without a router needing to understand + a new hash function. For example, the KeyIdRestriction is bit-wise + compared between an Interest's KeyIdRestriction field and a + ContentObject's KeyId field. This format means the outer field + values do not change with differing hash functions so a router can + still identify those fields and do a binary comparison of the hash + TLV without need to understand the specific hash used. An + alternative approach, such as using T_KEYID_SHA512-256, would require + each router keeps an up-to-date parser and supporting user-defined + hash functions here would explode the parsing state-space. + + A CCNx entity MUST support the hash type T_SHA-256. An entity MAY + support the remaining hash types. + + +-----------+------------------------+ + | Abbrev | Lengths (octets) | + +-----------+------------------------+ + | T_SHA-256 | 32 | + | | | + | T_SHA-512 | 64, 32 | + | | | + | n/a | Experimental TLV types | + +-----------+------------------------+ + + Table 3: CCNx Hash Functions + + 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 + +---------------+---------------+---------------+---------------+ + | T_FOO | 36 | + +---------------+---------------+---------------+---------------+ + | T_SHA512 | 32 | + +---------------+---------------+---------------+---------------+ + / 32-byte hash value / + +---------------+---------------+---------------+---------------+ + + Figure 9: Example nesting inside type T_FOO + +3.3.4. Link + + A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}. + It is a general encoding that is used in both the payload of a + Content Object with PayloadType = "Link" and in a Content Object's + KeyLink field. A Link is essentially the body of an Interest. + + + + + + +Mosko, et al. Experimental [Page 13] + +RFC 8609 CCNx TLV July 2019 + + + 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 + +---------------+---------------+---------------+---------------+ + / Mandatory CCNx Name / + +---------------+---------------+---------------+---------------+ + / Optional KeyIdRestriction / + +---------------+---------------+---------------+---------------+ + / Optional ContentObjectHashRestriction / + +---------------+---------------+---------------+---------------+ + + Figure 10: Link Encoding + +3.4. Hop-by-Hop TLV Headers + + 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 + document: + + +-------------+--------------------+--------------------------------+ + | Abbrev | Name | Description | + +-------------+--------------------+--------------------------------+ + | T_INTLIFE | Interest Lifetime | The time an Interest should | + | | (Section 3.4.1) | stay pending at an | + | | | intermediate node. | + | | | | + | T_CACHETIME | Recommended Cache | The Recommended Cache Time for | + | | Time (Section | Content Objects. | + | | 3.4.2) | | + | | | | + | T_MSGHASH | Message Hash | A cryptographic hash (Section | + | | (Section 3.4.3) | 3.3.3). | + +-------------+--------------------+--------------------------------+ + + Table 4: Hop-by-Hop Header Types + + Additional hop-by-hop headers are defined in higher level + specifications such as the fragmentation specification. + +3.4.1. Interest Lifetime + + The Interest Lifetime is the time that an Interest should stay + pending at an intermediate node. It is expressed in milliseconds as + an unsigned integer in network byte order. + + 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 + no reply is expected and a forwarder could skip creating a PIT entry. + + + + +Mosko, et al. Experimental [Page 14] + +RFC 8609 CCNx TLV July 2019 + + + 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 + +---------------+---------------+---------------+---------------+ + | T_INTLIFE | Length | + +---------------+---------------+---------------+---------------+ + / / + / Lifetime (Length octets) / + / / + +---------------+---------------+---------------+---------------+ + + Figure 11: Interest Lifetime Encoding + +3.4.2. Recommended Cache Time + + The Recommended Cache Time (RCT) is a measure of the useful lifetime + of a Content Object as assigned by a content producer or upstream + node. It serves as a guideline to the Content Store cache in + determining how long to keep the Content Object. It is a + 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 + takes precedence over the RCT and must be obeyed. + + 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 + a previously signed Content Object with an updated RCT without + 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. + + The Recommended Cache Time (a millisecond timestamp) is an unsigned + integer in network byte order that indicates the time when the + payload expires (as the number of milliseconds since the epoch in + UTC). It is a 64-bit field. + + 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 + +---------------+---------------+---------------+---------------+ + | T_CACHETIME | 8 | + +---------------+---------------+---------------+---------------+ + / / + / Recommended Cache Time / + / / + +---------------+---------------+---------------+---------------+ + + Figure 12: Recommended Cache Time Encoding + + + + + + + +Mosko, et al. Experimental [Page 15] + +RFC 8609 CCNx TLV July 2019 + + +3.4.3. 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 + of a message. An egress device should remove the value. This + permits intermediate devices within that trusted domain to match + against a ContentObjectHashRestriction without calculating it at + every hop. + + The message hash is a cryptographic hash from the start of the CCNx + Message TLV to the end of the packet. It is used to match against + the ContentObjectHashRestriction (Section 3.6.2.1.2). The Message + Hash may be of longer length than an Interest's restriction, in which + case the device should use the left bytes of the Message Hash to + check against the Interest's value. + + The Message Hash may only carry one hash type and there may only be + one Message Hash header. + + The Message Hash header is unprotected, so this header is only of + practical use within a trusted domain, such as an operator's + autonomous system. + + 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 + +---------------+---------------+---------------+---------------+ + | T_MSGHASH | (length + 4) | + +---------------+---------------+---------------+---------------+ + | hash type | length | + +---------------+---------------+---------------+---------------+ + / hash value / + +---------------+---------------+---------------+---------------+ + + Figure 13: Message Hash Header + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 16] + +RFC 8609 CCNx TLV July 2019 + + +3.5. Top-Level Types + + The top-level TLV types listed below exist at the outermost level of + a CCNx Message TLV. + + +----------------------+------------+-------------------------------+ + | Abbrev | Name | Description | + +----------------------+------------+-------------------------------+ + | T_INTEREST | Interest | An Interest MessageType. | + | | (Section | | + | | 3.6) | | + | | | | + | T_OBJECT | Content | A Content Object MessageType | + | | Object | | + | | (Section | | + | | 3.6) | | + | | | | + | T_VALIDATION_ALG | Validation | The method of message | + | | Algorithm | verification such as a | + | | (Section | Message Integrity Check | + | | 3.6.4.1) | (MIC), Message Authentication | + | | | Code (MAC), or cryptographic | + | | | signature. | + | | | | + | T_VALIDATION_PAYLOAD | Validation | The validation output, such | + | | Payload | as the CRC32C code or the RSA | + | | (Section | signature. | + | | 3.6.4.2) | | + +----------------------+------------+-------------------------------+ + + Table 5: CCNx Top Level Types + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 17] + +RFC 8609 CCNx TLV July 2019 + + +3.6. CCNx Message TLV + + This is the format for the CCNx Message itself. The CCNx Message TLV + is the portion of the CCNx Packet between the hop-by-hop headers and + the Validation TLVs. The figure below is an expansion of the "CCNx + Message TLV" depicted in the beginning of Section 3. The CCNx + Message TLV begins with MessageType and runs through the optional + Payload. The same general format is used for both Interest and + Content Object messages which are differentiated by the MessageType + field. The first enclosed TLV of a CCNx Message TLV is always the + Name TLV, if present. This is followed by an optional Message TLVs + and an optional Payload TLV. + + 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 + +---------------+---------------+---------------+---------------+ + | MessageType | MessageLength | + +---------------+---------------+---------------+---------------+ + / Name TLV (Type = T_NAME) / + +---------------+---------------+---------------+---------------+ + / Optional Message TLVs (Various Types) / + +---------------+---------------+---------------+---------------+ + / 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 TLV Types + + + + + + + + + + + +Mosko, et al. Experimental [Page 18] + +RFC 8609 CCNx TLV July 2019 + + +3.6.1. Name + + 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 + include Pad TLVs. + + As described in CCNx Semantics [RFC8569], using the CCNx URI + [CCNxURI] notation, a T_NAME with zero length corresponds to "ccnx:/" + (the default route). The message grammar does not allow the first + name segment to have zero length in a CCNx Message TLV Name. In the + TLV encoding, "ccnx:/" corresponds to T_NAME with zero length. + + 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 + +---------------+---------------+---------------+---------------+ + | T_NAME | Length | + +---------------+---------------+---------------+---------------+ + / Name segment TLVs / + +---------------+---------------+---------------+---------------+ + + Figure 15: Name Encoding + + +---------------+-------------+-------------------------------------+ + | Symbolic Name | Name | Description | + +---------------+-------------+-------------------------------------+ + | T_NAMESEGMENT | Name | A generic name segment. | + | | segment | | + | | (Section | | + | | 3.6.1.1) | | + | | | | + | T_IPID | Interest | An identifier that represents the | + | | Payload ID | Interest Payload field. As an | + | | (Section | example, the Payload ID might be a | + | | 3.6.1.2) | hash of the Interest Payload. This | + | | | provides a way to differentiate | + | | | between Interests based on their | + | | | payloads without having to parse | + | | | all the bytes of the payload | + | | | itself, and instead using only this | + | | | Payload ID name segment. | + | | | | + | T_APP:00 - | Application | Application-specific payload in a | + | T_APP:4096 | Components | name segment. An application may | + | | (Section | apply its own semantics to the 4096 | + | | 3.6.1.1) | reserved types. | + +---------------+-------------+-------------------------------------+ + + Table 7: CCNx Name Types + + + +Mosko, et al. Experimental [Page 19] + +RFC 8609 CCNx TLV July 2019 + + +3.6.1.1. Name Segments + + 4096 special application payload name segments are allocated. These + have application semantics applied to them. A good convention is to + put the application's identity in the name prior to using these name + segments. + + For example, a name like "ccnx:/foo/bar/hi" would be encoded as: + + 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 + +---------------+---------------+---------------+---------------+ + | (T_NAME) | 0x14 (20) | + +---------------+---------------+---------------+---------------+ + | (T_NAME_SEGMENT) | 0x03 (3) | + +---------------+---------------+---------------+---------------+ + | f o o |(T_NAME_SEGMENT) + +---------------+---------------+---------------+---------------+ + | | 0x03 (3) | b | + +---------------+---------------+---------------+---------------+ + | a r | (T_NAME_SEGMENT) | + +---------------+---------------+---------------+---------------+ + | 0x02 (2) | h | i | + +---------------+---------------+---------------+---------------+ + + Figure 16: Name Encoding Example + +3.6.1.2. Interest Payload ID + + The InterestPayloadID is a name segment created by the origin of an + Interest to represent the Interest Payload. This allows the proper + multiplexing of Interests based on their name if they have different + payloads. A common representation is to use a hash of the Interest + Payload as the InterestPayloadID. + + As part of the Value of the TLV, the InterestPayloadID contains a + one-octet identifier of the method used to create the + InterestPayloadID followed by a variable-length octet string. An + implementation is not required to implement any of the methods to + receive an Interest; the InterestPayloadID may be treated only as an + opaque octet string for the purposes of multiplexing Interests with + different payloads. Only a device creating an InterestPayloadID name + segment or a device verifying such a segment needs to implement the + algorithms. + + It uses the encoding of hash values specified in Section 3.3.3. + + + + + +Mosko, et al. Experimental [Page 20] + +RFC 8609 CCNx TLV July 2019 + + + In normal operations, we recommend displaying the InterestPayloadID + as an opaque octet string in a CCNx URI, as this is the common + denominator for implementation parsing. + + The InterestPayloadID, even if it is a hash, should not convey any + security context. If a system requires confirmation that a specific + entity created the InterestPayload, it should use a cryptographic + signature on the Interest via the ValidationAlgorithm and + ValidationPayload or use its own methods inside the Interest Payload. + +3.6.2. Message TLVs + + Each message type (Interest or Content Object) is associated with a + set of optional Message TLVs. Additional specification documents may + extend the types associated with each. + +3.6.2.1. Interest Message TLVs + + There are two Message TLVs currently associated with an Interest + message: the KeyIdRestriction selector and the ContentObjectHashRestr + selector are used to narrow the universe of acceptable Content + Objects that would satisfy the Interest. + + 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 + +---------------+---------------+---------------+---------------+ + | MessageType | MessageLength | + +---------------+---------------+---------------+---------------+ + | Name TLV | + +---------------+---------------+---------------+---------------+ + / Optional KeyIdRestriction TLV / + +---------------------------------------------------------------+ + / Optional ContentObjectHashRestriction TLV / + +---------------------------------------------------------------+ + + Figure 17: Interest Message TLVs + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 21] + +RFC 8609 CCNx TLV July 2019 + + + +----------------+------------------------------+-------------------+ + | Abbrev | Name | Description | + +----------------+------------------------------+-------------------+ + | T_KEYIDRESTR | KeyIdRestriction (Section | A representation | + | | 3.6.2.1.1) | (as per Section | + | | | 3.3.3) of the | + | | | KeyId | + | | | | + | T_OBJHASHRESTR | ContentObjectHashRestriction | A representation | + | | (Section 3.6.2.1.2) | (as per Section | + | | | 3.3.3) of the | + | | | hash of the | + | | | specific Content | + | | | Object that would | + | | | satisfy the | + | | | Interest. | + +----------------+------------------------------+-------------------+ + + Table 8: CCNx Interest Message TLV Types + +3.6.2.1.1. KeyIdRestriction + + An Interest MAY include a KeyIdRestriction selector. This ensures + 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. + +3.6.2.1.2. ContentObjectHashRestriction + + An Interest MAY contain a ContentObjectHashRestriction selector. + This is the hash of the Content Object -- the self-certifying name + restriction that must be verified in the network, if an Interest + carried this restriction (see Message Hash (Section 3.4.3)). The + LENGTH MUST be from one of the allowed values for that hash (see + Section 3.3.3). + + The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of + length 32 bytes. + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 22] + +RFC 8609 CCNx TLV July 2019 + + + 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 + +---------------+---------------+---------------+---------------+ + | T_OBJHASHRESTR | (LENGTH+4) | + +---------------+---------------+---------------+---------------+ + | hash type | LENGTH | + +---------------+---------------+---------------+---------------+ + / LENGTH octets of hash / + +---------------+---------------+---------------+---------------+ + + Figure 18: ContentObjectHashRestriction Encoding + +3.6.2.2. Content Object Message TLVs + + The following message TLVs are currently defined for Content Objects: + PayloadType (optional) and ExpiryTime (optional). + + 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 + +---------------+---------------+---------------+---------------+ + | MessageType | MessageLength | + +---------------+---------------+---------------+---------------+ + | Name TLV | + +---------------+---------------+---------------+---------------+ + / Optional PayloadType TLV / + +---------------------------------------------------------------+ + / Optional ExpiryTime TLV / + +---------------------------------------------------------------+ + + Figure 19: Content Object Message TLVs + + +-------------+-------------+---------------------------------------+ + | Abbrev | Name | Description | + +-------------+-------------+---------------------------------------+ + | T_PAYLDTYPE | PayloadType | Indicates the type of Payload | + | | (Section | contents. | + | | 3.6.2.2.1) | | + | | | | + | T_EXPIRY | ExpiryTime | The time at which the Payload | + | | (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 + + + + + +Mosko, et al. Experimental [Page 23] + +RFC 8609 CCNx TLV July 2019 + + +3.6.2.2.1. PayloadType + + The PayloadType is an octet representing the general type of the + Payload TLV. + + o T_PAYLOADTYPE_DATA: Data (possibly encrypted) + + o T_PAYLOADTYPE_KEY: Key + + o T_PAYLOADTYPE_LINK: Link + + The Data type indicates that the Payload of the ContentObject is + opaque application bytes. The Key type indicates that the Payload is + a DER-encoded public key. The Link type indicates that the Payload + is one or more Links (Section 3.3.4). If this field is missing, a + Data type is assumed. + + 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 + +---------------+---------------+---------------+---------------+ + | T_PAYLDTYPE | 1 | + +---------------+---------------+---------------+---------------+ + | PayloadType | + +---------------+ + + Figure 20: PayloadType Encoding + +3.6.2.2.2. ExpiryTime + + The ExpiryTime is the time at which the Payload expires, as expressed + 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 + field. A cache or end system should not respond with a Content + Object past its ExpiryTime. Routers forwarding a Content Object do + not need to check the ExpiryTime. If the ExpiryTime field is + missing, the Content Object has no expressed expiration, and a cache + or end system may use the Content Object for as long as desired. + + 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 + +---------------+---------------+---------------+---------------+ + | T_EXPIRY | 8 | + +---------------+---------------+---------------+---------------+ + / ExpiryTime / + / / + +---------------+---------------+---------------+---------------+ + + Figure 21: ExpiryTime encoding + + + +Mosko, et al. Experimental [Page 24] + +RFC 8609 CCNx TLV July 2019 + + +3.6.3. Payload + + 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 + SHOULD be omitted, rather than being of zero length. + + 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 + +---------------+---------------+---------------+---------------+ + | T_PAYLOAD | Length | + +---------------+---------------+---------------+---------------+ + / Payload Contents / + +---------------+---------------+---------------+---------------+ + + Figure 22: Payload Encoding + +3.6.4. Validation + + Both Interests and Content Objects have the option to include + information about how to validate the CCNx Message. This information + is contained in two TLVs: the ValidationAlgorithm TLV and the + ValidationPayload TLV. The ValidationAlgorithm TLV specifies the + mechanism to be used to verify the CCNx Message. Examples include + verification with a Message Integrity Check (MIC), a Message + Authentication Code (MAC), or a cryptographic signature. The + ValidationPayload TLV contains the validation output, such as the + CRC32C code or the RSA signature. + + An Interest would most likely only use a MIC type of validation -- a + CRC, checksum, or digest. + +3.6.4.1. Validation Algorithm + + The ValidationAlgorithm is a set of nested TLVs containing all of the + information needed to verify the message. The outermost container + has type = T_VALIDATION_ALG. The first nested TLV defines the + specific type of validation to be performed on the message. The type + is identified with the "ValidationType" as shown in the figure below + and elaborated in the table below. Nested within that container are + the TLVs for any ValidationType-dependent data -- for example, a Key + Id, Key Locator, etc. + + Complete examples of several types may be found in Section 3.6.4.1.5. + + + + + + + + +Mosko, et al. Experimental [Page 25] + +RFC 8609 CCNx TLV July 2019 + + + 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 + +---------------+---------------+---------------+---------------+ + | T_VALIDATION_ALG | ValidationAlgLength | + +---------------+---------------+---------------+---------------+ + | ValidationType | Length | + +---------------+---------------+---------------+---------------+ + / ValidationType-dependent data / + +---------------+---------------+---------------+---------------+ + + Figure 23: Validation Algorithm Encoding + + +-----------------+---------------+---------------------------------+ + | Abbrev | Name | Description | + +-----------------+---------------+---------------------------------+ + | T_CRC32C | CRC32C | Castagnoli CRC32 (iSCSI, ext4, | + | | (Section | etc.) with normal form | + | | 3.6.4.1.1) | polynomial 0x1EDC6F41. | + | | | | + | T_HMAC-SHA256 | HMAC-SHA256 | HMAC (RFC 2104) using SHA256 | + | | (Section | hash. | + | | 3.6.4.1.2) | | + | | | | + | T_RSA-SHA256 | RSA-SHA256 | RSA public-key signature using | + | | (Section | SHA256 digest. | + | | 3.6.4.1.3) | | + | | | | + | T_EC-SECP-256K1 | SECP-256K1 | Elliptic Curve signature with | + | | (Section | SECP-256K1 parameters (see | + | | 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 + +3.6.4.1.1. Message Integrity Checks + + MICs do not require additional data in order to perform the + verification. An example is CRC32C that has a zero-length value. + + + + + + + + + +Mosko, et al. Experimental [Page 26] + +RFC 8609 CCNx TLV July 2019 + + +3.6.4.1.2. Message Authentication Codes + + MACs are useful for communication between two trusting parties who + have already shared secret keys. An example is the HMAC algorithm. + A MAC uses the KeyId field to identify which shared secret is in use. + 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 + + Signature type Validators specify a digest mechanism and a signing + algorithm to verify the message. Examples include an RSA signature + on a SHA256 digest, an Elliptic Curve signature with SECP-256K1 + parameters, etc. These Validators require a KeyId and a mechanism + for locating the publisher's public key (a KeyLocator) -- and + optionally a PublicKey or Certificate or KeyLink. + +3.6.4.1.4. Validation-Dependent Data + + Different Validation Algorithms require access to different pieces of + data contained in the ValidationAlgorithm TLV. As described above, + Key Ids, Key Locators, Public Keys, Certificates, Links, and Key + Names all play a role in different Validation Algorithms. Any number + of Validation-Dependent Data containers can be present in a + Validation Algorithm TLV. + + + + + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 27] + +RFC 8609 CCNx TLV July 2019 + + + Below is a table of CCNx ValidationType-dependent data types: + + +-------------+-----------------+-----------------------------------+ + | Abbrev | Name | Description | + +-------------+-----------------+-----------------------------------+ + | T_KEYID | SignerKeyId | An identifier of the shared | + | | (Section | secret or public key associated | + | | 3.6.4.1.4.1) | with a MAC or Signature. | + | | | | + | T_PUBLICKEY | Public Key | DER-encoded public key. | + | | (Section | | + | | 3.6.4.1.4.2) | | + | | | | + | T_CERT | Certificate | DER-encoded X.509 certificate. | + | | (Section | | + | | 3.6.4.1.4.3) | | + | | | | + | T_KEYLINK | KeyLink | A CCNx Link object. | + | | (Section | | + | | 3.6.4.1.4.4) | | + | | | | + | 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 + +3.6.4.1.4.1. KeyId + + The KeyId for a signature is the publisher key identifier. It is + similar to a Subject Key Identifier from X.509 (see Section 4.2.1.2 + of [RFC5280]). It should be derived from the key used to sign, such + as from the SHA-256 hash of the key. It applies to both public and + private key systems and to symmetric key systems. + + The KeyId is represented using the hash format in Section 3.3.3. If + an application protocol uses a non-hash identifier, it should use one + of the reserved values. + + + + + + + + + + + + +Mosko, et al. Experimental [Page 28] + +RFC 8609 CCNx TLV July 2019 + + + 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 + +---------------+---------------+---------------+---------------+ + | T_KEYID | LENGTH+4 | + +---------------+---------------+---------------+---------------+ + | <hash type> | LENGTH | + +---------------+---------------+---------------+---------------+ + / LENGTH octets of hash / + +---------------+---------------+---------------+---------------+ + + Figure 24: KeyId Encoding + +3.6.4.1.4.2. Public Key + + A Public Key is a DER-encoded Subject Public Key Info block, as in an + X.509 certificate. + + 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 + +---------------+---------------+---------------+---------------+ + | T_PUBLICKEY | Length | + +---------------+---------------+---------------+---------------+ + / Public Key (DER-encoded SPKI) / + +---------------+---------------+---------------+---------------+ + + Figure 25: Public Key Encoding + +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 + 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 | + +---------------+---------------+---------------+---------------+ + / Certificate (DER-encoded X.509) / + +---------------+---------------+---------------+---------------+ + + Figure 26: Certificate Encoding + + + + + + + + + + +Mosko, et al. Experimental [Page 29] + +RFC 8609 CCNx TLV July 2019 + + +3.6.4.1.4.4. KeyLink + + A KeyLink type KeyLocator is a Link. + + The KeyLink ContentObjectHashRestr, if included, is the digest of the + Content Object identified by KeyLink, not the digest of the public + key. Likewise, the KeyIdRestr of the KeyLink is the KeyId of the + ContentObject, not necessarily of the wrapped key. + + 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 + +---------------+---------------+-------------------------------+ + | T_KEYLINK | Length | + +---------------+---------------+-------------------------------+ + / Link / + +---------------------------------------------------------------+ + + Figure 27: KeyLink Encoding + +3.6.4.1.4.5. SignatureTime + + The SignatureTime is a millisecond timestamp indicating the time at + which a signature was created. The signer sets this field to the + current time when creating a signature. A verifier may use this time + to determine whether or not the signature was created during the + validity period of a key, or if it occurred in a reasonable sequence + with other associated signatures. The SignatureTime is unrelated to + any time associated with the actual CCNx Message, which could have + been created long before the signature. The default behavior is to + always include a SignatureTime when creating an authenticated message + (e.g., HMAC or RSA). + + SignatureTime is an unsigned integer in network byte order that + indicates when the signature was created (as the number of + milliseconds since the epoch in UTC). It is a fixed 64-bit field. + + 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 + +---------------+---------------+-------------------------------+ + | T_SIGTIME | 8 | + +---------------+---------------+-------------------------------+ + / SignatureTime / + +---------------------------------------------------------------+ + + Figure 28: SignatureTime Encoding + + + + + + +Mosko, et al. Experimental [Page 30] + +RFC 8609 CCNx TLV July 2019 + + +3.6.4.1.5. Validation Examples + + As an example of a MIC-type validation, the encoding for CRC32C + validation would be: + + 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 + +---------------+---------------+---------------+---------------+ + | T_VALIDATION_ALG | 4 | + +---------------+---------------+---------------+---------------+ + | T_CRC32C | 0 | + +---------------+---------------+---------------+---------------+ + + Figure 29: CRC32C Encoding Example + + As an example of a MAC-type validation, the encoding for an HMAC + using a SHA256 hash would be: + + 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 + +---------------+---------------+---------------+---------------+ + | T_VALIDATION_ALG | 40 | + +---------------+---------------+---------------+---------------+ + | T_HMAC-SHA256 | 36 | + +---------------+---------------+---------------+---------------+ + | T_KEYID | 32 | + +---------------+---------------+---------------+---------------+ + / KeyId / + /---------------+---------------+-------------------------------+ + + Figure 30: HMAC-SHA256 Encoding Example + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 31] + +RFC 8609 CCNx TLV July 2019 + + + 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 + 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 octets + Variable Length | + +---------------+---------------+---------------+---------------+ + | T_RSA-SHA256 | 40 octets + Variable Length | + +---------------+---------------+---------------+---------------+ + | T_KEYID | 32 | + +---------------+---------------+---------------+---------------+ + / KeyId / + /---------------+---------------+-------------------------------+ + | T_PUBLICKEY | Variable Length (~160 octets)| + +---------------+---------------+---------------+---------------+ + / Public Key (DER-encoded SPKI) / + +---------------+---------------+---------------+---------------+ + + Figure 31: RSA-SHA256 Encoding Example + +3.6.4.2. Validation Payload + + 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 + +---------------+---------------+---------------+---------------+ + | T_VALIDATION_PAYLOAD | ValidationPayloadLength | + +---------------+---------------+---------------+---------------+ + / Type-dependent data / + +---------------+---------------+---------------+---------------+ + + Figure 32: Validation Payload Encoding + + The ValidationPayload contains the validation output, such as the + CRC32C code or the RSA signature. + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 32] + +RFC 8609 CCNx TLV July 2019 + + +4. IANA Considerations + + This section details each kind of CCNx protocol value that can be + registered. Each type registry can be updated by incrementally + expanding the type space, i.e., by allocating and reserving new + types. As per [RFC8126], this section details the creation of the + "Content-Centric Networking (CCNx)" registry and several + subregistries. + +4.1. Packet Type Registry + + IANA has created the "CCNx Packet Types" registry and allocated the + packet types described below. The registration procedure is RFC + Required. The Type value is 1 octet. The range is 0x00-0xFF. + + +------+-------------+----------------------------------+ + | Type | Name | Reference | + +------+-------------+----------------------------------+ + | 0x00 | PT_INTEREST | Fixed Header Types (Section 3.2) | + | | | | + | 0x01 | PT_CONTENT | Fixed Header Types (Section 3.2) | + | | | | + | 0x02 | PT_RETURN | Fixed Header Types (Section 3.2) | + +------+-------------+----------------------------------+ + + Packet Types + + + + + + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 33] + +RFC 8609 CCNx TLV July 2019 + + +4.2. Interest Return Code Registry + + 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 + 1 octet. The range is 0x00-0xFF. + + +------+---------------------------------------+--------------------+ + | Type | Name | Reference | + +------+---------------------------------------+--------------------+ + | 0x00 | Reserved | | + | | | | + | 0x01 | T_RETURN_NO_ROUTE | Fixed Header Types | + | | | (Section 3.2.3.3) | + | | | | + | 0x02 | T_RETURN_LIMIT_EXCEEDED | Fixed Header Types | + | | | (Section 3.2.3.3) | + | | | | + | 0x03 | T_RETURN_NO_RESOURCES | Fixed Header Types | + | | | (Section 3.2.3.3) | + | | | | + | 0x04 | T_RETURN_PATH_ERROR | Fixed Header Types | + | | | (Section 3.2.3.3) | + | | | | + | 0x05 | T_RETURN_PROHIBITED | Fixed Header Types | + | | | (Section 3.2.3.3) | + | | | | + | 0x06 | T_RETURN_CONGESTED | Fixed Header Types | + | | | (Section 3.2.3.3) | + | | | | + | 0x07 | T_RETURN_MTU_TOO_LARGE | Fixed Header Types | + | | | (Section 3.2.3.3) | + | | | | + | 0x08 | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types | + | | | (Section 3.2.3.3) | + | | | | + | 0x09 | T_RETURN_MALFORMED_INTEREST | Fixed Header Types | + | | | (Section 3.2.3.3) | + +------+---------------------------------------+--------------------+ + + CCNx Interest Return Types + + + + + + + + + + +Mosko, et al. Experimental [Page 34] + +RFC 8609 CCNx TLV July 2019 + + +4.3. Hop-by-Hop Type Registry + + 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 + 0x0000-0xFFFF. + + +---------------+-------------+-------------------------------------+ + | Type | Name | Reference | + +---------------+-------------+-------------------------------------+ + | 0x0000 | Reserved | | + | | | | + | 0x0001 | T_INTLIFE | Hop-by-hop TLV headers (Section | + | | | 3.4) | + | | | | + | 0x0002 | T_CACHETIME | Hop-by-hop TLV headers (Section | + | | | 3.4) | + | | | | + | 0x0003 | T_MSGHASH | Hop-by-hop TLV headers (Section | + | | | 3.4) | + | | | | + | 0x0004 - | Reserved | | + | 0x0007 | | | + | | | | + | 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) | + +---------------+-------------+-------------------------------------+ + + CCNx Hop-by-Hop Types + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 35] + +RFC 8609 CCNx TLV July 2019 + + +4.4. Top-Level Type Registry + + 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 + 0x0000-0xFFFF. + + +--------+----------------------+-------------------------------+ + | Type | Name | Reference | + +--------+----------------------+-------------------------------+ + | 0x0000 | Reserved | | + | | | | + | 0x0001 | T_INTEREST | Top-Level Types (Section 3.5) | + | | | | + | 0x0002 | T_OBJECT | Top-Level Types (Section 3.5) | + | | | | + | 0x0003 | T_VALIDATION_ALG | Top-Level Types (Section 3.5) | + | | | | + | 0x0004 | T_VALIDATION_PAYLOAD | Top-Level Types (Section 3.5) | + +--------+----------------------+-------------------------------+ + + CCNx Top-Level Types + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 36] + +RFC 8609 CCNx TLV July 2019 + + +4.5. Name Segment Type Registry + + 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 + 0x0000-0xFFFF. + + +--------------+------------------+---------------------------------+ + | Type | Name | Reference | + +--------------+------------------+---------------------------------+ + | 0x0000 | Reserved | | + | | | | + | 0x0001 | T_NAMESEGMENT | Name (Section 3.6.1) | + | | | | + | 0x0002 | T_IPID | Name (Section 3.6.1) | + | | | | + | 0x0010 - | Reserved | RFC 8609 | + | 0x0013 | | | + | | | | + | 0x0FFF | T_ORG | Organization-Specific TLVs | + | | | (Section 3.3.2) | + | | | | + | 0x1000 - | T_APP:00 - | Application Components (Section | + | 0x1FFF | T_APP:4096 | 3.6.1) | + +--------------+------------------+---------------------------------+ + + CCNx Name Segment Types + +4.6. Message Type Registry + + 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 + 0x0000-0xFFFF. + + + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 37] + +RFC 8609 CCNx TLV July 2019 + + + +---------------+----------------+----------------------------------+ + | Type | Name | Reference | + +---------------+----------------+----------------------------------+ + | 0x0000 | T_NAME | Message Types (Section 3.6) | + | | | | + | 0x0001 | T_PAYLOAD | Message Types (Section 3.6) | + | | | | + | 0x0002 | T_KEYIDRESTR | Message Types (Section 3.6) | + | | | | + | 0x0003 | T_OBJHASHRESTR | Message Types (Section 3.6) | + | | | | + | 0x0005 | T_PAYLDTYPE | Content Object Message Types | + | | | (Section 3.6.2.2) | + | | | | + | 0x0006 | T_EXPIRY | Content Object Message Types | + | | | (Section 3.6.2.2) | + | | | | + | 0x0007 - | Reserved | RFC 8609 | + | 0x000C | | | + | | | | + | 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) | + +---------------+----------------+----------------------------------+ + + CCNx Message Types + +4.7. Payload Type Registry + + 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 + 0x00-0xFF. + + +------+--------------------+-----------------------------------+ + | Type | Name | Reference | + +------+--------------------+-----------------------------------+ + | 0x00 | T_PAYLOADTYPE_DATA | Payload Types (Section 3.6.2.2.1) | + | | | | + | 0x01 | T_PAYLOADTYPE_KEY | Payload Types (Section 3.6.2.2.1) | + | | | | + | 0x02 | T_PAYLOADTYPE_LINK | Payload Types (Section 3.6.2.2.1) | + +------+--------------------+-----------------------------------+ + + CCNx Payload Types + + + +Mosko, et al. Experimental [Page 38] + +RFC 8609 CCNx TLV July 2019 + + +4.8. Validation Algorithm Type Registry + + IANA has created the "CCNx Validation Algorithm Types" registry and + allocated the validation algorithm types described below. The + registration procedure is Specification Required. The Type value is + 2 octets. The range is 0x0000-0xFFFF. + + +---------------+-----------------+---------------------------------+ + | 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) | + +---------------+-----------------+---------------------------------+ + + CCNx Validation Algorithm Types + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 39] + +RFC 8609 CCNx TLV July 2019 + + +4.9. Validation-Dependent Data Type Registry + + 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 | + +---------------+----------------+----------------------------------+ + | 0x0000 | Reserved | | + | | | | + | 0x0009 | T_KEYID | Validation-Dependent Data | + | | | (Section 3.6.4.1.4) | + | | | | + | 0x000A | T_PUBLICKEYLOC | Validation-Dependent Data | + | | | (Section 3.6.4.1.4) | + | | | | + | 0x000B | T_PUBLICKEY | Validation-Dependent Data | + | | | (Section 3.6.4.1.4) | + | | | | + | 0x000C | T_CERT | Validation-Dependent Data | + | | | (Section 3.6.4.1.4) | + | | | | + | 0x000D | T_LINK | Validation-Dependent Data | + | | | (Section 3.6.4.1.4) | + | | | | + | 0x000E | T_KEYLINK | Validation-Dependent Data | + | | | (Section 3.6.4.1.4) | + | | | | + | 0x000F | T_SIGTIME | Validation-Dependent Data | + | | | (Section 3.6.4.1.4) | + | | | | + | 0x0FFF | T_ORG | Organization-Specific TLVs | + | | | (Section 3.3.2) | + | | | | + | 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) | + +---------------+----------------+----------------------------------+ + + CCNx Validation-Dependent Data Types + +4.10. Hash Function Type Registry + + IANA has created the "CCNx Hash Function Types" registry and + allocated the hash function types described below. The registration + procedure is Specification Required. The Type value is 2 octets. + The range is 0x0000-0xFFFF. + + + + +Mosko, et al. Experimental [Page 40] + +RFC 8609 CCNx TLV July 2019 + + + +---------------+-----------+---------------------------------------+ + | Type | Name | Reference | + +---------------+-----------+---------------------------------------+ + | 0x0000 | Reserved | | + | | | | + | 0x0001 | T_SHA-256 | Hash Format (Section 3.3.3) | + | | | | + | 0x0002 | T_SHA-512 | Hash Format (Section 3.3.3) | + | | | | + | 0x0FFF | T_ORG | Organization-Specific TLVs (Section | + | | | 3.3.2) | + | | | | + | 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) | + +---------------+-----------+---------------------------------------+ + + CCNx Hash Function Types + +5. Security Considerations + + The CCNx protocol is a Layer 3 network protocol, which may also + operate as an overlay using other transports such as UDP or other + tunnels. It includes intrinsic support for message authentication + via a signature (e.g., RSA or elliptic curve) or Message + Authentication Code (e.g., HMAC). In lieu of an authenticator, it + may instead use a Message Integrity Check (e.g., SHA or CRC). CCNx + does not specify an encryption envelope; that function is left to a + high-layer protocol (e.g., Encrypted Sessions in CCNx [esic]). + + 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 + ECDSA) to all packet types. Because Interest packets can be sent at + will, an application should carefully select when to use a given + ValidationAlgorithm in an Interest to avoid DoS attacks. MICs, for + 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 + general guideline, an application might use a MIC on an Interest to + detect unintentionally corrupted packets. If one wishes to secure an + Interest, one should consider using an encrypted wrapper and a + protocol that prevents replay attacks, especially if the Interest is + being used as an actuator. Simply using an authentication code or + signature does not make an Interest secure. There are several + examples in the literature on how to secure ICN-style messaging + [mobile] [ace]. + + + + + + +Mosko, et al. Experimental [Page 41] + +RFC 8609 CCNx TLV July 2019 + + + 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 + include a public key embedded in the object or may use the + PublicKeyLocator field to point to a public key (or public-key + certificate) that authenticates the message. One key exchange + specification is CCNxKE [ccnxke] [mobile], which is similar to the + TLS 1.3 key exchange except it is over the CCNx Layer 3 messages. + Trust is beyond the scope of a Layer 3 protocol and is left to + applications or application frameworks. + + The combination of an ephemeral key exchange (e.g., CCNxKE [ccnxke]) + and an encapsulating encryption (e.g., [esic]) provides the + equivalent of a TLS tunnel. Intermediate nodes may forward the + Interests and Content Objects but have no visibility inside. It also + completely hides the internal names in those used by the encryption + layer. This type of tunneling encryption is useful for content that + has little or no cacheability, as it can only be used by someone with + the ephemeral key. Short-term caching may help with lossy links or + mobility, but long-term caching is usually not of interest. + + Broadcast encryption or proxy re-encryption may be useful for content + with multiple uses over time or many consumers. There is currently + no recommendation for this form of encryption. + + The specific encoding of messages will have security implications. + This document uses a Type-Length-Value (TLV) encoding. We chose to + compromise between extensibility and unambiguous encodings of types + and lengths. Some TLV encodings use variable-length T and variable- + length L fields to accommodate a wide gamut of values while trying to + be byte efficient. Our TLV encoding uses a fixed length 2-byte T and + 2-byte L. Using fixed-length T and L fields solves two problems. + The first is aliases. If one is able to encode the same value, such + as 0x02 and 0x0002, in different byte lengths, then one must decide + if they mean the same thing, if they are different, or if one is + illegal. If they are different, then one must always compare on the + buffers not the integer equivalents. If one is illegal, then one + must validate the TLV encoding -- every field of every packet at + every hop. If they are the same, then one has the second problem: + how to specify packet filters. For example, if a name has 6 name + components, then there are 7 T fields and 7 L fields, each of which + might have up to 4 representations of the same value. That would be + 14 fields with 4 encodings each, or 1001 combinations. It also means + that one cannot compare, for example, a name via a memory function, + as one needs to consider that any embedded T or L might have a + different format. + + + + + + +Mosko, et al. Experimental [Page 42] + +RFC 8609 CCNx TLV July 2019 + + + The Interest Return message has no authenticator from the previous + hop. Therefore, the payload of the Interest Return should only be + used locally to match an Interest. A node should never forward that + Interest payload as an Interest. It should also verify that it sent + the Interest in the Interest Return to that node and not allow anyone + to negate Interest messages. + + Caching nodes must take caution when processing content objects. It + is essential that the Content Store obey the rules outlined in + [RFC8569] to avoid certain types of attacks. CCNx 1.0 has no + mechanism to work around an undesired result from the network (there + are no "excludes"), so if a cache becomes poisoned with bad content + it might cause problems retrieving content. There are three types of + access to content from a Content Store: unrestricted, signature + restricted, and hash restricted. If an Interest has no restrictions, + then the requester is not particular about what they get back, so any + matching cached object is OK. In the hash restricted case, the + requester is very specific about what they want, and the Content + Store (and every forward hop) can easily verify that the content + matches the request. In the signature restricted case (which is + often used for initial manifest discovery), the requester only knows + the KeyId that signed the content. This case requires the closest + attention in the Content Store to avoid amplifying bad data. The + Content Store must only respond with a content object if it can + verify the signature -- this means either the content object carries + the public key inside it or the Interest carries the public key in + addition to the KeyId. If that is not the case, then the Content + Store should treat the Interest as a cache miss and let an endpoint + respond. + + A user-level cache could perform full signature verification by + fetching a public key according to the PublicKeyLocator. However, + 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 + cache operator only inserting content that it knows has the correct + signature. + + The CCNx grammar allows for hash algorithm agility via the HashType. + It specifies a short list of acceptable hash algorithms that should + be implemented at each forwarder. Some hash values only apply to end + systems, so updating the hash algorithm does not affect forwarders -- + they would simply match the buffer that includes the type-length-hash + buffer. Some fields, such as the ConObjHash, must be verified at + each hop, so a forwarder (or related system) must know the hash + algorithm, and it could cause backward compatibility problems if the + hash type is updated. + + + + + +Mosko, et al. Experimental [Page 43] + +RFC 8609 CCNx TLV July 2019 + + + A CCNx name uses binary matching, whereas a URI uses a case- + insensitive hostname. Some systems may also use case-insensitive + matching of the URI path to a resource. An implication of this is + that human-entered CCNx names will likely have case or non-ASCII + symbol mismatches unless one uses a consistent URI normalization for + the CCNx name. It also means that an entity that registers a CCNx- + routable prefix -- say, "ccnx:/example.com" -- would need separate + registrations for simple variations like "ccnx:/Example.com". Unless + this is addressed in URI normalization and routing protocol + conventions, there could be phishing attacks. + + For a more general introduction to ICN-related security concerns and + approaches, see [RFC7927] and [RFC7945]. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +6.2. Informative References + + [ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, + "NDN-ACE: Access control for constrained environments over + named data networking", NDN Technical Report NDN-0036, + 2015, <http://new.named-data.net/wp-content/uploads/2015/ + 12/ndn-0036-1-ndn-ace.pdf>. + + [ccnxke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange + Protocol Version 1.0", Work in Progress, draft-wood-icnrg- + ccnxkeyexchange-02, March 2017. + + [CCNxURI] Mosko, M. and C. Wood, "The CCNx URI Scheme", Work in + Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016. + + [CCNxz] Mosko, M., "CCNxz TLV Header Compression Experimental + Code", commit f1093a2, March 2018, + <https://github.com/PARC/CCNxz>. + + + + + + +Mosko, et al. Experimental [Page 44] + +RFC 8609 CCNx TLV July 2019 + + + [compress] Mosko, M., "Header Compression for TLV-based Packets", + ICNRG Interim Meeting, 2016, + <https://datatracker.ietf.org/meeting/interim-2016-icnrg- + 02/materials/slides-interim-2016-icnrg-2-7>. + + [ECC] Certicom Research, "SEC 2: Recommended Elliptic Curve + Domain Parameters", 2010, + <http://www.secg.org/sec2-v2.pdf>. + + [esic] Mosko, M. and C. Wood, "Encrypted Sessions In CCNx + (ESIC)", Work in Progress, draft-wood-icnrg-esic-01, + 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 + Content-Centric Networks", IFIP Networking, 2017, + <http://dl.ifip.org/db/conf/networking/ + networking2017/1570334964.pdf>. + + [nnc] Jacobson, V., Smetters, D., Thornton, J., Plass, M., + Briggs, N., and R. Braynard, "Networking Named Content", + Proceedings of the 5th international conference on + Emerging networking experiments and technologies (CoNEXT + '09), 2009, <http://dx.doi.org/10.1145/1658939.1658941>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <https://www.rfc-editor.org/info/rfc5280>. + + [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., + Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, + "Information-Centric Networking (ICN) Research + Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, + <https://www.rfc-editor.org/info/rfc7927>. + + [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., + and G. Boggia, "Information-Centric Networking: Evaluation + and Security Considerations", RFC 7945, + DOI 10.17487/RFC7945, September 2016, + <https://www.rfc-editor.org/info/rfc7945>. + + + + + + + +Mosko, et al. Experimental [Page 45] + +RFC 8609 CCNx TLV July 2019 + + + [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 + + Marc Mosko + PARC, Inc. + Palo Alto, California 94304 + United States of America + + Phone: +01 650-812-4405 + Email: mmosko@parc.com + + + Ignacio Solis + LinkedIn + Mountain View, California 94043 + United States of America + + Email: nsolis@linkedin.com + + + Christopher A. Wood + University of California, Irvine + Irvine, California 92697 + United States of America + + Phone: +01 315-806-5939 + Email: woodc1@uci.edu + + + + + + + + + + + + + + + +Mosko, et al. Experimental [Page 46] + |