idnits 2.17.1 draft-oran-icnrg-reflexive-forwarding-00.txt: -(1254): 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 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 April 2020) is 1483 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-02 == Outdated reference: A later version (-07) exists of draft-oran-icnrg-pathsteering-00 Summary: 0 errors (**), 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: 4 October 2020 2 April 2020 8 Reflexive Forwarding for CCNx and NDN Protocols 9 draft-oran-icnrg-reflexive-forwarding-00 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 4 October 2020. 46 Copyright Notice 48 Copyright (c) 2020 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 . . . . . . . . . . . . . . . 4 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. Naming of Reflexive Interests . . . . . . . . . . . . . . . . 10 65 5. Forwarder operation for Reflexive Interests . . . . . . . . . 11 66 6. State coupling between producer and consumer . . . . . . . . 12 67 7. Use cases for Reflexive Interests . . . . . . . . . . . . . . 12 68 7.1. Achieving Remote Method Invocation with Reflexive 69 Interests . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7.2. RESTful Web Interactions . . . . . . . . . . . . . . . . 15 71 7.3. Achieving simple data pull from consumers with reflexive 72 Interests . . . . . . . . . . . . . . . . . . . . . . . . 15 73 8. Implementation Considerations . . . . . . . . . . . . . . . . 19 74 8.1. Forwarder implementation considerations . . . . . . . . . 19 75 8.1.1. Forwarding Information Base (FIB) . . . . . . . . . . 19 76 8.1.2. Interactions with Interest Lifetime . . . . . . . . . 20 77 8.1.3. Interactions with Interest aggregation . . . . . . . 21 78 8.2. Consumer Implementation Considerations . . . . . . . . . 21 79 8.2.1. Data objects returned by the consumer to reflexive name 80 Interests arriving from a producer . . . . . . . . . 21 81 8.2.2. Terminating unwanted reflexive Interest exchanges . . 22 82 8.2.3. Interactions with caching . . . . . . . . . . . . . . 22 83 8.3. Producer Implementation Considerations . . . . . . . . . 22 84 9. Operational Considerations . . . . . . . . . . . . . . . . . 23 85 10. Mapping to CCNx and NDN packet encodings . . . . . . . . . . 24 86 10.1. Packet encoding for CCNx . . . . . . . . . . . . . . . . 24 87 10.2. Packet encoding for NDN . . . . . . . . . . . . . . . . 24 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 90 12.1. Collisions of reflexive Interest names . . . . . . . . . 25 91 12.2. Additional resource pressure on PIT and FIB . . . . . . 26 92 12.3. Privacy Considerations . . . . . . . . . . . . . . . . . 26 93 13. Normative References . . . . . . . . . . . . . . . . . . . . 27 94 14. Informative References . . . . . . . . . . . . . . . . . . . 27 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 97 1. Introduction 99 Current ICN protocols such as CCNx [RFC8569] and [NDN] have a wide 100 range of useful applications in content retrieval and other scenarios 101 that depend only on a robust two-way exchange in the form of a 102 request and response. These ICN architectures use the terms 103 "consumer" and "producer" for the respective roles of the requester 104 and the responder, and the protocols directly capture the mechanics 105 of the two-way exchange through the "Interest message" carrying the 106 request, and the "Data message" carrying the response. Through these 107 constructs, the protocols are heavily biased toward a pure _pull- 108 based_ interaction model where requests are small (carrying little or 109 no user-supplied data other than the name of the requested data 110 object), and responses are relatively large - up to an architecture- 111 defined maximum transmission unit (MTU) on the order of kilobytes or 112 tens of kilobytes. 114 A number of important applications however require interaction models 115 more complex than individual request/response interactions in the 116 same direction (i.e. between the same consumer and one or more 117 producers). Among these we identify three important classes which 118 are the target of the proposed enhancements defined in this 119 specification. These are described in the following paragraphs. 121 *Remote Method Invocation (RMI, aka RPC):* When invoking a remote 122 method, it is common for the method to require arguments supplied 123 by the caller. In conventional TCP/IP style protocols like CORBA 124 or HTTP "Post", these are pushed to the server as part of the 125 message or messages that comprise the request. In ICN-style 126 protocols there is an unattractive choice between inflating the 127 request initiation with pushed arguments, or arranging to have one 128 or more independent request/responses in the opposite direction 129 for the server to fetch the arguments. Both of these approaches 130 have substantial disadvantages. Recently, a viable alternative 131 emerged through the work on RICE [Krol2018] which pioneered the 132 main design elements proposed in this specification. 134 *Phone-Home scenario:* Applications in sensing, Internet-of-things 135 (IoT) and other types where data is produced unpredictably and 136 needs to be _pushed_ somewhere create a conundrum for the pure 137 pull-based architectures considered here. If instead one eschews 138 relaxing the size asymmetry between requests and responses, some 139 additional protocol machinery is needed. Earlier efforts in the 140 ICN community have recognized this issue and designed methods to 141 provoke a cooperating element to issue a request to return the 142 data the originator desires to push, essentially "phoning home" to 143 get the responder to fetch the data. One that has been explored 144 to some extent is the _Interest-Interest-Data_ exchange 145 [Carzaniga2011], where an Interest is sent containing the desired 146 request as encapsulated data. CCNx-1.0 Bidirectional Streams 147 [Mosko2017] are also based on a scheme where an Interest is used 148 to signal a name prefix that a consumer has registered for 149 receiving Interests from a peer in a bidirectional streaming 150 session. 152 *Peer state synchronization:* A large class of applications, 153 typified by those built on top of on reliable order-preserving 154 transport protocols, require initial state synchronization between 155 the peers. This is accomplished with a three-way (or longer) 156 handshake, since employing a two-way handshake as provided in the 157 existing NDN and CCNx protocols exposes a number of well-know 158 hazards, such as _half-open connections_. When attempted for 159 security-related operations such as key exchange, additional 160 hazards such as _man-in-the-middle_ attacks become trivial to 161 mount. Existing alternatives, similar to those used in the two 162 examples above, instead utilize either overlapping Interest-Data 163 exchanges in opposite directions (resulting in a four-way 164 handshake) or by adding initialization data to the initial request 165 and employing an Interest-Interest-Data protocol extension as 166 noted in the Phone-home scenarios above. 168 All of the above application interaction models present interesting 169 challenges, as neither relaxing the architecture to support pushing 170 large amounts of data, nor introducing substantial complexities 171 through multiple independent Interest-Data exchanges is an attractive 172 approach. The following subsections provide further background and 173 justification for why push and/or independent exchanges are 174 problematical. 176 1.1. Problems with pushing data 178 There are two substantial problems with the simple approach of just 179 allowing arbitrary amounts of data to be included with requests. 180 These are: 182 1. In ICN protocols, Interest messages are intended to be small, on 183 the order the size of a TCP ACK, as opposed to the size of a TCP 184 data segment. This is because the hop-by-hop congestion control 185 and forwarder state management requires Interest messages to be 186 buffered in expectation of returning data, and possibly 187 retransmitted hop-by-hop as opposed to end-to-end. In addition, 188 the need to create and manage state on a per-Interest basis is 189 substantially complicated if requests in Interest messages are 190 larger than a Path MTU (PMTU) and need to be fragmented hop-by- 191 hop. 193 2. If the payload data of a request is used for invoking a 194 computation (as in the RMI case described above) then substantial 195 bandwidth can be wasted if the computation is either refused or 196 abandoned for any number of reasons, including the requestor 197 failing an authorization check, or the responder not having 198 sufficient resources to execute the associated computation. 200 These problems also exist in pure datagram transport protocols such 201 as those used for legacy RMI applications like NFS [RFC7530]. More 202 usual are application protocols like HTTP(s) which rely on the TCP or 203 QUIC 3-way handshake to establish a session and then have congestion 204 control and segmentation provided as part of the transport protocol, 205 further allowing sessions to be rejected before large amounts of data 206 are transmitted or significant computational resources expended. 208 1.2. Problems with utilizing independent exchanges 210 In order to either complete a three-way handshake, or fetch data via 211 a pull from the original requestor, the role of consumer and producer 212 need to be reversed and an Interest/Data exchange initiated in the 213 direction opposite of the initiating exchange. When done with an 214 independent Interest/Data request and response, a number of 215 complications ensue. Among them are: 217 1. The originating consumer needs to have a routable name prefix 218 that can be used for the exchange. This means the consumer must 219 arrange to have its name prefix propagated in the ICN routing 220 system with sufficient reach that the producer issuing the 221 interest can be assured it is routed appropriately. While some 222 consumers are generally online and act as application servers, 223 justifying the maintenance of this routing information, many do 224 not. Further, in mobile environments, a pure consumer that does 225 not need to have a routable name prefix can benefit from the 226 inherent consumer mobility support in the CCNx and NDN protocols. 227 By requiring a routable name prefix, extra mobile routing 228 machinery is needed, such as that proposed in KITE [Zhang2018] or 229 MAPME [Auge2018]. 231 2. The consumer name prefix in item (1) above must be communicated 232 to the producer as a payload, name suffix, or other field of the 233 initiating Interest message. Since this name in its entirety is 234 chosen by the consumer, it is highly problematic from a security 235 standpoint, as it can recruit the producer to mount a reflection 236 attack against the consumer's chosen victim. 238 3. The correlation between the exchanges in opposite directions must 239 be maintained by both the consumer and the producer as 240 independent state, as opposed to being architecturally tied 241 together as would be the case with a conventional 3-way handshake 242 finite state machine. While this can of course be accomplished 243 with care by both parties, experience has shown that it is error 244 prone (for example see the checkered history of interactions 245 between the SIP [RFC3261] and SDP Offer-Answer [RFC6337]) 246 protocols. When employed as the wrapper for a key management 247 protocol such as with TLS [RFC8446] state management errors can 248 be catastrophic for security. 250 2. Requirements Language 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 254 "OPTIONAL" in this document are to be interpreted as described in 255 [RFC2119]. 257 3. Overview of the Reflexive Forwarding design 259 This specification defines a _Reflexive Forwarding_ extension to CCNx 260 and NDN that avoids the problems enumerated in Sections 1.1 and 1.2. 261 It straightforwardly exploits the hop-by-hop state and symmetric 262 routing properties of the current protocols. 264 Figure 1 below illustrates a canonical NDN/CCNx forwarder with its 265 conceptual data structures of the Content Store (CS), Pending 266 Interest Table (PIT) and Forwarding Information Base (FIB). The key 267 observation involves the relation between the PIT and the FIB. Upon 268 arrival of an Interest, a PIT entry is created which contains state 269 recording the incoming interface on which the Interest. If the 270 Interest is not immediately satisfied by cached data in the CS, the 271 forwarder looks up the name in the FIB to ascertain the _next-hop_ to 272 propagate the Interest onward upstream toward the named producer. 273 Therefore, a chain of forwarding state is established during Interest 274 forwarding that couples the PIT entries of the chain of forwarders 275 together conceptually as _breadcrumbs_. These are used to forward the 276 returning Data Message over the inverse path through the chain of 277 forwarders until the Data message arrives at the originating 278 consumer. The state in the PITs is _unwound_ by destroying it as 279 each PIT entry is _satisfied_. This behavior is *critical* to the 280 feasibility of the reflexive forwarding design we propose. 282 +-----------------------------------------------------------------+ 283 | ICN Node | 284 | Send data to all ======== | 285 | interfaces that | 286 | requested it | 287 | YES +------------------+ | 288 <------------------------| Pending Interest | <--------------------- 289 | | | Table (PIT) | Data | 290 | | +------------------+ 1) Find (Signed) | 291 | | 2) Save | Name | 292 | V Data | NO in | 293 | +---------------+ | PIT? | 294 | | Content Store | | | 295 | | (CS) | | | 296 | +---------------+ | | 297 | | | 298 | V | 299 | Drop Data | 300 | | 301 +-----------------------------------------------------------------+ 302 +-----------------------------------------------------------------+ 303 | ICN Node | 304 | ======== | 305 | | 306 | +====================+| 307 | |Forwarding Strategy || 308 | +====================+| 309 | | 310 | 1) Find name 2) Matching 3) Find matching | 311 | in CS? name in PIT? entry in FIB? | 312 | NO NO YES| 313 | +---------------+ +----------------+ +-------------------+ | 314 | | Content Store | | Pending | | Forwarding | | 315 --->| (CS) |-->| Interest |-->| Information Base |--> 316 | | | | Table (PIT) | | ( FIB) | | 317 | +---------------+ +----------------+ +-------------------+ | 318 | Return | YES YES | NO NO | | 319 | Data | Add | Add | Drop | 320 | | Incoming | new | or | 321 | <------| Itf. | Interest | NACK | 322 | V V | 323 | | 324 +-----------------------------------------------------------------+ 326 Figure 1: ICN forwarder structure 328 Given the above forwarding properties for Interests, it should be 329 clear that while an Interest is outstanding and ultimately arrives at 330 a producer who can respond to it, there is sufficient state in the 331 chain of forwarders to route not just a returning Data message, but 332 potentially another Interest directed through the inverse path to the 333 unique consumer who issued the original Interest. (Section 8.1.3 334 describes how Interest aggregation interacts with this scheme.) The 335 key question therefore is how to access this state in a way that it 336 can be used to forward Interests. 338 In order to achieve this _Reflexive Interest_ forwarding on the 339 inverse path recorded in the PIT of each forwarder, we need a few 340 critical design elements. These are as follows: 342 1. The Reflexive Interest needs to have a Name. This name is what 343 the originating consumer will use to match against the Data 344 object (or objects - more on this later) it wishes the producer 345 to fetch by issuing the Reflexive Interest. This cannot be just 346 any name, but needs to essentially name the state already 347 recorded in the PIT and not allow the consumer to manufacture an 348 arbitrary name and mount a reflection attack as pointed out in 349 Section 1.2, Paragraph 2, Item 2. 351 2. There has to be a FIB entry at each forwarder for this name 352 prefix so that when the reflexive interest arrives, the forwarder 353 can forward it downstream toward the originating consumer. This 354 FIB entry points directly to the incoming interface on which the 355 corresponding original Interest arrived. The FIB entry needs to 356 be created as part of the forwarding of the original Interest so 357 that it is available in time to catch any reflexive Interest 358 issued by the producer. It usually makes sense to destroy this 359 FIB entry when the Data message satisfying the original Interest 360 arrives since this avoids any dangling stale state. Given the 361 deign details documented later in this specification, stale FIB 362 state does not represent a correctness hazard and hence can be 363 done lazily if desired in an implementation. See Section 5 for 364 more details on FIB operation considerations. 366 3. There has to be coupling of the state between the originating 367 Interest-Data exchange and the enclosed Reflexive Interest-Data 368 exchange at both the consumer and the producer. In our design, 369 this accomplished by the way reflexive interest names are chosen. 371 The following sections provide the normative details on each of these 372 design elements. The overall interaction flow for reflexive 373 forwarding is illustrated below in Figure 2. 375 +-----------+ +-----------+ +-----------+ 376 | Consumer | | Forwarder | | Producer | 377 +-----------+ +-----------+ +-----------+ 378 | | | 379 | I1 | | 380 |--------------->| | 381 |--------------\ | | 382 || Install RNP |-| | 383 || in FIB | | | 384 ||-------------| | | 385 | | | 386 | | I1 | 387 | |----------------------------->| 388 | | | -----------\ 389 | | |-| Create | 390 | | | | RI state | 391 | | | |----------| 392 | | | 393 | | RI | 394 | |<-----------------------------| 395 | | --------------------\ | 396 | |-| lookup RNP in FIB | | 397 | | |-------------------| | 398 | | | 399 | RI | | 400 |<---------------| | 401 | | | 402 | D2 | | 403 |--------------->| | 404 | | | 405 | | D2 | 406 | |----------------------------->| 407 | | | ------------\ 408 | | |-| answer I1 | 409 | | | |-----------| 410 | | | 411 | | D1 | 412 | |<-----------------------------| 413 | | -----------------------\ | 414 | |-| remove RNP FIB entry | | 415 | | |----------------------| | 416 | | | 417 | D1 | | 418 |<---------------| | 419 | | | 421 Legend: 422 I1: Interest #1 containing the Reflexive Name Prefix TLV 423 RI: Reflexive Interest with Reflexive Name Prefix Component 424 RNP: Reflexive Name Prefix 425 D1: Data message, answering initiating I1 Interest 426 D2: Data message, answering RI 428 Figure 2: Message Flow Overview 430 4. Naming of Reflexive Interests 432 A consumer may have one or more objects for the producer to fetch, 433 and therefore needs to communicate enough information in their 434 initial Interest to allow the producer to construct properly formed 435 reflexive Interest names. For some applications the set of _full 436 names_ (see [I-D.irtf-icnrg-terminology]) is known a priori, for 437 example through compile time bindings of arguments in interface 438 definitions or by the architectural definition of a simple sensor 439 reading. In other cases the full names of the individual objects 440 must be communicated in the original Interest message. In all cases 441 enough state must be provided by the consumer for the forwarders to 442 construct a FIB entry (as noted in Section 3, Paragraph 6, Item 2). 443 This is accomplished through the following naming construct. 445 We define a new typed name component, identified by a registered name 446 component type in the IANA registry for [RFC8569]. We call this the 447 _Reflexive Interest Name Component type_. It MUST be the first (i.e. 448 high order) name component of any Reflexive Interest issued by a 449 producer. Its value is a random 64 bit number, assigned by the 450 consumer, which provides the entropy required to uniquely identify 451 the issuing consumer for the duration of any outstanding Interest- 452 Data exchange. The consumer SHOULD choose a different random value 453 for each Interest message it constructs, for two reasons: 455 1. If stale FIB sate is present, the randomness prevents potential 456 mis-routing of reflexive interests (see Section 8.1.1 below for 457 more details), and 459 2. Re-use of the same reflexive interest name over multiple 460 interactions might reveal linkability information that could be 461 used by surveillance adversaries for tracking purposes. 463 This initial name component is either communicated by itself through 464 a _Reflexive Name Prefix TLV_ in the originating Interest, or 465 prepended to any object names the consumer wishes the producer to 466 fetch explicitly where there is more than one object needed by the 467 producer for the current Interest-Data interaction. There are four 468 cases to consider: 470 1. The reflexive _fullname_ of a single object to fetch. 472 2. A single reflexive name prefix out of which the producer can (by 473 application-specific means) construct a number of _fullnames_ of 474 the objects it may want to fetch, 476 3. The reflexive _fullname_ of a FLIC Manifest [I-D.irtf-icnrg-flic] 477 enumerating the suffixes that may be used by the producer to 478 construct the necessary names, 480 4. Multiple reflexive name TLVs MAY be included in the Interest 481 message if none of the above 3 options covers the desired use 482 case. 484 The last of the four options above, while not explicitly outlawed, 485 SHOULD NOT be used. This is because it results in a longer Interest 486 message and requires extra FIB resources. Hence, it is more likely a 487 forwarder will reject the Interest for lack of resources. A 488 forwarder MAY optimize for the case of a single Reflexive Name TLV at 489 the expense of those with more than one. 491 A producer, upon receiving an Interest with one or more Reflexive 492 Name TLVs, may decide it needs the pull the associated data 493 object(s). It therefore can issue one or more Reflexive Interests by 494 appending the necessary name components needed to form valid full 495 names of the associated objects present at the originating consumer. 496 These in fact comprise conventional Interest-Data exchanges, with no 497 alteration of the usual semantics with regard to signatures, caching, 498 expiration, etc. When the producer has retrieved the required 499 objects to complete the original Interest-Data exchange, it can issue 500 its Data response, which unwinds all the established state at the 501 producer, the consumer, and the intermediate forwarders. 503 5. Forwarder operation for Reflexive Interests 505 The forwarder operation for CCNx and/or NDN is changed in three 506 respects when supporting Reflexive Interests. 508 1. The forwarder MUST create short-lifetime FIB entries for any 509 Reflexive Interest Name prefixes communicated in an Interest 510 message. If the forwarder does not have sufficient resources to 511 do so, it MUST reject the Interest with the T_RETURN_NO_RESOURCES 512 error - the same error used if the forwarder were lacking 513 sufficient PIT resources to process the Interest message. 515 2. Those FIB entries MUST be queried whenever an Interest message 516 arrives whose first name component is of the type _Reflexive 517 Interest Name Component_ 519 3. The FIB entry MUST be removed eventually, after the corresponding 520 Data message has been forwarded. One option would be to remove 521 the FIB directly after the Data message has been forwarded. 522 However, the forwarder MAY do lazy cleanup. 524 The PIT entry for the Reflexive Interest is consumed per regular 525 Interest/Data message forwarding requirements. The PIT entry for the 526 originating Interest (that communicated the Reflexive Interest Name) 527 is also consumed by a final Data message from the producer to the 528 original consumer. 530 6. State coupling between producer and consumer 532 A consumer that wishes to use this scheme MUST utilize one of the 533 reflexive naming options defined in Section 4 and include it in the 534 corresponding Interest message. The Reflexive Name TLV _and_ the 535 full name of the requested data object (that identifies the producer) 536 identify the common state shared by the consumer and the producer. 537 When the producer responds by sending Interests with the Reflexive 538 Name Prefix, the original consumer therefore has sufficient 539 information to map these Interests to the ongoing Interest-Data 540 exchange. 542 The exchange is finished when the producer who received the original 543 Interest message responds with a Data message (or an Interest Return 544 message in the case of error) answering the original Interest. After 545 sending this Data message, the producer SHOULD destroy the 546 corresponding shared state. It MAY decide to use a timer that will 547 trigger a later state destruction. After receiving this Data 548 message, the originating consumer MUST destroy the corresponding 549 Interest-Data exchange state. 551 7. Use cases for Reflexive Interests 553 7.1. Achieving Remote Method Invocation with Reflexive Interests 555 RICE (Remote Method Invocation in ICN) [Krol2018] uses the Reflexive 556 Interest Forwarding scheme that inspired the design specified in this 557 document. 559 In RICE, the original Interest denotes the remote method (plus 560 potential parameters) to be invoked at a producer (server). Before 561 committing any computating resources, the server can then request 562 authentication credentials and (optional) parameters using reflexive 563 Interest-Data exchanges. 565 When the server has obtained the necessary credentials and input 566 parameters, it can decide to commit computing resources, starts the 567 compute process, and returns a handle ("Thunk") in the final Data 568 message to the original consumer (client). 570 The client would later request the computation results using a 571 regular Interest-Data exchange (outside the Reflexive-Interest 572 transaction) -- using the Thunk as a name for the computation result. 574 Figure 3 depicts an abstract message diagram for RICE. In addition 575 to the 4-way Reflexive Forwarding Handshake (see Figure 2 for the 576 details of the interaction), RICE adds another (standard) ICN 577 Interest/Data exchange for transmitting the RMI result. The Thunk 578 name is provided to the consumer in the D1 DATA message (answering 579 the initial I1 Interest). 581 +-----------+ +-----------+ 582 | Consumer | | Producer | 583 +-----------+ +-----------+ 584 | | 585 | I1 | 586 |------------------------->| 587 | | ---------------------\ 588 | |-| Requesting request | 589 | | | parameters | 590 | | | and credentials | 591 | | |--------------------| 592 | | 593 | RI | 594 |<-------------------------| 595 | | 596 | D2 | 597 |------------------------->| 598 | | --------------------\ 599 | |-| Commit compute | 600 | | | resources, | 601 | | | return Thunk name | 602 | | |-------------------| 603 | | 604 | D1 | 605 |<-------------------------| 606 | | ----------------\ 607 | |-| Invoke Remote | 608 | | | Method | 609 | | |---------------| 610 | -------------------\ | 611 |-| After some time, | | 612 | | request result | | 613 | |------------------| | 614 | | 615 | I3 | 616 |------------------------->| 617 | | 618 | D3 | 619 |<-------------------------| 620 | | 621 Legend: 622 I1: Interest #1 containing the Reflexive Name Prefix TLV 623 D1: Data message, answering initiating I1 Interest, 624 returning Thunk name 625 D2: Data message, answering RI (parameters, credentials) 626 I3: Regular Interest for Thunk (compute result) 627 D3: Data message, answering I3 628 Figure 3: RICE Message Flow 630 7.2. RESTful Web Interactions 632 In todays HTTP-based web, RESTful (Representational State Transfer) 633 web interactions are realized by sending requests in a client/server 634 interaction, where the requests provides the application context (or 635 a reference to it). It has been noted in [Moiseenko2014] that 636 corresponding requests often exceed the response messages in size, 637 and that this raises the problems noted in Section 1.1 when 638 attempting to map such exchanges directly to CCNx/NDN. 640 Another reason not to include all request parameters in a (possibly 641 encrypted) Interest message is the fact that a server (that is 642 serving thousands of clients) would be obliged to receive, possibly 643 decrypt and parse the complete requests before being able to 644 determine whether the requestor is authorized, whether the request 645 can be served etc. Many non-trivial requests could thus lead to 646 computational overload attacks. 648 Using Reflexive Interest Forwarding for RESTful Web Interactions 649 would encode the REST request in the Original request, together with 650 a Reflexive Interest Prefix that the server could then use to get 651 back to the client for authentication credentials and request 652 parameters, such as cookies. The request result (response message) 653 could either be transmitted in the Data message answering the 654 original request, or -- in case of dynamic, longer-running 655 computations -- in a seperate Interest/Data exchange, potentially 656 leveraging the Thunk scheme described in section Section 7.1. 658 Unlike approaches where clients have to signal a globally routable 659 prefix to the network, this approach would not require the client 660 (original consumer) to expose its identity to the network (the 661 network only sees the temporary Reflexive Name Prefix), but it would 662 still be possible to authenticate the client at the server. 664 7.3. Achieving simple data pull from consumers with reflexive Interests 666 An oft-cited use case for ICN network architectures is _Internet of 667 Things_ (IoT), where the sources of data are limited-resource sensor/ 668 actuators. Many approaches have been tried (e.g. [Baccelli2014], 669 [Lindgren2016], [Gundogan2018]) with varying degrees of success in 670 addressing the issues outlined in Section 1.1. The reflexive 671 forwarding extension may substantially ameliorate the documented 672 difficulties by allowing a different model for the basic interaction 673 of sensors with the ICN network. 675 Instead of acting as a producer (either directly to the Internet or 676 indirectly through the use of some form of application-layer 677 gateway), the IoT device need only act as a consumer. When it has 678 data to provide, it issues a "phone-home" Interest message to a pre- 679 configured rendezvous name (e.g. an application-layer gateway or ICN 680 Repo [Chen2015]) and provides a reflexive name prefix TLV for the 681 data it wishes to publish. The target producer may then issue the 682 necessary reflexive Interest message(s) to fetch the data. Once 683 fetched, validated, and stored, the producer then responds to the 684 original Interest message with a success indication, possibly 685 containing a Data object if needed to allow the originating device to 686 modify its internal state. Alternatively, the producer might choose 687 to not respond and allow the original Interest to time out, although 688 this is NOT RECOMMENDED except in cases where the extra message 689 transmission bandwith is at a premium compared to the persistence of 690 stale state in the forwarders. We note that this interaction 691 approach mirrors the earlier efforts using Interest-Interest-Data 692 designs. 694 Figure 4 depicts this interaction with the OPTIONAL D1 message. See 695 Figure 2 for the details of the general Reflexive Forwarding 696 interaction. 698 +-----------+ +-----------+ 699 | Consumer | | Producer | 700 +-----------+ +-----------+ 701 ------------\ | | 702 | new IoT |-| | 703 | data item | | | 704 | produced | | | 705 |-----------| | | 706 ---------------\ | | 707 | "phone home" |-| | 708 | by notifying | | | 709 | producer | | | 710 |--------------| | | 711 | | 712 | I1 | 713 |------------>| 714 | | --------------------\ 715 | |-| generate Interest | 716 | | | for IoT data | 717 | | |-------------------| 718 | | 719 | RI | 720 |<------------| 721 -----------------\ | | 722 | send requested |-| | 723 | data object | | | 724 |----------------| | | 725 | | 726 | D2 | 727 |------------>| 728 | | -----------------------\ 729 | |-| finalize interaction | 730 | | | with optional | 731 | | | Data message | 732 | | |----------------------| 733 | | 734 | D1 | 735 |<------------| 736 | | 737 Legend: 738 I1: Interest #1 containing the Reflexive Name Prefix TLV 739 D1: Data message (OPTIONAL), finalizing interaction 740 D1: Data message, answering RI, returning IoT data object 742 Figure 4: "Phone Home" Message Flow 744 There are two approaches that the IoT device can use for its response 745 to a reflexive Interest. It can simply construct a Data Message 746 bound through the usual ICN hash name to the reflexive Interest name. 747 Since the scope of any data object bound in this way is only the 748 duration of the enclosing Interest-Data exchange (see Section 8.2) 749 the producer would need to itself construct any persistent Data 750 object, name it, and sign it. This is sometimes the right approach, 751 as for some applications the identity of the originating IoT device 752 is not important from an operational or security point of view; in 753 contrast the identity of the gateway or Repo is what matters. 755 If alternatively, the persistent Data object should be bound from a 756 naming and security point of view to the originating IoT device, this 757 can be easily accomplished. Instead of directly placing the content 758 in a Data object responding to the reflexive Interest as above, the 759 consumer encapsulates a complete CCNx/NDN Data message (which 760 includes the desired name of the data) as in the response to the 761 reflexive Interest message. 763 The interaction model described above brings a number potential 764 advantages, some obvious, some less so. We enumerate a few of them 765 as follows: 767 * By not requiring the IoT device to be actively listening for 768 Interests, it can sleep and only wake up if it has something to 769 communicate. Conversely, parties interested in obtaining data 770 from the device do not need to be constantly polling in order to 771 ascertain if there is new data available. 773 * No forwarder resources are tied up with state apart from the 774 actual reflexive forwarding interactions. All that is needed is 775 enough routing state in the FIB to be able to forward the "phone 776 home" Interest to an appropriate target producer. While this 777 model does not provide all the richness of a full Pub/Sub system 778 (like that described in [Gundogan2018]) we argue it is adequate 779 for a large subclass of such applications. 781 * The reflexive interest, through either a name suffix or Interest 782 payload, can give the IoT device useful context from which to 783 craft its Data object in response. One highly useful parameter 784 would be a robust clock value for the device to use as a timestamp 785 of the data, possibly as part of its name to correctly place it in 786 a time seres of sensor readings. This substantially alleviates 787 the need for low-end devices to have a robust time base, as long 788 as they trust the producer they contact to provide it. 790 8. Implementation Considerations 792 There are a number of important aspects to the reflexive forwarding 793 design which affect correctness and performance of existing 794 forwarder, consumer, and producer implementations desiring to support 795 it. This section discusses the effect on each of these elements of 796 the CCNx/NDN protocol architecture. 798 8.1. Forwarder implementation considerations 800 8.1.1. Forwarding Information Base (FIB) 802 The FIB is a performance-critical data structure in any forwarder, as 803 it needs to support relatively expensive longest name prefix match 804 (LNPM) lookup algorithms. A number of well-known FIB data structures 805 are heavily optimized for read access, since for normal Interest 806 message processing the FIB changes slowly - only after topological 807 changes or routing protocol updates. Support for reflexive names 808 changes this, as FIB entries are created and destroyed rapidly as 809 Interest messages containing reflexive name TLVs are processed and 810 the corresponding Data messages come back. 812 While it may be feasible, especially in low-end forwarders handling a 813 low packet forwarding rate to ignore this problem, for high-speed 814 forwarders there are a number of hazards, including: 816 1. If the entire FIB needs to be locked in order to insert or remove 817 entries, this could cause inflated forwarding delays or in 818 extreme cases, forwarding performance collapse. 820 2. A number of high-speed forwarder implementations employ a sharded 821 PIT scheme to better parallelize forwarding across processing 822 cores. The FIB, however, is still a shared data structure which 823 is either read without read locks across cores, or explicitly 824 copied such that there is a separate copy of the FIB for each PIT 825 shard. Clearly, a high update rate without read locks and/or 826 updating many copies of the FIB are unattractive implementation 827 options. (Note: with this reflexive name scheme it is not 828 feasible to force reflexive interests to be hashed or be 829 otherwise directed to the PIT shard holding the original Interest 830 state). 832 There are any number of alternative FIB implementations that can work 833 well however. The most straightforward is to simply implement a 834 "special" FIB for just reflexive name lookups. This is feasible 835 because reflexive names deterministically contain the distinguished 836 high-order name component type of T_REFLEXIVE_NAME, whose content is 837 a 64-bit value that can be easily hashed to a FIB entry directly, 838 avoiding the more expensive LNPM lookup. Inserts and deletes then 839 devolve to the well-understood problem of hash table maintenance. 841 8.1.2. Interactions with Interest Lifetime 843 If and when a producer decides to fetch data from the consumer using 844 one or more reflexive Interest-Data exchanges, the total latency for 845 the original Interest-Data exchange is inflated, potentially by 846 multiple RTTs. It is difficult for a consumer to predict the 847 inflation factor when issuing the original Interest, and hence there 848 can be a substantial hazard of that Interest lifetime expiring before 849 completion of the full multi-way exchange. This can result in 850 persistent failures, which is obviously highly undesirable. 852 There is a fairly straightforward technique that can be employed by 853 forwarders to avoid these "false" Interest lifetime expirations. In 854 the absence of a superior alternative technique, it is RECOMMENDED 855 that all forwarders implement the following algorithm. 857 When processing an Interest containing the reflexive name TLV and 858 creating the necessary FIB entry (see Section 8.1.1 above), the 859 forwarder also creates a _back pointer_ from that FIB entry to the 860 PIT entry for the Interest message that created it. This PIT entry 861 contains the current value of the remaining Interest lifetime or 862 alternatively a value from which the remaining Interest lifetime can 863 be easily computed. Call this value _IL_(t)_. 865 If and when a reflexive Interest arrives from upstream matching the 866 reflexive FIB entry, the forwarder examines the Interest lifetime of 867 the arriving reflexive Interest. Call this value _IL_(r)_. The 868 forwarder computes MAX(_IL_(t), (IL_(r) * 1.5)_), and replaces 869 _IL_(t)_ with this value. This in effect ensures that the remaining 870 Interest lifetime of the original Interest accounts for the 871 additional 1.5 RTTs that may occur as a result of the reflexive 872 Interest-Data exchange. 874 If the above algorithm is implemented naively as described above, it 875 may run afoul of a sharded PIT forwarder implementation, since the 876 PIT entry for the reflexive Interest and the PIT entry for the 877 original Interest may be in different shards. Therefore, if the 878 update is done cross-shard on each reflexive Interest arrival, 879 performance may suffer, perhaps dramatically. Instead, the following 880 approach to updating the Interest lifetime after computing the new 881 value is RECOMMMENDED for sharded-PIT forwarders. 883 When creating the reflexive FIB entry as above in Section 8.1.1, copy 884 the remaining Interest lifetime from the PIT entry. Do the PIT 885 update if and only if this value is about to expire, thus paying the 886 cross-shard update cost only if the original Interest is about to 887 expire. A further optimization at the cost of modest extra 888 complexity is to instead _queue_ the update to the core holding the 889 shard of the original PIT entry rather than doing the update 890 directly. If the PIT entry expires or is satisfied, instead of 891 removing it the associated core checks the update queue and does the 892 necessary update. 894 While the above approach of inflating the interest lifetime of the 895 original Interest to accommodate the additional RTTs of reflexive 896 Interest-Data exchanges, this does introduce a new vulnerability that 897 must be dealt with. A Producer, either through a bug or malicious 898 intent, could keep an originating Interest-Data exchange alive by 899 continuing to send reflexive Interests back to the consumer, while 900 the consumer had no way to terminate the enclosing interaction (there 901 is no "cancel Interest" function in either NDN nor CCNx). To 902 eliminate this hazard, if the consumer rejects a reflexive interest 903 with a T_RETURN_PROHIBITED error, the forwarder(s), in addition to 904 satisfying the coresponding PIT entry, MUST also delete the 905 associated reflexive FIB entry, thereby preventing any further 906 reflexive Interests from reaching the consumer. This allows the 907 enclosing Interest-Datsa exchange to either time out or be correctly 908 ended with a Data message or Interest Return from the Producer. 910 8.1.3. Interactions with Interest aggregation 912 As with numerous other situations where multiple Interests for the 913 same named object arrive containing different parameters (e.g. 914 Interest Lifetime, QoS, payload hash) the same phenomenon occurs for 915 the reflexive Name TLV. If such Interests collide, the forwarder 916 MUST NOT aggregate these Interest messages and instead MUST create a 917 separate PIT entry for each. 919 8.2. Consumer Implementation Considerations 921 8.2.1. Data objects returned by the consumer to reflexive name 922 Interests arriving from a producer 924 The Data objects returned to the producer in response to a reflexive 925 Interest are normal CCNx/NDN data objects. It is therefore worth 926 noting that the object is bound to the reflexive Interest full name 927 via the hash and hence the scope of the object is under most 928 circumstances meaningful only for the duration of the enclosing 929 Interest-Data interaction. This property is ideal for naming and 930 securing data that is "part of" the enclosing interaction - things 931 like method arguments, authenticators, and key exchange parameters, 932 but not for the creation and naming of objects intended to survive 933 outside the current interaction's scope (c.f. Section 7.3, which 934 describes how to provide globally-named objects using encapsulation). 935 In general, the consumer should use the following guidelines in 936 creating Data messages in response to reflexive Interest messages 937 from the producer. 939 (a) Set the recommended cache time (T_CACHETIME) either to zero, or 940 a value no greater than the Interest lifetime (T_INTLIFE) of the 941 original Interest messsage. 943 (b) Set the payload type (T_PAYLDTYPE) according to the type of 944 object being returned (e.g. object, link, manifest) 946 (c) Set the expiry time (T_EXPIRY) to a value greater than _now_, 947 and less than or equal to the _now_ + Interest lifetime 948 (T_INTLIFE) of the original Interest messsage. 950 8.2.2. Terminating unwanted reflexive Interest exchanges 952 A consumer may wish to stop receiving reflxive Interests due to 953 possible erors or malicious behavior on the part of the producer. 954 Therefore, if the consumer receives an unwanted reflexive Interest, 955 it SHOULD reject that interest with a T_RETURN_PROHIBITED error. 956 This will provoke the forwarders to prevent further reflexive 957 Interests from reaching the consumer, as described above in 958 Section 8.1.2, Paragraph 7. 960 8.2.3. Interactions with caching 962 The reflexive named objects provide "local", temporary names that are 963 only defined for one specific interaction between a consumer and a 964 producer. Corresponding Data objects MUST NOT be shared between 965 multiple consumers (violating this would require specail gyrations by 966 the producer since the reflexive Name utilizes per-consumer/per- 967 interaction random values). A producer MUST NOT issue an Interest 968 message for any reflexive name after it has sent the final Data 969 message answering the original Interest. 971 Forwarders SHOULD still cache reflexive Data objects for 972 retransmissions within a transactions, but they MUST remove them from 973 the content store when they forward the final Data message answering 974 the original Interest. 976 8.3. Producer Implementation Considerations 978 Producers receiving an Interest with a Reflexive Name Component, MAY 979 decide to issue Interests for the corresponding Data objects. All 980 Reflexive Interest message that a producer sends MUST be sent over 981 the face that the original Interest was received on. 983 9. Operational Considerations 985 This extension represents a substantial enhancement to the CCNx/NDN 986 protocol architecture and hence has important forward and backward 987 compatibility effects. The most important of these is that correct 988 operation of the scheme requires an unbroken chain of forwarders 989 between the consumer and the desired producer that support the 990 Reflexive Name TLV and the corresponding forwarder capabilities 991 specified in Section 5. When this invariant is not satisfied, some 992 means is necessary to detect and hopefully recover from the error. 993 We have identified three possible approaches to handling the lack of 994 universal deployment of forwarders supporting the reflexive 995 forwarding scheme. 997 The first approach simply lets the producer detect the error by 998 getting a "no route to destination" error when trying to send an 999 Interest to a reflexive name. This will catch the error, but only 1000 after forwarding resources are tied up and the producer has done some 1001 work on the original Interest message. Further, the producer would 1002 need a bit of smarts to determine that this is a permanent error and 1003 not a transient to be retried. In order for the consumer to attempt 1004 recovery, there might be a need for some explicit error returned for 1005 the original interest to tell the consumer what the likely problem 1006 is. This approach does not enable an obvious recovery path for the 1007 consumer either, since while we might envision a way to steer a 1008 subsequent Interest onto a working path as proposed in 1009 [I-D.oran-icnrg-pathsteering], there is no capability to force 1010 Interest routing away from an otherwise working path not supporting 1011 the reflexive name TLV. 1013 A second approach is to bump the CCNx/NDN protocol version to 1014 explicitly indicate the lack of comparability. Such Interests would 1015 be rejected by forwarders not supporting this protocol extension. A 1016 consumer wishing to use the reflexive name TLV would use the higher 1017 protocol version on those Interest messages (but could of course 1018 continue to use the current version number on other Interest 1019 messages). This is a big hammer, but may be called for in this 1020 situation because: 1022 (a) it detects the problem immediately and deterministically, and 1024 (b) one could assume an ICN routing protocol that would only forward 1025 to a next hop that supports the updated protocol version number. 1026 The supported forwarder protocol versions would have been 1027 communicated in the routing protocol ahead of time. 1029 A third option is to, as a precondition utilizing the protocol in a 1030 deployment, create and deploy a neighbor capability exchange protocol 1031 which will tell a downstream forwarder if the upstream can handle the 1032 new TLV. This might avoid the large hammer of updating the protocol 1033 version, but of course this puts a pretty strong dependency on 1034 somebody actually designing and publishing such a protocol! On the 1035 other hand, a neighbor capability exchange protocol for CCNx/NDN 1036 would have a number of other substantial benefits, which makes it 1037 worth seriously considering anyway. 1039 10. Mapping to CCNx and NDN packet encodings 1041 10.1. Packet encoding for CCNx 1043 For CCNx[RFC8569] there is one new Name Component TLV type defined in 1044 this specification. 1046 +------------------+----------------+--------------------------+ 1047 | Abbrev | Name | Description | 1048 +==================+================+==========================+ 1049 | T_REFLEXIVE_NAME | Reflexive Name | Name component to use as | 1050 | | Component | name prefix in Reflexive | 1051 | | | Interest Message | 1052 +------------------+----------------+--------------------------+ 1054 Table 1: Reflexive Name TLV 1056 10.2. Packet encoding for NDN 1058 TBD based on [NDNTLV]. Suggestions from the NDN team greatly 1059 appreciated. 1061 11. IANA Considerations 1063 Please add the T_REFLEXIVE_NAME component TLV to the CCNx Name types 1064 TLV types registry of [RFC8609], with Length 9 bytes and type of 64 1065 bit random integer. 1067 1 2 3 1068 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 1069 +---------------+---------------+---------------+---------------+ 1070 | T_REFLEXIVE_NAME | 8 | 1071 +---------------+---------------+---------------+---------------+ 1072 | | 1073 | 64bit Integer randomly assigned by consumer | 1074 +-------------------------------+-------------------------------+ 1076 Figure 5: Reflexive Name component type 1078 12. Security Considerations 1080 One of the major motivations for the reflexive forwarding extension 1081 specified in this document is in fact to enable better security and 1082 privacy characteristics for ICN networks. The main considerations 1083 are presented in Section 1, but we briefly recapitulate them here: 1085 * Current approaches to authentication and data transfer often use 1086 payloads in Interest messages, which are clumsy to secure 1087 (Interest messages must be signed) and as a consequence make it 1088 very difficult to ensure consumer privacy. Reflexive forwarding 1089 moves all sensitive data to the Data messages sent in response to 1090 reflexive Interests, which are secured in the same manner as all 1091 other Data messages in the CCNx and NDN protocol designs. 1093 * In many scenarios, consumers are forced to also act as producers 1094 so that data may be fetched by either a particular, or arbitrary 1095 other party. The means the consumer must arrange to have a 1096 routable name prefix and that prefix be disseminated by the 1097 routing protocol or other means. This represents both a privacy 1098 hazard (by revealing possible important information about the 1099 consumer) and a security concern as it opens up the consumer to 1100 the full panoply of flooding and crafted Interest denial of 1101 service attacks. 1103 * In order to achieve multi-way handshakes, in current designs a 1104 consumer wishing a producer to communicate back must inform the 1105 producer of what (globally routable) name to use. This gives the 1106 consumer a convenient means to mount a variety of reflection 1107 attacks by enlisting the producer to send Interests to desired 1108 victims. 1110 As a major protocol extension however, this design brings its own 1111 potential security issues, which are discussed in the following 1112 subsections. 1114 12.1. Collisions of reflexive Interest names 1116 Reflexive Interest names are constructed using 64-bit random numbers. 1117 This is intended to ensure an off-path attacker cannot easily 1118 manufacture a matching reflexive Interest and either masquerade as 1119 the producer, or mount a denial of service attack on the consumer. 1120 It also limits tracking through the linkability of Interests 1121 containing a re-used random value. 1123 Therefore consumers MUST utilize a robust means of generating these 1124 random values, and it is RECOMMENDED that a pseudo-random number 1125 generator (PRNG) approved for use with cryptographic protocols be 1126 employed. 1128 12.2. Additional resource pressure on PIT and FIB 1130 Normal Interest message processing in CCNx and NDN needs to consider 1131 effect of various resource depletion attacks on the PIT, particularly 1132 in the form of Interest flooding attacks (see [Gasti2012] for a good 1133 overview of DoS and DDoS mitigation on ICN networks). Interest 1134 messages utilizing this reflexive forwarding extension can place 1135 additional resource pressure on the PIT, and additionally cause 1136 otherwise stable FIB resources to be subject to highly dynamic usage. 1138 While this does not represent a new DoS/DDoS attack vector, the 1139 ability of a malicious consumer to utilize this extension in an 1140 attack does represent an increased risk of resource depletion, 1141 especially if such Interests are given unfair access to PIT and FIB 1142 resources. Implementers SHOULD therefore protect PIT and FIB 1143 resources by weighing requests for reflexive forwarding resources 1144 appropriately relative to other Interests. 1146 12.3. Privacy Considerations 1148 ICN architectures like CCNx and NDN provide a rich tapestry of 1149 interesting privacy issues, which have been extensively explored in 1150 the research literature. The fundamental tradeoffs for privacy 1151 concern the risk of exposing the names of information objects to the 1152 forwarding elements of the network, which is a necessary property of 1153 any name-based routing and forwarding design. Numerous approaches 1154 have been explored with varying degrees of success, such as onion 1155 routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), and name 1156 obfuscation ([Arianfar2011]) among others. 1158 Reflexive forwarding does not change the overall landscape of privacy 1159 tradeoffs, nor seem to introduce additional hazards. In fact, the 1160 privacy exposures are confined to the inverse path of forwarders from 1161 the producer to the consumer, through which the original Interest 1162 forwarding may have already exposed names on path. Similar name 1163 privacy techniques to those cited above may be equally applied to the 1164 names in reflexive Interests. 1166 While the individual reflexive Interest-Data exchanges have similar 1167 properties to those in any NDN or CCNx exchange, the target usages by 1168 applications may have interaction patterns that are subject to 1169 relatively straightforward fingerprinting by adversaries. For 1170 example, a particular RMI invocation may fingerprint simply through 1171 the count of arguments fetched by the producer and their sizes. The 1172 attacker must however be on path, which somewhat ameliorates the 1173 exposure hazards. 1175 13. Normative References 1177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1178 Requirement Levels", BCP 14, RFC 2119, 1179 DOI 10.17487/RFC2119, March 1997, 1180 . 1182 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1183 Networking (CCNx) Semantics", RFC 8569, 1184 DOI 10.17487/RFC8569, July 2019, 1185 . 1187 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1188 Networking (CCNx) Messages in TLV Format", RFC 8609, 1189 DOI 10.17487/RFC8609, July 2019, 1190 . 1192 14. Informative References 1194 [Arianfar2011] 1195 Arianfar, S., Koponen, T., Raghavan, B., and S. Shenker, 1196 "On preserving privacy in content-oriented networks, in 1197 ICN '11: Proceedings of the ACM SIGCOMM workshop on 1198 Information-centric networking", 1199 DOI https://doi.org/10.1145/2018584.2018589, August 2011, 1200 . 1202 [Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., 1203 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less 1204 Producer Mobility in Content-Centric Networks, in IEEE 1205 Transactions on Network, Volume 15, Issue 2", 1206 DOI 10.1109/TNSM.2018.2796720, June 2018, 1207 . 1209 [Baccelli2014] 1210 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 1211 Wählisch, "Information centric networking in the IoT: 1212 experiments with NDN in the wild, in ACM-ICN '14: 1213 Proceedings of the 1st ACM Conference on Information- 1214 Centric Networking", DOI 10.1145/2660129.2660144, 1215 September 2014, 1216 . 1218 [Carzaniga2011] 1219 Carzaniga, A., Papalini, M., and A.L. Wolf, "Content-Based 1220 Publish/Subscribe Networking and Information-Centric 1221 Networking", DOI 10.1145/2018584.2018599, September 2011, 1222 . 1225 [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDSS: A Named Data Storage 1226 System, in International Conference on Cloud and Autonomic 1227 Computing", DOI 10.1109/ICCAC.2015.12, September 2014, 1228 . 1230 [DiBenedettoGTU12] 1231 DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzun, 1232 "ANDaNA: Anonymous Named Data Networking Application, in 1233 NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2, 2102, 1234 . 1237 [Gasti2012] 1238 Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang, "DoS 1239 and DDoS in Named Data Networking, in 22nd International 1240 Conference on Computer Communication and Networks 1241 (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August 2013, 1242 . 1244 [Ghali2017] 1245 Tsudik, G., Ghali, C., and C. Wood, "When encryption is 1246 not enough: privacy attacks in content-centric networking, 1247 in ICN '17: Proceedings of the 4th ACM Conference on 1248 Information-Centric Networking", 1249 DOI https://doi.org/10.1145/3125719.3125723, September 1250 2017, 1251 . 1253 [Gundogan2018] 1254 Gündoğan, C., Kietzmann, P., Schmidt, T., and M. Wählisch, 1255 "HoPP: publish-subscribe for the constrained IoT, in ICN 1256 '18: Proceedings of the 5th ACM Conference on Information- 1257 Centric Networking", DOI 10.1145/3267955.3269020, 1258 September 2018, 1259 . 1261 [I-D.irtf-icnrg-flic] 1262 Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like 1263 ICN Collections (FLIC)", Work in Progress, Internet-Draft, 1264 draft-irtf-icnrg-flic-02, 4 November 2019, 1265 . 1267 [I-D.irtf-icnrg-terminology] 1268 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 1269 D., and C. Tschudin, "Information-Centric Networking 1270 (ICN): CCNx and NDN Terminology", Work in Progress, 1271 Internet-Draft, draft-irtf-icnrg-terminology-08, 17 1272 January 2020, . 1275 [I-D.oran-icnrg-pathsteering] 1276 Moiseenko, I. and D. Oran, "Path Steering in CCNx and 1277 NDN", Work in Progress, Internet-Draft, draft-oran-icnrg- 1278 pathsteering-00, 21 October 2019, 1279 . 1282 [Krol2018] Krol, M., Habak, K., Oran, D., Kutscher, D., and I. 1283 Psaras, "RICE: Remote Method Invocation in ICN, in 1284 Proceedings of the 5th ACM Conference on Information- 1285 Centric Networking - ICN '18", 1286 DOI 10.1145/3267955.3267956, September 2018, 1287 . 1290 [Lindgren2016] 1291 Lindgren, A., Ben Abdessiem, F., Ahlgren, B., Schlelén, 1292 O., and A.M. Malik, "Design choices for the IoT in 1293 Information-Centric Networks, in 13th IEEE Annual Consumer 1294 Communications and Networking Conference (CCNC)", 1295 DOI 10.1109/CCNC.2016.7444905, January 2016, 1296 . 1298 [Moiseenko2014] 1299 Moiseenko, I., Stapp, M., and D. Oran, "Communication 1300 patterns for web interaction in named data networking", 1301 DOI 10.1145/2660129.2660152, September 2014, 1302 . 1304 [Mosko2017] 1305 Mosko, M., "CCNx 1.0 Bidirectional Streams", 1306 arXiv 1707.04738, July 2017, 1307 . 1309 [NDN] "Named Data Networking", 2020, 1310 . 1312 [NDNTLV] "NDN Packet Format Specification", 2016, 1313 . 1315 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1316 A., Peterson, J., Sparks, R., Handley, M., and E. 1317 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1318 DOI 10.17487/RFC3261, June 2002, 1319 . 1321 [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session 1322 Initiation Protocol (SIP) Usage of the Offer/Answer 1323 Model", RFC 6337, DOI 10.17487/RFC6337, August 2011, 1324 . 1326 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 1327 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 1328 March 2015, . 1330 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1331 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1332 . 1334 [Zhang2018] 1335 Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang, "KITE: 1336 Producer Mobility Support in Named Data Networking, in 1337 Proceedings of the 5th ACM Conference on Information- 1338 Centric Networking - ICN '18", 1339 DOI 10.1145/3267955.3267959, September 2018, 1340 . 1343 Authors' Addresses 1345 Dave Oran 1346 Network Systems Research and Design 1347 4 Shady Hill Square 1348 Cambridge, MA 02138 1349 United States of America 1351 Email: daveoran@orandom.net 1353 Dirk Kutscher 1354 University of Applied Sciences Emden/Leer 1355 Constantiapl. 4 1356 26723 Emden 1357 Germany 1359 Email: ietf@dkutscher.net 1360 URI: https://dirk-kutscher.info