idnits 2.17.1 draft-oran-icnrg-reflexive-forwarding-02.txt: -(1556): 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 6 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 (16 February 2022) is 798 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-05 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: 20 August 2022 16 February 2022 8 Reflexive Forwarding for CCNx and NDN Protocols 9 draft-oran-icnrg-reflexive-forwarding-02 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 20 August 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 . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . 16 76 9.2. RESTful Web Interactions . . . . . . . . . . . . . . . . 18 77 9.3. Achieving simple data pull from consumers with reflexive 78 Interests . . . . . . . . . . . . . . . . . . . . . . . . 19 79 10. Implementation Considerations . . . . . . . . . . . . . . . . 22 80 10.1. Forwarder implementation considerations . . . . . . . . 22 81 10.1.1. Interactions with Input Processing of Interest and 82 Data packets . . . . . . . . . . . . . . . . . . . . 22 83 10.1.2. Interactions with Interest Lifetime . . . . . . . . 23 84 10.1.3. Interactions with Interest aggregation and multi-path/ 85 multi-destination forwarding . . . . . . . . . . . . 24 86 10.2. Consumer Implementation Considerations . . . . . . . . . 25 87 10.2.1. Data objects returned by the consumer to reflexive 88 name Interests arriving from a producer . . . . . . . 25 89 10.2.2. Terminating unwanted reflexive Interest exchanges . 25 90 10.2.3. Interactions with caching . . . . . . . . . . . . . 26 91 10.3. Producer Implementation Considerations . . . . . . . . . 26 92 11. Operational Considerations . . . . . . . . . . . . . . . . . 26 93 12. Mapping to CCNx and NDN packet encodings . . . . . . . . . . 27 94 12.1. Packet encoding for CCNx . . . . . . . . . . . . . . . . 28 95 12.2. Packet encoding for NDN . . . . . . . . . . . . . . . . 28 96 12.2.1. Reflexive Name Component Type . . . . . . . . . . . 28 97 12.2.2. Reflexive Name Prefix TLV . . . . . . . . . . . . . 29 98 12.2.3. PIT Tokens for NDNLPv2 . . . . . . . . . . . . . . . 29 99 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 100 13.1. Reflexive Name Prefix TLV . . . . . . . . . . . . . . . 30 101 13.2. Forward and Reverse PIT-Token hop-by-hop option TLVs . . 30 102 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31 103 14.1. Collisions of reflexive Interest names . . . . . . . . . 31 104 14.2. Additional resource pressure on PIT and FIB . . . . . . 32 105 14.3. Potential Vulnerabilities from the use of PIT Tokens . . 32 106 14.4. Privacy Considerations . . . . . . . . . . . . . . . . . 32 107 15. Normative References . . . . . . . . . . . . . . . . . . . . 33 108 16. Informative References . . . . . . . . . . . . . . . . . . . 33 109 Appendix A. Alternative Designs Considered . . . . . . . . . . . 37 110 A.1. Handling reflexive interests using dynamic FIB entries . 37 111 A.1.1. Design complexities and performance issues with 112 FIB-based design . . . . . . . . . . . . . . . . . . 38 113 A.1.2. Interactions between FIB-based design and Interest 114 Lifetime . . . . . . . . . . . . . . . . . . . . . . 39 115 A.2. Reflexive forwarding using Path Steering . . . . . . . . 40 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 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, Interest messages are intended to be small, on 204 the order the size of a TCP ACK, as opposed to the size of a TCP 205 data segment. This is because the hop-by-hop congestion control 206 and forwarder state management requires Interest messages to be 207 buffered in expectation of returning data, and possibly 208 retransmitted hop-by-hop as opposed to end-to-end. In addition, 209 the need to create and manage state on a per-Interest basis is 210 substantially complicated if requests in Interest messages are 211 larger than a Path MTU (PMTU) and need to be fragmented hop-by- 212 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 interacts with this scheme.) The 357 key question therefore is how to access this state in a way that it 358 can be used to forward Interests. 360 In order to achieve this _Reflexive Interest_ forwarding on the 361 inverse path recorded in the PIT of each forwarder, we need a few 362 critical design elements: 364 1. The Reflexive Interest needs to have a Name. This name is what 365 the originating consumer will use to match against the Data 366 object (or multiple Data objects - more on this later) that the 367 producer may request by issuing the Reflexive Interest. This 368 cannot be just any name, but needs to essentially name the state 369 already recorded in the PIT and not allow the consumer to 370 manufacture an arbitrary name and mount a reflection attack as 371 pointed out in Section 1.2, Paragraph 2, Item 2. 373 2. Each forwarder along the inverse path from producer to consumer 374 must be able to forward the reflexive Interest towards the 375 direction of the Consumer, without being able to rely on global 376 routing information, as the Reflexive Name Prefixes are only 377 valid for each Reflexive Forwarding session. Essential to this 378 operation is the ability to access the PIT entry associated with 379 the original Interest message, since that contains the state 380 necessary to identify the ingress face of the original Interest, 381 which is the unique output face over which the Reflexive Interest 382 needs to be forwarded. The Name assigned by the consumer for 383 Reflexive Name Prefix in theory is adequate to the task, but 384 entails an expensive and complicated lookup procedure. In order 385 to make this lookup both simple and efficient, we adopt an 386 extended version of the "PIT-Token" scheme pioneered by the high- 387 speed NIST NDN forwarder [Shi2020]. In this specification, we 388 are using _Forward Direction PIT Tokens_ (FPTs) that nodes attach 389 to forwarded Interests in the upstream direction, and _Reverse 390 Direction PIT Tokens_ (RPTs) that nodes attach to Reflexive 391 Interests (as well as regular Data messages) in the downstream 392 direction. We describe the specific processing requirements in 393 more detail below. 395 3. There has to be coupling of the state between the originating 396 Interest-Data exchange and the enclosed Reflexive Interest-Data 397 exchange at both the consumer and the producer. In our design, 398 this is accomplished by the way reflexive interest names are 399 chosen. 401 The following sections provide the normative details on each of these 402 design elements. The overall interaction flow for reflexive 403 forwarding is illustrated below in Figure 2. 405 +-----------+ +-----------+ +-----------+ 406 | Consumer | | Forwarder | | Producer | 407 +-----------+ +-----------+ +-----------+ 408 | | | 409 | I1 | | 410 |----------------->| | 411 | -------------\ | | 412 | | Record RNP |-| | 413 | | in PIT | | | 414 | |------------| | | 415 | | ----------------\ | 416 | |-| Add FPT to I1 | | 417 | | |---------------| | 418 | | | 419 | | I1 | 420 | |---------------------->| 421 | | | ------------\ 422 | | |-| Check | 423 | | | | prefix, | 424 | | | | creating | 425 | | | | Reflexive | 426 | | | | Interest | 427 | | | | state | 428 | | | |-----------| 429 | | ------------\ | 430 | | | FPT(I1)-> |-| 431 | | | RPT(I2) | | 432 | | |-----------| | 433 | | | 434 | | Reflex. I2 | 435 | |<----------------------| 436 | | --------------\ | 437 | |-| use RPT(I2) | | 438 | | | to find | | 439 | | | PIT of I1, | | 440 | | | check | | 441 | | | matching | | 442 | | | of RNP | | 443 | | | create I2 | | 444 | | | PIT entry, | | 445 | | | forward I2 | | 446 | | |-------------| | 447 | --------------\ | | 448 | | add RPT(I1) |-| | 449 | | and | | | 450 | | FPT(I2) PIT | | | 451 | | to I2 | | | 452 | |-------------| | | 453 | | | 454 | I2 | | 455 |<-----------------| | 456 | | | 457 | D2 obj | | 458 |----------------->| | 459 | --------------\ | | 460 | | consume I2 |-| | 461 | | PIT entry | | | 462 | | and forward | | | 463 | | D2 | | | 464 | |-------------| | | 465 |----------------\ | | 466 || add FPT of I2 |-| | 467 || as RPT of D2 | | | 468 ||---------------| | | 469 | | --------------\ | 470 | |-| satisfy PIT | | 471 | | | of I2 | | 472 | | |-------------| | 473 | | | 474 | | D2 | 475 | |---------------------->| 476 | | | ---------------\ 477 | | |-| all | 478 | | | | parameters | 479 | | | | received, | 480 | | | | answer orig. | 481 | | | | I1 Interest | 482 | | | |--------------| 483 | | | 484 | | D1 obj. | 485 | |<----------------------| 486 | -------------\ | | 487 | | satisfy I1 |-| | 488 | | PIT entry, | | | 489 | | forward D1 | | | 490 | |------------| | | 491 |----------------\ | | 492 || add FPT of I1 |-| | 493 || as RPT of D1 | | | 494 ||---------------| | | 495 | | | 496 | D1 | | 497 |<-----------------| | 498 | | | 499 Legend: 500 I1: Interest #1 containing the Reflexive Name Prefix TLV 501 RI: Reflexive Interest with Reflexive Name Prefix Component 502 RNP: Reflexive Name Prefix 503 FPT: Forward Direction PIT Token 504 RPT: Reverse Direction PIT Token 505 D1: Data message, answering initiating I1 Interest 506 D2: Data message, answering RI 508 Figure 2: Message Flow Overview 510 4. Consumer Operation 512 A consumer that wants to initiate a Reflexive Forwarding session MUST 513 create an Interest (I1) with a Reflexive Name Prefix (RNP) TLV that 514 should be used by the producer when issuing Reflexive Interests (RI) 515 back to the consumer. Upon receiving a Reflexive Interest (e.g. I2 516 in Figure 2) from a Producer in response to the Interest whose first 517 name component is the RNP supplied earlier, the consumer SHOULD 518 perform a name match against the object specified in the Reflexive 519 Name, and return that object to the producer in a conventional Data 520 message, (e.g. D2 in Figure 2). 522 5. Naming of Reflexive Interests 524 A consumer may have one or more objects for the producer to fetch, 525 and therefore needs to communicate enough information in its initial 526 Interest to allow the producer to construct properly formed Reflexive 527 Interest names. For some applications the set of _full names_ (see 528 [I-D.irtf-icnrg-terminology]) is known a priori, for example through 529 compile time bindings of arguments in interface definitions or by the 530 architectural definition of a simple sensor reading. In other cases, 531 the full names of the individual objects must be communicated in the 532 original Interest message. 534 We define a new typed name component, identified by a registered name 535 component type in the IANA registry for [RFC8569]. We call this the 536 _Reflexive Interest Name Component type_. It MUST be the first (i.e. 537 high order) name component of any Reflexive Interest issued by a 538 producer. Its value is a random 128 bit number, assigned by the 539 consumer, which provides the entropy required to uniquely identify 540 the issuing consumer for the duration of any outstanding Interest- 541 Data exchange. We suggest using a UUID as specified in [RFC4122] but 542 any scheme that meets the randomness and entropy requirements can 543 suffice. The consumer SHOULD choose a different random value for 544 each Interest message it constructs because: 546 1. If there is insufficient randomness, a name collision on the 547 Reflexive Names could occur at any of the intermediate forwarders 548 which would result in the same mutability problems generated by 549 poor name selection in other contexts; and 551 2. Re-use of the same reflexive interest name over multiple 552 interactions might reveal linkability information that could be 553 used by surveillance adversaries for tracking purposes. 555 This initial name component is either communicated by itself through 556 a _Reflexive Name Prefix TLV_ in the originating Interest, or 557 prepended to any object names the consumer wishes the producer to 558 fetch explicitly where there is more than one object needed by the 559 producer for the current Interest-Data interaction. There are four 560 cases to consider: 562 1. The reflexive _fullname_ of a single object to fetch. 564 2. A single reflexive name prefix out of which the producer can (by 565 application-specific means) construct a number of _fullnames_ of 566 the objects it may want to fetch. 568 3. The reflexive _fullname_ of a FLIC Manifest [I-D.irtf-icnrg-flic] 569 enumerating the suffixes that may be used by the producer to 570 construct the necessary names. 572 4. Multiple reflexive name TLVs MAY be included in the Interest 573 message if none of the above 3 options covers the desired use 574 case. 576 The last of the four options above, while not explicitly outlawed, 577 SHOULD NOT be used. This is because it results in a longer Interest 578 message and requires extra FIB resources. Hence, it is more likely a 579 forwarder will reject the Interest for lack of resources. A 580 forwarder MAY optimize for the case of a single Reflexive Name TLV at 581 the expense of those with more than one. 583 A producer, upon receiving an Interest with one or more Reflexive 584 Name TLVs, may decide it needs the pull the associated data 585 object(s). It therefore can issue one or more Reflexive Interests by 586 appending the necessary name components needed to form valid full 587 names of the associated objects present at the originating consumer. 588 These in fact comprise conventional Interest-Data exchanges, with no 589 alteration of the usual semantics with regard to signatures, caching, 590 expiration, etc. When the producer has retrieved the required 591 objects to complete the original Interest-Data exchange, it can issue 592 its Data response, which unwinds all the established state at the 593 producer, the consumer, and the intermediate forwarders. 595 6. Producer Operation 597 A producer that has received an Interest with a Reflexive Name Prefix 598 (RNP) MUST store the supplied RNP and the Forward PIT Token (FPT) 599 from the received Interest for subsequent (optional, depending on 600 application semantics) Reflexive Interest sending. 602 When sending a Reflexive Interest back to the consumer, the producer 603 MUST construct a corresponding Interest name based on the RNP and 604 insert the received Forward PIT Token (FPT) as the Reverse PIT Token 605 (RPT) TLV in the reflexive Interest. 607 7. Forwarder Operation 609 The forwarder operation for CCNx and/or NDN is changed in the 610 following respects when supporting Reflexive Interests. The 611 requirements are slightly different for a simple forwarder meeting 612 the mandatory aspects of the specification, versus a forwarder 613 designed for high-performance, as discussed later in Section 10.1.1. 614 The main differences are in how PIT lookups are done, and whether the 615 forwarder only does the steps necessary to process the PIT Tokens 616 supplied by upstream and downstream forwarders, or whether it also 617 generates and processes its own PIT Tokens. 619 1. Upon receiving an Interest containing a Reflexive Name Prefix 620 (RNP) TLV the forwarder MUST record the RNP as an element of the 621 PIT entry for that Interest. (For interactions with Interest 622 aggregation, also see Section 10.1.3). 624 2. When forwarding and Interest with a Reflexive Name Prefix (RNP) 625 TLV, the forwarder MAY generate a Forward PIT Token (FPT) and 626 append it to the forwarded Interest to be processed by the next 627 hop. 629 3. If an Interest contains a Reverse PIT Token (RPT), the forwarder 630 MAY use that value to access the corresponding PIT entry, or do a 631 direct lookup based on the Reflexive Interest Name Prefix. 633 4. The forwarders MUST check that the high-order Name component of 634 the Interest is of type RNP. If not, while this could strictly 635 speaking be considered an error, simply process the Interest as a 636 normal non-reflexive Interest and skip the steps below. A match 637 indicates that this is a Reflexive Interest corresponding to the 638 original consumer to producer Interest, so execute the following 639 steps. 641 5. Create a new PIT entry for the Reflexive Interest (if resources 642 are sufficient). Also, see Section 10.1.1 for how PIT sharding 643 interacts with the location and creation of PIT entries on high- 644 speed forwarders. 646 6. Record the Forward PIT-Token (FPT), if any, in this PIT entry, as 647 would be done for any received Interest containing an FTP TLV. 649 7. Look up the ingress face from the originating Interest's PIT 650 entry and forward the Reflexive Interest on this single face, and 652 * Append the the RPT from the ingress face information of the 653 original Interest's PIT entry, if any 655 * Append a FPT TLV to the Interest if the forwarder requires the 656 downstream forwarder to supply an RPT in any returning Data 657 packet for this Reflexive interest 659 The PIT entry for the Reflexive Interest is consumed per regular 660 Interest/Data message forwarding requirements. The PIT entry for the 661 originating Interest (that communicated the Reflexive Interest Name) 662 is also consumed by a final Data message from the producer to the 663 original consumer. 665 7.1. Forwarder algorithms in pseudocode 667 This section provides some pseudocode examples to further explain the 668 details of forwarder operation. It has separate code paths for 669 minimal forwarder operations and those needed by high-performance 670 forwarders as is further discussed in Section 10.1.1. 672 7.1.1. Processing of a normal Interest containing a Reflexive Name 673 Prefix TLV 675 Create PIT entry for Interest; 676 IF interest contains FPT, record FPT along with ingress face to use as RPT later; 677 Record RNP in PIT entry; 678 EITHER 679 Create entry in an RNP look-aside table with RNP value; 680 OR 681 Generate a FPT for this PIT entry and add to Interest; 682 Forward Interest upstream; 684 7.1.2. Processing of a Reflexive Interest 686 IF Interest contains an RPT 687 use RPT to lookup up PIT entry for original interest; 688 ELSE 689 Use RNP of Interest's Name TLV to lookup original Interest PIT entry; 690 Create PIT entry for Reflexive Interest; 691 IF RNP of Reflexive Interest matches RNP in PIT entry 692 BEGIN 693 Extract FPT from Original Interest PIT entry (if any); 694 Add FPT to Reflexive interest as RPT for downstream forwarder; 695 Optionally, generate and add FPT for the Reflexive Interest for returning Data 696 END; 697 ELSE 698 Process as a normal Interest; 700 8. State coupling between producer and consumer 702 A consumer that wishes to use this scheme MUST utilize one of the 703 reflexive naming options defined in Section 5 and include it in the 704 corresponding Interest message. The Reflexive Name TLV _and_ the 705 full name of the requested data object (that identifies the producer) 706 identify the common state shared by the consumer and the producer. 707 When the producer responds by sending Interests with the Reflexive 708 Name Prefix, the original consumer therefore has sufficient 709 information to map these Interests to the ongoing Interest-Data 710 exchange. 712 The exchange is finished when the producer who received the original 713 Interest message responds with a Data message (or an Interest Return 714 message in the case of error) answering the original Interest. After 715 sending this Data message, the producer SHOULD destroy the 716 corresponding shared state. It MAY decide to use a timer that will 717 trigger a later state destruction. After receiving this Data 718 message, the originating consumer MUST destroy the corresponding 719 Interest-Data exchange state. 721 9. Use cases for Reflexive Interests 723 9.1. Achieving Remote Method Invocation with Reflexive Interests 725 RICE (Remote Method Invocation in ICN) [Krol2018] used a similar 726 Reflexive Interest Forwarding scheme that inspired the design 727 specified in this document (similar to, the original design captured 728 in Appendix A.1). 730 In RICE, the original Interest denotes the remote method (plus 731 potential parameters) to be invoked at a producer (server). Before 732 committing any computing resources, the server can then request 733 authentication credentials and (optional) parameters using reflexive 734 Interest-Data exchanges. 736 When the server has obtained the necessary credentials and input 737 parameters, it can decide to commit computing resources, starts the 738 compute process, and returns a handle ("Thunk") in the final Data 739 message to the original consumer (client). 741 The client would later request the computation results using a 742 regular Interest-Data exchange (outside the Reflexive-Interest 743 transaction) - using the Thunk as a name for the computation result. 745 Figure 3 depicts an abstract message diagram for RICE. In addition 746 to the 4-way Reflexive Forwarding Handshake (see Figure 2 for the 747 details of the interaction), RICE adds another (standard) ICN 748 Interest/Data exchange for transmitting the RMI result. The Thunk 749 name is provided to the consumer in the D1 DATA message (answering 750 the initial I1 Interest). 752 +-----------+ +-----------+ 753 | Consumer | | Producer | 754 +-----------+ +-----------+ 755 | | 756 | I1 | 757 |------------------------->| 758 | | ---------------------\ 759 | |-| Requesting request | 760 | | | parameters | 761 | | | and credentials | 762 | | |--------------------| 763 | | 764 | RI | 765 |<-------------------------| 766 | | 767 | D2 | 768 |------------------------->| 769 | | --------------------\ 770 | |-| Commit compute | 771 | | | resources, | 772 | | | return Thunk name | 773 | | |-------------------| 774 | | 775 | D1 | 776 |<-------------------------| 777 | | ----------------\ 778 | |-| Invoke Remote | 779 | | | Method | 780 | | |---------------| 781 | -------------------\ | 782 |-| After some time, | | 783 | | request result | | 784 | |------------------| | 785 | | 786 | I3 | 787 |------------------------->| 788 | | 789 | D3 | 790 |<-------------------------| 791 | | 793 Legend: 794 I1: Interest #1 containing the Reflexive Name Prefix TLV 795 D1: Data message, answering initiating I1 Interest, 796 returning Thunk name 797 D2: Data message, answering RI (parameters, credentials) 798 I3: Regular Interest for Thunk (compute result) 799 D3: Data message, answering I3 801 Figure 3: RICE Message Flow 803 9.2. RESTful Web Interactions 805 In todays HTTP-based web, RESTful (Representational State Transfer) 806 web interactions are realized by sending requests in a client/server 807 interaction, where the requests provides the application context (or 808 a reference to it). It has been noted in [Moiseenko2014] that 809 corresponding requests often exceed the response messages in size, 810 and that this raises the problems noted in Section 1.1 when 811 attempting to map such exchanges directly to CCNx/NDN. 813 Another reason not to include all request parameters in a (possibly 814 encrypted) Interest message is the fact that a server (that is 815 serving thousands of clients) would be obliged to receive, possibly 816 decrypt and parse the complete requests before being able to 817 determine whether the requestor is authorized, whether the request 818 can be served etc. Many non-trivial requests could thus lead to 819 computational overload attacks. 821 Using Reflexive Interest Forwarding for RESTful Web Interactions 822 would encode the REST request in the Original request, together with 823 a Reflexive Interest Prefix that the server could then use to get 824 back to the client for authentication credentials and request 825 parameters, such as cookies. The request result (response message) 826 could either be transmitted in the Data message answering the 827 original request, or - in case of dynamic, longer-running 828 computations - in a seperate Interest/Data exchange, potentially 829 leveraging the Thunk scheme described in section Section 9.1. 831 Unlike approaches where clients have to signal a globally routable 832 prefix to the network, this approach would not require the client 833 (original consumer) to expose its identity to the network (the 834 network only sees the temporary Reflexive Name Prefix), but it would 835 still be possible to authenticate the client at the server. 837 9.3. Achieving simple data pull from consumers with reflexive Interests 839 An oft-cited use case for ICN network architectures is _Internet of 840 Things_ (IoT), where the sources of data are limited-resource sensor/ 841 actuators. Many approaches have been tried (e.g. [Baccelli2014], 842 [Lindgren2016], [Gundogan2018]) with varying degrees of success in 843 addressing the issues outlined in Section 1.1. The reflexive 844 forwarding extension may substantially ameliorate the documented 845 difficulties by allowing a different model for the basic interaction 846 of sensors with the ICN network. 848 Instead of acting as a producer (either directly to the Internet or 849 indirectly through the use of some form of application-layer 850 gateway), the IoT device need only act as a consumer. When it has 851 data to provide, it issues a "phone-home" Interest message to a pre- 852 configured rendezvous name (e.g. an application-layer gateway or ICN 853 Repo [Chen2015]) and provides a reflexive name prefix TLV for the 854 data it wishes to publish. The target producer may then issue the 855 necessary reflexive Interest message(s) to fetch the data. Once 856 fetched, validated, and stored, the producer then responds to the 857 original Interest message with a success indication, possibly 858 containing a Data object if needed to allow the originating device to 859 modify its internal state. Alternatively, the producer might choose 860 to not respond and allow the original Interest to time out, although 861 this is NOT RECOMMENDED except in cases where the extra message 862 transmission bandwith is at a premium compared to the persistence of 863 stale state in the forwarders. We note that this interaction 864 approach mirrors the earlier efforts using Interest-Interest-Data 865 designs. 867 Figure 4 depicts this interaction with the (optional) D1 message. 868 See Figure 2 for the details of the general Reflexive Forwarding 869 interaction. 871 +-----------+ +-----------+ 872 | Consumer | | Producer | 873 +-----------+ +-----------+ 874 ------------\ | | 875 | new IoT |-| | 876 | data item | | | 877 | produced | | | 878 |-----------| | | 879 ---------------\ | | 880 | "phone home" |-| | 881 | by notifying | | | 882 | producer | | | 883 |--------------| | | 884 | | 885 | I1 | 886 |------------>| 887 | | --------------------\ 888 | |-| generate Interest | 889 | | | for IoT data | 890 | | |-------------------| 891 | | 892 | RI | 893 |<------------| 894 -----------------\ | | 895 | send requested |-| | 896 | data object | | | 897 |----------------| | | 898 | | 899 | D2 | 900 |------------>| 901 | | -----------------------\ 902 | |-| finalize interaction | 903 | | | with optional | 904 | | | Data message | 905 | | |----------------------| 906 | | 907 | D1 | 908 |<------------| 909 | | 910 Legend: 911 I1: Interest #1 containing the Reflexive Name Prefix TLV 912 D1: Data message (OPTIONAL), finalizing interaction 913 D1: Data message, answering RI, returning IoT data object 915 Figure 4: "Phone Home" Message Flow 917 There are two approaches that the IoT device can use for its response 918 to a reflexive Interest. It can simply construct a Data Message 919 bound through the usual ICN hash name to the reflexive Interest name. 920 Since the scope of any data object bound in this way is only the 921 duration of the enclosing Interest-Data exchange (see Section 10.2) 922 the producer would need to itself construct any persistent Data 923 object, name it, and sign it. This is sometimes the right approach, 924 as for some applications the identity of the originating IoT device 925 is not important from an operational or security point of view; in 926 contrast the identity of the gateway or Repo is what matters. 928 If alternatively, the persistent Data object should be bound from a 929 naming and security point of view to the originating IoT device, this 930 can be easily accomplished. Instead of directly placing the content 931 in a Data object responding to the reflexive Interest as above, the 932 consumer encapsulates a complete CCNx/NDN Data message (which 933 includes the desired name of the data) as in the response to the 934 reflexive Interest message. 936 The interaction model described above brings a number potential 937 advantages, some obvious, some less so. We enumerate a few of them 938 as follows: 940 * By not requiring the IoT device to be actively listening for 941 Interests, it can sleep and only wake up if it has something to 942 communicate. Conversely, parties interested in obtaining data 943 from the device do not need to be constantly polling in order to 944 ascertain if there is new data available. 946 * No forwarder resources are tied up with state apart from the 947 actual reflexive forwarding interactions. All that is needed is 948 enough routing state in the FIB to be able to forward the "phone 949 home" Interest to an appropriate target producer. While this 950 model does not provide all the richness of a full Pub/Sub system 951 (like that described in [Gundogan2018]) we argue it is adequate 952 for a large subclass of such applications. 954 * The reflexive interest, through either a name suffix or Interest 955 payload, can give the IoT device useful context from which to 956 craft its Data object in response. One highly useful parameter 957 would be a robust clock value for the device to use as a timestamp 958 of the data, possibly as part of its name to correctly place it in 959 a time seres of sensor readings. This substantially alleviates 960 the need for low-end devices to have a robust time base, as long 961 as they trust the producer they contact to provide it. 963 10. Implementation Considerations 965 There are a number of important aspects to the reflexive forwarding 966 design which affect correctness and performance of existing 967 forwarder, consumer, and producer implementations desiring to support 968 it. This section discusses the effect on each of these elements of 969 the CCNx/NDN protocol architecture. 971 10.1. Forwarder implementation considerations 973 10.1.1. Interactions with Input Processing of Interest and Data packets 975 Reflexive Interests are designed specifically to be no different from 976 any other Interest other than the use of the Reflexive Interest 977 Prefix name component type as their high-order name component. This 978 means that a forwarder does not have to have special handling in 979 terms of creation, and destruction, and other Interest processing 980 needs such as timeouts, Interest satisfaction, and caching of 981 returning data in the CS if desired. However, this design does 982 require additional processing for Reflexive Interests not needed in 983 the absence of reflexive forwarding. The most significant 984 requirements are: 986 * In order to locate the corresponding PIT entry for the original 987 Interest, the forwarder's packet input processing needs to be able 988 to efficiently locate the PIT entry of the origianl Interest that 989 contained the RNP TLV. 991 * Ensure that the high order name component of the Reflexive 992 Interest matches the RNP stored in that PIT entry. 994 There are a few additional considerations to highlight for high-speed 995 forwarders however; these are discussed in the following paragraphs. 997 In order to achieve forwarding scalability, high speed forwarders 998 need to exploit available parallelism in both CPU (through multiple 999 cores) and memory (through multiport DRAM and limiting accesses to 1000 both DRAM and L3 caches). One commonly-used technique is _PIT 1001 sharding_, where the forwarder-global PIT is partitoned among cores 1002 such that all processing of both Interest and Data for a given Name 1003 is directed at the same core, optimizing both L1 I-cache utilization 1004 and L2/L3/DRAM throughput and latency. This is achieved in a number 1005 of implementations (e.g. [So2013]) by hashing the fullname in the 1006 Interest or Data and using that hash to select the assigned 1007 processing core (and associated memory banks). This efficiently 1008 distributes the load and minimizes the number of memory accesses 1009 other than to bytes of the input packet. 1011 Straightforward input name hashing to achieve a sharded PIT has one 1012 potentially undesirable side effect: the original Interest containing 1013 the Reflexive Name Prefix TLV and any resultant reflexive Interests 1014 issued by the producer will likely hash to different PIT shards, 1015 making any pointers that need to be traversed across shards or cross- 1016 shard updates expensive, possibly dramatically so. One could either 1017 optimize those accesses (as, for example, suggested in the discussion 1018 of Interest Lifetime in Section 10.1.2) or add special input handling 1019 of reflexive interests to steer them to the same shard as the 1020 original interest. This latter technique is what we have specified 1021 by making the use of PIT Tokens similar to those in [Shi2020] an 1022 important element of the design. 1024 10.1.2. Interactions with Interest Lifetime 1026 If and when a producer decides to fetch data from the consumer using 1027 one or more reflexive Interest-Data exchanges, the total latency for 1028 the original Interest-Data exchange is inflated, potentially by 1029 multiple RTTs. It is difficult for a consumer to predict the 1030 inflation factor when issuing the original Interest, and hence there 1031 can be a substantial hazard of that Interest lifetime expiring before 1032 completion of the full multi-way exchange. This can result in 1033 persistent failures, which is obviously highly undesirable. 1035 There is a fairly straightforward technique that can be employed by 1036 forwarders to avoid these "false" Interest lifetime expirations. In 1037 the absence of a superior alternative technique, it is RECOMMENDED 1038 that all forwarders implement the following algorithm. 1040 If and when a reflexive Interest arrives matching the original 1041 Interest's PIT entry, the forwarder examines the Interest lifetime of 1042 the arriving reflexive Interest. Call this value _IL_r_. The 1043 forwarder computes MAX(_IL_t, (IL_r * 1.5)_), and replaces _IL_t_ 1044 with this value. This in effect ensures that the remaining Interest 1045 lifetime of the original Interest accounts for the additional 1.5 1046 RTTs that may occur as a result of the reflexive Interest-Data 1047 exchange. 1049 | We note that this is not unduly expensive in this design where 1050 | the two PIT entries are guaranteed to be in the same PIT shard 1051 | on a high speed forwarder. The earlier design discussed in 1052 | Appendix A.1.2 required some additional gymnastics. 1054 While the above approach of inflating the interest lifetime of the 1055 original Interest to accommodate the additional RTTs of reflexive 1056 Interest-Data exchanges avoids the timeout problem, this does 1057 introduce a new vulnerability that must be dealt with. A Producer, 1058 either through a bug or malicious intent, could keep an originating 1059 Interest-Data exchange alive by continuing to send reflexive 1060 Interests back to the consumer, while the consumer had no way to 1061 terminate the enclosing interaction (there is no "cancel Interest" 1062 function in either NDN nor CCNx). To eliminate this hazard, if the 1063 consumer rejects a reflexive interest with a T_RETURN_PROHIBITED 1064 error, the forwarder(s), in addition to satisfying the coresponding 1065 PIT entry, MUST also delete the RNP from the original Interest's PIT 1066 entry, thereby preventing any further reflexive Interests from 1067 reaching the consumer. This allows the enclosing Interest-Data 1068 exchange to either time out or be correctly ended with a Data message 1069 or Interest Return from the Producer. 1071 10.1.3. Interactions with Interest aggregation and multi-path/multi- 1072 destination forwarding 1074 As with numerous other situations where multiple Interests for the 1075 same named object arrive containing different parameters (e.g. 1076 Interest Lifetime, QoS, payload hash) the same phenomenon occurs for 1077 the reflexive Name TLV. If Interests with different reflexive name 1078 prefix TLVs collide, the forwarder MUST NOT aggregate these Interest 1079 messages and instead MUST create a separate PIT entry for each. This 1080 in turn means that a different Forward PIT-Token (FPT) will be placed 1081 in the individual forwarded Interests. 1083 Forwarders supporting multi-path forwarding may of course exploit 1084 this capability for Interests with identical reflexive name prefix 1085 TLVs, like any other Interests. There are two sub-cases of multi- 1086 next hop behavior; regular multi-path (where the split traffic 1087 reconverges further upstream) and multi-destination (where it doesn't 1088 and the Interest reaches multiple producers). 1090 For multi-path, since the Interests that converge upstream carry 1091 identical reflexive Interest name TLVs, they will get aggregated. 1092 The forwarder might, just as for any other Interest, decide to either 1093 do single or multi-path forwarding of that reflexive Interest. If 1094 sent multi-path in parallel, these also will reconverge on the 1095 inverse path and get aggregated. The inclusion of the Forward PIT- 1096 Token (FPT) in the forwarded Interest is unaffected by multi-path 1097 since it is only used on returning Data messages or Reflexive 1098 Interests to access the correct PIT entry. 1100 For multi-destination, reflexive Interests might get issued by 1101 multiple producers, but they will carry the same reflexive name 1102 prefix and hence be forwarded using the ingress face of the same 1103 original Interest PIT entrie until reaching the join point, at which 1104 they will get aggregated and thus handled identically to any other 1105 Interest(s) subject to aggregation. 1107 10.2. Consumer Implementation Considerations 1109 10.2.1. Data objects returned by the consumer to reflexive name 1110 Interests arriving from a producer 1112 The Data objects returned to the producer in response to a reflexive 1113 Interest are normal CCNx/NDN data objects. It is therefore worth 1114 noting that the object is bound to the reflexive Interest full name 1115 via the hash and hence the scope of the object is under most 1116 circumstances meaningful only for the duration of the enclosing 1117 Interest-Data interaction. This property is ideal for naming and 1118 securing data that is "part of" the enclosing interaction - things 1119 like method arguments, authenticators, and key exchange parameters, 1120 but not for the creation and naming of objects intended to survive 1121 outside the current interaction's scope (c.f. Section 9.3, which 1122 describes how to provide globally-named objects using encapsulation). 1123 In general, the consumer should use the following guidelines in 1124 creating Data messages in response to reflexive Interest messages 1125 from the producer. 1127 (a) Set the recommended cache time (T_CACHETIME) either to zero, or 1128 a value no greater than the Interest lifetime (T_INTLIFE) of the 1129 original Interest messsage. 1131 (b) Set the payload type (T_PAYLDTYPE) according to the type of 1132 object being returned (e.g. object, link, manifest) 1134 (c) Set the expiry time (T_EXPIRY) to a value greater than _now_, 1135 and less than or equal to the _now_ + Interest lifetime 1136 (T_INTLIFE) of the original Interest messsage. 1138 10.2.2. Terminating unwanted reflexive Interest exchanges 1140 A consumer may wish to stop receiving reflxive Interests due to 1141 possible erors or malicious behavior on the part of the producer. 1142 Therefore, if the consumer receives an unwanted reflexive Interest, 1143 it SHOULD reject that interest with a T_RETURN_PROHIBITED error. 1144 This will provoke the forwarders to prevent further reflexive 1145 Interests from reaching the consumer, as described above in 1146 Section 10.1.2, Paragraph 5. 1148 10.2.3. Interactions with caching 1150 The reflexive named objects provide "local", temporary names that are 1151 only defined for one specific interaction between a consumer and a 1152 producer. Corresponding Data objects MUST NOT be shared between 1153 multiple consumers (violating this would require special gyrations by 1154 the producer since the reflexive Name utilizes per-consumer/per- 1155 interaction random values). A producer MUST NOT issue an Interest 1156 message for any reflexive name after it has sent the final Data 1157 message answering the original Interest. 1159 Forwarders SHOULD still cache reflexive Data objects for 1160 retransmissions within a transactions, but they MUST invalidate or 1161 remove them from the content store when they forward the final Data 1162 message answering the original Interest. 1164 10.3. Producer Implementation Considerations 1166 Producers receiving an Interest with a Reflexive Name Component, MAY 1167 decide to issue Interests for the corresponding Data objects. All 1168 Reflexive Interest message that a producer sends MUST be sent over 1169 the face that the original Interest was received on. 1171 11. Operational Considerations 1173 This extension represents a substantial enhancement to the CCNx/NDN 1174 protocol architecture and hence has important forward and backward 1175 compatibility effects. The most important of these is that correct 1176 operation of the scheme requires an unbroken chain of forwarders 1177 between the consumer and the desired producer that support the 1178 Reflexive Name TLV, the Forward and Backward PIT-Token TLVs and the 1179 corresponding forwarder capabilities specified in Section 7. When 1180 this invariant is not satisfied, some means is necessary to detect 1181 and hopefully recover from the error. We have identified three 1182 possible approaches to handling the lack of universal deployment of 1183 forwarders supporting the reflexive forwarding scheme. 1185 The first approach simply lets the producer detect the error by 1186 getting a "no route to destination" error when trying to send an 1187 Interest to a reflexive name. This will catch the error, but only 1188 after forwarding resources are tied up and the producer has done some 1189 work on the original Interest message. Further, the producer would 1190 need a bit of smarts to determine that this is a permanent error and 1191 not a transient to be retried. In order for the consumer to attempt 1192 recovery, there might be a need for some explicit error returned for 1193 the original interest to tell the consumer what the likely problem 1194 is. This approach does not enable an obvious recovery path for the 1195 consumer either, since if the producer cannot easily detect the 1196 error, the consumer has no way to know if a retry has any chance of 1197 succeeding. 1199 A second approach is to bump the CCNx/NDN protocol version to 1200 explicitly indicate the lack of compatability. Such Interests would 1201 be rejected by forwarders not supporting these protocol extensions. 1202 A consumer wishing to use the reflexive name TLV together with 1203 Reverse PIT-Tokens, would use the higher protocol version on those 1204 Interest messages (but could of course continue to use the current 1205 version number on other Interest messages). This is a big hammer, 1206 but may be called for in this situation because: 1208 (a) it detects the problem immediately and deterministically, and 1210 (b) one could assume an ICN routing protocol that would only forward 1211 to a next hop that supports the updated protocol version number. 1212 The supported forwarder protocol versions would have been 1213 communicated in the routing protocol ahead of time. 1215 A third option is to, as a precondition to utilizing the protocol in 1216 a deployment, create and deploy a neighbor capability exchange 1217 protocol which will tell a downstream forwarder if the upstream can 1218 handle the new TLV. This might avoid the large hammer of updating 1219 the protocol version, but of course this puts a pretty strong 1220 dependency on somebody actually designing and publishing such a 1221 protocol! On the other hand, a neighbor capability exchange protocol 1222 for CCNx/NDN would have a number of other substantial benefits, which 1223 makes it worth seriously considering anyway. 1225 12. Mapping to CCNx and NDN packet encodings 1226 12.1. Packet encoding for CCNx 1228 For CCNx[RFC8569] this specification defines one new Name Component 1229 TLV type, and two hop-by-hop option TLVs. 1231 +==================+================+==========================+ 1232 | Abbrev | Name | Description | 1233 +==================+================+==========================+ 1234 | T_REFLEXIVE_NAME | Reflexive Name | Name component to use as | 1235 | | Component | name prefix in Reflexive | 1236 | | | Interest Messages | 1237 +------------------+----------------+--------------------------+ 1239 Table 1: Reflexive Name TLV 1241 +========+=========+==============================================+ 1242 | Abbrev | Name | Description | 1243 +========+=========+==============================================+ 1244 | T_FPT | Forward | 1-32 byte value chosen by the forwarder for | 1245 | | PIT | a PIT entry communicated upstream toward a | 1246 | | TOKEN | producer | 1247 +--------+---------+----------------------------------------------+ 1248 | T_RPT | Reverse | 1-32 byte value placed in either a Data | 1249 | | PIT | packet or a Reflexive Interest packet by a | 1250 | | TOKEN | producer or forwarder to allow the upsteam | 1251 | | | forwarder to access the PIT entry identified | 1252 | | | by a received forward PIT Token (FPT) | 1253 +--------+---------+----------------------------------------------+ 1255 Table 2: Hop-by-hop PIT Token TLVs 1257 12.2. Packet encoding for NDN 1259 *These are proposed assignments based on [NDNTLV]. Suggestions from 1260 the NDN team would be greatly appreciated.* 1262 12.2.1. Reflexive Name Component Type 1264 The NDN Name component TLVs needs to have a new component type added 1265 with type RNP (for reflexive name prefix). We suggest something 1266 like: *TBD* 1268 | *Note:*It seems like the current 0.2.1 packet format only has 1269 | allocated two name component types - a _GenericNameComponent_ 1270 | and a _ImplicitSha256DigestComponent_. Shouldn't there be more 1271 | types by now or is this spec out of date? 1273 12.2.2. Reflexive Name Prefix TLV 1275 The Reflexive Name Prefix TLV needs to be added to the NDN Interest 1276 packet format. We suggest using [RFC4122], hence something like: 1278 +---------+----------+------------------------+ 1279 | RNP ::= | RNP-TYPE | TLV-LENGTH(=16) BYTE8) | 1280 +---------+----------+------------------------+ 1282 Table 3: Proposed Reflexive Name Prefix TLV 1283 for NDN Interest Packet 1285 12.2.3. PIT Tokens for NDNLPv2 1287 The current NDN Link Protocol current has an assignment for the PIT 1288 Token mechanism pioneered in [Shi2020]. That approach only needed a 1289 single field, since PIT Tokens are only used to express one 1290 "direction" - for consumer-to-producer Interests and producer-to- 1291 consumer Data messages. This specification employs PIT Tokens on 1292 both enclosing Interest-Data exchanges, but also on Reflexive 1293 Interests to locate the PIT entry of an enclosing Interest on 1294 reception by a forwarder. Therefore we suggest that the existing 1295 NDNLPv2 assignment of 1297 +---------------+--------------------------------------+ 1298 | LpHeaderField | PitToken | 1299 +---------------+--------------------------------------+ 1300 | PitToken | PIT-TOKEN-TYPE TLV-LENGTH 1*32OCTET> | 1301 +---------------+--------------------------------------+ 1303 Table 4: Current NDNLPv2 PIT Token assignment 1305 be renamed to indicate its use in the forward direction of consumer 1306 to producer Interests and returning Data, and a second allocation be 1307 done for a _Reverse PIT Token_ specifically for inclusion in 1308 Reflexive Interests as follows: 1310 +-----------------+--------------------------------------+ 1311 | LpHeaderField | ReversePitToken | 1312 +-----------------+--------------------------------------+ 1313 | ReversePitToken | PIT-TOKEN-TYPE TLV-LENGTH 1*32OCTET> | 1314 +-----------------+--------------------------------------+ 1316 Table 5: Proposed NDNLPv2 Reverse PIT Token assignment 1318 13. IANA Considerations 1320 13.1. Reflexive Name Prefix TLV 1322 Please add the T_REFLEXIVE_NAME component TLV to the CCNx Name types 1323 TLV types registry of [RFC8609], with Length 9 bytes and type of 128 1324 bit random value. 1326 1 2 3 1327 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 1328 +---------------+---------------+---------------+---------------+ 1329 | T_REFLEXIVE_NAME | 16 | 1330 +---------------+---------------+---------------+---------------+ 1331 | | 1332 | 128 bit value randomly assigned by consumer | 1333 +-------------------------------+-------------------------------+ 1335 Figure 5: Reflexive Name component type 1337 13.2. Forward and Reverse PIT-Token hop-by-hop option TLVs 1339 Please add the T_FPT and T_RPT TLVS to the CCNx Hop-by-Hop Type 1340 Registry of [RFC8609], with Length 1-32 bytes and type of random 1341 value. 1343 1 2 3 1344 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 1345 +---------------+---------------+---------------+---------------+ 1346 | T_FPT | 1-32 | 1347 +---------------+---------------+---------------+---------------+ 1348 | | 1349 | 1-32 byte value randomly assigned by forwarder | 1350 +-------------------------------+-------------------------------+ 1352 Figure 6: Forward PIT-Token hop-by-hop TLV 1354 1 2 3 1355 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 1356 +---------------+---------------+---------------+---------------+ 1357 | T_RPT | 1-32 | 1358 +---------------+---------------+---------------+---------------+ 1359 | | 1360 | 1-32 byte value randomly assigned by forwarder | 1361 +-------------------------------+-------------------------------+ 1363 Figure 7: Reverse PIT-Token hop-by-hop TLV 1365 14. Security Considerations 1367 One of the major motivations for the reflexive forwarding extension 1368 specified in this document is in fact to enable better security and 1369 privacy characteristics for ICN networks. The main considerations 1370 are presented in Section 1, but we briefly recapitulate them here: 1372 * Current approaches to authentication and data transfer often use 1373 payloads in Interest messages, which are clumsy to secure 1374 (Interest messages must be signed) and as a consequence make it 1375 very difficult to ensure consumer privacy. Reflexive forwarding 1376 moves all sensitive data to the Data messages sent in response to 1377 reflexive Interests, which are secured in the same manner as all 1378 other Data messages in the CCNx and NDN protocol designs. 1380 * In many scenarios, consumers are forced to also act as producers 1381 so that data may be fetched by either a particular, or arbitrary 1382 other party. The means the consumer must arrange to have a 1383 routable name prefix and that prefix be disseminated by the 1384 routing protocol or other means. This represents both a privacy 1385 hazard (by revealing possible important information about the 1386 consumer) and a security concern as it opens up the consumer to 1387 the full panoply of flooding and crafted Interest Denial of 1388 Service attacks. 1390 * In order to achieve multi-way handshakes, in current designs a 1391 consumer wishing a producer to communicate back must inform the 1392 producer of what (globally routable) name to use. This gives the 1393 consumer a convenient means to mount a variety of reflection 1394 attacks by enlisting the producer to send Interests to desired 1395 victims. 1397 As a major protocol extension however, this design brings its own 1398 potential security issues, which are discussed in the following 1399 subsections. 1401 14.1. Collisions of reflexive Interest names 1403 Reflexive Interest names are constructed using 128-bit random 1404 numbers. This is intended to ensure an off-path attacker cannot 1405 easily manufacture a matching reflexive Interest and either 1406 masquerade as the producer, or mount a denial of service attack on 1407 the consumer. It also limits tracking through the linkability of 1408 Interests containing a re-used random value. 1410 Therefore consumers MUST utilize a robust means of generating these 1411 random values, and it is RECOMMENDED that the [RFC4122] format be 1412 used, with a a pseudo-random number generator (PRNG) approved for use 1413 with cryptographic protocols. 1415 14.2. Additional resource pressure on PIT and FIB 1417 Normal Interest message processing in CCNx and NDN needs to consider 1418 effect of various resource depletion attacks on the PIT, particularly 1419 in the form of Interest flooding attacks (see [Gasti2012] for a good 1420 overview of DoS and DDoS mitigation on ICN networks). Interest 1421 messages utilizing this reflexive forwarding extension can place 1422 additional resource pressure on the PIT. 1424 While this does not represent a new DoS/DDoS attack vector, the 1425 ability of a malicious consumer to utilize this extension in an 1426 attack does represent an increased risk of resource depletion, 1427 especially if such Interests are given unfair access to PIT and FIB 1428 resources. Implementers SHOULD therefore protect PIT and FIB 1429 resources by weighing requests for reflexive forwarding resources 1430 appropriately relative to other Interests. 1432 14.3. Potential Vulnerabilities from the use of PIT Tokens 1434 By including PIT Tokens in the CCNx or NDN protocol, an attacker has 1435 the opportunity to manipulate these values by either replacement or 1436 elision. So far we do not have enough experimental data nor formal 1437 security analysis to assess whether useful attacks against the 1438 protocol via the PIT Tokens can be mounted. The fields are carried 1439 differently in CCNx and NDN, but in both cases they are outside the 1440 cryptographic integrity envelope and not encrypted for 1441 confidentiality as part of the base protocols. 1443 For both cases however, the potential vulnerabilities can be foiled, 1444 at least for point-to-point communication over an L2 hop, by 1445 employing either link-layer encryption (in the case of CCNx), or by 1446 encrypting the NDNLPv2 protocol, which carries these fields for NDN. 1448 14.4. Privacy Considerations 1450 ICN architectures like CCNx and NDN provide a rich tapestry of 1451 interesting privacy issues, which have been extensively explored in 1452 the research literature. The fundamental tradeoffs for privacy 1453 concern the risk of exposing the names of information objects to the 1454 forwarding elements of the network, which is a necessary property of 1455 any name-based routing and forwarding design. Numerous approaches 1456 have been explored with varying degrees of success, such as onion 1457 routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), and name 1458 obfuscation ([Arianfar2011]) among others. 1460 Reflexive forwarding does not change the overall landscape of privacy 1461 tradeoffs, nor seem to introduce additional hazards. In fact, the 1462 privacy exposures are confined to the inverse path of forwarders from 1463 the producer to the consumer, through which the original Interest 1464 forwarding may have already exposed names on path. Similar name 1465 privacy techniques to those cited above may be equally applied to the 1466 names in reflexive Interests. 1468 While the individual reflexive Interest-Data exchanges have similar 1469 properties to those in any NDN or CCNx exchange, the target usages by 1470 applications may have interaction patterns that are subject to 1471 relatively straightforward fingerprinting by adversaries. For 1472 example, a particular RMI invocation may fingerprint simply through 1473 the count of arguments fetched by the producer and their sizes. The 1474 attacker must however be on path, which somewhat ameliorates the 1475 exposure hazards. 1477 15. Normative References 1479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1480 Requirement Levels", BCP 14, RFC 2119, 1481 DOI 10.17487/RFC2119, March 1997, 1482 . 1484 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1485 Networking (CCNx) Semantics", RFC 8569, 1486 DOI 10.17487/RFC8569, July 2019, 1487 . 1489 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1490 Networking (CCNx) Messages in TLV Format", RFC 8609, 1491 DOI 10.17487/RFC8609, July 2019, 1492 . 1494 16. Informative References 1496 [Arianfar2011] 1497 Arianfar, S., Koponen, T., Raghavan, B., and S. Shenker, 1498 "On preserving privacy in content-oriented networks, in 1499 ICN '11: Proceedings of the ACM SIGCOMM workshop on 1500 Information-centric networking", 1501 DOI https://doi.org/10.1145/2018584.2018589, August 2011, 1502 . 1504 [Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., 1505 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less 1506 Producer Mobility in Content-Centric Networks, in IEEE 1507 Transactions on Network, Volume 15, Issue 2", 1508 DOI 10.1109/TNSM.2018.2796720, June 2018, 1509 . 1511 [Baccelli2014] 1512 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 1513 Wählisch, "Information centric networking in the IoT: 1514 experiments with NDN in the wild, in ACM-ICN '14: 1515 Proceedings of the 1st ACM Conference on Information- 1516 Centric Networking", DOI 10.1145/2660129.2660144, 1517 September 2014, 1518 . 1520 [Carzaniga2011] 1521 Carzaniga, A., Papalini, M., and A.L. Wolf, "Content-Based 1522 Publish/Subscribe Networking and Information-Centric 1523 Networking", DOI 10.1145/2018584.2018599, September 2011, 1524 . 1527 [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDSS: A Named Data Storage 1528 System, in International Conference on Cloud and Autonomic 1529 Computing", DOI 10.1109/ICCAC.2015.12, September 2014, 1530 . 1532 [DiBenedettoGTU12] 1533 DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzun, 1534 "ANDaNA: Anonymous Named Data Networking Application, in 1535 NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2, 2102, 1536 . 1539 [Gasti2012] 1540 Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang, "DoS 1541 and DDoS in Named Data Networking, in 22nd International 1542 Conference on Computer Communication and Networks 1543 (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August 2013, 1544 . 1546 [Ghali2017] 1547 Tsudik, G., Ghali, C., and C. Wood, "When encryption is 1548 not enough: privacy attacks in content-centric networking, 1549 in ICN '17: Proceedings of the 4th ACM Conference on 1550 Information-Centric Networking", 1551 DOI https://doi.org/10.1145/3125719.3125723, September 1552 2017, 1553 . 1555 [Gundogan2018] 1556 Gündoğan, C., Kietzmann, P., Schmidt, T., and M. Wählisch, 1557 "HoPP: publish-subscribe for the constrained IoT, in ICN 1558 '18: Proceedings of the 5th ACM Conference on Information- 1559 Centric Networking", DOI 10.1145/3267955.3269020, 1560 September 2018, 1561 . 1563 [I-D.irtf-icnrg-flic] 1564 Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, "File- 1565 Like ICN Collections (FLIC)", Work in Progress, Internet- 1566 Draft, draft-irtf-icnrg-flic-03, 7 November 2021, 1567 . 1570 [I-D.irtf-icnrg-terminology] 1571 Wissingh, B., Wood, C. A., Afanasyev, A., Zhang, L., Oran, 1572 D., and C. Tschudin, "Information-Centric Networking 1573 (ICN): Content-Centric Networking (CCNx) and Named Data 1574 Networking (NDN) Terminology", Work in Progress, Internet- 1575 Draft, draft-irtf-icnrg-terminology-08, 17 January 2020, 1576 . 1579 [I-D.oran-icnrg-pathsteering] 1580 Moiseenko, I. and D. Oran, "Path Steering in CCNx and 1581 NDN", Work in Progress, Internet-Draft, draft-oran-icnrg- 1582 pathsteering-05, 8 November 2021, 1583 . 1586 [Krol2018] Krol, M., Habak, K., Oran, D., Kutscher, D., and I. 1587 Psaras, "RICE: Remote Method Invocation in ICN, in 1588 Proceedings of the 5th ACM Conference on Information- 1589 Centric Networking — ICN '18", 1590 DOI 10.1145/3267955.3267956, September 2018, 1591 . 1594 [Lindgren2016] 1595 Lindgren, A., Ben Abdessiem, F., Ahlgren, B., Schlelén, 1596 O., and A.M. Malik, "Design choices for the IoT in 1597 Information-Centric Networks, in 13th IEEE Annual Consumer 1598 Communications and Networking Conference (CCNC)", 1599 DOI 10.1109/CCNC.2016.7444905, January 2016, 1600 . 1602 [Moiseenko2014] 1603 Moiseenko, I., Stapp, M., and D. Oran, "Communication 1604 patterns for web interaction in named data networking", 1605 DOI 10.1145/2660129.2660152, September 2014, 1606 . 1608 [Mosko2017] 1609 Mosko, M., "CCNx 1.0 Bidirectional Streams", 1610 arXiv 1707.04738, July 2017, 1611 . 1613 [NDN] "Named Data Networking", 2020, 1614 . 1616 [NDNTLV] "NDN Packet Format Specification", 2016, 1617 . 1619 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1620 A., Peterson, J., Sparks, R., Handley, M., and E. 1621 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1622 DOI 10.17487/RFC3261, June 2002, 1623 . 1625 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1626 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1627 DOI 10.17487/RFC4122, July 2005, 1628 . 1630 [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session 1631 Initiation Protocol (SIP) Usage of the Offer/Answer 1632 Model", RFC 6337, DOI 10.17487/RFC6337, August 2011, 1633 . 1635 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 1636 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 1637 March 2015, . 1639 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1640 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1641 . 1643 [Shi2020] Shi, J., Pesavento, D., and L. Benmohamed, "NDN-DPDK: NDN 1644 Forwarding at 100 Gbps on Commodity Hardware, in 1645 Proceedings of the 7th ACM Conference on Information- 1646 Centric Networking — ICN '20", 1647 DOI 10.1145/3405656.3418715, September 2020, 1648 . 1650 [So2013] So, W., Narayanan, A., and D. Oran, "Named data networking 1651 on a router: Fast and DoS-resistant forwarding with hash 1652 tables, in proceedings of Architectures for Networking and 1653 Communications Systems", DOI 10.1109/ANCS.2013.6665203, 1654 October 2013, 1655 . 1657 [Zhang2018] 1658 Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang, "KITE: 1659 Producer Mobility Support in Named Data Networking, in 1660 Proceedings of the 5th ACM Conference on Information- 1661 Centric Networking — ICN '18", 1662 DOI 10.1145/3267955.3267959, September 2018, 1663 . 1666 Appendix A. Alternative Designs Considered 1668 During development of this specification, a number of alternative 1669 designs were considered and at least partially documented. This 1670 appendix explains them for historical purposes, and explains why 1671 these were considered inferior to the design we settled on to carry 1672 forward. 1674 A.1. Handling reflexive interests using dynamic FIB entries 1676 The original draft specification employed the use of dynamically- 1677 created FIB entries for forwarding Reflexive Interests. In this 1678 approach, at each forwarder along the inverse path from producer to 1679 consumer, a FIB entry must be present that matches this name via 1680 Longest Name Prefix Match (LNPM), so that when the reflexive interest 1681 arrives, the forwarder can forward it downstream toward the 1682 originating consumer. This FIB entry would point directly to the 1683 incoming interface on which the corresponding original Interest 1684 arrived. The FIB entry needs to be created as part of the forwarding 1685 of the original Interest so that it is available in time to catch any 1686 reflexive Interest issued by the producer. It would usually make 1687 sense to destroy this FIB entry when the Data message satisfying the 1688 original Interest arrives since this avoids any dangling stale state. 1689 Given the design details discussed below, stale FIB state would not 1690 represent a correctness hazard and hence could be done lazily if 1691 desired in an implementation. 1693 In this scheme, the forwarder operates as follows: 1695 1. The forwarder creates short-lifetime FIB entries for any 1696 Reflexive Interest Name prefixes communicated in an Interest 1697 message. If the forwarder does not have sufficient resources to 1698 do so, it rejects the Interest with the T_RETURN_NO_RESOURCES 1699 error - the same error used if the forwarder were lacking 1700 sufficient PIT resources to process the Interest message. 1702 2. Those FIB entries are queried whenever an Interest message 1703 arrives whose first name component is of the type _Reflexive 1704 Interest Name Component (RNP)_ 1706 3. The FIB entry gets removed eventually, after the corresponding 1707 Data message has been forwarded. One option would be to remove 1708 the FIB directly after the Data message has been forwarded. 1709 However, the forwarder might choose do lazy cleanup. 1711 There are a number of additional considerations with this design that 1712 need to be dealt with. 1714 A.1.1. Design complexities and performance issues with FIB-based design 1716 When processing an Interest containing the reflexive name TLV and 1717 creating the necessary FIB entry, the forwarder also creates a _back 1718 pointer_ from that FIB entry to the PIT entry for the Interest 1719 message that created it. This PIT entry contains the current value 1720 of the remaining Interest lifetime or alternatively a value from 1721 which the remaining Interest lifetime can be easily computed. Call 1722 this value _IL_t_. 1724 The forwarder input thread could key off the high-order name 1725 component type (one byte) and if reflexive, do a reflexive FIB lookup 1726 instead of a full name hash. The reflexive FIB entry would contain 1727 the shard identity of the matching Interest (concretely, the core id 1728 servicing the shard) and steer the reflexive interest there. The 1729 reflexive name prefix FIB lookup would have to be competitive 1730 performance-wise with a full-name hash for this to win, however. 1731 Experimentation is needed to further evaluate such implementation 1732 tradeoffs for input packet load balancing in high-speed forwarders. 1734 The FIB is a performance-critical data structure in any forwarder, as 1735 it needs to support relatively expensive longest name prefix match 1736 (LNPM) lookup algorithms. A number of well-known FIB data structures 1737 are heavily optimized for read access, since for normal Interest 1738 message processing the FIB changes slowly - only after topological 1739 changes or routing protocol updates. Support for reflexive names 1740 using dynamic FIB entries changes this, as FIB entries would be 1741 created and destroyed rapidly as Interest messages containing 1742 reflexive name TLVs are processed and the corresponding Data messages 1743 come back. 1745 While it may be feasible, especially in low-end forwarders handling a 1746 low packet forwarding rate to ignore this problem, for high-speed 1747 forwarders there are a number of hazards, including: 1749 1. If the entire FIB needs to be locked in order to insert or remove 1750 entries, this could cause inflated forwarding delays or in 1751 extreme cases, forwarding performance collapse. 1753 2. A number of high-speed forwarder implementations employ a sharded 1754 PIT scheme (see Section 10.1.1) to better parallelize forwarding 1755 across processing cores. The FIB, however, is still a shared 1756 data structure which is either read without read locks across 1757 cores, or explicitly copied such that there is a separate copy of 1758 the FIB for each PIT shard. Clearly, a high update rate without 1759 read locks and/or updating many copies of the FIB are 1760 unattractive implementation options. (Note: unlike the adopted 1761 scheme in the main specification, by just depending on a dynamic 1762 FIB it is not feasible to force reflexive interests to be hashed 1763 or be otherwise directed to the PIT shard holding the original 1764 Interest state). 1766 There are any number of alternative FIB implementations that can work 1767 adequately. The most straightforward would be to simply implement a 1768 "special" FIB for just reflexive name lookups. This is feasible 1769 because reflexive names deterministically contain the distinguished 1770 high-order name component type of T_REFLEXIVE_NAME, whose content is 1771 a 64-bit value that can be easily hashed to a FIB entry directly, 1772 avoiding the more expensive LNPM lookup. Inserts and deletes then 1773 devolve to the well-understood problem of hash table maintenance. 1775 A.1.2. Interactions between FIB-based design and Interest Lifetime 1777 If Interest lifetime handling is implemented naively, it may run 1778 afoul of a sharded PIT forwarder implementation, since the PIT entry 1779 for the reflexive Interest and the PIT entry for the original 1780 Interest may be in different shards. Therefore, if the update is 1781 done cross-shard on each reflexive Interest arrival, performance may 1782 suffer, perhaps dramatically. Instead, the following approach to 1783 updating the Interest lifetime after computing the new value is would 1784 be needed by this FIB-based design for sharded-PIT forwarders. 1786 When creating the reflexive FIB entry as above in Appendix A.1.1, 1787 copy the remaining Interest lifetime from the PIT entry. Do the PIT 1788 update if and only if this value is about to expire, thus paying the 1789 cross-shard update cost only if the original Interest is about to 1790 expire. A further optimization at the cost of modest extra 1791 complexity is to instead _queue_ the update to the core holding the 1792 shard of the original PIT entry rather than doing the update 1793 directly. If the PIT entry expires or is satisfied, instead of 1794 removing it the associated core checks the update queue and does the 1795 necessary update. 1797 A.2. Reflexive forwarding using Path Steering 1799 We also considered leveraging Path Steering 1800 [I-D.oran-icnrg-pathsteering] Path Labels that inform the forwarder 1801 at each hop which outgoing face to use for for forwarding the 1802 Reflexive Interest. In this approach, the producer, when creating 1803 and issuing the Reflexive Interest with the Reflexive Name Prefix 1804 includes a Path Label to strictly steer the forwarding at all hops 1805 from the producer to the consumer (strict mode Path Steering). This 1806 means, the Reflexive Interest carries the Reflexive Name Prefix, but 1807 forwarders do not apply LNPM or any other outgoing face selection 1808 based on the name. It also eliminates the need for dynamic FIB 1809 entries as discussed above in Appendix A.1. Instead the forwarding 1810 is strictly steered by the Path Label using regular Path Steering 1811 semantics. 1813 The message flow using Path Steering would look like the following: 1815 +-----------+ +-----------+ +-----------+ 1816 | Consumer | | Forwarder | | Producer | 1817 +-----------+ +-----------+ +-----------+ 1818 | -----------------------------\ | | 1819 |-| Create I1 with additional, | | | 1820 | | emptyPath Label | | | 1821 | | data structure | | | 1822 | | for reverse discovery | | | 1823 | |----------------------------| | | 1824 | | | 1825 | I1 with Path Label | | 1826 | and RNP TLV | | 1827 |----------------------------------->| | 1828 | | -----------------\ | 1829 | |-| Add path label | | 1830 | | | for adjacency | | 1831 | | | to Consumer | | 1832 | | |----------------| | 1833 | | | 1834 | | I1 | 1835 | |-------------------------->| 1836 | | ------------------\ | 1837 | | | Create RI state |-| 1838 | | |-----------------| | 1839 | | | 1840 | | RI with RNP | 1841 | | and path label | 1842 | | (strict mode) | 1843 | |<--------------------------| 1844 | --------------------------\ | | 1845 | | perform path label |-| | 1846 | | switching (no FIB info) | | | 1847 | |-------------------------| | | 1848 | | | 1849 | RI with RNP | | 1850 |<-----------------------------------| | 1851 | | | 1852 | D2 (RNP) | | 1853 |----------------------------------->| | 1854 | | --------------------\ | 1855 | |-| regular PIT-based | | 1856 | | | forwarding | | 1857 | | |-------------------| | 1858 | | | 1859 | | D2 (RNP) | 1860 | |-------------------------->| 1861 | | -----------------\ | 1862 | | | all parameters |-| 1863 | | | received, | | 1864 | | | answer orig. | | 1865 | | | I1 Interest | | 1866 | | |----------------| | 1867 | | | 1868 | | D1 | 1869 | |<--------------------------| 1870 | --------------------\ | | 1871 | | regular PIT-based |-| | 1872 | | forwarding | | | 1873 | |-------------------| | | 1874 | | | 1875 | D1 | | 1876 |<-----------------------------------| | 1877 | | | 1879 Legend: 1880 I1: Interest #1 containing the Reflexive Name Prefix TLV 1881 RI: Reflexive Interest with Reflexive Name Prefix Component 1882 RNP: Reflexive Name Prefix 1883 D1: Data message, answering initiating I1 Interest 1884 D2: Data message, answering RI 1886 Figure 8: Message Flow Overview using Path Steering 1888 Path Steering uses Path Label data structures on the downstream path 1889 (from producer to consumer) to discover and collect hop-by-hop 1890 forwarding information so that consumers can then specify selected 1891 paths for subsequent Interests. Reflexive Forwarding would use the 1892 same data structure, but for "reverse discovery", i.e., in the 1893 upstream direction from consumer to producer. 1895 From an operational perspective the path-steering approach does not 1896 exhibit good properties with respect to backward compatibility. 1897 Without a complete path of forwarders between consumer and producer 1898 that support path steering, reflexive interests cannot reach the 1899 intended consumer. While we might envision a way to steer a 1900 subsequent Interest onto a working path as proposed in 1901 [I-D.oran-icnrg-pathsteering], there is no capability to force 1902 Interest routing away from an otherwise working path not supporting 1903 the reflexive name TLV. 1905 Authors' Addresses 1907 Dave Oran 1908 Network Systems Research and Design 1909 4 Shady Hill Square 1910 Cambridge, MA 02138 1911 United States of America 1913 Email: daveoran@orandom.net 1915 Dirk Kutscher 1916 University of Applied Sciences Emden/Leer 1917 Constantiapl. 4 1918 26723 Emden 1919 Germany 1921 Email: ietf@dkutscher.net 1922 URI: https://dirk-kutscher.info