icnrg: draft-irtf-icnrg-ccnxmessages-07.txt

File draft-irtf-icnrg-ccnxmessages-07.txt, 110.3 KB (added by Borje.Ohlman@…, 2 months ago)
Line 
1
2
3
4
5ICNRG                                                           M. Mosko
6Internet-Draft                                                PARC, Inc.
7Intended status: Experimental                                   I. Solis
8Expires: September 8, 2018                                      LinkedIn
9                                                                 C. Wood
10                                         University of California Irvine
11                                                           March 7, 2018
12
13
14                      CCNx Messages in TLV Format
15                  draft-irtf-icnrg-ccnxmessages-07
16
17Abstract
18
19   This document specifies the encoding of CCNx messages in a TLV packet
20   format, including the TLV types used by each message element and the
21   encoding of each value.  The semantics of CCNx messages follow the
22   encoding-independent CCNx Semantics specification.
23
24   This document is a product of the Information Centric Networking
25   research group (ICNRG).
26
27Status of This Memo
28
29   This Internet-Draft is submitted in full conformance with the
30   provisions of BCP 78 and BCP 79.
31
32   Internet-Drafts are working documents of the Internet Engineering
33   Task Force (IETF).  Note that other groups may also distribute
34   working documents as Internet-Drafts.  The list of current Internet-
35   Drafts is at http://datatracker.ietf.org/drafts/current/.
36
37   Internet-Drafts are draft documents valid for a maximum of six months
38   and may be updated, replaced, or obsoleted by other documents at any
39   time.  It is inappropriate to use Internet-Drafts as reference
40   material or to cite them other than as "work in progress."
41
42   This Internet-Draft will expire on September 8, 2018.
43
44Copyright Notice
45
46   Copyright (c) 2018 IETF Trust and the persons identified as the
47   document authors.  All rights reserved.
48
49   This document is subject to BCP 78 and the IETF Trust's Legal
50   Provisions Relating to IETF Documents
51   (http://trustee.ietf.org/license-info) in effect on the date of
52   publication of this document.  Please review these documents
53
54
55
56Mosko, et al.           Expires September 8, 2018               [Page 1]
57
58Internet-Draft                  CCNx TLV                      March 2018
59
60
61   carefully, as they describe your rights and restrictions with respect
62   to this document.  Code Components extracted from this document must
63   include Simplified BSD License text as described in Section 4.e of
64   the Trust Legal Provisions and are provided without warranty as
65   described in the Simplified BSD License.
66
67Table of Contents
68
69   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
70     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
71   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
72   3.  Type-Length-Value (TLV) Packets . . . . . . . . . . . . . . .   5
73     3.1.  Overall packet format . . . . . . . . . . . . . . . . . .   6
74     3.2.  Fixed Headers . . . . . . . . . . . . . . . . . . . . . .   7
75       3.2.1.  Interest Fixed Header . . . . . . . . . . . . . . . .   8
76         3.2.1.1.  Interest HopLimit . . . . . . . . . . . . . . . .   8
77       3.2.2.  Content Object Fixed Header . . . . . . . . . . . . .   9
78       3.2.3.  InterestReturn Fixed Header . . . . . . . . . . . . .   9
79         3.2.3.1.  InterestReturn HopLimit . . . . . . . . . . . . .   9
80         3.2.3.2.  InterestReturn Flags  . . . . . . . . . . . . . .   9
81         3.2.3.3.  Return Code . . . . . . . . . . . . . . . . . . .  10
82     3.3.  Global Formats  . . . . . . . . . . . . . . . . . . . . .  10
83       3.3.1.  Pad . . . . . . . . . . . . . . . . . . . . . . . . .  10
84       3.3.2.  Organization Specific TLVs  . . . . . . . . . . . . .  11
85       3.3.3.  Hash Format . . . . . . . . . . . . . . . . . . . . .  11
86       3.3.4.  Link  . . . . . . . . . . . . . . . . . . . . . . . .  12
87     3.4.  Hop-by-hop TLV headers  . . . . . . . . . . . . . . . . .  13
88       3.4.1.  Interest Lifetime . . . . . . . . . . . . . . . . . .  13
89       3.4.2.  Recommended Cache Time  . . . . . . . . . . . . . . .  14
90       3.4.3.  Message Hash  . . . . . . . . . . . . . . . . . . . .  14
91     3.5.  Top-Level Types . . . . . . . . . . . . . . . . . . . . .  15
92     3.6.  CCNx Message  . . . . . . . . . . . . . . . . . . . . . .  16
93       3.6.1.  Name  . . . . . . . . . . . . . . . . . . . . . . . .  16
94         3.6.1.1.  Name Segments . . . . . . . . . . . . . . . . . .  17
95         3.6.1.2.  Interest Payload ID . . . . . . . . . . . . . . .  18
96       3.6.2.  Message TLVs  . . . . . . . . . . . . . . . . . . . .  19
97         3.6.2.1.  Interest Message TLVs . . . . . . . . . . . . . .  19
98         3.6.2.2.  Content Object Message TLVs . . . . . . . . . . .  20
99       3.6.3.  Payload . . . . . . . . . . . . . . . . . . . . . . .  22
100       3.6.4.  Validation  . . . . . . . . . . . . . . . . . . . . .  22
101         3.6.4.1.  Validation Algorithm  . . . . . . . . . . . . . .  22
102         3.6.4.2.  Validation Payload  . . . . . . . . . . . . . . .  28
103   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
104     4.1.  Packet Type Registry  . . . . . . . . . . . . . . . . . .  29
105     4.2.  Interest Return Code Registry . . . . . . . . . . . . . .  29
106     4.3.  Hop-by-Hop Type Registry  . . . . . . . . . . . . . . . .  31
107     4.4.  Top-Level Type Registry . . . . . . . . . . . . . . . . .  31
108     4.5.  Name Segment Type Registry  . . . . . . . . . . . . . . .  32
109
110
111
112Mosko, et al.           Expires September 8, 2018               [Page 2]
113
114Internet-Draft                  CCNx TLV                      March 2018
115
116
117     4.6.  Message Type Registry . . . . . . . . . . . . . . . . . .  33
118     4.7.  Payload Type Registry . . . . . . . . . . . . . . . . . .  34
119     4.8.  Validation Algorithm Type Registry  . . . . . . . . . . .  35
120     4.9.  Validation Dependent Data Type Registry . . . . . . . . .  36
121     4.10. Hash Function Type Registry . . . . . . . . . . . . . . .  37
122   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  38
123   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  41
124     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  41
125     6.2.  Informative References  . . . . . . . . . . . . . . . . .  41
126   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  43
127
1281.  Introduction
129
130   This document specifies a Type-Length-Value (TLV) packet format and
131   the TLV type and value encodings for CCNx messages.  A full
132   description of the CCNx network protocol, providing an encoding-free
133   description of CCNx messages and message elements, may be found in
134   [CCNSemantics].  CCNx is a network protocol that uses a hierarchical
135   name to forward requests and to match responses to requests.  It does
136   not use endpoint addresses, such as Internet Protocol.  Restrictions
137   in a request can limit the response by the public key of the
138   response's signer or the cryptographic hash of the response.  Every
139   CCNx forwarder along the path does the name matching and restriction
140   checking.  The CCNx protocol fits within the broader framework of
141   Information Centric Networking (ICN) protocols [RFC7927].
142
143   This document describes a TLV scheme using a fixed 2-byte T and a
144   fixed 2-byte L field.  The rational for this choice is described in
145   Section 5.  Briefly, this choice is to avoid multiple encodings of
146   the same value (aliases) and reduce the work of a validator to ensure
147   compliance.  Unlike some uses of TLV in networking, the use here must
148   be evaluated at each network hop, so even small validation latencies
149   could add to a large packet forwarding delay.  For very small packets
150   or low throughput links, where the extra bytes may become a concern,
151   one may use a TLV compression protocol, for example [compress] and
152   [CCNxz].
153
154   This document specifies:
155
156   o  The TLV packet format.
157
158   o  The overall packet format for CCNx messages.
159
160   o  The TLV types used by CCNx messages.
161
162   o  The encoding of values for each type.
163
164   o  Top level types that exist at the outermost containment.
165
166
167
168Mosko, et al.           Expires September 8, 2018               [Page 3]
169
170Internet-Draft                  CCNx TLV                      March 2018
171
172
173   o  Interest TLVs that exist within Interest containment.
174
175   o  Content Object TLVs that exist within Content Object containment.
176
177   This document is supplemented by this document:
178
179   o  Message semantics: see [CCNSemantics] for the protocol operation
180      regarding Interest and Content Object, including the Interest
181      Return protocol.
182
183   o  URI notation: see [CCNxURI] for the CCNx URI notation.
184
185   The type values in Section 4 represent the values in common usage
186   today.  These values may change pending IANA assignments.  All type
187   values are relative to their parent containers.  It is possible for a
188   TLV to redefine a type value defined by its parent.  For example,
189   each level of a nested TLV structure might define a "type = 1" with a
190   completely different meaning.
191
192   Packets are represented as 32-bit wide words using ASCII art.  Due to
193   the nested levels of TLV encoding and the presence of optional fields
194   and variable sizes, there is no concise way to represent all
195   possibilities.  We use the convention that ASCII art fields enclosed
196   by vertical bars "|" represent exact bit widths.  Fields with a
197   forward slash "/" are variable bit widths, which we typically pad out
198   to word alignment for picture readability.
199
200   The document represents the consensus of the ICN RG.  It is the first
201   ICN protocol from the RG, created from the early CCNx protocol [nnc]
202   with significant revision and input from the ICN community and RG
203   members.  The draft has received critical reading by several members
204   of the ICN community and the RG.  The authors and RG chairs approve
205   of the contents.  The document is sponsored under the IRTF and is not
206   issued by the IETF and is not an IETF standard.  This is an
207   experimental protocol and may not be suitable for any specific
208   application and the specification may change in the future.
209
2101.1.  Requirements Language
211
212   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
213   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
214   document are to be interpreted as described in RFC 2119 [RFC2119].
215
2162.  Definitions
217
218   o  Name: A hierarchically structured variable length identifier.  It
219      is an ordered list of path segments, which may be variable length
220      octet strings.  In human-readable form, it is represented in URI
221
222
223
224Mosko, et al.           Expires September 8, 2018               [Page 4]
225
226Internet-Draft                  CCNx TLV                      March 2018
227
228
229      format as ccnx:/path/part.  There is no host or query string.  See
230      [CCNxURI] for complete details.
231
232   o  Interest: A message requesting a Content Object with a matching
233      Name and other optional selectors to choose from multiple objects
234      with the same Name.  Any Content Object with a Name and optional
235      selectors that matches the Name and optional selectors of the
236      Interest is said to satisfy the Interest.
237
238   o  Content Object: A data object sent in response to an Interest
239      request.  It has an (optional) Name and a content payload that are
240      bound together via cryptographic means.
241
2423.  Type-Length-Value (TLV) Packets
243
244   We use 16-bit Type and 16-bit Length fields to encode TLV based
245   packets.  This provides 64K different possible types and value field
246   lengths of up to 64KiB.  With 64K possible types, there should be
247   sufficient space for basic protocol types, while also allowing ample
248   room for experimentation, application use, and growth.
249
250   Specifically, the TLV types in the range 0x1000 - 0x1FFF are reserved
251   for experimental use.  These type values are reserved in all TLV
252   container contexts.  In the event that more space is needed, either
253   for types or for length, a new version of the protocol would be
254   needed.  See Section 3.3.2 for more information about organization
255   specific TLVs.
256
257   +--------+-------------------------+--------------------------------+
258   | Abbrev |           Name          | Description                    |
259   +--------+-------------------------+--------------------------------+
260   | T_ORG  |     Vendor Specific     | Information specific to a      |
261   |        |   Information (Section  | vendor implementation (see     |
262   |        |          3.3.2)         | below).                        |
263   |        |                         |                                |
264   |  n/a   |       Experimental      | Experimental use.              |
265   +--------+-------------------------+--------------------------------+
266
267                        Table 1: Reserved TLV Types
268
269                        1                   2
270    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
271   +---------------+---------------+---------------+---------------+
272   |              Type             |            Length             |
273   +---------------+---------------+---------------+---------------+
274
275
276
277
278
279
280Mosko, et al.           Expires September 8, 2018               [Page 5]
281
282Internet-Draft                  CCNx TLV                      March 2018
283
284
285   The Length field contains the length of the Value field in octets.
286   It does not include the length of the Type and Length fields.  The
287   length MAY be zero.
288
289   TLV structures are nestable, allowing the Value field of one TLV
290   structure to contain additional TLV structures.  The enclosing TLV
291   structure is called the container of the enclosed TLV.
292
293   Type values are context-dependent.  Within a TLV container, one may
294   re-use previous type values for new context-dependent purposes.
295
2963.1.  Overall packet format
297
298   Each packet includes the 8 byte fixed header described below,
299   followed by a set of TLV fields.  These fields are optional hop-by-
300   hop headers and the Packet Payload.
301
302                       1                   2                   3
303   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
304   +---------------+---------------+---------------+---------------+
305   |    Version    |  PacketType   |         PacketLength          |
306   +---------------+---------------+---------------+---------------+
307   |           PacketType specific fields          | HeaderLength  |
308   +---------------+---------------+---------------+---------------+
309   / Optional Hop-by-hop header TLVs                               /
310   +---------------+---------------+---------------+---------------+
311   / PacketPayload TLVs                                            /
312   +---------------+---------------+---------------+---------------+
313
314   The packet payload is a TLV encoding of the CCNx message, followed by
315   optional Validation TLVs.
316
317                       1                   2                   3
318   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
319   +---------------+---------------+---------------+---------------+
320   | CCNx Message TLV                                              /
321   +---------------+---------------+---------------+---------------+
322   / Optional CCNx ValidationAlgorithm TLV                         /
323   +---------------+---------------+---------------+---------------+
324   / Optional CCNx ValidationPayload TLV (ValidationAlg required)  /
325   +---------------+---------------+---------------+---------------+
326
327   This document describes the Version "1" TLV encoding.
328
329   After discarding the fixed and hop-by-hop headers the remaining
330   PacketPayload should be a valid protocol message.  Therefore, the
331   PacketPayload always begins with a 4 byte TLV defining the protocol
332   message (whether it is an Interest, Content Object, or other message
333
334
335
336Mosko, et al.           Expires September 8, 2018               [Page 6]
337
338Internet-Draft                  CCNx TLV                      March 2018
339
340
341   type) and its total length.  The embedding of a self-sufficient
342   protocol data unit inside the fixed and hop-by-hop headers allows a
343   network stack to discard the headers and operate only on the embedded
344   message.
345
346   The range of bytes protected by the Validation includes the CCNx
347   Message and the ValidationAlgorithm.
348
349   The ContentObjectHash begins with the CCNx Message and ends at the
350   tail of the packet.
351
3523.2.  Fixed Headers
353
354   CCNx messages begin with an 8 byte fixed header (non-TLV format).
355   The HeaderLength field represents the combined length of the Fixed
356   and Hop-by-hop headers.  The PacketLength field represents the entire
357   Packet length.
358
359   A specific PacketType may assign meaning to the "PacketType specific
360   fields".
361
362   The PacketPayload of a CCNx packet is the protocol message itself.
363   The Content Object Hash is computed over the PacketPayload only,
364   excluding the fixed and hop-by-hop headers as those might change from
365   hop to hop.  Signed information or Similarity Hashes should not
366   include any of the fixed or hop-by-hop headers.  The PacketPayload
367   should be self-sufficient in the event that the fixed and hop-by-hop
368   headers are removed.
369
370                        1                   2                   3
371    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
372   +---------------+---------------+---------------+---------------+
373   |    Version    |  PacketType   |         PacketLength          |
374   +---------------+---------------+---------------+---------------+
375   |           PacketType specific fields          | HeaderLength  |
376   +---------------+---------------+---------------+---------------+
377
378   o  Version: defines the version of the packet.
379
380   o  HeaderLength: The length of the fixed header (8 bytes) and hop-by-
381      hop headers.  The minimum value MUST be "8".
382
383   o  PacketType: describes forwarder actions to take on the packet.
384
385   o  PacketLength: Total octets of packet including all headers (fixed
386      header plus hop-by-hop headers) and protocol message.
387
388
389
390
391
392Mosko, et al.           Expires September 8, 2018               [Page 7]
393
394Internet-Draft                  CCNx TLV                      March 2018
395
396
397   o  PacketType Specific Fields: specific PacketTypes define the use of
398      these bits.
399
400   The PacketType field indicates how the forwarder should process the
401   packet.  A Request Packet (Interest) has PacketType PT_INTEREST, a
402   Response (Content Object) has PacketType PT_CONTENT, and an
403   InterestReturn Packet has PacketType PT_RETURN.
404
405   HeaderLength is the number of octets from the start of the packet
406   (Version) to the end of the hop-by-hop headers.  PacketLength is the
407   number of octets from the start of the packet to the end of the
408   packet.
409
410   The PacketType specific fields are reserved bits whose use depends on
411   the PacketType.  They are used for network-level signaling.
412
4133.2.1.  Interest Fixed Header
414
415   If the PacketType in the Fixed Header is PT_INTEREST, it indicates
416   that the PacketPayload should be processed as an Interest message.
417   For this type of packet, the Fixed Header includes a field for a
418   HopLimit as well as Reserved and Flags fields.  The Reserved field
419   MUST be set to 0 in an Interest - this field will be set to a return
420   code in the case of an Interest Return.  There are currently no Flags
421   defined, so this field MUST be set to 0.
422
423                        1                   2                   3
424    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
425   +---------------+---------------+---------------+---------------+
426   |    Version    |  PT_INTEREST  |         PacketLength          |
427   +---------------+---------------+---------------+---------------+
428   |   HopLimit    |   Reserved    |     Flags     | HeaderLength  |
429   +---------------+---------------+---------------+---------------+
430
4313.2.1.1.  Interest HopLimit
432
433   For an Interest message, the HopLimit is a counter that is
434   decremented with each hop.  It limits the distance an Interest may
435   travel on the network.  The node originating the Interest MAY put in
436   any value - up to the maximum of 255.  Each node that receives an
437   Interest with a HopLimit decrements the value upon reception.  If the
438   value is 0 after the decrement, the Interest MUST NOT be forwarded
439   off the node.
440
441   It is an error to receive an Interest with a 0 hop-limit from a
442   remote node.
443
444
445
446
447
448Mosko, et al.           Expires September 8, 2018               [Page 8]
449
450Internet-Draft                  CCNx TLV                      March 2018
451
452
4533.2.2.  Content Object Fixed Header
454
455   If the PacketType in the Fixed Header is PT_CONTENT, it indicates
456   that the PacketPayload should be processed as a Content Object
457   message.  A Content Object defines a Flags field, however there are
458   currently no flags defined, so the Flags field must be set to 0.
459
460                        1                   2                   3
461    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
462   +---------------+---------------+---------------+---------------+
463   |    Version    |  PT_CONTENT   |         PacketLength          |
464   +---------------+---------------+---------------+---------------+
465   |            Reserved           |     Flags     | HeaderLength  |
466   +---------------+---------------+---------------+---------------+
467
4683.2.3.  InterestReturn Fixed Header
469
470   If the PacketType in the Fixed Header is PT_RETURN, it indicates that
471   the PacketPayload should be processed as a returned Interest message.
472   The only difference between this InterestReturn message and the
473   original Interest is that the PacketType is changed to PT_RETURN and
474   a ReturnCode is is put into the Reserved octet.  All other fields are
475   unchanged.  The purpose of this encoding is to prevent packet length
476   changes so no additional bytes are needed to return an Interest to
477   the previous hop.  See [CCNSemantics] for a protocol description of
478   this packet type.
479
480                        1                   2                   3
481    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
482   +---------------+---------------+---------------+---------------+
483   |    Version    |   PT_RETURN   |         PacketLength          |
484   +---------------+---------------+---------------+---------------+
485   |   HopLimit    |  ReturnCode   |     Flags     | HeaderLength  |
486   +---------------+---------------+---------------+---------------+
487
4883.2.3.1.  InterestReturn HopLimit
489
490   This is the original Interest's HopLimit, as received.  It is the
491   value before being decremented at the current node (i.e. the received
492   value).
493
4943.2.3.2.  InterestReturn Flags
495
496   These are the original Flags as set in the Interest.
497
498
499
500
501
502
503
504Mosko, et al.           Expires September 8, 2018               [Page 9]
505
506Internet-Draft                  CCNx TLV                      March 2018
507
508
5093.2.3.3.  Return Code
510
511   The numeric value assigned to the return types is defined below.
512   This value is set by the node creating the Interest Return.
513
514   A return code of "0" MUST NOT be used, as it indicates that the
515   returning system did not modify the Return Code field.
516
517   +-------------------------------------+-----------------------------+
518   |                 Type                | Return Type                 |
519   +-------------------------------------+-----------------------------+
520   |          T_RETURN_NO_ROUTE          | No Route                    |
521   |                                     |                             |
522   |       T_RETURN_LIMIT_EXCEEDED       | Hop Limit Exceeded          |
523   |                                     |                             |
524   |        T_RETURN_NO_RESOURCES        | No Resources                |
525   |                                     |                             |
526   |         T_RETURN_PATH_ERROR         | Path Error                  |
527   |                                     |                             |
528   |         T_RETURN_PROHIBITED         | Prohibited                  |
529   |                                     |                             |
530   |          T_RETURN_CONGESTED         | Congested                   |
531   |                                     |                             |
532   |        T_RETURN_MTU_TOO_LARGE       | MTU too large               |
533   |                                     |                             |
534   | T_RETURN_UNSUPPORTED_HASH_RESTRICTI | Unsupported ContentObjectHa |
535   |                  ON                 | shRestriction               |
536   |                                     |                             |
537   |     T_RETURN_MALFORMED_INTEREST     | Malformed Interest          |
538   +-------------------------------------+-----------------------------+
539
540                           Table 2: Return Codes
541
5423.3.  Global Formats
543
544   This section defines global formats that may be nested within other
545   TLVs.
546
5473.3.1.  Pad
548
549   The pad type may be used by protocols that prefer word-aligned data.
550   The size of the word may be defined by the protocol.  Padding 4-byte
551   words, for example, would use a 1-byte, 2-byte, and 3-byte Length.
552   Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, 7)-byte Length.
553
554   A pad MAY be inserted after any TLV in the CCNx Message or in the
555   Validation Dependent Data In the remainder of this document, we will
556   not show optional pad TLVs.
557
558
559
560Mosko, et al.           Expires September 8, 2018              [Page 10]
561
562Internet-Draft                  CCNx TLV                      March 2018
563
564
565                       1                   2                   3
566   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
567   +---------------+---------------+---------------+---------------+
568   |             T_PAD             |             Length            |
569   +---------------+---------------+---------------+---------------+
570   /                 variable length pad MUST be zeros             /
571   +---------------+---------------+---------------+---------------+
572
5733.3.2.  Organization Specific TLVs
574
575   Organization specific TLVs MUST use the T_ORG type.  The Length field
576   is the length of the organization specific information plus 3.  The
577   Value begins with the 3 byte organization number derived from the
578   last three digits of the IANA Private Enterprise Numbers
579   [EpriseNumbers], followed by the organization specific information.
580
581                       1                   2                   3
582   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
583   +---------------+---------------+---------------+---------------+
584   |             T_ORG             |     Length (3+value length)   |
585   +---------------+---------------+---------------+---------------+
586   |   PEN[0]      |    PEN[1]     |     PEN[2]    |               /
587   +---------------+---------------+---------------+               +
588   /                  Vendor Specific Value                        /
589   +---------------+---------------+---------------+---------------+
590
5913.3.3.  Hash Format
592
593   Hash values are used in several fields throughout a packet.  This TLV
594   encoding is commonly embedded inside those fields to specify the
595   specific hash function used and it's value.  Note that the reserved
596   TLV types are also reserved here for user-defined experimental
597   functions.
598
599   The LENGTH field of the hash value MUST be less than or equal to the
600   hash function length.  If the LENGTH is less than the full length, it
601   is taken as the left LENGTH bytes of the hash function output.  Only
602   the specified truncations are allowed.
603
604   This nested format is used because it allows binary comparison of
605   hash values for certain fields without a router needing to understand
606   a new hash function.  For example, the KeyIdRestriction is bit-wise
607   compared between an Interest's KeyIdRestriction field and a
608   ContentObject's KeyId field.  This format means the outer field
609   values do not change with differing hash functions so a router can
610   still identify those fields and do a binary comparison of the hash
611   TLV without need to understand the specific hash used.  An
612   alternative approach, such as using T_KEYID_SHA512-256, would require
613
614
615
616Mosko, et al.           Expires September 8, 2018              [Page 11]
617
618Internet-Draft                  CCNx TLV                      March 2018
619
620
621   each router keep an up-to-date parser and supporting user-defined
622   hash functions here would explode the parsing state-space.
623
624   A CCN entity MUST support the hash type T_SHA-256.  An entity MAY
625   support the remaining hash types.
626
627                  +-----------+------------------------+
628                  |   Abbrev  |    Lengths (octets)    |
629                  +-----------+------------------------+
630                  | T_SHA-256 |           32           |
631                  |           |                        |
632                  | T_SHA-512 |         64, 32         |
633                  |           |                        |
634                  |    n/a    | Experimental TLV types |
635                  +-----------+------------------------+
636
637                       Table 3: CCNx Hash Functions
638
639                       1                   2                   3
640   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
641   +---------------+---------------+---------------+---------------+
642   |             T_FOO             |              36               |
643   +---------------+---------------+---------------+---------------+
644   |           T_SHA512            |               32              |
645   +---------------+---------------+---------------+---------------+
646   /                        32-byte hash value                     /
647   +---------------+---------------+---------------+---------------+
648
649                     Example nesting inside type T_FOO
650
6513.3.4.  Link
652
653   A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}.
654   It is a general encoding that is used in both the payload of a
655   Content Object with PayloadType = "Link" and in the KeyLink field in
656   a KeyLocator.
657
658                       1                   2                   3
659   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
660   +---------------+---------------+-------------------------------+
661   / Mandatory CCNx Name                                           /
662   +---------------+---------------+-------------------------------+
663   / Optional KeyIdRestriction                                     /
664   +---------------------------------------------------------------+
665   / Optional ContentObjectHashRestriction                         /
666   +---------------------------------------------------------------+
667
668
669
670
671
672Mosko, et al.           Expires September 8, 2018              [Page 12]
673
674Internet-Draft                  CCNx TLV                      March 2018
675
676
6773.4.  Hop-by-hop TLV headers
678
679   Hop-by-hop TLV headers are unordered and meaning MUST NOT be attached
680   to their ordering.  Three hop-by-hop headers are described in this
681   document:
682
683   +-------------+-------------------+---------------------------------+
684   |    Abbrev   |        Name       | Description                     |
685   +-------------+-------------------+---------------------------------+
686   |  T_INTLIFE  | Interest Lifetime | The time an Interest should     |
687   |             |  (Section 3.4.1)  | stay pending at an intermediate |
688   |             |                   | node.                           |
689   |             |                   |                                 |
690   | T_CACHETIME | Recommended Cache | The Recommended Cache Time for  |
691   |             |   Time (Section   | Content Objects.                |
692   |             |       3.4.2)      |                                 |
693   |             |                   |                                 |
694   |  T_MSGHASH  |    Message Hash   | The hash of the CCNx Message to |
695   |             |  (Section 3.4.3)  | end of packet using Section     |
696   |             |                   | 3.3.3 format.                   |
697   +-------------+-------------------+---------------------------------+
698
699                     Table 4: Hop-by-hop Header Types
700
701   Additional hop-by-hop headers are defined in higher level
702   specifications such as the fragmentation specification.
703
7043.4.1.  Interest Lifetime
705
706   The Interest Lifetime is the time that an Interest should stay
707   pending at an intermediate node.  It is expressed in milliseconds as
708   an unsigned, network byte order integer.
709
710   A value of 0 (encoded as 1 byte %x00) indicates the Interest does not
711   elicit a Content Object response.  It should still be forwarded, but
712   no reply is expected.
713
714                        1                   2                   3
715    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
716   +---------------+---------------+---------------+---------------+
717   |          T_INTLIFE            |             Length            |
718   +---------------+---------------+---------------+---------------+
719   /                                                               /
720   /                      Lifetime (length octets)                 /
721   /                                                               /
722   +---------------+---------------+---------------+---------------+
723
724
725
726
727
728Mosko, et al.           Expires September 8, 2018              [Page 13]
729
730Internet-Draft                  CCNx TLV                      March 2018
731
732
7333.4.2.  Recommended Cache Time
734
735   The Recommended Cache Time (RCT) is a measure of the useful lifetime
736   of a Content Object as assigned by a content producer or upstream
737   node.  It serves as a guideline to the Content Store cache in
738   determining how long to keep the Content Object.  It is a
739   recommendation only and may be ignored by the cache.  This is in
740   contrast to the ExpiryTime (described in Section 3.6.2.2.2) which
741   takes precedence over the RCT and must be obeyed.
742
743   Because the Recommended Cache Time is an optional hop-by-hop header
744   and not a part of the signed message, a content producer may re-issue
745   a previously signed Content Object with an updated RCT without
746   needing to re-sign the message.  There is little ill effect from an
747   attacker changing the RCT as the RCT serves as a guideline only.
748
749   The Recommended Cache Time (a millisecond timestamp) is a network
750   byte ordered unsigned integer of the number of milliseconds since the
751   epoch in UTC of when the payload expires.  It is a 64-bit field.
752
753                        1                   2                   3
754    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
755   +---------------+---------------+---------------+---------------+
756   |         T_CACHETIME           |               8               |
757   +---------------+---------------+---------------+---------------+
758   /                                                               /
759   /                    Recommended Cache Time                     /
760   /                                                               /
761   +---------------+---------------+---------------+---------------+
762
7633.4.3.  Message Hash
764
765   Within a trusted domain, an operator may calculate the message hash
766   at a border device and insert that value into the hop-by-hop headers
767   of a message.  An egress device should remove the value.  This
768   permits intermediate devices within that trusted domain to match
769   against a ContentObjectHashRestriction without calculating it at
770   every hop.
771
772   The message hash is a cryptographic hash from the start of the CCNx
773   Message to the end of the packet.  It is used to match against the
774   ContentObjectHashRestriction (Section 3.6.2.1.2).  The Message Hash
775   may be of longer length than an Interest's restriction, in which case
776   the device should use the left bytes of the Message Hash to check
777   against the Interest's value.
778
779   The Message Hash may only carry one hash type and there may only be
780   one Message Hash header.
781
782
783
784Mosko, et al.           Expires September 8, 2018              [Page 14]
785
786Internet-Draft                  CCNx TLV                      March 2018
787
788
789   The Message Hash header is unprotected, so this header is only of
790   practical use within a trusted domain, such as an operator's
791   autonomous system.
792
793                       1                   2                   3
794   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
795   +---------------+---------------+---------------+---------------+
796   |          T_MSGHASH            |         (length + 4)          |
797   +---------------+---------------+---------------+---------------+
798   |         (hash type)           |            length             |
799   +---------------+---------------+---------------+---------------+
800   /                           hash value                          /
801   +---------------+---------------+---------------+---------------+
802
803                            Message Hash Header
804
8053.5.  Top-Level Types
806
807   The top-level TLV types listed below exist at the outermost level of
808   a CCNx protocol message.
809
810   +----------------------+-------------------+------------------------+
811   |        Abbrev        |        Name       | Description            |
812   +----------------------+-------------------+------------------------+
813   |      T_INTEREST      | Interest (Section | An Interest            |
814   |                      |        3.6)       | MessageType.           |
815   |                      |                   |                        |
816   |       T_OBJECT       |   Content Object  | A Content Object       |
817   |                      |   (Section 3.6)   | MessageType            |
818   |                      |                   |                        |
819   |   T_VALIDATION_ALG   |     Validation    | The method of message  |
820   |                      |     Algorithm     | verification such as   |
821   |                      | (Section 3.6.4.1) | Message Integrity      |
822   |                      |                   | Check (MIC), a Message |
823   |                      |                   | Authentication Code    |
824   |                      |                   | (MAC), or a            |
825   |                      |                   | cryptographic          |
826   |                      |                   | signature.             |
827   |                      |                   |                        |
828   | T_VALIDATION_PAYLOAD |     Validation    | The validation output, |
829   |                      |  Payload (Section | such as the CRC32C     |
830   |                      |      3.6.4.2)     | code or the RSA        |
831   |                      |                   | signature.             |
832   +----------------------+-------------------+------------------------+
833
834                       Table 5: CCNx Top Level Types
835
836
837
838
839
840Mosko, et al.           Expires September 8, 2018              [Page 15]
841
842Internet-Draft                  CCNx TLV                      March 2018
843
844
8453.6.  CCNx Message
846
847   This is the format for the CCNx protocol message itself.  The CCNx
848   message is the portion of the packet between the hop-by-hop headers
849   and the Validation TLVs.  The figure below is an expansion of the
850   "CCNx Message TLV" depicted in the beginning of Section 3.  The CCNx
851   message begins with MessageType and runs through the optional
852   Payload.  The same general format is used for both Interest and
853   Content Object messages which are differentiated by the MessageType
854   field.  The first enclosed TLV of a CCNx Message is always the Name
855   TLV.  This is followed by an optional Message TLVs and an optional
856   Payload TLV.
857
858                        1                   2                   3
859    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
860   +---------------+---------------+---------------+---------------+
861   |         MessageType           |         MessageLength         |
862   +---------------+---------------+---------------+---------------+
863   | Name TLV       (Type = T_NAME)                                |
864   +---------------+---------------+---------------+---------------+
865   / Optional Message TLVs   (Various Types)                       /
866   +---------------+---------------+---------------+---------------+
867   / Optional Payload TLV  (Type = T_PAYLOAD)                      /
868   +---------------+---------------+---------------+---------------+
869
870
871   +-----------+-----------------+-------------------------------------+
872   |   Abbrev  |       Name      | Description                         |
873   +-----------+-----------------+-------------------------------------+
874   |   T_NAME  |  Name (Section  | The CCNx Name requested in an       |
875   |           |      3.6.1)     | Interest or published in a Content  |
876   |           |                 | Object.                             |
877   |           |                 |                                     |
878   | T_PAYLOAD |     Payload     | The message payload.                |
879   |           | (Section 3.6.3) |                                     |
880   +-----------+-----------------+-------------------------------------+
881
882                        Table 6: CCNx Message Types
883
8843.6.1.  Name
885
886   A Name is a TLV encoded sequence of segments.  The table below lists
887   the type values appropriate for these Name segments.  A Name MUST NOT
888   include PAD TLVs.
889
890   As described in CCNx Semantics [CCNSemantics], using the CCNx URI
891   [CCNxURI] notation, a T_NAME with 0 length corresponds to ccnx:/ (the
892   default route) and is distinct from a name with one zero length
893
894
895
896Mosko, et al.           Expires September 8, 2018              [Page 16]
897
898Internet-Draft                  CCNx TLV                      March 2018
899
900
901   segment, such as ccnx:/NAME=.  In the TLV encoding, ccnx:/
902   corresponds to T_NAME with 0 length, while ccnx:/NAME= corresponds to
903   T_NAME with 4 length and T_NAMESEGMENT with 0 length.
904
905                        1                   2                   3
906    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
907   +---------------+---------------+---------------+---------------+
908   |            T_NAME             |            Length             |
909   +---------------+---------------+---------------+---------------+
910   / Name segment TLVs                                             /
911   +---------------+---------------+---------------+---------------+
912
913   +---------------+-------------------+-------------------------------+
914   | Symbolic Name |        Name       | Description                   |
915   +---------------+-------------------+-------------------------------+
916   | T_NAMESEGMENT |    Name segment   | A generic name Segment.       |
917   |               | (Section 3.6.1.1) |                               |
918   |               |                   |                               |
919   |     T_IPID    |  Interest Payload | An identifier that represents |
920   |               |    ID (Section    | the Interest Payload field.   |
921   |               |      3.6.1.2)     | As an example, the Payload ID |
922   |               |                   | might be a hash of the        |
923   |               |                   | Interest Payload.  This       |
924   |               |                   | provides a way to             |
925   |               |                   | differentiate between         |
926   |               |                   | Interests based on their      |
927   |               |                   | payloads without having to    |
928   |               |                   | parse all the bytes of the    |
929   |               |                   | payload itself; instead using |
930   |               |                   | only this Payload ID Name     |
931   |               |                   | segment.                      |
932   |               |                   |                               |
933   |   T_APP:00 -  |    Application    | Application-specific payload  |
934   |   T_APP:4096  |     Components    | in a name segment.  An        |
935   |               | (Section 3.6.1.1) | application may apply its own |
936   |               |                   | semantics to the 4096         |
937   |               |                   | reserved types.               |
938   +---------------+-------------------+-------------------------------+
939
940                         Table 7: CCNx Name Types
941
9423.6.1.1.  Name Segments
943
944   4096 special application payload name segments are allocated.  These
945   have application semantics applied to them.  A good convention is to
946   put the application's identity in the name prior to using these name
947   segments.
948
949
950
951
952Mosko, et al.           Expires September 8, 2018              [Page 17]
953
954Internet-Draft                  CCNx TLV                      March 2018
955
956
957   For example, a name like "ccnx:/foo/bar/hi" would be encoded as:
958
959                        1                   2                   3
960    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
961   +---------------+---------------+---------------+---------------+
962   |            (T_NAME)           |           %x14 (20)           |
963   +---------------+---------------+---------------+---------------+
964   |        (T_NAME_SEGMENT)       |           %x03 (3)            |
965   +---------------+---------------+---------------+---------------+
966   |       f                o               o      |(T_NAME_SEGMENT)
967   +---------------+---------------+---------------+---------------+
968   |               |            %x03 (3)           |       b       |
969   +---------------+---------------+---------------+---------------+
970   |      a                r       |           (T_NAME_SEGMENT)    |
971   +---------------+---------------+---------------+---------------+
972   |           %x02 (2)            |       h       |       i       |
973   +---------------+---------------+---------------+---------------+
974
9753.6.1.2.  Interest Payload ID
976
977   The InterestPayloadID is a name segment created by the origin of an
978   Interest to represent the Interest Payload.  This allows the proper
979   multiplexing of Interests based on their name if they have different
980   payloads.  A common representation is to use a hash of the Interest
981   Payload as the InterestPayloadID.
982
983   As part of the TLV 'value', the InterestPayloadID contains a one
984   identifier of method used to create the InterestPayloadID followed by
985   a variable length octet string.  An implementation is not required to
986   implement any of the methods to receive an Interest; the
987   InterestPayloadID may be treated only as an opaque octet string for
988   purposes of multiplexing Interests with different payloads.  Only a
989   device creating an InterestPayloadID name segment or a device
990   verifying such a segment need to implement the algorithms.
991
992   It uses the Section 3.3.3 encoding of hash values.
993
994   In normal operations, we recommend displaying the InterestPayloadID
995   as an opaque octet string in a CCNx URI, as this is the common
996   denominator for implementation parsing.
997
998   The InterestPayloadID, even if it is a hash, should not convey any
999   security context.  If a system requires confirmation that a specific
1000   entity created the InterestPayload, it should use a cryptographic
1001   signature on the Interest via the ValidationAlgorithm and
1002   ValidationPayload or use its own methods inside the Interest Payload.
1003
1004
1005
1006
1007
1008Mosko, et al.           Expires September 8, 2018              [Page 18]
1009
1010Internet-Draft                  CCNx TLV                      March 2018
1011
1012
10133.6.2.  Message TLVs
1014
1015   Each message type (Interest or Content Object) is associated with a
1016   set of optional Message TLVs.  Additional specification documents may
1017   extend the types associated with each.
1018
10193.6.2.1.  Interest Message TLVs
1020
1021   There are two Message TLVs currently associated with an Interest
1022   message: the KeyIdRestriction selector and the ContentObjectHashRestr
1023   selector are used to narrow the universe of acceptable Content
1024   Objects that would satisfy the Interest.
1025
1026                        1                   2                   3
1027    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
1028   +---------------+---------------+---------------+---------------+
1029   |         MessageType           |         MessageLength         |
1030   +---------------+---------------+---------------+---------------+
1031   | Name TLV                                                      |
1032   +---------------+---------------+---------------+---------------+
1033   / Optional KeyIdRestriction TLV                                 /
1034   +---------------------------------------------------------------+
1035   / Optional ContentObjectHashRestriction TLV                     /
1036   +---------------------------------------------------------------+
1037
1038   +----------------+------------------------------+-------------------+
1039   |     Abbrev     |             Name             | Description       |
1040   +----------------+------------------------------+-------------------+
1041   |  T_KEYIDRESTR  |  KeyIdRestriction (Section   | A Section 3.3.3   |
1042   |                |          3.6.2.1.1)          | representation of |
1043   |                |                              | the KeyId         |
1044   |                |                              |                   |
1045   | T_OBJHASHRESTR | ContentObjectHashRestriction | A Section 3.3.3   |
1046   |                |     (Section 3.6.2.1.2)      | representation of |
1047   |                |                              | the hash of the   |
1048   |                |                              | specific Content  |
1049   |                |                              | Object that would |
1050   |                |                              | satisfy the       |
1051   |                |                              | Interest.         |
1052   +----------------+------------------------------+-------------------+
1053
1054                 Table 8: CCNx Interest Message TLV Types
1055
10563.6.2.1.1.  KeyIdRestriction
1057
1058   An Interest MAY include a KeyIdRestriction selector.  This ensures
1059   that only Content Objects with matching KeyIds will satisfy the
1060   Interest.  See Section 3.6.4.1.4.1 for the format of a KeyId.
1061
1062
1063
1064Mosko, et al.           Expires September 8, 2018              [Page 19]
1065
1066Internet-Draft                  CCNx TLV                      March 2018
1067
1068
10693.6.2.1.2.  ContentObjectHashRestriction
1070
1071   An Interest MAY contain a ContentObjectHashRestriction selector.
1072   This is the hash of the Content Object - the self-certifying name
1073   restriction that must be verified in the network, if an Interest
1074   carried this restriction.  It is calculated from the beginning of the
1075   CCNx Message to the end of the packet.  The LENGTH MUST be from one
1076   of the allowed values for that hash (see Section 3.3.3).
1077
1078   The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of
1079   length 32 bytes.
1080
1081                        1                   2                   3
1082    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
1083   +---------------+---------------+---------------+---------------+
1084   |        T_OBJHASHRESTR         |            LENGTH+4           |
1085   +---------------+---------------+---------------+---------------+
1086   |          <hash type>          |             LENGTH            |
1087   +---------------+---------------+---------------+---------------+
1088   /                     LENGTH octets of hash                     /
1089   +---------------+---------------+---------------+---------------+
1090
10913.6.2.2.  Content Object Message TLVs
1092
1093   The following message TLVs are currently defined for Content Objects:
1094   PayloadType (optional) and ExpiryTime (optional).
1095
1096                         1                   2                   3
1097    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
1098   +---------------+---------------+---------------+---------------+
1099   |         MessageType           |         MessageLength         |
1100   +---------------+---------------+---------------+---------------+
1101   | Name TLV                                                      |
1102   +---------------+---------------+---------------+---------------+
1103   / Optional PayloadType TLV                                      /
1104   +---------------------------------------------------------------+
1105   / Optional ExpiryTime TLV                                       /
1106   +---------------------------------------------------------------+
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120Mosko, et al.           Expires September 8, 2018              [Page 20]
1121
1122Internet-Draft                  CCNx TLV                      March 2018
1123
1124
1125   +-------------+---------------------+-------------------------------+
1126   |    Abbrev   |         Name        | Description                   |
1127   +-------------+---------------------+-------------------------------+
1128   | T_PAYLDTYPE |     PayloadType     | Indicates the type of Payload |
1129   |             | (Section 3.6.2.2.1) | contents.                     |
1130   |             |                     |                               |
1131   |   T_EXPIRY  | ExpiryTime (Section | The time at which the Payload |
1132   |             |      3.6.2.2.2)     | expires, as expressed in the  |
1133   |             |                     | number of milliseconds since  |
1134   |             |                     | the epoch in UTC.  If         |
1135   |             |                     | missing, Content Object may   |
1136   |             |                     | be used as long as desired.   |
1137   +-------------+---------------------+-------------------------------+
1138
1139              Table 9: CCNx Content Object Message TLV Types
1140
11413.6.2.2.1.  PayloadType
1142
1143   The PayloadType is a network byte order integer representing the
1144   general type of the Payload TLV.
1145
1146   o  T_PAYLOADTYPE_DATA: Data (possibly encrypted)
1147
1148   o  T_PAYLOADTYPE_KEY: Key
1149
1150   o  T_PAYLOADTYPE_LINK: Link
1151
1152   The Data type indicate that the Payload of the ContentObject is
1153   opaque application bytes.  The Key type indicates that the Payload is
1154   a DER encoded public key.  The Link type indicates that the Payload
1155   is one or more Link (Section 3.3.4).  If this field is missing, a
1156   "Data" type is assumed.
1157
1158                        1                   2                   3
1159    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
1160   +---------------+---------------+---------------+---------------+
1161   |            T_PAYLDTYPE        |            Length             |
1162   +---------------+---------------+---------------+---------------+
1163   |  PayloadType  /
1164   +---------------+
1165
11663.6.2.2.2.  ExpiryTime
1167
1168   The ExpiryTime is the time at which the Payload expires, as expressed
1169   by a timestamp containing the number of milliseconds since the epoch
1170   in UTC.  It is a network byte order unsigned integer in a 64-bit
1171   field.  A cache or end system should not respond with a Content
1172   Object past its ExpiryTime.  Routers forwarding a Content Object do
1173
1174
1175
1176Mosko, et al.           Expires September 8, 2018              [Page 21]
1177
1178Internet-Draft                  CCNx TLV                      March 2018
1179
1180
1181   not need to check the ExpiryTime.  If the ExpiryTime field is
1182   missing, the Content Object has no expressed expiration and a cache
1183   or end system may use the Content Object for as long as desired.
1184
1185                        1                   2                   3
1186    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
1187   +---------------+---------------+---------------+---------------+
1188   |           T_EXPIRY            |               8               |
1189   +---------------+---------------+---------------+---------------+
1190   /                          ExpiryTime                           /
1191   /                                                               /
1192   +---------------+---------------+---------------+---------------+
1193
11943.6.3.  Payload
1195
1196   The Payload TLV contains the content of the packet.  It MAY be of
1197   zero length.  If a packet does not have any payload, this field MAY
1198   be omitted, rather than carrying a zero length.
1199
1200                        1                   2                   3
1201    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
1202   +---------------+---------------+---------------+---------------+
1203   |           T_PAYLOAD           |            Length             |
1204   +---------------+---------------+---------------+---------------+
1205   /                        Payload Contents                       /
1206   +---------------+---------------+---------------+---------------+
1207
12083.6.4.  Validation
1209
1210   Both Interests and Content Objects have the option to include
1211   information about how to validate the CCNx message.  This information
1212   is contained in two TLVs: the ValidationAlgorithm TLV and the
1213   ValidationPayload TLV.  The ValidationAlgorithm TLV specifies the
1214   mechanism to be used to verify the CCNx message.  Examples include
1215   verification with a Message Integrity Check (MIC), a Message
1216   Authentication Code (MAC), or a cryptographic signature.  The
1217   ValidationPayload TLV contains the validation output, such as the
1218   CRC32C code or the RSA signature.
1219
1220   An Interest would most likely only use a MIC type of validation - a
1221   crc, checksum, or digest.
1222
12233.6.4.1.  Validation Algorithm
1224
1225   The ValidationAlgorithm is a set of nested TLVs containing all of the
1226   information needed to verify the message.  The outermost container
1227   has type = T_VALIDATION_ALG.  The first nested TLV defines the
1228   specific type of validation to be performed on the message.  The type
1229
1230
1231
1232Mosko, et al.           Expires September 8, 2018              [Page 22]
1233
1234Internet-Draft                  CCNx TLV                      March 2018
1235
1236
1237   is identified with the "ValidationType" as shown in the figure below
1238   and elaborated in the table below.  Nested within that container are
1239   the TLVs for any ValidationType dependent data, for example a Key Id,
1240   Key Locator etc.
1241
1242   Complete examples of several types may be found in Section 3.6.4.1.5
1243
1244                        1                   2                   3
1245    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
1246   +---------------+---------------+---------------+---------------+
1247   |       T_VALIDATION_ALG        |      ValidationAlgLength      |
1248   +---------------+---------------+---------------+---------------+
1249   |        ValidationType         |            Length             |
1250   +---------------+---------------+---------------+---------------+
1251   / ValidationType dependent data                                 /
1252   +---------------+---------------+---------------+---------------+
1253
1254   +---------------+---------------------+-----------------------------+
1255   |     Abbrev    |         Name        | Description                 |
1256   +---------------+---------------------+-----------------------------+
1257   |    T_CRC32C   |   CRC32C (Section   | Castagnoli CRC32 (iSCSI,    |
1258   |               |      3.6.4.1.1)     | ext4, etc.), with normal    |
1259   |               |                     | form polynomial 0x1EDC6F41. |
1260   |               |                     |                             |
1261   | T_HMAC-SHA256 |     HMAC-SHA256     | HMAC (RFC 2104) using       |
1262   |               | (Section 3.6.4.1.2) | SHA256 hash.                |
1263   |               |                     |                             |
1264   |  T_RSA-SHA256 | RSA-SHA256 (Section | RSA public key signature    |
1265   |               |      3.6.4.1.3)     | using SHA256 digest.        |
1266   |               |                     |                             |
1267   | EC-SECP-256K1 | SECP-256K1 (Section | Elliptic Curve signature    |
1268   |               |      3.6.4.1.3)     | with SECP-256K1 parameters  |
1269   |               |                     | (see [ECC]).                |
1270   |               |                     |                             |
1271   | EC-SECP-384R1 | SECP-384R1 (Section | Elliptic Curve signature    |
1272   |               |      3.6.4.1.3)     | with SECP-384R1 parameters  |
1273   |               |                     | (see [ECC]).                |
1274   +---------------+---------------------+-----------------------------+
1275
1276                      Table 10: CCNx Validation Types
1277
12783.6.4.1.1.  Message Integrity Checks
1279
1280   MICs do not require additional data in order to perform the
1281   verification.  An example is CRC32C that has a "0" length value.
1282
1283
1284
1285
1286
1287
1288Mosko, et al.           Expires September 8, 2018              [Page 23]
1289
1290Internet-Draft                  CCNx TLV                      March 2018
1291
1292
12933.6.4.1.2.  Message Authentication Checks
1294
1295   MACs are useful for communication between two trusting parties who
1296   have already shared private keys.  Examples include an RSA signature
1297   of a SHA256 digest or others.  They rely on a KeyId.  Some MACs might
1298   use more than a KeyId, but those would be defined in the future.
1299
13003.6.4.1.3.  Signature
1301
1302   Signature type Validators specify a digest mechanism and a signing
1303   algorithm to verify the message.  Examples include RSA signature og a
1304   SHA256 digest, an Elliptic Curve signature with SECP-256K1
1305   parameters, etc.  These Validators require a KeyId and a mechanism
1306   for locating the publishers public key (a KeyLocator) - optionally a
1307   PublicKey or Certificate or KeyLink.
1308
13093.6.4.1.4.  Validation Dependent Data
1310
1311   Different Validation Algorithms require access to different pieces of
1312   data contained in the ValidationAlgorithm TLV.  As described above,
1313   Key Ids, Key Locators, Public Keys, Certificates, Links and Key Names
1314   all play a role in different Validation Algorithms.  Any number of
1315   Validation Dependent Data containers can be present in a Validation
1316   Algorithm TLV.
1317
1318   Following is a table of CCNx ValidationType dependent data types:
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344Mosko, et al.           Expires September 8, 2018              [Page 24]
1345
1346Internet-Draft                  CCNx TLV                      March 2018
1347
1348
1349   +-------------+-----------------------+-----------------------------+
1350   |    Abbrev   |          Name         | Description                 |
1351   +-------------+-----------------------+-----------------------------+
1352   |   T_KEYID   |  SignerKeyId (Section | An identifier of the shared |
1353   |             |      3.6.4.1.4.1)     | secret or public key        |
1354   |             |                       | associated with a MAC or    |
1355   |             |                       | Signature.                  |
1356   |             |                       |                             |
1357   | T_PUBLICKEY |  Public Key (Section  | DER encoded public key.     |
1358   |             |      3.6.4.1.4.2)     |                             |
1359   |             |                       |                             |
1360   |    T_CERT   |  Certificate (Section | DER encoded X509            |
1361   |             |      3.6.4.1.4.3)     | certificate.                |
1362   |             |                       |                             |
1363   |  T_KEYLINK  |    KeyLink (Section   | A CCNx Link object.         |
1364   |             |      3.6.4.1.4.4)     |                             |
1365   |             |                       |                             |
1366   |  T_SIGTIME  |     SignatureTime     | A millsecond timestamp      |
1367   |             | (Section 3.6.4.1.4.5) | indicating the time when    |
1368   |             |                       | the signature was created.  |
1369   +-------------+-----------------------+-----------------------------+
1370
1371              Table 11: CCNx Validation Dependent Data Types
1372
13733.6.4.1.4.1.  KeyId
1374
1375   The KeyId is the publisher key identifier.  It is similar to a
1376   Subject Key Identifier from X509 [RFC 5280, Section 4.2.1.2].  It
1377   should be derived from the key used to sign, such as from the SHA-256
1378   hash of the key.  It applies to both public/private key systems and
1379   to symmetric key systems.
1380
1381   The KeyId is represented using the Section 3.3.3.  If a protocol uses
1382   a non-hash identifier, it should use one of the reserved values.
1383
1384                        1                   2                   3
1385    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
1386   +---------------+---------------+---------------+---------------+
1387   |            T_KEYID            |            LENGTH+4           |
1388   +---------------+---------------+---------------+---------------+
1389   |          <hash type>          |             LENGTH            |
1390   +---------------+---------------+---------------+---------------+
1391   /                     LENGTH octets of hash                     /
1392   +---------------+---------------+---------------+---------------+
1393
1394
1395
1396
1397
1398
1399
1400Mosko, et al.           Expires September 8, 2018              [Page 25]
1401
1402Internet-Draft                  CCNx TLV                      March 2018
1403
1404
14053.6.4.1.4.2.  Public Key
1406
1407   A Public Key is a DER encoded Subject Public Key Info block, as in an
1408   X509 certificate.
1409
1410                        1
1411    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1412   +---------------+---------------+---------------+---------------+
1413   |          T_PUBLICKEY          |            Length             |
1414   +---------------+---------------+---------------+---------------+
1415   /                Public Key (DER encoded SPKI)                  /
1416   +---------------+---------------+---------------+---------------+
1417
14183.6.4.1.4.3.  Certificate
1419
1420                        1                   2                   3
1421    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
1422   +---------------+---------------+---------------+---------------+
1423   |            T_CERT             |            Length             |
1424   +---------------+---------------+---------------+---------------+
1425   /                 Certificate (DER encoded X509)                /
1426   +---------------+---------------+---------------+---------------+
1427
14283.6.4.1.4.4.  KeyLink
1429
1430   A KeyLink type KeyLocator is a Link.
1431
1432   The KeyLink ContentObjectHashRestr, if included, is the digest of the
1433   Content Object identified by KeyLink, not the digest of the public
1434   key.  Likewise, the KeyIdRestr of the KeyLink is the KeyId of the
1435   ContentObject, not necessarily of the wrapped key.
1436
1437                        1                   2                   3
1438    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
1439   +---------------+---------------+-------------------------------+
1440   |          T_KEYKINK            |            Length             |
1441   +---------------+---------------+-------------------------------+
1442   / Link                                                          /
1443   +---------------------------------------------------------------+
1444
14453.6.4.1.4.5.  SignatureTime
1446
1447   The SignatureTime is a millisecond timestamp indicating the time at
1448   which a signature was created.  The signer sets this field to the
1449   current time when creating a signature.  A verifier may use this time
1450   to determine whether or not the signature was created during the
1451   validity period of a key, or if it occurred in a reasonable sequence
1452   with other associated signatures.  The SignatureTime is unrelated to
1453
1454
1455
1456Mosko, et al.           Expires September 8, 2018              [Page 26]
1457
1458Internet-Draft                  CCNx TLV                      March 2018
1459
1460
1461   any time associated with the actual CCNx Message, which could have
1462   been created long before the signature.  The default behavior is to
1463   always include a SignatureTime when creating an authenticated message
1464   (e.g.  HMAC or RSA).
1465
1466   SignatureTime is a network byte ordered unsigned integer of the
1467   number of milliseconds since the epoch in UTC of when the signature
1468   was created.  It is a fixed 64-bit field.
1469
1470                        1                   2                   3
1471    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
1472   +---------------+---------------+-------------------------------+
1473   |           T_SIGTIME           |               8               |
1474   +---------------+---------------+-------------------------------+
1475   /                         SignatureTime                         /
1476   +---------------------------------------------------------------+
1477
14783.6.4.1.5.  Validation Examples
1479
1480   As an example of a MIC type validation, the encoding for CRC32C
1481   validation would be:
1482
1483                        1                   2                   3
1484    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
1485   +---------------+---------------+---------------+---------------+
1486   |      T_VALIDATION_ALG         |               4               |
1487   +---------------+---------------+---------------+---------------+
1488   |            T_CRC32C           |               0               |
1489   +---------------+---------------+---------------+---------------+
1490
1491   As an example of a MAC type validation, the encoding for an HMAC
1492   using a SHA256 hash would be:
1493
1494                        1                   2                   3
1495    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
1496   +---------------+---------------+---------------+---------------+
1497   |       T_VALIDATION_ALG        |               40              |
1498   +---------------+---------------+---------------+---------------+
1499   |        T_HMAC-SHA256          |               36              |
1500   +---------------+---------------+---------------+---------------+
1501   |             T_KEYID           |               32              |
1502   +---------------+---------------+---------------+---------------+
1503   /                            KeyId                              /
1504   /---------------+---------------+-------------------------------+
1505
1506   As an example of a Signature type validation, the encoding for an RSA
1507   public key signing using a SHA256 digest and Public Key would be:
1508
1509
1510
1511
1512Mosko, et al.           Expires September 8, 2018              [Page 27]
1513
1514Internet-Draft                  CCNx TLV                      March 2018
1515
1516
1517                        1                   2                   3
1518    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
1519   +---------------+---------------+---------------+---------------+
1520   |       T_VALIDATION_ALG        |      44 + Variable Length     |
1521   +---------------+---------------+---------------+---------------+
1522   |          T_RSA-SHA256         |      40 + Variable Length     |
1523   +---------------+---------------+---------------+---------------+
1524   |             T_KEYID           |               32              |
1525   +---------------+---------------+---------------+---------------+
1526   /                            KeyId                              /
1527   /---------------+---------------+-------------------------------+
1528   |          T_PUBLICKEY          |   Variable Length (~ 160)     |
1529   +---------------+---------------+---------------+---------------+
1530   /                Public Key (DER encoded SPKI)                  /
1531   +---------------+---------------+---------------+---------------+
1532
15333.6.4.2.  Validation Payload
1534
1535                        1                   2                   3
1536    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
1537   +---------------+---------------+---------------+---------------+
1538   |     T_VALIDATION_PAYLOAD      |  ValidationPayloadLength      |
1539   +---------------+---------------+---------------+---------------+
1540   / Type-dependent data                                           /
1541   +---------------+---------------+---------------+---------------+
1542
1543   The ValidationPayload contains the validation output, such as the
1544   CRC32C code or the RSA signature.
1545
15464.  IANA Considerations
1547
1548   This section details each kind of protocol value that can be
1549   registered.  Each type registry can be updated by incrementally
1550   expanding the type space, i.e., by allocating and reserving new
1551   types.  As per [RFC5226] this section details the creation of the
1552   "CCNx Registry" and several sub-registries.
1553
1554                       +----------+---------------+
1555                       | Property | Value         |
1556                       +----------+---------------+
1557                       | Name     | CCNx Registry |
1558                       |          |               |
1559                       | Abbrev   | CCNx          |
1560                       +----------+---------------+
1561
1562                             Registry Creation
1563
1564
1565
1566
1567
1568Mosko, et al.           Expires September 8, 2018              [Page 28]
1569
1570Internet-Draft                  CCNx TLV                      March 2018
1571
1572
15734.1.  Packet Type Registry
1574
1575   The following packet types should be allocated.  A PacketType MUST be
1576   1 byte.  New packet types are allocated via "RFC Required" action.
1577
1578                 +----------------+----------------------+
1579                 | Property       | Value                |
1580                 +----------------+----------------------+
1581                 | Name           | Packet Type Registry |
1582                 |                |                      |
1583                 | Parent         | CCNx Registry        |
1584                 |                |                      |
1585                 | Review process | RFC Required         |
1586                 |                |                      |
1587                 | Syntax         | 1 octet (decimal)    |
1588                 +----------------+----------------------+
1589
1590                             Registry Creation
1591
1592         +------+-------------+----------------------------------+
1593         | Type |     Name    |            Reference             |
1594         +------+-------------+----------------------------------+
1595         |  0   | PT_INTEREST | Fixed Header Types (Section 3.2) |
1596         |      |             |                                  |
1597         |  1   |  PT_CONTENT | Fixed Header Types (Section 3.2) |
1598         |      |             |                                  |
1599         |  2   |  PT_RETURN  | Fixed Header Types (Section 3.2) |
1600         +------+-------------+----------------------------------+
1601
1602                           Packet Type Namespace
1603
16044.2.  Interest Return Code Registry
1605
1606   The following InterestReturn code types should be allocated.
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624Mosko, et al.           Expires September 8, 2018              [Page 29]
1625
1626Internet-Draft                  CCNx TLV                      March 2018
1627
1628
1629   +--------------+----------------------------------------------------+
1630   | Property     | Value                                              |
1631   +--------------+----------------------------------------------------+
1632   | Name         | Interest Return Code                               |
1633   |              |                                                    |
1634   | Parent       | CCNx Registry                                      |
1635   |              |                                                    |
1636   | Review       | Expert Review, should include public standard      |
1637   | process      | leading to RFC.                                    |
1638   |              |                                                    |
1639   | Syntax       | 1 octet (decimal)                                  |
1640   +--------------+----------------------------------------------------+
1641
1642                             Registry Creation
1643
1644   +------+---------------------------------------+--------------------+
1645   | Type |                  Name                 |     Reference      |
1646   +------+---------------------------------------+--------------------+
1647   |  1   |           T_RETURN_NO_ROUTE           | Fixed Header Types |
1648   |      |                                       | (Section 3.2.3.3)  |
1649   |      |                                       |                    |
1650   |  2   |        T_RETURN_LIMIT_EXCEEDED        | Fixed Header Types |
1651   |      |                                       | (Section 3.2.3.3)  |
1652   |      |                                       |                    |
1653   |  3   |         T_RETURN_NO_RESOURCES         | Fixed Header Types |
1654   |      |                                       | (Section 3.2.3.3)  |
1655   |      |                                       |                    |
1656   |  4   |          T_RETURN_PATH_ERROR          | Fixed Header Types |
1657   |      |                                       | (Section 3.2.3.3)  |
1658   |      |                                       |                    |
1659   |  5   |          T_RETURN_PROHIBITED          | Fixed Header Types |
1660   |      |                                       | (Section 3.2.3.3)  |
1661   |      |                                       |                    |
1662   |  6   |           T_RETURN_CONGESTED          | Fixed Header Types |
1663   |      |                                       | (Section 3.2.3.3)  |
1664   |      |                                       |                    |
1665   |  7   |         T_RETURN_MTU_TOO_LARGE        | Fixed Header Types |
1666   |      |                                       | (Section 3.2.3.3)  |
1667   |      |                                       |                    |
1668   |  8   | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types |
1669   |      |                                       | (Section 3.2.3.3)  |
1670   |      |                                       |                    |
1671   |  9   |      T_RETURN_MALFORMED_INTEREST      | Fixed Header Types |
1672   |      |                                       | (Section 3.2.3.3)  |
1673   +------+---------------------------------------+--------------------+
1674
1675                      Interest Return Type Namespace
1676
1677
1678
1679
1680Mosko, et al.           Expires September 8, 2018              [Page 30]
1681
1682Internet-Draft                  CCNx TLV                      March 2018
1683
1684
16854.3.  Hop-by-Hop Type Registry
1686
1687   The following hop-by-hop types should be allocated.
1688
1689              +----------------+----------------------------+
1690              | Property       | Value                      |
1691              +----------------+----------------------------+
1692              | Name           | Hop-by-Hop Type Registry   |
1693              |                |                            |
1694              | Parent         | CCNx Registry              |
1695              |                |                            |
1696              | Review process | RFC Required               |
1697              |                |                            |
1698              | Syntax         | 2 octet TLV type (decimal) |
1699              +----------------+----------------------------+
1700
1701                             Registry Creation
1702
1703   +---------------+-------------+-------------------------------------+
1704   |      Type     |     Name    |              Reference              |
1705   +---------------+-------------+-------------------------------------+
1706   |       1       |  T_INTLIFE  |   Hop-by-hop TLV headers (Section   |
1707   |               |             |                 3.4)                |
1708   |               |             |                                     |
1709   |       2       | T_CACHETIME |   Hop-by-hop TLV headers (Section   |
1710   |               |             |                 3.4)                |
1711   |               |             |                                     |
1712   |       3       |  T_MSGHASH  |   Hop-by-hop TLV headers (Section   |
1713   |               |             |                 3.4)                |
1714   |               |             |                                     |
1715   |     4 - 7     |   Reserved  |                                     |
1716   |               |             |                                     |
1717   |     %x0FFE    |    T_PAD    |         Pad (Section 3.3.1)         |
1718   |               |             |                                     |
1719   |     %x0FFF    |    T_ORG    | Organization-Specific TLVs (Section |
1720   |               |             |                3.3.2)               |
1721   |               |             |                                     |
1722   | %x1000-%x1FFF |   Reserved  |     Experimental Use (Section 3)    |
1723   +---------------+-------------+-------------------------------------+
1724
1725                         Hop-by-Hop Type Namespace
1726
17274.4.  Top-Level Type Registry
1728
1729   The following top-level types should be allocated.
1730
1731
1732
1733
1734
1735
1736Mosko, et al.           Expires September 8, 2018              [Page 31]
1737
1738Internet-Draft                  CCNx TLV                      March 2018
1739
1740
1741              +----------------+----------------------------+
1742              | Property       | Value                      |
1743              +----------------+----------------------------+
1744              | Name           | Top-Level Type Registry    |
1745              |                |                            |
1746              | Parent         | CCNx Registry              |
1747              |                |                            |
1748              | Review process | RFC Required               |
1749              |                |                            |
1750              | Syntax         | 2 octet TLV type (decimal) |
1751              +----------------+----------------------------+
1752
1753                             Registry Creation
1754
1755      +------+----------------------+-------------------------------+
1756      | Type |         Name         |           Reference           |
1757      +------+----------------------+-------------------------------+
1758      |  1   |      T_INTEREST      | Top-Level Types (Section 3.5) |
1759      |      |                      |                               |
1760      |  2   |       T_OBJECT       | Top-Level Types (Section 3.5) |
1761      |      |                      |                               |
1762      |  3   |   T_VALIDATION_ALG   | Top-Level Types (Section 3.5) |
1763      |      |                      |                               |
1764      |  4   | T_VALIDATION_PAYLOAD | Top-Level Types (Section 3.5) |
1765      +------+----------------------+-------------------------------+
1766
1767                         Top-Level Type Namespace
1768
17694.5.  Name Segment Type Registry
1770
1771   The following name segment types should be allocated.
1772
1773       +----------------+-----------------------------------------+
1774       | Property       | Value                                   |
1775       +----------------+-----------------------------------------+
1776       | Name           | Name Segment Type Registry              |
1777       |                |                                         |
1778       | Parent         | CCNx Registry                           |
1779       |                |                                         |
1780       | Review process | Expert Review with public specification |
1781       |                |                                         |
1782       | Syntax         | 2 octet TLV type (decimal)              |
1783       +----------------+-----------------------------------------+
1784
1785                             Registry Creation
1786
1787
1788
1789
1790
1791
1792Mosko, et al.           Expires September 8, 2018              [Page 32]
1793
1794Internet-Draft                  CCNx TLV                      March 2018
1795
1796
1797   +--------------+------------------+---------------------------------+
1798   |     Type     |       Name       |            Reference            |
1799   +--------------+------------------+---------------------------------+
1800   |      1       |  T_NAMESEGMENT   |       Name (Section 3.6.1)      |
1801   |              |                  |                                 |
1802   |      2       |      T_IPID      |       Name (Section 3.6.1)      |
1803   |              |                  |                                 |
1804   |   16 - 19    |     Reserved     |       Used in other drafts      |
1805   |              |                  |                                 |
1806   |    %x0FFF    |      T_ORG       |    Organization-Specific TLVs   |
1807   |              |                  |         (Section 3.3.2)         |
1808   |              |                  |                                 |
1809   |   %x1000 -   |    T_APP:00 -    | Application Components (Section |
1810   |    %x1FFF    |    T_APP:4096    |              3.6.1)             |
1811   +--------------+------------------+---------------------------------+
1812
1813                        Name Segment Type Namespace
1814
18154.6.  Message Type Registry
1816
1817   The following CCNx message segment types should be allocated.
1818
1819              +----------------+----------------------------+
1820              | Property       | Value                      |
1821              +----------------+----------------------------+
1822              | Name           | Message Type Registry      |
1823              |                |                            |
1824              | Parent         | CCNx Registry              |
1825              |                |                            |
1826              | Review process | RFC Required               |
1827              |                |                            |
1828              | Syntax         | 2 octet TLV type (decimal) |
1829              +----------------+----------------------------+
1830
1831                             Registry Creation
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848Mosko, et al.           Expires September 8, 2018              [Page 33]
1849
1850Internet-Draft                  CCNx TLV                      March 2018
1851
1852
1853   +---------------+----------------+----------------------------------+
1854   |      Type     |      Name      |            Reference             |
1855   +---------------+----------------+----------------------------------+
1856   |       0       |     T_NAME     |   Message Types (Section 3.6)    |
1857   |               |                |                                  |
1858   |       1       |   T_PAYLOAD    |   Message Types (Section 3.6)    |
1859   |               |                |                                  |
1860   |       2       |  T_KEYIDRESTR  |   Message Types (Section 3.6)    |
1861   |               |                |                                  |
1862   |       3       | T_OBJHASHRESTR |   Message Types (Section 3.6)    |
1863   |               |                |                                  |
1864   |       5       |  T_PAYLDTYPE   |   Content Object Message Types   |
1865   |               |                |        (Section 3.6.2.2)         |
1866   |               |                |                                  |
1867   |       6       |    T_EXPIRY    |   Content Object Message Types   |
1868   |               |                |        (Section 3.6.2.2)         |
1869   |               |                |                                  |
1870   |     7 - 12    |    Reserved    |     Used in other RFC drafts     |
1871   |               |                |                                  |
1872   |     %x0FFE    |     T_PAD      |       Pad (Section 3.3.1)        |
1873   |               |                |                                  |
1874   |     %x0FFF    |     T_ORG      |    Organization-Specific TLVs    |
1875   |               |                |         (Section 3.3.2)          |
1876   |               |                |                                  |
1877   | %x1000-%x1FFF |    Reserved    |   Experimental Use (Section 3)   |
1878   +---------------+----------------+----------------------------------+
1879
1880                        CCNx Message Type Namespace
1881
18824.7.  Payload Type Registry
1883
1884   The following payload types should be allocated.
1885
1886      +----------------+--------------------------------------------+
1887      | Property       | Value                                      |
1888      +----------------+--------------------------------------------+
1889      | Name           | PayloadType Registry                       |
1890      |                |                                            |
1891      | Parent         | CCNx Registry                              |
1892      |                |                                            |
1893      | Review process | Expert Review with public specification    |
1894      |                |                                            |
1895      | Syntax         | Variable length unsigned integer (decimal) |
1896      +----------------+--------------------------------------------+
1897
1898                             Registry Creation
1899
1900
1901
1902
1903
1904Mosko, et al.           Expires September 8, 2018              [Page 34]
1905
1906Internet-Draft                  CCNx TLV                      March 2018
1907
1908
1909     +------+--------------------+-----------------------------------+
1910     | Type |        Name        |             Reference             |
1911     +------+--------------------+-----------------------------------+
1912     |  0   | T_PAYLOADTYPE_DATA | Payload Types (Section 3.6.2.2.1) |
1913     |      |                    |                                   |
1914     |  1   | T_PAYLOADTYPE_KEY  | Payload Types (Section 3.6.2.2.1) |
1915     |      |                    |                                   |
1916     |  2   | T_PAYLOADTYPE_LINK | Payload Types (Section 3.6.2.2.1) |
1917     +------+--------------------+-----------------------------------+
1918
1919                          Payload Type Namespace
1920
19214.8.  Validation Algorithm Type Registry
1922
1923   The following validation algorithm types should be allocated.
1924
1925   +---------------+---------------------------------------------------+
1926   | Property      | Value                                             |
1927   +---------------+---------------------------------------------------+
1928   | Name          | Validation Algorithm Type Registry                |
1929   |               |                                                   |
1930   | Parent        | CCNx Registry                                     |
1931   |               |                                                   |
1932   | Review        | Expert Review with public specification of the    |
1933   | process       | algorithm                                         |
1934   |               |                                                   |
1935   | Syntax        | 2 octet TLV type (decimal)                        |
1936   +---------------+---------------------------------------------------+
1937
1938                             Registry Creation
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960Mosko, et al.           Expires September 8, 2018              [Page 35]
1961
1962Internet-Draft                  CCNx TLV                      March 2018
1963
1964
1965   +---------------+---------------+-----------------------------------+
1966   |      Type     |      Name     |             Reference             |
1967   +---------------+---------------+-----------------------------------+
1968   |       2       |    T_CRC32C   |   Validation Algorithm (Section   |
1969   |               |               |              3.6.4.1)             |
1970   |               |               |                                   |
1971   |       4       | T_HMAC-SHA256 |   Validation Algorithm (Section   |
1972   |               |               |              3.6.4.1)             |
1973   |               |               |                                   |
1974   |       5       |  T_RSA-SHA256 |   Validation Algorithm (Section   |
1975   |               |               |              3.6.4.1)             |
1976   |               |               |                                   |
1977   |       6       | EC-SECP-256K1 |   Validation Algorithm (Section   |
1978   |               |               |              3.6.4.1)             |
1979   |               |               |                                   |
1980   |       7       | EC-SECP-384R1 |   Validation Algorithm (Section   |
1981   |               |               |              3.6.4.1)             |
1982   |               |               |                                   |
1983   |     %x0FFE    |     T_PAD     |        Pad (Section 3.3.1)        |
1984   |               |               |                                   |
1985   |     %x0FFF    |     T_ORG     |     Organization-Specific TLVs    |
1986   |               |               |          (Section 3.3.2)          |
1987   |               |               |                                   |
1988   | %x1000-%x1FFF |    Reserved   |    Experimental Use (Section 3)   |
1989   +---------------+---------------+-----------------------------------+
1990
1991                    Validation Algorithm Type Namespace
1992
19934.9.  Validation Dependent Data Type Registry
1994
1995   The following validation dependent data types should be allocated.
1996
1997       +----------------+-----------------------------------------+
1998       | Property       | Value                                   |
1999       +----------------+-----------------------------------------+
2000       | Name           | Validation Dependent Data Type Registry |
2001       |                |                                         |
2002       | Parent         | CCNx Registry                           |
2003       |                |                                         |
2004       | Review process | RFC Required                            |
2005       |                |                                         |
2006       | Syntax         | 2 octet TLV type (decimal)              |
2007       +----------------+-----------------------------------------+
2008
2009                             Registry Creation
2010
2011
2012
2013
2014
2015
2016Mosko, et al.           Expires September 8, 2018              [Page 36]
2017
2018Internet-Draft                  CCNx TLV                      March 2018
2019
2020
2021   +---------------+----------------+----------------------------------+
2022   |      Type     |      Name      |            Reference             |
2023   +---------------+----------------+----------------------------------+
2024   |       9       |    T_KEYID     |    Validation Dependent Data     |
2025   |               |                |       (Section 3.6.4.1.4)        |
2026   |               |                |                                  |
2027   |       10      | T_PUBLICKEYLOC |    Validation Dependent Data     |
2028   |               |                |       (Section 3.6.4.1.4)        |
2029   |               |                |                                  |
2030   |       11      |  T_PUBLICKEY   |    Validation Dependent Data     |
2031   |               |                |       (Section 3.6.4.1.4)        |
2032   |               |                |                                  |
2033   |       12      |     T_CERT     |    Validation Dependent Data     |
2034   |               |                |       (Section 3.6.4.1.4)        |
2035   |               |                |                                  |
2036   |       13      |     T_LINK     |    Validation Dependent Data     |
2037   |               |                |       (Section 3.6.4.1.4)        |
2038   |               |                |                                  |
2039   |       14      |   T_KEYLINK    |    Validation Dependent Data     |
2040   |               |                |       (Section 3.6.4.1.4)        |
2041   |               |                |                                  |
2042   |       15      |   T_SIGTIME    |    Validation Dependent Data     |
2043   |               |                |       (Section 3.6.4.1.4)        |
2044   |               |                |                                  |
2045   |     %x0FFF    |     T_ORG      |    Organization-Specific TLVs    |
2046   |               |                |         (Section 3.3.2)          |
2047   |               |                |                                  |
2048   | %x1000-%x1FFF |    Reserved    |   Experimental Use (Section 3)   |
2049   +---------------+----------------+----------------------------------+
2050
2051                 Validation Dependent Data Type Namespace
2052
20534.10.  Hash Function Type Registry
2054
2055   The following CCNx hash function types should be allocated.
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072Mosko, et al.           Expires September 8, 2018              [Page 37]
2073
2074Internet-Draft                  CCNx TLV                      March 2018
2075
2076
2077   +--------------+----------------------------------------------------+
2078   | Property     | Value                                              |
2079   +--------------+----------------------------------------------------+
2080   | Name         | Hash Function Type Registry                        |
2081   |              |                                                    |
2082   | Parent       | CCNx Registry                                      |
2083   |              |                                                    |
2084   | Review       | Expert Review with public specification of the     |
2085   | process      | hash function                                      |
2086   |              |                                                    |
2087   | Syntax       | 2 octet TLV type (decimal)                         |
2088   +--------------+----------------------------------------------------+
2089
2090                             Registry Creation
2091
2092   +---------------+-----------+---------------------------------------+
2093   |      Type     |    Name   |               Reference               |
2094   +---------------+-----------+---------------------------------------+
2095   |       1       | T_SHA-256 |      Hash Format (Section 3.3.3)      |
2096   |               |           |                                       |
2097   |       2       | T_SHA-512 |      Hash Format (Section 3.3.3)      |
2098   |               |           |                                       |
2099   |     %x0FFF    |   T_ORG   |  Organization-Specific TLVs (Section  |
2100   |               |           |                 3.3.2)                |
2101   |               |           |                                       |
2102   | %x1000-%x1FFF |  Reserved |      Experimental Use (Section 3)     |
2103   +---------------+-----------+---------------------------------------+
2104
2105                     CCNx Hash Function Type Namespace
2106
21075.  Security Considerations
2108
2109   The CCNx protocol is a layer 3 network protocol, which may also
2110   operate as an overlay using other transports, such as UDP or other
2111   tunnels.  It includes intrinsic support for message authentication
2112   via a signature (e.g.  RSA or elliptic curve) or message
2113   authentication code (e.g.  HMAC).  In lieu of an authenticator, it
2114   may instead use a message integrity check (e.g.  SHA or CRC).  CCNx
2115   does not specify an encryption envelope, that function is left to a
2116   high-layer protocol (e.g. [esic]).
2117
2118   The CCNx message format includes the ability to attach MICs (e.g.
2119   SHA-256 or CRC), MACs (e.g.  HMAC), and Signatures (e.g.  RSA or
2120   ECDSA) to all packet types.  This does not mean that it is a good
2121   idea to use an arbitrary ValidationAlgorithm, nor to include
2122   computationally expensive algorithms in Interest packets, as that
2123   could lead to computational DoS attacks.  Applications should use an
2124   explicit protocol to guide their use of packet signatures.  As a
2125
2126
2127
2128Mosko, et al.           Expires September 8, 2018              [Page 38]
2129
2130Internet-Draft                  CCNx TLV                      March 2018
2131
2132
2133   general guideline, an application might use a MIC on an Interest to
2134   detect unintentionally corrupted packets.  If one wishes to secure an
2135   Interest, one should consider using an encrypted wrapper and a
2136   protocol that prevents replay attacks, especially if the Interest is
2137   being used as an actuator.  Simply using an authentication code or
2138   signature does not make an Interests secure.  There are several
2139   examples in the literature on how to secure ICN-style messaging
2140   [mobile] [ace].
2141
2142   As a layer 3 protocol, this document does not describe how one
2143   arrives at keys or how one trusts keys.  The CCNx content object may
2144   include a public key embedded in the object or may use the
2145   PublicKeyLocator field to point to a public key (or public key
2146   certificate) that authenticates the message.  One key exchange
2147   specification is CCNxKE [ccnxke]  [mobile], which is similar to the
2148   TLS 1.3 key exchange except it is over the CCNx layer 3 messages.
2149   Trust is beyond the scope of a layer-3 protocol protocol and left to
2150   applications or application frameworks.
2151
2152   The combination of an ephemeral key exchange (e.g.  CCNxKE [ccnxke])
2153   and an encapsulating encryption (e.g. [esic]) provides the equivalent
2154   of a TLS tunnel.  Intermediate nodes may forward the Interests and
2155   Content Objects, but have no visibility inside.  It also completely
2156   hides the internal names in those used by the encryption layer.  This
2157   type of tunneling encryption is useful for content that has little or
2158   no cache-ability as it can only be used by someone with the ephemeral
2159   key.  Short term caching may help with lossy links or mobility, but
2160   long term caching is usually not of interest.
2161
2162   Broadcast encryption or proxy re-encryption may be useful for content
2163   with multiple uses over time or many consumers.  There is currently
2164   no recommendation for this form of encryption.
2165
2166   The specific encoding of messages will have security implications.
2167   This document uses a type-length-value (TLV) encoding.  We chose to
2168   compromise between extensibility and unambiguous encodings of types
2169   and lengths.  Some TLVs use variable length T and variable length L
2170   fields to accomodate a wide gamut of values while trying to be byte-
2171   efficient.  Our TLV encoding uses a fixed length 2-byte T and 2-byte
2172   L.  Using a fixed-length T and L field solves two problems.  The
2173   first is aliases.  If one is able to encode the same value, such as
2174   0x2 and 0x02, in different byte lengths then one must decide if they
2175   mean the same thing, if they are different, or if one is illegal.  If
2176   they are different, then one must always compare on the buffers not
2177   the integer equivalents.  If one is illegal, then one must validate
2178   the TLV encoding -- every field of every packet at every hop.  If
2179   they are the same, then one has the second problem: how to specify
2180   packet filters.  For example, if a name has 6 name components, then
2181
2182
2183
2184Mosko, et al.           Expires September 8, 2018              [Page 39]
2185
2186Internet-Draft                  CCNx TLV                      March 2018
2187
2188
2189   there are 7 T's and 7 L's, each of which might have up to 4
2190   representations of the same value.  That would be 14 fields with 4
2191   encodings each, or 1001 combinations.  It also means that one cannot
2192   compare, for example, a name via a memory function as one needs to
2193   consider that any embedded T or L might have a different format.
2194
2195   The Interest Return message has no authenticator from the previous
2196   hop.  Therefore, the payload of the Interest Return should only be
2197   used locally to match an Interest.  A node should never forward that
2198   Interest payload as an Interest.  It should also verify that it sent
2199   the Interest in the Interest Return to that node and not allow anyone
2200   to negate Interest messages.
2201
2202   Caching nodes must take caution when processing content objects.  It
2203   is essential that the Content Store obey the rules outlined in
2204   [CCNSemantics] to avoid certain types of attacks.  Unlike NDN, CCNx
2205   1.0 has no mechanism to work around an undesired result from the
2206   network (there are no "excludes"), so if a cache becomes poisoned
2207   with bad content it might cause problems retrieving content.  There
2208   are three types of access to content from a content store:
2209   unrestricted, signature restricted, and hash restricted.  If an
2210   Interest has no restrictions, then the requester is not particular
2211   about what they get back, so any matching cached object is OK.  In
2212   the hash restricted case, the requester is very specific about what
2213   they want and the content store (and every forward hop) can easily
2214   verify that the content matches the request.  In the signature
2215   verified case (often used for initial manifest discovery), the
2216   requester only knows the KeyId that signed the content.  It is this
2217   case that requires the closest attention in the content store to
2218   avoid amplifying bad data.  The content store must only respond with
2219   a content object if it can verify the signature -- this means either
2220   the content object carries the public key inside it or the Interest
2221   carries the public key in addition to the KeyId.  If that is not the
2222   case, then the content store should treat the Interest as a cache
2223   miss and let an endpoint respond.
2224
2225   A user-level cache could perform full signature verification by
2226   fetching a public key according to the PublicKeyLocator.  That is
2227   not, however, a burden we wish to impose on the forwarder.  A user-
2228   level cache could also rely on out-of-band attestation, such as the
2229   cache operator only inserting content that it knows has the correct
2230   signature.
2231
2232   The CCNx grammar allows for hash algorithm agility via the HashType.
2233   It specifies a short list of acceptable hash algorithms that should
2234   be implemented at each forwarder.  Some hash values only apply to end
2235   systems, so updating the hash algorithm does not affect forwarders --
2236   they would simply match the buffer that includes the type-length-hash
2237
2238
2239
2240Mosko, et al.           Expires September 8, 2018              [Page 40]
2241
2242Internet-Draft                  CCNx TLV                      March 2018
2243
2244
2245   buffer.  Some fields, such as the ConObjHash, must be verified at
2246   each hop, so a forwarder (or related system) must know the hash
2247   algorithm and it could cause backward compatibility problems if the
2248   hash type is updated.
2249
2250   A CCNx name uses binary matching whereas a URI uses a case
2251   insensitive hostname.  Some systems may also use case insensitive
2252   matching of the URI path to a resource.  An implication of this is
2253   that human-entered CCNx names will likely have case or non-ASCII
2254   symbol mismatches unless one uses a consistent URI normalization to
2255   the CCNx name.  It also means that an entity that registers a CCNx
2256   routable prefix, say ccnx:/example.com, would need separate
2257   registrations for simple variations like ccnx:/Example.com.  Unless
2258   this is addressed in URI normalization and routing protocol
2259   conventions, there could be phishing attacks.
2260
2261   For a more general introduction to ICN-related security concerns and
2262   approaches, see [RFC7927] and [RFC7945]
2263
22646.  References
2265
22666.1.  Normative References
2267
2268   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2269              Requirement Levels", BCP 14, RFC 2119,
2270              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
2271              editor.org/info/rfc2119>.
2272
22736.2.  Informative References
2274
2275   [ace]      Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang,
2276              "NDN-ACE: Access control for constrained environments over
2277              named data networking", NDN Technical Report NDN-0036,
2278              2015, <http://new.named-data.net/wp-
2279              content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf>.
2280
2281   [CCN]      PARC, Inc., "CCNx Open Source", 2007,
2282              <http://www.CCNx.org>.
2283
2284   [CCNSemantics]
2285              Mosko, M., Solis, I., and C. Wood, "CCNx Semantics
2286              (Internet draft)", 2018, <https://www.ietf.org/id/draft-
2287              irtf-icnrg-ccnxsemantics-07.txt>.
2288
2289   [ccnxke]   Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange
2290              Protocol Version 1.0", 2017,
2291              <https://www.ietf.org/archive/id/draft-wood-icnrg-
2292              ccnxkeyexchange-02.txt>.
2293
2294
2295
2296Mosko, et al.           Expires September 8, 2018              [Page 41]
2297
2298Internet-Draft                  CCNx TLV                      March 2018
2299
2300
2301   [CCNxURI]  Mosko, M. and C. Wood, "The CCNx URI Scheme (Internet
2302              draft)", 2017,
2303              <http://tools.ietf.org/html/draft-mosko-icnrg-ccnxuri-02>.
2304
2305   [CCNxz]    Mosko, M., "CCNxz TLV Header Compression Experimental
2306              Code", 2016-2018, <https://github.com/PARC/CCNxz>.
2307
2308   [compress]
2309              Mosko, M., "Header Compression for TLV-based Packets",
2310              2016, <https://datatracker.ietf.org/meeting/interim-2016-
2311              icnrg-02/materials/slides-interim-2016-icnrg-2-7>.
2312
2313   [ECC]      Certicom Research, "SEC 2: Recommended Elliptic Curve
2314              Domain Parameters", 2010,
2315              <http://www.secg.org/sec2-v2.pdf>.
2316
2317   [EpriseNumbers]
2318              IANA, "IANA Private Enterprise Numbers", 2015,
2319              <http://www.iana.org/assignments/enterprise-numbers/
2320              enterprise-numbers>.
2321
2322   [esic]     Mosko, M. and C. Wood, "Encrypted Sessions In CCNx
2323              (ESIC)", 2017, <https://www.ietf.org/id/draft-wood-icnrg-
2324              esic-01.txt>.
2325
2326   [mobile]   Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in
2327              Content-Centric Networks", IFIP Networking, 2017,
2328              <http://dl.ifip.org/db/conf/networking/
2329              networking2017/1570334964.pdf>.
2330
2331   [nnc]      Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
2332              Briggs, N., and R. Braynard, "Networking Named Content",
2333              2009, <http://dx.doi.org/10.1145/1658939.1658941>.
2334
2335   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
2336              Text on Security Considerations", BCP 72, RFC 3552,
2337              DOI 10.17487/RFC3552, July 2003, <https://www.rfc-
2338              editor.org/info/rfc3552>.
2339
2340   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
2341              IANA Considerations Section in RFCs", RFC 5226,
2342              DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
2343              editor.org/info/rfc5226>.
2344
2345
2346
2347
2348
2349
2350
2351
2352Mosko, et al.           Expires September 8, 2018              [Page 42]
2353
2354Internet-Draft                  CCNx TLV                      March 2018
2355
2356
2357   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
2358              Housley, R., and W. Polk, "Internet X.509 Public Key
2359              Infrastructure Certificate and Certificate Revocation List
2360              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
2361              <https://www.rfc-editor.org/info/rfc5280>.
2362
2363   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
2364              Keranen, A., and P. Hallam-Baker, "Naming Things with
2365              Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
2366              <https://www.rfc-editor.org/info/rfc6920>.
2367
2368   [RFC7927]  Kutscher, D., Eum, S., Pentikousis, K., Psaras, I.,
2369              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
2370              "Information-Centric Networking (ICN) Research
2371              Challenges", 2016, <https://trac.tools.ietf.org/html/
2372              rfc7927>.
2373
2374   [RFC7945]  Pentikousis, K., Ohlman, B., Davies, E., Spirou, S., and
2375              G. Boggia, "Information-Centric Networking: Evaluation and
2376              Security Considerations", 2016,
2377              <https://trac.tools.ietf.org/html/rfc7945>.
2378
2379Authors' Addresses
2380
2381   Marc Mosko
2382   PARC, Inc.
2383   Palo Alto, California  94304
2384   USA
2385
2386   Phone: +01 650-812-4405
2387   Email: marc.mosko@parc.com
2388
2389
2390   Ignacio Solis
2391   LinkedIn
2392   Mountain View, California  94043
2393   USA
2394
2395   Email: nsolis@linkedin.com
2396
2397
2398   Christopher A. Wood
2399   University of California Irvine
2400   Irvine, California  92697
2401   USA
2402
2403   Phone: +01 315-806-5939
2404   Email: woodc1@uci.edu
2405
2406
2407
2408Mosko, et al.           Expires September 8, 2018              [Page 43]