idnits 2.17.1 draft-irtf-icnrg-ccnxmessages-09.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 (January 24, 2019) is 1919 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 512 -- Looks like a reference, but probably isn't: '1' on line 512 -- Looks like a reference, but probably isn't: '2' on line 512 == Missing Reference: 'KeyIdRestr' is mentioned on line 571, but not defined == Missing Reference: 'ContentObjectHashRestr' is mentioned on line 571, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 4 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: July 28, 2019 LinkedIn 6 C. Wood 7 University of California Irvine 8 January 24, 2019 10 CCNx Messages in TLV Format 11 draft-irtf-icnrg-ccnxmessages-09 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 http://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 July 28, 2019. 40 Copyright Notice 42 Copyright (c) 2019 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 (http://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 . . . . . . . . . . . . . . . . 9 65 3.2.2. Content Object Fixed Header . . . . . . . . . . . . . 9 66 3.2.3. InterestReturn Fixed Header . . . . . . . . . . . . . 9 67 3.2.3.1. InterestReturn HopLimit . . . . . . . . . . . . . 10 68 3.2.3.2. InterestReturn Flags . . . . . . . . . . . . . . 10 69 3.2.3.3. Return Code . . . . . . . . . . . . . . . . . . . 10 70 3.3. Global Formats . . . . . . . . . . . . . . . . . . . . . 10 71 3.3.1. Pad . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.3.2. Organization Specific TLVs . . . . . . . . . . . . . 11 73 3.3.3. Hash Format . . . . . . . . . . . . . . . . . . . . . 11 74 3.3.4. Link . . . . . . . . . . . . . . . . . . . . . . . . 13 75 3.4. Hop-by-hop TLV headers . . . . . . . . . . . . . . . . . 13 76 3.4.1. Interest Lifetime . . . . . . . . . . . . . . . . . . 14 77 3.4.2. Recommended Cache Time . . . . . . . . . . . . . . . 14 78 3.4.3. Message Hash . . . . . . . . . . . . . . . . . . . . 15 79 3.5. Top-Level Types . . . . . . . . . . . . . . . . . . . . . 16 80 3.6. CCNx Message . . . . . . . . . . . . . . . . . . . . . . 16 81 3.6.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 17 82 3.6.1.1. Name Segments . . . . . . . . . . . . . . . . . . 18 83 3.6.1.2. Interest Payload ID . . . . . . . . . . . . . . . 19 84 3.6.2. Message TLVs . . . . . . . . . . . . . . . . . . . . 20 85 3.6.2.1. Interest Message TLVs . . . . . . . . . . . . . . 20 86 3.6.2.2. Content Object Message TLVs . . . . . . . . . . . 21 87 3.6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 23 88 3.6.4. Validation . . . . . . . . . . . . . . . . . . . . . 23 89 3.6.4.1. Validation Algorithm . . . . . . . . . . . . . . 23 90 3.6.4.2. Validation Payload . . . . . . . . . . . . . . . 29 91 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 92 4.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 30 93 4.2. Interest Return Code Registry . . . . . . . . . . . . . . 30 94 4.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 31 95 4.4. Top-Level Type Registry . . . . . . . . . . . . . . . . . 32 96 4.5. Name Segment Type Registry . . . . . . . . . . . . . . . 33 97 4.6. Message Type Registry . . . . . . . . . . . . . . . . . . 34 98 4.7. Payload Type Registry . . . . . . . . . . . . . . . . . . 35 99 4.8. Validation Algorithm Type Registry . . . . . . . . . . . 36 100 4.9. Validation Dependent Data Type Registry . . . . . . . . . 37 101 4.10. Hash Function Type Registry . . . . . . . . . . . . . . . 39 102 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 103 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 104 6.1. Normative References . . . . . . . . . . . . . . . . . . 43 105 6.2. Informative References . . . . . . . . . . . . . . . . . 43 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 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 avoids multiple encodings of the 126 same value (aliases) and reduces the work of a validator to ensure 127 compliance. Unlike some uses of TLV in networking, the each network 128 hop must evaluate the encoding, so even small validation latencies at 129 each hop could add up to a large overall forwarding delay. For very 130 small packets or low throughput links, where the extra bytes may 131 become a concern, one may use a TLV compression protocol, for example 132 [compress] and [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. For example, each 161 level of a nested TLV structure might define a "type = 1" with a 162 completely different meaning. In the following, we use the symbolic 163 names defined in that section. 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 are 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 attributes 200 that matches the Name and optional selectors of the Interest is 201 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 at each level of TLV 212 encoding, there should be sufficient space for basic protocol types, 213 while also allowing ample room for experimentation, application use, 214 vendor extensions, and growth. This encoding does not allow for 215 jumbo packets beyond 64 KiB total length. If used on a media that 216 allows for jumbo frames, we suggest defining a media adapation 217 envelope that allows for multiple smaller frames. 219 There are several global TLV definitions that we reserve at all 220 hierarchical contexts. The TLV types in the range 0x1000 - 0x1FFF 221 are reserved for experimental use. The TLV type T_ORG is also 222 reserved for vendor extensions ( see Section 3.3.2). The TLV type 223 T_PAD is used to optionally pad a field out to some desired 224 alignment. 226 +--------+-------------------------+--------------------------------+ 227 | Abbrev | Name | Description | 228 +--------+-------------------------+--------------------------------+ 229 | T_ORG | Vendor Specific | Information specific to a | 230 | | Information (Section | vendor implementation (see | 231 | | 3.3.2) | below). | 232 | | | | 233 | T_PAD | Padding (Section 3.3.1) | Adds padding to a field (see | 234 | | | below). | 235 | | | | 236 | n/a | Experimental | Experimental use. | 237 +--------+-------------------------+--------------------------------+ 239 Table 1: Reserved TLV Types 240 1 2 241 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 242 +---------------+---------------+---------------+---------------+ 243 | Type | Length | 244 +---------------+---------------+---------------+---------------+ 246 The Length field contains the length of the Value field in octets. 247 It does not include the length of the Type and Length fields. The 248 length MAY be zero. 250 TLV structures are nestable, allowing the Value field of one TLV 251 structure to contain additional TLV structures. The enclosing TLV 252 structure is called the container of the enclosed TLV. 254 Type values are context-dependent. Within a TLV container, one may 255 re-use previous type values for new context-dependent purposes. 257 3.1. Overall packet format 259 Each packet includes the 8 byte fixed header, described below, 260 followed by a set of TLV fields. These fields are optional hop-by- 261 hop headers and the Packet Payload. 263 1 2 3 264 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 265 +---------------+---------------+---------------+---------------+ 266 | Version | PacketType | PacketLength | 267 +---------------+---------------+---------------+---------------+ 268 | PacketType specific fields | HeaderLength | 269 +---------------+---------------+---------------+---------------+ 270 / Optional Hop-by-hop header TLVs / 271 +---------------+---------------+---------------+---------------+ 272 / PacketPayload TLVs / 273 +---------------+---------------+---------------+---------------+ 275 The packet payload is a TLV encoding of the CCNx message, followed by 276 optional Validation TLVs. 278 1 2 3 279 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 280 +---------------+---------------+---------------+---------------+ 281 | CCNx Message TLV / 282 +---------------+---------------+---------------+---------------+ 283 / Optional CCNx ValidationAlgorithm TLV / 284 +---------------+---------------+---------------+---------------+ 285 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 286 +---------------+---------------+---------------+---------------+ 287 This document describes the Version "1" TLV encoding. 289 After discarding the fixed and hop-by-hop headers the remaining 290 PacketPayload should be a valid protocol message. Therefore, the 291 PacketPayload always begins with 4 bytes of type-length that 292 specifies the protocol message (whether it is an Interest, Content 293 Object, or other message type) and its total length. The embedding 294 of a self-sufficient protocol data unit inside the fixed and hop-by- 295 hop headers allows a network stack to discard the headers and operate 296 only on the embedded message. It also de-couples the PacketType 297 field -- which specifies how to forward the packet -- from the 298 PacketPayload. 300 The range of bytes protected by the Validation includes the CCNx 301 Message and the ValidationAlgorithm. 303 The ContentObjectHash begins with the CCNx Message and ends at the 304 tail of the packet. 306 3.2. Fixed Headers 308 CCNx messages begin with an 8 byte fixed header (non-TLV format). 309 The HeaderLength field represents the combined length of the Fixed 310 and Hop-by-hop headers. The PacketLength field represents the entire 311 Packet length from the first byte of Version to the last byte of the 312 packet. 314 A specific PacketType may assign meaning to the "PacketType specific 315 fields," which are otherwise reserved. For the three defined 316 PacketTypes (Interest, ContentObject, and InterestReturn), we define 317 those values in this document. 319 The PacketPayload of a CCNx packet is the protocol message itself. 320 The Content Object Hash is computed over the PacketPayload only, 321 excluding the fixed and hop-by-hop headers as those might change from 322 hop to hop. Signed information or Similarity Hashes should not 323 include any of the fixed or hop-by-hop headers. The PacketPayload 324 should be self-sufficient in the event that the fixed and hop-by-hop 325 headers are removed. 327 1 2 3 328 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 329 +---------------+---------------+---------------+---------------+ 330 | Version | PacketType | PacketLength | 331 +---------------+---------------+---------------+---------------+ 332 | PacketType specific fields | HeaderLength | 333 +---------------+---------------+---------------+---------------+ 334 o Version: defines the version of the packet. 336 o HeaderLength: The length of the fixed header (8 bytes) and hop-by- 337 hop headers. The minimum value MUST be "8". 339 o PacketType: describes forwarder actions to take on the packet. 341 o PacketLength: Total octets of packet including all headers (fixed 342 header plus hop-by-hop headers) and protocol message. 344 o PacketType Specific Fields: specific PacketTypes define the use of 345 these bits. 347 The PacketType field indicates how the forwarder should process the 348 packet. A Request Packet (Interest) has PacketType PT_INTEREST, a 349 Response (Content Object) has PacketType PT_CONTENT, and an 350 InterestReturn has PacketType PT_RETURN. 352 HeaderLength is the number of octets from the start of the packet 353 (Version) to the end of the hop-by-hop headers. PacketLength is the 354 number of octets from the start of the packet to the end of the 355 packet. Both lengths have a minimum value of 8 (the fixed header 356 itself). 358 The PacketType specific fields are reserved bits whose use depends on 359 the PacketType. They are used for network-level signaling. 361 3.2.1. Interest Fixed Header 363 If the PacketType is PT_INTEREST, it indicates that the PacketPayload 364 should be processed as an Interest message. For this type of packet, 365 the Fixed Header includes a field for a HopLimit as well as Reserved 366 and Flags fields. The Reserved field MUST be set to 0 in an Interest 367 - this field will be set to a return code in the case of an Interest 368 Return. There are currently no Flags defined, so this field MUST be 369 set to 0. 371 1 2 3 372 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 373 +---------------+---------------+---------------+---------------+ 374 | Version | PT_INTEREST | PacketLength | 375 +---------------+---------------+---------------+---------------+ 376 | HopLimit | Reserved | Flags | HeaderLength | 377 +---------------+---------------+---------------+---------------+ 379 3.2.1.1. Interest HopLimit 381 For an Interest message, the HopLimit is a counter that is 382 decremented with each hop. It limits the distance an Interest may 383 travel on the network. The node originating the Interest MAY put in 384 any value - up to the maximum of 255. Each node that receives an 385 Interest with a HopLimit decrements the value upon reception. If the 386 value is 0 after the decrement, the Interest MUST NOT be forwarded 387 off the node. 389 It is an error to receive an Interest with a 0 hop-limit from a 390 remote node. 392 3.2.2. Content Object Fixed Header 394 If the PacketType is PT_CONTENT, it indicates that the PacketPayload 395 should be processed as a Content Object message. A Content Object 396 defines a Flags field, however there are currently no flags defined, 397 so the Flags field must be set to 0. 399 1 2 3 400 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 401 +---------------+---------------+---------------+---------------+ 402 | Version | PT_CONTENT | PacketLength | 403 +---------------+---------------+---------------+---------------+ 404 | Reserved | Flags | HeaderLength | 405 +---------------+---------------+---------------+---------------+ 407 3.2.3. InterestReturn Fixed Header 409 If the PacketType is PT_RETURN, it indicates that the PacketPayload 410 should be processed as a returned Interest message. The only 411 difference between this InterestReturn message and the original 412 Interest is that the PacketType is changed to PT_RETURN and a 413 ReturnCode is is put into the ReturnCode field. All other fields are 414 unchanged from the Interest packet. The purpose of this encoding is 415 to prevent packet length changes so no additional bytes are needed to 416 return an Interest to the previous hop. See [CCNSemantics] for a 417 protocol description of this packet type. 419 1 2 3 420 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 421 +---------------+---------------+---------------+---------------+ 422 | Version | PT_RETURN | PacketLength | 423 +---------------+---------------+---------------+---------------+ 424 | HopLimit | ReturnCode | Flags | HeaderLength | 425 +---------------+---------------+---------------+---------------+ 427 3.2.3.1. InterestReturn HopLimit 429 This is the original Interest's HopLimit, as received. It is the 430 value before being decremented at the current node (i.e. the received 431 value). 433 3.2.3.2. InterestReturn Flags 435 These are the original Flags as set in the Interest. 437 3.2.3.3. Return Code 439 The numeric value assigned to the return types is defined below. 440 This value is set by the node creating the Interest Return. 442 A return code of "0" MUST NOT be used, as it indicates that the 443 returning system did not modify the Return Code field. 445 +-------------------------------------+-----------------------------+ 446 | Type | Return Type | 447 +-------------------------------------+-----------------------------+ 448 | T_RETURN_NO_ROUTE | No Route | 449 | | | 450 | T_RETURN_LIMIT_EXCEEDED | Hop Limit Exceeded | 451 | | | 452 | T_RETURN_NO_RESOURCES | No Resources | 453 | | | 454 | T_RETURN_PATH_ERROR | Path Error | 455 | | | 456 | T_RETURN_PROHIBITED | Prohibited | 457 | | | 458 | T_RETURN_CONGESTED | Congested | 459 | | | 460 | T_RETURN_MTU_TOO_LARGE | MTU too large | 461 | | | 462 | T_RETURN_UNSUPPORTED_HASH_RESTRICTI | Unsupported ContentObjectHa | 463 | ON | shRestriction | 464 | | | 465 | T_RETURN_MALFORMED_INTEREST | Malformed Interest | 466 +-------------------------------------+-----------------------------+ 468 Table 2: Return Codes 470 3.3. Global Formats 472 This section defines global formats that may be nested within other 473 TLVs. 475 3.3.1. Pad 477 The pad type may be used by protocols that prefer word-aligned data. 478 The size of the word may be defined by the protocol. Padding 4-byte 479 words, for example, would use a 1-byte, 2-byte, and 3-byte Length. 480 Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, 7)-byte Length. 482 One MUST NOT pad inside a Name. Apart from that, a pad MAY be 483 inserted after any other TLV in the CCNx Message or in the Validation 484 Dependent Data In the remainder of this document, we will not show 485 optional pad TLVs. 487 1 2 3 488 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 489 +---------------+---------------+---------------+---------------+ 490 | T_PAD | Length | 491 +---------------+---------------+---------------+---------------+ 492 / variable length pad MUST be zeros / 493 +---------------+---------------+---------------+---------------+ 495 3.3.2. Organization Specific TLVs 497 Organization specific TLVs (also known as Vendor TLVs) MUST use the 498 T_ORG type. The Length field is the length of the organization 499 specific information plus 3. The Value begins with the 3 byte 500 organization number derived from the last three digits of the IANA 501 Private Enterprise Numbers [EpriseNumbers], followed by the 502 organization specific information. 504 A T_ORG MAY be used as a path segment in a Name, in which case it is 505 a regular path segment and is part of the regular name matching. 507 1 2 3 508 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 509 +---------------+---------------+---------------+---------------+ 510 | T_ORG | Length (3+value length) | 511 +---------------+---------------+---------------+---------------+ 512 | PEN[0] | PEN[1] | PEN[2] | / 513 +---------------+---------------+---------------+ + 514 / Vendor Specific Value / 515 +---------------+---------------+---------------+---------------+ 517 3.3.3. Hash Format 519 Hash values are used in several fields throughout a packet. This TLV 520 encoding is commonly embedded inside those fields to specify the 521 specific hash function used and it's value. Note that the reserved 522 TLV types are also reserved here for user-defined experimental 523 functions. 525 The LENGTH field of the hash value MUST be less than or equal to the 526 hash function length. If the LENGTH is less than the full length, it 527 is taken as the left LENGTH bytes of the hash function output. Only 528 specified truncations are allowed, not arbitrary truncations. 530 This nested format is used because it allows binary comparison of 531 hash values for certain fields without a router needing to understand 532 a new hash function. For example, the KeyIdRestriction is bit-wise 533 compared between an Interest's KeyIdRestriction field and a 534 ContentObject's KeyId field. This format means the outer field 535 values do not change with differing hash functions so a router can 536 still identify those fields and do a binary comparison of the hash 537 TLV without need to understand the specific hash used. An 538 alternative approach, such as using T_KEYID_SHA512-256, would require 539 each router keep an up-to-date parser and supporting user-defined 540 hash functions here would explode the parsing state-space. 542 A CCNx entity MUST support the hash type T_SHA-256. An entity MAY 543 support the remaining hash types. 545 +-----------+------------------------+ 546 | Abbrev | Lengths (octets) | 547 +-----------+------------------------+ 548 | T_SHA-256 | 32 | 549 | | | 550 | T_SHA-512 | 64, 32 | 551 | | | 552 | n/a | Experimental TLV types | 553 +-----------+------------------------+ 555 Table 3: CCNx Hash Functions 557 1 2 3 558 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 559 +---------------+---------------+---------------+---------------+ 560 | T_FOO | 36 | 561 +---------------+---------------+---------------+---------------+ 562 | T_SHA512 | 32 | 563 +---------------+---------------+---------------+---------------+ 564 / 32-byte hash value / 565 +---------------+---------------+---------------+---------------+ 567 Example nesting inside type T_FOO 569 3.3.4. Link 571 A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}. 572 It is a general encoding that is used in both the payload of a 573 Content Object with PayloadType = "Link" and in the KeyLink field in 574 a KeyLocator. A Link is essentially the body of an Interest. 576 1 2 3 577 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 578 +---------------+---------------+-------------------------------+ 579 / Mandatory CCNx Name / 580 +---------------+---------------+-------------------------------+ 581 / Optional KeyIdRestriction / 582 +---------------------------------------------------------------+ 583 / Optional ContentObjectHashRestriction / 584 +---------------------------------------------------------------+ 586 3.4. Hop-by-hop TLV headers 588 Hop-by-hop TLV headers are unordered and meaning MUST NOT be attached 589 to their ordering. Three hop-by-hop headers are described in this 590 document: 592 +-------------+-------------------+---------------------------------+ 593 | Abbrev | Name | Description | 594 +-------------+-------------------+---------------------------------+ 595 | T_INTLIFE | Interest Lifetime | The time an Interest should | 596 | | (Section 3.4.1) | stay pending at an intermediate | 597 | | | node. | 598 | | | | 599 | T_CACHETIME | Recommended Cache | The Recommended Cache Time for | 600 | | Time (Section | Content Objects. | 601 | | 3.4.2) | | 602 | | | | 603 | T_MSGHASH | Message Hash | The hash of the CCNx Message to | 604 | | (Section 3.4.3) | end of packet using Section | 605 | | | 3.3.3 format. | 606 +-------------+-------------------+---------------------------------+ 608 Table 4: Hop-by-hop Header Types 610 Additional hop-by-hop headers are defined in higher level 611 specifications such as the fragmentation specification. 613 3.4.1. Interest Lifetime 615 The Interest Lifetime is the time that an Interest should stay 616 pending at an intermediate node. It is expressed in milliseconds as 617 an unsigned, network byte order integer. 619 A value of 0 (encoded as 1 byte %x00) indicates the Interest does not 620 elicit a Content Object response. It should still be forwarded, but 621 no reply is expected and a forwarder could skip creating a PIT entry. 623 1 2 3 624 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 625 +---------------+---------------+---------------+---------------+ 626 | T_INTLIFE | Length | 627 +---------------+---------------+---------------+---------------+ 628 / / 629 / Lifetime (length octets) / 630 / / 631 +---------------+---------------+---------------+---------------+ 633 3.4.2. Recommended Cache Time 635 The Recommended Cache Time (RCT) is a measure of the useful lifetime 636 of a Content Object as assigned by a content producer or upstream 637 node. It serves as a guideline to the Content Store cache in 638 determining how long to keep the Content Object. It is a 639 recommendation only and may be ignored by the cache. This is in 640 contrast to the ExpiryTime (described in Section 3.6.2.2.2) which 641 takes precedence over the RCT and must be obeyed. 643 Because the Recommended Cache Time is an optional hop-by-hop header 644 and not a part of the signed message, a content producer may re-issue 645 a previously signed Content Object with an updated RCT without 646 needing to re-sign the message. There is little ill effect from an 647 attacker changing the RCT as the RCT serves as a guideline only. 649 The Recommended Cache Time (a millisecond timestamp) is a network 650 byte ordered unsigned integer of the number of milliseconds since the 651 epoch in UTC of when the payload expires. It is a 64-bit field. 653 1 2 3 654 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 655 +---------------+---------------+---------------+---------------+ 656 | T_CACHETIME | 8 | 657 +---------------+---------------+---------------+---------------+ 658 / / 659 / Recommended Cache Time / 660 / / 661 +---------------+---------------+---------------+---------------+ 663 3.4.3. Message Hash 665 Within a trusted domain, an operator may calculate the message hash 666 at a border device and insert that value into the hop-by-hop headers 667 of a message. An egress device should remove the value. This 668 permits intermediate devices within that trusted domain to match 669 against a ContentObjectHashRestriction without calculating it at 670 every hop. 672 The message hash is a cryptographic hash from the start of the CCNx 673 Message to the end of the packet. It is used to match against the 674 ContentObjectHashRestriction (Section 3.6.2.1.2). The Message Hash 675 may be of longer length than an Interest's restriction, in which case 676 the device should use the left bytes of the Message Hash to check 677 against the Interest's value. 679 The Message Hash may only carry one hash type and there may only be 680 one Message Hash header. 682 The Message Hash header is unprotected, so this header is only of 683 practical use within a trusted domain, such as an operator's 684 autonomous system. 686 1 2 3 687 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 688 +---------------+---------------+---------------+---------------+ 689 | T_MSGHASH | (length + 4) | 690 +---------------+---------------+---------------+---------------+ 691 | (hash type) | length | 692 +---------------+---------------+---------------+---------------+ 693 / hash value / 694 +---------------+---------------+---------------+---------------+ 696 Message Hash Header 698 3.5. Top-Level Types 700 The top-level TLV types listed below exist at the outermost level of 701 a CCNx protocol message. 703 +----------------------+-------------------+------------------------+ 704 | Abbrev | Name | Description | 705 +----------------------+-------------------+------------------------+ 706 | T_INTEREST | Interest (Section | An Interest | 707 | | 3.6) | MessageType. | 708 | | | | 709 | T_OBJECT | Content Object | A Content Object | 710 | | (Section 3.6) | MessageType | 711 | | | | 712 | T_VALIDATION_ALG | Validation | The method of message | 713 | | Algorithm | verification such as | 714 | | (Section 3.6.4.1) | Message Integrity | 715 | | | Check (MIC), a Message | 716 | | | Authentication Code | 717 | | | (MAC), or a | 718 | | | cryptographic | 719 | | | signature. | 720 | | | | 721 | T_VALIDATION_PAYLOAD | Validation | The validation output, | 722 | | Payload (Section | such as the CRC32C | 723 | | 3.6.4.2) | code or the RSA | 724 | | | signature. | 725 +----------------------+-------------------+------------------------+ 727 Table 5: CCNx Top Level Types 729 3.6. CCNx Message 731 This is the format for the CCNx protocol message itself. The CCNx 732 message is the portion of the packet between the hop-by-hop headers 733 and the Validation TLVs. The figure below is an expansion of the 734 "CCNx Message TLV" depicted in the beginning of Section 3. The CCNx 735 message begins with MessageType and runs through the optional 736 Payload. The same general format is used for both Interest and 737 Content Object messages which are differentiated by the MessageType 738 field. The first enclosed TLV of a CCNx Message is always the Name 739 TLV. This is followed by an optional Message TLVs and an optional 740 Payload TLV. 742 1 2 3 743 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 744 +---------------+---------------+---------------+---------------+ 745 | MessageType | MessageLength | 746 +---------------+---------------+---------------+---------------+ 747 | Name TLV (Type = T_NAME) | 748 +---------------+---------------+---------------+---------------+ 749 / Optional Message TLVs (Various Types) / 750 +---------------+---------------+---------------+---------------+ 751 / Optional Payload TLV (Type = T_PAYLOAD) / 752 +---------------+---------------+---------------+---------------+ 754 +-----------+-----------------+-------------------------------------+ 755 | Abbrev | Name | Description | 756 +-----------+-----------------+-------------------------------------+ 757 | T_NAME | Name (Section | The CCNx Name requested in an | 758 | | 3.6.1) | Interest or published in a Content | 759 | | | Object. | 760 | | | | 761 | T_PAYLOAD | Payload | The message payload. | 762 | | (Section 3.6.3) | | 763 +-----------+-----------------+-------------------------------------+ 765 Table 6: CCNx Message Types 767 3.6.1. Name 769 A Name is a TLV encoded sequence of segments. The table below lists 770 the type values appropriate for these Name segments. A Name MUST NOT 771 include PAD TLVs. 773 As described in CCNx Semantics [CCNSemantics], using the CCNx URI 774 [CCNxURI] notation, a T_NAME with 0 length corresponds to ccnx:/ (the 775 default route) and is distinct from a name with one zero length 776 segment, such as ccnx:/NAME=. In the TLV encoding, ccnx:/ 777 corresponds to T_NAME with 0 length, while ccnx:/NAME= corresponds to 778 T_NAME with 4 length and T_NAMESEGMENT with 0 length. 780 1 2 3 781 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 782 +---------------+---------------+---------------+---------------+ 783 | T_NAME | Length | 784 +---------------+---------------+---------------+---------------+ 785 / Name segment TLVs / 786 +---------------+---------------+---------------+---------------+ 787 +---------------+-------------------+-------------------------------+ 788 | Symbolic Name | Name | Description | 789 +---------------+-------------------+-------------------------------+ 790 | T_NAMESEGMENT | Name segment | A generic name Segment. | 791 | | (Section 3.6.1.1) | | 792 | | | | 793 | T_IPID | Interest Payload | An identifier that represents | 794 | | ID (Section | the Interest Payload field. | 795 | | 3.6.1.2) | As an example, the Payload ID | 796 | | | might be a hash of the | 797 | | | Interest Payload. This | 798 | | | provides a way to | 799 | | | differentiate between | 800 | | | Interests based on their | 801 | | | payloads without having to | 802 | | | parse all the bytes of the | 803 | | | payload itself; instead using | 804 | | | only this Payload ID Name | 805 | | | segment. | 806 | | | | 807 | T_APP:00 - | Application | Application-specific payload | 808 | T_APP:4096 | Components | in a name segment. An | 809 | | (Section 3.6.1.1) | application may apply its own | 810 | | | semantics to the 4096 | 811 | | | reserved types. | 812 +---------------+-------------------+-------------------------------+ 814 Table 7: CCNx Name Types 816 3.6.1.1. Name Segments 818 4096 special application payload name segments are allocated. These 819 have application semantics applied to them. A good convention is to 820 put the application's identity in the name prior to using these name 821 segments. 823 For example, a name like "ccnx:/foo/bar/hi" would be encoded as: 825 1 2 3 826 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 827 +---------------+---------------+---------------+---------------+ 828 | (T_NAME) | %x14 (20) | 829 +---------------+---------------+---------------+---------------+ 830 | (T_NAME_SEGMENT) | %x03 (3) | 831 +---------------+---------------+---------------+---------------+ 832 | f o o |(T_NAME_SEGMENT) 833 +---------------+---------------+---------------+---------------+ 834 | | %x03 (3) | b | 835 +---------------+---------------+---------------+---------------+ 836 | a r | (T_NAME_SEGMENT) | 837 +---------------+---------------+---------------+---------------+ 838 | %x02 (2) | h | i | 839 +---------------+---------------+---------------+---------------+ 841 3.6.1.2. Interest Payload ID 843 The InterestPayloadID is a name segment created by the origin of an 844 Interest to represent the Interest Payload. This allows the proper 845 multiplexing of Interests based on their name if they have different 846 payloads. A common representation is to use a hash of the Interest 847 Payload as the InterestPayloadID. 849 As part of the TLV 'value', the InterestPayloadID contains a one 850 identifier of method used to create the InterestPayloadID followed by 851 a variable length octet string. An implementation is not required to 852 implement any of the methods to receive an Interest; the 853 InterestPayloadID may be treated only as an opaque octet string for 854 purposes of multiplexing Interests with different payloads. Only a 855 device creating an InterestPayloadID name segment or a device 856 verifying such a segment need to implement the algorithms. 858 It uses the Section 3.3.3 encoding of hash values. 860 In normal operations, we recommend displaying the InterestPayloadID 861 as an opaque octet string in a CCNx URI, as this is the common 862 denominator for implementation parsing. 864 The InterestPayloadID, even if it is a hash, should not convey any 865 security context. If a system requires confirmation that a specific 866 entity created the InterestPayload, it should use a cryptographic 867 signature on the Interest via the ValidationAlgorithm and 868 ValidationPayload or use its own methods inside the Interest Payload. 870 3.6.2. Message TLVs 872 Each message type (Interest or Content Object) is associated with a 873 set of optional Message TLVs. Additional specification documents may 874 extend the types associated with each. 876 3.6.2.1. Interest Message TLVs 878 There are two Message TLVs currently associated with an Interest 879 message: the KeyIdRestriction selector and the ContentObjectHashRestr 880 selector are used to narrow the universe of acceptable Content 881 Objects that would satisfy the Interest. 883 1 2 3 884 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 885 +---------------+---------------+---------------+---------------+ 886 | MessageType | MessageLength | 887 +---------------+---------------+---------------+---------------+ 888 | Name TLV | 889 +---------------+---------------+---------------+---------------+ 890 / Optional KeyIdRestriction TLV / 891 +---------------------------------------------------------------+ 892 / Optional ContentObjectHashRestriction TLV / 893 +---------------------------------------------------------------+ 895 +----------------+------------------------------+-------------------+ 896 | Abbrev | Name | Description | 897 +----------------+------------------------------+-------------------+ 898 | T_KEYIDRESTR | KeyIdRestriction (Section | A Section 3.3.3 | 899 | | 3.6.2.1.1) | representation of | 900 | | | the KeyId | 901 | | | | 902 | T_OBJHASHRESTR | ContentObjectHashRestriction | A Section 3.3.3 | 903 | | (Section 3.6.2.1.2) | representation of | 904 | | | the hash of the | 905 | | | specific Content | 906 | | | Object that would | 907 | | | satisfy the | 908 | | | Interest. | 909 +----------------+------------------------------+-------------------+ 911 Table 8: CCNx Interest Message TLV Types 913 3.6.2.1.1. KeyIdRestriction 915 An Interest MAY include a KeyIdRestriction selector. This ensures 916 that only Content Objects with matching KeyIds will satisfy the 917 Interest. See Section 3.6.4.1.4.1 for the format of a KeyId. 919 3.6.2.1.2. ContentObjectHashRestriction 921 An Interest MAY contain a ContentObjectHashRestriction selector. 922 This is the hash of the Content Object - the self-certifying name 923 restriction that must be verified in the network, if an Interest 924 carried this restriction. It is calculated from the beginning of the 925 CCNx Message to the end of the packet. The LENGTH MUST be from one 926 of the allowed values for that hash (see Section 3.3.3). 928 The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of 929 length 32 bytes. 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 | T_OBJHASHRESTR | LENGTH+4 | 935 +---------------+---------------+---------------+---------------+ 936 | | LENGTH | 937 +---------------+---------------+---------------+---------------+ 938 / LENGTH octets of hash / 939 +---------------+---------------+---------------+---------------+ 941 3.6.2.2. Content Object Message TLVs 943 The following message TLVs are currently defined for Content Objects: 944 PayloadType (optional) and ExpiryTime (optional). 946 1 2 3 947 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 948 +---------------+---------------+---------------+---------------+ 949 | MessageType | MessageLength | 950 +---------------+---------------+---------------+---------------+ 951 | Name TLV | 952 +---------------+---------------+---------------+---------------+ 953 / Optional PayloadType TLV / 954 +---------------------------------------------------------------+ 955 / Optional ExpiryTime TLV / 956 +---------------------------------------------------------------+ 957 +-------------+---------------------+-------------------------------+ 958 | Abbrev | Name | Description | 959 +-------------+---------------------+-------------------------------+ 960 | T_PAYLDTYPE | PayloadType | Indicates the type of Payload | 961 | | (Section 3.6.2.2.1) | contents. | 962 | | | | 963 | T_EXPIRY | ExpiryTime (Section | The time at which the Payload | 964 | | 3.6.2.2.2) | expires, as expressed in the | 965 | | | number of milliseconds since | 966 | | | the epoch in UTC. If | 967 | | | missing, Content Object may | 968 | | | be used as long as desired. | 969 +-------------+---------------------+-------------------------------+ 971 Table 9: CCNx Content Object Message TLV Types 973 3.6.2.2.1. PayloadType 975 The PayloadType is a network byte order integer representing the 976 general type of the Payload TLV. 978 o T_PAYLOADTYPE_DATA: Data (possibly encrypted) 980 o T_PAYLOADTYPE_KEY: Key 982 o T_PAYLOADTYPE_LINK: Link 984 The Data type indicate that the Payload of the ContentObject is 985 opaque application bytes. The Key type indicates that the Payload is 986 a DER encoded public key. The Link type indicates that the Payload 987 is one or more Link (Section 3.3.4). If this field is missing, a 988 "Data" type is assumed. 990 1 2 3 991 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 992 +---------------+---------------+---------------+---------------+ 993 | T_PAYLDTYPE | Length | 994 +---------------+---------------+---------------+---------------+ 995 | PayloadType / 996 +---------------+ 998 3.6.2.2.2. ExpiryTime 1000 The ExpiryTime is the time at which the Payload expires, as expressed 1001 by a timestamp containing the number of milliseconds since the epoch 1002 in UTC. It is a network byte order unsigned integer in a 64-bit 1003 field. A cache or end system should not respond with a Content 1004 Object past its ExpiryTime. Routers forwarding a Content Object do 1005 not need to check the ExpiryTime. If the ExpiryTime field is 1006 missing, the Content Object has no expressed expiration and a cache 1007 or end system may use the Content Object for as long as desired. 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_EXPIRY | 8 | 1013 +---------------+---------------+---------------+---------------+ 1014 / ExpiryTime / 1015 / / 1016 +---------------+---------------+---------------+---------------+ 1018 3.6.3. Payload 1020 The Payload TLV contains the content of the packet. It MAY be of 1021 zero length. If a packet does not have any payload, this field MAY 1022 be omitted, rather than carrying a zero length. 1024 1 2 3 1025 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 1026 +---------------+---------------+---------------+---------------+ 1027 | T_PAYLOAD | Length | 1028 +---------------+---------------+---------------+---------------+ 1029 / Payload Contents / 1030 +---------------+---------------+---------------+---------------+ 1032 3.6.4. Validation 1034 Both Interests and Content Objects have the option to include 1035 information about how to validate the CCNx message. This information 1036 is contained in two TLVs: the ValidationAlgorithm TLV and the 1037 ValidationPayload TLV. The ValidationAlgorithm TLV specifies the 1038 mechanism to be used to verify the CCNx message. Examples include 1039 verification with a Message Integrity Check (MIC), a Message 1040 Authentication Code (MAC), or a cryptographic signature. The 1041 ValidationPayload TLV contains the validation output, such as the 1042 CRC32C code or the RSA signature. 1044 An Interest would most likely only use a MIC type of validation - a 1045 crc, checksum, or digest. 1047 3.6.4.1. Validation Algorithm 1049 The ValidationAlgorithm is a set of nested TLVs containing all of the 1050 information needed to verify the message. The outermost container 1051 has type = T_VALIDATION_ALG. The first nested TLV defines the 1052 specific type of validation to be performed on the message. The type 1053 is identified with the "ValidationType" as shown in the figure below 1054 and elaborated in the table below. Nested within that container are 1055 the TLVs for any ValidationType dependent data, for example a Key Id, 1056 Key Locator etc. 1058 Complete examples of several types may be found in Section 3.6.4.1.5 1060 1 2 3 1061 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 1062 +---------------+---------------+---------------+---------------+ 1063 | T_VALIDATION_ALG | ValidationAlgLength | 1064 +---------------+---------------+---------------+---------------+ 1065 | ValidationType | Length | 1066 +---------------+---------------+---------------+---------------+ 1067 / ValidationType dependent data / 1068 +---------------+---------------+---------------+---------------+ 1070 +---------------+---------------------+-----------------------------+ 1071 | Abbrev | Name | Description | 1072 +---------------+---------------------+-----------------------------+ 1073 | T_CRC32C | CRC32C (Section | Castagnoli CRC32 (iSCSI, | 1074 | | 3.6.4.1.1) | ext4, etc.), with normal | 1075 | | | form polynomial 0x1EDC6F41. | 1076 | | | | 1077 | T_HMAC-SHA256 | HMAC-SHA256 | HMAC (RFC 2104) using | 1078 | | (Section 3.6.4.1.2) | SHA256 hash. | 1079 | | | | 1080 | T_RSA-SHA256 | RSA-SHA256 (Section | RSA public key signature | 1081 | | 3.6.4.1.3) | using SHA256 digest. | 1082 | | | | 1083 | EC-SECP-256K1 | SECP-256K1 (Section | Elliptic Curve signature | 1084 | | 3.6.4.1.3) | with SECP-256K1 parameters | 1085 | | | (see [ECC]). | 1086 | | | | 1087 | EC-SECP-384R1 | SECP-384R1 (Section | Elliptic Curve signature | 1088 | | 3.6.4.1.3) | with SECP-384R1 parameters | 1089 | | | (see [ECC]). | 1090 +---------------+---------------------+-----------------------------+ 1092 Table 10: CCNx Validation Types 1094 3.6.4.1.1. Message Integrity Checks 1096 MICs do not require additional data in order to perform the 1097 verification. An example is CRC32C that has a "0" length value. 1099 3.6.4.1.2. Message Authentication Checks 1101 MACs are useful for communication between two trusting parties who 1102 have already shared private keys. Examples include an RSA signature 1103 of a SHA256 digest or others. They rely on a KeyId. Some MACs might 1104 use more than a KeyId, but those would be defined in the future. 1106 3.6.4.1.3. Signature 1108 Signature type Validators specify a digest mechanism and a signing 1109 algorithm to verify the message. Examples include RSA signature og a 1110 SHA256 digest, an Elliptic Curve signature with SECP-256K1 1111 parameters, etc. These Validators require a KeyId and a mechanism 1112 for locating the publishers public key (a KeyLocator) - optionally a 1113 PublicKey or Certificate or KeyLink. 1115 3.6.4.1.4. Validation Dependent Data 1117 Different Validation Algorithms require access to different pieces of 1118 data contained in the ValidationAlgorithm TLV. As described above, 1119 Key Ids, Key Locators, Public Keys, Certificates, Links and Key Names 1120 all play a role in different Validation Algorithms. Any number of 1121 Validation Dependent Data containers can be present in a Validation 1122 Algorithm TLV. 1124 Following is a table of CCNx ValidationType dependent data types: 1126 +-------------+-----------------------+-----------------------------+ 1127 | Abbrev | Name | Description | 1128 +-------------+-----------------------+-----------------------------+ 1129 | T_KEYID | SignerKeyId (Section | An identifier of the shared | 1130 | | 3.6.4.1.4.1) | secret or public key | 1131 | | | associated with a MAC or | 1132 | | | Signature. | 1133 | | | | 1134 | T_PUBLICKEY | Public Key (Section | DER encoded public key. | 1135 | | 3.6.4.1.4.2) | | 1136 | | | | 1137 | T_CERT | Certificate (Section | DER encoded X509 | 1138 | | 3.6.4.1.4.3) | certificate. | 1139 | | | | 1140 | T_KEYLINK | KeyLink (Section | A CCNx Link object. | 1141 | | 3.6.4.1.4.4) | | 1142 | | | | 1143 | T_SIGTIME | SignatureTime | A millsecond timestamp | 1144 | | (Section 3.6.4.1.4.5) | indicating the time when | 1145 | | | the signature was created. | 1146 +-------------+-----------------------+-----------------------------+ 1148 Table 11: CCNx Validation Dependent Data Types 1150 3.6.4.1.4.1. KeyId 1152 The KeyId is the publisher key identifier. It is similar to a 1153 Subject Key Identifier from X509 [RFC 5280, Section 4.2.1.2]. It 1154 should be derived from the key used to sign, such as from the SHA-256 1155 hash of the key. It applies to both public/private key systems and 1156 to symmetric key systems. 1158 The KeyId is represented using the Section 3.3.3. If a protocol uses 1159 a non-hash identifier, it should use one of the reserved values. 1161 1 2 3 1162 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 1163 +---------------+---------------+---------------+---------------+ 1164 | T_KEYID | LENGTH+4 | 1165 +---------------+---------------+---------------+---------------+ 1166 | | LENGTH | 1167 +---------------+---------------+---------------+---------------+ 1168 / LENGTH octets of hash / 1169 +---------------+---------------+---------------+---------------+ 1171 3.6.4.1.4.2. Public Key 1173 A Public Key is a DER encoded Subject Public Key Info block, as in an 1174 X509 certificate. 1176 1 1177 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1178 +---------------+---------------+---------------+---------------+ 1179 | T_PUBLICKEY | Length | 1180 +---------------+---------------+---------------+---------------+ 1181 / Public Key (DER encoded SPKI) / 1182 +---------------+---------------+---------------+---------------+ 1184 3.6.4.1.4.3. Certificate 1186 1 2 3 1187 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 1188 +---------------+---------------+---------------+---------------+ 1189 | T_CERT | Length | 1190 +---------------+---------------+---------------+---------------+ 1191 / Certificate (DER encoded X509) / 1192 +---------------+---------------+---------------+---------------+ 1194 3.6.4.1.4.4. KeyLink 1196 A KeyLink type KeyLocator is a Link. 1198 The KeyLink ContentObjectHashRestr, if included, is the digest of the 1199 Content Object identified by KeyLink, not the digest of the public 1200 key. Likewise, the KeyIdRestr of the KeyLink is the KeyId of the 1201 ContentObject, not necessarily of the wrapped key. 1203 1 2 3 1204 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 1205 +---------------+---------------+-------------------------------+ 1206 | T_KEYKINK | Length | 1207 +---------------+---------------+-------------------------------+ 1208 / Link / 1209 +---------------------------------------------------------------+ 1211 3.6.4.1.4.5. SignatureTime 1213 The SignatureTime is a millisecond timestamp indicating the time at 1214 which a signature was created. The signer sets this field to the 1215 current time when creating a signature. A verifier may use this time 1216 to determine whether or not the signature was created during the 1217 validity period of a key, or if it occurred in a reasonable sequence 1218 with other associated signatures. The SignatureTime is unrelated to 1219 any time associated with the actual CCNx Message, which could have 1220 been created long before the signature. The default behavior is to 1221 always include a SignatureTime when creating an authenticated message 1222 (e.g. HMAC or RSA). 1224 SignatureTime is a network byte ordered unsigned integer of the 1225 number of milliseconds since the epoch in UTC of when the signature 1226 was created. It is a fixed 64-bit field. 1228 1 2 3 1229 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 1230 +---------------+---------------+-------------------------------+ 1231 | T_SIGTIME | 8 | 1232 +---------------+---------------+-------------------------------+ 1233 / SignatureTime / 1234 +---------------------------------------------------------------+ 1236 3.6.4.1.5. Validation Examples 1238 As an example of a MIC type validation, the encoding for CRC32C 1239 validation would be: 1241 1 2 3 1242 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 1243 +---------------+---------------+---------------+---------------+ 1244 | T_VALIDATION_ALG | 4 | 1245 +---------------+---------------+---------------+---------------+ 1246 | T_CRC32C | 0 | 1247 +---------------+---------------+---------------+---------------+ 1249 As an example of a MAC type validation, the encoding for an HMAC 1250 using a SHA256 hash 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 | 40 | 1256 +---------------+---------------+---------------+---------------+ 1257 | T_HMAC-SHA256 | 36 | 1258 +---------------+---------------+---------------+---------------+ 1259 | T_KEYID | 32 | 1260 +---------------+---------------+---------------+---------------+ 1261 / KeyId / 1262 /---------------+---------------+-------------------------------+ 1264 As an example of a Signature type validation, the encoding for an RSA 1265 public key signing using a SHA256 digest and Public Key would be: 1267 1 2 3 1268 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 1269 +---------------+---------------+---------------+---------------+ 1270 | T_VALIDATION_ALG | 44 + Variable Length | 1271 +---------------+---------------+---------------+---------------+ 1272 | T_RSA-SHA256 | 40 + Variable Length | 1273 +---------------+---------------+---------------+---------------+ 1274 | T_KEYID | 32 | 1275 +---------------+---------------+---------------+---------------+ 1276 / KeyId / 1277 /---------------+---------------+-------------------------------+ 1278 | T_PUBLICKEY | Variable Length (~ 160) | 1279 +---------------+---------------+---------------+---------------+ 1280 / Public Key (DER encoded SPKI) / 1281 +---------------+---------------+---------------+---------------+ 1283 3.6.4.2. Validation Payload 1285 1 2 3 1286 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 1287 +---------------+---------------+---------------+---------------+ 1288 | T_VALIDATION_PAYLOAD | ValidationPayloadLength | 1289 +---------------+---------------+---------------+---------------+ 1290 / Type-dependent data / 1291 +---------------+---------------+---------------+---------------+ 1293 The ValidationPayload contains the validation output, such as the 1294 CRC32C code or the RSA signature. 1296 4. IANA Considerations 1298 This section details each kind of protocol value that can be 1299 registered. Each type registry can be updated by incrementally 1300 expanding the type space, i.e., by allocating and reserving new 1301 types. As per [RFC5226] this section details the creation of the 1302 "CCNx Registry" and several sub-registries. 1304 +----------+---------------+ 1305 | Property | Value | 1306 +----------+---------------+ 1307 | Name | CCNx Registry | 1308 | | | 1309 | Abbrev | CCNx | 1310 +----------+---------------+ 1312 Registry Creation 1314 4.1. Packet Type Registry 1316 The following packet types should be allocated. A PacketType MUST be 1317 1 byte. New packet types are allocated via "RFC Required" action. 1319 +----------------+----------------------+ 1320 | Property | Value | 1321 +----------------+----------------------+ 1322 | Name | Packet Type Registry | 1323 | | | 1324 | Parent | CCNx Registry | 1325 | | | 1326 | Review process | RFC Required | 1327 | | | 1328 | Syntax | 1 octet | 1329 +----------------+----------------------+ 1331 Registry Creation 1333 +------+-------------+----------------------------------+ 1334 | Type | Name | Reference | 1335 +------+-------------+----------------------------------+ 1336 | %x00 | PT_INTEREST | Fixed Header Types (Section 3.2) | 1337 | | | | 1338 | %x01 | PT_CONTENT | Fixed Header Types (Section 3.2) | 1339 | | | | 1340 | %x02 | PT_RETURN | Fixed Header Types (Section 3.2) | 1341 +------+-------------+----------------------------------+ 1343 Packet Type Namespace 1345 4.2. Interest Return Code Registry 1347 The following InterestReturn code types should be allocated. 1349 +----------------+------------------------+ 1350 | Property | Value | 1351 +----------------+------------------------+ 1352 | Name | Interest Return Code | 1353 | | | 1354 | Parent | CCNx Registry | 1355 | | | 1356 | Review process | Specification Required | 1357 | | | 1358 | Syntax | 1 octet | 1359 +----------------+------------------------+ 1361 Registry Creation 1363 +------+---------------------------------------+--------------------+ 1364 | Type | Name | Reference | 1365 +------+---------------------------------------+--------------------+ 1366 | %x00 | Reserved | | 1367 | | | | 1368 | %x01 | T_RETURN_NO_ROUTE | Fixed Header Types | 1369 | | | (Section 3.2.3.3) | 1370 | | | | 1371 | %x02 | T_RETURN_LIMIT_EXCEEDED | Fixed Header Types | 1372 | | | (Section 3.2.3.3) | 1373 | | | | 1374 | %x03 | T_RETURN_NO_RESOURCES | Fixed Header Types | 1375 | | | (Section 3.2.3.3) | 1376 | | | | 1377 | %x04 | T_RETURN_PATH_ERROR | Fixed Header Types | 1378 | | | (Section 3.2.3.3) | 1379 | | | | 1380 | %x05 | T_RETURN_PROHIBITED | Fixed Header Types | 1381 | | | (Section 3.2.3.3) | 1382 | | | | 1383 | %x06 | T_RETURN_CONGESTED | Fixed Header Types | 1384 | | | (Section 3.2.3.3) | 1385 | | | | 1386 | %x07 | T_RETURN_MTU_TOO_LARGE | Fixed Header Types | 1387 | | | (Section 3.2.3.3) | 1388 | | | | 1389 | %x08 | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types | 1390 | | | (Section 3.2.3.3) | 1391 | | | | 1392 | %x09 | T_RETURN_MALFORMED_INTEREST | Fixed Header Types | 1393 | | | (Section 3.2.3.3) | 1394 +------+---------------------------------------+--------------------+ 1396 Interest Return Type Namespace 1398 4.3. Hop-by-Hop Type Registry 1400 The following hop-by-hop types should be allocated. 1402 +----------------+--------------------------+ 1403 | Property | Value | 1404 +----------------+--------------------------+ 1405 | Name | Hop-by-Hop Type Registry | 1406 | | | 1407 | Parent | CCNx Registry | 1408 | | | 1409 | Review process | RFC Required | 1410 | | | 1411 | Syntax | 2 octet TLV type | 1412 +----------------+--------------------------+ 1414 Registry Creation 1416 +---------------+-------------+-------------------------------------+ 1417 | Type | Name | Reference | 1418 +---------------+-------------+-------------------------------------+ 1419 | %x0000 | Reserved | | 1420 | | | | 1421 | %x0001 | T_INTLIFE | Hop-by-hop TLV headers (Section | 1422 | | | 3.4) | 1423 | | | | 1424 | %x0002 | T_CACHETIME | Hop-by-hop TLV headers (Section | 1425 | | | 3.4) | 1426 | | | | 1427 | %x0003 | T_MSGHASH | Hop-by-hop TLV headers (Section | 1428 | | | 3.4) | 1429 | | | | 1430 | %x0004 - | Reserved | | 1431 | %x0007 | | | 1432 | | | | 1433 | %x0FFE | T_PAD | Pad (Section 3.3.1) | 1434 | | | | 1435 | %x0FFF | T_ORG | Organization-Specific TLVs (Section | 1436 | | | 3.3.2) | 1437 | | | | 1438 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1439 +---------------+-------------+-------------------------------------+ 1441 Hop-by-Hop Type Namespace 1443 4.4. Top-Level Type Registry 1445 The following top-level types should be allocated. 1447 +----------------+-------------------------+ 1448 | Property | Value | 1449 +----------------+-------------------------+ 1450 | Name | Top-Level Type Registry | 1451 | | | 1452 | Parent | CCNx Registry | 1453 | | | 1454 | Review process | RFC Required | 1455 | | | 1456 | Syntax | 2 octet TLV type | 1457 +----------------+-------------------------+ 1459 Registry Creation 1461 +--------+----------------------+-------------------------------+ 1462 | Type | Name | Reference | 1463 +--------+----------------------+-------------------------------+ 1464 | %x0000 | Reserved | | 1465 | | | | 1466 | %x0001 | T_INTEREST | Top-Level Types (Section 3.5) | 1467 | | | | 1468 | %x0002 | T_OBJECT | Top-Level Types (Section 3.5) | 1469 | | | | 1470 | %x0003 | T_VALIDATION_ALG | Top-Level Types (Section 3.5) | 1471 | | | | 1472 | %x0004 | T_VALIDATION_PAYLOAD | Top-Level Types (Section 3.5) | 1473 +--------+----------------------+-------------------------------+ 1475 Top-Level Type Namespace 1477 4.5. Name Segment Type Registry 1479 The following name segment types should be allocated. 1481 +----------------+----------------------------+ 1482 | Property | Value | 1483 +----------------+----------------------------+ 1484 | Name | Name Segment Type Registry | 1485 | | | 1486 | Parent | CCNx Registry | 1487 | | | 1488 | Review process | Specification Required | 1489 | | | 1490 | Syntax | 2 octet TLV type | 1491 +----------------+----------------------------+ 1493 Registry Creation 1495 +--------------+------------------+---------------------------------+ 1496 | Type | Name | Reference | 1497 +--------------+------------------+---------------------------------+ 1498 | %x0000 | Reserved | | 1499 | | | | 1500 | %x0001 | T_NAMESEGMENT | Name (Section 3.6.1) | 1501 | | | | 1502 | %x0002 | T_IPID | Name (Section 3.6.1) | 1503 | | | | 1504 | %x0010 - | Reserved | Used in other drafts | 1505 | %x0013 | | | 1506 | | | | 1507 | %x0FFF | T_ORG | Organization-Specific TLVs | 1508 | | | (Section 3.3.2) | 1509 | | | | 1510 | %x1000 - | T_APP:00 - | Application Components (Section | 1511 | %x1FFF | T_APP:4096 | 3.6.1) | 1512 +--------------+------------------+---------------------------------+ 1514 Name Segment Type Namespace 1516 4.6. Message Type Registry 1518 The following CCNx message segment types should be allocated. 1520 +----------------+-----------------------+ 1521 | Property | Value | 1522 +----------------+-----------------------+ 1523 | Name | Message Type Registry | 1524 | | | 1525 | Parent | CCNx Registry | 1526 | | | 1527 | Review process | RFC Required | 1528 | | | 1529 | Syntax | 2 octet TLV type | 1530 +----------------+-----------------------+ 1532 Registry Creation 1534 +---------------+----------------+----------------------------------+ 1535 | Type | Name | Reference | 1536 +---------------+----------------+----------------------------------+ 1537 | %x0000 | T_NAME | Message Types (Section 3.6) | 1538 | | | | 1539 | %x0001 | T_PAYLOAD | Message Types (Section 3.6) | 1540 | | | | 1541 | %x0002 | T_KEYIDRESTR | Message Types (Section 3.6) | 1542 | | | | 1543 | %x0003 | T_OBJHASHRESTR | Message Types (Section 3.6) | 1544 | | | | 1545 | %x0005 | T_PAYLDTYPE | Content Object Message Types | 1546 | | | (Section 3.6.2.2) | 1547 | | | | 1548 | %x0006 | T_EXPIRY | Content Object Message Types | 1549 | | | (Section 3.6.2.2) | 1550 | | | | 1551 | %x0007 - | Reserved | Used in other RFC drafts | 1552 | %x000C | | | 1553 | | | | 1554 | %x0FFE | T_PAD | Pad (Section 3.3.1) | 1555 | | | | 1556 | %x0FFF | T_ORG | Organization-Specific TLVs | 1557 | | | (Section 3.3.2) | 1558 | | | | 1559 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1560 +---------------+----------------+----------------------------------+ 1562 CCNx Message Type Namespace 1564 4.7. Payload Type Registry 1566 The following payload types should be allocated. 1568 +----------------+----------------------------------+ 1569 | Property | Value | 1570 +----------------+----------------------------------+ 1571 | Name | PayloadType Registry | 1572 | | | 1573 | Parent | CCNx Registry | 1574 | | | 1575 | Review process | Specification Required | 1576 | | | 1577 | Syntax | Variable length unsigned integer | 1578 +----------------+----------------------------------+ 1580 Registry Creation 1582 +------+--------------------+-----------------------------------+ 1583 | Type | Name | Reference | 1584 +------+--------------------+-----------------------------------+ 1585 | %x00 | T_PAYLOADTYPE_DATA | Payload Types (Section 3.6.2.2.1) | 1586 | | | | 1587 | %x01 | T_PAYLOADTYPE_KEY | Payload Types (Section 3.6.2.2.1) | 1588 | | | | 1589 | %x02 | T_PAYLOADTYPE_LINK | Payload Types (Section 3.6.2.2.1) | 1590 +------+--------------------+-----------------------------------+ 1592 Payload Type Namespace 1594 4.8. Validation Algorithm Type Registry 1596 The following validation algorithm types should be allocated. Note: 1597 registration requires public specification of the algorithm. 1599 +----------------+------------------------------------+ 1600 | Property | Value | 1601 +----------------+------------------------------------+ 1602 | Name | Validation Algorithm Type Registry | 1603 | | | 1604 | Parent | CCNx Registry | 1605 | | | 1606 | Review process | Specification Required | 1607 | | | 1608 | Syntax | 2 octet TLV type | 1609 +----------------+------------------------------------+ 1611 Registry Creation 1613 +---------------+---------------+-----------------------------------+ 1614 | Type | Name | Reference | 1615 +---------------+---------------+-----------------------------------+ 1616 | %x0000 | Reserved | | 1617 | | | | 1618 | %x0001 | Unassigned | | 1619 | | | | 1620 | %x0002 | T_CRC32C | Validation Algorithm (Section | 1621 | | | 3.6.4.1) | 1622 | | | | 1623 | %x0003 | Unassigned | | 1624 | | | | 1625 | %x0004 | T_HMAC-SHA256 | Validation Algorithm (Section | 1626 | | | 3.6.4.1) | 1627 | | | | 1628 | %x0005 | T_RSA-SHA256 | Validation Algorithm (Section | 1629 | | | 3.6.4.1) | 1630 | | | | 1631 | %x0006 | EC-SECP-256K1 | Validation Algorithm (Section | 1632 | | | 3.6.4.1) | 1633 | | | | 1634 | %x0007 | EC-SECP-384R1 | Validation Algorithm (Section | 1635 | | | 3.6.4.1) | 1636 | | | | 1637 | %x0FFE | T_PAD | Pad (Section 3.3.1) | 1638 | | | | 1639 | %x0FFF | T_ORG | Organization-Specific TLVs | 1640 | | | (Section 3.3.2) | 1641 | | | | 1642 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1643 +---------------+---------------+-----------------------------------+ 1645 Validation Algorithm Type Namespace 1647 4.9. Validation Dependent Data Type Registry 1649 The following validation dependent data types should be allocated. 1651 +----------------+-----------------------------------------+ 1652 | Property | Value | 1653 +----------------+-----------------------------------------+ 1654 | Name | Validation Dependent Data Type Registry | 1655 | | | 1656 | Parent | CCNx Registry | 1657 | | | 1658 | Review process | RFC Required | 1659 | | | 1660 | Syntax | 2 octet TLV type | 1661 +----------------+-----------------------------------------+ 1663 Registry Creation 1665 +---------------+----------------+----------------------------------+ 1666 | Type | Name | Reference | 1667 +---------------+----------------+----------------------------------+ 1668 | %x0000 | Reserved | | 1669 | | | | 1670 | %x0001 - | Unassigned | | 1671 | %x0008 | | | 1672 | | | | 1673 | %x0009 | T_KEYID | Validation Dependent Data | 1674 | | | (Section 3.6.4.1.4) | 1675 | | | | 1676 | %x000A | T_PUBLICKEYLOC | Validation Dependent Data | 1677 | | | (Section 3.6.4.1.4) | 1678 | | | | 1679 | %x000B | T_PUBLICKEY | Validation Dependent Data | 1680 | | | (Section 3.6.4.1.4) | 1681 | | | | 1682 | %x000C | T_CERT | Validation Dependent Data | 1683 | | | (Section 3.6.4.1.4) | 1684 | | | | 1685 | %x000D | T_LINK | Validation Dependent Data | 1686 | | | (Section 3.6.4.1.4) | 1687 | | | | 1688 | %x000E | T_KEYLINK | Validation Dependent Data | 1689 | | | (Section 3.6.4.1.4) | 1690 | | | | 1691 | %x000F | T_SIGTIME | Validation Dependent Data | 1692 | | | (Section 3.6.4.1.4) | 1693 | | | | 1694 | %x0FFF | T_ORG | Organization-Specific TLVs | 1695 | | | (Section 3.3.2) | 1696 | | | | 1697 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1698 +---------------+----------------+----------------------------------+ 1700 Validation Dependent Data Type Namespace 1702 4.10. Hash Function Type Registry 1704 The following CCNx hash function types should be allocated. Note: 1705 registration requires public specification of the algorithm. 1707 +----------------+-----------------------------+ 1708 | Property | Value | 1709 +----------------+-----------------------------+ 1710 | Name | Hash Function Type Registry | 1711 | | | 1712 | Parent | CCNx Registry | 1713 | | | 1714 | Review process | Specification Required | 1715 | | | 1716 | Syntax | 2 octet TLV type | 1717 +----------------+-----------------------------+ 1719 Registry Creation 1721 +---------------+-----------+---------------------------------------+ 1722 | Type | Name | Reference | 1723 +---------------+-----------+---------------------------------------+ 1724 | %x0000 | Reserved | | 1725 | | | | 1726 | %x0001 | T_SHA-256 | Hash Format (Section 3.3.3) | 1727 | | | | 1728 | %x0002 | T_SHA-512 | Hash Format (Section 3.3.3) | 1729 | | | | 1730 | %x0FFF | T_ORG | Organization-Specific TLVs (Section | 1731 | | | 3.3.2) | 1732 | | | | 1733 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1734 +---------------+-----------+---------------------------------------+ 1736 CCNx Hash Function Type Namespace 1738 5. Security Considerations 1740 The CCNx protocol is a layer 3 network protocol, which may also 1741 operate as an overlay using other transports, such as UDP or other 1742 tunnels. It includes intrinsic support for message authentication 1743 via a signature (e.g. RSA or elliptic curve) or message 1744 authentication code (e.g. HMAC). In lieu of an authenticator, it 1745 may instead use a message integrity check (e.g. SHA or CRC). CCNx 1746 does not specify an encryption envelope, that function is left to a 1747 high-layer protocol (e.g. [esic]). 1749 The CCNx message format includes the ability to attach MICs (e.g. 1750 SHA-256 or CRC), MACs (e.g. HMAC), and Signatures (e.g. RSA or 1751 ECDSA) to all packet types. This does not mean that it is a good 1752 idea to use an arbitrary ValidationAlgorithm, nor to include 1753 computationally expensive algorithms in Interest packets, as that 1754 could lead to computational DoS attacks. Applications should use an 1755 explicit protocol to guide their use of packet signatures. As a 1756 general guideline, an application might use a MIC on an Interest to 1757 detect unintentionally corrupted packets. If one wishes to secure an 1758 Interest, one should consider using an encrypted wrapper and a 1759 protocol that prevents replay attacks, especially if the Interest is 1760 being used as an actuator. Simply using an authentication code or 1761 signature does not make an Interests secure. There are several 1762 examples in the literature on how to secure ICN-style messaging 1763 [mobile] [ace]. 1765 As a layer 3 protocol, this document does not describe how one 1766 arrives at keys or how one trusts keys. The CCNx content object may 1767 include a public key embedded in the object or may use the 1768 PublicKeyLocator field to point to a public key (or public key 1769 certificate) that authenticates the message. One key exchange 1770 specification is CCNxKE [ccnxke] [mobile], which is similar to the 1771 TLS 1.3 key exchange except it is over the CCNx layer 3 messages. 1772 Trust is beyond the scope of a layer-3 protocol protocol and left to 1773 applications or application frameworks. 1775 The combination of an ephemeral key exchange (e.g. CCNxKE [ccnxke]) 1776 and an encapsulating encryption (e.g. [esic]) provides the equivalent 1777 of a TLS tunnel. Intermediate nodes may forward the Interests and 1778 Content Objects, but have no visibility inside. It also completely 1779 hides the internal names in those used by the encryption layer. This 1780 type of tunneling encryption is useful for content that has little or 1781 no cache-ability as it can only be used by someone with the ephemeral 1782 key. Short term caching may help with lossy links or mobility, but 1783 long term caching is usually not of interest. 1785 Broadcast encryption or proxy re-encryption may be useful for content 1786 with multiple uses over time or many consumers. There is currently 1787 no recommendation for this form of encryption. 1789 The specific encoding of messages will have security implications. 1790 This document uses a type-length-value (TLV) encoding. We chose to 1791 compromise between extensibility and unambiguous encodings of types 1792 and lengths. Some TLVs use variable length T and variable length L 1793 fields to accomodate a wide gamut of values while trying to be byte- 1794 efficient. Our TLV encoding uses a fixed length 2-byte T and 2-byte 1795 L. Using a fixed-length T and L field solves two problems. The 1796 first is aliases. If one is able to encode the same value, such as 1797 0x2 and 0x02, in different byte lengths then one must decide if they 1798 mean the same thing, if they are different, or if one is illegal. If 1799 they are different, then one must always compare on the buffers not 1800 the integer equivalents. If one is illegal, then one must validate 1801 the TLV encoding -- every field of every packet at every hop. If 1802 they are the same, then one has the second problem: how to specify 1803 packet filters. For example, if a name has 6 name components, then 1804 there are 7 T's and 7 L's, each of which might have up to 4 1805 representations of the same value. That would be 14 fields with 4 1806 encodings each, or 1001 combinations. It also means that one cannot 1807 compare, for example, a name via a memory function as one needs to 1808 consider that any embedded T or L might have a different format. 1810 The Interest Return message has no authenticator from the previous 1811 hop. Therefore, the payload of the Interest Return should only be 1812 used locally to match an Interest. A node should never forward that 1813 Interest payload as an Interest. It should also verify that it sent 1814 the Interest in the Interest Return to that node and not allow anyone 1815 to negate Interest messages. 1817 Caching nodes must take caution when processing content objects. It 1818 is essential that the Content Store obey the rules outlined in 1819 [CCNSemantics] to avoid certain types of attacks. Unlike NDN, CCNx 1820 1.0 has no mechanism to work around an undesired result from the 1821 network (there are no "excludes"), so if a cache becomes poisoned 1822 with bad content it might cause problems retrieving content. There 1823 are three types of access to content from a content store: 1824 unrestricted, signature restricted, and hash restricted. If an 1825 Interest has no restrictions, then the requester is not particular 1826 about what they get back, so any matching cached object is OK. In 1827 the hash restricted case, the requester is very specific about what 1828 they want and the content store (and every forward hop) can easily 1829 verify that the content matches the request. In the signature 1830 verified case (often used for initial manifest discovery), the 1831 requester only knows the KeyId that signed the content. It is this 1832 case that requires the closest attention in the content store to 1833 avoid amplifying bad data. The content store must only respond with 1834 a content object if it can verify the signature -- this means either 1835 the content object carries the public key inside it or the Interest 1836 carries the public key in addition to the KeyId. If that is not the 1837 case, then the content store should treat the Interest as a cache 1838 miss and let an endpoint respond. 1840 A user-level cache could perform full signature verification by 1841 fetching a public key according to the PublicKeyLocator. That is 1842 not, however, a burden we wish to impose on the forwarder. A user- 1843 level cache could also rely on out-of-band attestation, such as the 1844 cache operator only inserting content that it knows has the correct 1845 signature. 1847 The CCNx grammar allows for hash algorithm agility via the HashType. 1848 It specifies a short list of acceptable hash algorithms that should 1849 be implemented at each forwarder. Some hash values only apply to end 1850 systems, so updating the hash algorithm does not affect forwarders -- 1851 they would simply match the buffer that includes the type-length-hash 1852 buffer. Some fields, such as the ConObjHash, must be verified at 1853 each hop, so a forwarder (or related system) must know the hash 1854 algorithm and it could cause backward compatibility problems if the 1855 hash type is updated. 1857 A CCNx name uses binary matching whereas a URI uses a case 1858 insensitive hostname. Some systems may also use case insensitive 1859 matching of the URI path to a resource. An implication of this is 1860 that human-entered CCNx names will likely have case or non-ASCII 1861 symbol mismatches unless one uses a consistent URI normalization to 1862 the CCNx name. It also means that an entity that registers a CCNx 1863 routable prefix, say ccnx:/example.com, would need separate 1864 registrations for simple variations like ccnx:/Example.com. Unless 1865 this is addressed in URI normalization and routing protocol 1866 conventions, there could be phishing attacks. 1868 For a more general introduction to ICN-related security concerns and 1869 approaches, see [RFC7927] and [RFC7945] 1871 6. References 1873 6.1. Normative References 1875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1876 Requirement Levels", BCP 14, RFC 2119, 1877 DOI 10.17487/RFC2119, March 1997, . 1880 6.2. Informative References 1882 [ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, 1883 "NDN-ACE: Access control for constrained environments over 1884 named data networking", NDN Technical Report NDN-0036, 1885 2015, . 1888 [CCNSemantics] 1889 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics 1890 (Internet draft)", 2018, . 1893 [ccnxke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange 1894 Protocol Version 1.0", 2017, 1895 . 1898 [CCNxURI] Mosko, M. and C. Wood, "The CCNx URI Scheme (Internet 1899 draft)", 2017, 1900 . 1902 [CCNxz] Mosko, M., "CCNxz TLV Header Compression Experimental 1903 Code", 2016-2018, . 1905 [compress] 1906 Mosko, M., "Header Compression for TLV-based Packets", 1907 2016, . 1910 [ECC] Certicom Research, "SEC 2: Recommended Elliptic Curve 1911 Domain Parameters", 2010, 1912 . 1914 [EpriseNumbers] 1915 IANA, "IANA Private Enterprise Numbers", 2015, 1916 . 1919 [esic] Mosko, M. and C. Wood, "Encrypted Sessions In CCNx 1920 (ESIC)", 2017, . 1923 [mobile] Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in 1924 Content-Centric Networks", IFIP Networking, 2017, 1925 . 1928 [nnc] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 1929 Briggs, N., and R. Braynard, "Networking Named Content", 1930 2009, . 1932 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1933 IANA Considerations Section in RFCs", RFC 5226, 1934 DOI 10.17487/RFC5226, May 2008, . 1937 [RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., 1938 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1939 "Information-Centric Networking (ICN) Research 1940 Challenges", 2016, . 1943 [RFC7945] Pentikousis, K., Ohlman, B., Davies, E., Spirou, S., and 1944 G. Boggia, "Information-Centric Networking: Evaluation and 1945 Security Considerations", 2016, 1946 . 1948 Authors' Addresses 1950 Marc Mosko 1951 PARC, Inc. 1952 Palo Alto, California 94304 1953 USA 1955 Phone: +01 650-812-4405 1956 Email: marc.mosko@parc.com 1958 Ignacio Solis 1959 LinkedIn 1960 Mountain View, California 94043 1961 USA 1963 Email: nsolis@linkedin.com 1965 Christopher A. Wood 1966 University of California Irvine 1967 Irvine, California 92697 1968 USA 1970 Phone: +01 315-806-5939 1971 Email: woodc1@uci.edu