idnits 2.17.1 draft-oran-icnrg-pathsteering-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 November 2021) is 893 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 (-12) exists of draft-irtf-icnrg-icnping-02 == Outdated reference: A later version (-11) exists of draft-irtf-icnrg-icntraceroute-02 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 I. Moiseenko 3 Internet-Draft UCLA 4 Intended status: Experimental D. Oran 5 Expires: 12 May 2022 Network Systems Research and Design 6 8 November 2021 8 Path Steering in CCNx and NDN 9 draft-oran-icnrg-pathsteering-05 11 Abstract 13 Path Steering is a mechanism to discover paths to the producers of 14 ICN content objects and steer subsequent Interest messages along a 15 previously discovered path. It has various uses, including the 16 operation of state-of-the-art multipath congestion control algorithms 17 and for network measurement and management. This specification 18 derives directly from the design published in _Path Switching in 19 Content Centric and Named Data Networks_ (4th ACM Conference on 20 Information-Centric Networking - ICN'17) and therefore does not 21 recapitulate the design motivations, implementation details, or 22 evaluation of the scheme. Some technical details are different 23 however, and where there are differences, the design documented here 24 is to be considered definitive. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 12 May 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Path Steering as an experimental extension to ICN protocol 58 architectures . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Essential elements of ICN path discovery and path steering . 4 62 2.1. Path Discovery . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Path Steering . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Handling Path Steering errors . . . . . . . . . . . . . . 7 65 2.4. How to represent the Path Label . . . . . . . . . . . . . 8 66 3. Mapping to CCNx and NDN packet encodings . . . . . . . . . . 9 67 3.1. Path label TLV . . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Path label encoding for CCNx . . . . . . . . . . . . . . 10 69 3.3. Path label encoding for NDN . . . . . . . . . . . . . . . 11 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 5.1. Cryptographic protection of a path label . . . . . . . . 14 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 6.2. Informative References . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 Path Steering is a mechanism to discover paths to the producers of 81 ICN content objects and steer subsequent Interest messages along a 82 previously discovered path. It has various uses, including the 83 operation of state-of-the-art multipath congestion control algorithms 84 and for network measurement and management. This specification 85 derives directly from the design published in [Moiseenko2017] and 86 therefore does not recapitulate the design motivations, 87 implementation details, or evaluation of the scheme. That 88 publication should be considered a normative reference as it is not 89 likely a reader will be able to understand all elements of this 90 design without first having read the reference. Some technical 91 details are different however, and where there are differences, the 92 design documented here is to be considered definitive. 94 Path discovery and subsequent path steering in ICN networks is 95 facilitated by the symmetry of forward and reverse paths in the CCNx 96 and NDN architectures. Path discovery is achieved by a consumer 97 endpoint transmitting an ordinary Interest message and receiving a 98 Content (Data) message containing an end-to-end path label 99 constructed on the reverse path by the forwarding plane. Path 100 steering is achieved by a consumer endpoint including a path label in 101 the Interest message, which is forwarded to each nexthop through the 102 corresponding egress interfaces in conjunction with longest name 103 prefix match (LNPM) FIB lookup. 105 1.1. Path Steering as an experimental extension to ICN protocol 106 architectures 108 There are a number of important use cases to justify extending ICN 109 architectures such as CCNx [RFC8569] or NDN [NDN] to provide these 110 capabilities. These are summarized as follows: 112 * Support the discovery, monitoring and troubleshooting of multi- 113 path network connectivity based on names and name prefixes. 114 Analogous functions have been shown to be a crucial operational 115 capability in multicast and multi-path topologies for IP. The 116 canonical tools are the well-known _traceroute_ and _ping_. For 117 point-to-multipoint MPLS the more recent tree trace [RFC8029] 118 protocol is used. Equivalent diagnostic functions have been 119 defined for CCNx through the ICN Ping [I-D.irtf-icnrg-icnping] and 120 ICN Traceroute [I-D.irtf-icnrg-icntraceroute] specifications, both 121 of which are capable of exploiting path steering if available. 123 * Perform accurate online measurement of network performance, which 124 generally requires multiple consecutive packets follow the same 125 path under control of an application. 127 * Improve the performance and flexibility of multi-path congestion 128 control algorithms. Congestion control schemes such as 129 [Mahdian2016] and [Song2018] depend on the ability of a consumer 130 to explicitly steer packets onto individual paths in a multi-path 131 and/or multi-destination topology. 133 * A consumer endpoint can mitigate content poisoning attacks by 134 directing its Interests onto the network paths that bypass 135 poisoned caches. 137 1.2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 1.3. Terminology 145 This document uses the general ICN terms that are defined in 146 [RFC8793]. In addition we define the following terms specific to 147 path steering: 149 Path Discovery: The process of sending an Interest requesting 150 discover of a path and if successful, receiving a Data containing 151 a Path Label for the path the corresponding Interest traversed 153 Path Steering: The process of sending an Interest message containing 154 the Path Label of a previously discovered path in roder that the 155 forwarders use that path when forwarding that particular Interest 156 message. 158 Path Label: An optional field in the packet indicating a particular 159 path from a consumer to either a producer, or a forwarder cache 160 that can respond with the requested item. In an Interest message, 161 the Path Label gets built up hop by hop as the interest traverses 162 a path. In a Data message, the Path Label carries the full path 163 information back to the consumer for use in one or more subsequent 164 Interest messages. 166 Nexthop Label: One entry in a Path Label representing the next hop 167 for the corresponding forwarder to use when a path-steered 168 Interest message arrives at that forwarder. A sequence of Nexthop 169 Labels constitutes a full Path Label. 171 2. Essential elements of ICN path discovery and path steering 173 We elucidate the design using CCNx semantics [RFC8569] and extend its 174 Packet Encoding [RFC8609] as defined in Section 3.2. While the 175 terminology is slightly different, this design can be applied also to 176 NDN, by extending its bespoke packet encodings [NDNTLV] (See 177 Section 3.3). 179 2.1. Path Discovery 181 _End-to-end Path Discovery_ for CCNx is achieved by creating a _path 182 label_ and placing it as a hop-by-hop TLV in a CCNx Content (Data) 183 message. The path label is constructed hop-by-hop as the message 184 traverses the reverse path of transit CCNx forwarders as shown in the 185 first example in Figure 1. The path label is updated by adding to 186 the existing path label the nexthop label of the interface at which 187 the Content (Data) message has arrived. Eventually, when the 188 Content(Data) message arrives at the consumer, the path label 189 identifies the complete path the Content (Data) message took to reach 190 the consumer. As shown in the second example in the figure, when 191 multiple paths are available, subsequent interests can discover 192 additional paths by omitting a path steering TLV and obtaining a new 193 path label on the returning interest. 195 Discover and use first path: 197 Consumer Interest 1 ___ Interest 2 198 | | ^ | 199 | | | | 200 | | | | 201 Forwarder 1 v | V 202 | (nexthop 1) (nexthop 1) ^ (nexthop 1) 203 | | | | 204 | | | | 205 Forwarder 2 v | v 206 (nexthop 3) / \ (nexthop 2) (nexthop 2) ^ (nexthop 2) 207 / \ | | | 208 / \ | | | 209 / \ | | | 210 / \ | | | 211 / \ | | | 212 Forwarder 4 Forwarder 3 v | v 213 (nexthop 5)\ / (nexthop 4) (nexthop 4) ^ (nexthop 4) 214 \ / | | | 215 \ / | | | 216 \ / | | | 217 \ / | | | 218 \ / | | | 219 \ / v | v 220 Producer ___ Data 1 ___ 221 or 222 Content Store 224 Discover and use second path: 226 Consumer Interest 3 ___ Interest 4 227 | | ^ | 228 | | | | 229 | | | | 230 Forwarder 1 v | V 231 | (nexthop 1) (nexthop 1) ^ (nexthop 1) 232 | | | | 233 | | | | 234 Forwarder 2 v | v 235 (nexthop 3) / \ (nexthop 2) (nexthop 3) ^ (nexthop 3) 236 / \ | | | 237 / \ | | | 238 / \ | | | 239 / \ | | | 240 / \ | | | 241 Forwarder 4 Forwarder 3 v | v 242 (nexthop 5)\ / (nexthop 4) (nexthop 5) ^ (nexthop 5) 243 \ / | | | 244 \ / | | | 245 \ / | | | 246 \ / | | | 247 \ / | | | 248 \ / v | v 249 Producer ___ Data 2 ___ 250 or 251 Content Store 253 Figure 1: Basic example of path discovery and steering 255 2.2. Path Steering 257 Due to the symmetry of forward and reverse paths in CCNx, a consumer 258 application can reuse a discovered path label to fetch the same or 259 similar (e.g. next chunk, or next Application Data Unit, or next 260 pointer in a Manifest [I-D.irtf-icnrg-flic]) Content (Data) message 261 over the discovered network path. This _Path Steering_ is achieved 262 by processing the Interest message's path label at each transit ICN 263 forwarder and forwarding the Interest through the specified nexthop 264 among those identified as feasible by LNPM FIB lookup (Figure 2). 266 ------------------------------------------------------------------------ 267 FORWARD PATH 268 ------------------------------------------------------------------------ 270 Interest +---------+ +-----+ (path label) +--------+ (match) Interest 271 -------->| Content |->| PIT | ------------>| Label |----------------> 272 | Store | +-----+ | Lookup | 273 +---------+ | \ (no path label) +--------+ 274 | | \ |\ (path label mismatch) 275 Data | | \ | \ 276 <---------+ v \ | \ 277 aggregate \ | \ 278 \ | \ 279 \ | +-----+ Interest 280 +--------------|---->| FIB | ---------> 281 | +-----+ 282 Interest-Return (NACK) v | (no route) 283 <----------------------------------------------+<-------+ 285 ------------------------------------------------------------------------ 286 REVERSE PATH 287 ------------------------------------------------------------------------ 289 Interest-return(NACK) +-----+ (update path label) Interest-Return(NACK) 290 <---------------------| |<----------------------------------------- 291 | | 292 Data +---------+ | PIT | (update path label) Data 293 <------| Content |<---| |<----------------------------------------- 294 | Store | | | 295 +---------+ +-----+ 296 | 297 | (no match) 298 v 300 Figure 2: Path Steering CCN / NDN data plane 302 2.3. Handling Path Steering errors 304 Over time, the state of interfaces and the FIB on forwarders may 305 change such that, at any particular forwarder, a given nexthop is no 306 longer valid for a given prefix. In this case, the path label will 307 point to a now-invalid nexthop. This is detected by failure to find 308 a match between the decoded nexthop ID and the nexthops of the FIB 309 entry after LNPM FIB lookup. 311 On detecting an invalid path label, the forwarder SHOULD respond to 312 the Interest with an Interest-Return. We therefore define a new 313 _Invalid path label_ response code for the Interest Return message 314 and include the current path label as a hop-by-hop header. Each 315 transit forwarder processing the Interest-Return message updates the 316 path label in the same manner as Content (Data) messages, so that the 317 consumer receiving the Interest-Return (NACK) can easily identify 318 which path label is no longer valid. 320 A consumer may alternatively request that a forwarder detecting the 321 inconsistency forward the Interest by means of normal LNPM FIB lookup 322 rather than returning an error. The consumer endpoint, if it cares, 323 can keep enough information about outstanding Interests to determine 324 if the path label sent with the Interest fails to match the path 325 label in the corresponding returned Content (Data), and use that 326 information to replace stale path labels. It does so by setting the 327 FALLBACK MODE flag of the path label TLV in its Interest message. 329 2.4. How to represent the Path Label 331 [Moiseenko2017] presents various options for how to represent a path 332 label, with different tradeoffs in flexibility, performance and space 333 efficiency. For this specification, we choose the _Polynomial 334 encoding_ which achieves reasonable space efficiency at the cost of 335 establishing a hard limit on the length of paths that can be 336 represented. 338 The polynomial encoding utilizes a fixed-size bit array. Each 339 transit ICN forwarder is allocated a fixed sized portion of the bit 340 array. This design allocates 12 bits (i.e. 4095 as a _generator 341 polynomial_) to each intermediate ICN forwarder. This should match 342 the scalability of today's commercial routers that support up to 4096 343 physical and logical interfaces and usually do not have more than a 344 few hundred active ones. 346 +------------------------------------------------------------------+ 347 | Path Label bitmap | 348 +----------+-----------------+-----------------+-------------------+ 349 | index | nexthop label | nexthop label | | 350 +----------+-----------------+-----------------+-------------------+ 351 |<- 8bit ->|<---- 12bit ---->|<---- 12bit ---->|<----------------->| 353 Figure 3: Fixed size path label 355 A forwarder that receives a Content (Data) message encodes the 356 nexthop label in the next available slot and increments label index. 357 Conversely, a forwarder that receives an Interest message reads the 358 current nexthop label and decrements label index. Therefore, the 359 extra computation required at each hop to forward either an interest 360 or Content Object message with a path label is minimized and 361 constitutes a fairly trivial additional overhead compared to FIB 362 lookup and other required operations. 364 This approach results in individual path label TLV instances being of 365 fixed pre-computed size. While this places a hard upper bound on the 366 maximum number of network hops that can be represented, this is not a 367 significant a practical problem in NDN and CCNx, since the size can 368 be pre-set during Content(Data) message encoding based on the exact 369 number of network hops traversed by the Interest message. Even long 370 paths of 24 hops will fit in a path label bitmap of 36 bytes if 371 nexthop label is encoded in 12 bits. 373 3. Mapping to CCNx and NDN packet encodings 375 3.1. Path label TLV 377 A Path label TLV is the tuple: {[Flags], [Path Label Hop Count], 378 [Nexthop Label], [Path label bitmap]}. 380 +================+=============+ 381 | Flag | Value (hex) | 382 +================+=============+ 383 | DISCOVERY MODE | 0x00 | 384 +----------------+-------------+ 385 | FALLBACK MODE | 0x01 | 386 +----------------+-------------+ 387 | STRICT MODE | 0x02 | 388 +----------------+-------------+ 390 Table 1: Path label flags 392 The Path Label Hop Count (PLHC) MUST be incremented by NDN and CCNx 393 forwarders if the Interest packet carries a path label and DISCOVERY 394 mode flag is set. A producer node or a forwarder with cached data 395 packet MUST use PLHC in calculation of a path label bitmap size 396 suitable for encoding the entire path to the consumer. The Path 397 Label Hop Count (PLHC) MUST be set to zero in newly created Data or 398 Interest-Return (NACK) packets. A consumer node MUST reuse Path 399 Label Hop Count (PLHC) together with the Path label bitmap (PLB) in 400 order to correctly forward the Interest(s) along the corresponding 401 network path. 403 If an NDN or CCNx forwarder supports path labeling, the Nexthop label 404 MUST be used to determine the correct egress interface for an 405 Interest packet carrying either the FALLBACK MODE or STRICT MODE 406 flag. If any particular NDN or CCNx forwarder is configured to 407 decrypt path labels of Interest packets (Section "Security 408 considerations" (Section 5)), then the forwarder MUST 410 1. decrypt the path label with its own symmetric key, 412 2. update the nexthop label with outermost label in the path label, 414 3. decrement Path Label Hop Count (PLHC), and 416 4. remove the outermost label from the path label. 418 If any particular NDN or CCNx forwarder is NOT configured to decrypt 419 path labels of Interest packets, then path label decryption SHOULD 420 NOT be performed. 422 The Nexthop label MUST be ignored by NDN and CCNx forwarders if 423 present in Data or Interest-Return (NACK) packets. If any particular 424 NDN or CCNx forwarder is configured to encrypt path labels of Data 425 and Interest-Return (NACK) packets (Section Security Considerations 426 (Section 5)), then the forwarder MUST encrypt existing path label 427 with its own symmetric key, append the nexthop label of the ingress 428 interface to the path label, and increment Path Label Hop Count 429 (PLHC). If any particular NDN or CCNx forwarder is NOT configured to 430 encrypt path labels of Interest packets, then path label encryption 431 SHOULD NOT be performed. 433 NDN and CCNx forwarders MUST fallback to longest name prefix match 434 (LNPM) FIB lookup if an Interest packet carries an invalid nexthop 435 label and the FALLBACK MODE flag is set. 437 CCNx forwarders MUST respond with an Interest Return packet 438 specifying the T_RETURN_INVALID_PATH_LABEL code if Interest packet 439 carries an invalid path label and the STRICT MODE flag is set. 441 CCNx forwarders MUST respond with an Interest Return packet 442 specifying the T_RETURN_MALFORMED_INTEREST code if the Interest 443 packet carries a path label TLV with both FALLBACK MODE and STRICT 444 MODE flags set. 446 3.2. Path label encoding for CCNx 448 Path Label is an optional Hop-by-Hop header TLV that can be present 449 in CCNx Interest, InterestReturn and Content Object packets. 451 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 452 +---------------+---------------+---------------+---------------+ 453 | T_PATH_LABEL | Length + 4 | 454 +---------------+---------------+---------------+---------------+ 455 | Flags | Path Label | Nexthop Label | 456 | | Hop Count | | 457 +---------------+---------------+---------------+---------------+ 458 / / 459 / Path label bitmap (Length octets) / 460 / / 461 +---------------+---------------+---------------+---------------+ 463 Figure 4: Path label Hop-by-Hop header TLV for CCNx 465 3.3. Path label encoding for NDN 467 Path Label is an optional TLV in NDN Interest, Data and NACK packets. 468 The Path Label TLV SHOULD NOT take part in Interest, Data or NACK 469 signature calculation as it is potentially modified at every network 470 hop. 472 PathLabel = PATH-LABEL-TYPE TLV-LENGTH 473 PathLabelFlags 474 PathLabelBitmap 476 PathLabelFlags = PATH-LABEL-FLAGS-TYPE 477 TLV-LENGTH ; == 1 478 OCTET 480 NexthopLabel = PATH-LABEL-NEXTHOP-LABEL-TYPE 481 TLV-LENGTH ; == 2 482 2 OCTET 484 PathLabelHopCount = PATH-LABEL-HOP-COUNT-TYPE 485 TLV-LENGTH ; == 1 486 OCTET 488 PathLabelBitmap = PATH-LABEL-BITMAP-TYPE 489 TLV-LENGTH ; == 64 490 64 OCTET 492 Figure 5: Path label TLV for NDN 494 +===============================+=============+ 495 | Flag | Value (hex) | 496 +===============================+=============+ 497 | PATH-LABEL-TYPE | 0x09 | 498 +-------------------------------+-------------+ 499 | PATH-LABEL-FLAGS-TYPE | 0x0B | 500 +-------------------------------+-------------+ 501 | PATH-LABEL-BITMAP-TYPE | 0x0D | 502 +-------------------------------+-------------+ 503 | PATH-LABEL-NEXTHOP-LABEL-TYPE | 0x0E | 504 +-------------------------------+-------------+ 505 | PATH-LABEL-HOP-COUNT-TYPE | 0x0F | 506 +-------------------------------+-------------+ 508 Table 2: TLV-TYPE number assignments 510 4. IANA Considerations 512 IANA is requested to make the following assignments: 514 1. Please assign the value 0x0004 for T_PATH_LABEL in the *CCNx Hop- 515 by-Hop Types* registry. 517 2. Please assign the TLV types in Table 2 in the *CCNx Hop-by-Hop 518 type registry*. 520 3. Please assign the value 0xA for the T_RETURN_INVALID_PATH_LABEL 521 in the *CCNx Interest Return Code Types" registry*. 523 4. Please create the *CCNx Path Label Flags* registry and assign the 524 values listed in Table 1. 526 5. Security Considerations 528 A path is invalidated by renumbering nexthop label(s). A malicious 529 consumer can attempt to mount an attack by transmitting Interests 530 with path labels which differ only in a single now-invalid nexthop 531 label in order to _brute force_ a valid nexthop label. If such an 532 attack succeeds, a malicious consumer would be capable of steering 533 Interests over a network path that may not match the paths computed 534 by the routing algorithm or learned adaptively by the forwarders. 536 When a label lookup fails, by default an _Invalid path label_ 537 Interest-Return (NACK) message is returned to the consumer. This 538 contains a path label identical to the one included in the 539 corresponding Interest message. A malicious consumer can therefore 540 analyze the message's Hop Count field to infer which specific nexthop 541 label had failed and direct an attack to influence path steering at 542 that hop. This threat can be mitigated by the following 543 countermeasures: 545 * A nexthop label of larger size is harder to crack. If nexthop 546 labels are not allocated in a predictable fashion by the routers, 547 brute forcing a 32-bit nexthop label requires on average O(2^31) 548 Interests. However, this specification uses nexthop labels with 549 much less entropy (12 bits), so depending on computational 550 hardness is not workable. 552 * An ICN forwarder can periodically update nexthop labels to limit 553 the maximum lifetime of paths. It is RECOMMENDED that forwarders 554 update path labels at least every few minutes. 556 * A void Hop Count field in an _Invalid path label_ Interest-Return 557 (NACK) message would not give out the information on which 558 specific nexthop label had failed. An attacker might need to 559 brute force all nexthop labels in all combinations. However, some 560 useful diagnostic capability is lost by obscuring the hop count. 561 For example the locus of routing churn is harder to pin down 562 through analysis of path-steered pings or traceroutes. A 563 forwarder MAY choose to invalidate the hop count in addition to 564 changing nexthop labels periodically as above. 566 ICN protocols can be susceptible to a variety of cache poisoning 567 attacks, where a colluding consumer and producer arrange for bogus 568 content (with either invalid or inappropriate signatures) to populate 569 forwarder caches. These are generally confined to on-path attacks. 570 It is also theoretically possible to launch a similar attack without 571 a cooperating producer such that the caches of on-path routers become 572 poisoned with the content from off-path routers (i.e. physical 573 connectivity, but no route in a FIB for a given prefix). We estimate 574 that without any prior knowledge of the network topology, the 575 complexity of this type of attack is in the ballpark of Breadth- 576 First-Search and Depth-First-Search algorithms with the additional 577 burden of transmitting 2^31 Interests in order to crack a nexthop 578 label on each hop. Relatively short periodic update of nexthop 579 labels and anti- _label scan_ heuristics implemented in the ICN 580 forwarder may successfully mitigate this type of attack. 582 5.1. Cryptographic protection of a path label 584 If the countermeasures listed above do not provide sufficient 585 protection against malicious mis-steering of Interests, the path 586 label can be made opaque to the consumer endpoint via hop-by-hop 587 symmetric cryptography applied to the path labels (Figure 6). This 588 method is viable due to the symmetry of forward and reverse paths in 589 CCNx and NDN architectures combined with ICN path steering requiring 590 only reads/writes of the topmost nexthop label (i.e. active nexthop 591 label) in the path label. This way a path steering capable ICN 592 forwarder receiving a Data (Content) message encrypts the current 593 path label with its own non-shared symmetric key prior to adding a 594 new nexthop label to the path label. The Data (Content) message is 595 forwarded downstream with unencrypted topmost (i.e active) nexthop 596 label and encrypted remaining content of the path label. As a 597 result, a consumer endpoint receives a Data (Content) message with a 598 unique path label exposing only the topmost nexthop label as 599 cleartext. A path steering forwarder receiving an Interest message 600 performs label lookup using the topmost nexthop label, decrypts the 601 path label with its own non-shared symmetric key, and forwards the 602 message upstream. 604 Cryptographic protection of a path label does not require any key 605 negotiation among ICN forwarders, and is no more expensive than 606 MACsec or IPsec. It is also quite possible that strict hop-by-hop 607 path label encryption is not necessary and path label encryption only 608 on the border routers of the trusted administrative or routing 609 domains may suffice. 611 Producer 612 | ^ 613 | | 614 Path Label TLV | | Path Label TLV 615 +-----------------------+ | | +-----------------------+ 616 |nexthop label=456 | v | |nexthop label=456 | 617 |encrypted path label={}| Forwarder 3 |encrypted path label={}| 618 +-----------------------+ | ^ +-----------------------+ 619 | | 620 path label is encrypted | | path label is decrypted 621 with Forwarder 3 | | with Forwarder 3 622 symmetric key | | symmetric key 623 | | 624 | | 625 | | 626 | | 627 | | 628 Path Label TLV | | Path Label TLV 629 +-----------------------+ | | +-----------------------+ 630 |nexthop label=634 | v | |nexthop label=634 | 631 |encrypted path label= | Forwarder 2 |encrypted path label= | 632 | {456} | | ^ | {456} | 633 +-----------------------+ | | +-----------------------+ 634 | | 635 path label is encrypted | | path label is decrypted 636 with Forwarder 2 | | with Forwarder 2 637 symmetric key | | symmetric key 638 | | 639 | | 640 | | 641 | | 642 | | 643 Path Label TLV | | Path Label TLV 644 +-----------------------+ | | +-----------------------+ 645 |nexthop label=912 | v | |nexthop label=912 | 646 |encrypted path label= | Forwarder 1 |encrypted path label= | 647 | {634, encrypted path | | ^ | {634, encrypted path | 648 | label {456}} | | | | label {456}} | 649 +-----------------------+ | | +-----------------------+ 650 | | 651 path label is encrypted | | path label is decrypted 652 with Forwarder 1 | | with Forwarder 1 653 symmetric key | | symmetric key 654 | | 655 | | 656 | | 657 | | 658 v | 659 Consumer 661 Figure 6: Path label protection with hop-by-hop symmetric 662 cryptography 664 6. References 666 6.1. Normative References 668 [Moiseenko2017] 669 Moiseenko, I. and D. Oran, "Path Switching in Content 670 Centric and Named Data Networks, in 4th ACM Conference on 671 Information-Centric Networking (ICN 2017)", 672 DOI 10.1145/3125719.3125721, September 2017, 673 . 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679 . 681 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 682 Networking (CCNx) Semantics", RFC 8569, 683 DOI 10.17487/RFC8569, July 2019, 684 . 686 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 687 Networking (CCNx) Messages in TLV Format", RFC 8609, 688 DOI 10.17487/RFC8609, July 2019, 689 . 691 6.2. Informative References 693 [I-D.irtf-icnrg-flic] 694 Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, "File- 695 Like ICN Collections (FLIC)", Work in Progress, Internet- 696 Draft, draft-irtf-icnrg-flic-02, 4 November 2019, 697 . 700 [I-D.irtf-icnrg-icnping] 701 Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 702 D. Oran, "ICN Ping Protocol Specification", Work in 703 Progress, Internet-Draft, draft-irtf-icnrg-icnping-02, 11 704 April 2021, . 707 [I-D.irtf-icnrg-icntraceroute] 708 Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 709 D. Oran, "ICN Traceroute Protocol Specification", Work in 710 Progress, Internet-Draft, draft-irtf-icnrg-icntraceroute- 711 02, 11 April 2021, . 714 [Mahdian2016] 715 Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, 716 "MIRCC: Multipath-aware ICN Rate-based Congestion Control, 717 in Proceedings of the 3rd ACM Conference on Information- 718 Centric Networking", DOI 10.1145/2984356.2984365, 2016, 719 . 722 [NDN] "Named Data Networking", various, 723 . 725 [NDNTLV] "NDN Packet Format Specification.", 2016, 726 . 728 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 729 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 730 Switched (MPLS) Data-Plane Failures", RFC 8029, 731 DOI 10.17487/RFC8029, March 2017, 732 . 734 [RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 735 D., and C. Tschudin, "Information-Centric Networking 736 (ICN): Content-Centric Networking (CCNx) and Named Data 737 Networking (NDN) Terminology", RFC 8793, 738 DOI 10.17487/RFC8793, June 2020, 739 . 741 [Song2018] Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level 742 Multi-path Interest Control for Information Centric 743 Networking, in 5th ACM Conference on Information-Centric 744 Networking", DOI 10.1145/3267955.3267971, 2018, 745 . 748 Authors' Addresses 750 Ilya Moiseenko 751 UCLA 753 Email: iliamo@ucla.edu 755 Dave Oran 756 Network Systems Research and Design 757 4 Shady Hill Square 758 Cambridge, MA 02138 759 United States of America 761 Email: daveoran@orandom.net