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

File draft-irtf-icnrg-ccnxsemantics-07.txt, 85.6 KB (added by Borje.Ohlman@…, 8 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 Semantics
15                 draft-irtf-icnrg-ccnxsemantics-07
16
17Abstract
18
19   This document describes the core concepts of the Content Centric
20   Networking (CCNx) architecture and presents a network protocol based
21   on two messages: Interests and Content Objects.  It specifies the set
22   of mandatory and optional fields within those messages and describes
23   their behavior and interpretation.  This architecture and protocol
24   specification is independent of a specific wire encoding.
25
26   The protocol also uses a Control message called an InterestReturn,
27   whereby one system can return an Interest message to the previous hop
28   due to an error condition.  This indicates to the previous hop that
29   the current system will not respond to the Interest.
30
31   This document is a product of the Information Centric Networking
32   research group (ICNRG).
33
34Status of This Memo
35
36   This Internet-Draft is submitted in full conformance with the
37   provisions of BCP 78 and BCP 79.
38
39   Internet-Drafts are working documents of the Internet Engineering
40   Task Force (IETF).  Note that other groups may also distribute
41   working documents as Internet-Drafts.  The list of current Internet-
42   Drafts is at http://datatracker.ietf.org/drafts/current/.
43
44   Internet-Drafts are draft documents valid for a maximum of six months
45   and may be updated, replaced, or obsoleted by other documents at any
46   time.  It is inappropriate to use Internet-Drafts as reference
47   material or to cite them other than as "work in progress."
48
49   This Internet-Draft will expire on September 8, 2018.
50
51
52
53
54
55
56Mosko, et al.           Expires September 8, 2018               [Page 1]
57
58Internet-Draft               CCNx Semantics                   March 2018
59
60
61Copyright Notice
62
63   Copyright (c) 2018 IETF Trust and the persons identified as the
64   document authors.  All rights reserved.
65
66   This document is subject to BCP 78 and the IETF Trust's Legal
67   Provisions Relating to IETF Documents
68   (http://trustee.ietf.org/license-info) in effect on the date of
69   publication of this document.  Please review these documents
70   carefully, as they describe your rights and restrictions with respect
71   to this document.  Code Components extracted from this document must
72   include Simplified BSD License text as described in Section 4.e of
73   the Trust Legal Provisions and are provided without warranty as
74   described in the Simplified BSD License.
75
76Table of Contents
77
78   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
79     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
80     1.2.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
81     1.3.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   6
82   2.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
83     2.1.  Message Grammar . . . . . . . . . . . . . . . . . . . . .   9
84     2.2.  Consumer Behavior . . . . . . . . . . . . . . . . . . . .  13
85     2.3.  Publisher Behavior  . . . . . . . . . . . . . . . . . . .  14
86     2.4.  Forwarder Behavior  . . . . . . . . . . . . . . . . . . .  15
87       2.4.1.  Interest HopLimit . . . . . . . . . . . . . . . . . .  15
88       2.4.2.  Interest Aggregation  . . . . . . . . . . . . . . . .  16
89       2.4.3.  Content Store Behavior  . . . . . . . . . . . . . . .  17
90       2.4.4.  Interest Pipeline . . . . . . . . . . . . . . . . . .  17
91       2.4.5.  Content Object Pipeline . . . . . . . . . . . . . . .  18
92   3.  Names . . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
93     3.1.  Name Examples . . . . . . . . . . . . . . . . . . . . . .  20
94     3.2.  Interest Payload ID . . . . . . . . . . . . . . . . . . .  20
95   4.  Cache Control . . . . . . . . . . . . . . . . . . . . . . . .  20
96   5.  Content Object Hash . . . . . . . . . . . . . . . . . . . . .  21
97   6.  Link  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
98   7.  Hashes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
99   8.  Validation  . . . . . . . . . . . . . . . . . . . . . . . . .  22
100     8.1.  Validation Algorithm  . . . . . . . . . . . . . . . . . .  22
101   9.  Interest to Content Object matching . . . . . . . . . . . . .  23
102   10. Interest Return . . . . . . . . . . . . . . . . . . . . . . .  24
103     10.1.  Message Format . . . . . . . . . . . . . . . . . . . . .  25
104     10.2.  ReturnCode Types . . . . . . . . . . . . . . . . . . . .  25
105     10.3.  Interest Return Protocol . . . . . . . . . . . . . . . .  26
106       10.3.1.  No Route . . . . . . . . . . . . . . . . . . . . . .  27
107       10.3.2.  HopLimit Exceeded  . . . . . . . . . . . . . . . . .  28
108       10.3.3.  Interest MTU Too Large . . . . . . . . . . . . . . .  28
109
110
111
112Mosko, et al.           Expires September 8, 2018               [Page 2]
113
114Internet-Draft               CCNx Semantics                   March 2018
115
116
117       10.3.4.  No Resources . . . . . . . . . . . . . . . . . . . .  28
118       10.3.5.  Path Error . . . . . . . . . . . . . . . . . . . . .  28
119       10.3.6.  Prohibited . . . . . . . . . . . . . . . . . . . . .  28
120       10.3.7.  Congestion . . . . . . . . . . . . . . . . . . . . .  28
121       10.3.8.  Unsupported Content Object Hash Algorithm  . . . . .  29
122       10.3.9.  Malformed Interest . . . . . . . . . . . . . . . . .  29
123   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
124   12. Security Considerations . . . . . . . . . . . . . . . . . . .  29
125   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
126     13.1.  Normative References . . . . . . . . . . . . . . . . . .  32
127     13.2.  Informative References . . . . . . . . . . . . . . . . .  32
128   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34
129
1301.  Introduction
131
132   This document describes the principles of the CCNx architecture.  It
133   describes a network protocol that uses a hierarchical name to forward
134   requests and to match responses to requests.  It does not use
135   endpoint addresses, such as Internet Protocol.  Restrictions in a
136   request can limit the response by the public key of the response's
137   signer or the cryptographic hash of the response.  Every CCNx
138   forwarder along the path does the name matching and restriction
139   checking.  The CCNx protocol fits within the broader framework of
140   Information Centric Networking (ICN) protocols [RFC7927].  This
141   document concerns the semantics of the protocol and is not dependent
142   on a specific wire format encoding.  The CCNx Messages [CCNMessages]
143   document describes a type-length-value (TLV) wire protocol encoding.
144   This section introduces the main concepts of CCNx, which are further
145   elaborated in the remainder of the document.
146
147   The CCNx protocol derives from the early ICN work by Jacobson et al.
148   [nnc].  Jacobson's version of CCNx is known as the 0.x version ("CCNx
149   0.x") and the present work is known as the 1.0 version ("CCNx 1.0").
150   There are two active implementations of CCNx 1.0.  The most complete
151   implementation is Community ICN (CINC) [cicn], a Linux Foundation
152   project hosted at fd.io.  Another active implementation is CCN-lite
153   [ccnlite], with support for IoT systems and the RIOT operating
154   system.
155
156   The original work by Jacobson formed the basis of the Named Data
157   Networking [ndn] (NDN) university project.  The current CCNx 1.0
158   specification diverges from NDN in a few significant areas.  As CCNx
159   0.x is no longer under development, we will only describe some of the
160   differences with NDN.  In both NDN and CCNx 1.0, a forwarder uses a
161   longest prefix match of a request name against the forwarding
162   information base (FIB) to send the request through the network to a
163   system that can issue a response.  A forwarder must then match a
164   response's name to a request's name to determine the reverse path and
165
166
167
168Mosko, et al.           Expires September 8, 2018               [Page 3]
169
170Internet-Draft               CCNx Semantics                   March 2018
171
172
173   deliver the response to the requester.  Herein lies the main
174   difference between NDN and CCNx 1.0.
175
176   NDN performs, at the network layer, content discovery via various
177   strategies of partial matching a request name to a response name.
178   NDN supports several different content discovery strategies that
179   differ in their load on the network and the state maintained at each
180   hop.  A forwarding strategy must be implemented at each forwarder.
181   On a match, a forwarder returns the entire response (e.g. several
182   kilobytes to megabytes of data) hop-by-hop to the requester.  The
183   requestor may then use that response or issue a new request that
184   excludes the unwanted result via a type of interval filter on the
185   last name component of the request's name.  CCNx 1.0 does not include
186   discovery at the network level, but uses a protocol on top of it's
187   layer 3 protocol.  In CCNx 1.0, not every forwarder needs to
188   implement discovery and the network could support multiple discovery
189   protocols.  The main ramification of this approach is that in CCNx
190   1.0 the name in a response always exactly matches the name in a
191   request (see Section 9 for the exact details and one exception for
192   nameless responses).  A forwarder does not prefix match a response to
193   a request.
194
195   CCNx Selectors [selectors] is an example of using a higher-layer
196   protocol on top of the CCNx 1.0 layer-3 to perform content discovery.
197   The selector protocol uses a method similar to the original CCNx 0.x
198   and the current NDN techniques without requiring partial name
199   matching of a response to a request in the forwarder.
200
201   The document represents the consensus of the ICN RG.  It is the first
202   ICN protocol from the RG, created from the early CCNx protocol [nnc]
203   with significant revision and input from the ICN community and RG
204   members.  The draft has received critical reading by several members
205   of the ICN community and the RG.  The authors and RG chairs approve
206   of the contents.  The document is sponsored under the IRTF and is not
207   issued by the IETF and is not an IETF standard.  This is an
208   experimental protocol and may not be suitable for any specific
209   application and the specification may change in the future.
210
2111.1.  Requirements Language
212
213   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
214   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
215   document are to be interpreted as described in RFC 2119 [RFC2119].
216
217
218
219
220
221
222
223
224Mosko, et al.           Expires September 8, 2018               [Page 4]
225
226Internet-Draft               CCNx Semantics                   March 2018
227
228
2291.2.  Architecture
230
231   We describe the architecture of the network in which CCNx operates
232   and introduce certain terminology from [terminology].  The detailed
233   behavior of each component and message grammars are in Section 2.
234
235   A producer (also called a publisher) is an endpoint that encapsualtes
236   content in Content Objects for transport in the CCNx network.  A
237   producer has a public/private keypair and signs (directly or
238   indirectly) the content objects.  Usually, the producer's keyid (hash
239   of the public key) is well-known or may be derived from the
240   producer's namespace via standard means.
241
242   A producer operates within one or more namespaces.  A namespace is a
243   name prefix that is represented in the forwarding information base
244   (FIB).  This allows a request to reach the producer and fetch a
245   response (if one exists).
246
247   The forwarding information base (FIB) is a table that tells a
248   forwarder where to send a request.  It may point to a local
249   application, a local cache or content store, or to a remote system.
250   If there is no matching entry in the FIB, a forwarder cannot process
251   a request.  The detailed rules on name matching to the FIB are given
252   in Section 2.4.4.  An endpoint has a FIB, though it may be a simple
253   default route.  An intermediate system (i.e. a router) typically has
254   a much larger FIB.  A core CCNx forwarder, for example, would know
255   all the global routes.
256
257   A consumer is an endpoint that requests a name.  It is beyond the
258   scope of this document to describe how a consumer learns of a name or
259   publisher keyid -- higher layer protocols build on top of CCNx handle
260   those tasks, such as search engines or lookup services or well known
261   names.  The consumer constructs a request, called an Interest, and
262   forwards it via the endpoint's FIB.  The consumer should get back
263   either a response, called a Content Object, that matches the Interest
264   or a control message, called an InterestReturn, that indicates the
265   network cannot handle the request.
266
267   There are three ways to detect errors in Interest handling.  An
268   InterestReturn is a network control message that indicates a low-
269   level error like no route or out of resources.  If an Interest
270   arrives at a producer, but the producer does not have the requested
271   content, the producer should send an application-specific error
272   message (e.g. a not found message).  Finally, a consumer may not
273   receive anything, in which case it should timeout and, depending on
274   the application, retry the request or return an error to the
275   application.
276
277
278
279
280Mosko, et al.           Expires September 8, 2018               [Page 5]
281
282Internet-Draft               CCNx Semantics                   March 2018
283
284
2851.3.  Protocol Overview
286
287   The goal of CCNx is to name content and retrieve the content from the
288   network without binding it to a specific network endpoint.  A routing
289   system (specified separately) populates the forwarding information
290   base (FIB) tables at each CCNx router with hierarchical name prefixes
291   that point towards the content producers under that prefix.  A
292   request finds matching content along those paths, in which case a
293   response carries the data, or if no match is found a control message
294   indicates the failure.  A request may further refine acceptable
295   responses with a restriction on the response's signer and the
296   cryptographic hash of the response.  The details of these
297   restrictions are described below.
298
299   The CCNx name is a hierarchical series of path segments.  Each path
300   segment has a type and zero or more bytes.  Matching two names is
301   done as a binary comparison of the type and value, segment by
302   segment.  The human-readable form is defined under a URI scheme
303   "ccnx:" [CCNxURI], though the canonical encoding of a name is a
304   series of (type, octet string) pairs.  There is no requirement that
305   any path segment be human readable or UTF-8.  The first few segments
306   in a name will matched against the FIB and a routing protocol may put
307   its own restrictions on the routable name components (e.g. a maximum
308   length or character encoding rules).  In principle, path segments and
309   names have unbounded length, though in practice they are limited by
310   the wire format encoding and practical considerations imposed by a
311   routing protocol.  Note that in CCNx path segments use binary
312   comparison whereas in a URI the authority uses case-insensitive
313   hostname (due to DNS).
314
315   The CCNx name, as used by the forwarder, is purposefully left as a
316   general octet-encoded type and value without any requirements on
317   human readability and character encoding.  The reason for this is
318   that we are concerned with how a forwarder processes names.  We
319   expect that applications, routing protocols, or other higher layers
320   will apply their own conventions and restrictions on the allowed path
321   segment types and path segment values.
322
323   CCNx is a request and response protocol to fetch chunks of data using
324   a name.  The integrity of each chunk may be directly asserted through
325   a digital signature or Message Authentication Code (MAC), or,
326   alternatively, indirectly via hash chains.  Chunks may also carry
327   weaker message integrity checks (MICs) or no integrity protection
328   mechanism at all.  Because provenance information is carried with
329   each chunk (or larger indirectly protected block), we no longer need
330   to rely on host identities, such as those derived from TLS
331   certificates, to ascertain the chunk legitimacy.  Data integrity is
332   therefore a core feature of CCNx; it does not rely on the data
333
334
335
336Mosko, et al.           Expires September 8, 2018               [Page 6]
337
338Internet-Draft               CCNx Semantics                   March 2018
339
340
341   transmission channel.  There are several options for data
342   confidentiality, discussed later.
343
344   This document only defines the general properties of CCNx names.  In
345   some isolated environments, CCNx users may be able to use any name
346   they choose and either inject that name (or prefix) into a routing
347   protocol or use other information foraging techniques.  In the
348   Internet environment, there will be policies around the formats of
349   names and assignments of names to publishers, though those are not
350   specified here.
351
352   The key concept of CCNx is that a subjective name is
353   cryptographically bound to a fixed payload.  These publisher-
354   generated bindings can therefore be cryptographically verified.  A
355   named payload is thus the tuple {{Name, ExtraFields, Payload,
356   ValidationAlgorithm}, ValidationPayload}, where all fields in the
357   inner tuple are covered by the validation payload (e.g. signature).
358   Consumers of this data can check the binding integrity by re-
359   computing the same cryptographic hash and verifying the digital
360   signature in Validation.
361
362   In addition to digital signatures (e.g.  RSA), we also support
363   message authentication codes (e.g.  HMAC) and message integrity codes
364   (e.g.  SHA-256 or CRC).  To maintain the cryptographic binding, there
365   should be an object with a signature or authentication code, but not
366   all objects require it.  For example, a first object with a signature
367   could refer to other objects via a hash chain, a Merkle tree, or a
368   signed manifest.  The later objects may not have any validation and
369   rely purely on the references.  The use of an integrity code (e.g.
370   CRC) is intended for protecting Interests in the network from
371   accidental corruption.
372
373   CCNx specifies a network protocol around Interests (request messages)
374   and Content Objects (response messages) to move named payloads.  An
375   Interest includes the Name -- which identifies the desired response
376   -- and optional matching restrictions.  Restrictions limit the
377   possible matching Content Objects.  Two restrictions exist:
378   KeyIdRestr and ContentObjectHashRestr.  The first restriction on the
379   KeyId limits responses to those signed with a ValidationAlgorithm
380   KeyId field equal to the restriction.  The second is the Content
381   ObjectHash restriction, which limits the response to one where the
382   cryptographic hash of the entire named payload is equal to the
383   restriction.
384
385   The hierarchy of a CCNx Name is used for routing via the longest
386   matching prefix in a Forwarder.  The longest matching prefix is
387   computed name segment by name segment in the hierarchical path name,
388   where each name segment must be exactly equal to match.  There is no
389
390
391
392Mosko, et al.           Expires September 8, 2018               [Page 7]
393
394Internet-Draft               CCNx Semantics                   March 2018
395
396
397   requirement that the prefix be globally routable.  Within a
398   deployment any local routing may be used, even one that only uses a
399   single flat (non-hierarchical) name segment.
400
401   Another concept of CCNx is that there should be flow balance between
402   Interest messages and Content Object messages.  At the network level,
403   an Interest traveling along a single path should elicit no more than
404   one Content Object response.  If some node sends the Interest along
405   more than one path, that node should consolidate the responses such
406   that only one Content Object flows back towards the requester.  If an
407   Interest is sent broadcast or multicast on a multiple-access media,
408   the sender should be prepared for multiple responses unless some
409   other media-dependent mechanism like gossip suppression or leader
410   election is used.
411
412   As an Interest travels the forward path following the Forwarding
413   Information Base (FIB), it establishes state at each forwarder such
414   that a Content Object response can trace its way back to the original
415   requester(s) without the requester needing to include a routable
416   return address.  We use the notional Pending Interest Table (PIT) as
417   a method to store state that facilitates the return of a Content
418   Object.
419
420   The notional PIT table stores the last hop of an Interest plus its
421   Name and optional restrictions.  This is the data required to match a
422   Content Object to an Interest (see Section 9).  When a Content Object
423   arrives, it must be matched against the PIT to determine which
424   entries it satisfies.  For each such entry, at most one copy of the
425   Content Object is sent to each listed last hop in the PIT entries.
426
427   An actual PIT table is not mandated by the specification.  An
428   implementation may use any technique that gives the same external
429   behavior.  There are, for example, research papers that use
430   techniques like label switching in some parts of the network to
431   reduce the per-node state incurred by the PIT table [dart].  Some
432   implementations store the PIT state in the FIB, so there is not a
433   second table.
434
435   If multiple Interests with the same {Name, KeyIdRestr,
436   ContentObjectHashRestr} tuple arrive at a node before a Content
437   Object matching the first Interest comes back, they are grouped in
438   the same PIT entry and their last hops aggregated (see
439   Section 2.4.2).  Thus, one Content Object might satisfy multiple
440   pending Interests in a PIT.
441
442   In CCNx, higher-layer protocols are often called "name-based
443   protocols" because they operate on the CCNx Name.  For example, a
444   versioning protocol might append additional name segments to convey
445
446
447
448Mosko, et al.           Expires September 8, 2018               [Page 8]
449
450Internet-Draft               CCNx Semantics                   March 2018
451
452
453   state about the version of payload.  A content discovery protocol
454   might append certain protocol-specific name segments to a prefix to
455   discover content under that prefix.  Many such protocols may exist
456   and apply their own rules to Names.  They may be layered with each
457   protocol encapsulating (to the left) a higher layer's Name prefix.
458
459   This document also describes a control message called an
460   InterestReturn.  A network element may return an Interest message to
461   a previous hop if there is an error processing the Interest.  The
462   returned Interest may be further processed at the previous hop or
463   returned towards the Interest origin.  When a node returns an
464   Interest it indicates that the previous hop should not expect a
465   response from that node for the Interest, i.e., there is no PIT entry
466   left at the returning node for a Content Object to follow.
467
468   There are multiple ways to describe larger objects in CCNx.
469   Aggregating layer-3 content objects in to larger objects is beyond
470   the scope of this document.  One proposed method, FLIC [flic], uses a
471   manifest to enumerate the pieces of a larger object.  Manifests are,
472   themselves, Content Objects.  Another option is to use a convention
473   in the Content Object name, as in the CCNx Chunking [chunking]
474   protocol where a large object is broken in to small chunks and each
475   chunk receives a special name component indicating its serial order.
476
477   At the semantic level, described in this document, we do not address
478   fragmentation.  One experimental fragmentation protocol, BeginEnd
479   Fragments [befrags] uses a multipoint-PPP style technique for use
480   over layer-2 interfaces with the CCNx Messages [CCNMessages] TLV wire
481   forman specification.
482
483   With these concepts, the remainder of the document specifies the
484   behavior of a forwarder in processing Interest, Content Object, and
485   InterestReturn messages.
486
4872.  Protocol
488
489   CCNx is a request and response protocol.  A request is called an
490   Interest and a response is called a Content Object.  CCNx also uses a
491   1-hop control message called InterestReturn.  These are, as a group,
492   called CCNx Messages.
493
4942.1.  Message Grammar
495
496   The CCNx message ABNF [RFC5234] grammar is shown in Figure 1.  The
497   grammar does not include any encoding delimiters, such as TLVs.
498   Specific wire encodings are given in a separate document.  If a
499   Validation section exists, the Validation Algorithm covers from the
500   Body (BodyName or BodyOptName) through the end of the ValidationAlg
501
502
503
504Mosko, et al.           Expires September 8, 2018               [Page 9]
505
506Internet-Draft               CCNx Semantics                   March 2018
507
508
509   section.  The InterestLifetime, CacheTime, and Return Code fields
510   exist outside of the validation envelope and may be modified.
511
512   The various fields -- in alphabetical order -- are defined as:
513
514   o  AbsTime: Absolute times are conveyed as the 64-bit UTC time in
515      milliseconds since the epoch (standard POSIX time).
516
517   o  CacheTime: The absolute time after which the publisher believes
518      there is low value in caching the content object.  This is a
519      recommendation to caches (see Section 4).
520
521   o  ConObjField: These are optional fields that may appear in a
522      Content Object.
523
524   o  ConObjHash: The value of the Content Object Hash, which is the
525      SHA256-32 over the message from the beginning of the body to the
526      end of the message.  Note that this coverage area is different
527      from the ValidationAlg.  This value SHOULD NOT be trusted across
528      domains (see Section 5).
529
530   o  ExpiryTime: An absolute time after which the content object should
531      be considered expired (see Section 4).
532
533   o  HopLimit: Interest messages may loop if there are loops in the
534      forwarding plane.  To eventually terminate loops, each Interest
535      carries a HopLimit that is decremented after each hop and no
536      longer forwarded when it reaches zero.  See Section 2.4.
537
538   o  InterestField: These are optional fields that may appear in an
539      Interest message.
540
541   o  KeyIdRestr: The KeyId Restriction.  A Content Object must have a
542      KeyId with the same value as the restriction.
543
544   o  ContentObjectHashRestr: The Content Object Hash Restriction.  A
545      content object must hash to the same value as the restriction
546      using the same HashType.  The ContentObjectHashRestr MUST use
547      SHA256-32.
548
549   o  KeyId: An identifier for the key used in the ValidationAlg.  For
550      public key systems, this should be the SHA-256 hash of the public
551      key.  For symmetric key systems, it should be an identifier agreed
552      upon by the parties.
553
554   o  KeyLink: A Link (see Section 6) that names how to retrieve the key
555      used to verify the ValidationPayload.  A message SHOULD NOT have
556      both a KeyLink and a PublicKey.
557
558
559
560Mosko, et al.           Expires September 8, 2018              [Page 10]
561
562Internet-Draft               CCNx Semantics                   March 2018
563
564
565   o  Lifetime: The approximate time during which a requester is willing
566      to wait for a response, usually measured in seconds.  It is not
567      strongly related to the network round trip time, though it must
568      necessarily be larger.
569
570   o  Name: A name is made up of a non-empty first segment followed by
571      zero or more additional segments, which may be of 0 length.  Path
572      segments are opaque octet strings, and are thus case-sensitive if
573      encoding UTF-8.  An Interest MUST have a Name.  A Content Object
574      MAY have a Name (see Section 9).  The segments of a name are said
575      to be complete if its segments uniquely identify a single Content
576      Object.  A name is exact if its segments are complete.  An
577      Interest carrying a full name is one which specifies an exact name
578      and the ContentObjectHashRestr of the corresponding Content
579      Object.
580
581   o  Payload: The message's data, as defined by PayloadType.
582
583   o  PayloadType: The format of the Payload.  If missing, assume
584      DataType.  DataType means the payload is opaque application bytes.
585      KeyType means the payload is a DER-encoded public key.  LinkType
586      means it is one or more Links (see Section 6).
587
588   o  PublicKey: Some applications may wish to embed the public key used
589      to verify the signature within the message itself.  The PublickKey
590      is DER encoded.  A message SHOULD NOT have both a KeyLink and a
591      PublicKey.
592
593   o  RelTime: A relative time, measured in milli-seconds.
594
595   o  ReturnCode: States the reason an Interest message is being
596      returned to the previous hop (see Section 10.2).
597
598   o  SigTime: The absolute time (UTC milliseconds) when the signature
599      was generated.
600
601   o  Hash: Hash values carried in a Message carry a HashType to
602      identify the algorithm used to generate the hash followed by the
603      hash value.  This form is to allow hash agility.  Some fields may
604      mandate a specific HashType.
605
606
607
608
609
610
611
612
613
614
615
616Mosko, et al.           Expires September 8, 2018              [Page 11]
617
618Internet-Draft               CCNx Semantics                   March 2018
619
620
621   Message       := Interest / ContentObject / InterestReturn
622   Interest      := HopLimit [Lifetime] BodyName [Validation]
623   ContentObject := [CacheTime / ConObjHash] BodyOptName [Validation]
624   InterestReturn:= ReturnCode Interest
625   BodyName      := Name Common
626   BodyOptName   := [Name] Common
627   Common        := *Field [Payload]
628   Validation    := ValidationAlg ValidatonPayload
629
630   Name          := FirstSegment *Segment
631   FirstSegment  := 1* OCTET
632   Segment       := 0* OCTET
633
634   ValidationAlg := RSA-SHA256 HMAC-SHA256 CRC32C
635   ValidatonPayload := 1* OCTET
636   RSA-SHA256    := KeyId [PublicKey] [SigTime] [KeyLink]
637   HMAC-SHA256   := KeyId [SigTime] [KeyLink]
638   CRC32C        := [SigTime]
639
640   AbsTime       := 8 OCTET ; 64-bit UTC msec since epoch
641   CacheTime     := AbsTime
642   ConObjField   := ExpiryTime / PayloadType
643   ConObjHash    := Hash ; The Content Object Hash
644   DataType      := "1"
645   ExpiryTime    := AbsTime
646   Field         := InterestField / ConObjField
647   Hash          := HashType 1* OCTET
648   HashType      := SHA256-32 / SHA512-64 / SHA512-32
649   HopLimit      := OCTET
650   InterestField := KeyIdRestr / ContentObjectHashRestr
651   KeyId         := 1* OCTET ; key identifier
652   KeyIdRestr    := 1* OCTET
653   KeyLink       := Link
654   KeyType       := "2"
655   Lifetime      := RelTime
656   Link          := Name [KeyIdResr] [ContentObjectHashRestr]
657   LinkType      := "3"
658   ContentObjectHashRestr  := Hash
659   Payload       := *OCTET
660   PayloadType   := DataType / KeyType / LinkType
661   PublicKey     := ; DER-encoded public key
662   RelTime       := 1* OCTET ; msec
663   ReturnCode    := ; see Section 10.2
664   SigTime       := AbsTime
665
666                                 Figure 1
667
668
669
670
671
672Mosko, et al.           Expires September 8, 2018              [Page 12]
673
674Internet-Draft               CCNx Semantics                   March 2018
675
676
6772.2.  Consumer Behavior
678
679   To request a piece of content for a given {Name, [KeyIdRest],
680   [ContentObjectHashRestr]} tuple, a consumer creates an Interest
681   message with those values.  It MAY add a validation section,
682   typically only a CRC32C.  A consumer MAY put a Payload field in an
683   Interest to send additional data to the producer beyond what is in
684   the Name.  The Name is used for routing and may be remembered at each
685   hop in the notional PIT table to facilitate returning a content
686   object; Storing large amounts of state in the Name could lead to high
687   memory requirements.  Because the Payload is not considered when
688   forwarding an Interest or matching a Content Object to an Interest, a
689   consumer SHOULD put an Interest Payload ID (see Section 3.2) as part
690   of the name to allow a forwarder to match Interests to content
691   objects and avoid aggregating Interests with different payloads.
692   Similarly, if a consumer uses a MAC or a signature, it SHOULD also
693   include a unique segment as part of the name to prevent the Interest
694   from being aggregated with other Interests or satisfied by a Content
695   Object that has no relation to the validation.
696
697   The consumer SHOULD specify an InterestLifetime, which is the length
698   of time the consumer is willing to wait for a response.  The
699   InterestLifetime is an application-scale time, not a network round
700   trip time (see Section 2.4.2).  If not present, the InterestLifetime
701   will use a default value (TO_INTERESTLIFETIME).
702
703   The consumer SHOULD set the Interest HopLimit to a reasonable value
704   or use the default 255.  If the consumer knows the distances to the
705   producer via routing, it SHOULD use that value.
706
707   A consumer hands off the Interest to its first forwarder, which will
708   then forward the Interest over the network to a publisher (or
709   replica) that may satisfy it based on the name (see Section 2.4).
710
711   Interest messages are unreliable.  A consumer SHOULD run a transport
712   protocol that will retry the Interest if it goes unanswered, up to
713   the InterestLifetime.  No transport protocol is specified in this
714   document.
715
716   The network MAY send to the consumer an InterestReturn message that
717   indicates the network cannot fulfill the Interest.  The ReturnCode
718   specifies the reason for the failure, such as no route or congestion.
719   Depending on the ReturnCode, the consumer MAY retry the Interest or
720   MAY return an error to the requesting application.
721
722   If the content was found and returned by the first forwarder, the
723   consumer will receive a Content Object.  The consumer SHOULD:
724
725
726
727
728Mosko, et al.           Expires September 8, 2018              [Page 13]
729
730Internet-Draft               CCNx Semantics                   March 2018
731
732
733   o  Ensure the content object is properly formatted.
734
735   o  Verify that the returned Name matches a pending request.  If the
736      request also had KeyIdRestr and ObjHashRest, it should also
737      validate those properties.
738
739   o  If the content object is signed, it SHOULD cryptographically
740      verify the signature.  If it does not have the corresponding key,
741      it SHOULD fetch the key, such as from a key resolution service or
742      via the KeyLink.
743
744   o  If the signature has a SigTime, the consumer MAY use that in
745      considering if the signature is valid.  For example, if the
746      consumer is asking for dynamically generated content, it should
747      expect the SigTime to not be before the time the Interest was
748      generated.
749
750   o  If the content object is signed, it should assert the
751      trustworthiness of the signing key to the namespace.  Such an
752      assertion is beyond the scope of this document, though one may use
753      traditional PKI methods, a trusted key resolution service, or
754      methods like [schematized trust].
755
756   o  It MAY cache the content object for future use, up to the
757      ExpiryTime if present.
758
759   o  A consumer MAY accept a content object off the wire that is
760      expired.  It may happen that a packet expires while in flight, and
761      there is no requirement that forwarders drop expired packets in
762      flight.  The only requirement is that content stores, caches, or
763      producers MUST NOT respond with an expired content object.
764
7652.3.  Publisher Behavior
766
767   This document does not specify the method by which names populate a
768   Forwarding Information Base (FIB) table at forwarders (see
769   Section 2.4).  A publisher is either configured with one or more name
770   prefixes under which it may create content, or it chooses its name
771   prefixes and informs the routing layer to advertise those prefixes.
772
773   When a publisher receives an Interest, it SHOULD:
774
775   o  Verify that the Interest is part of the publishers namespace(s).
776
777   o  If the Interest has a Validation section, verify the
778      ValidationPayload.  Usually an Interest will only have a CRC32C
779      unless the publisher application specifically accommodates other
780      validations.  The publisher MAY choose to drop Interests that
781
782
783
784Mosko, et al.           Expires September 8, 2018              [Page 14]
785
786Internet-Draft               CCNx Semantics                   March 2018
787
788
789      carry a Validation section if the publisher application does not
790      expect those signatures as this could be a form of computational
791      denial of service.  If the signature requires a key that the
792      publisher does not have, it is NOT RECOMMENDED that the publisher
793      fetch the key over the network, unless it is part of the
794      application's expected behavior.
795
796   o  Retrieve or generate the requested content object and return it to
797      the Interest's previous hop.  If the requested content cannot be
798      returned, the publisher SHOULD reply with an InterestReturn or a
799      content object with application payload that says the content is
800      not available; this content object should have a short ExpiryTime
801      in the future.
802
8032.4.  Forwarder Behavior
804
805   A forwarder routes Interest messages based on a Forwarding
806   Information Base (FIB), returns Content Objects that match Interests
807   to the Interest's previous hop, and processes InterestReturn control
808   messages.  It may also keep a cache of Content Objects in the
809   notional Content Store table.  This document does not specify the
810   internal behavior of a forwarder -- only these and other external
811   behaviors.
812
813   In this document, we will use two processing pipelines, one for
814   Interests and one for Content Objects.  Interest processing is made
815   up of checking for duplicate Interests in the PIT (see
816   Section 2.4.2), checking for a cached Content Object in the Content
817   Store (see Section 2.4.3), and forwarding an Interest via the FIB.
818   Content Store processing is made up of checking for matching
819   Interests in the PIT and forwarding to those previous hops.
820
8212.4.1.  Interest HopLimit
822
823   Interest looping is not prevented in CCNx.  An Interest traversing
824   loops is eventually discarded using the hop-limit field of the
825   Interest, which is decremented at each hop traversed by the Interest.
826
827   Every Interest MUST carry a HopLimit.
828
829   When an Interest is received from another forwarder, the HopLimit
830   MUST be positive.  A forwarder MUST decrement the HopLimit of an
831   Interest by at least 1 before it is forwarded.
832
833   If the HopLimit equals 0, the Interest MUST NOT be forwarded to
834   another forwarder; it MAY be sent to a publisher application or
835   serviced from a local Content Store.
836
837
838
839
840Mosko, et al.           Expires September 8, 2018              [Page 15]
841
842Internet-Draft               CCNx Semantics                   March 2018
843
844
8452.4.2.  Interest Aggregation
846
847   Interest aggregation is when a forwarder receives an Interest message
848   that could be satisfied by another Interest message already forwarded
849   by the node so the forwarder suppresses the new Interest; it only
850   records the additional previous hop so a Content Object sent in
851   response to the first Interest will satisfy both Interests.
852
853   CCNx uses an Interest aggregation rule that assumes the
854   InterestLifetime is akin to a subscription time and is not a network
855   round trip time.  Some previous aggregation rules assumed the
856   lifetime was a round trip time, but this leads to problems of
857   expiring an Interest before a response comes if the RTT is estimated
858   too short or interfering with an ARQ scheme that wants to re-transmit
859   an Interest but a prior interest over-estimated the RTT.
860
861   A forwarder MAY implement an Interest aggregation scheme.  If it does
862   not, then it will forward all Interest messages.  This does not imply
863   that multiple, possibly identical, Content Objects will come back.  A
864   forwarder MUST still satisfy all pending Interests, so one Content
865   Object could satisfy multiple similar interests, even if the
866   forwarded did not suppress duplicate Interest messages.
867
868   A RECOMMENDED Interest aggregation scheme is:
869
870   o  Two Interests are considered 'similar' if they have the same Name,
871      KeyIdRestr, and ContentObjectHashRestr.
872
873   o  Let the notional value InterestExpiry (a local value at the
874      forwarder) be equal to the receive time plus the InterestLifetime
875      (or a platform-dependent default value if not present).
876
877   o  An Interest record (PIT entry) is considered invalid if its
878      InterestExpiry time is in the past.
879
880   o  The first reception of an Interest MUST be forwarded.
881
882   o  A second or later reception of an Interest similar to a valid
883      pending Interest from the same previous hop MUST be forwarded.  We
884      consider these a retransmission requests.
885
886   o  A second or later reception of an Interest similar to a valid
887      pending Interest from a new previous hop MAY be aggregated (not
888      forwarded).
889
890   o  Aggregating an Interest MUST extend the InterestExpiry time of the
891      Interest record.  An implementation MAY keep a single
892      InterestExpiry time for all previous hops or MAY keep the
893
894
895
896Mosko, et al.           Expires September 8, 2018              [Page 16]
897
898Internet-Draft               CCNx Semantics                   March 2018
899
900
901      InterestExpiry time per previous hop.  In the first case, the
902      forwarder might send a Content Object down a path that is no
903      longer waiting for it, in which case the previous hop (next hop of
904      the Content Object) would drop it.
905
9062.4.3.  Content Store Behavior
907
908   The Content Store is a special cache that sits on the fast path of a
909   CCNx forwarder.  It is an optional component.  It serves to repair
910   lost packets and handle flash requests for popular content.  It could
911   be pre-populated or use opportunistic caching.  Because the Content
912   Store could serve to amplify an attach via cache poisoning, there are
913   special rules about how a Content Store behaves.
914
915   1.  A forwarder MAY implement a Content Store.  If it does, the
916       Content Store matches a Content Object to an Interest via the
917       normal matching rules (see Section 9).
918
919   2.  If an Interest has a KeyIdRestr, then the Content Store MUST NOT
920       reply unless it knows the signature on the matching Content
921       Object is correct.  It may do this by external knowledge (i.e.,
922       in a managed network or system with pre-populated caches) or by
923       having the public key and cryptographically verifying the
924       signature.  If the public key is provided in the Content Object
925       itself (i.e., in the PublicKey field) or in the Interest, the
926       Content Store MUST verify that the public key's SHA-256 hash is
927       equal to the KeyId and that it verifies the signature.  A Content
928       Store MAY verify the digital signature of a Content Object before
929       it is cached, but it is not required to do so.  A Content Store
930       SHOULD NOT fetch keys over the network.  If it cannot or has not
931       yet verified the signature, it should treat the Interest as a
932       cache miss.
933
934   3.  If an Interest has an ContentObjectHashRestr, then the Content
935       Store MUST NOT reply unless it knows the the matching Content
936       Object has the correct hash.  If it cannot verify the hash, then
937       it should treat the Interest as a cache miss.
938
939   4.  It must object the Cache Control directives (see Section 4).
940
9412.4.4.  Interest Pipeline
942
943   1.  Perform the HopLimit check (see Section 2.4.1).
944
945   2.  Determine if the Interest can be aggregated, as per
946       Section 2.4.2.  If it can be, aggregate and do not forward the
947       Interest.
948
949
950
951
952Mosko, et al.           Expires September 8, 2018              [Page 17]
953
954Internet-Draft               CCNx Semantics                   March 2018
955
956
957   3.  If forwarding the Interest, check for a hit in the Content Store,
958       as per Section 2.4.3.  If a matching Content Object is found,
959       return it to the Interest's previous hop.  This injects the
960       Content Store as per Section 2.4.5.
961
962   4.  Lookup the Interest in the FIB.  Longest prefix match (LPM) is
963       performed name segment by name segment (not byte or bit).  It
964       SHOULD exclude the Interest's previous hop.  If a match is found,
965       forward the Interest.  If no match is found or the forwarder
966       choses to not forward due to a local condition (e.g.,
967       congestion), it SHOULD send an InterestReturn message, as per
968       Section 10.
969
9702.4.5.  Content Object Pipeline
971
972   1.  It is RECOMMENDED that a forwarder that receives a content object
973       check that the Content Object came from an expected previous hop.
974       An expected previous hop is one pointed to by the FIB or one
975       recorded in the PIT as having had a matching Interest sent that
976       way.
977
978   2.  A Content Object MUST be matched to all pending Interests that
979       satisfy the matching rules (see Section 9).  Each satisfied
980       pending Interest MUST then be removed from the set of pending
981       Interests.
982
983   3.  A forwarder SHOULD NOT send more then one copy of the received
984       Content Object to the same Interest previous hop.  It may happen,
985       for example, that two Interest ask for the same Content Object in
986       different ways (e.g., by name and by name an KeyId) and that they
987       both come from the same previous hop.  It is normal to send the
988       same content object multiple times on the same interface, such as
989       Ethernet, if it is going to different previous hops.
990
991   4.  A Content Object SHOULD only be put in the Content Store if it
992       satisfied an Interest (and passed rule #1 above).  This is to
993       reduce the chances of cache poisoning.
994
9953.  Names
996
997   A CCNx name is a composition of name segments.  Each name segment
998   carries a label identifying the purpose of the name segment, and a
999   value.  For example, some name segments are general names and some
1000   serve specific purposes, such as carrying version information or the
1001   sequencing of many chunks of a large object into smaller, signed
1002   Content Objects.
1003
1004
1005
1006
1007
1008Mosko, et al.           Expires September 8, 2018              [Page 18]
1009
1010Internet-Draft               CCNx Semantics                   March 2018
1011
1012
1013   There are three different types of names in CCNx: prefix, exact, and
1014   full names.  A prefix name is simply a name that does not uniquely
1015   identify a single Content Object, but rather a namespace or prefix of
1016   an existing Content Object name.  An exact name is one which uniquely
1017   identifies the name of a Content Object.  A full name is one which is
1018   exact and is accompanied by an explicit or implicit ConObjHash.  The
1019   ConObjHash is explicit in an Interest and implicit in a Content
1020   Object.
1021
1022   The name segment labels specified in this document are given in the
1023   table below.  Name Segment is a general name segment, typically
1024   occurring in the routable prefix and user-specified content name.
1025   Other segment types are for functional name components that imply a
1026   specific purpose.
1027
1028   A forwarding table entry may contain name segments of any type.
1029   Routing protocol policy and local system policy may limit what goes
1030   into forwarding entries, but there is no restriction at the core
1031   level.  An Interest routing protocol, for example, may only allow
1032   binary name segments.  A load balancer or compute cluster may route
1033   through additional component types, depending on their services.
1034
1035   +-------------+-----------------------------------------------------+
1036   |     Name    | Description                                         |
1037   +-------------+-----------------------------------------------------+
1038   |     Name    | A generic name segment that includes arbitrary      |
1039   |   Segment   | octets.                                             |
1040   |             |                                                     |
1041   |   Interest  | An octet string that identifies the payload carried |
1042   |  Payload ID | in an Interest. As an example, the Payload ID might |
1043   |             | be a hash of the Interest Payload.  This provides a |
1044   |             | way to differentiate between Interests based on the |
1045   |             | Payload solely through a Name Segment without       |
1046   |             | having to include all the extra bytes of the        |
1047   |             | payload itself.                                     |
1048   |             |                                                     |
1049   | Application | An application-specific payload in a name segment.  |
1050   |  Components | An application may apply its own semantics to these |
1051   |             | components.  A good practice is to identify the     |
1052   |             | application in a Name segment prior to the          |
1053   |             | application component segments.                     |
1054   +-------------+-----------------------------------------------------+
1055
1056                     Table 1: CCNx Name Segment Types
1057
1058   At the lowest level, a Forwarder does not need to understand the
1059   semantics of name segments; it need only identify name segment
1060   boundaries and be able to compare two name segments (both label and
1061
1062
1063
1064Mosko, et al.           Expires September 8, 2018              [Page 19]
1065
1066Internet-Draft               CCNx Semantics                   March 2018
1067
1068
1069   value) for equality.  The Forwarder matches paths segment-by-segment
1070   against its forwarding table to determine a next hop.
1071
10723.1.  Name Examples
1073
1074   This section uses the CCNx URI [CCNxURI] representation of CCNx names
1075   .
1076
1077   +--------------------------+----------------------------------------+
1078   |           Name           | Description                            |
1079   +--------------------------+----------------------------------------+
1080   |          ccnx:/          | A 0-length name, corresponds to a      |
1081   |                          | default route.                         |
1082   |                          |                                        |
1083   |       ccnx:/NAME=        | A name with 1 segment of 0 length,     |
1084   |                          | distinct from ccnx:/.                  |
1085   |                          |                                        |
1086   | ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first      |
1087   |                          | segment is of type NAME and the second |
1088   |                          | segment is of type APP:0.              |
1089   +--------------------------+----------------------------------------+
1090
1091                        Table 2: CCNx Name Examples
1092
10933.2.  Interest Payload ID
1094
1095   An Interest may also have a Payload which carries state about the
1096   Interest but is not used to match a Content Object.  If an Interest
1097   contains a payload, the Interest name should contain an Interest
1098   Payload ID (IPID).  The IPID allows a PIT table entry to correctly
1099   multiplex Content Objects in response to a specific Interest with a
1100   specific payload ID.  The IPID could be derived from a hash of the
1101   payload or could be a GUID or a nonce.  An optional Metadata field
1102   defines the IPID field so other systems could verify the IPID, such
1103   as when it is derived from a hash of the payload.  No system is
1104   required to verify the IPID.
1105
11064.  Cache Control
1107
1108   CCNx supports two fields that affect cache control.  These determine
1109   how a cache or Content Store handles a Content Object.  They are not
1110   used in the fast path, but only to determine if a Content Object can
1111   be injected on to the fast path in response to an Interest.
1112
1113   The ExpiryTime is a field that exists within the signature envelope
1114   of a Validation Algorithm.  It is the UTC time in milliseconds after
1115   which the Content Object is considered expired and MUST no longer be
1116
1117
1118
1119
1120Mosko, et al.           Expires September 8, 2018              [Page 20]
1121
1122Internet-Draft               CCNx Semantics                   March 2018
1123
1124
1125   used to respond to an Interest from a cache.  Stale content MAY be
1126   flushed from the cache.
1127
1128   The Recommended Cache Time (RCT) is a field that exists outside the
1129   signature envelope.  It is the UTC time in milliseconds after which
1130   the publisher considers the Content Object to be of low value to
1131   cache.  A cache SHOULD discard it after the RCT, though it MAY keep
1132   it and still respond with it.  A cache MAY discard the content object
1133   before the RCT time too; there is no contractual obligation to
1134   remember anything.
1135
1136   This formulation allows a producer to create a Content Object with a
1137   long ExpiryTime but short RCT and keep re-publishing the same,
1138   signed, Content Object over and over again by extending the RCT.
1139   This allows a form of "phone home" where the publisher wants to
1140   periodically see that the content is being used.
1141
11425.  Content Object Hash
1143
1144   CCNx allows an Interest to restrict a response to a specific hash.
1145   The hash covers the Content Object message body and the validation
1146   sections, if present.  Thus, if a Content Object is signed, its hash
1147   includes that signature value.  The hash does not include the fixed
1148   or hop-by-hop headers of a Content Object.  Because it is part of the
1149   matching rules (see Section 9), the hash is used at every hop.
1150
1151   There are two options for matching the content object hash
1152   restriction in an Interest.  First, a forwarder could compute for
1153   itself the hash value and compare it to the restriction.  This is an
1154   expensive operation.  The second option is for a border device to
1155   compute the hash once and place the value in a header (ConObjHash)
1156   that is carried through the network.  The second option, of course,
1157   removes any security properties from matching the hash, so SHOULD
1158   only be used within a trusted domain.  The header SHOULD be removed
1159   when crossing a trust boundary.
1160
11616.  Link
1162
1163   A Link is the tuple {Name, [KeyIdRestr], [ContentObjectHashRestr]}.
1164   The information in a Link comprises the fields of an Interest which
1165   would retrieve the Link target.  A Content Object with PayloadType =
1166   "Link" is an object whose payload is one or more Links.  This tuple
1167   may be used as a KeyLink to identify a specific object with the
1168   certificate wrapped key.  It is RECOMMENDED to include at least one
1169   of KeyIdRestr or Content ObjectHashRestr.  If neither restriction is
1170   present, then any Content Object with a matching name from any
1171   publisher could be returned.
1172
1173
1174
1175
1176Mosko, et al.           Expires September 8, 2018              [Page 21]
1177
1178Internet-Draft               CCNx Semantics                   March 2018
1179
1180
11817.  Hashes
1182
1183   Several protocol fields use cryptographic hash functions, which must
1184   be secure against attack and collisions.  Because these hash
1185   functions change over time, with better ones appearing and old ones
1186   falling victim to attacks, it is important that a CCNx protocol
1187   implementation supports hash agility.
1188
1189   In this document, we suggest certain hashes (e.g., SHA-256), but a
1190   specific implementation may use what it deems best.  The normative
1191   CCNx Messages [CCNMessages] specification should be taken as the
1192   definition of acceptable hash functions and uses.
1193
11948.  Validation
1195
11968.1.  Validation Algorithm
1197
1198   The Validator consists of a ValidationAlgorithm that specifies how to
1199   verify the message and a ValidationPayload containing the validation
1200   output, e.g., the digital signature or MAC.  The ValidationAlgorithm
1201   section defines the type of algorithm to use and includes any
1202   necessary additional information.  The validation is calculated from
1203   the beginning of the CCNx Message through the end of the
1204   ValidationAlgorithm section.  The ValidationPayload is the integrity
1205   value bytes, such as a MAC or signature.
1206
1207   Some Validators contain a KeyId, identifying the publisher
1208   authenticating the Content Object.  If an Interest carries a
1209   KeyIdRestr, then that KeyIdRestr MUST exactly match the Content
1210   Object's KeyId.
1211
1212   Validation Algorithms fall into three categories: MICs, MACs, and
1213   Signatures.  Validators using Message Integrity Code (MIC) algorithms
1214   do not need to provide any additional information; they may be
1215   computed and verified based only on the algorithm (e.g., CRC32C).
1216   MAC validators require the use of a KeyId identifying the secret key
1217   used by the authenticator.  Because MACs are usually used between two
1218   parties that have already exchanged secret keys via a key exchange
1219   protocol, the KeyId may be any agreed-upon value to identify which
1220   key is used.  Signature validators use public key cryptographic
1221   algorithms such as RSA, DSA, ECDSA.  The KeyId field in the
1222   ValidationAlgorithm identifies the public key used to verify the
1223   signature.  A signature may optionally include a KeyLocator, as
1224   described above, to bundle a Key or Certificate or KeyLink.  MAC and
1225   Signature validators may also include a SignatureTime, as described
1226   above.
1227
1228
1229
1230
1231
1232Mosko, et al.           Expires September 8, 2018              [Page 22]
1233
1234Internet-Draft               CCNx Semantics                   March 2018
1235
1236
1237   A PublicKeyLocator KeyLink points to a Content Object with a DER-
1238   encoded X509 certificate in the payload.  In this case, the target
1239   KeyId must equal the first object's KeyId.  The target KeyLocator
1240   must include the public key corresponding to the KeyId.  That key
1241   must validate the target Signature.  The payload is an X.509
1242   certificate whose public key must match the target KeyLocator's key.
1243   It must be issued by a trusted authority, preferably specifying the
1244   valid namespace of the key in the distinguished name.
1245
12469.  Interest to Content Object matching
1247
1248   A Content Object satisfies an Interest if and only if (a) the Content
1249   Object name, if present, exactly matches the Interest name, and (b)
1250   the ValidationAlgorithm KeyId of the Content Object exactly equals
1251   the Interest KeyIdRestr, if present, and (c) the computed Content
1252   ObjectHash exactly equals the Interest ContentObjectHashRestr, if
1253   present.
1254
1255   The matching rules are given by this predicate, which if it evaluates
1256   true means the Content Object matches the Interest.  Ni = Name in
1257   Interest (may not be empty), Ki = KeyIdRestr in the interest (may be
1258   empty), Hi = ContentObjectHashRestr in Interest (may be empty).
1259   Likewise, No, Ko, Ho are those properties in the Content Object,
1260   where No and Ko may be empty; Ho always exists.  For binary
1261   relations, we use & for AND and | for OR.  We use E for the EXISTS
1262   (not empty) operator and ! for the NOT EXISTS operator.
1263
1264   As a special case, if the ContentObjectHashRestr in the Interest
1265   specifies an unsupported hash algorithm, then no Content Object can
1266   match the Interest so the system should drop the Interest and MAY
1267   send an InterestReturn to the previous hop.  In this case, the
1268   predicate below will never get executed because the Interest is never
1269   forwarded.  If the system is using the optional behavior of having a
1270   different system calculate the hash for it, then the system may
1271   assume all hash functions are supported and leave it to the other
1272   system to accept or reject the Interest.
1273
1274   (!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi)
1275
1276   As one can see, there are two types of attributes one can match.  The
1277   first term depends on the existence of the attribute in the Content
1278   Object while the next two terms depend on the existence of the
1279   attribute in the Interest.  The last term is the "Nameless Object"
1280   restriction which states that if a Content Object does not have a
1281   Name, then it must match the Interest on at least the Hash
1282   restriction.
1283
1284
1285
1286
1287
1288Mosko, et al.           Expires September 8, 2018              [Page 23]
1289
1290Internet-Draft               CCNx Semantics                   March 2018
1291
1292
1293   If a Content Object does not carry the Content ObjectHash as an
1294   expressed field, it must be calculated in network to match against.
1295   It is sufficient within an autonomous system to calculate a Content
1296   ObjectHash at a border router and carry it via trusted means within
1297   the autonomous system.  If a Content Object ValidationAlgorithm does
1298   not have a KeyId then the Content Object cannot match an Interest
1299   with a KeyIdRestr.
1300
130110.  Interest Return
1302
1303   This section describes the process whereby a network element may
1304   return an Interest message to a previous hop if there is an error
1305   processing the Interest.  The returned Interest may be further
1306   processed at the previous hop or returned towards the Interest
1307   origin.  When a node returns an Interest it indicates that the
1308   previous hop should not expect a response from that node for the
1309   Interest -- i.e., there is no PIT entry left at the returning node.
1310
1311   The returned message maintains compatibility with the existing TLV
1312   packet format (a fixed header, optional hop-by-hop headers, and the
1313   CCNx message body).  The returned Interest packet is modified in only
1314   two ways:
1315
1316   o  The PacketType is set to InterestReturn to indicate a Feedback
1317      message.
1318
1319   o  The ReturnCode is set to the appropriate value to signal the
1320      reason for the return
1321
1322   The specific encodings of the Interest Return are specified in
1323   [CCNMessages].
1324
1325   A Forwarder is not required to send any Interest Return messages.
1326
1327   A Forwarder is not required to process any received Interest Return
1328   message.  If a Forwarder does not process Interest Return messages,
1329   it SHOULD silently drop them.
1330
1331   The Interest Return message does not apply to a Content Object or any
1332   other message type.
1333
1334   An Interest Return message is a 1-hop message between peers.  It is
1335   not propagated multiple hops via the FIB.  An intermediate node that
1336   receives an InterestReturn may take corrective actions or may
1337   propagate its own InterestReturn to previous hops as indicated in the
1338   reverse path of a PIT entry.
1339
1340
1341
1342
1343
1344Mosko, et al.           Expires September 8, 2018              [Page 24]
1345
1346Internet-Draft               CCNx Semantics                   March 2018
1347
1348
134910.1.  Message Format
1350
1351   The Interest Return message looks exactly like the original Interest
1352   message with the exception of the two modifications mentioned above.
1353   The PacketType is set to indicate the message is an InterestReturn
1354   and the reserved byte in the Interest header is used as a Return
1355   Code.  The numeric values for the PacketType and ReturnCodes are in
1356   [CCNMessages].
1357
135810.2.  ReturnCode Types
1359
1360   This section defines the InterestReturn ReturnCode introduced in this
1361   RFC.  The numeric values used in the packet are defined in
1362   [CCNMessages].
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400Mosko, et al.           Expires September 8, 2018              [Page 25]
1401
1402Internet-Draft               CCNx Semantics                   March 2018
1403
1404
1405   +----------------------+--------------------------------------------+
1406   | Name                 | Description                                |
1407   +----------------------+--------------------------------------------+
1408   | No Route (Section    | The returning Forwarder has no route to    |
1409   | 10.3.1)              | the Interest name.                         |
1410   |                      |                                            |
1411   | HopLimit Exceeded    | The HopLimit has decremented to 0 and need |
1412   | (Section 10.3.2)     | to forward the packet.                     |
1413   |                      |                                            |
1414   | Interest MTU too     | The Interest's MTU does not conform to the |
1415   | large (Section       | required minimum and would require         |
1416   | 10.3.3)              | fragmentation.                             |
1417   |                      |                                            |
1418   | No Resources         | The node does not have the resources to    |
1419   | (Section 10.3.4)     | process the Interest.                      |
1420   |                      |                                            |
1421   | Path error (Section  | There was a transmission error when        |
1422   | 10.3.5)              | forwarding the Interest along a route (a   |
1423   |                      | transient error).                          |
1424   |                      |                                            |
1425   | Prohibited (Section  | An administrative setting prohibits        |
1426   | 10.3.6)              | processing this Interest.                  |
1427   |                      |                                            |
1428   | Congestion (Section  | The Interest was dropped due to congestion |
1429   | 10.3.7)              | (a transient error).                       |
1430   |                      |                                            |
1431   | Unsupported Content  | The Interest was dropped because it        |
1432   | Object Hash          | requested a Content Object Hash            |
1433   | Algorithm (Section   | Restriction using a hash algorithm that    |
1434   | 10.3.8)              | cannot be computed.                        |
1435   |                      |                                            |
1436   | Malformed Interest   | The Interest was dropped because it did    |
1437   | (Section 10.3.9)     | not correctly parse.                       |
1438   +----------------------+--------------------------------------------+
1439
1440                   Table 3: Interest Return Reason Codes
1441
144210.3.  Interest Return Protocol
1443
1444   This section describes the Forwarder behavior for the various Reason
1445   codes for Interest Return.  A Forwarder is not required to generate
1446   any of the codes, but if it does, it MUST conform to this
1447   specification.
1448
1449   If a Forwarder receives an Interest Return, it SHOULD take these
1450   standard corrective actions.  A forwarder is allowed to ignore
1451   Interest Return messages, in which case its PIT entry would go
1452   through normal timeout processes.
1453
1454
1455
1456Mosko, et al.           Expires September 8, 2018              [Page 26]
1457
1458Internet-Draft               CCNx Semantics                   March 2018
1459
1460
1461   o  Verify that the Interest Return came from a next-hop to which it
1462      actually sent the Interest.
1463
1464   o  If a PIT entry for the corresponding Interest does not exist, the
1465      Forwarder should ignore the Interest Return.
1466
1467   o  If a PIT entry for the corresponding Interest does exist, the
1468      Forwarder MAY do one of the following:
1469
1470      *  Try a different forwarding path, if one exists, and discard the
1471         Interest Return, or
1472
1473      *  Clear the PIT state and send an Interest Return along the
1474         reverse path.
1475
1476   If a forwarder tries alternate routes, it MUST ensure that it does
1477   not use same same path multiple times.  For example, it could keep
1478   track of which next hops it has tried and not re-use them.
1479
1480   If a forwarder tries an alternate route, it may receive a second
1481   InterestReturn, possibly of a different type than the first
1482   InterestReturn.  For example, node A sends an Interest to node B,
1483   which sends a No Route return.  Node A then tries node C, which sends
1484   a Prohibited.  Node A should choose what it thinks is the appropriate
1485   code to send back to its previous hop
1486
1487   If a forwarder tries an alternate route, it should decrement the
1488   Interest Lifetime to account for the time spent thus far processing
1489   the Interest.
1490
149110.3.1.  No Route
1492
1493   If a Forwarder receives an Interest for which it has no route, or for
1494   which the only route is back towards the system that sent the
1495   Interest, the Forwarder SHOULD generate a "No Route" Interest Return
1496   message.
1497
1498   How a forwarder manages the FIB table when it receives a No Route
1499   message is implementation dependent.  In general, receiving a No
1500   Route Interest Return should not cause a forwarder to remove a route.
1501   The dynamic routing protocol that installed the route should correct
1502   the route or the administrator who created a static route should
1503   correct the configuration.  A forwarder could suppress using that
1504   next hop for some period of time.
1505
1506
1507
1508
1509
1510
1511
1512Mosko, et al.           Expires September 8, 2018              [Page 27]
1513
1514Internet-Draft               CCNx Semantics                   March 2018
1515
1516
151710.3.2.  HopLimit Exceeded
1518
1519   A Forwarder MAY choose to send HopLimit Exceeded messages when it
1520   receives an Interest that must be forwarded off system and the
1521   HopLimit is 0.
1522
152310.3.3.  Interest MTU Too Large
1524
1525   If a Forwarder receives an Interest whose MTU exceeds the prescribed
1526   minimum, it MAY send an "Interest MTU Too Large" message, or it may
1527   silently discard the Interest.
1528
1529   If a Forwarder receives an "Interest MTU Too Large" is SHOULD NOT try
1530   alternate paths.  It SHOULD propagate the Interest Return to its
1531   previous hops.
1532
153310.3.4.  No Resources
1534
1535   If a Forwarder receives an Interest and it cannot process the
1536   Interest due to lack of resources, it MAY send an InterestReturn.  A
1537   lack of resources could be the PIT table is too large, or some other
1538   capacity limit.
1539
154010.3.5.  Path Error
1541
1542   If a forwarder detects an error forwarding an Interest, such as over
1543   a reliable link, it MAY send a Path Error Interest Return indicating
1544   that it was not able to send or repair a forwarding error.
1545
154610.3.6.  Prohibited
1547
1548   A forwarder may have administrative policies, such as access control
1549   lists, that prohibit receiving or forwarding an Interest.  If a
1550   forwarder discards an Interest due to a policy, it MAY send a
1551   Prohibited InterestReturn to the previous hop.  For example, if there
1552   is an ACL that says /parc/private can only come from interface e0,
1553   but the Forwarder receives one from e1, the Forwarder must have a way
1554   to return the Interest with an explanation.
1555
155610.3.7.  Congestion
1557
1558   If a forwarder discards an Interest due to congestion, it MAY send a
1559   Congestion InterestReturn to the previous hop.
1560
1561
1562
1563
1564
1565
1566
1567
1568Mosko, et al.           Expires September 8, 2018              [Page 28]
1569
1570Internet-Draft               CCNx Semantics                   March 2018
1571
1572
157310.3.8.  Unsupported Content Object Hash Algorithm
1574
1575   If a Content Object Hash Restriction specifies a hash algorithm the
1576   forwarder cannot verify, the Interest should not be accepted and the
1577   forwarder MAY send an InterestReturn to the previous hop.
1578
157910.3.9.  Malformed Interest
1580
1581   If a forwarder detects a structural or syntactical error in an
1582   Interest, it SHOULD drop the interest and MAY send an InterestReturn
1583   to the previous hop.  This does not imply that any router must
1584   validate the entire structure of an Interest.
1585
158611.  IANA Considerations
1587
1588   This memo includes no request to IANA.
1589
1590   TO_INTERESTLIFETIME = 2 seconds.
1591
159212.  Security Considerations
1593
1594   The CCNx protocol is a layer 3 network protocol, which may also
1595   operate as an overlay using other transports, such as UDP or other
1596   tunnels.  It includes intrinsic support for message authentication
1597   via a signature (e.g.  RSA or elliptic curve) or message
1598   authentication code (e.g.  HMAC).  In lieu of an authenticator, it
1599   may instead use a message integrity check (e.g.  SHA or CRC).  CCNx
1600   does not specify an encryption envelope, that function is left to a
1601   high-layer protocol (e.g. [esic]).
1602
1603   The CCNx message format includes the ability to attach MICs (e.g.
1604   SHA-256 or CRC), MACs (e.g.  HMAC), and Signatures (e.g.  RSA or
1605   ECDSA) to all packet types.  This does not mean that it is a good
1606   idea to use an arbitrary ValidationAlgorithm, nor to include
1607   computationally expensive algorithms in Interest packets, as that
1608   could lead to computational DoS attacks.  Applications should use an
1609   explicit protocol to guide their use of packet signatures.  As a
1610   general guideline, an application might use a MIC on an Interest to
1611   detect unintentionally corrupted packets.  If one wishes to secure an
1612   Interest, one should consider using an encrypted wrapper and a
1613   protocol that prevents replay attacks, especially if the Interest is
1614   being used as an actuator.  Simply using an authentication code or
1615   signature does not make an Interests secure.  There are several
1616   examples in the literature on how to secure ICN-style messaging
1617   [mobile] [ace].
1618
1619   As a layer 3 protocol, this document does not describe how one
1620   arrives at keys or how one trusts keys.  The CCNx content object may
1621
1622
1623
1624Mosko, et al.           Expires September 8, 2018              [Page 29]
1625
1626Internet-Draft               CCNx Semantics                   March 2018
1627
1628
1629   include a public key embedded in the object or may use the
1630   PublicKeyLocator field to point to a public key (or public key
1631   certificate) that authenticates the message.  One key exchange
1632   specification is CCNxKE [ccnxke] [mobile], which is similar to the
1633   TLS 1.3 key exchange except it is over the CCNx layer 3 messages.
1634   Trust is beyond the scope of a layer-3 protocol protocol and left to
1635   applications or application frameworks.
1636
1637   The combination of an ephemeral key exchange (e.g.  CCNxKE [ccnxke])
1638   and an encapsulating encryption (e.g. [esic]) provides the equivalent
1639   of a TLS tunnel.  Intermediate nodes may forward the Interests and
1640   Content Objects, but have no visibility inside.  It also completely
1641   hides the internal names in those used by the encryption layer.  This
1642   type of tunneling encryption is useful for content that has little or
1643   no cache-ability as it can only be used by someone with the ephemeral
1644   key.  Short term caching may help with lossy links or mobility, but
1645   long term caching is usually not of interest.
1646
1647   Broadcast encryption or proxy re-encryption may be useful for content
1648   with multiple uses over time or many consumers.  There is currently
1649   no recommendation for this form of encryption.
1650
1651   The specific encoding of messages will have security implications.
1652   [CCNMessages] uses a type-length-value (TLV) encoding.  We chose to
1653   compromise between extensibility and unambiguous encodings of types
1654   and lengths.  Some TLVs use variable length T and variable length L
1655   fields to accomodate a wide gamut of values while trying to be byte-
1656   efficient.  Our TLV encoding uses a fixed length 2-byte T and 2-byte
1657   L.  Using a fixed-length T and L field solves two problems.  The
1658   first is aliases.  If one is able to encode the same value, such as
1659   0x2 and 0x02, in different byte lengths then one must decide if they
1660   mean the same thing, if they are different, or if one is illegal.  If
1661   they are different, then one must always compare on the buffers not
1662   the integer equivalents.  If one is illegal, then one must validate
1663   the TLV encoding -- every field of every packet at every hop.  If
1664   they are the same, then one has the second problem: how to specify
1665   packet filters.  For example, if a name has 6 name components, then
1666   there are 7 T's and 7 L's, each of which might have up to 4
1667   representations of the same value.  That would be 14 fields with 4
1668   encodings each, or 1001 combinations.  It also means that one cannot
1669   compare, for example, a name via a memory function as one needs to
1670   consider that any embedded T or L might have a different format.
1671
1672   The Interest Return message has no authenticator from the previous
1673   hop.  Therefore, the payload of the Interest Return should only be
1674   used locally to match an Interest.  A node should never forward that
1675   Interest payload as an Interest.  It should also verify that it sent
1676
1677
1678
1679
1680Mosko, et al.           Expires September 8, 2018              [Page 30]
1681
1682Internet-Draft               CCNx Semantics                   March 2018
1683
1684
1685   the Interest in the Interest Return to that node and not allow anyone
1686   to negate Interest messages.
1687
1688   Caching nodes must take caution when processing content objects.  It
1689   is essential that the Content Store obey the rules outlined in
1690   Section 2.4.3 to avoid certain types of attacks.  Unlike NDN, CCNx
1691   1.0 has no mechanism to work around an undesired result from the
1692   network (there are no "excludes"), so if a cache becomes poisoned
1693   with bad content it might cause problems retrieving content.  There
1694   are three types of access to content from a content store:
1695   unrestricted, signature restricted, and hash restricted.  If an
1696   Interest has no restrictions, then the requester is not particular
1697   about what they get back, so any matching cached object is OK.  In
1698   the hash restricted case, the requester is very specific about what
1699   they want and the content store (and every forward hop) can easily
1700   verify that the content matches the request.  In the signature
1701   verified case (often used for initial manifest discovery), the
1702   requester only knows the KeyId that signed the content.  It is this
1703   case that requires the closest attention in the content store to
1704   avoid amplifying bad data.  The content store must only respond with
1705   a content object if it can verify the signature -- this means either
1706   the content object carries the public key inside it or the Interest
1707   carries the public key in addition to the KeyId.  If that is not the
1708   case, then the content store should treat the Interest as a cache
1709   miss and let an endpoint respond.
1710
1711   A user-level cache could perform full signature verification by
1712   fetching a public key according to the PublicKeyLocator.  That is
1713   not, however, a burden we wish to impose on the forwarder.  A user-
1714   level cache could also rely on out-of-band attestation, such as the
1715   cache operator only inserting content that it knows has the correct
1716   signature.
1717
1718   The CCNx grammar allows for hash algorithm agility via the HashType.
1719   It specifies a short list of acceptable hash algorithms that should
1720   be implemented at each forwarder.  Some hash values only apply to end
1721   systems, so updating the hash algorithm does not affect forwarders --
1722   they would simply match the buffer that includes the type-length-hash
1723   buffer.  Some fields, such as the ConObjHash, must be verified at
1724   each hop, so a forwarder (or related system) must know the hash
1725   algorithm and it could cause backward compatibility problems if the
1726   hash type is updated.  [CCNMessages] is the authoritative source for
1727   per-field allowed hash types in that encoding.
1728
1729   A CCNx name uses binary matching whereas a URI uses a case
1730   insensitive hostname.  Some systems may also use case insensitive
1731   matching of the URI path to a resource.  An implication of this is
1732   that human-entered CCNx names will likely have case or non-ASCII
1733
1734
1735
1736Mosko, et al.           Expires September 8, 2018              [Page 31]
1737
1738Internet-Draft               CCNx Semantics                   March 2018
1739
1740
1741   symbol mismatches unless one uses a consistent URI normalization to
1742   the CCNx name.  It also means that an entity that registers a CCNx
1743   routable prefix, say ccnx:/example.com, would need separate
1744   registrations for simple variations like ccnx:/Example.com.  Unless
1745   this is addressed in URI normalization and routing protocol
1746   conventions, there could be phishing attacks.
1747
1748   For a more general introduction to ICN-related security concerns and
1749   approaches, see [RFC7927] and [RFC7945]
1750
175113.  References
1752
175313.1.  Normative References
1754
1755   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1756              Requirement Levels", BCP 14, RFC 2119,
1757              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
1758              editor.org/info/rfc2119>.
1759
176013.2.  Informative References
1761
1762   [ace]      Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang,
1763              "NDN-ACE: Access control for constrained environments over
1764              named data networking", NDN Technical Report NDN-0036,
1765              2015, <http://new.named-data.net/wp-
1766              content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf>.
1767
1768   [befrags]  Mosko, M. and C. Tschudin, "ICN "Begin-End" Hop by Hop
1769              Fragmentation", 2017, <https://www.ietf.org/archive/id/
1770              draft-mosko-icnrg-beginendfragment-02.txt>.
1771
1772   [CCN]      PARC, Inc., "CCNx Open Source", 2007,
1773              <http://www.CCNx.org>.
1774
1775   [ccnlite]  Tschudin, C., et al., University of Basel, "CCN-Lite V2",
1776              2011-2018, <http://www.ccn-lite.net/>.
1777
1778   [CCNMessages]
1779              Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
1780              Format (Internet draft)", 2018, <https://www.ietf.org/id/
1781              draft-irtf-icnrg-ccnxmessages-07.txt>.
1782
1783   [ccnxke]   Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange
1784              Protocol Version 1.0", 2017,
1785              <https://www.ietf.org/archive/id/draft-wood-icnrg-
1786              ccnxkeyexchange-02.txt>.
1787
1788
1789
1790
1791
1792Mosko, et al.           Expires September 8, 2018              [Page 32]
1793
1794Internet-Draft               CCNx Semantics                   March 2018
1795
1796
1797   [CCNxURI]  Mosko, M. and C. Wood, "The CCNx URI Scheme (Internet
1798              draft)", 2017,
1799              <http://tools.ietf.org/html/draft-mosko-icnrg-ccnxuri-02>.
1800
1801   [chunking]
1802              Mosko, M., "CCNx Content Object Chunking", 2016,
1803              <https://www.ietf.org/archive/id/draft-mosko-icnrg-
1804              ccnxchunking-02.txt>.
1805
1806   [cicn]     Muscariello, L., et al., Cisco Systems, "Community ICN
1807              (CICN)", 2017-2018, <https://wiki.fd.io/view/Cicn>.
1808
1809   [dart]     Garcia-Luna-Aceves, J. and M. Mirzazad-Barijough, "A
1810              Light-Weight Forwarding Plane for Content-Centric
1811              Networks", 2016, <https://arxiv.org/pdf/1603.06044.pdf>.
1812
1813   [esic]     Mosko, M. and C. Wood, "Encrypted Sessions In CCNx
1814              (ESIC)", 2017, <https://www.ietf.org/id/draft-wood-icnrg-
1815              esic-01.txt>.
1816
1817   [flic]     Tschudin, C. and C. Wood, "File-Like ICN Collection
1818              (FLIC)", 2017, <https://www.ietf.org/archive/id/draft-
1819              tschudin-icnrg-flic-03.txt>.
1820
1821   [mobile]   Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in
1822              Content-Centric Networks", IFIP Networking, 2017,
1823              <http://dl.ifip.org/db/conf/networking/
1824              networking2017/1570334964.pdf>.
1825
1826   [ndn]      UCLA, "Named Data Networking", 2007,
1827              <http://www.named-data.net>.
1828
1829   [nnc]      Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
1830              Briggs, N., and R. Braynard, "Networking Named Content",
1831              2009, <http://dx.doi.org/10.1145/1658939.1658941>.
1832
1833   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1834              Text on Security Considerations", BCP 72, RFC 3552,
1835              DOI 10.17487/RFC3552, July 2003, <https://www.rfc-
1836              editor.org/info/rfc3552>.
1837
1838   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1839              Resource Identifier (URI): Generic Syntax", STD 66,
1840              RFC 3986, DOI 10.17487/RFC3986, January 2005,
1841              <https://www.rfc-editor.org/info/rfc3986>.
1842
1843
1844
1845
1846
1847
1848Mosko, et al.           Expires September 8, 2018              [Page 33]
1849
1850Internet-Draft               CCNx Semantics                   March 2018
1851
1852
1853   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1854              Specifications: ABNF", STD 68, RFC 5234,
1855              DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
1856              editor.org/info/rfc5234>.
1857
1858   [RFC7927]  Kutscher, D., Eum, S., Pentikousis, K., Psaras, I.,
1859              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
1860              "Information-Centric Networking (ICN) Research
1861              Challenges", 2016, <https://trac.tools.ietf.org/html/
1862              rfc7927>.
1863
1864   [RFC7945]  Pentikousis, K., Ohlman, B., Davies, E., Spirou, S., and
1865              G. Boggia, "Information-Centric Networking: Evaluation and
1866              Security Considerations", 2016,
1867              <https://trac.tools.ietf.org/html/rfc7945>.
1868
1869   [selectors]
1870              Mosko, M., "CCNx Selector Based Discovery", 2017,
1871              <https://raw.githubusercontent.com/mmosko/ccnx-protocol-
1872              rfc/master/docs/build/draft-mosko-icnrg-selectors-01.txt>.
1873
1874   [terminology]
1875              Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
1876              D., and C. Tschudin, "Information-Centric Networking
1877              (ICN): CCN and NDN Terminology", 2017,
1878              <https://www.ietf.org/id/draft-irtf-icnrg-terminology-
1879              00.txt>.
1880
1881Authors' Addresses
1882
1883   Marc Mosko
1884   PARC, Inc.
1885   Palo Alto, California  94304
1886   USA
1887
1888   Phone: +01 650-812-4405
1889   Email: marc.mosko@parc.com
1890
1891
1892   Ignacio Solis
1893   LinkedIn
1894   Mountain View, California  94043
1895   USA
1896
1897   Email: nsolis@linkedin.com
1898
1899
1900
1901
1902
1903
1904Mosko, et al.           Expires September 8, 2018              [Page 34]
1905
1906Internet-Draft               CCNx Semantics                   March 2018
1907
1908
1909   Christopher A. Wood
1910   University of California Irvine
1911   Irvine, California  92697
1912   USA
1913
1914   Phone: +01 315-806-5939
1915   Email: woodc1@uci.edu
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
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]