idnits 2.17.1 draft-oran-icnrg-pathsteering-01.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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 April 2020) is 1464 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: 25 October 2020 Network Systems Research and Design 6 23 April 2020 8 Path Steering in CCNx and NDN 9 draft-oran-icnrg-pathsteering-01 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 25 October 2020. 43 Copyright Notice 45 Copyright (c) 2020 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. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Essential elements of ICN path discovery and path steering . 4 59 2.1. Path Discovery . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Path Steering . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Handling Path Steering errors . . . . . . . . . . . . . . 6 62 2.4. How to represent the Path Label . . . . . . . . . . . . . 6 63 3. Mapping to CCNx and NDN packet encodings . . . . . . . . . . 7 64 3.1. Path label TLV . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Path label encoding for CCNx . . . . . . . . . . . . . . 9 66 3.3. Path label encoding for NDN . . . . . . . . . . . . . . . 9 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 5.1. Cryptographic protection of a path label . . . . . . . . 12 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 6.2. Informative References . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 Path Steering is a mechanism to discover paths to the producers of 78 ICN content objects and steer subsequent Interest messages along a 79 previously discovered path. It has various uses, including the 80 operation of state-of-the-art multipath congestion control algorithms 81 and for network measurement and management. This specification 82 derives directly from the design published in [Moiseenko2017] and 83 therefore does not recapitulate the design motivations, 84 implementation details, or evaluation of the scheme. That 85 publication should be considered a normative reference as it is not 86 likely a reader will be able to understand all elements of this 87 design without first having read the reference. Some technical 88 details are different however, and where there are differences, the 89 design documented here is to be considered definitive. 91 There are a number of important use cases to justify extending ICN 92 architectures such as CCNx [RFC8569] or [NDN] to provide these 93 capabilities. These are summarized as follows: 95 * Support the discovery, monitoring and troubleshooting of multi- 96 path network connectivity based on names and name prefixes. 97 Analogous functions have been shown to be a crucial operational 98 capability in multicast and multi-path topologies for IP. The 99 canonical tools are the well-known _traceroute_ and _ping_. For 100 point-to-multipoint MPLS the more recent tree trace [RFC8029] 101 protocol is used. Equivalent diagnostic functions have been 102 defined for CCNx through the ICN Ping 103 [I-D.mastorakis-icnrg-icnping] and ICN Traceroute 104 [I-D.mastorakis-icnrg-icntraceroute] specifications, both of which 105 are capable of exploiting path steering if available. 107 * Perform accurate online measurement of network performance, which 108 generally requires multiple consecutive packets follow the same 109 path under control of an application. 111 * Improve the performance and flexibility of multi-path congestion 112 control algorithms. Congestion control schemes such as 113 [Mahdian2016] and [Song2018] depend on the ability of a consumer 114 to explicitly steer packets onto individual paths in a multi-path 115 and/or multi-destination topology. 117 * A consumer endpoint can mitigate content poisoning attacks by 118 directing its Interests onto the network paths that bypass 119 poisoned caches. 121 Path discovery and subsequent path steering in ICN networks is 122 facilitated by the symmetry of forward and reverse paths in the CCNx 123 and NDN architectures. Path discovery is achieved by a consumer 124 endpoint transmitting an ordinary Interest message and receiving a 125 Content (Data) message containing an end-to-end path label 126 constructed on the reverse path by the forwarding plane. Path 127 steering is achieved by a consumer endpoint including a path label in 128 the Interest message, which is forwarded to each nexthop through the 129 corresponding egress interfaces in conjunction with longest name 130 prefix match (LNPM) FIB lookup. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 2. Essential elements of ICN path discovery and path steering 140 We elucidate the design using CCNx semantics [RFC8569] and extend its 141 Packet Encoding [RFC8609] as defined in Section 3.2. While the 142 terminology is slightly different, this design can be applied also to 143 NDN, by extending its bespoke packet encodings [NDNTLV] (See 144 Section 3.3). 146 2.1. Path Discovery 148 _End-to-end Path Discovery_ for CCNx is achieved by creating a _path 149 label_ and placing it as a hop-by-hop TLV in a CCNx Content (Data) 150 message. The path label is constructed hop-by-hop as the message 151 traverses the reverse path of transit CCNx forwarders (Figure 1). 152 The path label is updated by adding to the existing path label the 153 nexthop label of the interface at which the Content (Data) message 154 has arrived. Eventually, when the Content(Data) message arrives at 155 the consumer, the path label identifies the complete path the Content 156 (Data) message took to reach the consumer. 158 Consumer Interest 1 ___ Interest 2 159 | | ^ | 160 | | | | 161 | | | | 162 Forwarder 1 v | V 163 | (nexthop 1) (nexthop 1) ^ (nexthop 1) 164 | | | | 165 | | | | 166 Forwarder 2 v | v 167 (nexthop 3) / \ (nexthop 2) (nexthop 2) ^ (nexthop 2) 168 / \ | | | 169 / \ | | | 170 / \ | | | 171 / \ | | | 172 / \ | | | 173 Forwarder 4 Forwarder 3 v | v 174 (nexthop 5)\ / (nexthop 4) (nexthop 4) ^ (nexthop 4) 175 \ / | | | 176 \ / | | | 177 \ / | | | 178 \ / | | | 179 \ / | | | 180 \ / v | v 181 Producer ___ Data 1 ___ 182 or 183 Content Store 185 Figure 1: Figure 1: Basic example of path discovery and steering 187 2.2. Path Steering 189 Due to the symmetry of forward and reverse paths in CCNx, a consumer 190 application can reuse a discovered path label to fetch the same or 191 similar (e.g. next chunk, or next Application Data Unit, or next 192 pointer in a Manifest [I-D.icnrg-flic]) Content (Data) message over 193 the discovered network path. This _Path Steering_ is achieved by 194 processing the Interest message's path label at each transit ICN 195 forwarder and forwarding the Interest through the specified nexthop 196 among those identified as feasible by LNPM FIB lookup (Figure 2). 198 ------------------------------------------------------------------------ 199 FORWARD PATH 200 ------------------------------------------------------------------------ 202 Interest +---------+ +-----+ (path label) +--------+ (match) Interest 203 -------->| Content |->| PIT | ------------>| Label |----------------> 204 | Store | +-----+ | Lookup | 205 +---------+ | \ (no path label) +--------+ 206 | | \ |\ (path label mismatch) 207 Data | | \ | \ 208 <---------+ v \ | \ 209 aggregate \ | \ 210 \ | \ 211 \ | +-----+ Interest 212 +--------------|---->| FIB | ---------> 213 | +-----+ 214 Interest-Return (NACK) v | (no route) 215 <----------------------------------------------+<-------+ 217 ------------------------------------------------------------------------ 218 REVERSE PATH 219 ------------------------------------------------------------------------ 221 Interest-return(NACK) +-----+ (update path label) Interest-Return(NACK) 222 <---------------------| |<----------------------------------------- 223 | | 224 Data +---------+ | PIT | (update path label) Data 225 <------| Content |<---| |<----------------------------------------- 226 | Store | | | 227 +---------+ +-----+ 228 | 229 | (no match) 230 v 232 Figure 2: Figure 2: Path Steering CCN / NDN data plane 234 2.3. Handling Path Steering errors 236 Over time, the state of interfaces and the FIB on forwarders may 237 change such that, at any particular forwarder, a given nexthop is no 238 longer valid for a given prefix. In this case, the path label will 239 point to a now-invalid nexthop. This is detected by failure to find 240 a match between the decoded nexthop ID and the nexthops of the FIB 241 entry after LNPM FIB lookup. 243 On detecting an invalid path label, the forwarder SHOULD respond to 244 the Interest with an Interest-Return. We therefore define a new 245 _Invalid path label_ response code for the Interest Return message 246 and include the current path label as a hop-by-hop header. Each 247 transit forwarder processing the Interest-Return message updates the 248 path label in the same manner as Content (Data) messages, so that the 249 consumer receiving the Interest-Return (NACK) can easily identify 250 which path label is no longer valid. 252 A consumer may alternatively request that a forwarder detecting the 253 inconsistency forward the Interest by means of normal LNPM FIB lookup 254 rather than returning an error. The consumer endpoint, if it cares, 255 can keep enough information about outstanding Interests to determine 256 if the path label sent with the Interest fails to match the path 257 label in the corresponding returned Content (Data), and use that 258 information to replace stale path labels. It does so by setting the 259 FALLBACK MODE flag of the path label TLV in its Interest message. 261 2.4. How to represent the Path Label 263 [Moiseenko2017] presents various options for how to represent a path 264 label, with different tradeoffs in flexibility, performance and space 265 efficiency. For this specification, we choose the _Polynomial 266 encoding_ which achieves reasonable space efficiency at the cost of 267 establishing a hard limit on the length of paths that can be 268 represented. 270 The polynomial encoding utilizes a fixed-size bit array. Each 271 transit ICN forwarder is allocated a fixed sized portion of the bit 272 array. This design allocates 12 bits (i.e. 4095 as a _generator 273 polynomial_) to each intermediate ICN forwarder. This should match 274 the scalability of today's commercial routers that support up to 4096 275 physical and logical interfaces and usually do not have more than a 276 few hundred active ones. 278 +------------------------------------------------------------------+ 279 | Path Label bitmap | 280 +----------+-----------------+-----------------+-------------------+ 281 | index | nexthop label | nexthop label | | 282 +----------+-----------------+-----------------+-------------------+ 283 |<- 8bit ->|<---- 12bit ---->|<---- 12bit ---->|<----------------->| 285 Figure 3: Figure 3: Fixed size path label 287 A forwarder that receives a Content (Data) message encodes the 288 nexthop label in the next available slot and increments label index. 289 Conversely, a forwarder that receives an Interest message reads the 290 current nexthop label and decrements label index. Therefore, the 291 extra computation required at each hop to forward either an interest 292 or Content Object message with a path label is minimized and 293 constitutes a fairly trivial additional overhead compared to FIB 294 lookup and other required operations. 296 This approach results in individual path label TLV instances being of 297 fixed pre-computed size. While this places a hard upper bound on the 298 maximum number of network hops that can be represented, this is not a 299 significant a practical problem in NDN and CCNx, since the size can 300 be pre-set during Content(Data) message encoding based on the exact 301 number of network hops traversed by the Interest message. Even long 302 paths of 24 hops will fit in a path label bitmap of 36 bytes if 303 nexthop label is encoded in 12 bits. 305 3. Mapping to CCNx and NDN packet encodings 307 3.1. Path label TLV 309 A Path label TLV is the tuple: {[Flags], [Path Label Hop Count], 310 [Nexthop Label], [Path label bitmap]}. 312 +----------------+-------------+ 313 | Flag | Value (hex) | 314 +================+=============+ 315 | DISCOVERY MODE | 0x00 | 316 +----------------+-------------+ 317 | FALLBACK MODE | 0x01 | 318 +----------------+-------------+ 319 | STRICT MODE | 0x02 | 320 +----------------+-------------+ 322 Table 1: Path label flags 324 The Path Label Hop Count (PLHC) MUST be incremented by NDN and CCNx 325 forwarders if the Interest packet carries a path label and DISCOVERY 326 mode flag is set. A producer node or a forwarder with cached data 327 packet MUST use PLHC in calculation of a path label bitmap size 328 suitable for encoding the entire path to the consumer. The Path 329 Label Hop Count (PLHC) MUST be set to zero in newly created Data or 330 Interest-Return (NACK) packets. A consumer node MUST reuse Path 331 Label Hop Count (PLHC) together with the Path label bitmap (PLB) in 332 order to correctly forward the Interest(s) along the corresponding 333 network path. 335 If an NDN or CCNx forwarder supports path labeling, the Nexthop label 336 MUST be used to determine the correct egress interface for an 337 Interest packet carrying either the FALLBACK MODE or STRICT MODE 338 flag. If any particular NDN or CCNx forwarder is configured to 339 decrypt path labels of Interest packets (Section "Security 340 considerations" (Section 5)), then the forwarder MUST 342 1. decrypt the path label with its own symmetric key, 344 2. update the nexthop label with outermost label in the path label, 346 3. decrement Path Label Hop Count (PLHC), and 348 4. remove the outermost label from the path label. 350 If any particular NDN or CCNx forwarder is NOT configured to decrypt 351 path labels of Interest packets, then path label decryption SHOULD 352 NOT be performed. 354 The Nexthop label MUST be ignored by NDN and CCNx forwarders if 355 present in Data or Interest-Return (NACK) packets. If any particular 356 NDN or CCNx forwarder is configured to encrypt path labels of Data 357 and Interest-Return (NACK) packets (Section Security Considerations 358 (Section 5)), then the forwarder MUST encrypt existing path label 359 with its own symmetric key, append the nexthop label of the ingress 360 interface to the path label, and increment Path Label Hop Count 361 (PLHC). If any particular NDN or CCNx forwarder is NOT configured to 362 encrypt path labels of Interest packets, then path label encryption 363 SHOULD NOT be performed. 365 NDN and CCNx forwarders MUST fallback to longest name prefix match 366 (LNPM) FIB lookup if an Interest packet carries an invalid nexthop 367 label and the FALLBACK MODE flag is set. 369 CCNx forwarders MUST respond with an Interest Return packet 370 specifying the T_RETURN_INVALID_PATH_LABEL code if Interest packet 371 carries an invalid path label and the STRICT MODE flag is set. 373 CCNx forwarders MUST respond with an Interest Return packet 374 specifying the T_RETURN_MALFORMED_INTEREST code if the Interest 375 packet carries a path label TLV with both FALLBACK MODE and STRICT 376 MODE flags set. 378 3.2. Path label encoding for CCNx 380 Path Label is an optional Hop-by-Hop header TLV that can be present 381 in CCNx Interest, InterestReturn and Content Object packets. 383 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 384 +---------------+---------------+---------------+---------------+ 385 | T_PATH_LABEL | Length + 4 | 386 +---------------+---------------+---------------+---------------+ 387 | Flags | Path Label | Nexthop Label | 388 | | Hop Count | | 389 +---------------+---------------+---------------+---------------+ 390 / / 391 / Path label bitmap (Length octets) / 392 / / 393 +---------------+---------------+---------------+---------------+ 395 Figure 4: Figure 4: Path label Hop-by-Hop header TLV for CCNx 397 3.3. Path label encoding for NDN 399 Path Label is an optional TLV in NDN Interest, Data and NACK packets. 400 The Path Label TLV SHOULD NOT take part in Interest, Data or NACK 401 signature calculation as it is potentially modified at every network 402 hop. 404 PathLabel = PATH-LABEL-TYPE TLV-LENGTH 405 PathLabelFlags 406 PathLabelBitmap 408 PathLabelFlags = PATH-LABEL-FLAGS-TYPE 409 TLV-LENGTH ; == 1 410 OCTET 412 NexthopLabel = PATH-LABEL-NEXTHOP-LABEL-TYPE 413 TLV-LENGTH ; == 2 414 2 OCTET 416 PathLabelHopCount = PATH-LABEL-HOP-COUNT-TYPE 417 TLV-LENGTH ; == 1 418 OCTET 420 PathLabelBitmap = PATH-LABEL-BITMAP-TYPE 421 TLV-LENGTH ; == 64 422 64 OCTET 424 Figure 5: Figure 5: Path label TLV for NDN 426 +-------------------------------+-------------+ 427 | Flag | Value (hex) | 428 +===============================+=============+ 429 | PATH-LABEL-TYPE | 0x09 | 430 +-------------------------------+-------------+ 431 | PATH-LABEL-FLAGS-TYPE | 0x0B | 432 +-------------------------------+-------------+ 433 | PATH-LABEL-BITMAP-TYPE | 0x0D | 434 +-------------------------------+-------------+ 435 | PATH-LABEL-NEXTHOP-LABEL-TYPE | 0x0E | 436 +-------------------------------+-------------+ 437 | PATH-LABEL-HOP-COUNT-TYPE | 0x0F | 438 +-------------------------------+-------------+ 440 Table 2: TLV-TYPE number assignments 442 4. IANA Considerations 444 IANA is requested to make the following assignments: 446 1. Please assign the value 0x0004 for T_PATH_LABEL in the *CCNx Hop- 447 by-Hop Types* registry. 449 2. Please assign the TLV types in Table 2 in the *CCNx Hop-by-Hop 450 type registry*. 452 3. Please assign the value 0xA for the T_RETURN_INVALID_PATH_LABEL 453 in the *CCNx Interest Return Code Types" registry*. 455 4. Please create the *CCNx Path Label Flags* registry and assign the 456 values listed in Table 1. 458 5. Security Considerations 460 A path is invalidated by renumbering nexthop label(s). A malicious 461 consumer can attempt to mount an attack by transmitting Interests 462 with path labels which differ only in a single now-invalid nexthop 463 label in order to _brute force_ a valid nexthop label. If such an 464 attack succeeds, a malicious consumer would be capable of steering 465 Interests over a network path that may not match the paths computed 466 by the routing algorithm or learned adaptively by the forwarders. 468 When a label lookup fails, by default an _Invalid path label_ 469 Interest-Return (NACK) message is returned to the consumer. This 470 contains a path label identical to the one included in the 471 corresponding Interest message. A malicious consumer can therefore 472 analyze the message's Hop Count field to infer which specific nexthop 473 label had failed and direct an attack to influence path steering at 474 that hop. This threat can be mitigated by the following 475 countermeasures: 477 * A nexthop label of larger size is harder to crack. If nexthop 478 labels are not allocated in a predictable fashion by the routers, 479 brute forcing a 32-bit nexthop label requires on average O(2^31) 480 Interests. However, this specification uses nexthop labels with 481 much less entropy (12 bits), so depending on computational 482 hardness is not workable. 484 * An ICN forwarder can periodically update nexthop labels to limit 485 the maximum lifetime of paths. It is RECOMMENDED that forwarders 486 update path labels at least every few minutes. 488 * A void Hop Count field in an _Invalid path label_ Interest-Return 489 (NACK) message would not give out the information on which 490 specific nexthop label had failed. An attacker might need to 491 brute force all nexthop labels in all combinations. However, some 492 useful diagnostic capability is lost by obscuring the hop count. 493 For example the locus of routing churn is harder to pin down 494 through analysis of path-steered pings or traceroutes. A 495 forwarder MAY choose to invalidate the hop count in addition to 496 changing nexthop labels periodically as above. 498 ICN protocols can be susceptible to a variety of cache poisoning 499 attacks, where a colluding consumer and producer arrange for bogus 500 content (with either invalid or inappropriate signatures) to populate 501 forwarder caches. These are generally confined to on-path attacks. 502 It is also theoretically possible to launch a similar attack without 503 a cooperating producer such that the caches of on-path routers become 504 poisoned with the content from off-path routers (i.e. physical 505 connectivity, but no route in a FIB for a given prefix). We estimate 506 that without any prior knowledge of the network topology, the 507 complexity of this type of attack is in the ballpark of Breadth- 508 First-Search and Depth-First-Search algorithms with the additional 509 burden of transmitting 2^31 Interests in order to crack a nexthop 510 label on each hop. Relatively short periodic update of nexthop 511 labels and anti- _label scan_ heuristics implemented in the ICN 512 forwarder may successfully mitigate this type of attack. 514 5.1. Cryptographic protection of a path label 516 If the countermeasures listed above do not provide sufficient 517 protection against malicious mis-steering of Interests, the path 518 label can be made opaque to the consumer endpoint via hop-by-hop 519 symmetric cryptography applied to the path labels (Figure 6). This 520 method is viable due to the symmetry of forward and reverse paths in 521 CCNx and NDN architectures combined with ICN path steering requiring 522 only reads/writes of the topmost nexthop label (i.e. active nexthop 523 label) in the path label. This way a path steering capable ICN 524 forwarder receiving a Data (Content) message encrypts the current 525 path label with its own non-shared symmetric key prior to adding a 526 new nexthop label to the path label. The Data (Content) message is 527 forwarded downstream with unencrypted topmost (i.e active) nexthop 528 label and encrypted remaining content of the path label. As a 529 result, a consumer endpoint receives a Data (Content) message with a 530 unique path label exposing only the topmost nexthop label as 531 cleartext. A path steering forwarder receiving an Interest message 532 performs label lookup using the topmost nexthop label, decrypts the 533 path label with its own non-shared symmetric key, and forwards the 534 message upstream. 536 Cryptographic protection of a path label does not require any key 537 negotiation among ICN forwarders, and is no more expensive than 538 MACsec or IPsec. It is also quite possible that strict hop-by-hop 539 path label encryption is not necessary and path label encryption only 540 on the border routers of the trusted administrative or routing 541 domains may suffice. 543 Producer 544 | ^ 545 | | 546 Path Label TLV | | Path Label TLV 547 +-----------------------+ | | +-----------------------+ 548 |nexthop label=456 | v | |nexthop label=456 | 549 |encrypted path label={}| Forwarder 3 |encrypted path label={}| 550 +-----------------------+ | ^ +-----------------------+ 551 | | 552 path label is encrypted | | path label is decrypted 553 with Forwarder 3 | | with Forwarder 3 554 symmetric key | | symmetric key 555 | | 556 | | 557 | | 558 | | 559 | | 560 Path Label TLV | | Path Label TLV 561 +-----------------------+ | | +-----------------------+ 562 |nexthop label=634 | v | |nexthop label=634 | 563 |encrypted path label= | Forwarder 2 |encrypted path label= | 564 | {456} | | ^ | {456} | 565 +-----------------------+ | | +-----------------------+ 566 | | 567 path label is encrypted | | path label is decrypted 568 with Forwarder 2 | | with Forwarder 2 569 symmetric key | | symmetric key 570 | | 571 | | 572 | | 573 | | 574 | | 575 Path Label TLV | | Path Label TLV 576 +-----------------------+ | | +-----------------------+ 577 |nexthop label=912 | v | |nexthop label=912 | 578 |encrypted path label= | Forwarder 1 |encrypted path label= | 579 | {634, encrypted path | | ^ | {634, encrypted path | 580 | label {456}} | | | | label {456}} | 581 +-----------------------+ | | +-----------------------+ 582 | | 583 path label is encrypted | | path label is decrypted 584 with Forwarder 1 | | with Forwarder 1 585 symmetric key | | symmetric key 586 | | 587 | | 588 | | 589 | | 590 v | 591 Consumer 593 Figure 6: Figure 6: Path label protection with hop-by-hop symmetric 594 cryptography 596 6. References 598 6.1. Normative References 600 [Moiseenko2017] 601 Moiseenko, I. and D. Oran, "Path Switching in Content 602 Centric and Named Data Networks, in 4th ACM Conference on 603 Information-Centric Networking (ICN 2017)", 604 DOI 10.1145/3125719.3125721, September 2017, 605 . 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, 610 DOI 10.17487/RFC2119, March 1997, 611 . 613 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 614 Networking (CCNx) Semantics", RFC 8569, 615 DOI 10.17487/RFC8569, July 2019, 616 . 618 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 619 Networking (CCNx) Messages in TLV Format", RFC 8609, 620 DOI 10.17487/RFC8609, July 2019, 621 . 623 6.2. Informative References 625 [I-D.icnrg-flic] 626 Tschudin, C. and C. Wood, "File-Like ICN Collection 627 (FLIC)", Work in Progress, Internet-Draft, draft-icnrg- 628 flic-00, 25 June 2017, 629 . 631 [I-D.mastorakis-icnrg-icnping] 632 Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 633 D. Oran, "ICN Ping Protocol Specification", Work in 634 Progress, Internet-Draft, draft-mastorakis-icnrg-icnping- 635 06, 13 February 2020, . 638 [I-D.mastorakis-icnrg-icntraceroute] 639 Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 640 D. Oran, "ICN Traceroute Protocol Specification", Work in 641 Progress, Internet-Draft, draft-mastorakis-icnrg- 642 icntraceroute-06, 13 February 2020, 643 . 646 [Mahdian2016] 647 Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, 648 "MIRCC: Multipath-aware ICN Rate-based Congestion Control, 649 in Proceedings of the 3rd ACM Conference on Information- 650 Centric Networking", DOI 10.1145/2984356.2984365, 2016, 651 . 654 [NDN] "Named Data Networking", various, 655 . 657 [NDNTLV] "NDN Packet Format Specification.", 2016, 658 . 660 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 661 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 662 Switched (MPLS) Data-Plane Failures", RFC 8029, 663 DOI 10.17487/RFC8029, March 2017, 664 . 666 [Song2018] Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level 667 Multi-path Interest Control for Information Centric 668 Networking, in 5th ACM Conference on Information-Centric 669 Networking", DOI 10.1145/3267955.3267971, 2018, 670 . 673 Authors' Addresses 675 Ilya Moiseenko 676 UCLA 678 Email: iliamo@ucla.edu 679 Dave Oran 680 Network Systems Research and Design 681 4 Shady Hill Square 682 Cambridge, MA 02138 683 United States of America 685 Email: daveoran@orandom.net