idnits 2.17.1 draft-irtf-icnrg-ccnxsemantics-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (June 26, 2018) is 2123 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Validation' is mentioned on line 509, but not defined == Missing Reference: 'Lifetime' is mentioned on line 508, but not defined == Missing Reference: 'Name' is mentioned on line 513, but not defined == Missing Reference: 'Payload' is mentioned on line 514, but not defined == Missing Reference: 'PublicKey' is mentioned on line 523, but not defined == Missing Reference: 'SigTime' is mentioned on line 525, but not defined == Missing Reference: 'KeyLink' is mentioned on line 524, but not defined == Missing Reference: 'KeyIdResr' is mentioned on line 543, but not defined == Missing Reference: 'ContentObjectHashRestr' is mentioned on line 1021, but not defined == Missing Reference: 'KeyIdRest' is mentioned on line 559, but not defined == Missing Reference: 'KeyIdRestr' is mentioned on line 1021, but not defined == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-07 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Mosko 3 Internet-Draft PARC, Inc. 4 Intended status: Experimental I. Solis 5 Expires: December 28, 2018 LinkedIn 6 C. Wood 7 University of California Irvine 8 June 26, 2018 10 CCNx Semantics 11 draft-irtf-icnrg-ccnxsemantics-09 13 Abstract 15 This document describes the core concepts of the Content Centric 16 Networking (CCNx) architecture and presents a network protocol based 17 on two messages: Interests and Content Objects. It specifies the set 18 of mandatory and optional fields within those messages and describes 19 their behavior and interpretation. This architecture and protocol 20 specification is independent of a specific wire encoding. 22 The protocol also uses a Control message called an InterestReturn, 23 whereby one system can return an Interest message to the previous hop 24 due to an error condition. This indicates to the previous hop that 25 the current system will not respond to the Interest. 27 This document is a product of the Information Centric Networking 28 research group (ICNRG). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 28, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 67 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 68 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.1. Message Grammar . . . . . . . . . . . . . . . . . . . . . 9 70 2.2. Consumer Behavior . . . . . . . . . . . . . . . . . . . . 12 71 2.3. Publisher Behavior . . . . . . . . . . . . . . . . . . . 14 72 2.4. Forwarder Behavior . . . . . . . . . . . . . . . . . . . 14 73 2.4.1. Interest HopLimit . . . . . . . . . . . . . . . . . . 15 74 2.4.2. Interest Aggregation . . . . . . . . . . . . . . . . 16 75 2.4.3. Content Store Behavior . . . . . . . . . . . . . . . 17 76 2.4.4. Interest Pipeline . . . . . . . . . . . . . . . . . . 18 77 2.4.5. Content Object Pipeline . . . . . . . . . . . . . . . 18 78 3. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 3.1. Name Examples . . . . . . . . . . . . . . . . . . . . . . 20 80 3.2. Interest Payload ID . . . . . . . . . . . . . . . . . . . 21 81 4. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 21 82 5. Content Object Hash . . . . . . . . . . . . . . . . . . . . . 22 83 6. Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 7. Hashes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 8. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 8.1. Validation Algorithm . . . . . . . . . . . . . . . . . . 23 87 9. Interest to Content Object matching . . . . . . . . . . . . . 24 88 10. Interest Return . . . . . . . . . . . . . . . . . . . . . . . 25 89 10.1. Message Format . . . . . . . . . . . . . . . . . . . . . 25 90 10.2. ReturnCode Types . . . . . . . . . . . . . . . . . . . . 26 91 10.3. Interest Return Protocol . . . . . . . . . . . . . . . . 26 92 10.3.1. No Route . . . . . . . . . . . . . . . . . . . . . . 27 93 10.3.2. HopLimit Exceeded . . . . . . . . . . . . . . . . . 28 94 10.3.3. Interest MTU Too Large . . . . . . . . . . . . . . . 28 95 10.3.4. No Resources . . . . . . . . . . . . . . . . . . . . 28 96 10.3.5. Path Error . . . . . . . . . . . . . . . . . . . . . 28 97 10.3.6. Prohibited . . . . . . . . . . . . . . . . . . . . . 28 98 10.3.7. Congestion . . . . . . . . . . . . . . . . . . . . . 29 99 10.3.8. Unsupported Content Object Hash Algorithm . . . . . 29 100 10.3.9. Malformed Interest . . . . . . . . . . . . . . . . . 29 101 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 102 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 13.1. Normative References . . . . . . . . . . . . . . . . . . 32 105 13.2. Informative References . . . . . . . . . . . . . . . . . 32 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 108 1. Introduction 110 This document describes the principles of the CCNx architecture. It 111 describes a network protocol that uses a hierarchical name to forward 112 requests and to match responses to requests. It does not use 113 endpoint addresses, such as Internet Protocol. Restrictions in a 114 request can limit the response by the public key of the response's 115 signer or the cryptographic hash of the response. Every CCNx 116 forwarder along the path does the name matching and restriction 117 checking. The CCNx protocol fits within the broader framework of 118 Information Centric Networking (ICN) protocols [RFC7927]. This 119 document concerns the semantics of the protocol and is not dependent 120 on a specific wire format encoding. The CCNx Messages [CCNMessages] 121 document describes a type-length-value (TLV) wire protocol encoding. 122 This section introduces the main concepts of CCNx, which are further 123 elaborated in the remainder of the document. 125 The CCNx protocol derives from the early ICN work by Jacobson et al. 126 [nnc]. Jacobson's version of CCNx is known as the 0.x version ("CCNx 127 0.x") and the present work is known as the 1.0 version ("CCNx 1.0"). 128 There are two active implementations of CCNx 1.0. The most complete 129 implementation is Community ICN (CINC) [cicn], a Linux Foundation 130 project hosted at fd.io. Another active implementation is CCN-lite 131 [ccnlite], with support for IoT systems and the RIOT operating 132 system. CCNx 0.x formed the basis of the Named Data Networking [ndn] 133 (NDN) university project. 135 The current CCNx 1.0 specification diverges from CCNx 0.x in a few 136 significant areas. The most pronounced behavioral difference between 137 CCNx 0.x and CCNx 1.0 is that CCNx 1.0 has a simpler response 138 processing behavior. In both versions, a forwarder uses a 139 hierarchical longest prefix match of a request name against the 140 forwarding information base (FIB) to send the request through the 141 network to a system that can issue a response. A forwarder must then 142 match a response's name to a request's name to determine the reverse 143 path and deliver the response to the requester. In CCNx 0.x, the 144 Interest name may be a hierarchical prefix of the response name, 145 which allows a form of layer 3 content discovery. In CCNx 1.0, a 146 response's name must exactly equal a request's name. Content 147 discovery is performed by a higher-layer protocol. 149 CCNx Selectors [selectors] is an example of using a higher-layer 150 protocol on top of the CCNx 1.0 layer-3 to perform content discovery. 151 The selector protocol uses a method similar to the original CCNx 0.x 152 techniques without requiring partial name matching of a response to a 153 request in the forwarder. 155 The document represents the consensus of the ICN RG. It is the first 156 ICN protocol from the RG, created from the early CCNx protocol [nnc] 157 with significant revision and input from the ICN community and RG 158 members. The draft has received critical reading by several members 159 of the ICN community and the RG. The authors and RG chairs approve 160 of the contents. The document is sponsored under the IRTF and is not 161 issued by the IETF and is not an IETF standard. This is an 162 experimental protocol and may not be suitable for any specific 163 application and the specification may change in the future. 165 1.1. Requirements Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 1.2. Architecture 173 We describe the architecture of the network in which CCNx operates 174 and introduce certain terminology from [terminology]. The detailed 175 behavior of each component and message grammars are in Section 2. 177 A producer (also called a publisher) is an endpoint that encapsualtes 178 content in Content Objects for transport in the CCNx network. A 179 producer has a public/private keypair and signs (directly or 180 indirectly) the content objects. Usually, the producer's keyid (hash 181 of the public key) is well-known or may be derived from the 182 producer's namespace via standard means. 184 A producer operates within one or more namespaces. A namespace is a 185 name prefix that is represented in the forwarding information base 186 (FIB). This allows a request to reach the producer and fetch a 187 response (if one exists). 189 The forwarding information base (FIB) is a table that tells a 190 forwarder where to send a request. It may point to a local 191 application, a local cache or content store, or to a remote system. 192 If there is no matching entry in the FIB, a forwarder cannot process 193 a request. The detailed rules on name matching to the FIB are given 194 in Section 2.4.4. An endpoint has a FIB, though it may be a simple 195 default route. An intermediate system (i.e. a router) typically has 196 a much larger FIB. A core CCNx forwarder, for example, would know 197 all the global routes. 199 A consumer is an endpoint that requests a name. It is beyond the 200 scope of this document to describe how a consumer learns of a name or 201 publisher keyid -- higher layer protocols build on top of CCNx handle 202 those tasks, such as search engines or lookup services or well known 203 names. The consumer constructs a request, called an Interest, and 204 forwards it via the endpoint's FIB. The consumer should get back 205 either a response, called a Content Object, that matches the Interest 206 or a control message, called an InterestReturn, that indicates the 207 network cannot handle the request. 209 There are three ways to detect errors in Interest handling. An 210 InterestReturn is a network control message that indicates a low- 211 level error like no route or out of resources. If an Interest 212 arrives at a producer, but the producer does not have the requested 213 content, the producer should send an application-specific error 214 message (e.g. a not found message). Finally, a consumer may not 215 receive anything, in which case it should timeout and, depending on 216 the application, retry the request or return an error to the 217 application. 219 1.3. Protocol Overview 221 The goal of CCNx is to name content and retrieve the content from the 222 network without binding it to a specific network endpoint. A routing 223 system (specified separately) populates the forwarding information 224 base (FIB) tables at each CCNx router with hierarchical name prefixes 225 that point towards the content producers under that prefix. A 226 request finds matching content along those paths, in which case a 227 response carries the data, or if no match is found a control message 228 indicates the failure. A request may further refine acceptable 229 responses with a restriction on the response's signer and the 230 cryptographic hash of the response. The details of these 231 restrictions are described below. 233 The CCNx name is a hierarchical series of path segments. Each path 234 segment has a type and zero or more bytes. Matching two names is 235 done as a binary comparison of the type and value, segment by 236 segment. The human-readable form is defined under a URI scheme 237 "ccnx:" [CCNxURI], though the canonical encoding of a name is a 238 series of (type, octet string) pairs. There is no requirement that 239 any path segment be human readable or UTF-8. The first few segments 240 in a name will matched against the FIB and a routing protocol may put 241 its own restrictions on the routable name components (e.g. a maximum 242 length or character encoding rules). In principle, path segments and 243 names have unbounded length, though in practice they are limited by 244 the wire format encoding and practical considerations imposed by a 245 routing protocol. Note that in CCNx path segments use binary 246 comparison whereas in a URI the authority uses case-insensitive 247 hostname (due to DNS). 249 The CCNx name, as used by the forwarder, is purposefully left as a 250 general octet-encoded type and value without any requirements on 251 human readability and character encoding. The reason for this is 252 that we are concerned with how a forwarder processes names. We 253 expect that applications, routing protocols, or other higher layers 254 will apply their own conventions and restrictions on the allowed path 255 segment types and path segment values. 257 CCNx is a request and response protocol to fetch chunks of data using 258 a name. The integrity of each chunk may be directly asserted through 259 a digital signature or Message Authentication Code (MAC), or, 260 alternatively, indirectly via hash chains. Chunks may also carry 261 weaker message integrity checks (MICs) or no integrity protection 262 mechanism at all. Because provenance information is carried with 263 each chunk (or larger indirectly protected block), we no longer need 264 to rely on host identities, such as those derived from TLS 265 certificates, to ascertain the chunk legitimacy. Data integrity is 266 therefore a core feature of CCNx; it does not rely on the data 267 transmission channel. There are several options for data 268 confidentiality, discussed later. 270 This document only defines the general properties of CCNx names. In 271 some isolated environments, CCNx users may be able to use any name 272 they choose and either inject that name (or prefix) into a routing 273 protocol or use other information foraging techniques. In the 274 Internet environment, there will be policies around the formats of 275 names and assignments of names to publishers, though those are not 276 specified here. 278 The key concept of CCNx is that a subjective name is 279 cryptographically bound to a fixed payload. These publisher- 280 generated bindings can therefore be cryptographically verified. A 281 named payload is thus the tuple {{Name, ExtraFields, Payload, 282 ValidationAlgorithm}, ValidationPayload}, where all fields in the 283 inner tuple are covered by the validation payload (e.g. signature). 284 Consumers of this data can check the binding integrity by re- 285 computing the same cryptographic hash and verifying the digital 286 signature in ValidationPayload. 288 In addition to digital signatures (e.g. RSA), CCNx also supports 289 message authentication codes (e.g. HMAC) and message integrity codes 290 (e.g. SHA-256 or CRC). To maintain the cryptographic binding, there 291 should be at least one object with a signature or authentication 292 code, but not all objects require it. For example, a first object 293 with a signature could refer to other objects via a hash chain, a 294 Merkle tree, or a signed manifest. The later objects may not have 295 any validation and rely purely on the references. The use of an 296 integrity code (e.g. CRC) is intended for detecting accidental 297 corruption in an Interest. 299 CCNx specifies a network protocol around Interests (request messages) 300 and Content Objects (response messages) to move named payloads. An 301 Interest includes the Name -- which identifies the desired response 302 -- and optional matching restrictions. Restrictions limit the 303 possible matching Content Objects. Two restrictions exist: 304 KeyIdRestr and ContentObjectHashRestr. The first restriction on the 305 KeyId limits responses to those signed with a ValidationAlgorithm 306 KeyId field equal to the restriction. The second is the Content 307 ObjectHash restriction, which limits the response to one where the 308 cryptographic hash of the entire named payload is equal to the 309 restriction. 311 The hierarchy of a CCNx Name is used for routing via the longest 312 matching prefix in a Forwarder. The longest matching prefix is 313 computed name segment by name segment in the hierarchical path name, 314 where each name segment must be exactly equal to match. There is no 315 requirement that the prefix be globally routable. Within a 316 deployment any local routing may be used, even one that only uses a 317 single flat (non-hierarchical) name segment. 319 Another concept of CCNx is that there should be flow balance between 320 Interest messages and Content Object messages. At the network level, 321 an Interest traveling along a single path should elicit no more than 322 one Content Object response. If some node sends the Interest along 323 more than one path, that node should consolidate the responses such 324 that only one Content Object flows back towards the requester. If an 325 Interest is sent broadcast or multicast on a multiple-access media, 326 the sender should be prepared for multiple responses unless some 327 other media-dependent mechanism like gossip suppression or leader 328 election is used. 330 As an Interest travels the forward path following the Forwarding 331 Information Base (FIB), it establishes state at each forwarder such 332 that a Content Object response can trace its way back to the original 333 requester(s) without the requester needing to include a routable 334 return address. We use the notional Pending Interest Table (PIT) as 335 a method to store state that facilitates the return of a Content 336 Object. 338 The notional PIT table stores the last hop of an Interest plus its 339 Name and optional restrictions. This is the data required to match a 340 Content Object to an Interest (see Section 9). When a Content Object 341 arrives, it must be matched against the PIT to determine which 342 entries it satisfies. For each such entry, at most one copy of the 343 Content Object is sent to each listed last hop in the PIT entries. 345 An actual PIT table is not mandated by the specification. An 346 implementation may use any technique that gives the same external 347 behavior. There are, for example, research papers that use 348 techniques like label switching in some parts of the network to 349 reduce the per-node state incurred by the PIT table [dart]. Some 350 implementations store the PIT state in the FIB, so there is not a 351 second table. 353 If multiple Interests with the same {Name, KeyIdRestr, 354 ContentObjectHashRestr} tuple arrive at a node before a Content 355 Object matching the first Interest comes back, they are grouped in 356 the same PIT entry and their last hops aggregated (see 357 Section 2.4.2). Thus, one Content Object might satisfy multiple 358 pending Interests in a PIT. 360 In CCNx, higher-layer protocols are often called "name-based 361 protocols" because they operate on the CCNx Name. For example, a 362 versioning protocol might append additional name segments to convey 363 state about the version of payload. A content discovery protocol 364 might append certain protocol-specific name segments to a prefix to 365 discover content under that prefix. Many such protocols may exist 366 and apply their own rules to Names. They may be layered with each 367 protocol encapsulating (to the left) a higher layer's Name prefix. 369 This document also describes a control message called an 370 InterestReturn. A network element may return an Interest message to 371 a previous hop if there is an error processing the Interest. The 372 returned Interest may be further processed at the previous hop or 373 returned towards the Interest origin. When a node returns an 374 Interest it indicates that the previous hop should not expect a 375 response from that node for the Interest, i.e., there is no PIT entry 376 left at the returning node for a Content Object to follow. 378 There are multiple ways to describe larger objects in CCNx. 379 Aggregating layer-3 content objects in to larger objects is beyond 380 the scope of this document. One proposed method, FLIC [flic], uses a 381 manifest to enumerate the pieces of a larger object. Manifests are, 382 themselves, Content Objects. Another option is to use a convention 383 in the Content Object name, as in the CCNx Chunking [chunking] 384 protocol where a large object is broken in to small chunks and each 385 chunk receives a special name component indicating its serial order. 387 At the semantic level, described in this document, we do not address 388 fragmentation. One experimental fragmentation protocol, BeginEnd 389 Fragments [befrags] uses a multipoint-PPP style technique for use 390 over layer-2 interfaces with the CCNx Messages [CCNMessages] TLV wire 391 forman specification. 393 With these concepts, the remainder of the document specifies the 394 behavior of a forwarder in processing Interest, Content Object, and 395 InterestReturn messages. 397 2. Protocol 399 CCNx is a request and response protocol. A request is called an 400 Interest and a response is called a Content Object. CCNx also uses a 401 1-hop control message called InterestReturn. These are, as a group, 402 called CCNx Messages. 404 2.1. Message Grammar 406 The CCNx message ABNF [RFC5234] grammar is shown in Figure 1. The 407 grammar does not include any encoding delimiters, such as TLVs. 408 Specific wire encodings are given in a separate document. If a 409 Validation section exists, the Validation Algorithm covers from the 410 Body (BodyName or BodyOptName) through the end of the ValidationAlg 411 section. The InterestLifetime, CacheTime, and Return Code fields 412 exist outside of the validation envelope and may be modified. 414 The various fields -- in alphabetical order -- are defined as: 416 o AbsTime: Absolute times are conveyed as the 64-bit UTC time in 417 milliseconds since the epoch (standard POSIX time). 419 o CacheTime: The absolute time after which the publisher believes 420 there is low value in caching the content object. This is a 421 recommendation to caches (see Section 4). 423 o ConObjField: These are optional fields that may appear in a 424 Content Object. 426 o ConObjHash: The value of the Content Object Hash, which is the 427 SHA256-32 over the message from the beginning of the body to the 428 end of the message. Note that this coverage area is different 429 from the ValidationAlg. This value SHOULD NOT be trusted across 430 domains (see Section 5). 432 o ExpiryTime: An absolute time after which the content object should 433 be considered expired (see Section 4). 435 o Hash: Hash values carried in a Message carry a HashType to 436 identify the algorithm used to generate the hash followed by the 437 hash value. This form is to allow hash agility. Some fields may 438 mandate a specific HashType. 440 o HopLimit: Interest messages may loop if there are loops in the 441 forwarding plane. To eventually terminate loops, each Interest 442 carries a HopLimit that is decremented after each hop and no 443 longer forwarded when it reaches zero. See Section 2.4. 445 o InterestField: These are optional fields that may appear in an 446 Interest message. 448 o KeyIdRestr: The KeyId Restriction. A Content Object must have a 449 KeyId with the same value as the restriction. 451 o ContentObjectHashRestr: The Content Object Hash Restriction. A 452 content object must hash to the same value as the restriction 453 using the same HashType. The ContentObjectHashRestr MUST use 454 SHA256-32. 456 o KeyId: An identifier for the key used in the ValidationAlg. For 457 public key systems, this should be the SHA-256 hash of the public 458 key. For symmetric key systems, it should be an identifier agreed 459 upon by the parties. 461 o KeyLink: A Link (see Section 6) that names how to retrieve the key 462 used to verify the ValidationPayload. A message SHOULD NOT have 463 both a KeyLink and a PublicKey. 465 o Lifetime: The approximate time during which a requester is willing 466 to wait for a response, usually measured in seconds. It is not 467 strongly related to the network round trip time, though it must 468 necessarily be larger. 470 o Name: A name is made up of a non-empty first segment followed by 471 zero or more additional segments, which may be of 0 length. Path 472 segments are opaque octet strings, and are thus case-sensitive if 473 encoding UTF-8. An Interest MUST have a Name. A Content Object 474 MAY have a Name (see Section 9). The segments of a name are said 475 to be complete if its segments uniquely identify a single Content 476 Object. A name is exact if its segments are complete. An 477 Interest carrying a full name is one which specifies an exact name 478 and the ContentObjectHashRestr of the corresponding Content 479 Object. 481 o Payload: The message's data, as defined by PayloadType. 483 o PayloadType: The format of the Payload. If missing, assume 484 DataType. DataType means the payload is opaque application bytes. 485 KeyType means the payload is a DER-encoded public key. LinkType 486 means it is one or more Links (see Section 6). 488 o PublicKey: Some applications may wish to embed the public key used 489 to verify the signature within the message itself. The PublickKey 490 is DER encoded. A message SHOULD NOT have both a KeyLink and a 491 PublicKey. 493 o RelTime: A relative time, measured in milli-seconds. 495 o ReturnCode: States the reason an Interest message is being 496 returned to the previous hop (see Section 10.2). 498 o SigTime: The absolute time (UTC milliseconds) when the signature 499 was generated. 501 o Vendor: Vendor-specific opaque data. The Vendor data includes the 502 IANA Private Enterprise Numbers [EpriseNumbers], followed by 503 vendor-specific information. CCNx allows vendor-specific data in 504 most locations of the grammar. 506 Message := Interest / ContentObject / InterestReturn 507 Interest := IntHdr BodyName [Validation] 508 IntHdr := HopLimit [Lifetime] *Vendor 509 ContentObject := ConObjHdr BodyOptName [Validation] 510 ConObjHdr := [CacheTime / ConObjHash] *Vendor 511 InterestReturn:= ReturnCode Interest 512 BodyName := Name Common 513 BodyOptName := [Name] Common 514 Common := *Field [Payload] 515 Validation := ValidationAlg ValidatonPayload 517 Name := FirstSegment *Segment 518 FirstSegment := 1* OCTET / Vendor 519 Segment := 0* OCTET / Vendor 521 ValidationAlg := (RSA-SHA256 / HMAC-SHA256 / CRC32C) *Vendor 522 ValidatonPayload := 1* OCTET 523 RSA-SHA256 := KeyId [PublicKey] [SigTime] [KeyLink] 524 HMAC-SHA256 := KeyId [SigTime] [KeyLink] 525 CRC32C := [SigTime] 527 AbsTime := 8 OCTET ; 64-bit UTC msec since epoch 528 CacheTime := AbsTime 529 ConObjField := ExpiryTime / PayloadType 530 ConObjHash := Hash ; The Content Object Hash 531 DataType := "1" 532 ExpiryTime := AbsTime 533 Field := InterestField / ConObjField / Vendor 534 Hash := HashType 1* OCTET 535 HashType := SHA256-32 / SHA512-64 / SHA512-32 536 HopLimit := OCTET 537 InterestField := KeyIdRestr / ContentObjectHashRestr 538 KeyId := 1* OCTET ; key identifier 539 KeyIdRestr := 1* OCTET 540 KeyLink := Link 541 KeyType := "2" 542 Lifetime := RelTime 543 Link := Name [KeyIdResr] [ContentObjectHashRestr] 544 LinkType := "3" 545 ContentObjectHashRestr := Hash 546 Payload := *OCTET 547 PayloadType := DataType / KeyType / LinkType 548 PublicKey := ; DER-encoded public key 549 RelTime := 1* OCTET ; msec 550 ReturnCode := ; see Section 10.2 551 SigTime := AbsTime 552 Vendor := PEN 0* OCTET 553 PEN := ; IANA Private Enterprise Number 555 Figure 1 557 2.2. Consumer Behavior 559 To request a piece of content for a given {Name, [KeyIdRest], 560 [ContentObjectHashRestr]} tuple, a consumer creates an Interest 561 message with those values. It MAY add a validation section, 562 typically only a CRC32C. A consumer MAY put a Payload field in an 563 Interest to send additional data to the producer beyond what is in 564 the Name. The Name is used for routing and may be remembered at each 565 hop in the notional PIT table to facilitate returning a content 566 object; Storing large amounts of state in the Name could lead to high 567 memory requirements. Because the Payload is not considered when 568 forwarding an Interest or matching a Content Object to an Interest, a 569 consumer SHOULD put an Interest Payload ID (see Section 3.2) as part 570 of the name to allow a forwarder to match Interests to content 571 objects and avoid aggregating Interests with different payloads. 572 Similarly, if a consumer uses a MAC or a signature, it SHOULD also 573 include a unique segment as part of the name to prevent the Interest 574 from being aggregated with other Interests or satisfied by a Content 575 Object that has no relation to the validation. 577 The consumer SHOULD specify an InterestLifetime, which is the length 578 of time the consumer is willing to wait for a response. The 579 InterestLifetime is an application-scale time, not a network round 580 trip time (see Section 2.4.2). If not present, the InterestLifetime 581 will use a default value (TO_INTERESTLIFETIME). 583 The consumer SHOULD set the Interest HopLimit to a reasonable value 584 or use the default 255. If the consumer knows the distances to the 585 producer via routing, it SHOULD use that value. 587 A consumer hands off the Interest to its first forwarder, which will 588 then forward the Interest over the network to a publisher (or 589 replica) that may satisfy it based on the name (see Section 2.4). 591 Interest messages are unreliable. A consumer SHOULD run a transport 592 protocol that will retry the Interest if it goes unanswered, up to 593 the InterestLifetime. No transport protocol is specified in this 594 document. 596 The network MAY send to the consumer an InterestReturn message that 597 indicates the network cannot fulfill the Interest. The ReturnCode 598 specifies the reason for the failure, such as no route or congestion. 599 Depending on the ReturnCode, the consumer MAY retry the Interest or 600 MAY return an error to the requesting application. 602 If the content was found and returned by the first forwarder, the 603 consumer will receive a Content Object. The consumer SHOULD: 605 o Ensure the content object is properly formatted. 607 o Verify that the returned Name matches a pending request. If the 608 request also had KeyIdRestr or ObjHashRest, it MUST also validate 609 those properties. 611 o If the content object is signed, it SHOULD cryptographically 612 verify the signature. If it does not have the corresponding key, 613 it SHOULD fetch the key, such as from a key resolution service or 614 via the KeyLink. 616 o If the signature has a SigTime, the consumer MAY use that in 617 considering if the signature is valid. For example, if the 618 consumer is asking for dynamically generated content, it should 619 expect the SigTime to not be before the time the Interest was 620 generated. 622 o If the content object is signed, it should assert the 623 trustworthiness of the signing key to the namespace. Such an 624 assertion is beyond the scope of this document, though one may use 625 traditional PKI methods, a trusted key resolution service, or 626 methods like [trust]. 628 o It MAY cache the content object for future use, up to the 629 ExpiryTime if present. 631 o A consumer MAY accept a content object off the wire that is 632 expired. It may happen that a packet expires while in flight, and 633 there is no requirement that forwarders drop expired packets in 634 flight. The only requirement is that content stores, caches, or 635 producers MUST NOT respond with an expired content object. 637 2.3. Publisher Behavior 639 This document does not specify the method by which names populate a 640 Forwarding Information Base (FIB) table at forwarders (see 641 Section 2.4). A publisher is either configured with one or more name 642 prefixes under which it may create content, or it chooses its name 643 prefixes and informs the routing layer to advertise those prefixes. 645 When a publisher receives an Interest, it SHOULD: 647 o Verify that the Interest is part of the publishers namespace(s). 649 o If the Interest has a Validation section, verify the 650 ValidationPayload. Usually an Interest will only have a CRC32C 651 unless the publisher application specifically accommodates other 652 validations. The publisher MAY choose to drop Interests that 653 carry a Validation section if the publisher application does not 654 expect those signatures as this could be a form of computational 655 denial of service. If the signature requires a key that the 656 publisher does not have, it is NOT RECOMMENDED that the publisher 657 fetch the key over the network, unless it is part of the 658 application's expected behavior. 660 o Retrieve or generate the requested content object and return it to 661 the Interest's previous hop. If the requested content cannot be 662 returned, the publisher SHOULD reply with an InterestReturn or a 663 content object with application payload that says the content is 664 not available; this content object should have a short ExpiryTime 665 in the future or not be cacheable (i.e. an expiry time of 0). 667 2.4. Forwarder Behavior 669 A forwarder routes Interest messages based on a Forwarding 670 Information Base (FIB), returns Content Objects that match Interests 671 to the Interest's previous hop, and processes InterestReturn control 672 messages. It may also keep a cache of Content Objects in the 673 notional Content Store table. This document does not specify the 674 internal behavior of a forwarder -- only these and other external 675 behaviors. 677 In this document, we will use two processing pipelines, one for 678 Interests and one for Content Objects. Interest processing is made 679 up of checking for duplicate Interests in the PIT (see 680 Section 2.4.2), checking for a cached Content Object in the Content 681 Store (see Section 2.4.3), and forwarding an Interest via the FIB. 682 Content Store processing is made up of checking for matching 683 Interests in the PIT and forwarding to those previous hops. 685 2.4.1. Interest HopLimit 687 Interest looping is not prevented in CCNx. An Interest traversing 688 loops is eventually discarded using the hop-limit field of the 689 Interest, which is decremented at each hop traversed by the Interest. 691 A loop may also terminate because the Interest is aggregated with 692 it's previous PIT entry along the loop. In this case, the Content 693 will be sent back along the loop and eventually return to a node that 694 already forwarded the content, so it will likely not have a PIT entry 695 any more. When the content reaches a node without a PIT entry, it 696 will be discarded. It may be that a new Interest or another looped 697 Interest will return to that same node, in which case the node will 698 either return a cached response to make a new PIT entry, as below. 700 The HopLimit is the last resort method to stop Interest loops where a 701 Content Object chases an Interest around a loop and where the 702 intermediate nodes, for whatever reason, no longer have a PIT entry 703 and do not cache the Content Object. 705 Every Interest MUST carry a HopLimit. An Interest received from a 706 local application MAY have a 0 HopLimit, which restricts the Interest 707 to other local sources. 709 When an Interest is received from another forwarder, the HopLimit 710 MUST be positive, otherwise the forwarder will discard the Interest. 711 A forwarder MUST decrement the HopLimit of an Interest by at least 1 712 before it is forwarded. 714 If the decremented HopLimit equals 0, the Interest MUST NOT be 715 forwarded to another forwarder; it MAY be sent to a local publisher 716 application or serviced from a local Content Store. 718 A RECOMMENDED HopLimit processing pipeline is below: 720 o If Interest received from a remote system: 722 * If received HopLimit is 0, optionally send InterestReturn 723 (HopLimit Exceeded), and discard Interest. 725 * Otherwise, decrement the HopLimit by 1. 727 o Process as per Content Store and Aggregation rules. 729 o If the Interest will be forwarded: 731 * If the (potentailly decremented) HopLimit is 0, restrict 732 forwarding to the local system. 734 * Otherwise, forward as desired to local or remote systems. 736 2.4.2. Interest Aggregation 738 Interest aggregation is when a forwarder receives an Interest message 739 that could be satisfied by the response to another Interest message 740 already forwarded by the node, so the forwarder suppresses forwarding 741 the new Interest; it only records the additional previous hop so a 742 Content Object sent in response to the first Interest will satisfy 743 both Interests. 745 CCNx uses an Interest aggregation rule that assumes the 746 InterestLifetime is akin to a subscription time and is not a network 747 round trip time. Some previous aggregation rules assumed the 748 lifetime was a round trip time, but this leads to problems of 749 expiring an Interest before a response comes if the RTT is estimated 750 too short or interfering with an ARQ scheme that wants to re-transmit 751 an Interest but a prior interest over-estimated the RTT. 753 A forwarder MAY implement an Interest aggregation scheme. If it does 754 not, then it will forward all Interest messages. This does not imply 755 that multiple, possibly identical, Content Objects will come back. A 756 forwarder MUST still satisfy all pending Interests, so one Content 757 Object could satisfy multiple similar interests, even if the 758 forwarded did not suppress duplicate Interest messages. 760 A RECOMMENDED Interest aggregation scheme is: 762 o Two Interests are considered 'similar' if they have the same Name, 763 KeyIdRestr, and ContentObjectHashRestr. 765 o Let the notional value InterestExpiry (a local value at the 766 forwarder) be equal to the receive time plus the InterestLifetime 767 (or a platform-dependent default value if not present). 769 o An Interest record (PIT entry) is considered invalid if its 770 InterestExpiry time is in the past. 772 o The first reception of an Interest MUST be forwarded. 774 o A second or later reception of an Interest similar to a valid 775 pending Interest from the same previous hop MUST be forwarded. We 776 consider these a retransmission requests. 778 o A second or later reception of an Interest similar to a valid 779 pending Interest from a new previous hop MAY be aggregated (not 780 forwarded). If this Interest has a larger HopLimit than the 781 pending Interest, it MUST be forwarded. 783 o Aggregating an Interest MUST extend the InterestExpiry time of the 784 Interest record. An implementation MAY keep a single 785 InterestExpiry time for all previous hops or MAY keep the 786 InterestExpiry time per previous hop. In the first case, the 787 forwarder might send a Content Object down a path that is no 788 longer waiting for it, in which case the previous hop (next hop of 789 the Content Object) would drop it. 791 2.4.3. Content Store Behavior 793 The Content Store is a special cache that is an integral part of a 794 CCNx forwarder. It is an optional component. It serves to repair 795 lost packets and handle flash requests for popular content. It could 796 be pre-populated or use opportunistic caching. Because the Content 797 Store could serve to amplify an attack via cache poisoning, there are 798 special rules about how a Content Store behaves. 800 1. A forwarder MAY implement a Content Store. If it does, the 801 Content Store matches a Content Object to an Interest via the 802 normal matching rules (see Section 9). 804 2. If an Interest has a KeyIdRestr, then the Content Store MUST NOT 805 reply unless it knows the signature on the matching Content 806 Object is correct. It may do this by external knowledge (i.e., 807 in a managed network or system with pre-populated caches) or by 808 having the public key and cryptographically verifying the 809 signature. A Content Store is NOT REQURIED to verify signatures; 810 if it does not, then it treats these cases like a cache miss. 812 3. If a Content Store chooses to verify signatures, then it MAY do 813 so as follows. If the public key is provided in the Content 814 Object itself (i.e., in the PublicKey field) or in the Interest, 815 the Content Store MUST verify that the public key's SHA-256 hash 816 is equal to the KeyId and that it verifies the signature. A 817 Content Store MAY verify the digital signature of a Content 818 Object before it is cached, but it is not required to do so. A 819 Content Store SHOULD NOT fetch keys over the network. If it 820 cannot or has not yet verified the signature, it should treat the 821 Interest as a cache miss. 823 4. If an Interest has an ContentObjectHashRestr, then the Content 824 Store MUST NOT reply unless it knows the the matching Content 825 Object has the correct hash. If it cannot verify the hash, then 826 it should treat the Interest as a cache miss. 828 5. It must obey the Cache Control directives (see Section 4). 830 2.4.4. Interest Pipeline 832 1. Perform the HopLimit check (see Section 2.4.1). 834 2. Determine if the Interest can be aggregated, as per 835 Section 2.4.2. If it can be, aggregate and do not forward the 836 Interest. 838 3. If forwarding the Interest, check for a hit in the Content Store, 839 as per Section 2.4.3. If a matching Content Object is found, 840 return it to the Interest's previous hop. This injects the 841 Content Store as per Section 2.4.5. 843 4. Lookup the Interest in the FIB. Longest prefix match (LPM) is 844 performed name segment by name segment (not byte or bit). It 845 SHOULD exclude the Interest's previous hop. If a match is found, 846 forward the Interest. If no match is found or the forwarder 847 choses to not forward due to a local condition (e.g., 848 congestion), it SHOULD send an InterestReturn message, as per 849 Section 10. 851 2.4.5. Content Object Pipeline 853 1. It is RECOMMENDED that a forwarder that receives a content object 854 check that the Content Object came from an expected previous hop. 855 An expected previous hop is one pointed to by the FIB or one 856 recorded in the PIT as having had a matching Interest sent that 857 way. 859 2. A Content Object MUST be matched to all pending Interests that 860 satisfy the matching rules (see Section 9). Each satisfied 861 pending Interest MUST then be removed from the set of pending 862 Interests. 864 3. A forwarder SHOULD NOT send more then one copy of the received 865 Content Object to the same Interest previous hop. It may happen, 866 for example, that two Interest ask for the same Content Object in 867 different ways (e.g., by name and by name an KeyId) and that they 868 both come from the same previous hop. It is normal to send the 869 same content object multiple times on the same interface, such as 870 Ethernet, if it is going to different previous hops. 872 4. A Content Object SHOULD only be put in the Content Store if it 873 satisfied an Interest (and passed rule #1 above). This is to 874 reduce the chances of cache poisoning. 876 3. Names 878 A CCNx name is a composition of name segments. Each name segment 879 carries a label identifying the purpose of the name segment, and a 880 value. For example, some name segments are general names and some 881 serve specific purposes, such as carrying version information or the 882 sequencing of many chunks of a large object into smaller, signed 883 Content Objects. 885 There are three different types of names in CCNx: prefix, exact, and 886 full names. A prefix name is simply a name that does not uniquely 887 identify a single Content Object, but rather a namespace or prefix of 888 an existing Content Object name. An exact name is one which uniquely 889 identifies the name of a Content Object. A full name is one which is 890 exact and is accompanied by an explicit or implicit ConObjHash. The 891 ConObjHash is explicit in an Interest and implicit in a Content 892 Object. 894 Note that a forwarder does not need to know any semantics about a 895 name. It only needs to be able to match a prefix to forward 896 Interests and match an exact or full name to forward Content Objects. 897 It is not sensitive to the name segment types. 899 The name segment labels specified in this document are given in the 900 table below. Name Segment is a general name segment, typically 901 occurring in the routable prefix and user-specified content name. 902 Other segment types are for functional name components that imply a 903 specific purpose. 905 +-------------+-----------------------------------------------------+ 906 | Name | Description | 907 +-------------+-----------------------------------------------------+ 908 | Name | A generic name segment that includes arbitrary | 909 | Segment | octets. | 910 | | | 911 | Interest | An octet string that identifies the payload carried | 912 | Payload ID | in an Interest. As an example, the Payload ID might | 913 | | be a hash of the Interest Payload. This provides a | 914 | | way to differentiate between Interests based on the | 915 | | Payload solely through a Name Segment without | 916 | | having to include all the extra bytes of the | 917 | | payload itself. | 918 | | | 919 | Application | An application-specific payload in a name segment. | 920 | Components | An application may apply its own semantics to these | 921 | | components. A good practice is to identify the | 922 | | application in a Name segment prior to the | 923 | | application component segments. | 924 +-------------+-----------------------------------------------------+ 926 Table 1: CCNx Name Segment Types 928 At the lowest level, a Forwarder does not need to understand the 929 semantics of name segments; it need only identify name segment 930 boundaries and be able to compare two name segments (both label and 931 value) for equality. The Forwarder matches paths segment-by-segment 932 against its forwarding table to determine a next hop. 934 3.1. Name Examples 936 This section uses the CCNx URI [CCNxURI] representation of CCNx 937 names. Note that as per the message grammar, an Interest must have a 938 Name with at least one name segment and that name segment must have 939 at least 1 octet of value. A Content Object must have a similar name 940 or no name at all. The FIB, on the other hand, could have 0-length 941 names (a default route), or a first name segment with no value, or a 942 regular name. 944 +--------------------------+----------------------------------------+ 945 | Name | Description | 946 +--------------------------+----------------------------------------+ 947 | ccnx:/ | A 0-length name, corresponds to a | 948 | | default route. | 949 | | | 950 | ccnx:/NAME= | A name with 1 segment of 0 length, | 951 | | distinct from ccnx:/. | 952 | | | 953 | ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first | 954 | | segment is of type NAME and the second | 955 | | segment is of type APP:0. | 956 +--------------------------+----------------------------------------+ 958 Table 2: CCNx Name Examples 960 3.2. Interest Payload ID 962 An Interest may also have a Payload which carries state about the 963 Interest but is not used to match a Content Object. If an Interest 964 contains a payload, the Interest name should contain an Interest 965 Payload ID (IPID). The IPID allows a PIT table entry to correctly 966 multiplex Content Objects in response to a specific Interest with a 967 specific payload ID. The IPID could be derived from a hash of the 968 payload or could be a GUID or a nonce. An optional Metadata field 969 defines the IPID field so other systems could verify the IPID, such 970 as when it is derived from a hash of the payload. No system is 971 required to verify the IPID. 973 4. Cache Control 975 CCNx supports two fields that affect cache control. These determine 976 how a cache or Content Store handles a Content Object. They are not 977 used in the fast path, but only to determine if a Content Object can 978 be injected on to the fast path in response to an Interest. 980 The ExpiryTime is a field that exists within the signature envelope 981 of a Validation Algorithm. It is the UTC time in milliseconds after 982 which the Content Object is considered expired and MUST no longer be 983 used to respond to an Interest from a cache. Stale content MAY be 984 flushed from the cache. 986 The Recommended Cache Time (RCT) is a field that exists outside the 987 signature envelope. It is the UTC time in milliseconds after which 988 the publisher considers the Content Object to be of low value to 989 cache. A cache SHOULD discard it after the RCT, though it MAY keep 990 it and still respond with it. A cache MAY discard the content object 991 before the RCT time too; there is no contractual obligation to 992 remember anything. 994 This formulation allows a producer to create a Content Object with a 995 long ExpiryTime but short RCT and keep re-publishing the same, 996 signed, Content Object over and over again by extending the RCT. 997 This allows a form of "phone home" where the publisher wants to 998 periodically see that the content is being used. 1000 5. Content Object Hash 1002 CCNx allows an Interest to restrict a response to a specific hash. 1003 The hash covers the Content Object message body and the validation 1004 sections, if present. Thus, if a Content Object is signed, its hash 1005 includes that signature value. The hash does not include the fixed 1006 or hop-by-hop headers of a Content Object. Because it is part of the 1007 matching rules (see Section 9), the hash is used at every hop. 1009 There are two options for matching the content object hash 1010 restriction in an Interest. First, a forwarder could compute for 1011 itself the hash value and compare it to the restriction. This is an 1012 expensive operation. The second option is for a border device to 1013 compute the hash once and place the value in a header (ConObjHash) 1014 that is carried through the network. The second option, of course, 1015 removes any security properties from matching the hash, so SHOULD 1016 only be used within a trusted domain. The header SHOULD be removed 1017 when crossing a trust boundary. 1019 6. Link 1021 A Link is the tuple {Name, [KeyIdRestr], [ContentObjectHashRestr]}. 1022 The information in a Link comprises the fields of an Interest which 1023 would retrieve the Link target. A Content Object with PayloadType = 1024 "Link" is an object whose payload is one or more Links. This tuple 1025 may be used as a KeyLink to identify a specific object with the 1026 certificate wrapped key. It is RECOMMENDED to include at least one 1027 of KeyIdRestr or Content ObjectHashRestr. If neither restriction is 1028 present, then any Content Object with a matching name from any 1029 publisher could be returned. 1031 7. Hashes 1033 Several protocol fields use cryptographic hash functions, which must 1034 be secure against attack and collisions. Because these hash 1035 functions change over time, with better ones appearing and old ones 1036 falling victim to attacks, it is important that a CCNx protocol 1037 implementation supports hash agility. 1039 In this document, we suggest certain hashes (e.g., SHA-256), but a 1040 specific implementation may use what it deems best. The normative 1041 CCNx Messages [CCNMessages] specification should be taken as the 1042 definition of acceptable hash functions and uses. 1044 8. Validation 1046 8.1. Validation Algorithm 1048 The Validator consists of a ValidationAlgorithm that specifies how to 1049 verify the message and a ValidationPayload containing the validation 1050 output, e.g., the digital signature or MAC. The ValidationAlgorithm 1051 section defines the type of algorithm to use and includes any 1052 necessary additional information. The validation is calculated from 1053 the beginning of the CCNx Message through the end of the 1054 ValidationAlgorithm section. The ValidationPayload is the integrity 1055 value bytes, such as a MAC or signature. 1057 Some Validators contain a KeyId, identifying the publisher 1058 authenticating the Content Object. If an Interest carries a 1059 KeyIdRestr, then that KeyIdRestr MUST exactly match the Content 1060 Object's KeyId. 1062 Validation Algorithms fall into three categories: MICs, MACs, and 1063 Signatures. Validators using Message Integrity Code (MIC) algorithms 1064 do not need to provide any additional information; they may be 1065 computed and verified based only on the algorithm (e.g., CRC32C). 1066 MAC validators require the use of a KeyId identifying the secret key 1067 used by the authenticator. Because MACs are usually used between two 1068 parties that have already exchanged secret keys via a key exchange 1069 protocol, the KeyId may be any agreed-upon value to identify which 1070 key is used. Signature validators use public key cryptographic 1071 algorithms such as RSA, DSA, ECDSA. The KeyId field in the 1072 ValidationAlgorithm identifies the public key used to verify the 1073 signature. A signature may optionally include a KeyLocator, as 1074 described above, to bundle a Key or Certificate or KeyLink. MAC and 1075 Signature validators may also include a SignatureTime, as described 1076 above. 1078 A PublicKeyLocator KeyLink points to a Content Object with a DER- 1079 encoded X509 certificate in the payload. In this case, the target 1080 KeyId must equal the first object's KeyId. The target KeyLocator 1081 must include the public key corresponding to the KeyId. That key 1082 must validate the target Signature. The payload is an X.509 1083 certificate whose public key must match the target KeyLocator's key. 1084 It must be issued by a trusted authority, preferably specifying the 1085 valid namespace of the key in the distinguished name. 1087 9. Interest to Content Object matching 1089 A Content Object satisfies an Interest if and only if (a) the Content 1090 Object name, if present, exactly matches the Interest name, and (b) 1091 the ValidationAlgorithm KeyId of the Content Object exactly equals 1092 the Interest KeyIdRestr, if present, and (c) the computed Content 1093 ObjectHash exactly equals the Interest ContentObjectHashRestr, if 1094 present. 1096 The matching rules are given by this predicate, which if it evaluates 1097 true means the Content Object matches the Interest. Ni = Name in 1098 Interest (may not be empty), Ki = KeyIdRestr in the interest (may be 1099 empty), Hi = ContentObjectHashRestr in Interest (may be empty). 1100 Likewise, No, Ko, Ho are those properties in the Content Object, 1101 where No and Ko may be empty; Ho always exists (it is an intrinsic 1102 property of the Content Object). For binary relations, we use & for 1103 AND and | for OR. We use E for the EXISTS (not empty) operator and ! 1104 for the NOT EXISTS operator. 1106 As a special case, if the ContentObjectHashRestr in the Interest 1107 specifies an unsupported hash algorithm, then no Content Object can 1108 match the Interest so the system should drop the Interest and MAY 1109 send an InterestReturn to the previous hop. In this case, the 1110 predicate below will never get executed because the Interest is never 1111 forwarded. If the system is using the optional behavior of having a 1112 different system calculate the hash for it, then the system may 1113 assume all hash functions are supported and leave it to the other 1114 system to accept or reject the Interest. 1116 (!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi) 1118 As one can see, there are two types of attributes one can match. The 1119 first term depends on the existence of the attribute in the Content 1120 Object while the next two terms depend on the existence of the 1121 attribute in the Interest. The last term is the "Nameless Object" 1122 restriction which states that if a Content Object does not have a 1123 Name, then it must match the Interest on at least the Hash 1124 restriction. 1126 If a Content Object does not carry the Content ObjectHash as an 1127 expressed field, it must be calculated in network to match against. 1128 It is sufficient within an autonomous system to calculate a Content 1129 ObjectHash at a border router and carry it via trusted means within 1130 the autonomous system. If a Content Object ValidationAlgorithm does 1131 not have a KeyId then the Content Object cannot match an Interest 1132 with a KeyIdRestr. 1134 10. Interest Return 1136 This section describes the process whereby a network element may 1137 return an Interest message to a previous hop if there is an error 1138 processing the Interest. The returned Interest may be further 1139 processed at the previous hop or returned towards the Interest 1140 origin. When a node returns an Interest it indicates that the 1141 previous hop should not expect a response from that node for the 1142 Interest -- i.e., there is no PIT entry left at the returning node. 1144 The returned message maintains compatibility with the existing TLV 1145 packet format (a fixed header, optional hop-by-hop headers, and the 1146 CCNx message body). The returned Interest packet is modified in only 1147 two ways: 1149 o The PacketType is set to InterestReturn to indicate a Feedback 1150 message. 1152 o The ReturnCode is set to the appropriate value to signal the 1153 reason for the return 1155 The specific encodings of the Interest Return are specified in 1156 [CCNMessages]. 1158 A Forwarder is not required to send any Interest Return messages. 1160 A Forwarder is not required to process any received Interest Return 1161 message. If a Forwarder does not process Interest Return messages, 1162 it SHOULD silently drop them. 1164 The Interest Return message does not apply to a Content Object or any 1165 other message type. 1167 An Interest Return message is a 1-hop message between peers. It is 1168 not propagated multiple hops via the FIB. An intermediate node that 1169 receives an InterestReturn may take corrective actions or may 1170 propagate its own InterestReturn to previous hops as indicated in the 1171 reverse path of a PIT entry. 1173 10.1. Message Format 1175 The Interest Return message looks exactly like the original Interest 1176 message with the exception of the two modifications mentioned above. 1177 The PacketType is set to indicate the message is an InterestReturn 1178 and the reserved byte in the Interest header is used as a Return 1179 Code. The numeric values for the PacketType and ReturnCodes are in 1180 [CCNMessages]. 1182 10.2. ReturnCode Types 1184 This section defines the InterestReturn ReturnCode introduced in this 1185 RFC. The numeric values used in the packet are defined in 1186 [CCNMessages]. 1188 +----------------------+--------------------------------------------+ 1189 | Name | Description | 1190 +----------------------+--------------------------------------------+ 1191 | No Route (Section | The returning Forwarder has no route to | 1192 | 10.3.1) | the Interest name. | 1193 | | | 1194 | HopLimit Exceeded | The HopLimit has decremented to 0 and need | 1195 | (Section 10.3.2) | to forward the packet. | 1196 | | | 1197 | Interest MTU too | The Interest's MTU does not conform to the | 1198 | large (Section | required minimum and would require | 1199 | 10.3.3) | fragmentation. | 1200 | | | 1201 | No Resources | The node does not have the resources to | 1202 | (Section 10.3.4) | process the Interest. | 1203 | | | 1204 | Path error (Section | There was a transmission error when | 1205 | 10.3.5) | forwarding the Interest along a route (a | 1206 | | transient error). | 1207 | | | 1208 | Prohibited (Section | An administrative setting prohibits | 1209 | 10.3.6) | processing this Interest. | 1210 | | | 1211 | Congestion (Section | The Interest was dropped due to congestion | 1212 | 10.3.7) | (a transient error). | 1213 | | | 1214 | Unsupported Content | The Interest was dropped because it | 1215 | Object Hash | requested a Content Object Hash | 1216 | Algorithm (Section | Restriction using a hash algorithm that | 1217 | 10.3.8) | cannot be computed. | 1218 | | | 1219 | Malformed Interest | The Interest was dropped because it did | 1220 | (Section 10.3.9) | not correctly parse. | 1221 +----------------------+--------------------------------------------+ 1223 Table 3: Interest Return Reason Codes 1225 10.3. Interest Return Protocol 1227 This section describes the Forwarder behavior for the various Reason 1228 codes for Interest Return. A Forwarder is not required to generate 1229 any of the codes, but if it does, it MUST conform to this 1230 specification. 1232 If a Forwarder receives an Interest Return, it SHOULD take these 1233 standard corrective actions. A forwarder is allowed to ignore 1234 Interest Return messages, in which case its PIT entry would go 1235 through normal timeout processes. 1237 o Verify that the Interest Return came from a next-hop to which it 1238 actually sent the Interest. 1240 o If a PIT entry for the corresponding Interest does not exist, the 1241 Forwarder should ignore the Interest Return. 1243 o If a PIT entry for the corresponding Interest does exist, the 1244 Forwarder MAY do one of the following: 1246 * Try a different forwarding path, if one exists, and discard the 1247 Interest Return, or 1249 * Clear the PIT state and send an Interest Return along the 1250 reverse path. 1252 If a forwarder tries alternate routes, it MUST ensure that it does 1253 not use same same path multiple times. For example, it could keep 1254 track of which next hops it has tried and not re-use them. 1256 If a forwarder tries an alternate route, it may receive a second 1257 InterestReturn, possibly of a different type than the first 1258 InterestReturn. For example, node A sends an Interest to node B, 1259 which sends a No Route return. Node A then tries node C, which sends 1260 a Prohibited. Node A should choose what it thinks is the appropriate 1261 code to send back to its previous hop 1263 If a forwarder tries an alternate route, it should decrement the 1264 Interest Lifetime to account for the time spent thus far processing 1265 the Interest. 1267 10.3.1. No Route 1269 If a Forwarder receives an Interest for which it has no route, or for 1270 which the only route is back towards the system that sent the 1271 Interest, the Forwarder SHOULD generate a "No Route" Interest Return 1272 message. 1274 How a forwarder manages the FIB table when it receives a No Route 1275 message is implementation dependent. In general, receiving a No 1276 Route Interest Return should not cause a forwarder to remove a route. 1278 The dynamic routing protocol that installed the route should correct 1279 the route or the administrator who created a static route should 1280 correct the configuration. A forwarder could suppress using that 1281 next hop for some period of time. 1283 10.3.2. HopLimit Exceeded 1285 A Forwarder MAY choose to send HopLimit Exceeded messages when it 1286 receives an Interest that must be forwarded off system and the 1287 HopLimit is 0. 1289 10.3.3. Interest MTU Too Large 1291 If a Forwarder receives an Interest whose MTU exceeds the prescribed 1292 minimum, it MAY send an "Interest MTU Too Large" message, or it may 1293 silently discard the Interest. 1295 If a Forwarder receives an "Interest MTU Too Large" is SHOULD NOT try 1296 alternate paths. It SHOULD propagate the Interest Return to its 1297 previous hops. 1299 10.3.4. No Resources 1301 If a Forwarder receives an Interest and it cannot process the 1302 Interest due to lack of resources, it MAY send an InterestReturn. A 1303 lack of resources could be the PIT table is too large, or some other 1304 capacity limit. 1306 10.3.5. Path Error 1308 If a forwarder detects an error forwarding an Interest, such as over 1309 a reliable link, it MAY send a Path Error Interest Return indicating 1310 that it was not able to send or repair a forwarding error. 1312 10.3.6. Prohibited 1314 A forwarder may have administrative policies, such as access control 1315 lists, that prohibit receiving or forwarding an Interest. If a 1316 forwarder discards an Interest due to a policy, it MAY send a 1317 Prohibited InterestReturn to the previous hop. For example, if there 1318 is an ACL that says /parc/private can only come from interface e0, 1319 but the Forwarder receives one from e1, the Forwarder must have a way 1320 to return the Interest with an explanation. 1322 10.3.7. Congestion 1324 If a forwarder discards an Interest due to congestion, it MAY send a 1325 Congestion InterestReturn to the previous hop. 1327 10.3.8. Unsupported Content Object Hash Algorithm 1329 If a Content Object Hash Restriction specifies a hash algorithm the 1330 forwarder cannot verify, the Interest should not be accepted and the 1331 forwarder MAY send an InterestReturn to the previous hop. 1333 10.3.9. Malformed Interest 1335 If a forwarder detects a structural or syntactical error in an 1336 Interest, it SHOULD drop the interest and MAY send an InterestReturn 1337 to the previous hop. This does not imply that any router must 1338 validate the entire structure of an Interest. 1340 11. IANA Considerations 1342 This memo includes no request to IANA. 1344 TO_INTERESTLIFETIME = 2 seconds. 1346 12. Security Considerations 1348 The CCNx protocol is a layer 3 network protocol, which may also 1349 operate as an overlay using other transports, such as UDP or other 1350 tunnels. It includes intrinsic support for message authentication 1351 via a signature (e.g. RSA or elliptic curve) or message 1352 authentication code (e.g. HMAC). In lieu of an authenticator, it 1353 may instead use a message integrity check (e.g. SHA or CRC). CCNx 1354 does not specify an encryption envelope, that function is left to a 1355 high-layer protocol (e.g. [esic]). 1357 The CCNx message format includes the ability to attach MICs (e.g. 1358 SHA-256 or CRC), MACs (e.g. HMAC), and Signatures (e.g. RSA or 1359 ECDSA) to all packet types. This does not mean that it is a good 1360 idea to use an arbitrary ValidationAlgorithm, nor to include 1361 computationally expensive algorithms in Interest packets, as that 1362 could lead to computational DoS attacks. Applications should use an 1363 explicit protocol to guide their use of packet signatures. As a 1364 general guideline, an application might use a MIC on an Interest to 1365 detect unintentionally corrupted packets. If one wishes to secure an 1366 Interest, one should consider using an encrypted wrapper and a 1367 protocol that prevents replay attacks, especially if the Interest is 1368 being used as an actuator. Simply using an authentication code or 1369 signature does not make an Interests secure. There are several 1370 examples in the literature on how to secure ICN-style messaging 1371 [mobile] [ace]. 1373 As a layer 3 protocol, this document does not describe how one 1374 arrives at keys or how one trusts keys. The CCNx content object may 1375 include a public key embedded in the object or may use the 1376 PublicKeyLocator field to point to a public key (or public key 1377 certificate) that authenticates the message. One key exchange 1378 specification is CCNxKE [ccnxke] [mobile], which is similar to the 1379 TLS 1.3 key exchange except it is over the CCNx layer 3 messages. 1380 Trust is beyond the scope of a layer-3 protocol protocol and left to 1381 applications or application frameworks. 1383 The combination of an ephemeral key exchange (e.g. CCNxKE [ccnxke]) 1384 and an encapsulating encryption (e.g. [esic]) provides the equivalent 1385 of a TLS tunnel. Intermediate nodes may forward the Interests and 1386 Content Objects, but have no visibility inside. It also completely 1387 hides the internal names in those used by the encryption layer. This 1388 type of tunneling encryption is useful for content that has little or 1389 no cache-ability as it can only be used by someone with the ephemeral 1390 key. Short term caching may help with lossy links or mobility, but 1391 long term caching is usually not of interest. 1393 Broadcast encryption or proxy re-encryption may be useful for content 1394 with multiple uses over time or many consumers. There is currently 1395 no recommendation for this form of encryption. 1397 The specific encoding of messages will have security implications. 1398 [CCNMessages] uses a type-length-value (TLV) encoding. We chose to 1399 compromise between extensibility and unambiguous encodings of types 1400 and lengths. Some TLVs use variable length T and variable length L 1401 fields to accomodate a wide gamut of values while trying to be byte- 1402 efficient. Our TLV encoding uses a fixed length 2-byte T and 2-byte 1403 L. Using a fixed-length T and L field solves two problems. The 1404 first is aliases. If one is able to encode the same value, such as 1405 0x2 and 0x02, in different byte lengths then one must decide if they 1406 mean the same thing, if they are different, or if one is illegal. If 1407 they are different, then one must always compare on the buffers not 1408 the integer equivalents. If one is illegal, then one must validate 1409 the TLV encoding -- every field of every packet at every hop. If 1410 they are the same, then one has the second problem: how to specify 1411 packet filters. For example, if a name has 6 name components, then 1412 there are 7 T's and 7 L's, each of which might have up to 4 1413 representations of the same value. That would be 14 fields with 4 1414 encodings each, or 1001 combinations. It also means that one cannot 1415 compare, for example, a name via a memory function as one needs to 1416 consider that any embedded T or L might have a different format. 1418 The Interest Return message has no authenticator from the previous 1419 hop. Therefore, the payload of the Interest Return should only be 1420 used locally to match an Interest. A node should never forward that 1421 Interest payload as an Interest. It should also verify that it sent 1422 the Interest in the Interest Return to that node and not allow anyone 1423 to negate Interest messages. 1425 Caching nodes must take caution when processing content objects. It 1426 is essential that the Content Store obey the rules outlined in 1427 Section 2.4.3 to avoid certain types of attacks. Unlike NDN, CCNx 1428 1.0 has no mechanism to work around an undesired result from the 1429 network (there are no "excludes"), so if a cache becomes poisoned 1430 with bad content it might cause problems retrieving content. There 1431 are three types of access to content from a content store: 1432 unrestricted, signature restricted, and hash restricted. If an 1433 Interest has no restrictions, then the requester is not particular 1434 about what they get back, so any matching cached object is OK. In 1435 the hash restricted case, the requester is very specific about what 1436 they want and the content store (and every forward hop) can easily 1437 verify that the content matches the request. In the signature 1438 verified case (often used for initial manifest discovery), the 1439 requester only knows the KeyId that signed the content. It is this 1440 case that requires the closest attention in the content store to 1441 avoid amplifying bad data. The content store must only respond with 1442 a content object if it can verify the signature -- this means either 1443 the content object carries the public key inside it or the Interest 1444 carries the public key in addition to the KeyId. If that is not the 1445 case, then the content store should treat the Interest as a cache 1446 miss and let an endpoint respond. 1448 A user-level cache could perform full signature verification by 1449 fetching a public key according to the PublicKeyLocator. That is 1450 not, however, a burden we wish to impose on the forwarder. A user- 1451 level cache could also rely on out-of-band attestation, such as the 1452 cache operator only inserting content that it knows has the correct 1453 signature. 1455 The CCNx grammar allows for hash algorithm agility via the HashType. 1456 It specifies a short list of acceptable hash algorithms that should 1457 be implemented at each forwarder. Some hash values only apply to end 1458 systems, so updating the hash algorithm does not affect forwarders -- 1459 they would simply match the buffer that includes the type-length-hash 1460 buffer. Some fields, such as the ConObjHash, must be verified at 1461 each hop, so a forwarder (or related system) must know the hash 1462 algorithm and it could cause backward compatibility problems if the 1463 hash type is updated. [CCNMessages] is the authoritative source for 1464 per-field allowed hash types in that encoding. 1466 A CCNx name uses binary matching whereas a URI uses a case 1467 insensitive hostname. Some systems may also use case insensitive 1468 matching of the URI path to a resource. An implication of this is 1469 that human-entered CCNx names will likely have case or non-ASCII 1470 symbol mismatches unless one uses a consistent URI normalization to 1471 the CCNx name. It also means that an entity that registers a CCNx 1472 routable prefix, say ccnx:/example.com, would need separate 1473 registrations for simple variations like ccnx:/Example.com. Unless 1474 this is addressed in URI normalization and routing protocol 1475 conventions, there could be phishing attacks. 1477 For a more general introduction to ICN-related security concerns and 1478 approaches, see [RFC7927] and [RFC7945] 1480 13. References 1482 13.1. Normative References 1484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1485 Requirement Levels", BCP 14, RFC 2119, 1486 DOI 10.17487/RFC2119, March 1997, . 1489 13.2. Informative References 1491 [ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, 1492 "NDN-ACE: Access control for constrained environments over 1493 named data networking", NDN Technical Report NDN-0036, 1494 2015, . 1497 [befrags] Mosko, M. and C. Tschudin, "ICN "Begin-End" Hop by Hop 1498 Fragmentation", 2017, . 1501 [ccnlite] Tschudin, C., et al., University of Basel, "CCN-Lite V2", 1502 2011-2018, . 1504 [CCNMessages] 1505 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1506 Format (Internet draft)", 2018, . 1509 [ccnxke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange 1510 Protocol Version 1.0", 2017, 1511 . 1514 [CCNxURI] Mosko, M. and C. Wood, "The CCNx URI Scheme (Internet 1515 draft)", 2017, 1516 . 1518 [chunking] 1519 Mosko, M., "CCNx Content Object Chunking", 2016, 1520 . 1523 [cicn] Muscariello, L., et al., Cisco Systems, "Community ICN 1524 (CICN)", 2017-2018, . 1526 [dart] Garcia-Luna-Aceves, J. and M. Mirzazad-Barijough, "A 1527 Light-Weight Forwarding Plane for Content-Centric 1528 Networks", 2016, . 1530 [EpriseNumbers] 1531 IANA, "IANA Private Enterprise Numbers", 2015, 1532 . 1535 [esic] Mosko, M. and C. Wood, "Encrypted Sessions In CCNx 1536 (ESIC)", 2017, . 1539 [flic] Tschudin, C. and C. Wood, "File-Like ICN Collection 1540 (FLIC)", 2017, . 1543 [mobile] Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in 1544 Content-Centric Networks", IFIP Networking, 2017, 1545 . 1548 [ndn] UCLA, "Named Data Networking", 2007, 1549 . 1551 [nnc] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 1552 Briggs, N., and R. Braynard, "Networking Named Content", 1553 2009, . 1555 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1556 Specifications: ABNF", STD 68, RFC 5234, 1557 DOI 10.17487/RFC5234, January 2008, . 1560 [RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., 1561 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1562 "Information-Centric Networking (ICN) Research 1563 Challenges", 2016, . 1566 [RFC7945] Pentikousis, K., Ohlman, B., Davies, E., Spirou, S., and 1567 G. Boggia, "Information-Centric Networking: Evaluation and 1568 Security Considerations", 2016, 1569 . 1571 [selectors] 1572 Mosko, M., "CCNx Selector Based Discovery", 2017, 1573 . 1576 [terminology] 1577 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 1578 D., and C. Tschudin, "Information-Centric Networking 1579 (ICN): CCN and NDN Terminology", 2017, 1580 . 1583 [trust] Tschudin, C., Uzun, E., and C. Wood, "Trust in 1584 Information-Centric Networking: From Theory to Practice", 1585 2016, . 1587 Authors' Addresses 1589 Marc Mosko 1590 PARC, Inc. 1591 Palo Alto, California 94304 1592 USA 1594 Phone: +01 650-812-4405 1595 Email: marc.mosko@parc.com 1597 Ignacio Solis 1598 LinkedIn 1599 Mountain View, California 94043 1600 USA 1602 Email: nsolis@linkedin.com 1603 Christopher A. Wood 1604 University of California Irvine 1605 Irvine, California 92697 1606 USA 1608 Phone: +01 315-806-5939 1609 Email: woodc1@uci.edu