idnits 2.17.1 draft-irtf-icnrg-ccnxmessages-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2018) is 2228 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 496 -- Looks like a reference, but probably isn't: '1' on line 496 -- Looks like a reference, but probably isn't: '2' on line 496 == Missing Reference: 'KeyIdRestr' is mentioned on line 555, but not defined == Missing Reference: 'ContentObjectHashRestr' is mentioned on line 555, but not defined == Unused Reference: 'CCN' is defined on line 1850, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1898, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 1908, but no explicit reference was found in the text == Unused Reference: 'RFC6920' is defined on line 1914, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-07 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Mosko 3 Internet-Draft PARC, Inc. 4 Intended status: Experimental I. Solis 5 Expires: September 20, 2018 LinkedIn 6 C. Wood 7 University of California Irvine 8 March 19, 2018 10 CCNx Messages in TLV Format 11 draft-irtf-icnrg-ccnxmessages-07 13 Abstract 15 This document specifies the encoding of CCNx messages in a TLV packet 16 format, including the TLV types used by each message element and the 17 encoding of each value. The semantics of CCNx messages follow the 18 encoding-independent CCNx Semantics specification. 20 This document is a product of the Information Centric Networking 21 research group (ICNRG). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 20, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Type-Length-Value (TLV) Packets . . . . . . . . . . . . . . . 5 61 3.1. Overall packet format . . . . . . . . . . . . . . . . . . 6 62 3.2. Fixed Headers . . . . . . . . . . . . . . . . . . . . . . 7 63 3.2.1. Interest Fixed Header . . . . . . . . . . . . . . . . 8 64 3.2.1.1. Interest HopLimit . . . . . . . . . . . . . . . . 8 65 3.2.2. Content Object Fixed Header . . . . . . . . . . . . . 9 66 3.2.3. InterestReturn Fixed Header . . . . . . . . . . . . . 9 67 3.2.3.1. InterestReturn HopLimit . . . . . . . . . . . . . 9 68 3.2.3.2. InterestReturn Flags . . . . . . . . . . . . . . 9 69 3.2.3.3. Return Code . . . . . . . . . . . . . . . . . . . 10 70 3.3. Global Formats . . . . . . . . . . . . . . . . . . . . . 10 71 3.3.1. Pad . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.3.2. Organization Specific TLVs . . . . . . . . . . . . . 11 73 3.3.3. Hash Format . . . . . . . . . . . . . . . . . . . . . 11 74 3.3.4. Link . . . . . . . . . . . . . . . . . . . . . . . . 12 75 3.4. Hop-by-hop TLV headers . . . . . . . . . . . . . . . . . 13 76 3.4.1. Interest Lifetime . . . . . . . . . . . . . . . . . . 13 77 3.4.2. Recommended Cache Time . . . . . . . . . . . . . . . 14 78 3.4.3. Message Hash . . . . . . . . . . . . . . . . . . . . 14 79 3.5. Top-Level Types . . . . . . . . . . . . . . . . . . . . . 15 80 3.6. CCNx Message . . . . . . . . . . . . . . . . . . . . . . 16 81 3.6.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 82 3.6.1.1. Name Segments . . . . . . . . . . . . . . . . . . 17 83 3.6.1.2. Interest Payload ID . . . . . . . . . . . . . . . 18 84 3.6.2. Message TLVs . . . . . . . . . . . . . . . . . . . . 19 85 3.6.2.1. Interest Message TLVs . . . . . . . . . . . . . . 19 86 3.6.2.2. Content Object Message TLVs . . . . . . . . . . . 20 87 3.6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 22 88 3.6.4. Validation . . . . . . . . . . . . . . . . . . . . . 22 89 3.6.4.1. Validation Algorithm . . . . . . . . . . . . . . 22 90 3.6.4.2. Validation Payload . . . . . . . . . . . . . . . 28 91 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 92 4.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 29 93 4.2. Interest Return Code Registry . . . . . . . . . . . . . . 29 94 4.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 31 95 4.4. Top-Level Type Registry . . . . . . . . . . . . . . . . . 31 96 4.5. Name Segment Type Registry . . . . . . . . . . . . . . . 32 97 4.6. Message Type Registry . . . . . . . . . . . . . . . . . . 33 98 4.7. Payload Type Registry . . . . . . . . . . . . . . . . . . 34 99 4.8. Validation Algorithm Type Registry . . . . . . . . . . . 35 100 4.9. Validation Dependent Data Type Registry . . . . . . . . . 36 101 4.10. Hash Function Type Registry . . . . . . . . . . . . . . . 37 102 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 103 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 104 6.1. Normative References . . . . . . . . . . . . . . . . . . 41 105 6.2. Informative References . . . . . . . . . . . . . . . . . 41 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 108 1. Introduction 110 This document specifies a Type-Length-Value (TLV) packet format and 111 the TLV type and value encodings for CCNx messages. A full 112 description of the CCNx network protocol, providing an encoding-free 113 description of CCNx messages and message elements, may be found in 114 [CCNSemantics]. CCNx is a network protocol that uses a hierarchical 115 name to forward requests and to match responses to requests. It does 116 not use endpoint addresses, such as Internet Protocol. Restrictions 117 in a request can limit the response by the public key of the 118 response's signer or the cryptographic hash of the response. Every 119 CCNx forwarder along the path does the name matching and restriction 120 checking. The CCNx protocol fits within the broader framework of 121 Information Centric Networking (ICN) protocols [RFC7927]. 123 This document describes a TLV scheme using a fixed 2-byte T and a 124 fixed 2-byte L field. The rational for this choice is described in 125 Section 5. Briefly, this choice is to avoid multiple encodings of 126 the same value (aliases) and reduce the work of a validator to ensure 127 compliance. Unlike some uses of TLV in networking, the use here must 128 be evaluated at each network hop, so even small validation latencies 129 could add to a large packet forwarding delay. For very small packets 130 or low throughput links, where the extra bytes may become a concern, 131 one may use a TLV compression protocol, for example [compress] and 132 [CCNxz]. 134 This document specifies: 136 o The TLV packet format. 138 o The overall packet format for CCNx messages. 140 o The TLV types used by CCNx messages. 142 o The encoding of values for each type. 144 o Top level types that exist at the outermost containment. 146 o Interest TLVs that exist within Interest containment. 148 o Content Object TLVs that exist within Content Object containment. 150 This document is supplemented by this document: 152 o Message semantics: see [CCNSemantics] for the protocol operation 153 regarding Interest and Content Object, including the Interest 154 Return protocol. 156 o URI notation: see [CCNxURI] for the CCNx URI notation. 158 The type values in Section 4 represent the values in common usage 159 today. These values may change pending IANA assignments. All type 160 values are relative to their parent containers. It is possible for a 161 TLV to redefine a type value defined by its parent. For example, 162 each level of a nested TLV structure might define a "type = 1" with a 163 completely different meaning. 165 Packets are represented as 32-bit wide words using ASCII art. Due to 166 the nested levels of TLV encoding and the presence of optional fields 167 and variable sizes, there is no concise way to represent all 168 possibilities. We use the convention that ASCII art fields enclosed 169 by vertical bars "|" represent exact bit widths. Fields with a 170 forward slash "/" are variable bit widths, which we typically pad out 171 to word alignment for picture readability. 173 The document represents the consensus of the ICN RG. It is the first 174 ICN protocol from the RG, created from the early CCNx protocol [nnc] 175 with significant revision and input from the ICN community and RG 176 members. The draft has received critical reading by several members 177 of the ICN community and the RG. The authors and RG chairs approve 178 of the contents. The document is sponsored under the IRTF and is not 179 issued by the IETF and is not an IETF standard. This is an 180 experimental protocol and may not be suitable for any specific 181 application and the specification may change in the future. 183 1.1. Requirements Language 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119 [RFC2119]. 189 2. Definitions 191 o Name: A hierarchically structured variable length identifier. It 192 is an ordered list of path segments, which may be variable length 193 octet strings. In human-readable form, it is represented in URI 194 format as ccnx:/path/part. There is no host or query string. See 195 [CCNxURI] for complete details. 197 o Interest: A message requesting a Content Object with a matching 198 Name and other optional selectors to choose from multiple objects 199 with the same Name. Any Content Object with a Name and optional 200 selectors that matches the Name and optional selectors of the 201 Interest is said to satisfy the Interest. 203 o Content Object: A data object sent in response to an Interest 204 request. It has an (optional) Name and a content payload that are 205 bound together via cryptographic means. 207 3. Type-Length-Value (TLV) Packets 209 We use 16-bit Type and 16-bit Length fields to encode TLV based 210 packets. This provides 64K different possible types and value field 211 lengths of up to 64KiB. With 64K possible types, there should be 212 sufficient space for basic protocol types, while also allowing ample 213 room for experimentation, application use, and growth. 215 Specifically, the TLV types in the range 0x1000 - 0x1FFF are reserved 216 for experimental use. These type values are reserved in all TLV 217 container contexts. In the event that more space is needed, either 218 for types or for length, a new version of the protocol would be 219 needed. See Section 3.3.2 for more information about organization 220 specific TLVs. 222 +--------+-------------------------+--------------------------------+ 223 | Abbrev | Name | Description | 224 +--------+-------------------------+--------------------------------+ 225 | T_ORG | Vendor Specific | Information specific to a | 226 | | Information (Section | vendor implementation (see | 227 | | 3.3.2) | below). | 228 | | | | 229 | n/a | Experimental | Experimental use. | 230 +--------+-------------------------+--------------------------------+ 232 Table 1: Reserved TLV Types 234 1 2 235 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 236 +---------------+---------------+---------------+---------------+ 237 | Type | Length | 238 +---------------+---------------+---------------+---------------+ 239 The Length field contains the length of the Value field in octets. 240 It does not include the length of the Type and Length fields. The 241 length MAY be zero. 243 TLV structures are nestable, allowing the Value field of one TLV 244 structure to contain additional TLV structures. The enclosing TLV 245 structure is called the container of the enclosed TLV. 247 Type values are context-dependent. Within a TLV container, one may 248 re-use previous type values for new context-dependent purposes. 250 3.1. Overall packet format 252 Each packet includes the 8 byte fixed header described below, 253 followed by a set of TLV fields. These fields are optional hop-by- 254 hop headers and the Packet Payload. 256 1 2 3 257 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 258 +---------------+---------------+---------------+---------------+ 259 | Version | PacketType | PacketLength | 260 +---------------+---------------+---------------+---------------+ 261 | PacketType specific fields | HeaderLength | 262 +---------------+---------------+---------------+---------------+ 263 / Optional Hop-by-hop header TLVs / 264 +---------------+---------------+---------------+---------------+ 265 / PacketPayload TLVs / 266 +---------------+---------------+---------------+---------------+ 268 The packet payload is a TLV encoding of the CCNx message, followed by 269 optional Validation TLVs. 271 1 2 3 272 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 273 +---------------+---------------+---------------+---------------+ 274 | CCNx Message TLV / 275 +---------------+---------------+---------------+---------------+ 276 / Optional CCNx ValidationAlgorithm TLV / 277 +---------------+---------------+---------------+---------------+ 278 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 279 +---------------+---------------+---------------+---------------+ 281 This document describes the Version "1" TLV encoding. 283 After discarding the fixed and hop-by-hop headers the remaining 284 PacketPayload should be a valid protocol message. Therefore, the 285 PacketPayload always begins with a 4 byte TLV defining the protocol 286 message (whether it is an Interest, Content Object, or other message 287 type) and its total length. The embedding of a self-sufficient 288 protocol data unit inside the fixed and hop-by-hop headers allows a 289 network stack to discard the headers and operate only on the embedded 290 message. 292 The range of bytes protected by the Validation includes the CCNx 293 Message and the ValidationAlgorithm. 295 The ContentObjectHash begins with the CCNx Message and ends at the 296 tail of the packet. 298 3.2. Fixed Headers 300 CCNx messages begin with an 8 byte fixed header (non-TLV format). 301 The HeaderLength field represents the combined length of the Fixed 302 and Hop-by-hop headers. The PacketLength field represents the entire 303 Packet length. 305 A specific PacketType may assign meaning to the "PacketType specific 306 fields". 308 The PacketPayload of a CCNx packet is the protocol message itself. 309 The Content Object Hash is computed over the PacketPayload only, 310 excluding the fixed and hop-by-hop headers as those might change from 311 hop to hop. Signed information or Similarity Hashes should not 312 include any of the fixed or hop-by-hop headers. The PacketPayload 313 should be self-sufficient in the event that the fixed and hop-by-hop 314 headers are removed. 316 1 2 3 317 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 318 +---------------+---------------+---------------+---------------+ 319 | Version | PacketType | PacketLength | 320 +---------------+---------------+---------------+---------------+ 321 | PacketType specific fields | HeaderLength | 322 +---------------+---------------+---------------+---------------+ 324 o Version: defines the version of the packet. 326 o HeaderLength: The length of the fixed header (8 bytes) and hop-by- 327 hop headers. The minimum value MUST be "8". 329 o PacketType: describes forwarder actions to take on the packet. 331 o PacketLength: Total octets of packet including all headers (fixed 332 header plus hop-by-hop headers) and protocol message. 334 o PacketType Specific Fields: specific PacketTypes define the use of 335 these bits. 337 The PacketType field indicates how the forwarder should process the 338 packet. A Request Packet (Interest) has PacketType PT_INTEREST, a 339 Response (Content Object) has PacketType PT_CONTENT, and an 340 InterestReturn Packet has PacketType PT_RETURN. 342 HeaderLength is the number of octets from the start of the packet 343 (Version) to the end of the hop-by-hop headers. PacketLength is the 344 number of octets from the start of the packet to the end of the 345 packet. 347 The PacketType specific fields are reserved bits whose use depends on 348 the PacketType. They are used for network-level signaling. 350 3.2.1. Interest Fixed Header 352 If the PacketType in the Fixed Header is PT_INTEREST, it indicates 353 that the PacketPayload should be processed as an Interest message. 354 For this type of packet, the Fixed Header includes a field for a 355 HopLimit as well as Reserved and Flags fields. The Reserved field 356 MUST be set to 0 in an Interest - this field will be set to a return 357 code in the case of an Interest Return. There are currently no Flags 358 defined, so this field MUST be set to 0. 360 1 2 3 361 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 362 +---------------+---------------+---------------+---------------+ 363 | Version | PT_INTEREST | PacketLength | 364 +---------------+---------------+---------------+---------------+ 365 | HopLimit | Reserved | Flags | HeaderLength | 366 +---------------+---------------+---------------+---------------+ 368 3.2.1.1. Interest HopLimit 370 For an Interest message, the HopLimit is a counter that is 371 decremented with each hop. It limits the distance an Interest may 372 travel on the network. The node originating the Interest MAY put in 373 any value - up to the maximum of 255. Each node that receives an 374 Interest with a HopLimit decrements the value upon reception. If the 375 value is 0 after the decrement, the Interest MUST NOT be forwarded 376 off the node. 378 It is an error to receive an Interest with a 0 hop-limit from a 379 remote node. 381 3.2.2. Content Object Fixed Header 383 If the PacketType in the Fixed Header is PT_CONTENT, it indicates 384 that the PacketPayload should be processed as a Content Object 385 message. A Content Object defines a Flags field, however there are 386 currently no flags defined, so the Flags field must be set to 0. 388 1 2 3 389 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 390 +---------------+---------------+---------------+---------------+ 391 | Version | PT_CONTENT | PacketLength | 392 +---------------+---------------+---------------+---------------+ 393 | Reserved | Flags | HeaderLength | 394 +---------------+---------------+---------------+---------------+ 396 3.2.3. InterestReturn Fixed Header 398 If the PacketType in the Fixed Header is PT_RETURN, it indicates that 399 the PacketPayload should be processed as a returned Interest message. 400 The only difference between this InterestReturn message and the 401 original Interest is that the PacketType is changed to PT_RETURN and 402 a ReturnCode is is put into the Reserved octet. All other fields are 403 unchanged. The purpose of this encoding is to prevent packet length 404 changes so no additional bytes are needed to return an Interest to 405 the previous hop. See [CCNSemantics] for a protocol description of 406 this packet type. 408 1 2 3 409 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 410 +---------------+---------------+---------------+---------------+ 411 | Version | PT_RETURN | PacketLength | 412 +---------------+---------------+---------------+---------------+ 413 | HopLimit | ReturnCode | Flags | HeaderLength | 414 +---------------+---------------+---------------+---------------+ 416 3.2.3.1. InterestReturn HopLimit 418 This is the original Interest's HopLimit, as received. It is the 419 value before being decremented at the current node (i.e. the received 420 value). 422 3.2.3.2. InterestReturn Flags 424 These are the original Flags as set in the Interest. 426 3.2.3.3. Return Code 428 The numeric value assigned to the return types is defined below. 429 This value is set by the node creating the Interest Return. 431 A return code of "0" MUST NOT be used, as it indicates that the 432 returning system did not modify the Return Code field. 434 +-------------------------------------+-----------------------------+ 435 | Type | Return Type | 436 +-------------------------------------+-----------------------------+ 437 | T_RETURN_NO_ROUTE | No Route | 438 | | | 439 | T_RETURN_LIMIT_EXCEEDED | Hop Limit Exceeded | 440 | | | 441 | T_RETURN_NO_RESOURCES | No Resources | 442 | | | 443 | T_RETURN_PATH_ERROR | Path Error | 444 | | | 445 | T_RETURN_PROHIBITED | Prohibited | 446 | | | 447 | T_RETURN_CONGESTED | Congested | 448 | | | 449 | T_RETURN_MTU_TOO_LARGE | MTU too large | 450 | | | 451 | T_RETURN_UNSUPPORTED_HASH_RESTRICTI | Unsupported ContentObjectHa | 452 | ON | shRestriction | 453 | | | 454 | T_RETURN_MALFORMED_INTEREST | Malformed Interest | 455 +-------------------------------------+-----------------------------+ 457 Table 2: Return Codes 459 3.3. Global Formats 461 This section defines global formats that may be nested within other 462 TLVs. 464 3.3.1. Pad 466 The pad type may be used by protocols that prefer word-aligned data. 467 The size of the word may be defined by the protocol. Padding 4-byte 468 words, for example, would use a 1-byte, 2-byte, and 3-byte Length. 469 Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, 7)-byte Length. 471 A pad MAY be inserted after any TLV in the CCNx Message or in the 472 Validation Dependent Data In the remainder of this document, we will 473 not show optional pad TLVs. 475 1 2 3 476 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 477 +---------------+---------------+---------------+---------------+ 478 | T_PAD | Length | 479 +---------------+---------------+---------------+---------------+ 480 / variable length pad MUST be zeros / 481 +---------------+---------------+---------------+---------------+ 483 3.3.2. Organization Specific TLVs 485 Organization specific TLVs MUST use the T_ORG type. The Length field 486 is the length of the organization specific information plus 3. The 487 Value begins with the 3 byte organization number derived from the 488 last three digits of the IANA Private Enterprise Numbers 489 [EpriseNumbers], followed by the organization specific information. 491 1 2 3 492 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 493 +---------------+---------------+---------------+---------------+ 494 | T_ORG | Length (3+value length) | 495 +---------------+---------------+---------------+---------------+ 496 | PEN[0] | PEN[1] | PEN[2] | / 497 +---------------+---------------+---------------+ + 498 / Vendor Specific Value / 499 +---------------+---------------+---------------+---------------+ 501 3.3.3. Hash Format 503 Hash values are used in several fields throughout a packet. This TLV 504 encoding is commonly embedded inside those fields to specify the 505 specific hash function used and it's value. Note that the reserved 506 TLV types are also reserved here for user-defined experimental 507 functions. 509 The LENGTH field of the hash value MUST be less than or equal to the 510 hash function length. If the LENGTH is less than the full length, it 511 is taken as the left LENGTH bytes of the hash function output. Only 512 the specified truncations are allowed. 514 This nested format is used because it allows binary comparison of 515 hash values for certain fields without a router needing to understand 516 a new hash function. For example, the KeyIdRestriction is bit-wise 517 compared between an Interest's KeyIdRestriction field and a 518 ContentObject's KeyId field. This format means the outer field 519 values do not change with differing hash functions so a router can 520 still identify those fields and do a binary comparison of the hash 521 TLV without need to understand the specific hash used. An 522 alternative approach, such as using T_KEYID_SHA512-256, would require 523 each router keep an up-to-date parser and supporting user-defined 524 hash functions here would explode the parsing state-space. 526 A CCN entity MUST support the hash type T_SHA-256. An entity MAY 527 support the remaining hash types. 529 +-----------+------------------------+ 530 | Abbrev | Lengths (octets) | 531 +-----------+------------------------+ 532 | T_SHA-256 | 32 | 533 | | | 534 | T_SHA-512 | 64, 32 | 535 | | | 536 | n/a | Experimental TLV types | 537 +-----------+------------------------+ 539 Table 3: CCNx Hash Functions 541 1 2 3 542 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 543 +---------------+---------------+---------------+---------------+ 544 | T_FOO | 36 | 545 +---------------+---------------+---------------+---------------+ 546 | T_SHA512 | 32 | 547 +---------------+---------------+---------------+---------------+ 548 / 32-byte hash value / 549 +---------------+---------------+---------------+---------------+ 551 Example nesting inside type T_FOO 553 3.3.4. Link 555 A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}. 556 It is a general encoding that is used in both the payload of a 557 Content Object with PayloadType = "Link" and in the KeyLink field in 558 a KeyLocator. 560 1 2 3 561 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 562 +---------------+---------------+-------------------------------+ 563 / Mandatory CCNx Name / 564 +---------------+---------------+-------------------------------+ 565 / Optional KeyIdRestriction / 566 +---------------------------------------------------------------+ 567 / Optional ContentObjectHashRestriction / 568 +---------------------------------------------------------------+ 570 3.4. Hop-by-hop TLV headers 572 Hop-by-hop TLV headers are unordered and meaning MUST NOT be attached 573 to their ordering. Three hop-by-hop headers are described in this 574 document: 576 +-------------+-------------------+---------------------------------+ 577 | Abbrev | Name | Description | 578 +-------------+-------------------+---------------------------------+ 579 | T_INTLIFE | Interest Lifetime | The time an Interest should | 580 | | (Section 3.4.1) | stay pending at an intermediate | 581 | | | node. | 582 | | | | 583 | T_CACHETIME | Recommended Cache | The Recommended Cache Time for | 584 | | Time (Section | Content Objects. | 585 | | 3.4.2) | | 586 | | | | 587 | T_MSGHASH | Message Hash | The hash of the CCNx Message to | 588 | | (Section 3.4.3) | end of packet using Section | 589 | | | 3.3.3 format. | 590 +-------------+-------------------+---------------------------------+ 592 Table 4: Hop-by-hop Header Types 594 Additional hop-by-hop headers are defined in higher level 595 specifications such as the fragmentation specification. 597 3.4.1. Interest Lifetime 599 The Interest Lifetime is the time that an Interest should stay 600 pending at an intermediate node. It is expressed in milliseconds as 601 an unsigned, network byte order integer. 603 A value of 0 (encoded as 1 byte %x00) indicates the Interest does not 604 elicit a Content Object response. It should still be forwarded, but 605 no reply is expected. 607 1 2 3 608 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 609 +---------------+---------------+---------------+---------------+ 610 | T_INTLIFE | Length | 611 +---------------+---------------+---------------+---------------+ 612 / / 613 / Lifetime (length octets) / 614 / / 615 +---------------+---------------+---------------+---------------+ 617 3.4.2. Recommended Cache Time 619 The Recommended Cache Time (RCT) is a measure of the useful lifetime 620 of a Content Object as assigned by a content producer or upstream 621 node. It serves as a guideline to the Content Store cache in 622 determining how long to keep the Content Object. It is a 623 recommendation only and may be ignored by the cache. This is in 624 contrast to the ExpiryTime (described in Section 3.6.2.2.2) which 625 takes precedence over the RCT and must be obeyed. 627 Because the Recommended Cache Time is an optional hop-by-hop header 628 and not a part of the signed message, a content producer may re-issue 629 a previously signed Content Object with an updated RCT without 630 needing to re-sign the message. There is little ill effect from an 631 attacker changing the RCT as the RCT serves as a guideline only. 633 The Recommended Cache Time (a millisecond timestamp) is a network 634 byte ordered unsigned integer of the number of milliseconds since the 635 epoch in UTC of when the payload expires. It is a 64-bit field. 637 1 2 3 638 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 639 +---------------+---------------+---------------+---------------+ 640 | T_CACHETIME | 8 | 641 +---------------+---------------+---------------+---------------+ 642 / / 643 / Recommended Cache Time / 644 / / 645 +---------------+---------------+---------------+---------------+ 647 3.4.3. Message Hash 649 Within a trusted domain, an operator may calculate the message hash 650 at a border device and insert that value into the hop-by-hop headers 651 of a message. An egress device should remove the value. This 652 permits intermediate devices within that trusted domain to match 653 against a ContentObjectHashRestriction without calculating it at 654 every hop. 656 The message hash is a cryptographic hash from the start of the CCNx 657 Message to the end of the packet. It is used to match against the 658 ContentObjectHashRestriction (Section 3.6.2.1.2). The Message Hash 659 may be of longer length than an Interest's restriction, in which case 660 the device should use the left bytes of the Message Hash to check 661 against the Interest's value. 663 The Message Hash may only carry one hash type and there may only be 664 one Message Hash header. 666 The Message Hash header is unprotected, so this header is only of 667 practical use within a trusted domain, such as an operator's 668 autonomous system. 670 1 2 3 671 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 672 +---------------+---------------+---------------+---------------+ 673 | T_MSGHASH | (length + 4) | 674 +---------------+---------------+---------------+---------------+ 675 | (hash type) | length | 676 +---------------+---------------+---------------+---------------+ 677 / hash value / 678 +---------------+---------------+---------------+---------------+ 680 Message Hash Header 682 3.5. Top-Level Types 684 The top-level TLV types listed below exist at the outermost level of 685 a CCNx protocol message. 687 +----------------------+-------------------+------------------------+ 688 | Abbrev | Name | Description | 689 +----------------------+-------------------+------------------------+ 690 | T_INTEREST | Interest (Section | An Interest | 691 | | 3.6) | MessageType. | 692 | | | | 693 | T_OBJECT | Content Object | A Content Object | 694 | | (Section 3.6) | MessageType | 695 | | | | 696 | T_VALIDATION_ALG | Validation | The method of message | 697 | | Algorithm | verification such as | 698 | | (Section 3.6.4.1) | Message Integrity | 699 | | | Check (MIC), a Message | 700 | | | Authentication Code | 701 | | | (MAC), or a | 702 | | | cryptographic | 703 | | | signature. | 704 | | | | 705 | T_VALIDATION_PAYLOAD | Validation | The validation output, | 706 | | Payload (Section | such as the CRC32C | 707 | | 3.6.4.2) | code or the RSA | 708 | | | signature. | 709 +----------------------+-------------------+------------------------+ 711 Table 5: CCNx Top Level Types 713 3.6. CCNx Message 715 This is the format for the CCNx protocol message itself. The CCNx 716 message is the portion of the packet between the hop-by-hop headers 717 and the Validation TLVs. The figure below is an expansion of the 718 "CCNx Message TLV" depicted in the beginning of Section 3. The CCNx 719 message begins with MessageType and runs through the optional 720 Payload. The same general format is used for both Interest and 721 Content Object messages which are differentiated by the MessageType 722 field. The first enclosed TLV of a CCNx Message is always the Name 723 TLV. This is followed by an optional Message TLVs and an optional 724 Payload TLV. 726 1 2 3 727 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 728 +---------------+---------------+---------------+---------------+ 729 | MessageType | MessageLength | 730 +---------------+---------------+---------------+---------------+ 731 | Name TLV (Type = T_NAME) | 732 +---------------+---------------+---------------+---------------+ 733 / Optional Message TLVs (Various Types) / 734 +---------------+---------------+---------------+---------------+ 735 / Optional Payload TLV (Type = T_PAYLOAD) / 736 +---------------+---------------+---------------+---------------+ 738 +-----------+-----------------+-------------------------------------+ 739 | Abbrev | Name | Description | 740 +-----------+-----------------+-------------------------------------+ 741 | T_NAME | Name (Section | The CCNx Name requested in an | 742 | | 3.6.1) | Interest or published in a Content | 743 | | | Object. | 744 | | | | 745 | T_PAYLOAD | Payload | The message payload. | 746 | | (Section 3.6.3) | | 747 +-----------+-----------------+-------------------------------------+ 749 Table 6: CCNx Message Types 751 3.6.1. Name 753 A Name is a TLV encoded sequence of segments. The table below lists 754 the type values appropriate for these Name segments. A Name MUST NOT 755 include PAD TLVs. 757 As described in CCNx Semantics [CCNSemantics], using the CCNx URI 758 [CCNxURI] notation, a T_NAME with 0 length corresponds to ccnx:/ (the 759 default route) and is distinct from a name with one zero length 760 segment, such as ccnx:/NAME=. In the TLV encoding, ccnx:/ 761 corresponds to T_NAME with 0 length, while ccnx:/NAME= corresponds to 762 T_NAME with 4 length and T_NAMESEGMENT with 0 length. 764 1 2 3 765 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 766 +---------------+---------------+---------------+---------------+ 767 | T_NAME | Length | 768 +---------------+---------------+---------------+---------------+ 769 / Name segment TLVs / 770 +---------------+---------------+---------------+---------------+ 772 +---------------+-------------------+-------------------------------+ 773 | Symbolic Name | Name | Description | 774 +---------------+-------------------+-------------------------------+ 775 | T_NAMESEGMENT | Name segment | A generic name Segment. | 776 | | (Section 3.6.1.1) | | 777 | | | | 778 | T_IPID | Interest Payload | An identifier that represents | 779 | | ID (Section | the Interest Payload field. | 780 | | 3.6.1.2) | As an example, the Payload ID | 781 | | | might be a hash of the | 782 | | | Interest Payload. This | 783 | | | provides a way to | 784 | | | differentiate between | 785 | | | Interests based on their | 786 | | | payloads without having to | 787 | | | parse all the bytes of the | 788 | | | payload itself; instead using | 789 | | | only this Payload ID Name | 790 | | | segment. | 791 | | | | 792 | T_APP:00 - | Application | Application-specific payload | 793 | T_APP:4096 | Components | in a name segment. An | 794 | | (Section 3.6.1.1) | application may apply its own | 795 | | | semantics to the 4096 | 796 | | | reserved types. | 797 +---------------+-------------------+-------------------------------+ 799 Table 7: CCNx Name Types 801 3.6.1.1. Name Segments 803 4096 special application payload name segments are allocated. These 804 have application semantics applied to them. A good convention is to 805 put the application's identity in the name prior to using these name 806 segments. 808 For example, a name like "ccnx:/foo/bar/hi" would be encoded as: 810 1 2 3 811 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 812 +---------------+---------------+---------------+---------------+ 813 | (T_NAME) | %x14 (20) | 814 +---------------+---------------+---------------+---------------+ 815 | (T_NAME_SEGMENT) | %x03 (3) | 816 +---------------+---------------+---------------+---------------+ 817 | f o o |(T_NAME_SEGMENT) 818 +---------------+---------------+---------------+---------------+ 819 | | %x03 (3) | b | 820 +---------------+---------------+---------------+---------------+ 821 | a r | (T_NAME_SEGMENT) | 822 +---------------+---------------+---------------+---------------+ 823 | %x02 (2) | h | i | 824 +---------------+---------------+---------------+---------------+ 826 3.6.1.2. Interest Payload ID 828 The InterestPayloadID is a name segment created by the origin of an 829 Interest to represent the Interest Payload. This allows the proper 830 multiplexing of Interests based on their name if they have different 831 payloads. A common representation is to use a hash of the Interest 832 Payload as the InterestPayloadID. 834 As part of the TLV 'value', the InterestPayloadID contains a one 835 identifier of method used to create the InterestPayloadID followed by 836 a variable length octet string. An implementation is not required to 837 implement any of the methods to receive an Interest; the 838 InterestPayloadID may be treated only as an opaque octet string for 839 purposes of multiplexing Interests with different payloads. Only a 840 device creating an InterestPayloadID name segment or a device 841 verifying such a segment need to implement the algorithms. 843 It uses the Section 3.3.3 encoding of hash values. 845 In normal operations, we recommend displaying the InterestPayloadID 846 as an opaque octet string in a CCNx URI, as this is the common 847 denominator for implementation parsing. 849 The InterestPayloadID, even if it is a hash, should not convey any 850 security context. If a system requires confirmation that a specific 851 entity created the InterestPayload, it should use a cryptographic 852 signature on the Interest via the ValidationAlgorithm and 853 ValidationPayload or use its own methods inside the Interest Payload. 855 3.6.2. Message TLVs 857 Each message type (Interest or Content Object) is associated with a 858 set of optional Message TLVs. Additional specification documents may 859 extend the types associated with each. 861 3.6.2.1. Interest Message TLVs 863 There are two Message TLVs currently associated with an Interest 864 message: the KeyIdRestriction selector and the ContentObjectHashRestr 865 selector are used to narrow the universe of acceptable Content 866 Objects that would satisfy the Interest. 868 1 2 3 869 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 870 +---------------+---------------+---------------+---------------+ 871 | MessageType | MessageLength | 872 +---------------+---------------+---------------+---------------+ 873 | Name TLV | 874 +---------------+---------------+---------------+---------------+ 875 / Optional KeyIdRestriction TLV / 876 +---------------------------------------------------------------+ 877 / Optional ContentObjectHashRestriction TLV / 878 +---------------------------------------------------------------+ 880 +----------------+------------------------------+-------------------+ 881 | Abbrev | Name | Description | 882 +----------------+------------------------------+-------------------+ 883 | T_KEYIDRESTR | KeyIdRestriction (Section | A Section 3.3.3 | 884 | | 3.6.2.1.1) | representation of | 885 | | | the KeyId | 886 | | | | 887 | T_OBJHASHRESTR | ContentObjectHashRestriction | A Section 3.3.3 | 888 | | (Section 3.6.2.1.2) | representation of | 889 | | | the hash of the | 890 | | | specific Content | 891 | | | Object that would | 892 | | | satisfy the | 893 | | | Interest. | 894 +----------------+------------------------------+-------------------+ 896 Table 8: CCNx Interest Message TLV Types 898 3.6.2.1.1. KeyIdRestriction 900 An Interest MAY include a KeyIdRestriction selector. This ensures 901 that only Content Objects with matching KeyIds will satisfy the 902 Interest. See Section 3.6.4.1.4.1 for the format of a KeyId. 904 3.6.2.1.2. ContentObjectHashRestriction 906 An Interest MAY contain a ContentObjectHashRestriction selector. 907 This is the hash of the Content Object - the self-certifying name 908 restriction that must be verified in the network, if an Interest 909 carried this restriction. It is calculated from the beginning of the 910 CCNx Message to the end of the packet. The LENGTH MUST be from one 911 of the allowed values for that hash (see Section 3.3.3). 913 The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of 914 length 32 bytes. 916 1 2 3 917 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 918 +---------------+---------------+---------------+---------------+ 919 | T_OBJHASHRESTR | LENGTH+4 | 920 +---------------+---------------+---------------+---------------+ 921 | | LENGTH | 922 +---------------+---------------+---------------+---------------+ 923 / LENGTH octets of hash / 924 +---------------+---------------+---------------+---------------+ 926 3.6.2.2. Content Object Message TLVs 928 The following message TLVs are currently defined for Content Objects: 929 PayloadType (optional) and ExpiryTime (optional). 931 1 2 3 932 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 933 +---------------+---------------+---------------+---------------+ 934 | MessageType | MessageLength | 935 +---------------+---------------+---------------+---------------+ 936 | Name TLV | 937 +---------------+---------------+---------------+---------------+ 938 / Optional PayloadType TLV / 939 +---------------------------------------------------------------+ 940 / Optional ExpiryTime TLV / 941 +---------------------------------------------------------------+ 942 +-------------+---------------------+-------------------------------+ 943 | Abbrev | Name | Description | 944 +-------------+---------------------+-------------------------------+ 945 | T_PAYLDTYPE | PayloadType | Indicates the type of Payload | 946 | | (Section 3.6.2.2.1) | contents. | 947 | | | | 948 | T_EXPIRY | ExpiryTime (Section | The time at which the Payload | 949 | | 3.6.2.2.2) | expires, as expressed in the | 950 | | | number of milliseconds since | 951 | | | the epoch in UTC. If | 952 | | | missing, Content Object may | 953 | | | be used as long as desired. | 954 +-------------+---------------------+-------------------------------+ 956 Table 9: CCNx Content Object Message TLV Types 958 3.6.2.2.1. PayloadType 960 The PayloadType is a network byte order integer representing the 961 general type of the Payload TLV. 963 o T_PAYLOADTYPE_DATA: Data (possibly encrypted) 965 o T_PAYLOADTYPE_KEY: Key 967 o T_PAYLOADTYPE_LINK: Link 969 The Data type indicate that the Payload of the ContentObject is 970 opaque application bytes. The Key type indicates that the Payload is 971 a DER encoded public key. The Link type indicates that the Payload 972 is one or more Link (Section 3.3.4). If this field is missing, a 973 "Data" type is assumed. 975 1 2 3 976 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 977 +---------------+---------------+---------------+---------------+ 978 | T_PAYLDTYPE | Length | 979 +---------------+---------------+---------------+---------------+ 980 | PayloadType / 981 +---------------+ 983 3.6.2.2.2. ExpiryTime 985 The ExpiryTime is the time at which the Payload expires, as expressed 986 by a timestamp containing the number of milliseconds since the epoch 987 in UTC. It is a network byte order unsigned integer in a 64-bit 988 field. A cache or end system should not respond with a Content 989 Object past its ExpiryTime. Routers forwarding a Content Object do 990 not need to check the ExpiryTime. If the ExpiryTime field is 991 missing, the Content Object has no expressed expiration and a cache 992 or end system may use the Content Object for as long as desired. 994 1 2 3 995 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 996 +---------------+---------------+---------------+---------------+ 997 | T_EXPIRY | 8 | 998 +---------------+---------------+---------------+---------------+ 999 / ExpiryTime / 1000 / / 1001 +---------------+---------------+---------------+---------------+ 1003 3.6.3. Payload 1005 The Payload TLV contains the content of the packet. It MAY be of 1006 zero length. If a packet does not have any payload, this field MAY 1007 be omitted, rather than carrying a zero length. 1009 1 2 3 1010 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 1011 +---------------+---------------+---------------+---------------+ 1012 | T_PAYLOAD | Length | 1013 +---------------+---------------+---------------+---------------+ 1014 / Payload Contents / 1015 +---------------+---------------+---------------+---------------+ 1017 3.6.4. Validation 1019 Both Interests and Content Objects have the option to include 1020 information about how to validate the CCNx message. This information 1021 is contained in two TLVs: the ValidationAlgorithm TLV and the 1022 ValidationPayload TLV. The ValidationAlgorithm TLV specifies the 1023 mechanism to be used to verify the CCNx message. Examples include 1024 verification with a Message Integrity Check (MIC), a Message 1025 Authentication Code (MAC), or a cryptographic signature. The 1026 ValidationPayload TLV contains the validation output, such as the 1027 CRC32C code or the RSA signature. 1029 An Interest would most likely only use a MIC type of validation - a 1030 crc, checksum, or digest. 1032 3.6.4.1. Validation Algorithm 1034 The ValidationAlgorithm is a set of nested TLVs containing all of the 1035 information needed to verify the message. The outermost container 1036 has type = T_VALIDATION_ALG. The first nested TLV defines the 1037 specific type of validation to be performed on the message. The type 1038 is identified with the "ValidationType" as shown in the figure below 1039 and elaborated in the table below. Nested within that container are 1040 the TLVs for any ValidationType dependent data, for example a Key Id, 1041 Key Locator etc. 1043 Complete examples of several types may be found in Section 3.6.4.1.5 1045 1 2 3 1046 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 1047 +---------------+---------------+---------------+---------------+ 1048 | T_VALIDATION_ALG | ValidationAlgLength | 1049 +---------------+---------------+---------------+---------------+ 1050 | ValidationType | Length | 1051 +---------------+---------------+---------------+---------------+ 1052 / ValidationType dependent data / 1053 +---------------+---------------+---------------+---------------+ 1055 +---------------+---------------------+-----------------------------+ 1056 | Abbrev | Name | Description | 1057 +---------------+---------------------+-----------------------------+ 1058 | T_CRC32C | CRC32C (Section | Castagnoli CRC32 (iSCSI, | 1059 | | 3.6.4.1.1) | ext4, etc.), with normal | 1060 | | | form polynomial 0x1EDC6F41. | 1061 | | | | 1062 | T_HMAC-SHA256 | HMAC-SHA256 | HMAC (RFC 2104) using | 1063 | | (Section 3.6.4.1.2) | SHA256 hash. | 1064 | | | | 1065 | T_RSA-SHA256 | RSA-SHA256 (Section | RSA public key signature | 1066 | | 3.6.4.1.3) | using SHA256 digest. | 1067 | | | | 1068 | EC-SECP-256K1 | SECP-256K1 (Section | Elliptic Curve signature | 1069 | | 3.6.4.1.3) | with SECP-256K1 parameters | 1070 | | | (see [ECC]). | 1071 | | | | 1072 | EC-SECP-384R1 | SECP-384R1 (Section | Elliptic Curve signature | 1073 | | 3.6.4.1.3) | with SECP-384R1 parameters | 1074 | | | (see [ECC]). | 1075 +---------------+---------------------+-----------------------------+ 1077 Table 10: CCNx Validation Types 1079 3.6.4.1.1. Message Integrity Checks 1081 MICs do not require additional data in order to perform the 1082 verification. An example is CRC32C that has a "0" length value. 1084 3.6.4.1.2. Message Authentication Checks 1086 MACs are useful for communication between two trusting parties who 1087 have already shared private keys. Examples include an RSA signature 1088 of a SHA256 digest or others. They rely on a KeyId. Some MACs might 1089 use more than a KeyId, but those would be defined in the future. 1091 3.6.4.1.3. Signature 1093 Signature type Validators specify a digest mechanism and a signing 1094 algorithm to verify the message. Examples include RSA signature og a 1095 SHA256 digest, an Elliptic Curve signature with SECP-256K1 1096 parameters, etc. These Validators require a KeyId and a mechanism 1097 for locating the publishers public key (a KeyLocator) - optionally a 1098 PublicKey or Certificate or KeyLink. 1100 3.6.4.1.4. Validation Dependent Data 1102 Different Validation Algorithms require access to different pieces of 1103 data contained in the ValidationAlgorithm TLV. As described above, 1104 Key Ids, Key Locators, Public Keys, Certificates, Links and Key Names 1105 all play a role in different Validation Algorithms. Any number of 1106 Validation Dependent Data containers can be present in a Validation 1107 Algorithm TLV. 1109 Following is a table of CCNx ValidationType dependent data types: 1111 +-------------+-----------------------+-----------------------------+ 1112 | Abbrev | Name | Description | 1113 +-------------+-----------------------+-----------------------------+ 1114 | T_KEYID | SignerKeyId (Section | An identifier of the shared | 1115 | | 3.6.4.1.4.1) | secret or public key | 1116 | | | associated with a MAC or | 1117 | | | Signature. | 1118 | | | | 1119 | T_PUBLICKEY | Public Key (Section | DER encoded public key. | 1120 | | 3.6.4.1.4.2) | | 1121 | | | | 1122 | T_CERT | Certificate (Section | DER encoded X509 | 1123 | | 3.6.4.1.4.3) | certificate. | 1124 | | | | 1125 | T_KEYLINK | KeyLink (Section | A CCNx Link object. | 1126 | | 3.6.4.1.4.4) | | 1127 | | | | 1128 | T_SIGTIME | SignatureTime | A millsecond timestamp | 1129 | | (Section 3.6.4.1.4.5) | indicating the time when | 1130 | | | the signature was created. | 1131 +-------------+-----------------------+-----------------------------+ 1133 Table 11: CCNx Validation Dependent Data Types 1135 3.6.4.1.4.1. KeyId 1137 The KeyId is the publisher key identifier. It is similar to a 1138 Subject Key Identifier from X509 [RFC 5280, Section 4.2.1.2]. It 1139 should be derived from the key used to sign, such as from the SHA-256 1140 hash of the key. It applies to both public/private key systems and 1141 to symmetric key systems. 1143 The KeyId is represented using the Section 3.3.3. If a protocol uses 1144 a non-hash identifier, it should use one of the reserved values. 1146 1 2 3 1147 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 1148 +---------------+---------------+---------------+---------------+ 1149 | T_KEYID | LENGTH+4 | 1150 +---------------+---------------+---------------+---------------+ 1151 | | LENGTH | 1152 +---------------+---------------+---------------+---------------+ 1153 / LENGTH octets of hash / 1154 +---------------+---------------+---------------+---------------+ 1156 3.6.4.1.4.2. Public Key 1158 A Public Key is a DER encoded Subject Public Key Info block, as in an 1159 X509 certificate. 1161 1 1162 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1163 +---------------+---------------+---------------+---------------+ 1164 | T_PUBLICKEY | Length | 1165 +---------------+---------------+---------------+---------------+ 1166 / Public Key (DER encoded SPKI) / 1167 +---------------+---------------+---------------+---------------+ 1169 3.6.4.1.4.3. Certificate 1171 1 2 3 1172 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 1173 +---------------+---------------+---------------+---------------+ 1174 | T_CERT | Length | 1175 +---------------+---------------+---------------+---------------+ 1176 / Certificate (DER encoded X509) / 1177 +---------------+---------------+---------------+---------------+ 1179 3.6.4.1.4.4. KeyLink 1181 A KeyLink type KeyLocator is a Link. 1183 The KeyLink ContentObjectHashRestr, if included, is the digest of the 1184 Content Object identified by KeyLink, not the digest of the public 1185 key. Likewise, the KeyIdRestr of the KeyLink is the KeyId of the 1186 ContentObject, not necessarily of the wrapped key. 1188 1 2 3 1189 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 1190 +---------------+---------------+-------------------------------+ 1191 | T_KEYKINK | Length | 1192 +---------------+---------------+-------------------------------+ 1193 / Link / 1194 +---------------------------------------------------------------+ 1196 3.6.4.1.4.5. SignatureTime 1198 The SignatureTime is a millisecond timestamp indicating the time at 1199 which a signature was created. The signer sets this field to the 1200 current time when creating a signature. A verifier may use this time 1201 to determine whether or not the signature was created during the 1202 validity period of a key, or if it occurred in a reasonable sequence 1203 with other associated signatures. The SignatureTime is unrelated to 1204 any time associated with the actual CCNx Message, which could have 1205 been created long before the signature. The default behavior is to 1206 always include a SignatureTime when creating an authenticated message 1207 (e.g. HMAC or RSA). 1209 SignatureTime is a network byte ordered unsigned integer of the 1210 number of milliseconds since the epoch in UTC of when the signature 1211 was created. It is a fixed 64-bit field. 1213 1 2 3 1214 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 1215 +---------------+---------------+-------------------------------+ 1216 | T_SIGTIME | 8 | 1217 +---------------+---------------+-------------------------------+ 1218 / SignatureTime / 1219 +---------------------------------------------------------------+ 1221 3.6.4.1.5. Validation Examples 1223 As an example of a MIC type validation, the encoding for CRC32C 1224 validation would be: 1226 1 2 3 1227 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 1228 +---------------+---------------+---------------+---------------+ 1229 | T_VALIDATION_ALG | 4 | 1230 +---------------+---------------+---------------+---------------+ 1231 | T_CRC32C | 0 | 1232 +---------------+---------------+---------------+---------------+ 1234 As an example of a MAC type validation, the encoding for an HMAC 1235 using a SHA256 hash would be: 1237 1 2 3 1238 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 1239 +---------------+---------------+---------------+---------------+ 1240 | T_VALIDATION_ALG | 40 | 1241 +---------------+---------------+---------------+---------------+ 1242 | T_HMAC-SHA256 | 36 | 1243 +---------------+---------------+---------------+---------------+ 1244 | T_KEYID | 32 | 1245 +---------------+---------------+---------------+---------------+ 1246 / KeyId / 1247 /---------------+---------------+-------------------------------+ 1249 As an example of a Signature type validation, the encoding for an RSA 1250 public key signing using a SHA256 digest and Public Key would be: 1252 1 2 3 1253 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 1254 +---------------+---------------+---------------+---------------+ 1255 | T_VALIDATION_ALG | 44 + Variable Length | 1256 +---------------+---------------+---------------+---------------+ 1257 | T_RSA-SHA256 | 40 + Variable Length | 1258 +---------------+---------------+---------------+---------------+ 1259 | T_KEYID | 32 | 1260 +---------------+---------------+---------------+---------------+ 1261 / KeyId / 1262 /---------------+---------------+-------------------------------+ 1263 | T_PUBLICKEY | Variable Length (~ 160) | 1264 +---------------+---------------+---------------+---------------+ 1265 / Public Key (DER encoded SPKI) / 1266 +---------------+---------------+---------------+---------------+ 1268 3.6.4.2. Validation Payload 1270 1 2 3 1271 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 1272 +---------------+---------------+---------------+---------------+ 1273 | T_VALIDATION_PAYLOAD | ValidationPayloadLength | 1274 +---------------+---------------+---------------+---------------+ 1275 / Type-dependent data / 1276 +---------------+---------------+---------------+---------------+ 1278 The ValidationPayload contains the validation output, such as the 1279 CRC32C code or the RSA signature. 1281 4. IANA Considerations 1283 This section details each kind of protocol value that can be 1284 registered. Each type registry can be updated by incrementally 1285 expanding the type space, i.e., by allocating and reserving new 1286 types. As per [RFC5226] this section details the creation of the 1287 "CCNx Registry" and several sub-registries. 1289 +----------+---------------+ 1290 | Property | Value | 1291 +----------+---------------+ 1292 | Name | CCNx Registry | 1293 | | | 1294 | Abbrev | CCNx | 1295 +----------+---------------+ 1297 Registry Creation 1299 4.1. Packet Type Registry 1301 The following packet types should be allocated. A PacketType MUST be 1302 1 byte. New packet types are allocated via "RFC Required" action. 1304 +----------------+----------------------+ 1305 | Property | Value | 1306 +----------------+----------------------+ 1307 | Name | Packet Type Registry | 1308 | | | 1309 | Parent | CCNx Registry | 1310 | | | 1311 | Review process | RFC Required | 1312 | | | 1313 | Syntax | 1 octet (decimal) | 1314 +----------------+----------------------+ 1316 Registry Creation 1318 +------+-------------+----------------------------------+ 1319 | Type | Name | Reference | 1320 +------+-------------+----------------------------------+ 1321 | 0 | PT_INTEREST | Fixed Header Types (Section 3.2) | 1322 | | | | 1323 | 1 | PT_CONTENT | Fixed Header Types (Section 3.2) | 1324 | | | | 1325 | 2 | PT_RETURN | Fixed Header Types (Section 3.2) | 1326 +------+-------------+----------------------------------+ 1328 Packet Type Namespace 1330 4.2. Interest Return Code Registry 1332 The following InterestReturn code types should be allocated. 1334 +--------------+----------------------------------------------------+ 1335 | Property | Value | 1336 +--------------+----------------------------------------------------+ 1337 | Name | Interest Return Code | 1338 | | | 1339 | Parent | CCNx Registry | 1340 | | | 1341 | Review | Expert Review, should include public standard | 1342 | process | leading to RFC. | 1343 | | | 1344 | Syntax | 1 octet (decimal) | 1345 +--------------+----------------------------------------------------+ 1347 Registry Creation 1349 +------+---------------------------------------+--------------------+ 1350 | Type | Name | Reference | 1351 +------+---------------------------------------+--------------------+ 1352 | 1 | T_RETURN_NO_ROUTE | Fixed Header Types | 1353 | | | (Section 3.2.3.3) | 1354 | | | | 1355 | 2 | T_RETURN_LIMIT_EXCEEDED | Fixed Header Types | 1356 | | | (Section 3.2.3.3) | 1357 | | | | 1358 | 3 | T_RETURN_NO_RESOURCES | Fixed Header Types | 1359 | | | (Section 3.2.3.3) | 1360 | | | | 1361 | 4 | T_RETURN_PATH_ERROR | Fixed Header Types | 1362 | | | (Section 3.2.3.3) | 1363 | | | | 1364 | 5 | T_RETURN_PROHIBITED | Fixed Header Types | 1365 | | | (Section 3.2.3.3) | 1366 | | | | 1367 | 6 | T_RETURN_CONGESTED | Fixed Header Types | 1368 | | | (Section 3.2.3.3) | 1369 | | | | 1370 | 7 | T_RETURN_MTU_TOO_LARGE | Fixed Header Types | 1371 | | | (Section 3.2.3.3) | 1372 | | | | 1373 | 8 | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types | 1374 | | | (Section 3.2.3.3) | 1375 | | | | 1376 | 9 | T_RETURN_MALFORMED_INTEREST | Fixed Header Types | 1377 | | | (Section 3.2.3.3) | 1378 +------+---------------------------------------+--------------------+ 1380 Interest Return Type Namespace 1382 4.3. Hop-by-Hop Type Registry 1384 The following hop-by-hop types should be allocated. 1386 +----------------+----------------------------+ 1387 | Property | Value | 1388 +----------------+----------------------------+ 1389 | Name | Hop-by-Hop Type Registry | 1390 | | | 1391 | Parent | CCNx Registry | 1392 | | | 1393 | Review process | RFC Required | 1394 | | | 1395 | Syntax | 2 octet TLV type (decimal) | 1396 +----------------+----------------------------+ 1398 Registry Creation 1400 +---------------+-------------+-------------------------------------+ 1401 | Type | Name | Reference | 1402 +---------------+-------------+-------------------------------------+ 1403 | 1 | T_INTLIFE | Hop-by-hop TLV headers (Section | 1404 | | | 3.4) | 1405 | | | | 1406 | 2 | T_CACHETIME | Hop-by-hop TLV headers (Section | 1407 | | | 3.4) | 1408 | | | | 1409 | 3 | T_MSGHASH | Hop-by-hop TLV headers (Section | 1410 | | | 3.4) | 1411 | | | | 1412 | 4 - 7 | Reserved | | 1413 | | | | 1414 | %x0FFE | T_PAD | Pad (Section 3.3.1) | 1415 | | | | 1416 | %x0FFF | T_ORG | Organization-Specific TLVs (Section | 1417 | | | 3.3.2) | 1418 | | | | 1419 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1420 +---------------+-------------+-------------------------------------+ 1422 Hop-by-Hop Type Namespace 1424 4.4. Top-Level Type Registry 1426 The following top-level types should be allocated. 1428 +----------------+----------------------------+ 1429 | Property | Value | 1430 +----------------+----------------------------+ 1431 | Name | Top-Level Type Registry | 1432 | | | 1433 | Parent | CCNx Registry | 1434 | | | 1435 | Review process | RFC Required | 1436 | | | 1437 | Syntax | 2 octet TLV type (decimal) | 1438 +----------------+----------------------------+ 1440 Registry Creation 1442 +------+----------------------+-------------------------------+ 1443 | Type | Name | Reference | 1444 +------+----------------------+-------------------------------+ 1445 | 1 | T_INTEREST | Top-Level Types (Section 3.5) | 1446 | | | | 1447 | 2 | T_OBJECT | Top-Level Types (Section 3.5) | 1448 | | | | 1449 | 3 | T_VALIDATION_ALG | Top-Level Types (Section 3.5) | 1450 | | | | 1451 | 4 | T_VALIDATION_PAYLOAD | Top-Level Types (Section 3.5) | 1452 +------+----------------------+-------------------------------+ 1454 Top-Level Type Namespace 1456 4.5. Name Segment Type Registry 1458 The following name segment types should be allocated. 1460 +----------------+-----------------------------------------+ 1461 | Property | Value | 1462 +----------------+-----------------------------------------+ 1463 | Name | Name Segment Type Registry | 1464 | | | 1465 | Parent | CCNx Registry | 1466 | | | 1467 | Review process | Expert Review with public specification | 1468 | | | 1469 | Syntax | 2 octet TLV type (decimal) | 1470 +----------------+-----------------------------------------+ 1472 Registry Creation 1474 +--------------+------------------+---------------------------------+ 1475 | Type | Name | Reference | 1476 +--------------+------------------+---------------------------------+ 1477 | 1 | T_NAMESEGMENT | Name (Section 3.6.1) | 1478 | | | | 1479 | 2 | T_IPID | Name (Section 3.6.1) | 1480 | | | | 1481 | 16 - 19 | Reserved | Used in other drafts | 1482 | | | | 1483 | %x0FFF | T_ORG | Organization-Specific TLVs | 1484 | | | (Section 3.3.2) | 1485 | | | | 1486 | %x1000 - | T_APP:00 - | Application Components (Section | 1487 | %x1FFF | T_APP:4096 | 3.6.1) | 1488 +--------------+------------------+---------------------------------+ 1490 Name Segment Type Namespace 1492 4.6. Message Type Registry 1494 The following CCNx message segment types should be allocated. 1496 +----------------+----------------------------+ 1497 | Property | Value | 1498 +----------------+----------------------------+ 1499 | Name | Message Type Registry | 1500 | | | 1501 | Parent | CCNx Registry | 1502 | | | 1503 | Review process | RFC Required | 1504 | | | 1505 | Syntax | 2 octet TLV type (decimal) | 1506 +----------------+----------------------------+ 1508 Registry Creation 1510 +---------------+----------------+----------------------------------+ 1511 | Type | Name | Reference | 1512 +---------------+----------------+----------------------------------+ 1513 | 0 | T_NAME | Message Types (Section 3.6) | 1514 | | | | 1515 | 1 | T_PAYLOAD | Message Types (Section 3.6) | 1516 | | | | 1517 | 2 | T_KEYIDRESTR | Message Types (Section 3.6) | 1518 | | | | 1519 | 3 | T_OBJHASHRESTR | Message Types (Section 3.6) | 1520 | | | | 1521 | 5 | T_PAYLDTYPE | Content Object Message Types | 1522 | | | (Section 3.6.2.2) | 1523 | | | | 1524 | 6 | T_EXPIRY | Content Object Message Types | 1525 | | | (Section 3.6.2.2) | 1526 | | | | 1527 | 7 - 12 | Reserved | Used in other RFC drafts | 1528 | | | | 1529 | %x0FFE | T_PAD | Pad (Section 3.3.1) | 1530 | | | | 1531 | %x0FFF | T_ORG | Organization-Specific TLVs | 1532 | | | (Section 3.3.2) | 1533 | | | | 1534 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1535 +---------------+----------------+----------------------------------+ 1537 CCNx Message Type Namespace 1539 4.7. Payload Type Registry 1541 The following payload types should be allocated. 1543 +----------------+--------------------------------------------+ 1544 | Property | Value | 1545 +----------------+--------------------------------------------+ 1546 | Name | PayloadType Registry | 1547 | | | 1548 | Parent | CCNx Registry | 1549 | | | 1550 | Review process | Expert Review with public specification | 1551 | | | 1552 | Syntax | Variable length unsigned integer (decimal) | 1553 +----------------+--------------------------------------------+ 1555 Registry Creation 1557 +------+--------------------+-----------------------------------+ 1558 | Type | Name | Reference | 1559 +------+--------------------+-----------------------------------+ 1560 | 0 | T_PAYLOADTYPE_DATA | Payload Types (Section 3.6.2.2.1) | 1561 | | | | 1562 | 1 | T_PAYLOADTYPE_KEY | Payload Types (Section 3.6.2.2.1) | 1563 | | | | 1564 | 2 | T_PAYLOADTYPE_LINK | Payload Types (Section 3.6.2.2.1) | 1565 +------+--------------------+-----------------------------------+ 1567 Payload Type Namespace 1569 4.8. Validation Algorithm Type Registry 1571 The following validation algorithm types should be allocated. 1573 +---------------+---------------------------------------------------+ 1574 | Property | Value | 1575 +---------------+---------------------------------------------------+ 1576 | Name | Validation Algorithm Type Registry | 1577 | | | 1578 | Parent | CCNx Registry | 1579 | | | 1580 | Review | Expert Review with public specification of the | 1581 | process | algorithm | 1582 | | | 1583 | Syntax | 2 octet TLV type (decimal) | 1584 +---------------+---------------------------------------------------+ 1586 Registry Creation 1588 +---------------+---------------+-----------------------------------+ 1589 | Type | Name | Reference | 1590 +---------------+---------------+-----------------------------------+ 1591 | 2 | T_CRC32C | Validation Algorithm (Section | 1592 | | | 3.6.4.1) | 1593 | | | | 1594 | 4 | T_HMAC-SHA256 | Validation Algorithm (Section | 1595 | | | 3.6.4.1) | 1596 | | | | 1597 | 5 | T_RSA-SHA256 | Validation Algorithm (Section | 1598 | | | 3.6.4.1) | 1599 | | | | 1600 | 6 | EC-SECP-256K1 | Validation Algorithm (Section | 1601 | | | 3.6.4.1) | 1602 | | | | 1603 | 7 | EC-SECP-384R1 | Validation Algorithm (Section | 1604 | | | 3.6.4.1) | 1605 | | | | 1606 | %x0FFE | T_PAD | Pad (Section 3.3.1) | 1607 | | | | 1608 | %x0FFF | T_ORG | Organization-Specific TLVs | 1609 | | | (Section 3.3.2) | 1610 | | | | 1611 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1612 +---------------+---------------+-----------------------------------+ 1614 Validation Algorithm Type Namespace 1616 4.9. Validation Dependent Data Type Registry 1618 The following validation dependent data types should be allocated. 1620 +----------------+-----------------------------------------+ 1621 | Property | Value | 1622 +----------------+-----------------------------------------+ 1623 | Name | Validation Dependent Data Type Registry | 1624 | | | 1625 | Parent | CCNx Registry | 1626 | | | 1627 | Review process | RFC Required | 1628 | | | 1629 | Syntax | 2 octet TLV type (decimal) | 1630 +----------------+-----------------------------------------+ 1632 Registry Creation 1634 +---------------+----------------+----------------------------------+ 1635 | Type | Name | Reference | 1636 +---------------+----------------+----------------------------------+ 1637 | 9 | T_KEYID | Validation Dependent Data | 1638 | | | (Section 3.6.4.1.4) | 1639 | | | | 1640 | 10 | T_PUBLICKEYLOC | Validation Dependent Data | 1641 | | | (Section 3.6.4.1.4) | 1642 | | | | 1643 | 11 | T_PUBLICKEY | Validation Dependent Data | 1644 | | | (Section 3.6.4.1.4) | 1645 | | | | 1646 | 12 | T_CERT | Validation Dependent Data | 1647 | | | (Section 3.6.4.1.4) | 1648 | | | | 1649 | 13 | T_LINK | Validation Dependent Data | 1650 | | | (Section 3.6.4.1.4) | 1651 | | | | 1652 | 14 | T_KEYLINK | Validation Dependent Data | 1653 | | | (Section 3.6.4.1.4) | 1654 | | | | 1655 | 15 | T_SIGTIME | Validation Dependent Data | 1656 | | | (Section 3.6.4.1.4) | 1657 | | | | 1658 | %x0FFF | T_ORG | Organization-Specific TLVs | 1659 | | | (Section 3.3.2) | 1660 | | | | 1661 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1662 +---------------+----------------+----------------------------------+ 1664 Validation Dependent Data Type Namespace 1666 4.10. Hash Function Type Registry 1668 The following CCNx hash function types should be allocated. 1670 +--------------+----------------------------------------------------+ 1671 | Property | Value | 1672 +--------------+----------------------------------------------------+ 1673 | Name | Hash Function Type Registry | 1674 | | | 1675 | Parent | CCNx Registry | 1676 | | | 1677 | Review | Expert Review with public specification of the | 1678 | process | hash function | 1679 | | | 1680 | Syntax | 2 octet TLV type (decimal) | 1681 +--------------+----------------------------------------------------+ 1683 Registry Creation 1685 +---------------+-----------+---------------------------------------+ 1686 | Type | Name | Reference | 1687 +---------------+-----------+---------------------------------------+ 1688 | 1 | T_SHA-256 | Hash Format (Section 3.3.3) | 1689 | | | | 1690 | 2 | T_SHA-512 | Hash Format (Section 3.3.3) | 1691 | | | | 1692 | %x0FFF | T_ORG | Organization-Specific TLVs (Section | 1693 | | | 3.3.2) | 1694 | | | | 1695 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1696 +---------------+-----------+---------------------------------------+ 1698 CCNx Hash Function Type Namespace 1700 5. Security Considerations 1702 The CCNx protocol is a layer 3 network protocol, which may also 1703 operate as an overlay using other transports, such as UDP or other 1704 tunnels. It includes intrinsic support for message authentication 1705 via a signature (e.g. RSA or elliptic curve) or message 1706 authentication code (e.g. HMAC). In lieu of an authenticator, it 1707 may instead use a message integrity check (e.g. SHA or CRC). CCNx 1708 does not specify an encryption envelope, that function is left to a 1709 high-layer protocol (e.g. [esic]). 1711 The CCNx message format includes the ability to attach MICs (e.g. 1712 SHA-256 or CRC), MACs (e.g. HMAC), and Signatures (e.g. RSA or 1713 ECDSA) to all packet types. This does not mean that it is a good 1714 idea to use an arbitrary ValidationAlgorithm, nor to include 1715 computationally expensive algorithms in Interest packets, as that 1716 could lead to computational DoS attacks. Applications should use an 1717 explicit protocol to guide their use of packet signatures. As a 1718 general guideline, an application might use a MIC on an Interest to 1719 detect unintentionally corrupted packets. If one wishes to secure an 1720 Interest, one should consider using an encrypted wrapper and a 1721 protocol that prevents replay attacks, especially if the Interest is 1722 being used as an actuator. Simply using an authentication code or 1723 signature does not make an Interests secure. There are several 1724 examples in the literature on how to secure ICN-style messaging 1725 [mobile] [ace]. 1727 As a layer 3 protocol, this document does not describe how one 1728 arrives at keys or how one trusts keys. The CCNx content object may 1729 include a public key embedded in the object or may use the 1730 PublicKeyLocator field to point to a public key (or public key 1731 certificate) that authenticates the message. One key exchange 1732 specification is CCNxKE [ccnxke] [mobile], which is similar to the 1733 TLS 1.3 key exchange except it is over the CCNx layer 3 messages. 1734 Trust is beyond the scope of a layer-3 protocol protocol and left to 1735 applications or application frameworks. 1737 The combination of an ephemeral key exchange (e.g. CCNxKE [ccnxke]) 1738 and an encapsulating encryption (e.g. [esic]) provides the equivalent 1739 of a TLS tunnel. Intermediate nodes may forward the Interests and 1740 Content Objects, but have no visibility inside. It also completely 1741 hides the internal names in those used by the encryption layer. This 1742 type of tunneling encryption is useful for content that has little or 1743 no cache-ability as it can only be used by someone with the ephemeral 1744 key. Short term caching may help with lossy links or mobility, but 1745 long term caching is usually not of interest. 1747 Broadcast encryption or proxy re-encryption may be useful for content 1748 with multiple uses over time or many consumers. There is currently 1749 no recommendation for this form of encryption. 1751 The specific encoding of messages will have security implications. 1752 This document uses a type-length-value (TLV) encoding. We chose to 1753 compromise between extensibility and unambiguous encodings of types 1754 and lengths. Some TLVs use variable length T and variable length L 1755 fields to accomodate a wide gamut of values while trying to be byte- 1756 efficient. Our TLV encoding uses a fixed length 2-byte T and 2-byte 1757 L. Using a fixed-length T and L field solves two problems. The 1758 first is aliases. If one is able to encode the same value, such as 1759 0x2 and 0x02, in different byte lengths then one must decide if they 1760 mean the same thing, if they are different, or if one is illegal. If 1761 they are different, then one must always compare on the buffers not 1762 the integer equivalents. If one is illegal, then one must validate 1763 the TLV encoding -- every field of every packet at every hop. If 1764 they are the same, then one has the second problem: how to specify 1765 packet filters. For example, if a name has 6 name components, then 1766 there are 7 T's and 7 L's, each of which might have up to 4 1767 representations of the same value. That would be 14 fields with 4 1768 encodings each, or 1001 combinations. It also means that one cannot 1769 compare, for example, a name via a memory function as one needs to 1770 consider that any embedded T or L might have a different format. 1772 The Interest Return message has no authenticator from the previous 1773 hop. Therefore, the payload of the Interest Return should only be 1774 used locally to match an Interest. A node should never forward that 1775 Interest payload as an Interest. It should also verify that it sent 1776 the Interest in the Interest Return to that node and not allow anyone 1777 to negate Interest messages. 1779 Caching nodes must take caution when processing content objects. It 1780 is essential that the Content Store obey the rules outlined in 1781 [CCNSemantics] to avoid certain types of attacks. Unlike NDN, CCNx 1782 1.0 has no mechanism to work around an undesired result from the 1783 network (there are no "excludes"), so if a cache becomes poisoned 1784 with bad content it might cause problems retrieving content. There 1785 are three types of access to content from a content store: 1786 unrestricted, signature restricted, and hash restricted. If an 1787 Interest has no restrictions, then the requester is not particular 1788 about what they get back, so any matching cached object is OK. In 1789 the hash restricted case, the requester is very specific about what 1790 they want and the content store (and every forward hop) can easily 1791 verify that the content matches the request. In the signature 1792 verified case (often used for initial manifest discovery), the 1793 requester only knows the KeyId that signed the content. It is this 1794 case that requires the closest attention in the content store to 1795 avoid amplifying bad data. The content store must only respond with 1796 a content object if it can verify the signature -- this means either 1797 the content object carries the public key inside it or the Interest 1798 carries the public key in addition to the KeyId. If that is not the 1799 case, then the content store should treat the Interest as a cache 1800 miss and let an endpoint respond. 1802 A user-level cache could perform full signature verification by 1803 fetching a public key according to the PublicKeyLocator. That is 1804 not, however, a burden we wish to impose on the forwarder. A user- 1805 level cache could also rely on out-of-band attestation, such as the 1806 cache operator only inserting content that it knows has the correct 1807 signature. 1809 The CCNx grammar allows for hash algorithm agility via the HashType. 1810 It specifies a short list of acceptable hash algorithms that should 1811 be implemented at each forwarder. Some hash values only apply to end 1812 systems, so updating the hash algorithm does not affect forwarders -- 1813 they would simply match the buffer that includes the type-length-hash 1814 buffer. Some fields, such as the ConObjHash, must be verified at 1815 each hop, so a forwarder (or related system) must know the hash 1816 algorithm and it could cause backward compatibility problems if the 1817 hash type is updated. 1819 A CCNx name uses binary matching whereas a URI uses a case 1820 insensitive hostname. Some systems may also use case insensitive 1821 matching of the URI path to a resource. An implication of this is 1822 that human-entered CCNx names will likely have case or non-ASCII 1823 symbol mismatches unless one uses a consistent URI normalization to 1824 the CCNx name. It also means that an entity that registers a CCNx 1825 routable prefix, say ccnx:/example.com, would need separate 1826 registrations for simple variations like ccnx:/Example.com. Unless 1827 this is addressed in URI normalization and routing protocol 1828 conventions, there could be phishing attacks. 1830 For a more general introduction to ICN-related security concerns and 1831 approaches, see [RFC7927] and [RFC7945] 1833 6. References 1835 6.1. Normative References 1837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1838 Requirement Levels", BCP 14, RFC 2119, 1839 DOI 10.17487/RFC2119, March 1997, 1840 . 1842 6.2. Informative References 1844 [ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, 1845 "NDN-ACE: Access control for constrained environments over 1846 named data networking", NDN Technical Report NDN-0036, 1847 2015, . 1850 [CCN] PARC, Inc., "CCNx Open Source", 2007, 1851 . 1853 [CCNSemantics] 1854 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics 1855 (Internet draft)", 2018, . 1858 [ccnxke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange 1859 Protocol Version 1.0", 2017, 1860 . 1863 [CCNxURI] Mosko, M. and C. Wood, "The CCNx URI Scheme (Internet 1864 draft)", 2017, 1865 . 1867 [CCNxz] Mosko, M., "CCNxz TLV Header Compression Experimental 1868 Code", 2016-2018, . 1870 [compress] 1871 Mosko, M., "Header Compression for TLV-based Packets", 1872 2016, . 1876 [ECC] Certicom Research, "SEC 2: Recommended Elliptic Curve 1877 Domain Parameters", 2010, 1878 . 1880 [EpriseNumbers] 1881 IANA, "IANA Private Enterprise Numbers", 2015, 1882 . 1885 [esic] Mosko, M. and C. Wood, "Encrypted Sessions In CCNx 1886 (ESIC)", 2017, 1887 . 1889 [mobile] Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in 1890 Content-Centric Networks", IFIP Networking, 2017, 1891 . 1894 [nnc] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 1895 Briggs, N., and R. Braynard, "Networking Named Content", 1896 2009, . 1898 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1899 Text on Security Considerations", BCP 72, RFC 3552, 1900 DOI 10.17487/RFC3552, July 2003, 1901 . 1903 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1904 IANA Considerations Section in RFCs", RFC 5226, 1905 DOI 10.17487/RFC5226, May 2008, 1906 . 1908 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1909 Housley, R., and W. Polk, "Internet X.509 Public Key 1910 Infrastructure Certificate and Certificate Revocation List 1911 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1912 . 1914 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1915 Keranen, A., and P. Hallam-Baker, "Naming Things with 1916 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1917 . 1919 [RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., 1920 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1921 "Information-Centric Networking (ICN) Research 1922 Challenges", 2016, 1923 . 1925 [RFC7945] Pentikousis, K., Ohlman, B., Davies, E., Spirou, S., and 1926 G. Boggia, "Information-Centric Networking: Evaluation and 1927 Security Considerations", 2016, 1928 . 1930 Authors' Addresses 1932 Marc Mosko 1933 PARC, Inc. 1934 Palo Alto, California 94304 1935 USA 1937 Phone: +01 650-812-4405 1938 Email: marc.mosko@parc.com 1940 Ignacio Solis 1941 LinkedIn 1942 Mountain View, California 94043 1943 USA 1945 Email: nsolis@linkedin.com 1947 Christopher A. Wood 1948 University of California Irvine 1949 Irvine, California 92697 1950 USA 1952 Phone: +01 315-806-5939 1953 Email: woodc1@uci.edu