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