idnits 2.17.1 draft-irtf-icnrg-ccnxsemantics-06.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 (October 29, 2017) is 2372 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Lifetime' is mentioned on line 371, but not defined == Missing Reference: 'Validation' is mentioned on line 372, but not defined == Missing Reference: 'Name' is mentioned on line 375, but not defined == Missing Reference: 'Payload' is mentioned on line 376, but not defined == Missing Reference: 'PublicKey' is mentioned on line 385, but not defined == Missing Reference: 'SigTime' is mentioned on line 387, but not defined == Missing Reference: 'KeyLink' is mentioned on line 386, but not defined == Missing Reference: 'KeyIdResr' is mentioned on line 405, but not defined == Missing Reference: 'ContentObjectHashRestr' is mentioned on line 405, but not defined == Missing Reference: 'KeyIdRest' is mentioned on line 419, but not defined == Missing Reference: 'KeyIdRestr' is mentioned on line 837, but not defined == Unused Reference: 'CCN' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1205, 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 (~~), 16 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: May 2, 2018 LinkedIn 6 C. Wood 7 University of California Irvine 8 October 29, 2017 10 CCNx Semantics 11 draft-irtf-icnrg-ccnxsemantics-06 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 May 2, 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. Content Store 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, and TLS, among others. While the specific wire 139 format of CCNx may vary to some extent based on transport, the core 140 principles and behaviors of CCNx outlined in this document should 141 remain fixed. 143 CCNx uses hierarchical names to identify bytes of payload. The Name 144 combines a routable prefix with an arbitrary application-dependent 145 suffix assigned by the publisher to a piece of content. The result 146 is a "named payload." In human-readable form, we represent names as 147 a "ccnx:" [CCNxURI] scheme URI [RFC3986], though the canonical 148 encoding should be octet strings. In this respect, we speak of a 149 name being made up of hierarchical path segments, which is the URI 150 terminology. 152 This document only defines the general properties of CCNx names. In 153 some isolated environments, CCNx users may be able to use any name 154 they choose and either inject that name (or prefix) into a routing 155 protocol or use other information foraging techniques. In the 156 Internet environment, there will be policies around the formats of 157 names and assignments of names to publishers, though those are not 158 specified here. 160 The key concept of CCNx is that a subjective name is 161 (cryptographically) bound to a fixed payload. These (publisher- 162 generated) bindings can therefore be (cryptographically) verified. 163 For example, a publisher could compute a cryptographic hash over the 164 name and payload, sign the hash, and deliver the tuple {Name, 165 Payload, Validation}. Consumers of this data can check the binding 166 integrity by re-computing the same cryptographic hash and verifying 167 the digital signature in Validation. Additional information would be 168 included as needed by specific validation mechanisms. Therefore, we 169 divide Validation into a ValidationAlgorithm and a ValidationPayload. 170 The ValidationAlgorithm has information about the crypto suite and 171 parameters. In particular, the ValidationAlgorithm usually has a 172 field called KeyId which identifies the public key used by the 173 validation, when applicable. The ValidationPayload is the output of 174 the validation algorithm, such as a CRC value, HMAC output, or RSA 175 signature. 177 In addition to the essential Name, Payload, and Validation sections, 178 a CCNx user may need to include some other signaling information. 179 This could include a hint about the type of Payload (e.g., 180 application data, a cryptographic key, etc.) or cache control 181 directives, etc. We will call this extra signaling information 182 ExtraFields. 184 A named payload is thus the tuple {{Name, ExtraFields, Payload, 185 ValidationAlgorithm}, ValidationPayload}, where all fields in the 186 inner tuple are covered by the validation algorithm. 188 CCNx specifies a network protocol around Interests (request messages) 189 and Content Objects (response messages) to move named payloads. An 190 Interest includes the Name -- which identifies the desired response 191 -- and optional matching restrictions. Restrictions limit the 192 possible maching Content Objects. Two restrictions exist: KeyIdRestr 193 and ContentObjectHashRestr. The first restriction on the KeyId 194 limits responses to those signed with a ValidationAlgorithm KeyId 195 field equal to the restriction. The second is the Content ObjectHash 196 restriction, which limits the response to one where the cryptographic 197 hash of the entire named payload is equal to the restriction. 199 The hierarchy of a CCNx Name is used for routing via the longest 200 matching prefix in a Forwarder. The longest matching prefix is 201 computed name segment by name segment in the hierarchical path name, 202 where each name segment must be exactly equal to match. There is no 203 requirement that the prefix be globally routable. Within a 204 deployment any local routing may be used, even one that only uses a 205 single flat (non-hierarchical) name segment. 207 Another concept of CCNx is that there should be flow balance between 208 Interest messages and Content Object messages. At the network level, 209 an Interest traveling along a single path should elicit no more than 210 one Content Object response. If some node sends the Interest along 211 more than one path, that node should consolidate the responses such 212 that only one Content Object flows back towards the requester. If an 213 Interest is sent broadcast or multicast on a multiple-access media, 214 the sender should be prepared for multiple responses unless some 215 other media-dependent mechanism like gossip suppression or leader 216 election is used. 218 As an Interest travels the forward path following the Forwarding 219 Information Base (FIB), it establishes state at each forwarder such 220 that a Content Object response can trace its way back to the original 221 requester(s) without the requester needing to include a routable 222 return address. We use the notional Pending Interest Table (PIT) as 223 a method to store state that facilitates the return of a Content 224 Object. The PIT table is not mandated by the specification. 226 The notional PIT table stores the last hop of an Interest plus its 227 Name and optional restrictions. This is the data required to match a 228 Content Object to an Interest (see Section 9). When a Content Object 229 arrives, it must be matched against the PIT to determine which 230 entries it satisfies. For each such entry, at most one copy of the 231 Content Object is sent to each listed last hop in the PIT entries. 233 If multiple Interests with the same {Name, KeyIdRestr, 234 ContentObjectHashRestr} tuple arrive at a node before a Content 235 Object matching the first Interest comes back, they are grouped in 236 the same PIT entry and their last hops aggregated (see 237 Section 2.4.2). Thus, one Content Object might satisfy multiple 238 pending Interests in a PIT. 240 In CCNx, higher-layer protocols often become so-called "name-based 241 protocols" because they operate on the CCNx Name. For example, a 242 versioning protocol might append additional name segments to convey 243 state about the version of payload. A content discovery protocol 244 might append certain protocol-specific name segments to a prefix to 245 discover content under that prefix. Many such protocols may exist 246 and apply their own rules to Names. They may be layered with each 247 protocol encapsulating (to the left) a higher layer's Name prefix. 249 This document also describes a control message called an 250 InterestReturn. A network element may return an Interest message to 251 a previous hop if there is an error processing the Interest. The 252 returned Interest may be further processed at the previous hop or 253 returned towards the Interest origin. When a node returns an 254 Interest it indicates that the previous hop should not expect a 255 response from that node for the Interest, i.e., there is no PIT entry 256 left at the returning node for a Content Object to follow. 258 There are multiple ways to describe larger objects in CCNx. Some 259 options may use the namespace while others may use a structure such 260 as a Manifest. This document does not address these options at this 261 time. 263 The remainder of this document describes a named payload as well as 264 the Interest and Content Object network protocol behavior in detail. 266 2. Protocol 268 CCNx is a request and response protocol. A request is called an 269 Interest and a response is called a Content Object. CCNx also uses a 270 1-hop control message called InterestReturn. These are, as a group, 271 called CCNx Messages. 273 2.1. Message Grammar 275 The CCNx message ABNF [RFC5234] grammar is shown in Figure 1. The 276 grammar does not include any encoding delimiters, such as TLVs. 277 Specific wire encodings are given in a separate document. If a 278 Validation section exists, the Validation Algorithm covers from the 279 Body (BodyName or BodyOptName) through the end of the ValidationAlg 280 section. The InterestLifetime, CacheTime, and Return Code fields 281 exist outside of the validation envelope and may be modified. 283 The various fields -- in alphabetical order -- are defined as: 285 o AbsTime: Absolute times are conveyed as the 64-bit UTC time in 286 milliseconds since the epoch (standard POSIX time). 288 o CacheTime: The absolute time after which the publisher believes 289 there is low value in caching the content object. This is a 290 recommendation to caches (see Section 4). 292 o ConObjField: These are optional fields that may appear in a 293 Content Object. 295 o ConObjHash: The value of the Content Object Hash, which is the 296 SHA256-32 over the message from the beginning of the body to the 297 end of the message. Note that this coverage area is different 298 from the ValidationAlg. This value SHOULD NOT be trusted across 299 domains (see Section 5). 301 o ExpiryTime: An absolute time after which the content object should 302 be considered expired (see Section 4). 304 o HopLimit: Interest messages may loop if there are loops in the 305 forwarding plane. To eventually terminate loops, each Interest 306 carries a HopLimit that is decremented after each hop and no 307 longer forwarded when it reaches zero. See Section 2.4. 309 o InterestField: These are optional fields that may appear in an 310 Interest message. 312 o KeyIdRestr: The KeyId Restriction. A Content Object must have a 313 KeyId with the same value as the restriction. 315 o ContentObjectHashRestr: The Content Object Hash Restriction. A 316 content object must hash to the same value as the restriction 317 using the same HashType. The ContentObjectHashRestr MUST use 318 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 Content Object 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 ContentObjectHashRestr of the corresponding Content 343 Object. 345 o Payload: The message's data, as defined by PayloadType. 347 o PayloadType: The format of the Payload. If missing, assume 348 DataType. DataType means the payload is opaque application bytes. 349 KeyType means the payload is a DER-encoded public key. LinkType 350 means it is one or more Links (see Section 6). 352 o PublicKey: Some applications may wish to embed the public key used 353 to verify the signature within the message itself. The PublickKey 354 is DER encoded. A message SHOULD NOT have both a KeyLink and a 355 PublicKey. 357 o RelTime: A relative time, measured in milli-seconds. 359 o ReturnCode: States the reason an Interest message is being 360 returned to the previous hop (see Section 10.2). 362 o SigTime: The absolute time (UTC milliseconds) when the signature 363 was generated. 365 o Hash: Hash values carried in a Message carry a HashType to 366 identify the algorithm used to generate the hash followed by the 367 hash value. This form is to allow hash agility. Some fields may 368 mandate a specific HashType. 370 Message := Interest / ContentObject / InterestReturn 371 Interest := HopLimit [Lifetime] BodyName [Validation] 372 ContentObject := [CacheTime / ConObjHash] BodyOptName [Validation] 373 InterestReturn:= ReturnCode Interest 374 BodyName := Name Common 375 BodyOptName := [Name] Common 376 Common := *Field [Payload] 377 Validation := ValidationAlg ValidatonPayload 379 Name := FirstSegment *Segment 380 FirstSegment := 1* OCTET 381 Segment := 0* OCTET 383 ValidationAlg := RSA-SHA256 HMAC-SHA256 CRC32C 384 ValidatonPayload := 1* OCTET 385 RSA-SHA256 := KeyId [PublicKey] [SigTime] [KeyLink] 386 HMAC-SHA256 := KeyId [SigTime] [KeyLink] 387 CRC32C := [SigTime] 389 AbsTime := 8 OCTET ; 64-bit UTC msec since epoch 390 CacheTime := AbsTime 391 ConObjField := ExpiryTime / PayloadType 392 ConObjHash := Hash ; The Content Object Hash 393 DataType := "1" 394 ExpiryTime := AbsTime 395 Field := InterestField / ConObjField 396 Hash := HashType 1* OCTET 397 HashType := SHA256-32 / SHA512-64 / SHA512-32 398 HopLimit := OCTET 399 InterestField := KeyIdRestr / ContentObjectHashRestr 400 KeyId := 1* OCTET ; key identifier 401 KeyIdRestr := 1* OCTET 402 KeyLink := Link 403 KeyType := "2" 404 Lifetime := RelTime 405 Link := Name [KeyIdResr] [ContentObjectHashRestr] 406 LinkType := "3" 407 ContentObjectHashRestr := Hash 408 Payload := *OCTET 409 PayloadType := DataType / KeyType / LinkType 410 PublicKey := ; DER-encoded public key 411 RelTime := 1* OCTET ; msec 412 ReturnCode := ; see Section 10.2 413 SigTime := AbsTime 415 Figure 1 417 2.2. Consumer Behavior 419 To request a piece of content for a given {Name, [KeyIdRest], 420 [ContentObjectHashRestr]} tuple, a consumer creates an Interest 421 message with those values. It MAY add a validation section, 422 typically only a CRC32C. A consumer MAY put a Payload field in an 423 Interest to send additional data to the producer beyond what is in 424 the Name. The Name is used for routing and may be remembered at each 425 hop in the notional PIT table to facilitate returning a content 426 object; Storing large amounts of state in the Name could lead to high 427 memory requirements. Because the Payload is not considered when 428 forwarding an Interest or matching a Content Object to an Interest, a 429 consumer SHOULD put an Interest Payload ID (see Section 3.2) as part 430 of the name to allow a forwarder to match Interests to content 431 objects and avoid aggregating Interests with different payloads. 432 Similarly, if a consumer uses a MAC or a signature, it SHOULD also 433 include a unique segment as part of the name to prevent the Interest 434 from being aggregated with other Interests or satisfied by a Content 435 Object that has no relation to the validation. 437 The consumer SHOULD specify an InterestLifetime, which is the length 438 of time the consumer is willing to wait for a response. The 439 InterestLifetime is an application-scale time, not a network round 440 trip time (see Section 2.4.2). If not present, the InterestLifetime 441 will use a default value (TO_INTERESTLIFETIME). 443 The consumer SHOULD set the Interest HopLimit to a reasonable value 444 or use the default 255. If the consumer knows the distances to the 445 producer via routing, it SHOULD use that value. 447 A consumer hands off the Interest to its first forwarder, which will 448 then forward the Interest over the network to a publisher (or 449 replica) that may satisfy it based on the name (see Section 2.4). 451 Interest messages are unreliable. A consumer SHOULD run a transport 452 protocol that will retry the Interest if it goes unanswered, up to 453 the InterestLifetime. No transport protocol is specified in this 454 document. 456 The network MAY send to the consumer an InterestReturn message that 457 indicates the network cannot fulfill the Interest. The ReturnCode 458 specifies the reason for the failure, such as no route or congestion. 459 Depending on the ReturnCode, the consumer MAY retry the Interest or 460 MAY return an error to the requesting application. 462 If the content was found and returned by the first forwarder, the 463 consumer will receive a Content Object. The consumer SHOULD: 465 o Ensure the content object is properly formatted. 467 o Verify that the returned Name matches a pending request. If the 468 request also had KeyIdRestr and ObjHashRest, it should also 469 validate those properties. 471 o If the content object is signed, it SHOULD cryptographically 472 verify the signature. If it does not have the corresponding key, 473 it SHOULD fetch the key, such as from a key resolution service or 474 via the KeyLink. 476 o If the signature has a SigTime, the consumer MAY use that in 477 considering if the signature is valid. For example, if the 478 consumer is asking for dynamically generated content, it should 479 expect the SigTime to not be before the time the Interest was 480 generated. 482 o If the content object is signed, it should assert the 483 trustworthiness of the signing key to the namespace. Such an 484 assertion is beyond the scope of this document, though one may use 485 traditional PKI methods, a trusted key resolution service, or 486 methods like [schematized trust]. 488 o It MAY cache the content object for future use, up to the 489 ExpiryTime if present. 491 o A consumer MAY accept a content object off the wire that is 492 expired. It may happen that a packet expires while in flight, and 493 there is no requirement that forwarders drop expired packets in 494 flight. The only requirement is that content stores, caches, or 495 producers MUST NOT respond with an expired content object. 497 2.3. Publisher Behavior 499 This document does not specify the method by which names populate a 500 Forwarding Information Base (FIB) table at forwarders (see 501 Section 2.4). A publisher is either configured with one or more name 502 prefixes under which it may create content, or it chooses its name 503 prefixes and informs the routing layer to advertise those prefixes. 505 When a publisher receives an Interest, it SHOULD: 507 o Verify that the Interest is part of the publishers namespace(s). 509 o If the Interest has a Validation section, verify the 510 ValidationPayload. Usually an Interest will only have a CRC32C 511 unless the publisher application specifically accommodates other 512 validations. The publisher MAY choose to drop Interests that 513 carry a Validation section if the publisher application does not 514 expect those signatures as this could be a form of computational 515 denial of service. If the signature requires a key that the 516 publisher does not have, it is NOT RECOMMENDED that the publisher 517 fetch the key over the network, unless it is part of the 518 application's expected behavior. 520 o Retrieve or generate the requested content object and return it to 521 the Interest's previous hop. If the requested content cannot be 522 returned, the publisher SHOULD reply with an InterestReturn or a 523 content object with application payload that says the content is 524 not available; this content object should have a short ExpiryTime 525 in the future. 527 2.4. Forwarder Behavior 529 A forwarder routes Interest messages based on a Forwarding 530 Information Base (FIB), returns Content Objects that match Interests 531 to the Interest's previous hop, and processes InterestReturn control 532 messages. It may also keep a cache of Content Objects in the 533 notional Content Store table. This document does not specify the 534 internal behavior of a forwarder -- only these and other external 535 behaviors. 537 In this document, we will use two processing pipelines, one for 538 Interests and one for Content Objects. Interest processing is made 539 up of checking for duplicate Interests in the PIT (see 540 Section 2.4.2), checking for a cached Content Object in the Content 541 Store (see Section 2.4.3), and forwarding an Interest via the FIB. 542 Content Store processing is made up of checking for matching 543 Interests in the PIT and forwarding to those previous hops. 545 2.4.1. Interest HopLimit 547 Interest looping is not prevented in CCNx. An Interest traversing 548 loops is eventually discarded using the hop-limit field of the 549 Interest, which is decremented at each hop traversed by the Interest. 551 Every Interest MUST carry a HopLimit. 553 When an Interest is received from another forwarder, the HopLimit 554 MUST be positive. A forwarder MUST decrement the HopLimit of an 555 Interest by at least 1 before it is forwarded. 557 If the HopLimit equals 0, the Interest MUST NOT be forwarded to 558 another forwarder; it MAY be sent to a publisher application or 559 serviced from a local Content Store. 561 2.4.2. Interest Aggregation 563 Interest aggregation is when a forwarder receives an Interest message 564 that could be satisfied by another Interest message already forwarded 565 by the node so the forwarder suppresses the new Interest; it only 566 records the additional previous hop so a Content Object sent in 567 response to the first Interest will satisfy both Interests. 569 CCNx uses an Interest aggregation rule that assumes the 570 InterestLifetime is akin to a subscription time and is not a network 571 round trip time. Some previous aggregation rules assumed the 572 lifetime was a round trip time, but this leads to problems of 573 expiring an Interest before a response comes if the RTT is estimated 574 too short or interfering with an ARQ scheme that wants to re-transmit 575 an Interest but a prior interest over-estimated the RTT. 577 A forwarder MAY implement an Interest aggregation scheme. If it does 578 not, then it will forward all Interest messages. This does not imply 579 that multiple, possibly identical, Content Objects will come back. A 580 forwarder MUST still satisfy all pending Interests, so one Content 581 Object could satisfy multiple similar interests, even if the 582 forwarded did not suppress duplicate Interest messages. 584 A RECOMMENDED Interest aggregation scheme is: 586 o Two Interests are considered 'similar' if they have the same Name, 587 KeyIdRestr, and ContentObjectHashRestr. 589 o Let the notional value InterestExpiry (a local value at the 590 forwarder) be equal to the receive time plus the InterestLifetime 591 (or a platform-dependent default value if not present). 593 o An Interest record (PIT entry) is considered invalid if its 594 InterestExpiry time is in the past. 596 o The first reception of an Interest MUST be forwarded. 598 o A second or later reception of an Interest similar to a valid 599 pending Interest from the same previous hop MUST be forwarded. We 600 consider these a retransmission requests. 602 o A second or later reception of an Interest similar to a valid 603 pending Interest from a new previous hop MAY be aggregated (not 604 forwarded). 606 o Aggregating an Interest MUST extend the InterestExpiry time of the 607 Interest record. An implementation MAY keep a single 608 InterestExpiry time for all previous hops or MAY keep the 609 InterestExpiry time per previous hop. In the first case, the 610 forwarder might send a Content Object down a path that is no 611 longer waiting for it, in which case the previous hop (next hop of 612 the Content Object) would drop it. 614 2.4.3. Content Store Behavior 616 The Content Store is a special cache that sits on the fast path of a 617 CCNx forwarder. It is an optional component. It serves to repair 618 lost packets and handle flash requests for popular content. It could 619 be pre-populated or use opportunistic caching. Because the Content 620 Store could serve to amplify an attach via cache poisoning, there are 621 special rules about how a Content Store behaves. 623 1. A forwarder MAY implement a Content Store. If it does, the 624 Content Store matches a Content Object to an Interest via the 625 normal matching rules (see Section 9). 627 2. If an Interest has a KeyIdRestr, then the Content Store MUST NOT 628 reply unless it knows the signature on the matching Content 629 Object is correct. It may do this by external knowledge (i.e., 630 in a managed network or system with pre-populated caches) or by 631 having the public key and cryptographically verifying the 632 signature. If the public key is provided in the Content Object 633 itself (i.e., in the PublicKey field) or in the Interest, the 634 Content Store MUST verify that the public key's SHA-256 hash is 635 equal to the KeyId and that it verifies the signature. A Content 636 Store MAY verify the digital signature of a Content Object before 637 it is cached, but it is not required to do so. A Content Store 638 SHOULD NOT fetch keys over the network. If it cannot or has not 639 yet verified the signature, it should treat the Interest as a 640 cache miss. 642 3. If an Interest has an ContentObjectHashRestr, then the Content 643 Store MUST NOT reply unless it knows the the matching Content 644 Object has the correct hash. If it cannot verify the hash, then 645 it should treat the Interest as a cache miss. 647 4. It must object the Cache Control directives (see Section 4). 649 2.4.4. Interest Pipeline 651 1. Perform the HopLimit check (see Section 2.4.1). 653 2. Determine if the Interest can be aggregated, as per 654 Section 2.4.2. If it can be, aggregate and do not forward the 655 Interest. 657 3. If forwarding the Interest, check for a hit in the Content Store, 658 as per Section 2.4.3. If a matching Content Object is found, 659 return it to the Interest's previous hop. This injects the 660 Content Store as per Section 2.4.5. 662 4. Lookup the Interest in the FIB. Longest prefix match (LPM) is 663 performed name segment by name segment (not byte or bit). It 664 SHOULD exclude the Interest's previous hop. If a match is found, 665 forward the Interest. If no match is found or the forwarder 666 choses to not forward due to a local condition (e.g., 667 congestion), it SHOULD send an InterestReturn message, as per 668 Section 10. 670 2.4.5. Content Object Pipeline 672 1. It is RECOMMENDED that a forwarder that receives a content object 673 check that the Content Object came from an expected previous hop. 674 An expected previous hop is one pointed to by the FIB or one 675 recorded in the PIT as having had a matching Interest sent that 676 way. 678 2. A Content Object MUST be matched to all pending Interests that 679 satisfy the matching rules (see Section 9). Each satisfied 680 pending Interest MUST then be removed from the set of pending 681 Interests. 683 3. A forwarder SHOULD NOT send more then one copy of the received 684 Content Object to the same Interest previous hop. It may happen, 685 for example, that two Interest ask for the same Content Object in 686 different ways (e.g., by name and by name an KeyId) and that they 687 both come from the same previous hop. It is normal to send the 688 same content object multiple times on the same interface, such as 689 Ethernet, if it is going to different previous hops. 691 4. A Content Object SHOULD only be put in the Content Store if it 692 satisfied an Interest (and passed rule #1 above). This is to 693 reduce the chances of cache poisoning. 695 3. Names 697 A CCNx name is a composition of name segments. Each name segment 698 carries a label identifying the purpose of the name segment, and a 699 value. For example, some name segments are general names and some 700 serve specific purposes, such as carrying version information or the 701 sequencing of many chunks of a large object into smaller, signed 702 Content Objects. 704 There are three different types of names in CCNx: prefix, exact, and 705 full names. A prefix name is simply a name that does not uniquely 706 identify a single Content Object, but rather a namespace or prefix of 707 an existing Content Object name. An exact name is one which uniquely 708 identifies the name of a Content Object. A full name is one which is 709 exact and is accompanied by an explicit or implicit ConObjHash. The 710 ConObjHash is explicit in an Interest and implicit in a Content 711 Object. 713 The name segment labels specified in this document are given in the 714 table below. Name Segment is a general name segment, typically 715 occurring in the routable prefix and user-specified content name. 716 Other segment types are for functional name components that imply a 717 specific purpose. 719 A forwarding table entry may contain name segments of any type. 720 Routing protocol policy and local system policy may limit what goes 721 into forwarding entries, but there is no restriction at the core 722 level. An Interest routing protocol, for example, may only allow 723 binary name segments. A load balancer or compute cluster may route 724 through additional component types, depending on their services. 726 +-------------+-----------------------------------------------------+ 727 | Name | Description | 728 +-------------+-----------------------------------------------------+ 729 | Name | A generic name segment that includes arbitrary | 730 | Segment | octets. | 731 | | | 732 | Interest | An octet string that identifies the payload carried | 733 | Payload ID | in an Interest. As an example, the Payload ID might | 734 | | be a hash of the Interest Payload. This provides a | 735 | | way to differentiate between Interests based on the | 736 | | Payload solely through a Name Segment without | 737 | | having to include all the extra bytes of the | 738 | | payload itself. | 739 | | | 740 | Application | An application-specific payload in a name segment. | 741 | Components | An application may apply its own semantics to these | 742 | | components. A good practice is to identify the | 743 | | application in a Name segment prior to the | 744 | | application component segments. | 745 +-------------+-----------------------------------------------------+ 747 Table 1: CCNx Name Segment Types 749 At the lowest level, a Forwarder does not need to understand the 750 semantics of name segments; it need only identify name segment 751 boundaries and be able to compare two name segments (both label and 752 value) for equality. The Forwarder matches paths segment-by-segment 753 against its forwarding table to determine a next hop. 755 3.1. Name Examples 757 This section uses the CCNx URI [CCNxURI] representation of CCNx names 758 . 760 +--------------------------+----------------------------------------+ 761 | Name | Description | 762 +--------------------------+----------------------------------------+ 763 | ccnx:/ | A 0-length name, corresponds to a | 764 | | default route. | 765 | | | 766 | ccnx:/NAME= | A name with 1 segment of 0 length, | 767 | | distinct from ccnx:/. | 768 | | | 769 | ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first | 770 | | segment is of type NAME and the second | 771 | | segment is of type APP:0. | 772 +--------------------------+----------------------------------------+ 774 Table 2: CCNx Name Examples 776 3.2. Interest Payload ID 778 An Interest may also have a Payload which carries state about the 779 Interest but is not used to match a Content Object. If an Interest 780 contains a payload, the Interest name should contain an Interest 781 Payload ID (IPID). The IPID allows a PIT table entry to correctly 782 multiplex Content Objects in response to a specific Interest with a 783 specific payload ID. The IPID could be derived from a hash of the 784 payload or could be a GUID or a nonce. An optional Metadata field 785 defines the IPID field so other systems could verify the IPID, such 786 as when it is derived from a hash of the payload. No system is 787 required to verify the IPID. 789 4. Cache Control 791 CCNx supports two fields that affect cache control. These determine 792 how a cache or Content Store handles a Content Object. They are not 793 used in the fast path, but only to determine if a Content Object can 794 be injected on to the fast path in response to an Interest. 796 The ExpiryTime is a field that exists within the signature envelope 797 of a Validation Algorithm. It is the UTC time in milliseconds after 798 which the Content Object is considered expired and MUST no longer be 799 used to respond to an Interest from a cache. Stale content MAY be 800 flushed from the cache. 802 The Recommended Cache Time (RCT) is a field that exists outside the 803 signature envelope. It is the UTC time in milliseconds after which 804 the publisher considers the Content Object to be of low value to 805 cache. A cache SHOULD discard it after the RCT, though it MAY keep 806 it and still respond with it. A cache MAY discard the content object 807 before the RCT time too; there is no contractual obligation to 808 remember anything. 810 This formulation allows a producer to create a Content Object with a 811 long ExpiryTime but short RCT and keep re-publishing the same, 812 signed, Content Object over and over again by extending the RCT. 813 This allows a form of "phone home" where the publisher wants to 814 periodically see that the content is being used. 816 5. Content Object Hash 818 CCNx allows an Interest to restrict a response to a specific hash. 819 The hash covers the Content Object message body and the validation 820 sections, if present. Thus, if a Content Object is signed, its hash 821 includes that signature value. The hash does not include the fixed 822 or hop-by-hop headers of a Content Object. Because it is part of the 823 matching rules (see Section 9), the hash is used at every hop. 825 There are two options for matching the content object hash 826 restriction in an Interest. First, a forwarder could compute for 827 itself the hash value and compare it to the restriction. This is an 828 expensive operation. The second option is for a border device to 829 compute the hash once and place the value in a header (ConObjHash) 830 that is carried through the network. The second option, of course, 831 removes any security properties from matching the hash, so SHOULD 832 only be used within a trusted domain. The header SHOULD be removed 833 when crossing a trust boundary. 835 6. Link 837 A Link is the tuple {Name, [KeyIdRestr], [Content ObjectHashRestr]}. 838 The information in a Link comprises the fields of an Interest which 839 would retrieve the Link target. A Content Object with PayloadType = 840 "Link" is an object whose payload is one or more Links. This tuple 841 may be used as a KeyLink to identify a specific object with the 842 certificate wrapped key. It is RECOMMENDED to include at least one 843 of KeyIdRestr or Content ObjectHashRestr. If neither restriction is 844 present, then any Content Object with a matching name from any 845 publisher could be returned. 847 7. Hashes 849 Several protocol fields use cryptographic hash functions, which must 850 be secure against attack and collisions. Because these hash 851 functions change over time, with better ones appearing and old ones 852 falling victim to attacks, it is important that a CCNx protocol 853 implementation supports hash agility. 855 In this document, we suggest certain hashes (e.g., SHA-256), but a 856 specific implementation may use what it deems best. The normative 857 CCNx Messages [CCNMessages] specification should be taken as the 858 definition of acceptable hash functions and uses. 860 8. Validation 862 8.1. Validation Algorithm 864 The Validator consists of a ValidationAlgorithm that specifies how to 865 verify the message and a ValidationPayload containing the validation 866 output, e.g., the digital signature or MAC. The ValidationAlgorithm 867 section defines the type of algorithm to use and includes any 868 necessary additional information. The validation is calculated from 869 the beginning of the CCNx Message through the end of the 870 ValidationAlgorithm section. The ValidationPayload is the integrity 871 value bytes, such as a MAC or signature. 873 Some Validators contain a KeyId, identifying the publisher 874 authenticating the Content Object. If an Interest carries a 875 KeyIdRestr, then that KeyIdRestr MUST exactly match the Content 876 Object's KeyId. 878 Validation Algorithms fall into three categories: MICs, MACs, and 879 Signatures. Validators using Message Integrity Code (MIC) algorithms 880 do not need to provide any additional information; they may be 881 computed and verified based only on the algorithm (e.g., CRC32C). 882 MAC validators require the use of a KeyId identifying the secret key 883 used by the authenticator. Because MACs are usually used between two 884 parties that have already exchanged secret keys via a key exchange 885 protocol, the KeyId may be any agreed-upon value to identify which 886 key is used. Signature validators use public key cryptographic 887 algorithms such as RSA, DSA, ECDSA. The KeyId field in the 888 ValidationAlgorithm identifies the public key used to verify the 889 signature. A signature may optionally include a KeyLocator, as 890 described above, to bundle a Key or Certificate or KeyLink. MAC and 891 Signature validators may also include a SignatureTime, as described 892 above. 894 A PublicKeyLocator KeyLink points to a Content Object with a DER- 895 encoded X509 certificate in the payload. In this case, the target 896 KeyId must equal the first object's KeyId. The target KeyLocator 897 must include the public key corresponding to the KeyId. That key 898 must validate the target Signature. The payload is an X.509 899 certificate whose public key must match the target KeyLocator's key. 900 It must be issued by a trusted authority, preferably specifying the 901 valid namespace of the key in the distinguished name. 903 9. Interest to Content Object matching 905 A Content Object satisfies an Interest if and only if (a) the Content 906 Object name, if present, exactly matches the Interest name, and (b) 907 the ValidationAlgorithm KeyId of the Content Object exactly equals 908 the Interest KeyIdRestr, if present, and (c) the computed Content 909 ObjectHash exactly equals the Interest ContentObjectHashRestr, if 910 present. 912 The matching rules are given by this predicate, which if it evaluates 913 true means the Content Object matches the Interest. Ni = Name in 914 Interest (may not be empty), Ki = KeyIdRestr in the interest (may be 915 empty), Hi = ContentObjectHashRestr in Interest (may be empty). 916 Likewise, No, Ko, Ho are those properties in the Content Object, 917 where No and Ko may be empty; Ho always exists. For binary 918 relations, we use & for AND and | for OR. We use E for the EXISTS 919 (not empty) operator and ! for the NOT EXISTS operator. 921 As a special case, if the ContentObjectHashRestr in the Interest 922 specifies an unsupported hash algorithm, then no Content Object can 923 match the Interest so the system should drop the Interest and MAY 924 send an InterestReturn to the previous hop. In this case, the 925 predicate below will never get executed because the Interest is never 926 forwarded. If the system is using the optional behavior of having a 927 different system calculate the hash for it, then the system may 928 assume all hash functions are supported and leave it to the other 929 system to accept or reject the Interest. 931 (!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi) 933 As one can see, there are two types of attributes one can match. The 934 first term depends on the existence of the attribute in the Content 935 Object while the next two terms depend on the existence of the 936 attribute in the Interest. The last term is the "Nameless Object" 937 restriction which states that if a Content Object does not have a 938 Name, then it must match the Interest on at least the Hash 939 restriction. 941 If a Content Object does not carry the Content ObjectHash as an 942 expressed field, it must be calculated in network to match against. 943 It is sufficient within an autonomous system to calculate a Content 944 ObjectHash at a border router and carry it via trusted means within 945 the autonomous system. If a Content Object ValidationAlgorithm does 946 not have a KeyId then the Content Object cannot match an Interest 947 with a KeyIdRestr. 949 10. Interest Return 951 This section describes the process whereby a network element may 952 return an Interest message to a previous hop if there is an error 953 processing the Interest. The returned Interest may be further 954 processed at the previous hop or returned towards the Interest 955 origin. When a node returns an Interest it indicates that the 956 previous hop should not expect a response from that node for the 957 Interest -- i.e., there is no PIT entry left at the returning node. 959 The returned message maintains compatibility with the existing TLV 960 packet format (a fixed header, optional hop-by-hop headers, and the 961 CCNx message body). The returned Interest packet is modified in only 962 two ways: 964 o The PacketType is set to InterestReturn to indicate a Feedback 965 message. 967 o The ReturnCode is set to the appropriate value to signal the 968 reason for the return 970 The specific encodings of the Interest Return are specified in 971 [CCNMessages]. 973 A Forwarder is not required to send any Interest Return messages. 975 A Forwarder is not required to process any received Interest Return 976 message. If a Forwarder does not process Interest Return messages, 977 it SHOULD silently drop them. 979 The Interest Return message does not apply to a Content Object or any 980 other message type. 982 An Interest Return message is a 1-hop message between peers. It is 983 not propagated multiple hops via the FIB. An intermediate node that 984 receives an InterestReturn may take corrective actions or may 985 propagate its own InterestReturn to previous hops as indicated in the 986 reverse path of a PIT entry. 988 10.1. Message Format 990 The Interest Return message looks exactly like the original Interest 991 message with the exception of the two modifications mentioned above. 992 The PacketType is set to indicate the message is an InterestReturn 993 and the reserved byte in the Interest header is used as a Return 994 Code. The numeric values for the PacketType and ReturnCodes are in 995 [CCNMessages]. 997 10.2. ReturnCode Types 999 This section defines the InterestReturn ReturnCode introduced in this 1000 RFC. The numeric values used in the packet are defined in 1001 [CCNMessages]. 1003 +----------------------+--------------------------------------------+ 1004 | Name | Description | 1005 +----------------------+--------------------------------------------+ 1006 | No Route (Section | The returning Forwarder has no route to | 1007 | 10.3.1) | the Interest name. | 1008 | | | 1009 | HopLimit Exceeded | The HopLimit has decremented to 0 and need | 1010 | (Section 10.3.2) | to forward the packet. | 1011 | | | 1012 | Interest MTU too | The Interest's MTU does not conform to the | 1013 | large (Section | required minimum and would require | 1014 | 10.3.3) | fragmentation. | 1015 | | | 1016 | No Resources | The node does not have the resources to | 1017 | (Section 10.3.4) | process the Interest. | 1018 | | | 1019 | Path error (Section | There was a transmission error when | 1020 | 10.3.5) | forwarding the Interest along a route (a | 1021 | | transient error). | 1022 | | | 1023 | Prohibited (Section | An administrative setting prohibits | 1024 | 10.3.6) | processing this Interest. | 1025 | | | 1026 | Congestion (Section | The Interest was dropped due to congestion | 1027 | 10.3.7) | (a transient error). | 1028 | | | 1029 | Unsupported Content | The Interest was dropped because it | 1030 | Object Hash | requested a Content Object Hash | 1031 | Algorithm (Section | Restriction using a hash algorithm that | 1032 | 10.3.8) | cannot be computed. | 1033 | | | 1034 | Malformed Interest | The Interest was dropped because it did | 1035 | (Section 10.3.9) | not correctly parse. | 1036 +----------------------+--------------------------------------------+ 1038 Table 3: Interest Return Reason Codes 1040 10.3. Interest Return Protocol 1042 This section describes the Forwarder behavior for the various Reason 1043 codes for Interest Return. A Forwarder is not required to generate 1044 any of the codes, but if it does, it MUST conform to this 1045 specification. 1047 If a Forwarder receives an Interest Return, it SHOULD take these 1048 standard corrective actions. A forwarder is allowed to ignore 1049 Interest Return messages, in which case its PIT entry would go 1050 through normal timeout processes. 1052 o Verify that the Interest Return came from a next-hop to which it 1053 actually sent the Interest. 1055 o If a PIT entry for the corresponding Interest does not exist, the 1056 Forwarder should ignore the Interest Return. 1058 o If a PIT entry for the corresponding Interest does exist, the 1059 Forwarder MAY do one of the following: 1061 * Try a different forwarding path, if one exists, and discard the 1062 Interest Return, or 1064 * Clear the PIT state and send an Interest Return along the 1065 reverse path. 1067 If a forwarder tries alternate routes, it MUST ensure that it does 1068 not use same same path multiple times. For example, it could keep 1069 track of which next hops it has tried and not re-use them. 1071 If a forwarder tries an alternate route, it may receive a second 1072 InterestReturn, possibly of a different type than the first 1073 InterestReturn. For example, node A sends an Interest to node B, 1074 which sends a No Route return. Node A then tries node C, which sends 1075 a Prohibited. Node A should choose what it thinks is the appropriate 1076 code to send back to its previous hop 1078 If a forwarder tries an alternate route, it should decrement the 1079 Interest Lifetime to account for the time spent thus far processing 1080 the Interest. 1082 10.3.1. No Route 1084 If a Forwarder receives an Interest for which it has no route, or for 1085 which the only route is back towards the system that sent the 1086 Interest, the Forwarder SHOULD generate a "No Route" Interest Return 1087 message. 1089 How a forwarder manages the FIB table when it receives a No Route 1090 message is implementation dependent. In general, receiving a No 1091 Route Interest Return should not cause a forwarder to remove a route. 1092 The dynamic routing protocol that installed the route should correct 1093 the route or the administrator who created a static route should 1094 correct the configuration. A forwarder could suppress using that 1095 next hop for some period of time. 1097 10.3.2. HopLimit Exceeded 1099 A Forwarder MAY choose to send HopLimit Exceeded messages when it 1100 receives an Interest that must be forwarded off system and the 1101 HopLimit is 0. 1103 10.3.3. Interest MTU Too Large 1105 If a Forwarder receives an Interest whose MTU exceeds the prescribed 1106 minimum, it MAY send an "Interest MTU Too Large" message, or it may 1107 silently discard the Interest. 1109 If a Forwarder receives an "Interest MTU Too Large" is SHOULD NOT try 1110 alternate paths. It SHOULD propagate the Interest Return to its 1111 previous hops. 1113 10.3.4. No Resources 1115 If a Forwarder receives an Interest and it cannot process the 1116 Interest due to lack of resources, it MAY send an InterestReturn. A 1117 lack of resources could be the PIT table is too large, or some other 1118 capacity limit. 1120 10.3.5. Path Error 1122 If a forwarder detects an error forwarding an Interest, such as over 1123 a reliable link, it MAY send a Path Error Interest Return indicating 1124 that it was not able to send or repair a forwarding error. 1126 10.3.6. Prohibited 1128 A forwarder may have administrative policies, such as access control 1129 lists, that prohibit receiving or forwarding an Interest. If a 1130 forwarder discards an Interest due to a policy, it MAY send a 1131 Prohibited InterestReturn to the previous hop. For example, if there 1132 is an ACL that says /parc/private can only come from interface e0, 1133 but the Forwarder receives one from e1, the Forwarder must have a way 1134 to return the Interest with an explanation. 1136 10.3.7. Congestion 1138 If a forwarder discards an Interest due to congestion, it MAY send a 1139 Congestion InterestReturn to the previous hop. 1141 10.3.8. Unsupported Content Object Hash Algorithm 1143 If a Content Object Hash Restriction specifies a hash algorithm the 1144 forwarder cannot verify, the Interest should not be accepted and the 1145 forwarder MAY send an InterestReturn to the previous hop. 1147 10.3.9. Malformed Interest 1149 If a forwarder detects a structural or syntactical error in an 1150 Interest, it SHOULD drop the interest and MAY send an InterestReturn 1151 to the previous hop. This does not imply that any router must 1152 validate the entire structure of an Interest. 1154 11. Acknowledgements 1156 12. IANA Considerations 1158 This memo includes no request to IANA. 1160 TO_INTERESTLIFETIME = 2 seconds. 1162 13. Security Considerations 1164 The Interest Return message has no authenticator from the previous 1165 hop. Therefore, the payload of the Interest Return should only be 1166 used locally to match an Interest. A node should never forward that 1167 Interest payload as an Interest. It should also verify that it sent 1168 the Interest in the Interest Return to that node and not allow anyone 1169 to negate Interest messages. 1171 Caching nodes must take caution when processing content objects. 1172 Verifying digital signatures requires a public key operation in the 1173 data plane. This can be abused as a denial-of-service vector against 1174 caching nodes. Therefore, it is recommended that caching routers 1175 only cache Content Objects which can be verified by an Interest 1176 ContentObjectHashRestr. 1178 If two adjacent peers require authenticated messaging, they must use 1179 an external mechanism such as MACSEC. 1181 14. References 1183 14.1. Normative References 1185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1186 Requirement Levels", BCP 14, RFC 2119, 1187 DOI 10.17487/RFC2119, March 1997, . 1190 14.2. Informative References 1192 [CCN] PARC, Inc., "CCNx Open Source", 2007, 1193 . 1195 [CCNMessages] 1196 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1197 Format (Internet draft)", 2017, 1198 . 1201 [CCNxURI] Mosko, M. and C. Wood, "The CCNx URI Scheme (Internet 1202 draft)", 2017, 1203 . 1205 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1206 Text on Security Considerations", BCP 72, RFC 3552, 1207 DOI 10.17487/RFC3552, July 2003, . 1210 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1211 Resource Identifier (URI): Generic Syntax", STD 66, 1212 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1213 . 1215 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1216 Specifications: ABNF", STD 68, RFC 5234, 1217 DOI 10.17487/RFC5234, January 2008, . 1220 Authors' Addresses 1222 Marc Mosko 1223 PARC, Inc. 1224 Palo Alto, California 94304 1225 USA 1227 Phone: +01 650-812-4405 1228 Email: marc.mosko@parc.com 1230 Ignacio Solis 1231 LinkedIn 1232 Mountain View, California 94043 1233 USA 1235 Email: nsolis@linkedin.com 1236 Christopher A. Wood 1237 University of California Irvine 1238 Irvine, California 92697 1239 USA 1241 Phone: +01 315-806-5939 1242 Email: woodc1@uci.edu