idnits 2.17.1 draft-oran-icnrg-reflexive-forwarding-03.txt: -(1555): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 20 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 June 2022) is 682 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-irtf-icnrg-flic-03 == Outdated reference: A later version (-07) exists of draft-oran-icnrg-pathsteering-06 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG D. Oran 3 Internet-Draft Network Systems Research and Design 4 Updates: 8569, 8609 (if approved) D. Kutscher 5 Intended status: Experimental University of Applied Sciences Emden/Leer 6 Expires: 8 December 2022 6 June 2022 8 Reflexive Forwarding for CCNx and NDN Protocols 9 draft-oran-icnrg-reflexive-forwarding-03 11 Abstract 13 Current Information-Centric Networking protocols such as CCNx and NDN 14 have a wide range of useful applications in content retrieval and 15 other scenarios that depend only on a robust two-way exchange in the 16 form of a request and response (represented by an _Interest-Data 17 exchange_ in the case of the two protocols noted above). A number of 18 important applications however, require placing large amounts of data 19 in the Interest message, and/or more than one two-way handshake. 20 While these can be accomplished using independent Interest-Data 21 exchanges by reversing the roles of consumer and producer, such 22 approaches can be both clumsy for applications and problematic from a 23 state management, congestion control, or security standpoint. This 24 specification proposes a _Reflexive Forwarding_ extension to the CCNx 25 and NDN protocol architectures that eliminates the problems inherent 26 in using independent Interest-Data exchanges for such applications. 27 It updates RFC8569 and RFC8609. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 8 December 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Problems with pushing data . . . . . . . . . . . . . . . 5 61 1.2. Problems with utilizing independent exchanges . . . . . . 5 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 63 3. Overview of the Reflexive Forwarding design . . . . . . . . . 6 64 4. Consumer Operation . . . . . . . . . . . . . . . . . . . . . 11 65 5. Naming of Reflexive Interests . . . . . . . . . . . . . . . . 12 66 6. Producer Operation . . . . . . . . . . . . . . . . . . . . . 13 67 7. Forwarder Operation . . . . . . . . . . . . . . . . . . . . . 14 68 7.1. Forwarder algorithms in pseudocode . . . . . . . . . . . 15 69 7.1.1. Processing of a normal Interest containing a Reflexive 70 Name Prefix TLV . . . . . . . . . . . . . . . . . . . 15 71 7.1.2. Processing of a Reflexive Interest . . . . . . . . . 15 72 8. State coupling between producer and consumer . . . . . . . . 16 73 9. Use cases for Reflexive Interests . . . . . . . . . . . . . . 16 74 9.1. Achieving Remote Method Invocation with Reflexive 75 Interests . . . . . . . . . . . . . . . . . . . . . . . . 17 76 9.2. RESTful Web Interactions . . . . . . . . . . . . . . . . 19 77 9.3. Achieving simple data pull from consumers with reflexive 78 Interests . . . . . . . . . . . . . . . . . . . . . . . . 19 79 10. Implementation Considerations . . . . . . . . . . . . . . . . 23 80 10.1. Forwarder implementation considerations . . . . . . . . 23 81 10.1.1. Interactions with Input Processing of Interest and 82 Data packets . . . . . . . . . . . . . . . . . . . . 23 83 10.1.2. Interactions with Interest Lifetime . . . . . . . . 24 84 10.1.3. Interactions with Interest aggregation and multi-path/ 85 multi-destination forwarding . . . . . . . . . . . . 25 86 10.2. Consumer Implementation Considerations . . . . . . . . . 26 87 10.2.1. Data objects returned by the consumer to reflexive 88 name Interests arriving from a producer . . . . . . . 26 89 10.2.2. Terminating unwanted reflexive Interest exchanges . 26 90 10.2.3. Interactions with caching . . . . . . . . . . . . . 27 91 10.3. Producer Implementation Considerations . . . . . . . . . 27 92 11. Operational Considerations . . . . . . . . . . . . . . . . . 27 93 12. Mapping to CCNx and NDN packet encodings . . . . . . . . . . 28 94 12.1. Packet encoding for CCNx . . . . . . . . . . . . . . . . 29 95 12.2. Packet encoding for NDN . . . . . . . . . . . . . . . . 29 96 12.2.1. Reflexive Name Component Type . . . . . . . . . . . 29 97 12.2.2. Reflexive Name Prefix TLV . . . . . . . . . . . . . 30 98 12.2.3. PIT Tokens for NDNLPv2 . . . . . . . . . . . . . . . 30 99 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 100 13.1. Reflexive Name Prefix TLV . . . . . . . . . . . . . . . 31 101 13.2. Forward and Reverse PIT-Token hop-by-hop option TLVs . . 31 102 14. Security Considerations . . . . . . . . . . . . . . . . . . . 32 103 14.1. Collisions of reflexive Interest names . . . . . . . . . 32 104 14.2. Additional resource pressure on PIT and FIB . . . . . . 33 105 14.3. Potential Vulnerabilities from the use of PIT Tokens . . 33 106 14.4. Privacy Considerations . . . . . . . . . . . . . . . . . 33 107 15. Normative References . . . . . . . . . . . . . . . . . . . . 34 108 16. Informative References . . . . . . . . . . . . . . . . . . . 34 109 Appendix A. Alternative Designs Considered . . . . . . . . . . . 38 110 A.1. Handling reflexive interests using dynamic FIB entries . 38 111 A.1.1. Design complexities and performance issues with 112 FIB-based design . . . . . . . . . . . . . . . . . . 39 113 A.1.2. Interactions between FIB-based design and Interest 114 Lifetime . . . . . . . . . . . . . . . . . . . . . . 40 115 A.2. Reflexive forwarding using Path Steering . . . . . . . . 41 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 118 1. Introduction 120 Current ICN protocols such as CCNx [RFC8569] and NDN [NDN] have a 121 wide range of useful applications in content retrieval and other 122 scenarios that depend only on a robust two-way exchange in the form 123 of a request and response. These ICN architectures use the terms 124 "consumer" and "producer" for the respective roles of the requester 125 and the responder, and the protocols directly capture the mechanics 126 of the two-way exchange through the "Interest message" carrying the 127 request, and the "Data message" carrying the response. Through these 128 constructs, the protocols are heavily biased toward a pure _pull- 129 based_ interaction model where requests are small (carrying little or 130 no user-supplied data other than the name of the requested data 131 object), and responses are relatively large - up to an architecture- 132 defined maximum transmission unit (MTU) on the order of kilobytes or 133 tens of kilobytes. 135 A number of important applications however require interaction models 136 more complex than individual request/response interactions in the 137 same direction (i.e. between the same consumer and one or more 138 producers). Among these we identify three important classes which 139 are the target of the proposed enhancements defined in this 140 specification. These are described in the following paragraphs. 142 *Remote Method Invocation (RMI, aka RPC):* When invoking a remote 143 method, it is common for the method to require arguments supplied 144 by the caller. In conventional TCP/IP style protocols like CORBA 145 or HTTP "Post", these are pushed to the server as part of the 146 message or messages that comprise the request. In ICN-style 147 protocols there is an unattractive choice between inflating the 148 request initiation with pushed arguments, or arranging to have one 149 or more independent request/response pairs in the opposite 150 direction for the server to fetch the arguments. Both of these 151 approaches have substantial disadvantages. Recently, a viable 152 alternative emerged through the work on RICE [Krol2018] which 153 pioneered the main design elements proposed in this specification. 155 *Phone-Home scenario:* Applications in sensing, Internet-of-things 156 (IoT) and other types where data is produced unpredictably and 157 needs to be _pushed_ somewhere create a conundrum for the pure 158 pull-based architectures considered here. If instead one eschews 159 relaxing the size asymmetry between requests and responses, some 160 additional protocol machinery is needed. Earlier efforts in the 161 ICN community have recognized this issue and designed methods to 162 provoke a cooperating element to issue a request to return the 163 data the originator desires to push, essentially "phoning home" to 164 get the responder to fetch the data. One that has been explored 165 to some extent is the _Interest-Interest-Data_ exchange 166 [Carzaniga2011], where an Interest is sent containing the desired 167 request as encapsulated data. CCNx-1.0 Bidirectional Streams 168 [Mosko2017] are also based on a scheme where an Interest is used 169 to signal a name prefix that a consumer has registered for 170 receiving Interests from a peer in a bidirectional streaming 171 session. 173 *Peer state synchronization:* A large class of applications, 174 typified by those built on top of reliable order-preserving 175 transport protocols, require initial state synchronization between 176 the peers. This is accomplished with a three-way (or longer) 177 handshake, since employing a two-way handshake as provided in the 178 existing NDN and CCNx protocols exposes a number of well-know 179 hazards, such as _half-open connections_. When attempted for 180 security-related operations such as key exchange, additional 181 hazards such as _man-in-the-middle_ attacks become trivial to 182 mount. Existing alternatives, similar to those used in the two 183 examples above, instead utilize either overlapping Interest-Data 184 exchanges in opposite directions (resulting in a four-way 185 handshake) or by adding initialization data to the initial request 186 and employing an Interest-Interest-Data protocol extension as 187 noted in the Phone-home scenarios above. 189 All of the above application interaction models present interesting 190 challenges, as neither relaxing the architecture to support pushing 191 large amounts of data, nor introducing substantial complexities 192 through multiple independent Interest-Data exchanges is an attractive 193 approach. The following subsections provide further background and 194 justification for why push and/or independent exchanges are 195 problematical. 197 1.1. Problems with pushing data 199 There are two substantial problems with the simple approach of just 200 allowing arbitrary amounts of data to be included with requests. 201 These are: 203 1. In ICN protocols such as NDN and CCNx, Interest messages are 204 intended to be small, on the order the size of a TCP ACK, as 205 opposed to the size of a TCP data segment. This is because the 206 hop-by-hop congestion control and forwarder state management 207 requires Interest messages to be buffered in expectation of 208 returning data, and possibly retransmitted hop-by-hop as opposed 209 to end-to-end. In addition, the need to create and manage state 210 on a per-Interest basis is substantially complicated if requests 211 in Interest messages are larger than a Path MTU (PMTU) and need 212 to be fragmented hop-by-hop. 214 2. If the payload data of a request is used for invoking a 215 computation (as in the RMI case described above) then substantial 216 bandwidth can be wasted if the computation is either refused or 217 abandoned for any number of reasons, including the requestor 218 failing an authorization check, or the responder not having 219 sufficient resources to execute the associated computation. 221 These problems also exist in pure datagram transport protocols such 222 as those used for legacy RMI applications like NFS [RFC7530]. More 223 usual are application protocols like HTTP(s) which rely on the TCP or 224 QUIC 3-way handshake to establish a session and then have congestion 225 control and segmentation provided as part of the transport protocol, 226 further allowing sessions to be rejected before large amounts of data 227 are transmitted or significant computational resources expended. 229 1.2. Problems with utilizing independent exchanges 231 In order to either complete a three-way handshake, or fetch data via 232 a pull from the original requestor, the role of consumer and producer 233 need to be reversed and an Interest/Data exchange initiated in the 234 direction opposite of the initiating exchange. When done with an 235 independent Interest/Data request and response, a number of 236 complications ensue. Among them are: 238 1. The originating consumer needs to have a routable name prefix 239 that can be used for the exchange. This means the consumer must 240 arrange to have its name prefix propagated in the ICN routing 241 system with sufficient reach that the producer issuing the 242 interest can be assured it is routed appropriately. While some 243 consumers are generally online and act as application servers, 244 justifying the maintenance of this routing information, many do 245 not. Further, in mobile environments, a pure consumer that does 246 not need to have a routable name prefix can benefit from the 247 inherent consumer mobility support in the CCNx and NDN protocols. 248 By requiring a routable name prefix, extra mobile routing 249 machinery is needed, such as that proposed in KITE [Zhang2018] or 250 MAPME [Auge2018]. 252 2. The consumer name prefix in item (1) above must be communicated 253 to the producer as a payload, name suffix, or other field of the 254 initiating Interest message. Since this name in its entirety is 255 chosen by the consumer, it is highly problematic from a security 256 standpoint, as it can recruit the producer to mount a reflection 257 attack against the consumer's chosen victim. 259 3. The correlation between the exchanges in opposite directions must 260 be maintained by both the consumer and the producer as 261 independent state, as opposed to being architecturally tied 262 together as would be the case with a conventional 3-way handshake 263 finite state machine. While this can of course be accomplished 264 with care by both parties, experience has shown that it is error 265 prone (for example see the checkered history of interactions 266 between the SIP [RFC3261] and SDP Offer-Answer [RFC6337]) 267 protocols. When employed as the wrapper for a key management 268 protocol such as with TLS [RFC8446] state management errors can 269 be catastrophic for security. 271 2. Requirements Language 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 275 "OPTIONAL" in this document are to be interpreted as described in 276 [RFC2119]. 278 3. Overview of the Reflexive Forwarding design 280 This specification defines a _Reflexive Forwarding_ extension to CCNx 281 and NDN that avoids the problems enumerated in Sections 1.1 and 1.2. 282 It straightforwardly exploits the hop-by-hop state and symmetric 283 routing properties of the current protocols. 285 Figure 1 below illustrates a canonical NDN/CCNx forwarder with its 286 conceptual data structures of the Content Store (CS), Pending 287 Interest Table (PIT) and Forwarding Information Base (FIB). The key 288 observation involves the relation between the PIT and the FIB. Upon 289 arrival of an Interest, a PIT entry is created which contains state 290 recording the incoming interface on which the Interest was received 291 on. If the Interest is not immediately satisfied by cached data in 292 the CS, the forwarder looks up the name in the FIB to ascertain the 293 _next-hop_ to propagate the Interest onward upstream toward the named 294 producer. Therefore, a chain of forwarding state is established 295 during Interest forwarding that couples the PIT entries of the chain 296 of forwarders together conceptually as _breadcrumbs_. These are used 297 to forward the returning Data Message over the inverse path through 298 the chain of forwarders until the Data message arrives at the 299 originating consumer. The state in the PITs is _unwound_ by 300 destroying it as each PIT entry is _satisfied_. This behavior is 301 *critical* to the feasibility of the reflexive forwarding design we 302 propose. 304 +-----------------------------------------------------------------+ 305 | ICN Node | 306 | Send data to all ======== | 307 | interfaces that | 308 | requested it | 309 | YES +------------------+ | 310 <------------------------| Pending Interest | <--------------------- 311 | | | Table (PIT) | Data | 312 | | +------------------+ 1) Find (Signed) | 313 | | 2) Save | Name | 314 | V Data | NO in | 315 | +---------------+ | PIT? | 316 | | Content Store | | | 317 | | (CS) | | | 318 | +---------------+ | | 319 | | | 320 | V | 321 | Drop Data | 322 | | 323 +-----------------------------------------------------------------+ 324 +-----------------------------------------------------------------+ 325 | ICN Node | 326 | ======== | 327 | | 328 | +====================+| 329 | |Forwarding Strategy || 330 | +====================+| 331 | | 332 | 1) Find name 2) Matching 3) Find matching | 333 | in CS? name in PIT? entry in FIB? | 334 | NO NO YES| 335 | +---------------+ +----------------+ +-------------------+ | 336 | | Content Store | | Pending | | Forwarding | | 337 --->| (CS) |-->| Interest |-->| Information Base |--> 338 | | | | Table (PIT) | | ( FIB) | | 339 | +---------------+ +----------------+ +-------------------+ | 340 | Return | YES YES | NO NO | | 341 | Data | Add | Add | Drop | 342 | | Incoming | new | or | 343 | <------| Itf. | Interest | NACK | 344 | V V | 345 | | 346 +-----------------------------------------------------------------+ 348 Figure 1: ICN forwarder structure 350 Given the above forwarding properties for Interests, it should be 351 clear that while an Interest is outstanding and ultimately arrives at 352 a producer who can respond to it, there is sufficient state in the 353 chain of forwarders to route not just a returning Data message, but 354 potentially another Interest directed through the inverse path to the 355 unique consumer who issued the original Interest. (Section 10.1.3 356 describes how Interest aggregation of requests to the same target 357 name from multiple consumers interacts with this scheme.) The key 358 question therefore is how to access this state in a way that it can 359 be used to forward Interests. 361 In order to achieve this _Reflexive Interest_ forwarding on the 362 inverse path recorded in the PIT of each forwarder, we need a few 363 critical design elements: 365 1. The Reflexive Interest needs to have a _Name_. This name is what 366 the originating consumer will use to match against the Data 367 object (or multiple Data objects - more on this later) that the 368 producer may request by issuing the Reflexive Interest. This 369 cannot be just any name, but needs to essentially name the state 370 already recorded in the PIT and not allow the consumer to 371 manufacture an arbitrary name and mount a reflection attack as 372 pointed out in Section 1.2, Paragraph 2, Item 2. 374 2. Each forwarder along the inverse path from producer to consumer 375 must be able to forward the reflexive Interest towards the 376 direction of the Consumer, without relying on global routing 377 information, as the Reflexive Name Prefixes are only valid while 378 the originating Interest/Data exchange state is present at the 379 forwarders. Essential to this operation is the ability to access 380 the PIT entry associated with the original Interest message, 381 since that contains the state necessary to identify the ingress 382 face of the original Interest, which is the unique (modulo 383 aggregation) output face over which the Reflexive Interest needs 384 to be forwarded. The Name assigned by the consumer for Reflexive 385 Name Prefix in theory is adequate to the task, but entails an 386 expensive and complicated lookup procedure. In order to make 387 this lookup both simple and efficient, we adopt an extended 388 version of the "PIT-Token" scheme pioneered by the high-speed 389 NIST NDN forwarder [Shi2020]. In this specification, we are 390 using _Forward Direction PIT Tokens_ (FPTs) that nodes attach to 391 forwarded Interests in the upstream direction, and _Reverse 392 Direction PIT Tokens_ (RPTs) that nodes attach to Reflexive 393 Interests (as well as regular Data messages) in the downstream 394 direction. We describe the specific processing requirements in 395 more detail below. 397 3. There has to be coupling of the state between the originating 398 Interest-Data exchange and the enclosed Reflexive Interest-Data 399 exchange at both the consumer and the producer. In our design, 400 this is accomplished by the way reflexive interest names are 401 chosen. 403 The following sections provide the normative details on each of these 404 design elements. The overall interaction flow for reflexive 405 forwarding is illustrated below in Figure 2. 407 +-----------+ +-----------+ +-----------+ 408 | Consumer | | Forwarder | | Producer | 409 +-----------+ +-----------+ +-----------+ 410 | | | 411 | I1 | | 412 |------------------------->| | 413 | -------------\ | | 414 | | Record RNP |-| | 415 | | in PIT(I1) | | | 416 | |------------| | | 417 | | --------------------\ | 418 | |-| Add FPT to I1.FPT | | 419 | | |-------------------| | 420 | | | 421 | | I1 | 422 | |-------------------------->| 423 | | | ------------\ 424 | | |-| Check | 425 | | | | prefix, | 426 | | | | creating | 427 | | | | Reflexive | 428 | | | | Interest | 429 | | | | state | 430 | | | |-----------| 431 | | -----------------\ | 432 | | | I1.FPT->I2.RPT |-| 433 | | |----------------| | 434 | | | 435 | | RI1 | 436 | |<--------------------------| 437 | | --------------------\ | 438 | |-| use I2.RPTto find | | 439 | | | PIT(I1), | | 440 | | | check match | | 441 | | | of PIT(I1).RNP | | 442 | | | create PIT(I2), | | 443 | | | forward I2 | | 444 | | |-------------------| | 445 |------------------------\ | | 446 || add I1.RPT and I2.FPT |-| | 447 || to PIT(I2) | | | 448 ||-----------------------| | | 449 | | | 450 | I2 | | 451 |<-------------------------| | 452 | | | 453 | D2 obj | | 454 |------------------------->| | 455 |------------------------\ | | 456 || consume PIT(I2) entry |-| | 457 || and forward D2 | | | 458 ||-----------------------| | | 459 | -----------------\ | | 460 | | I2.FPT->D2.RPT |-| | 461 | |----------------| | | 462 | | ------------------\ | 463 | |-| satisfy PIT(I2) | | 464 | | |-----------------| | 465 | | | 466 | | D2 | 467 | |-------------------------->| 468 | | | -------------\ 469 | | |-| all | 470 | | | | parameters | 471 | | | | received, | 472 | | | | answer I1 | 473 | | | |------------| 474 | | | 475 | | D1 object | 476 | |<--------------------------| 477 | -------------------\ | | 478 | | satisfy PIT(I1), |-| | 479 | | forward D1 | | | 480 | |------------------| | | 481 | -----------------\ | | 482 | | I1.FPT->D1.RPT |-| | 483 | |----------------| | | 484 | | | 485 | D1 | | 486 |<-------------------------| | 487 | | | 488 Legend: 489 I1: Interest #1 containing the Reflexive Name Prefix TLV 490 RI: Reflexive Interest with Reflexive Name Prefix Component 491 RNP: Reflexive Name Prefix 492 FPT: Forward Direction PIT Token 493 RPT: Reverse Direction PIT Token 494 D1: Data message, answering initiating I1 Interest 495 D2: Data message, answering RI 497 Figure 2: Message Flow Overview 499 4. Consumer Operation 501 A consumer that wants to employ Reflexive Forwarding MUST create an 502 Interest (I1) with a Reflexive Name Prefix (RNP) TLV that is used by 503 the producer when issuing Reflexive Interests (RI) back to the 504 consumer. Upon receiving a Reflexive Interest (e.g. RI1 in 505 Figure 2) from a Producer in response to the Interest whose first 506 name component is the RNP supplied earlier, the consumer SHOULD 507 perform a name match against the object specified in the Reflexive 508 Name, and return that object to the producer in a conventional Data 509 message, (e.g. D2 in Figure 2). 511 5. Naming of Reflexive Interests 513 A consumer may have one or more objects for the producer to fetch, 514 and therefore needs to communicate enough information in its initial 515 Interest to allow the producer to construct properly formed Reflexive 516 Interest names. For some applications the set of _full names_ (see 517 the ICN Terminology RFC [RFC8793]) is known a priori, for example 518 through compile time bindings of arguments in interface definitions 519 or by the architectural definition of a simple sensor reading. In 520 other cases, the full names of the individual objects must be 521 communicated in the original Interest message. 523 We define a new typed name component, identified by a registered name 524 component type in the IANA registry for [RFC8569]. We call this the 525 _Reflexive Interest Name Component type_. It MUST be the first (i.e. 526 high order) name component of any Reflexive Interest issued by a 527 producer. Its value is a random 128 bit quantity, assigned by the 528 consumer, which provides the entropy required to uniquely identify 529 the issuing consumer for the duration of any outstanding Interest- 530 Data exchange. We suggest using a UUID as specified in [RFC4122] but 531 any scheme that meets the randomness and entropy requirements can 532 suffice. The consumer SHOULD choose a different random value for 533 each Interest message it constructs because: 535 1. If there is insufficient randomness, a name collision on the 536 Reflexive Names could occur at any of the intermediate forwarders 537 which would result in the same mutability problems generated by 538 poor name selection in other contexts; and 540 2. Re-use of the same reflexive interest name over multiple 541 interactions might reveal linkability information that could be 542 used by surveillance adversaries for tracking purposes. 544 This initial name component is either communicated by itself through 545 a _Reflexive Name Prefix TLV_ in the originating Interest, or 546 prepended to any object names the consumer wishes the producer to 547 fetch explicitly where there is more than one object needed by the 548 producer for the current Interest-Data interaction. There are four 549 cases to consider: 551 1. The reflexive _fullname_ of a single object to fetch. 553 2. A single reflexive name prefix out of which the producer can (by 554 application-specific means) construct a number of _fullnames_ of 555 the objects it may want to fetch. 557 3. The reflexive _fullname_ of a FLIC Manifest [I-D.irtf-icnrg-flic] 558 enumerating the suffixes that may be used by the producer to 559 construct the necessary names. We distinguish this from the 560 single object fetch in case (1) above because the use of a 561 Manifest implies multiple reflexive Interest/Data exchanges with 562 the consumer. 564 4. Multiple reflexive name TLVs MAY be included in the Interest 565 message if none of the above 3 options covers the desired use 566 case. 568 The last of the four options above, while not explicitly outlawed, 569 SHOULD NOT be used. This is because it results in a longer Interest 570 message and requires extra FIB resources. Hence, it is more likely a 571 forwarder will reject the Interest for lack of resources. A 572 forwarder MAY optimize for the case of a single Reflexive Name TLV at 573 the expense of those with more than one. 575 A producer, upon receiving an Interest with one or more Reflexive 576 Name TLVs, may decide it needs to retrieve the associated data 577 object(s). It therefore can issue one or more Reflexive Interests by 578 appending the necessary name components needed to form valid full 579 names of the associated objects present at the originating consumer. 580 These in fact comprise conventional Interest-Data exchanges, with no 581 alteration of the usual semantics with regard to signatures, caching, 582 expiration, etc. When the producer has retrieved the required 583 objects to complete the original Interest-Data exchange, it can issue 584 its Data response, which unwinds all the established state at the 585 producer, the consumer, and the intermediate forwarders. 587 6. Producer Operation 589 A producer that has received an Interest with a Reflexive Name Prefix 590 (RNP) MUST store the supplied RNP and the Forward PIT Token (FPT) 591 from the received Interest for subsequent (optional, depending on 592 application semantics) Reflexive Interest sending. 594 When sending a Reflexive Interest back to the consumer, the producer 595 MUST construct a corresponding Interest name based on the RNP and 596 insert the received Forward PIT Token (FPT) as the Reverse PIT Token 597 (RPT) TLV in the reflexive Interest. 599 7. Forwarder Operation 601 The forwarder operation for CCNx and/or NDN is changed in the 602 following respects when supporting Reflexive Interests. The 603 requirements are slightly different for a simple forwarder meeting 604 the mandatory aspects of the specification, versus a forwarder 605 designed for high-performance, as discussed later in Section 10.1.1. 606 The main differences are in how PIT lookups are done, and whether the 607 forwarder only does the steps necessary to process the PIT Tokens 608 supplied by upstream and downstream forwarders, or whether it also 609 generates and processes its own PIT Tokens. 611 1. Upon receiving an Interest containing a Reflexive Name Prefix 612 (RNP) TLV the forwarder MUST record the RNP as an element of the 613 PIT entry for that Interest. (For interactions with Interest 614 aggregation, also see Section 10.1.3). 616 2. When forwarding an Interest with a Reflexive Name Prefix (RNP) 617 TLV, the forwarder MAY generate a Forward PIT Token (FPT) and 618 append it to the forwarded Interest to be processed by the next 619 hop. 621 3. If an Interest contains a Reverse PIT Token (RPT), the forwarder 622 MAY use that value to access the corresponding PIT entry, or do a 623 direct lookup based on the Reflexive Interest Name Prefix. 625 4. The forwarders MUST check that the high-order Name component of 626 the Interest is of type RNP. If not, while this could strictly 627 speaking be considered an error, the forwarder SHOULD simply 628 process the Interest as a normal non-reflexive Interest and skip 629 the steps below. A match indicates that this is a Reflexive 630 Interest corresponding to the original consumer to producer 631 Interest, so execute the following steps. 633 5. Create a new PIT entry for the Reflexive Interest (if resources 634 are sufficient). Also, see Section 10.1.1 for how PIT sharding 635 interacts with the location and creation of PIT entries on high- 636 speed forwarders. 638 6. Record the Forward PIT-Token (FPT), if any, in this PIT entry, as 639 would be done for any received Interest containing an FTP TLV. 641 7. Look up the ingress face from the originating Interest's PIT 642 entry, forward the Reflexive Interest on this face, with the 643 following changes: 645 * Append the the RPT from the ingress face information of the 646 original Interest's PIT entry, if any 648 * If the downstream forwarder desires the upstream forwarder to 649 supply an RPT in any returning Data Packet for this Reflexive 650 interest, optionally append a FPT TLV to the Interest. 652 The PIT entry for the Reflexive Interest is consumed per regular 653 Interest/Data message forwarding requirements. The PIT entry for the 654 originating Interest (that communicated the Reflexive Interest Name) 655 is also consumed by a final Data message from the producer to the 656 original consumer. 658 7.1. Forwarder algorithms in pseudocode 660 This section provides some pseudocode examples to further explain the 661 details of forwarder operation. It has separate code paths for 662 minimal forwarder operations and those needed by high-performance 663 forwarders as is further discussed in Section 10.1.1. 665 7.1.1. Processing of a normal Interest containing a Reflexive Name 666 Prefix TLV 668 Create PIT entry for Interest; 669 IF interest contains FPT 670 Record FPT along with ingress face to use as RPT later; 671 Record RNP in PIT entry; 672 EITHER 673 Create entry in an RNP look-aside table with RNP value; 674 OR 675 Generate a FPT for this PIT entry and add to Interest; 676 Forward Interest upstream; 678 7.1.2. Processing of a Reflexive Interest 679 IF Interest contains an RPT 680 use RPT to lookup up PIT entry for original interest; 681 ELSE 682 Use RNP of Interest's Name TLV to lookup original Interest PIT entry; 684 IF PIT entry of original Interest not is found 685 Issue an Interest Return with "No Route" error back to the producer; 686 RETURN; 687 ELSE 688 Create PIT entry for Reflexive Interest; 690 IF RNP of Reflexive Interest matches RNP in PIT entry 691 BEGIN 692 Extract FPT from Original Interest PIT entry (if any); 693 Add FPT to Reflexive interest as RPT for downstream forwarder; 694 Optionally, generate and add FPT for the Reflexive Interest for returning Data 695 END; 696 ELSE 697 Process as a normal Interest; 699 8. State coupling between producer and consumer 701 A consumer that wishes to use this scheme MUST utilize one of the 702 reflexive naming options defined in Section 5 and include it in the 703 corresponding Interest message. The Reflexive Name TLV _and_ the 704 full name of the requested data object (that identifies the producer) 705 identify the common state shared by the consumer and the producer. 706 When the producer responds by sending Interests with the Reflexive 707 Name Prefix, the original consumer therefore has sufficient 708 information to map these Interests to the ongoing Interest-Data 709 exchange. 711 The exchange is finished when the producer who received the original 712 Interest message responds with a Data message (or an Interest Return 713 message in the case of error) answering the original Interest. After 714 sending this Data message, the producer SHOULD destroy the 715 corresponding shared state. It MAY decide to use a timer that will 716 trigger a later state destruction. After receiving this Data 717 message, the originating consumer MUST destroy the corresponding 718 Interest-Data exchange state. 720 9. Use cases for Reflexive Interests 721 9.1. Achieving Remote Method Invocation with Reflexive Interests 723 RICE (Remote Method Invocation in ICN) [Krol2018] used a similar 724 Reflexive Interest Forwarding scheme that inspired the design 725 specified in this document (similar to the original design captured 726 in Appendix A.1). 728 In RICE, the original Interest denotes the remote method (plus 729 potential parameters) to be invoked at a producer (server). Before 730 committing any computing resources, the server can then request 731 authentication credentials and (optional) parameters using reflexive 732 Interest-Data exchanges. 734 When the server has obtained the necessary credentials and input 735 parameters, it can decide to commit computing resources, starts the 736 compute process, and returns a handle ("Thunk") in the final Data 737 message to the original consumer (client). 739 The client would later request the computation results using a 740 regular Interest-Data exchange (outside the Reflexive-Interest 741 transaction), using the Thunk as a name for the computation result. 743 Figure 3 depicts an abstract message diagram for RICE. In addition 744 to the 4-way Reflexive Forwarding Handshake (see Figure 2 for the 745 details of the interaction), RICE adds another (standard) ICN 746 Interest/Data exchange for transmitting the RMI result. The Thunk 747 name is provided to the consumer in the D1 DATA message (answering 748 the initial I1 Interest). 750 +-----------+ +-----------+ 751 | Consumer | | Producer | 752 +-----------+ +-----------+ 753 | | 754 | I1 | 755 |------------------------->| 756 | | ---------------------\ 757 | |-| Requesting request | 758 | | | parameters | 759 | | | and credentials | 760 | | |--------------------| 761 | | 762 | RI1 | 763 |<-------------------------| 764 | | 765 | RD1 | 766 |------------------------->| 767 | | --------------------\ 768 | |-| Commit compute | 769 | | | resources, | 770 | | | return Thunk name | 771 | | |-------------------| 772 | | 773 | D1 | 774 |<-------------------------| 775 | | ----------------\ 776 | |-| Invoke Remote | 777 | | | Method | 778 | | |---------------| 779 | -------------------\ | 780 |-| After some time, | | 781 | | request result | | 782 | |------------------| | 783 | | 784 | I2 | 785 |------------------------->| 786 | | 787 | D2 | 788 |<-------------------------| 789 | | 790 Legend: 791 I1: Interest #1 containing the Reflexive Name Prefix TLV 792 D1: Data message, answering initiating I1 Interest, 793 returning Thunk name 794 RI1: Reflexive Interest issued by producer 795 RD1: Data message, answering RI (parameters, credentials) 796 I2: Regular Interest for Thunk (compute result) 797 D2: Data message, answering I2 798 Figure 3: RICE Message Flow 800 9.2. RESTful Web Interactions 802 In todays HTTP-based web, RESTful (Representational State Transfer) 803 web interactions are realized by sending requests in a client/server 804 interaction, where the requests provides the application context (or 805 a reference to it). It has been noted in [Moiseenko2014] that 806 corresponding requests often exceed the response messages in size, 807 and that this raises the problems noted in Section 1.1 when 808 attempting to map such exchanges directly to CCNx/NDN. 810 Another reason not to include all request parameters in a (possibly 811 encrypted) Interest message is the fact that a server (that is 812 serving thousands of clients) would be obliged to receive, possibly 813 decrypt and parse the complete requests before being able to 814 determine whether the requestor is authorized, whether the request 815 can be served etc. Many non-trivial requests could thus lead to 816 computational overload attacks. 818 Using Reflexive Interest Forwarding for RESTful Web Interactions 819 would encode the REST request in the original request, together with 820 a Reflexive Interest Prefix that the server could then use to get 821 back to the client for authentication credentials and request 822 parameters, such as cookies. The request result (response message) 823 could either be transmitted in the Data message answering the 824 original request, or - in case of dynamic, longer-running 825 computations - in a seperate Interest/Data exchange, potentially 826 leveraging the Thunk scheme described in Section 9.1. 828 Unlike approaches where clients have to signal a globally routable 829 prefix to the network, this approach would not require the client 830 (original consumer) to expose its identity to the network (the 831 network only sees the temporary Reflexive Name Prefix), but it would 832 still be possible to authenticate the client at the server. 834 9.3. Achieving simple data pull from consumers with reflexive Interests 836 An oft-cited use case for ICN network architectures is _Internet of 837 Things_ (IoT), where the sources of data are limited-resource sensor/ 838 actuators. Many approaches have been tried (e.g. [Baccelli2014], 839 [Lindgren2016], [Gundogan2018]) with varying degrees of success in 840 addressing the issues outlined in Section 1.1. The reflexive 841 forwarding extension may substantially ameliorate the documented 842 difficulties by allowing a different model for the basic interaction 843 of sensors with the ICN network. 845 Instead of simply acting as a producer (either directly to the 846 Internet or indirectly through the use of some form of application- 847 layer gateway), the IoT device need only act as a consumer to 848 initiate commuhication. When it has data to provide, it issues a 849 "phone-home" Interest message to a pre-configured rendezvous name 850 (e.g. an application-layer gateway or ICN Repo [Chen2015]) and 851 provides a reflexive name prefix TLV for the data it wishes to 852 publish. The target producer may then issue the necessary reflexive 853 Interest message(s) to fetch the data. Once fetched, validated, and 854 stored, the producer then responds to the original Interest message 855 with a success indication, possibly containing a Data object if 856 needed to allow the originating device to modify its internal state. 857 Alternatively, the producer might choose to not respond and allow the 858 original Interest to time out, although this is NOT RECOMMENDED 859 except in cases where the extra message transmission bandwith is at a 860 premium compared to the persistence of stale state in the forwarders. 861 We note that this interaction approach mirrors the earlier efforts 862 using Interest-Interest-Data designs. 864 Figure 4 depicts this interaction with the (optional) D1 message. 865 See Figure 2 for the details of the general Reflexive Forwarding 866 interaction. 868 +-----------+ +-----------+ 869 | Consumer | | Producer | 870 +-----------+ +-----------+ 871 ------------\ | | 872 | new IoT |-| | 873 | data item | | | 874 | produced | | | 875 |-----------| | | 876 ---------------\ | | 877 | "phone home" |-| | 878 | by notifying | | | 879 | producer | | | 880 |--------------| | | 881 | | 882 | I1 | 883 |-------------------->| 884 | | --------------------\ 885 | |-| generate Interest | 886 | | | for IoT data | 887 | | |-------------------| 888 | | 889 | RI1 | 890 |<--------------------| 891 -----------------\ | | 892 | send requested |-| | 893 | data object | | | 894 |----------------| | | 895 | | 896 | RD1 | 897 |-------------------->| 898 | | -----------------------\ 899 | |-| finalize interaction | 900 | | | with optional | 901 | | | Data message | 902 | | |----------------------| 903 | | 904 | D1 (optional) | 905 |<--------------------| 906 | | 907 Legend: 908 I1: Interest #1 containing the Reflexive Name Prefix TLV 909 D1: Data message (OPTIONAL), finalizing interaction 910 RI1: Reflexive Interest requesting the IoT data 911 RD1: Data message, answering RI, returning IoT data object 912 D1: (optional) Data answering I1 914 Figure 4: "Phone Home" Message Flow 916 There are two approaches that the IoT device can use for its response 917 to a reflexive Interest. It can simply construct a Data Message 918 bound through the usual ICN hash name to the reflexive Interest name. 919 Since the scope of any data object bound in this way is only the 920 duration of the enclosing Interest-Data exchange (see Section 10.2) 921 the producer would need to itself construct any persistent Data 922 object, name it, and sign it. This is sometimes the right approach, 923 as for some applications the identity of the originating IoT device 924 is not important from an operational or security point of view; in 925 contrast the identity of the gateway or Repo is what matters. 927 If alternatively, the persistent Data object should be bound from a 928 naming and security point of view to the originating IoT device, this 929 can be easily accomplished. Instead of directly placing the content 930 in a Data object responding to the reflexive Interest as above, the 931 consumer encapsulates a complete CCNx/NDN Data message (which 932 includes the desired name of the data) in the response to the 933 reflexive Interest message. 935 The interaction model described above brings a number potential 936 advantages, some obvious, some less so. We enumerate a few of them 937 as follows: 939 * By not requiring the IoT device to be actively listening for 940 Interests, it can sleep and only wake up if it has something to 941 communicate. Conversely, parties interested in obtaining data 942 from the device do not need to be constantly polling in order to 943 ascertain if there is new data available. 945 * No forwarder resources are tied up with state apart from the 946 actual reflexive forwarding interactions. All that is needed is 947 enough routing state in the FIB to be able to forward the "phone 948 home" Interest to an appropriate target producer. While this 949 model does not provide all the richness of a full Pub/Sub system 950 (like that described in [Gundogan2018]) we argue it is adequate 951 for a large subclass of such applications. 953 * The reflexive interest, through either a name suffix or Interest 954 payload, can give the IoT device useful context from which to 955 craft its Data object in response. One highly useful parameter 956 would be a robust clock value for the device to use as a timestamp 957 of the data, possibly as part of its name, to correctly place it 958 in a time seres of sensor readings. This substantially alleviates 959 the need for low-end devices to have a robust time base, as long 960 as they trust the producer they contact to provide it. 962 10. Implementation Considerations 964 There are a number of important aspects to the reflexive forwarding 965 design which affect correctness and performance of existing 966 forwarder, consumer, and producer implementations desiring to support 967 it. This section discusses the effect of each of these elements on 968 the CCNx/NDN protocol architecture. 970 10.1. Forwarder implementation considerations 972 10.1.1. Interactions with Input Processing of Interest and Data packets 974 Reflexive Interests are designed specifically to be no different from 975 any other Interest other than the use of the Reflexive Interest 976 Prefix name component type as their high-order name component. This 977 means that a forwarder does not have to have special handling in 978 terms of creation, and destruction, and other Interest processing 979 needs such as timeouts, Interest satisfaction, and caching of 980 returning data in the CS if desired. However, this design does 981 require additional processing for Reflexive Interests not needed in 982 the absence of reflexive forwarding. The most significant 983 requirements are: 985 * In order to locate the corresponding PIT entry for the original 986 Interest, the forwarder's packet input processing needs to be able 987 to efficiently locate the PIT entry of the original Interest that 988 contained the RNP TLV. 990 * Ensure that the high order name component of the Reflexive 991 Interest matches the RNP stored in that PIT entry. 993 There are a few additional considerations to highlight for high-speed 994 forwarders however; these are discussed in the following paragraphs. 996 In order to achieve forwarding scalability, high speed forwarders 997 need to exploit available parallelism in both CPU (through multiple 998 cores) and memory (through multiport DRAM and limiting accesses to 999 both DRAM and L3 caches). One commonly-used technique is _PIT 1000 sharding_, where the forwarder-global PIT is partitoned among cores 1001 such that all processing of both Interest and Data for a given Name 1002 is directed at the same core, optimizing both L1 I-cache utilization 1003 and L2/L3/DRAM throughput and latency. This is achieved in a number 1004 of implementations (e.g. [So2013]) by hashing the fullname in the 1005 Interest or Data and using that hash to select the assigned 1006 processing core (and associated memory banks). This efficiently 1007 distributes the load and minimizes the number of memory accesses 1008 other than to bytes of the input packet. 1010 Straightforward input name hashing to achieve a sharded PIT has one 1011 potentially undesirable side effect: the original Interest containing 1012 the Reflexive Name Prefix TLV and any resultant reflexive Interests 1013 issued by the producer will likely hash to different PIT shards, 1014 making any pointers that need to be traversed across shards or cross- 1015 shard updates expensive, possibly dramatically so. One could either 1016 optimize those accesses (as, for example, suggested in the discussion 1017 of Interest Lifetime in Section 10.1.2) or add special input handling 1018 of reflexive interests to steer them to the same shard as the 1019 original interest. This latter technique is what we have specified 1020 by making the use of PIT Tokens similar to those in [Shi2020] an 1021 important element of the design. 1023 10.1.2. Interactions with Interest Lifetime 1025 If and when a producer decides to fetch data from the consumer using 1026 one or more reflexive Interest-Data exchanges, the total latency for 1027 the original Interest-Data exchange is inflated, potentially by 1028 multiple RTTs. It is difficult for a consumer to predict the 1029 inflation factor when issuing the original Interest, and hence there 1030 can be a substantial hazard of that Interest lifetime expiring before 1031 completion of the full multi-way exchange. This can result in 1032 persistent failures, which is obviously highly undesirable. 1034 There is a fairly straightforward technique that can be employed by 1035 forwarders to avoid these "false" Interest lifetime expirations. In 1036 the absence of a superior alternative technique, it is RECOMMENDED 1037 that all forwarders implement the following algorithm. 1039 If and when a reflexive Interest arrives matching the original 1040 Interest's PIT entry, the forwarder examines the Interest lifetime of 1041 the arriving reflexive Interest. Call this value _IL_r_. The 1042 forwarder computes MAX(_IL_t, (IL_r * 1.5)_), and replaces _IL_t_ 1043 with this value. This in effect ensures that the remaining Interest 1044 lifetime of the original Interest accounts for the additional 1.5 1045 RTTs that may occur as a result of the reflexive Interest-Data 1046 exchange. 1048 | We note that this is not unduly expensive in this design where 1049 | the two PIT entries are guaranteed to be in the same PIT shard 1050 | on a high speed forwarder. The earlier design discussed in 1051 | Appendix A.1.2 required some additional gymnastics. 1053 While the above approach of inflating the interest lifetime of the 1054 original Interest to accommodate the additional RTTs of reflexive 1055 Interest-Data exchanges avoids the timeout problem, this does 1056 introduce a new vulnerability that must be dealt with. A Producer, 1057 either through a bug or malicious intent, could keep an originating 1058 Interest-Data exchange alive by continuing to send reflexive 1059 Interests back to the consumer, while the consumer had no way to 1060 terminate the enclosing interaction (there is no "cancel Interest" 1061 function in either NDN nor CCNx). To eliminate this hazard, if the 1062 consumer rejects a reflexive interest with a T_RETURN_PROHIBITED 1063 error, the forwarder(s), in addition to satisfying the coresponding 1064 PIT entry, MUST also delete the RNP from the original Interest's PIT 1065 entry, thereby preventing any further reflexive Interests from 1066 reaching the consumer. This allows the enclosing Interest-Data 1067 exchange to either time out or be correctly ended with a Data message 1068 or Interest Return from the Producer. 1070 10.1.3. Interactions with Interest aggregation and multi-path/multi- 1071 destination forwarding 1073 As with numerous other situations where multiple Interests for the 1074 same named object arrive containing different parameters (e.g. 1075 Interest Lifetime, QoS, payload hash) the same phenomenon occurs for 1076 the reflexive Name TLV. If Interests with different reflexive name 1077 prefix TLVs collide, the forwarder MUST NOT aggregate these Interest 1078 messages and instead MUST create a separate PIT entry for each. This 1079 in turn means that a different Forward PIT-Token (FPT) will be placed 1080 in the individual forwarded Interests. 1082 Forwarders supporting multi-path forwarding may of course exploit 1083 this capability for Interests with identical reflexive name prefix 1084 TLVs, like any other Interests. There are two sub-cases of multi- 1085 next hop behavior; regular multi-path (where the split traffic 1086 reconverges further upstream) and multi-destination (where it doesn't 1087 and the Interest reaches multiple producers). 1089 For multi-path, since the Interests that converge upstream carry 1090 identical reflexive Interest name TLVs, they will get aggregated. 1091 The forwarder might, just as for any other Interest, decide to either 1092 do single or multi-path forwarding of that reflexive Interest. If 1093 sent multi-path in parallel, these also will reconverge on the 1094 inverse path and get aggregated. The inclusion of the Forward PIT- 1095 Token (FPT) in the forwarded Interest is unaffected by multi-path 1096 since it is only used on returning Data messages or Reflexive 1097 Interests to access the correct PIT entry. 1099 For multi-destination, reflexive Interests might get issued by 1100 multiple producers, but they will carry the same reflexive name 1101 prefix and hence be forwarded using the ingress face of the same 1102 original Interest PIT entry until reaching the join point, at which 1103 they will get aggregated and thus handled identically to any other 1104 Interest(s) subject to aggregation. 1106 10.2. Consumer Implementation Considerations 1108 10.2.1. Data objects returned by the consumer to reflexive name 1109 Interests arriving from a producer 1111 The Data objects returned to the producer in response to a reflexive 1112 Interest are normal CCNx/NDN data objects. The object returned in 1113 response to a reflexive Interest is named with its hash as the 1114 trailing component of the reflexive Interest name, and hence the 1115 scope of the object is under most circumstances meaningful only for 1116 the duration of the enclosing Interest-Data interaction. This 1117 property is ideal for naming and securing data that is "part of" the 1118 enclosing interaction - things like method arguments, authenticators, 1119 and key exchange parameters, but not for the creation and naming of 1120 objects intended to survive outside the current interaction's scope 1121 (c.f. Section 9.3, which describes how to provide globally-named 1122 objects using encapsulation). In general, the consumer should use 1123 the following guidelines in creating Data messages in response to 1124 reflexive Interest messages from the producer. 1126 (a) Set the recommended cache time (T_CACHETIME) either to zero, or 1127 a value no greater than the Interest lifetime (T_INTLIFE) of the 1128 original Interest messsage. 1130 (b) Set the payload type (T_PAYLDTYPE) according to the type of 1131 object being returned (e.g. object, link, manifest) 1133 (c) Set the expiry time (T_EXPIRY) to a value greater than _now_, 1134 and less than or equal to the _now_ + Interest lifetime 1135 (T_INTLIFE) of the original Interest messsage. 1137 10.2.2. Terminating unwanted reflexive Interest exchanges 1139 A consumer may wish to stop receiving reflxive Interests due to 1140 possible erors or malicious behavior on the part of the producer. 1141 Therefore, if the consumer receives an unwanted reflexive Interest, 1142 it SHOULD reject that interest with a T_RETURN_PROHIBITED error (See 1143 section 10.3.6 of [RFC8609] ). This will provoke the forwarders to 1144 prevent further reflexive Interests from reaching the consumer, as 1145 described above in Section 10.1.2, Paragraph 5. 1147 10.2.3. Interactions with caching 1149 The reflexive named objects provide "local", temporary names that are 1150 only defined for one specific interaction between a consumer and a 1151 producer. Corresponding Data objects MUST NOT be shared among 1152 multiple consumers (violating this would require special gyrations by 1153 the producer since the reflexive Name utilizes per-consumer/per- 1154 interaction random values). A producer MUST NOT issue an Interest 1155 message for any reflexive name after it has sent the final Data 1156 message answering the original Interest. 1158 Forwarders SHOULD still cache reflexive Data objects for 1159 retransmissions within a transactions, but they MUST invalidate or 1160 remove them from the content store when they forward the final Data 1161 message answering the original Interest. 1163 10.3. Producer Implementation Considerations 1165 Producers receiving an Interest with a Reflexive Name Component, MAY 1166 decide to issue Interests for the corresponding Data objects. All 1167 Reflexive Interest message that a producer sends MUST be sent over 1168 the face that the original Interest was received on. 1170 11. Operational Considerations 1172 This extension represents a substantial enhancement to the CCNx/NDN 1173 protocol architecture and hence has important forward and backward 1174 compatibility effects. The most important of these is that correct 1175 operation of the scheme requires an unbroken chain of forwarders 1176 between the consumer and the desired producer that support the 1177 Reflexive Name TLV, the Forward and Backward PIT-Token TLVs and the 1178 corresponding forwarder capabilities specified in Section 7. When 1179 this invariant is not satisfied, some means is necessary to detect 1180 and hopefully recover from the error. We have identified three 1181 possible approaches to handling the lack of universal deployment of 1182 forwarders supporting the reflexive forwarding scheme. 1184 The first approach simply lets the producer detect the error by 1185 getting a "no route to destination" error when trying to send an 1186 Interest to a reflexive name. This will catch the error, but only 1187 after forwarding resources are tied up and the producer has done some 1188 work on the original Interest message. Further, the producer would 1189 need a bit of smarts to determine that this is a permanent error and 1190 not a transient to be retried. In order for the consumer to attempt 1191 recovery, there might be a need for some explicit error returned for 1192 the original interest to tell the consumer what the likely problem 1193 is. This approach does not enable an obvious recovery path for the 1194 consumer either, since if the producer cannot easily detect the 1195 error, the consumer has no way to know if a retry has any chance of 1196 succeeding. 1198 A second approach is to bump the CCNx/NDN protocol version to 1199 explicitly indicate the lack of compatability. Such Interests would 1200 be rejected by forwarders not supporting these protocol extensions. 1201 A consumer wishing to use the reflexive name TLV together with 1202 Reverse PIT-Tokens, would use the higher protocol version on those 1203 Interest messages (but could of course continue to use the current 1204 version number on other Interest messages). This is a big hammer, 1205 but may be called for in this situation because: 1207 (a) it detects the problem immediately and deterministically, and 1209 (b) one could assume an ICN routing protocol that would only forward 1210 to a next hop that supports the updated protocol version number. 1211 The supported forwarder protocol versions would have been 1212 communicated in the routing protocol ahead of time. 1214 A third option is to, as a precondition to utilizing the protocol in 1215 a deployment, create and deploy a neighbor capability exchange 1216 protocol which will tell a downstream forwarder if the upstream can 1217 handle the new TLV. This might avoid the large hammer of updating 1218 the protocol version, but of course this puts a pretty strong 1219 dependency on somebody actually designing and publishing such a 1220 protocol! On the other hand, a neighbor capability exchange protocol 1221 for CCNx/NDN would have a number of other substantial benefits, which 1222 makes it worth seriously considering anyway. 1224 12. Mapping to CCNx and NDN packet encodings 1225 12.1. Packet encoding for CCNx 1227 For CCNx[RFC8569] this specification defines one new Name Component 1228 TLV type, and two hop-by-hop option TLVs. 1230 +==================+================+==========================+ 1231 | Abbrev | Name | Description | 1232 +==================+================+==========================+ 1233 | T_REFLEXIVE_NAME | Reflexive Name | Name component to use as | 1234 | | Component | name prefix in Reflexive | 1235 | | | Interest Messages | 1236 +------------------+----------------+--------------------------+ 1238 Table 1: Reflexive Name TLV 1240 +========+=========+===============================================+ 1241 | Abbrev | Name | Description | 1242 +========+=========+===============================================+ 1243 | T_FPT | Forward | 1-32 byte value chosen by the forwarder for a | 1244 | | PIT | PIT entry communicated upstream toward a | 1245 | | TOKEN | producer | 1246 +--------+---------+-----------------------------------------------+ 1247 | T_RPT | Reverse | 1-32 byte value placed in either a Data | 1248 | | PIT | packet or a Reflexive Interest packet by a | 1249 | | TOKEN | producer or forwarder to allow the downstream | 1250 | | | forwarder to access the PIT entry identified | 1251 | | | by a received forward PIT Token (FPT) | 1252 +--------+---------+-----------------------------------------------+ 1254 Table 2: Hop-by-hop PIT Token TLVs 1256 12.2. Packet encoding for NDN 1258 *These are proposed assignments based on [NDNTLV]. Suggestions from 1259 the NDN team would be greatly appreciated.* 1261 12.2.1. Reflexive Name Component Type 1263 The NDN Name component TLVs needs to have a new component type added 1264 with type RNP (for reflexive name prefix). We suggest something 1265 like: *TBD* 1267 | *Note:*It seems like the current 0.2.1 packet format only has 1268 | allocated two name component types - a _GenericNameComponent_ 1269 | and a _ImplicitSha256DigestComponent_. Shouldn't there be more 1270 | types by now or is this spec out of date? 1272 12.2.2. Reflexive Name Prefix TLV 1274 The Reflexive Name Prefix TLV needs to be added to the NDN Interest 1275 packet format. We suggest using [RFC4122], hence something like: 1277 +---------+----------+------------------------+ 1278 | RNP ::= | RNP-TYPE | TLV-LENGTH(=16) BYTE8) | 1279 +---------+----------+------------------------+ 1281 Table 3: Proposed Reflexive Name Prefix TLV 1282 for NDN Interest Packet 1284 12.2.3. PIT Tokens for NDNLPv2 1286 The current NDN Link Protocol current has an assignment for the PIT 1287 Token mechanism pioneered in [Shi2020]. That approach only needed a 1288 single field, since PIT Tokens are only used to express one 1289 "direction" - for consumer-to-producer Interests and producer-to- 1290 consumer Data messages. This specification employs PIT Tokens not 1291 only on enclosing Interest-Data exchanges, but also on Reflexive 1292 Interests to locate the PIT entry of an enclosing Interest on 1293 reception by a forwarder. Therefore we suggest that the existing 1294 NDNLPv2 assignment of 1296 +---------------+--------------------------------------+ 1297 | LpHeaderField | PitToken | 1298 +---------------+--------------------------------------+ 1299 | PitToken | PIT-TOKEN-TYPE TLV-LENGTH 1*32OCTET> | 1300 +---------------+--------------------------------------+ 1302 Table 4: Current NDNLPv2 PIT Token assignment 1304 be renamed to indicate its use in the forward direction of consumer 1305 to producer Interests and returning Data, and a second allocation be 1306 done for a _Reverse PIT Token_ specifically for inclusion in 1307 Reflexive Interests as follows: 1309 +-----------------+--------------------------------------+ 1310 | LpHeaderField | ReversePitToken | 1311 +-----------------+--------------------------------------+ 1312 | ReversePitToken | PIT-TOKEN-TYPE TLV-LENGTH 1*32OCTET> | 1313 +-----------------+--------------------------------------+ 1315 Table 5: Proposed NDNLPv2 Reverse PIT Token assignment 1317 13. IANA Considerations 1319 13.1. Reflexive Name Prefix TLV 1321 Please add the T_REFLEXIVE_NAME component TLV to the CCNx Name types 1322 TLV types registry of [RFC8609], with Length 16 bytes and type of 128 1323 bit random value. 1325 1 2 3 1326 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1327 +---------------+---------------+---------------+---------------+ 1328 | T_REFLEXIVE_NAME | 16 | 1329 +---------------+---------------+---------------+---------------+ 1330 | | 1331 | 128 bit value randomly assigned by consumer | 1332 +-------------------------------+-------------------------------+ 1334 Figure 5: Reflexive Name component type 1336 13.2. Forward and Reverse PIT-Token hop-by-hop option TLVs 1338 Please add the T_FPT and T_RPT TLVS to the CCNx Hop-by-Hop Type 1339 Registry of [RFC8609], with Length 1-32 bytes and type of random 1340 value. 1342 1 2 3 1343 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1344 +---------------+---------------+---------------+---------------+ 1345 | T_FPT | 1-32 | 1346 +---------------+---------------+---------------+---------------+ 1347 | | 1348 | 1-32 byte value randomly assigned by forwarder | 1349 +-------------------------------+-------------------------------+ 1351 Figure 6: Forward PIT-Token hop-by-hop TLV 1353 1 2 3 1354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1355 +---------------+---------------+---------------+---------------+ 1356 | T_RPT | 1-32 | 1357 +---------------+---------------+---------------+---------------+ 1358 | | 1359 | 1-32 byte value randomly assigned by forwarder | 1360 +-------------------------------+-------------------------------+ 1362 Figure 7: Reverse PIT-Token hop-by-hop TLV 1364 14. Security Considerations 1366 One of the major motivations for the reflexive forwarding extension 1367 specified in this document is in fact to enable better security and 1368 privacy characteristics for ICN networks. The main considerations 1369 are presented in Section 1, but we briefly recapitulate them here: 1371 * Current approaches to authentication and data transfer often use 1372 payloads in Interest messages, which are clumsy to secure 1373 (Interest messages must be signed) and as a consequence make it 1374 very difficult to ensure consumer privacy. Reflexive forwarding 1375 moves all sensitive data to the Data messages sent in response to 1376 reflexive Interests, which are secured in the same manner as all 1377 other Data messages in the CCNx and NDN protocol designs. 1379 * In many scenarios, consumers are forced to also act as producers 1380 so that data may be fetched by either a particular, or arbitrary 1381 other party. The means the consumer must arrange to have a 1382 routable name prefix and that prefix be disseminated by the 1383 routing protocol or other means. This represents both a privacy 1384 hazard (by revealing possible important information about the 1385 consumer) and a security concern as it opens up the consumer to 1386 the full panoply of flooding and crafted Interest Denial of 1387 Service attacks. 1389 * In order to achieve multi-way handshakes, in current designs a 1390 consumer wishing a producer to communicate back must inform the 1391 producer of what (globally routable) name to use. This gives the 1392 consumer a convenient means to mount a variety of reflection 1393 attacks by enlisting the producer to send Interests to desired 1394 victims. 1396 As a major protocol extension however, this design brings its own 1397 potential security issues, which are discussed in the following 1398 subsections. 1400 14.1. Collisions of reflexive Interest names 1402 Reflexive Interest names are constructed using 128-bit random 1403 numbers. This is intended to ensure an off-path attacker cannot 1404 easily manufacture a matching reflexive Interest and either 1405 masquerade as the producer, or mount a denial of service attack on 1406 the consumer. It also limits tracking through the linkability of 1407 Interests containing a re-used random value. 1409 Therefore consumers MUST utilize a robust means of generating these 1410 random values, and it is RECOMMENDED that the [RFC4122] format be 1411 used, with a pseudo-random number generator (PRNG) approved for use 1412 with cryptographic protocols. 1414 14.2. Additional resource pressure on PIT and FIB 1416 Normal Interest message processing in CCNx and NDN needs to consider 1417 effect of various resource depletion attacks on the PIT, particularly 1418 in the form of Interest flooding attacks (see [Gasti2012] for a good 1419 overview of DoS and DDoS mitigation on ICN networks). Interest 1420 messages utilizing this reflexive forwarding extension can place 1421 additional resource pressure on the PIT. 1423 While this does not represent a new DoS/DDoS attack vector, the 1424 ability of a malicious consumer to utilize this extension in an 1425 attack does represent an increased risk of resource depletion, 1426 especially if such Interests are given unfair access to PIT and FIB 1427 resources. Implementers SHOULD therefore protect PIT and FIB 1428 resources by weighing requests for reflexive forwarding resources 1429 appropriately relative to other Interests. 1431 14.3. Potential Vulnerabilities from the use of PIT Tokens 1433 By including PIT Tokens in the CCNx or NDN protocol, an attacker has 1434 the opportunity to manipulate these values by either replacement or 1435 elision. So far we do not have enough experimental data nor formal 1436 security analysis to assess whether useful attacks against the 1437 protocol via the PIT Tokens can be mounted. The fields are carried 1438 differently in CCNx and NDN, but in both cases they are outside the 1439 cryptographic integrity envelope and not encrypted for 1440 confidentiality as part of the base protocols. 1442 For both cases however, the potential vulnerabilities can be foiled, 1443 at least for point-to-point communication over an L2 hop, by 1444 employing either link-layer encryption (in the case of CCNx), or by 1445 encrypting the NDNLPv2 protocol, which carries these fields for NDN. 1447 14.4. Privacy Considerations 1449 ICN architectures like CCNx and NDN provide a rich tapestry of 1450 interesting privacy issues, which have been extensively explored in 1451 the research literature. The fundamental tradeoffs for privacy 1452 concern the risk of exposing the names of information objects to the 1453 forwarding elements of the network, which is a necessary property of 1454 any name-based routing and forwarding design. Numerous approaches 1455 have been explored with varying degrees of success, such as onion 1456 routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), and name 1457 obfuscation ([Arianfar2011]) among others. 1459 Reflexive forwarding does not change the overall landscape of privacy 1460 tradeoffs, nor seem to introduce additional hazards. In fact, the 1461 privacy exposures are confined to the inverse path of forwarders from 1462 the producer to the consumer, through which the original Interest 1463 forwarding may have already exposed names on path. Similar name 1464 privacy techniques to those cited above may be equally applied to the 1465 names in reflexive Interests. 1467 While the individual reflexive Interest-Data exchanges have similar 1468 properties to those in any NDN or CCNx exchange, the target usages by 1469 applications may have interaction patterns that are subject to 1470 relatively straightforward fingerprinting by adversaries. For 1471 example, a particular RMI invocation may fingerprint simply through 1472 the count of arguments fetched by the producer and their sizes. The 1473 attacker must however be on path, which somewhat ameliorates the 1474 exposure hazards. 1476 15. Normative References 1478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1479 Requirement Levels", BCP 14, RFC 2119, 1480 DOI 10.17487/RFC2119, March 1997, 1481 . 1483 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1484 Networking (CCNx) Semantics", RFC 8569, 1485 DOI 10.17487/RFC8569, July 2019, 1486 . 1488 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1489 Networking (CCNx) Messages in TLV Format", RFC 8609, 1490 DOI 10.17487/RFC8609, July 2019, 1491 . 1493 16. Informative References 1495 [Arianfar2011] 1496 Arianfar, S., Koponen, T., Raghavan, B., and S. Shenker, 1497 "On preserving privacy in content-oriented networks, in 1498 ICN '11: Proceedings of the ACM SIGCOMM workshop on 1499 Information-centric networking", 1500 DOI https://doi.org/10.1145/2018584.2018589, August 2011, 1501 . 1503 [Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., 1504 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less 1505 Producer Mobility in Content-Centric Networks, in IEEE 1506 Transactions on Network, Volume 15, Issue 2", 1507 DOI 10.1109/TNSM.2018.2796720, June 2018, 1508 . 1510 [Baccelli2014] 1511 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 1512 Wählisch, "Information centric networking in the IoT: 1513 experiments with NDN in the wild, in ACM-ICN '14: 1514 Proceedings of the 1st ACM Conference on Information- 1515 Centric Networking", DOI 10.1145/2660129.2660144, 1516 September 2014, 1517 . 1519 [Carzaniga2011] 1520 Carzaniga, A., Papalini, M., and A.L. Wolf, "Content-Based 1521 Publish/Subscribe Networking and Information-Centric 1522 Networking", DOI 10.1145/2018584.2018599, September 2011, 1523 . 1526 [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDSS: A Named Data Storage 1527 System, in International Conference on Cloud and Autonomic 1528 Computing", DOI 10.1109/ICCAC.2015.12, September 2014, 1529 . 1531 [DiBenedettoGTU12] 1532 DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzun, 1533 "ANDaNA: Anonymous Named Data Networking Application, in 1534 NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2, 2102, 1535 . 1538 [Gasti2012] 1539 Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang, "DoS 1540 and DDoS in Named Data Networking, in 22nd International 1541 Conference on Computer Communication and Networks 1542 (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August 2013, 1543 . 1545 [Ghali2017] 1546 Tsudik, G., Ghali, C., and C. Wood, "When encryption is 1547 not enough: privacy attacks in content-centric networking, 1548 in ICN '17: Proceedings of the 4th ACM Conference on 1549 Information-Centric Networking", 1550 DOI https://doi.org/10.1145/3125719.3125723, September 1551 2017, 1552 . 1554 [Gundogan2018] 1555 Gündoğan, C., Kietzmann, P., Schmidt, T., and M. Wählisch, 1556 "HoPP: publish-subscribe for the constrained IoT, in ICN 1557 '18: Proceedings of the 5th ACM Conference on Information- 1558 Centric Networking", DOI 10.1145/3267955.3269020, 1559 September 2018, 1560 . 1562 [I-D.irtf-icnrg-flic] 1563 Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, "File- 1564 Like ICN Collections (FLIC)", Work in Progress, Internet- 1565 Draft, draft-irtf-icnrg-flic-03, 7 November 2021, 1566 . 1569 [I-D.oran-icnrg-pathsteering] 1570 Moiseenko, I. and D. Oran, "Path Steering in CCNx and 1571 NDN", Work in Progress, Internet-Draft, draft-oran-icnrg- 1572 pathsteering-06, 5 May 2022, 1573 . 1576 [Krol2018] Krol, M., Habak, K., Oran, D., Kutscher, D., and I. 1577 Psaras, "RICE: Remote Method Invocation in ICN, in 1578 Proceedings of the 5th ACM Conference on Information- 1579 Centric Networking — ICN '18", 1580 DOI 10.1145/3267955.3267956, September 2018, 1581 . 1584 [Lindgren2016] 1585 Lindgren, A., Ben Abdessiem, F., Ahlgren, B., Schlelén, 1586 O., and A.M. Malik, "Design choices for the IoT in 1587 Information-Centric Networks, in 13th IEEE Annual Consumer 1588 Communications and Networking Conference (CCNC)", 1589 DOI 10.1109/CCNC.2016.7444905, January 2016, 1590 . 1592 [Moiseenko2014] 1593 Moiseenko, I., Stapp, M., and D. Oran, "Communication 1594 patterns for web interaction in named data networking", 1595 DOI 10.1145/2660129.2660152, September 2014, 1596 . 1598 [Mosko2017] 1599 Mosko, M., "CCNx 1.0 Bidirectional Streams", 1600 arXiv 1707.04738, July 2017, 1601 . 1603 [NDN] "Named Data Networking", 2020, 1604 . 1606 [NDNTLV] "NDN Packet Format Specification", 2016, 1607 . 1609 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1610 A., Peterson, J., Sparks, R., Handley, M., and E. 1611 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1612 DOI 10.17487/RFC3261, June 2002, 1613 . 1615 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1616 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1617 DOI 10.17487/RFC4122, July 2005, 1618 . 1620 [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session 1621 Initiation Protocol (SIP) Usage of the Offer/Answer 1622 Model", RFC 6337, DOI 10.17487/RFC6337, August 2011, 1623 . 1625 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 1626 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 1627 March 2015, . 1629 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1630 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1631 . 1633 [RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 1634 D., and C. Tschudin, "Information-Centric Networking 1635 (ICN): Content-Centric Networking (CCNx) and Named Data 1636 Networking (NDN) Terminology", RFC 8793, 1637 DOI 10.17487/RFC8793, June 2020, 1638 . 1640 [Shi2020] Shi, J., Pesavento, D., and L. Benmohamed, "NDN-DPDK: NDN 1641 Forwarding at 100 Gbps on Commodity Hardware, in 1642 Proceedings of the 7th ACM Conference on Information- 1643 Centric Networking — ICN '20", 1644 DOI 10.1145/3405656.3418715, September 2020, 1645 . 1647 [So2013] So, W., Narayanan, A., and D. Oran, "Named data networking 1648 on a router: Fast and DoS-resistant forwarding with hash 1649 tables, in proceedings of Architectures for Networking and 1650 Communications Systems", DOI 10.1109/ANCS.2013.6665203, 1651 October 2013, 1652 . 1654 [Zhang2018] 1655 Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang, "KITE: 1656 Producer Mobility Support in Named Data Networking, in 1657 Proceedings of the 5th ACM Conference on Information- 1658 Centric Networking — ICN '18", 1659 DOI 10.1145/3267955.3267959, September 2018, 1660 . 1663 Appendix A. Alternative Designs Considered 1665 During development of this specification, a number of alternative 1666 designs were considered and at least partially documented. This 1667 appendix explains them for historical purposes, and explains why 1668 these were considered inferior to the design we settled on to carry 1669 forward. 1671 A.1. Handling reflexive interests using dynamic FIB entries 1673 The original draft specification employed the use of dynamically- 1674 created FIB entries for forwarding Reflexive Interests. In this 1675 approach, at each forwarder along the inverse path from producer to 1676 consumer, a FIB entry must be present that matches this name via 1677 Longest Name Prefix Match (LNPM), so that when the reflexive interest 1678 arrives, the forwarder can forward it downstream toward the 1679 originating consumer. This FIB entry would point directly to the 1680 incoming interface on which the corresponding original Interest 1681 arrived. The FIB entry needs to be created as part of the forwarding 1682 of the original Interest so that it is available in time to catch any 1683 reflexive Interest issued by the producer. It would usually make 1684 sense to destroy this FIB entry when the Data message satisfying the 1685 original Interest arrives since this avoids any dangling stale state. 1686 Given the design details discussed below, stale FIB state would not 1687 represent a correctness hazard and hence could be done lazily if 1688 desired in an implementation. 1690 In this scheme, the forwarder operates as follows: 1692 1. The forwarder creates short-lifetime FIB entries for any 1693 Reflexive Interest Name prefixes communicated in an Interest 1694 message. If the forwarder does not have sufficient resources to 1695 do so, it rejects the Interest with the T_RETURN_NO_RESOURCES 1696 error - the same error used if the forwarder were lacking 1697 sufficient PIT resources to process the Interest message. 1699 2. Those FIB entries are queried whenever an Interest message 1700 arrives whose first name component is of the type _Reflexive 1701 Interest Name Component (RNP)_ 1703 3. The FIB entry gets removed eventually, after the corresponding 1704 Data message has been forwarded. One option would be to remove 1705 the FIB directly after the Data message has been forwarded. 1706 However, the forwarder might choose do lazy cleanup. 1708 There are a number of additional considerations with this design that 1709 need to be dealt with. 1711 A.1.1. Design complexities and performance issues with FIB-based design 1713 When processing an Interest containing the reflexive name TLV and 1714 creating the necessary FIB entry, the forwarder also creates a _back 1715 pointer_ from that FIB entry to the PIT entry for the Interest 1716 message that created it. This PIT entry contains the current value 1717 of the remaining Interest lifetime or alternatively a value from 1718 which the remaining Interest lifetime can be easily computed. Call 1719 this value _IL_t_. 1721 The forwarder input thread could key off the high-order name 1722 component type (one byte) and if reflexive, do a reflexive FIB lookup 1723 instead of a full name hash. The reflexive FIB entry would contain 1724 the shard identity of the matching Interest (concretely, the core id 1725 servicing the shard) and steer the reflexive interest there. The 1726 reflexive name prefix FIB lookup would have to be competitive 1727 performance-wise with a full-name hash for this to win, however. 1728 Experimentation is needed to further evaluate such implementation 1729 tradeoffs for input packet load balancing in high-speed forwarders. 1731 The FIB is a performance-critical data structure in any forwarder, as 1732 it needs to support relatively expensive longest name prefix match 1733 (LNPM) lookup algorithms. A number of well-known FIB data structures 1734 are heavily optimized for read access, since for normal Interest 1735 message processing the FIB changes slowly - only after topological 1736 changes or routing protocol updates. Support for reflexive names 1737 using dynamic FIB entries changes this, as FIB entries would be 1738 created and destroyed rapidly as Interest messages containing 1739 reflexive name TLVs are processed and the corresponding Data messages 1740 come back. 1742 While it may be feasible, especially in low-end forwarders handling a 1743 low packet forwarding rate to ignore this problem, for high-speed 1744 forwarders there are a number of hazards, including: 1746 1. If the entire FIB needs to be locked in order to insert or remove 1747 entries, this could cause inflated forwarding delays or in 1748 extreme cases, forwarding performance collapse. 1750 2. A number of high-speed forwarder implementations employ a sharded 1751 PIT scheme (see Section 10.1.1) to better parallelize forwarding 1752 across processing cores. The FIB, however, is still a shared 1753 data structure which is either read without read locks across 1754 cores, or explicitly copied such that there is a separate copy of 1755 the FIB for each PIT shard. Clearly, a high update rate without 1756 read locks and/or updating many copies of the FIB are 1757 unattractive implementation options. (Note: unlike the adopted 1758 scheme in the main specification, by just depending on a dynamic 1759 FIB it is not feasible to force reflexive interests to be hashed 1760 or be otherwise directed to the PIT shard holding the original 1761 Interest state). 1763 There are any number of alternative FIB implementations that can work 1764 adequately. The most straightforward would be to simply implement a 1765 "special" FIB for just reflexive name lookups. This is feasible 1766 because reflexive names deterministically contain the distinguished 1767 high-order name component type of T_REFLEXIVE_NAME, whose content is 1768 a 64-bit value that can be easily hashed to a FIB entry directly, 1769 avoiding the more expensive LNPM lookup. Inserts and deletes then 1770 devolve to the well-understood problem of hash table maintenance. 1772 A.1.2. Interactions between FIB-based design and Interest Lifetime 1774 If Interest lifetime handling is implemented naively, it may run 1775 afoul of a sharded PIT forwarder implementation, since the PIT entry 1776 for the reflexive Interest and the PIT entry for the original 1777 Interest may be in different shards. Therefore, if the update is 1778 done cross-shard on each reflexive Interest arrival, performance may 1779 suffer, perhaps dramatically. Instead, the following approach to 1780 updating the Interest lifetime after computing the new value is would 1781 be needed by this FIB-based design for sharded-PIT forwarders. 1783 When creating the reflexive FIB entry as above in Appendix A.1.1, 1784 copy the remaining Interest lifetime from the PIT entry. Do the PIT 1785 update if and only if this value is about to expire, thus paying the 1786 cross-shard update cost only if the original Interest is about to 1787 expire. A further optimization at the cost of modest extra 1788 complexity is to instead _queue_ the update to the core holding the 1789 shard of the original PIT entry rather than doing the update 1790 directly. If the PIT entry expires or is satisfied, instead of 1791 removing it the associated core checks the update queue and does the 1792 necessary update. 1794 A.2. Reflexive forwarding using Path Steering 1796 We also considered leveraging Path Steering 1797 [I-D.oran-icnrg-pathsteering] Path Labels that inform the forwarder 1798 at each hop which outgoing face to use for for forwarding the 1799 Reflexive Interest. In this approach, the producer, when creating 1800 and issuing the Reflexive Interest with the Reflexive Name Prefix 1801 includes a Path Label to strictly steer the forwarding at all hops 1802 from the producer to the consumer (strict mode Path Steering). This 1803 means, the Reflexive Interest carries the Reflexive Name Prefix, but 1804 forwarders do not apply LNPM or any other outgoing face selection 1805 based on the name. It also eliminates the need for dynamic FIB 1806 entries as discussed above in Appendix A.1. Instead the forwarding 1807 is strictly steered by the Path Label using regular Path Steering 1808 semantics. 1810 The message flow using Path Steering would look like the following: 1812 +-----------+ +-----------+ +-----------+ 1813 | Consumer | | Forwarder | | Producer | 1814 +-----------+ +-----------+ +-----------+ 1815 | -----------------------------\ | | 1816 |-| Create I1 with additional, | | | 1817 | | emptyPath Label | | | 1818 | | data structure | | | 1819 | | for reverse discovery | | | 1820 | |----------------------------| | | 1821 | | | 1822 | I1 with Path Label | | 1823 | and RNP TLV | | 1824 |----------------------------------->| | 1825 | | -----------------\ | 1826 | |-| Add path label | | 1827 | | | for adjacency | | 1828 | | | to Consumer | | 1829 | | |----------------| | 1830 | | | 1831 | | I1 | 1832 | |-------------------------->| 1833 | | ------------------\ | 1834 | | | Create RI state |-| 1835 | | |-----------------| | 1836 | | | 1837 | | RI with RNP | 1838 | | and path label | 1839 | | (strict mode) | 1840 | |<--------------------------| 1841 | --------------------------\ | | 1842 | | perform path label |-| | 1843 | | switching (no FIB info) | | | 1844 | |-------------------------| | | 1845 | | | 1846 | RI with RNP | | 1847 |<-----------------------------------| | 1848 | | | 1849 | D2 (RNP) | | 1850 |----------------------------------->| | 1851 | | --------------------\ | 1852 | |-| regular PIT-based | | 1853 | | | forwarding | | 1854 | | |-------------------| | 1855 | | | 1856 | | D2 (RNP) | 1857 | |-------------------------->| 1858 | | -----------------\ | 1859 | | | all parameters |-| 1860 | | | received, | | 1861 | | | answer orig. | | 1862 | | | I1 Interest | | 1863 | | |----------------| | 1864 | | | 1865 | | D1 | 1866 | |<--------------------------| 1867 | --------------------\ | | 1868 | | regular PIT-based |-| | 1869 | | forwarding | | | 1870 | |-------------------| | | 1871 | | | 1872 | D1 | | 1873 |<-----------------------------------| | 1874 | | | 1876 Legend: 1877 I1: Interest #1 containing the Reflexive Name Prefix TLV 1878 RI: Reflexive Interest with Reflexive Name Prefix Component 1879 RNP: Reflexive Name Prefix 1880 D1: Data message, answering initiating I1 Interest 1881 D2: Data message, answering RI 1883 Figure 8: Message Flow Overview using Path Steering 1885 Path Steering uses Path Label data structures on the downstream path 1886 (from producer to consumer) to discover and collect hop-by-hop 1887 forwarding information so that consumers can then specify selected 1888 paths for subsequent Interests. Reflexive Forwarding would use the 1889 same data structure, but for "reverse discovery", i.e., in the 1890 upstream direction from consumer to producer. 1892 From an operational perspective the path-steering approach does not 1893 exhibit good properties with respect to backward compatibility. 1894 Without a complete path of forwarders between consumer and producer 1895 that support path steering, reflexive interests cannot reach the 1896 intended consumer. While we might envision a way to steer a 1897 subsequent Interest onto a working path as proposed in 1898 [I-D.oran-icnrg-pathsteering], there is no capability to force 1899 Interest routing away from an otherwise working path not supporting 1900 the reflexive name TLV. 1902 Authors' Addresses 1904 Dave Oran 1905 Network Systems Research and Design 1906 4 Shady Hill Square 1907 Cambridge, MA 02138 1908 United States of America 1909 Email: daveoran@orandom.net 1911 Dirk Kutscher 1912 University of Applied Sciences Emden/Leer 1913 Constantiapl. 4 1914 26723 Emden 1915 Germany 1916 Email: ietf@dkutscher.net 1917 URI: https://dirk-kutscher.info