idnits 2.17.1 draft-irtf-icnrg-ccnxsemantics-05.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 (September 11, 2017) is 2419 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Lifetime' is mentioned on line 370, but not defined == Missing Reference: 'Validation' is mentioned on line 371, but not defined == Missing Reference: 'Name' is mentioned on line 374, but not defined == Missing Reference: 'Payload' is mentioned on line 375, but not defined == Missing Reference: 'PublicKey' is mentioned on line 384, but not defined == Missing Reference: 'SigTime' is mentioned on line 386, but not defined == Missing Reference: 'KeyLink' is mentioned on line 385, but not defined == Missing Reference: 'KeyIdResr' is mentioned on line 404, but not defined == Missing Reference: 'ObjHashRestr' is mentioned on line 404, but not defined == Missing Reference: 'KeyIdRest' is mentioned on line 418, but not defined == Missing Reference: 'KeyIdRestr' is mentioned on line 835, but not defined == Missing Reference: 'ContentObjectHashRestr' is mentioned on line 835, but not defined == Unused Reference: 'CCN' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1202, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-04 Summary: 0 errors (**), 0 flaws (~~), 17 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: March 15, 2018 LinkedIn 6 C. Wood 7 University of California Irvine 8 September 11, 2017 10 CCNx Semantics 11 draft-irtf-icnrg-ccnxsemantics-05 13 Abstract 15 This document describes the core concepts of the CCNx architecture 16 and presents a minimum network protocol based on two messages: 17 Interests and Content Objects. It specifies the set of mandatory and 18 optional fields within those messages and describes their behavior 19 and interpretation. This architecture and protocol specification is 20 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 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 15, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 3 64 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.1. Message Grammar . . . . . . . . . . . . . . . . . . . . . 6 66 2.2. Consumer Behavior . . . . . . . . . . . . . . . . . . . . 10 67 2.3. Publisher Behavior . . . . . . . . . . . . . . . . . . . 11 68 2.4. Forwarder Behavior . . . . . . . . . . . . . . . . . . . 12 69 2.4.1. Interest HopLimit . . . . . . . . . . . . . . . . . . 12 70 2.4.2. Interest Aggregation . . . . . . . . . . . . . . . . 13 71 2.4.3. ContentStore Behavior . . . . . . . . . . . . . . . . 14 72 2.4.4. Interest Pipeline . . . . . . . . . . . . . . . . . . 14 73 2.4.5. Content Object Pipeline . . . . . . . . . . . . . . . 15 74 3. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 3.1. Name Examples . . . . . . . . . . . . . . . . . . . . . . 17 76 3.2. Interest Payload ID . . . . . . . . . . . . . . . . . . . 17 77 4. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 17 78 5. Content Object Hash . . . . . . . . . . . . . . . . . . . . . 18 79 6. Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 7. Hashes . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 8. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 8.1. Validation Algorithm . . . . . . . . . . . . . . . . . . 19 83 9. Interest to Content Object matching . . . . . . . . . . . . . 20 84 10. Interest Return . . . . . . . . . . . . . . . . . . . . . . . 21 85 10.1. Message Format . . . . . . . . . . . . . . . . . . . . . 22 86 10.2. ReturnCode Types . . . . . . . . . . . . . . . . . . . . 22 87 10.3. Interest Return Protocol . . . . . . . . . . . . . . . . 23 88 10.3.1. No Route . . . . . . . . . . . . . . . . . . . . . . 24 89 10.3.2. HopLimit Exceeded . . . . . . . . . . . . . . . . . 25 90 10.3.3. Interest MTU Too Large . . . . . . . . . . . . . . . 25 91 10.3.4. No Resources . . . . . . . . . . . . . . . . . . . . 25 92 10.3.5. Path Error . . . . . . . . . . . . . . . . . . . . . 25 93 10.3.6. Prohibited . . . . . . . . . . . . . . . . . . . . . 25 94 10.3.7. Congestion . . . . . . . . . . . . . . . . . . . . . 25 95 10.3.8. Unsupported Content Object Hash Algorithm . . . . . 26 96 10.3.9. Malformed Interest . . . . . . . . . . . . . . . . . 26 98 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 99 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 100 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 103 14.2. Informative References . . . . . . . . . . . . . . . . . 27 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 This document describes the principles of the CCNx architecture. It 109 describes the network protocol based on two message types: Interests 110 and Content Objects. The description is not dependent on a specific 111 wire format or particular encodings. This section introduces the 112 main concepts of CCNx, which are further elaborated in the remainder 113 of the document. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 1.2. Protocol Overview 123 CCNx is a request and response protocol to fetch chunks of data using 124 a name. The integrity of each chunk may be directly asserted through 125 a digital signature or message authentication code (MAC), or, 126 alternatively, indirectly via hash chains. Chunks may also carry 127 weaker message integrity checks (MICs) or no integrity protection 128 mechanism at all. Because provenance information is carried with 129 each chunk (or larger indirectly protected block), we no longer need 130 to rely on host identities, such as those derived from TLS 131 certificates, to ascertain the chunk legitimacy. Data integrity is 132 therefore a core feature of CCNx; it does not rely on the data 133 transmission channel. There are several options for data 134 confidentiality, discussed later. 136 As a request and response protocol, CCNx may be carried over many 137 different transports. In use today are Ethernet, TCP, UDP, 802.15.4, 138 GTP, GRE, DTLS, TLS, and others. While the specific wire format of 139 CCNx may vary to some extent based on transport, the core principles 140 and behaviors of CCNx outlined in this document should remain fixed. 142 CCNx uses hierarchical names to identify bytes of payload. The Name 143 combines a routable prefix with an arbitrary application-dependent 144 suffix assigned by the publisher to a piece of content. The result 145 is a "named payload". This is different from other systems that use 146 only self-certifying names, where the payload name is intrinsically 147 derivable from the payload or its realization in a network object 148 (e.g., a SHA-256 hash of the payload or network object). In human- 149 readable form, we represent names as a "ccnx:" [CCNxURI] scheme URI 150 [RFC3986], though the canonical encoding should be octet strings. In 151 this respect, we speak of a name being made up of hierarchical path 152 segments, which is the URI terminology. 154 This document only defines the general properties of CCNx names. In 155 some isolated environments, CCNx users may be able to use any name 156 they choose and either inject that name (or prefix) into a routing 157 protocol or use other information foraging techniques. In the 158 Internet environment, there will be policies around the formats of 159 names and assignments of names to publishers, though those are not 160 specified here. 162 The key concept of CCNx is that a subjective name is 163 (cryptographically) bound to a fixed payload. These (publisher- 164 generated) bindings can therefore be (cryptographically) verified. 165 For example, a publisher could compute a cryptographic hash over the 166 name and payload, sign the hash, and deliver the tuple {Name, 167 Payload, Validation}. Consumers of this data can check the binding 168 integrity by re-computing the same cryptographic hash and verifying 169 the digital signature in Validation. Additional information would be 170 included as needed by specific validation mechanisms. Therefore, we 171 divide Validation in to a ValidationAlgorithm and a 172 ValidationPayload. The ValidationAlgorithm has information about the 173 crypto suite and parameters. In particular, the ValidationAlgorithm 174 usually has a field called KeyId which identifies the public key used 175 by the validation, when applicable. The ValidationPayload is the 176 output of the validation algorithm, such as a CRC value, an HMAC 177 output, or an RSA signature. 179 In addition to the essential Name, Payload, and Validation sections, 180 a CCNx user may need to include some other signaling information. 181 This could include a hint about the type of Payload (e.g., 182 application data, a cryptographic key, etc.) or cache control 183 directives, etc. We will call this extra signaling information 184 ExtraFields. 186 A named payload is thus the tuple {{Name, ExtraFields, Payload, 187 ValidationAlgorithm}, ValidationPayload}, where all fields in the 188 inner tuple are covered by the validation algorithm. 190 CCNx specifies a network protocol around Interests (request messages) 191 and Content Objects (response messages) to move named payloads. An 192 Interest includes the Name -- which identifies the desired response 193 -- and two optional limiting restrictions. The first restriction on 194 the KeyId to limit responses to those signed with a 195 ValidationAlgorithm KeyId field equal to the restriction. The second 196 is the ContentObjectHash restriction, which limits the response to 197 one where the cryptographic hash of the entire named payload is equal 198 to the restriction. 200 The hierarchy of a CCNx Name is used for routing via the longest 201 matching prefix in a Forwarder. The longest matching prefix is 202 computed name segment by name segment in the hierarchical path name, 203 where each name segment must be exactly equal to match. There is no 204 requirement that the prefix be globally routable. Within a 205 deployment any local routing may be used, even one that only uses a 206 single flat (non-hierarchical) name segment. 208 Another concept of CCNx is that there should be flow balance between 209 Interest messages and Content Object messages. At the network level, 210 an Interest traveling along a single path should elicit no more than 211 one Content Object response. If some node sends the Interest along 212 more than one path, that node should consolidate the responses such 213 that only one Content Object flows back towards the requester. If an 214 Interest is sent broadcast or multicast on a multiple-access media, 215 the sender should be prepared for multiple responses unless some 216 other media-dependent mechanism like gossip suppression or leader 217 election is used. 219 As an Interest travels the forward path following the Forwarding 220 Information Base (FIB), it establishes state at each forwarder such 221 that a Content Object response can trace its way back to the original 222 requester(s) without the requester needing to include a routable 223 return address. We use the notional Pending Interest Table (PIT) as 224 a method to store state that facilitates the return of a Content 225 Object. The PIT table is not mandated by the specification. 227 The notional PIT table stores the last hop of an Interest plus its 228 Name and optional restrictions. This is the data required to match a 229 Content Object to an Interest (see Section 9). When a Content Object 230 arrives, it must be matched against the PIT to determine which 231 entries it satisfies. For each such entry, at most one copy of the 232 Content Object is sent to each listed last hop in the PIT entries. 234 If multiple Interests with the same {Name, KeyIdRestriction, 235 ContentObjectHashRestriction} tuple arrive at a node before a Content 236 Object matching the first Interest comes back, they are grouped in 237 the same PIT entry and their last hops aggregated (see 238 Section 2.4.2). Thus, one Content Object might satisfy multiple 239 pending Interests in a PIT. 241 In CCNx, higher-layer protocols often become so-called "name-based 242 protocols" because they operate on the CCNx Name. For example, a 243 versioning protocol might append additional name segments to convey 244 state about the version of payload. A content discovery protocol 245 might append certain protocol-specific name segments to a prefix to 246 discover content under that prefix. Many such protocols may exist 247 and apply their own rules to Names. They may be layered with each 248 protocol encapsulating (to the left) a higher layer's Name prefix. 250 This document also describes a control message called an 251 InterestReturn. A network element may return an Interest message to 252 a previous hop if there is an error processing the Interest. The 253 returned Interest may be further processed at the previous hop or 254 returned towards the Interest origin. When a node returns an 255 Interest it indicates that the previous hop should not expect a 256 response from that node for the Interest, i.e., there is no PIT entry 257 left at the returning node for a Content Object to follow. 259 There are multiple ways to describe larger objects in CCNx. Some 260 options may use the namespace while others may use a structure such 261 as a Manifest. This document does not address these options at this 262 time. 264 The remainder of this document describes a named payload as well as 265 the Interest and Content Object network protocol behavior in detail. 267 2. Protocol 269 CCNx is a request and response protocol. A request is called an 270 Interest and a response is called a ContentObject. CCNx also uses a 271 1-hop control message called InterestReturn. These are, as a group, 272 called CCNx Messages. 274 2.1. Message Grammar 276 The CCNx message ABNF [RFC5234] grammar is show in Figure 1. The 277 grammar does not include any encoding delimiters, such as TLVs. 278 Specific wire encodings are given in a separate document. If a 279 Validation section exists, the Validation Algorithm covers from the 280 Body (BodyName or BodyOptName) through the end of the ValidationAlg 281 section. The InterestLifetime, CacheTime, and Return Code fields 282 exist outside of the validation envelope and may be modified. 284 The various fields -- in alphabetical order -- are defined as: 286 o AbsTime: Absolute times are conveyed as the 64-bit UTC time in 287 milliseconds since the epoch (standard POSIX time). 289 o CacheTime: The absolute time after which the publisher believes 290 there is low value in caching the content object. This is a 291 recommendation to caches (see Section 4). 293 o ConObjField: These are optional fields that may appear in a 294 Content Object. 296 o ConObjHash: The value of the Content Object Hash, which is the 297 SHA256-32 over the message from the beginning of the body to the 298 end of the message. Note that this coverage area is different 299 from the ValidationAlg. This value SHOULD NOT be trusted across 300 domains (see Section 5). 302 o ExpiryTime: An absolute time after which the content object should 303 be considered expired (see Section 4). 305 o HopLimit: Interest messages may loop if there are loops in the 306 forwarding plane. To eventually terminate loops, each Interest 307 carries a HopLimit that is decremented after each hop and no 308 longer forwarded when it reaches zero. See Section 2.4. 310 o InterestField: These are optional fields that may appear in an 311 Interest message. 313 o KeyIdRestr: The KeyId Restriction. A Content Object must have a 314 KeyId with the same value as the restriction. 316 o ObjHashRestr: The Content Object Hash Restriction. A content 317 object must hash to the same value as the restriction using the 318 same HashType. The ObjHashRestr MUST use SHA256-32. 320 o KeyId: An identifier for the key used in the ValidationAlg. For 321 public key systems, this should be the SHA-256 hash of the public 322 key. For symmetric key systems, it should be an identifer agreed 323 upon by the parties. 325 o KeyLink: A Link (see Section 6) that names how to retrieve the key 326 used to verify the ValidationPayload. A message SHOULD NOT have 327 both a KeyLink and a PublicKey. 329 o Lifetime: The approximate time during which a requester is willing 330 to wait for a response, usually measured in seconds. It is not 331 strongly related to the network round trip time, though it must 332 necessarily be larger. 334 o Name: A name is made up of a non-empty first segment followed by 335 zero or more additional segments, which may be of 0 length. Path 336 segments are opaque octet strings, and are thus case-sensitive if 337 encoding UTF-8. An Interest MUST have a Name. A ContentObject 338 MAY have a Name (see Section 9). The segments of a name are said 339 to be complete if its segments uniquely identify a single Content 340 Object. A name is exact if its segments are complete. An 341 Interest carrying a full name is one which specifies an exact name 342 and the ObjHashRestr of the corresponding Content Object. 344 o Payload: The message's data, as defined by PayloadType. 346 o PayloadType: The format of the Payload. If missing, assume 347 DataType. DataType means the payload is opaque application bytes. 348 KeyType means the payload is a DER-encoded public key. LinkType 349 means it is one or more Links (see Section 6). 351 o PublicKey: Some applications may wish to embed the public key used 352 to verify the signature within the message itself. The PublickKey 353 is DER encoded. A message SHOULD NOT have both a KeyLink and a 354 PublicKey. 356 o RelTime: A relative time, measured in milli-seconds. 358 o ReturnCode: States the reason an Interest message is being 359 returned to the previous hop (see Section 10.2). 361 o SigTime: The absolute time (UTC milliseconds) when the signature 362 was generated. 364 o Hash: Hash values carried in a Message carry a HashType to 365 identify the algorithm used to generate the hash followed by the 366 hash value. This form is to allow hash agility. Some fields may 367 mandate a specific HashType. 369 Message := Interest / ContentObject / InterestReturn 370 Interest := HopLimit [Lifetime] BodyName [Validation] 371 ContentObject := [CacheTime / ConObjHash] BodyOptName [Validation] 372 InterestReturn:= ReturnCode Interest 373 BodyName := Name Common 374 BodyOptName := [Name] Common 375 Common := *Field [Payload] 376 Validation := ValidationAlg ValidatonPayload 378 Name := FirstSegment *Segment 379 FirstSegment := 1* OCTET 380 Segment := 0* OCTET 382 ValidationAlg := RSA-SHA256 HMAC-SHA256 CRC32C 383 ValidatonPayload := 1* OCTET 384 RSA-SHA256 := KeyId [PublicKey] [SigTime] [KeyLink] 385 HMAC-SHA256 := KeyId [SigTime] [KeyLink] 386 CRC32C := [SigTime] 388 AbsTime := 8 OCTET ; 64-bit UTC msec since epoch 389 CacheTime := AbsTime 390 ConObjField := ExpiryTime / PayloadType 391 ConObjHash := Hash ; The Content Object Hash 392 DataType := "1" 393 ExpiryTime := AbsTime 394 Field := InterestField / ConObjField 395 Hash := HashType 1* OCTET 396 HashType := SHA256-32 / SHA512-64 / SHA512-32 397 HopLimit := OCTET 398 InterestField := KeyIdRestr / ObjHashRestr 399 KeyId := 1* OCTET ; key identifier 400 KeyIdRestr := 1* OCTET 401 KeyLink := Link 402 KeyType := "2" 403 Lifetime := RelTime 404 Link := Name [KeyIdResr] [ObjHashRestr] 405 LinkType := "3" 406 ObjHashRestr := Hash 407 Payload := *OCTET 408 PayloadType := DataType / KeyType / LinkType 409 PublicKey := ; DER-encoded public key 410 RelTime := 1* OCTET ; msec 411 ReturnCode := ; see Section 10.2 412 SigTime := AbsTime 414 Figure 1 416 2.2. Consumer Behavior 418 To request a piece of content for a given {Name, [KeyIdRest], 419 [ObjHashRestr]} tuple, a consumer creates an Interest message with 420 those values. It MAY add a validation section, typically only a 421 CRC32C. A consumer MAY put a Payload field in an Interest to send 422 additional data to the producer beyond what is in the Name. The Name 423 is used for routing and may be remembered at each hop in the notional 424 PIT table to facilitate returning a content object; Storing large 425 amounts of state in the Name could lead to high memory requirements. 426 Because the Payload is not considered when forwarding an Interest or 427 matching a Content Object to an Interest, a consumer SHOULD put an 428 Interest Payload ID (see Section Section 3.2) as part of the name to 429 allow a forwarder to match Interests to content objects and avoid 430 aggregating Interests with different payloads. Similarly, if a 431 consumer uses a MAC or a signature, it SHOULD also include a unique 432 segment as part of the name to prevent the Interest from being 433 aggregated with other Interests or satisfied by a Content Object that 434 has no relation to the validation. 436 The consumer SHOULD specify an InterestLifetime, which is the length 437 of time the consumer is willing to wait for a response. The 438 InterestLifetime is an application-scale time, not a network round 439 trip time (see Section 2.4.2). If not present, the InterestLifetime 440 will use a default value (TO_INTERESTLIFETIME). 442 The consumer SHOULD set the Interest HopLimit to a reasonable value 443 or use the default 255. If the consumer knows the distances to the 444 producer via routing, it SHOULD use that value. 446 A consumer hands off the Interest to its first forwarder, which will 447 then forward the Interest over the network to a publisher (or 448 replica) that may satisfy it based on the name (see Section 2.4). 450 Interest messages are unreliable. A consumer SHOULD run a transport 451 protocol that will retry the Interest if it goes unanswered, up to 452 the InterestLifetime. No transport protocol is specified in this 453 document. 455 The network MAY send to the consumer an InterestReturn message that 456 indicates the network cannot fulfill the Interest. The ReturnCode 457 specifies the reason for the failure, such as no route or congestion. 458 Depending on the ReturnCode, the consumer MAY retry the Interest or 459 MAY return an error to the requesting application. 461 If the content was found and returned by the first forwarder, the 462 consumer will receive a ContentObject. The consumer SHOULD: 464 o Ensure the content object is properly formatted. 466 o Verify that the returned Name matches a pending request. If the 467 request also had KeyIdRestr and ObjHashRest, it should also 468 validate those properties. 470 o If the content object is signed, it SHOULD cryptographically 471 verify the signature. If it does not have the corresponding key, 472 it SHOULD fetch the key, such as from a key resolution service or 473 via the KeyLink. 475 o If the signature has a SigTime, the consumer MAY use that in 476 considering if the signature is valid. For example, if the 477 consumer is asking for dynamically generated content, it should 478 expect the SigTime to not be before the time the Interest was 479 generated. 481 o If the content object is signed, it should assert the 482 trustworthiness of the signing key to the namespace. Such an 483 assertion is beyond the scope of this document, though one may use 484 traditional PKI methods, a trusted key resolution service, or 485 methods like [schematized trust]. 487 o It MAY cache the content object for future use, up to the 488 ExpiryTime if present. 490 o A consumer MAY accept a content object off the wire that is 491 expired. It may happen that a packet expires while in flight, and 492 there is no requirement that forwarders drop expired packets in 493 flight. The only requirement is that content stores, caches, or 494 producers MUST NOT respond with an expired content object. 496 2.3. Publisher Behavior 498 This document does not specify the method by which names populate a 499 Forwarding Information Base (FIB) table at forwarders (see 500 Section 2.4). A publisher is either configured with one or more name 501 prefixes under which it may create content, or it chooses its name 502 prefixes and informs the routing layer to advertise those prefixes. 504 When a publisher receives an Interest, it SHOULD: 506 o Verify that the Interest is part of the publishers namespace(s). 508 o If the Interest has a Validation section, verify the 509 ValidationPayload. Usually an Interest will only have a CRC32C 510 unless the publisher application specifically accommodates other 511 validations. The publisher MAY choose to drop Interests that 512 carry a Validation section if the publisher application does not 513 expect those signatures as this could be a form of computational 514 denial of service. If the signature requires a key that the 515 publisher does not have, it is NOT RECOMMENDED that the publisher 516 fetch the key over the network, unless it is part of the 517 application's expected behavior. 519 o Retrieve or generate the requested content object and return it to 520 the Interest's previous hop. If the requested content cannot be 521 returned, the publisher SHOULD reply with an InterestReturn or a 522 content object with application payload that says the content is 523 not available; this content object should have a short ExpiryTime 524 in the future. 526 2.4. Forwarder Behavior 528 A forwarder routes Interest messages based on a Forwarding 529 Information Base (FIB), returns Content Objects that match Interests 530 to the Interest's previous hop, and processes InterestReturn control 531 messages. It may also keep a cache of Content Objects in the 532 notional Content Store table. This document does not specify the 533 internal behavior of a forwarder -- only these and other external 534 behaviors. 536 In this document, we will use two processing pipelines, one for 537 Interests and one for Content Objects. Interest processing is made 538 up of checking for duplicate Interests in the PIT (see 539 Section 2.4.2), checking for a cached Content Object in the Content 540 Store (see Section 2.4.3), and forwarding an Interest via the FIB. 541 Content Store processing is made up of checking for matching 542 Interests in the PIT and forwarding to those previous hops. 544 2.4.1. Interest HopLimit 546 Interest looping is not prevented in CCNx. An Interest traversing 547 loops is eventually discarded using the hop-limit field of the 548 Interest, which is decremented at each hop traversed by the Interest. 550 Every Interest MUST carry a HopLimit. 552 When an Interest is received from another forwarder, the HopLimit 553 MUST be positive. A forwarder MUST decement the HopLimit of an 554 Interest by at least 1 before it is forwarded. 556 If the HopLimit equals 0, the Interest MUST NOT be forwarded to 557 another forwarder; it MAY be sent to a publisher application or 558 serviced from a local Content Store. 560 2.4.2. Interest Aggregation 562 Interest aggregation is when a forwarder receives an Interest message 563 that could be satisfied by another Interest message already forwarded 564 by the node so the forwarder suppresses the new Interest; it only 565 records the additional previous hop so a Content Object sent in 566 response to the first Interest will satisfy both Interests. 568 CCNx uses an interest aggregation rule that assumes the 569 InterestLifetime is akin to a subscription time and is not a network 570 round trip time. Some previous aggregation rules assumed the 571 lifetime was a round trip time, but this leads to problems of 572 expiring an Interest before a response comes if the RTT is estimated 573 too short or interfering with an ARQ scheme that wants to re-transmit 574 an Interest but a prior interest over-estimated the RTT. 576 A forwarder MAY implement an Interest aggregation scheme. If it does 577 not, then it will forward all Interest messages. This does not imply 578 that multiple, possibly identical, Content Objects will come back. A 579 forwarder MUST still satisfy all pending Interests, so one Content 580 Object could satisfy multiple similar interests, even if the 581 forwarded did not suppress duplicate Interest messages. 583 A RECOMMENDED Interest aggregation scheme is: 585 o Two Interests are considered 'similar' if they have the same Name, 586 KeyIdRestr, and ObjHashRestr. 588 o Let the notional value InterestExpiry (a local value at the 589 forwarder) be equal to the receive time plus the InterestLifetime 590 (or a platform-dependent default value if not present). 592 o An Interest record (PIT entry) is considered invalid if its 593 InterestExpiry time is in the past. 595 o The first reception of an Interest MUST be forwarded. 597 o A second or later reception of an Interest similar to a valid 598 pending Interest from the same previous hop MUST be forwarded. We 599 consider these a retransmission requests. 601 o A second or later reception of an Interest similar to a valid 602 pending Interest from a new previous hop MAY be aggregated (not 603 forwarded). 605 o Aggregating an Interest MUST extend the InterestExpiry time of the 606 Interest record. An implementation MAY keep a single 607 InterestExpiry time for all previous hops or MAY keep the 608 InterestExpiry time per previous hop. In the first case, the 609 forwarder might send a ContentObject down a path that is no longer 610 waiting for it, in which case the previous hop (next hop of the 611 Content Object) would drop it. 613 2.4.3. ContentStore Behavior 615 The ContentStore is a special cache that sits on the fast path of a 616 CCNx forwarder. It is an optional component. It serves to repair 617 lost packets and handle flash requests for popular content. It could 618 be pre-populated or use opportunistic caching. Because the Content 619 Store could serve to amplify an attach via cache poisoning, there are 620 special rules about how a Content Store behaves. 622 1. A forwarder MAY implement a ContentStore. If it does, the 623 Content Store matches a Content Object to an Interest via the 624 normal matching rules (see Section 9). 626 2. If an Interest has a KeyIdRestr, then the ContentStore MUST NOT 627 reply unless it knows the signature on the matching ContentObject 628 is correct. It may do this by external knowledge (i.e., in a 629 managed system pre-populating the cachine) or by having the 630 public key and cryptographically verifying the signature. If the 631 public key is provided in the ContentObject itself (i.e., in the 632 PublicKey field) or in the Interest, the ContentStore MUST verify 633 that the public key's SHA-256 hash is equal to the KeyId and that 634 it verifies the signature. A ContentStore MAY verify the digital 635 signature of a Content Object before it is cached, but it is not 636 required to do so. A ContentStore SHOULD NOT fetch keys over the 637 network. If it cannot or has not yet verified the signature, it 638 should treat the Interest as a cache miss. 640 3. If an Interest has an ObjHashRestr, then the ContentStore MUST 641 NOT reply unless it knows the the matching ContentObject has the 642 correct hash. If it cannot verify the hash, then it should treat 643 the Interest as a cache miss. 645 4. It must object the Cache Control directives (see Section 4). 647 2.4.4. Interest Pipeline 649 1. Perform the HopLimit check (see Section 2.4.1). 651 2. Determine if the Interest can be aggregated, as per 652 Section 2.4.2. If it can be, aggregate and do not forward the 653 Interest. 655 3. If forwarding the Interest, check for a hit in the Content Store, 656 as per Section 2.4.3. If a matching Content Object is found, 657 return it to the Interest's previous hop. This injects the 658 ContentStore as per Section 2.4.5. 660 4. Lookup the Interest in the FIB. Longest prefix match (LPM) is 661 performed name segment by name segment (not byte or bit). It 662 SHOULD exclude the Interest's previous hop. If a match is found, 663 forward the Interest. If no match is found or the forwarder 664 choses to not forward due to a local condition (e.g., 665 congestion), it SHOULD send an InterestReturn message, as per 666 Section 10. 668 2.4.5. Content Object Pipeline 670 1. It is RECOMMENDED that a forwarder that receives a content object 671 check that the ContentObject came from an expected previous hop. 672 An expected previous hop is one pointed to by the FIB or one 673 recorded in the PIT as having had a matching Interest sent that 674 way. 676 2. A Content Object MUST be matched to all pending Interests that 677 satisfy the matching rules (see Section 9). Each satisfied 678 pending Interest MUST then be removed from the set of pending 679 Interests. 681 3. A forwarder SHOULD NOT send more then one copy of the received 682 Content Object to the same Interest previous hop. It may happen, 683 for example, that two Interest ask for the same Content Object in 684 different ways (e.g., by name and by name an KeyId) and that they 685 both come from the same previous hop. It is normal to send the 686 same content object multiple times on the same interface, such as 687 Ethernet, if it is going to different previous hops. 689 4. A Content Object SHOULD only be put in the Content Store if it 690 satisfied an Interest (and passed rule #1 above). This is to 691 reduce the chances of cache poisoning. 693 3. Names 695 A CCNx name is a composition of name segments. Each name segment 696 carries a label identifying the purpose of the name segment, and a 697 value. For example, some name segments are general names and some 698 serve specific purposes, such as carrying version information or the 699 sequencing of many chunks of a large object into smaller, signed 700 Content Objects. 702 There are three different types of names in CCNx: prefix, exact, and 703 full names. A prefix name is simply a name that does not uniquely 704 identify a single Content Object, but rather a namespace or prefix of 705 an existing Content Object name. An exact name is one which uniquely 706 identifies the name of a Content Object. A full name is one which is 707 exact and is accompanied by an explicit or implicit ConObjHash. The 708 ConObjHash is explicit in an Interest and implicit in a Content 709 Object. 711 The name segment labels specified in this document are given in the 712 table below. Name Segment is a general name segment, typically 713 occurring in the routable prefix and user-specified content name. 714 Other segment types are for functional name components that imply a 715 specific purpose. 717 A forwarding table entry may contain name segments of any type. 718 Routing protocol policy and local system policy may limit what goes 719 into forwarding entries, but there is no restriction at the core 720 level. An Interest routing protocol, for example, may only allow 721 binary name segments. A load balancer or compute cluster may route 722 through additional component types, depending on their services. 724 +-------------+-----------------------------------------------------+ 725 | Name | Description | 726 +-------------+-----------------------------------------------------+ 727 | Name | A generic name segment that includes arbitrary | 728 | Segment | octets. | 729 | | | 730 | Interest | An octet string that identifies the payload carried | 731 | Payload ID | in an Interest. As an example, the Payload ID might | 732 | | be a hash of the Interest Payload. This provides a | 733 | | way to differentiate between Interests based on the | 734 | | Payload solely through a Name Segment without | 735 | | having to include all the extra bytes of the | 736 | | payload itself. | 737 | | | 738 | Application | An application-specific payload in a name segment. | 739 | Components | An application may apply its own semantics to these | 740 | | components. A good practice is to identify the | 741 | | application in a Name segment prior to the | 742 | | application component segments. | 743 +-------------+-----------------------------------------------------+ 745 Table 1: CCNx Name Segment Types 747 At the lowest level, a Forwarder does not need to understand the 748 semantics of name segments; it need only identify name segment 749 boundaries and be able to compare two name segments (both label and 750 value) for equality. The Forwarder matches paths segment-by-segment 751 against its forwarding table to determine a next hop. 753 3.1. Name Examples 755 This section uses the CCNx URI [CCNxURI] representation of CCNx names 756 . 758 +--------------------------+----------------------------------------+ 759 | Name | Description | 760 +--------------------------+----------------------------------------+ 761 | ccnx:/ | A 0-length name, corresponds to a | 762 | | default route. | 763 | | | 764 | ccnx:/NAME= | A name with 1 segment of 0 length, | 765 | | distinct from ccnx:/. | 766 | | | 767 | ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first | 768 | | segment is of type NAME and the second | 769 | | segment is of type APP:0. | 770 +--------------------------+----------------------------------------+ 772 Table 2: CCNx Name Examples 774 3.2. Interest Payload ID 776 An Interest may also have a Payload which carries state about the 777 Interest but is not used to match a Content Object. If an Interest 778 contains a payload, the Interest name should contain an Interest 779 Payload ID (IPID). The IPID allows a PIT table entry to correctly 780 multiplex Content Objects in response to a specific Interest with a 781 specific payload ID. The IPID could be derived from a hash of the 782 payload or could be a GUID or a nonce. An optional Metadata field 783 defines the IPID field so other systems could verify the IPID, such 784 as when it is derived from a hash of the payload. No system is 785 required to verify the IPID. 787 4. Cache Control 789 CCNx supports two fields that affect cache control. These determine 790 how a cache or Content Store handles a Content Object. They are not 791 used in the fast path, but only to determine if a ContentObject can 792 be injected on to the fast path in response to an Interest. 794 The ExpiryTime is a field that exists within the signature envelope 795 of a Validation Algorithm. It is the UTC time in milliseconds after 796 which the ContentObject is considered expired and MUST no longer be 797 used to respond to an Interest from a cache. Stale content MAY be 798 flushed from the cache. 800 The Recommended Cache Time (RCT) is a field that exists outside the 801 signature envelope. It is the UTC time in milliseconds after which 802 the publisher considers the Content Object to be of low value to 803 cache. A cache SHOULD discard it after the RCT, though it MAY keep 804 it and still respond with it. A cache is MAY discard the content 805 object before the RCT time too; there is no contractual obligation to 806 remember anything. 808 This formulation allows a producer to create a Content Object with a 809 long ExpiryTime but short RCT and keep re-publishing the same, 810 signed, Content Object over and over again by extending the RCT. 811 This allows a form of "phone home" where the publisher wants to 812 periodically see that the content is being used. 814 5. Content Object Hash 816 CCNx allows an Interest to restrict a response to a specific hash. 817 The hash covers the Content Object message body and the validation 818 sections, if present. Thus, if a Content Object is signed, its hash 819 includes that signature value. The hash does not include the fixed 820 or hop-by-hop headers of a Content Object. Because it is part of the 821 matching rules (see Section 9), the hash is used at every hop. 823 There are two options for matching the content object hash 824 restriction in an Interest. First, a forwarder could compute for 825 itself the hash value and compare it to the restriction. This is an 826 expensive operation. The second option is for a border device to 827 compute the hash once and place the value in a header (ConObjHash) 828 that is carried through the network. The second option, of course, 829 removes any security properties from matching the hash, so SHOULD 830 only be used within a trusted domain. The header SHOULD be removed 831 when crossing a trust boundary. 833 6. Link 835 A Link is the tuple {Name, [KeyIdRestr], [ContentObjectHashRestr]}. 836 The information in a Link comprises the fields the fields of an 837 Interest which would retrieve the Link target. A Content Object with 838 PayloadType = "Link" is an object whose payload is one or more Links. 839 This tuple may be used as a KeyLink to identify a specific object 840 with the certificate wrapped key. It is RECOMMENDED to include at 841 least one of KeyIdRestr or ContentObjectHashRestr. If neither 842 restriction is present, then any Content Object with a matching name 843 from any publisher could be returned. 845 7. Hashes 847 Several protocol fields use cryptographic hash functions, which must 848 be secure against attack and collisions. Because these hash 849 functions change over time, with better ones appearing and old ones 850 falling victim to attacks, it is important that a CCNx protocol 851 implementation support hash agility. 853 In this document, we suggest certain hashes (e.g., SHA-256), but a 854 specific implementation may use what it deems best. The normative 855 CCNx Messages [CCNMessages] specification should be taken as the 856 definition of acceptable hash functions and uses. 858 8. Validation 860 8.1. Validation Algorithm 862 The Validator consists of a ValidationAlgorithm that specifies how to 863 verify the message and a ValidationPayload containing the validation 864 output, e.g., the digital signature or MAC. The ValidationAlgorithm 865 section defines the type of algorithm to use and includes any 866 necessary additional information. The validation is calculated from 867 the beginning of the CCNx Message through the end of the 868 ValidationAlgorithm section. The ValidationPayload is the integrity 869 value bytes, such as a MAC or signature. 871 Some Validators contain a KeyId, identifying the publisher 872 authenticating the Content Object. If an Interest carries a 873 KeyIdRestriction, then that KeyIdRestriction MUST exactly match the 874 Content Object's KeyId. 876 Validation Algorithms fall into three categories: MICs, MACs, and 877 Signatures. Validators using MIC algorithms do not need to provide 878 any additional information; they may be computed and verified based 879 only on the algorithm (e.g., CRC32C). MAC validators require the use 880 of a KeyId identifying the secret key used by the authenticator. 881 Because MACs are usually used between two parties that have already 882 exchanged secret keys via a key exchange protocol, the KeyId may be 883 any agreed-upon value to identify which key is used. Signature 884 validators use public key cryptographic algorithms such as RSA, DSA, 885 ECDSA. The KeyId field in the ValidationAlgorithm identifies the 886 public key used to verify the signature. A signature may optionally 887 include a KeyLocator, as described above, to bundle a Key or 888 Certificate or KeyLink. MAC and Signature validators may also 889 include a SignatureTime, as described above. 891 A PublicKeyLocator KeyLink points to a Content Object with a DER- 892 encoded X509 certificate in the payload. In this case, the target 893 KeyId must equal the first object's KeyId. The target KeyLocator 894 must include the public key corresponding to the KeyId. That key 895 must validate the target Signature. The payload is an X.509 896 certificate whose public key must match the target KeyLocator's key. 897 It must be issued by a trusted authority, preferably specifying the 898 valid namespace of the key in the distinguished name. 900 9. Interest to Content Object matching 902 A Content Object satisfies an Interest if and only if (a) the Content 903 Object name, if present, exactly matches the Interest name, and (b) 904 the ValidationAlgorithm KeyId of the Content Object exactly equals 905 the Interest KeyIdRestriction, if present, and (c) the computed 906 ContentObjectHash exactly equals the Interest 907 ContentObjectHashRestriction, if present. 909 The matching rules are given by this predicate, which if it evaluates 910 true means the ContentObject matches the Interest. Ni = Name in 911 Interest (may not be empty), Ki = KeyIdRestriction in the interest 912 (may be empty), Hi = ContentObjectHashRestriction in Interest (may be 913 empty). Likewise, No, Ko, Ho are those properties in the 914 ContentObject, where No and Ko may be empty; Ho always exists. For 915 binary relations, we use & for AND and | for OR. We use E for the 916 EXISTS (not empty) operator and ! for the NOT EXISTS operator. 918 As a special case, if the ContentObjectHashRestriction in the 919 Interest specifies an unsupported hash algorithm, then no 920 ContentObject can match the Interest so the system should drop the 921 Interest and MAY send an InterestReturn to the previous hop. In this 922 case, the predicate below will never get executed because the 923 Interest is never forwarded. If the system is using the optional 924 behavior of having a different system calculate the hash for it, then 925 the system may assume all hash functions are supported and leave it 926 to the other system to accept or reject the Interest. 928 (!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi) 930 As one can see, there are two types of attributes one can match. The 931 first term depends on the existence of the attribute in the 932 ContentObject while the next two terms depend on the existence of the 933 attribute in the Interest. The last term is the "Nameless Object" 934 restriction which states that if a Content Object does not have a 935 Name, then it must match the Interest on at least the Hash 936 restriction. 938 If a Content Object does not carry the ContentObjectHash as an 939 expressed field, it must be calculated in network to match against. 940 It is sufficient within an autonomous system to calculate a 941 ContentObjectHash at a border router and carry it via trusted means 942 within the autonomous system. If a Content Object 943 ValidationAlgorithm does not have a KeyId then the Content Object 944 cannot match an Interest with a KeyIdRestriction. 946 10. Interest Return 948 This section describes the process whereby a network element may 949 return an Interest message to a previous hop if there is an error 950 processing the Interest. The returned Interest may be further 951 processed at the previous hop or returned towards the Interest 952 origin. When a node returns an Interest it indicates that the 953 previous hop should not expect a response from that node for the 954 Interest -- i.e., there is no PIT entry left at the returning node. 956 The returned message maintains compatibility with the existing TLV 957 packet format (a fixed header, optional hop-by-hop headers, and the 958 CCNx message body). The returned Interest packet is modified in only 959 two ways: 961 o The PacketType is set to InterestReturn to indicate a Feedback 962 message. 964 o The ReturnCode is set to the appropriate value to signal the 965 reason for the return 967 The specific encodings of the Interest Return are specified in 968 [CCNMessages]. 970 A Forwarder is not required to send any Interest Return messages. 972 A Forwarder is not required to process any received Interest Return 973 message. If a Forwarder does not process Interest Return messages, 974 it SHOULD silently drop them. 976 The Interest Return message does not apply to a Content Object or any 977 other message type. 979 An Interest Return message is a 1-hop message between peers. It is 980 not propagated multiple hops via the FIB. An intermediate node that 981 receives an InterestReturn may take corrective actions or may 982 propagate its own InterestReturn to previous hops as indicated in the 983 reverse path of a PIT entry. 985 10.1. Message Format 987 The Interest Return message looks exactly like the original Interest 988 message with the exception of the two modifications mentioned above. 989 The PacketType is set to indicate the message is an InterestReturn 990 and the reserved byte in the Interest header is used as a Return 991 Code. The numeric values for the PacketType and ReturnCodes are in 992 [CCNMessages]. 994 10.2. ReturnCode Types 996 This section defines the InterestReturn ReturnCode introduced in this 997 RFC. The numeric values used in the packet are defined in 998 [CCNMessages]. 1000 +----------------------+--------------------------------------------+ 1001 | Name | Description | 1002 +----------------------+--------------------------------------------+ 1003 | No Route (Section | The returning Forwarder has no route to | 1004 | 10.3.1) | the Interest name. | 1005 | | | 1006 | HopLimit Exceeded | The HopLimit has decremented to 0 and need | 1007 | (Section 10.3.2) | to forward the packet. | 1008 | | | 1009 | Interest MTU too | The Interest's MTU does not conform to the | 1010 | large (Section | required minimum and would require | 1011 | 10.3.3) | fragmentation. | 1012 | | | 1013 | No Resources | The node does not have the resources to | 1014 | (Section 10.3.4) | process the Interest. | 1015 | | | 1016 | Path error (Section | There was a transmission error when | 1017 | 10.3.5) | forwarding the Interest along a route (a | 1018 | | transient error). | 1019 | | | 1020 | Prohibited (Section | An administrative setting prohibits | 1021 | 10.3.6) | processing this Interest. | 1022 | | | 1023 | Congestion (Section | The Interest was dropped due to congestion | 1024 | 10.3.7) | (a transient error). | 1025 | | | 1026 | Unsupported Content | The Interest was dropped because it | 1027 | Object Hash | requested a Content Object Hash | 1028 | Algorithm (Section | Restriction using a hash algorithm that | 1029 | 10.3.8) | cannot be computed. | 1030 | | | 1031 | Malformed Interest | The Interest was dropped because it did | 1032 | (Section 10.3.9) | not correctly parse. | 1033 +----------------------+--------------------------------------------+ 1035 Table 3: Interest Return Reason Codes 1037 10.3. Interest Return Protocol 1039 This section describes the Forwarder behavior for the various Reason 1040 codes for Interest Return. A Forwarder is not required to generate 1041 any of the codes, but if it does, it MUST conform to this 1042 specification. 1044 If a Forwarder receives an Interest Return, it SHOULD take these 1045 standard corrective actions. A forwarder is allowed to ignore 1046 Interest Return messages, in which case its PIT entry would go 1047 through normal timeout processes. 1049 o Verify that the Interest Return came from a next-hop to which it 1050 actually sent the Interest. 1052 o If a PIT entry for the corresponding Interest does not exist, the 1053 Forwarder should ignore the Interest Return. 1055 o If a PIT entry for the corresponding Interest does exist, the 1056 Forwarder MAY do one of the following: 1058 * Try a different forwarding path, if one exists, and discard the 1059 Interest Return, or 1061 * Clear the PIT state and send an Interest Return along the 1062 reverse path. 1064 If a forwarder tries alternate routes, it MUST ensure that it does 1065 not use same same path multiple times. For example, it could keep 1066 track of which next hops it has tried and not re-use them. 1068 If a forwarder tries an alternate route, it may receive a second 1069 InterestReturn, possibly of a different type than the first 1070 InterestReturn. For example, node A sends an Interest to node B, 1071 which sends a No Route return. Node A then tries node C, which sends 1072 a Prohibited. Node A should choose what it thinks is the appropriate 1073 code to send back to its previous hop 1075 If a forwarder tries an alternate route, it should decrement the 1076 Interest Lifetime to account for the time spent thus far processing 1077 the Interest. 1079 10.3.1. No Route 1081 If a Forwarder receives an Interest for which it has no route, or for 1082 which the only route is back towards the system that sent the 1083 Interest, the Forwarder SHOULD generate a "No Route" Interest Return 1084 message. 1086 How a forwarder manages the FIB table when it receives a No Route 1087 message is implementation dependent. In general, receiving a No 1088 Route Interest Return should not cause a forwarder to remove a route. 1089 The dynamic routing protocol that installed the route should correct 1090 the route or the administrator who created a static route should 1091 correct the configuration. A forwarder could suppress using that 1092 next hop for some period of time. 1094 10.3.2. HopLimit Exceeded 1096 A Forwarder MAY choose to send HopLimit Exceeded messages when it 1097 receives an Interest that must be forwarded off system and the 1098 HopLimit is 0. 1100 10.3.3. Interest MTU Too Large 1102 If a Forwarder receives an Interest whose MTU exceeds the prescribed 1103 minimum, it MAY send an "Interest MTU Too Large" message, or it may 1104 silently discard the Interest. 1106 If a Forwarder receives an "Interest MTU Too Large" is SHOULD NOT try 1107 alternate paths. It SHOULD propagate the Interest Return to its 1108 previous hops. 1110 10.3.4. No Resources 1112 If a Forwarder receives an Interest and it cannot process the 1113 Interest due to lack of resources, it MAY send an InterestReturn. A 1114 lack of resources could be the PIT table is too large, or some other 1115 capacity limit. 1117 10.3.5. Path Error 1119 If a forwarder detects an error forwarding an Interest, such as over 1120 a reliable link, it MAY send a Path Error Interest Return indicating 1121 that it was not able to send or repair a forwarding error. 1123 10.3.6. Prohibited 1125 A forwarder may have administrative policies, such as access control 1126 lists, that prohibit receiving or forwarding an Interest. If a 1127 forwarder discards an Interest due to a policy, it MAY send a 1128 Prohibited InterestReturn to the previous hop. For example, if there 1129 is an ACL that says /parc/private can only come from interface e0, 1130 but the Forwarder receives one from e1, the Forwarder must have a way 1131 to return the Interest with an explanation. 1133 10.3.7. Congestion 1135 If a forwarder discards an Interest due to congestion, it MAY send a 1136 Congestion InterestReturn to the previous hop. 1138 10.3.8. Unsupported Content Object Hash Algorithm 1140 If a Content Object Hash Restriction specifies a hash algorithm the 1141 forwarder cannot verify, the Interest should not be accepted and the 1142 forwarder MAY send an InterestReturn to the previous hop. 1144 10.3.9. Malformed Interest 1146 If a forwarder detects a structural or syntactical error in an 1147 Interest, it SHOULD drop the interest and MAY send an InterestReturn 1148 to the previous hop. This does not imply that any router must 1149 validate the entire structure of an Interest. 1151 11. Acknowledgements 1153 12. IANA Considerations 1155 This memo includes no request to IANA. 1157 TO_INTERESTLIFETIME = 2 seconds. 1159 13. Security Considerations 1161 The Interest Return message has no authenticator from the previous 1162 hop. Therefore, the payload of the Interest Return should only be 1163 used locally to match an Interest. A node should never forward that 1164 Interest payload as an Interest. It should also verify that it sent 1165 the Interest in the Interest Return to that node and not allow anyone 1166 to negate Interest messages. 1168 Caching nodes must take caution when processing content objects. 1169 Verifying digital signatures requires a public key operation in the 1170 data plane. This can be abused as a denial-of-service vector against 1171 caching nodes. Therefore, it is recommended that caching routers 1172 only cache Content Objects which can be verified by an Interest 1173 ContentObjectHashRestriction. 1175 If two adjacent peers require authenticated messaging, they must use 1176 an external mechanism such as MACSEC. 1178 14. References 1180 14.1. Normative References 1182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1183 Requirement Levels", BCP 14, RFC 2119, 1184 DOI 10.17487/RFC2119, March 1997, . 1187 14.2. Informative References 1189 [CCN] PARC, Inc., "CCNx Open Source", 2007, 1190 . 1192 [CCNMessages] 1193 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1194 Format (Internet draft)", 2017, 1195 . 1198 [CCNxURI] Mosko, M. and C. Wood, "The CCNx URI Scheme (Internet 1199 draft)", 2017, 1200 . 1202 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1203 Text on Security Considerations", BCP 72, RFC 3552, 1204 DOI 10.17487/RFC3552, July 2003, . 1207 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1208 Resource Identifier (URI): Generic Syntax", STD 66, 1209 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1210 . 1212 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1213 Specifications: ABNF", STD 68, RFC 5234, 1214 DOI 10.17487/RFC5234, January 2008, . 1217 Authors' Addresses 1219 Marc Mosko 1220 PARC, Inc. 1221 Palo Alto, California 94304 1222 USA 1224 Phone: +01 650-812-4405 1225 Email: marc.mosko@parc.com 1227 Ignacio Solis 1228 LinkedIn 1229 Mountain View, California 94043 1230 USA 1232 Email: nsolis@linkedin.com 1233 Christopher A. Wood 1234 University of California Irvine 1235 Irvine, California 92697 1236 USA 1238 Phone: +01 315-806-5939 1239 Email: woodc1@uci.edu