idnits 2.17.00 (12 Aug 2021) /tmp/idnits15435/draft-irtf-icnrg-icnping-06.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 17 instances of too long lines in the document, the longest one being 38 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (3 May 2022) is 11 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccninfo-08 == Outdated reference: A later version (-06) exists of draft-oran-icnrg-pathsteering-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG S. Mastorakis 3 Internet-Draft University of Nebraska at Omaha 4 Intended status: Experimental J. Gibson 5 Expires: 4 November 2022 Cisco Systems 6 I. Moiseenko 7 Apple Inc 8 R. Droms 9 Unaffiliated 10 D. Oran 11 Network Systems Research and Design 12 3 May 2022 14 ICN Ping Protocol Specification 15 draft-irtf-icnrg-icnping-06 17 Abstract 19 This document presents the design of an ICN Ping protocol. It 20 includes the operations of both the client and the forwarder. This 21 document is a product of the IRTF Information-Centric Networking 22 Research Group (ICNRG). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 4 November 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Background on IP-Based Ping Operation . . . . . . . . . . . . 4 58 3. Ping Functionality Challenges and Opportunities in ICN . . . 4 59 4. ICN Ping Echo CCNx Packet Formats . . . . . . . . . . . . . . 7 60 4.1. ICN Ping Echo Request CCNx Packet Format . . . . . . . . 7 61 4.2. Ping Echo Reply CCNx Packet Format . . . . . . . . . . . 8 62 5. ICN Ping Echo NDN Packet Formats . . . . . . . . . . . . . . 12 63 5.1. ICN Ping Echo Request NDN Packet Format . . . . . . . . . 12 64 5.2. Ping Echo Reply NDN Packet Format . . . . . . . . . . . . 13 65 6. Forwarder Handling . . . . . . . . . . . . . . . . . . . . . 14 66 7. Protocol Operation For Locally-Scoped Namespaces . . . . . . 15 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 72 11.2. Informative References . . . . . . . . . . . . . . . . . 17 73 Appendix A. Ping Client Application (Consumer) Operation . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 Ascertaining data plane reachability to a destination and taking 79 coarse performance measurements of round trip time are fundamental 80 facilities for network administration and troubleshooting. In IP, 81 where routing and forwarding are based on IP addresses, ICMP echo and 82 ICMP echo response are the protocol mechanisms used for this purpose, 83 generally exercised through the familiar ping utility. In ICN, where 84 routing and forwarding are based on name prefixes, the ability to 85 ascertain reachability of names is required. 87 This document proposes protocol mechanisms for a ping equivalent in 88 ICN (CCNx [RFC8609] and NDN [NDNTLV]) networks. A non-normative 89 appendix suggests useful properties for an ICN ping client 90 application, analogous to IP ping, that originates echo requests and 91 processes echo replies. 93 In order to carry out meaningful experimentation and deployment of 94 ICN protocols, tools to manage and debug the operation of ICN 95 architectures and protocols are needed analogous to ping and 96 traceroute used for TCP/IP. This document describes the design of a 97 management and debugging protocol analogous to the ping protocol of 98 TCP/IP, which will aid the experimental deployment of ICN protocols. 99 As the community continues its experimentation with ICN architectures 100 and protocols, the design of ICN Ping might change accordingly. ICN 101 Ping is designed as a "first line of defense" tool to troubleshoot 102 ICN architectures and protocols. As such, this document is 103 classified as an experimental RFC. 105 This document is not an Internet Standards Track specification; it is 106 published for examination, experimental implementation, and 107 evaluation. This document defines an Experimental Protocol for the 108 Internet community. This document is a product of the Internet 109 Research Task Force (IRTF). The IRTF publishes the results of 110 Internet-related research and development activities. These results 111 might not be suitable for deployment. This RFC represents the 112 consensus of the Information-Centric Networking Research Group of the 113 Internet Research Task Force (IRTF). Documents approved for 114 publication by the IRSG are not candidates for any level of Internet 115 Standard; see Section 2 of RFC 7841. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 1.2. Terminology 125 To aid the understanding of readers, we define the following terms: 127 * Content object: A network-level packet that carries payload, 128 uniquely identified by a name, and is directly secured [RFC8793]. 130 * Producer: An ICN entity that creates Data packets and makes them 131 available for retrieval [RFC8793]. 133 * Producer's name: The name prefix that a request must carry in 134 order to reach a producer over an ICN network. 136 * Named Data: A synonym for a content object. 138 * Round Trip Time (RTT): The time between sending a request for a 139 specific piece of named data and receiving the corresponding piece 140 of named data. 142 * Sender: An entity that sends a request for named data or a piece 143 of named data. 145 * Name of a sender: An alias of producer's name. 147 * Border forwarder: The forwarder that is the border of a network 148 region where a producer's name is directly routable (i.e., the 149 producer's name is present in the FIB of forwarders within this 150 network region). 152 2. Background on IP-Based Ping Operation 154 In IP-based ping, an IP address is specified by the user either 155 directly, or via translation of a domain name through DNS. The ping 156 client application sends a number of ICMP Echo Request packets with 157 the specified IP address as the IP destination address and an IP 158 address from the client's host as the IP source address. 160 Each ICMP Echo Request is forwarded across the network based on its 161 destination IP address. If it eventually reaches the destination, 162 the destination responds by sending back an ICMP Echo Reply packet to 163 the IP source address from the ICMP Echo Request. 165 If an ICMP Echo Request does not reach the destination or the Echo 166 reply is lost, the ping client times out. Any ICMP error messages, 167 such as "no route to destination", generated by the ICMP Echo Request 168 message are returned to the client and reported. 170 3. Ping Functionality Challenges and Opportunities in ICN 172 In ICN, the communication paradigm is based exclusively on named 173 objects. An Interest is forwarded across the network based on the 174 name prefix that it carries. Eventually, a content object is 175 retrieved either from a producer application or some forwarder's 176 Content Store (CS). 178 IP-based ping was built as an add-on measurement and debugging tool 179 on top of an already existing network architecture. In ICN, we have 180 the opportunity to incorporate diagnostic mechanisms directly in the 181 network layer protocol, and hopefully provide more powerful 182 diagnostic capability than can be realized through the layered ICMP 183 Echo approach. 185 An ICN network differs from an IP network in at least 4 important 186 ways: 188 * IP identifies interfaces to an IP network with a fixed-length 189 address, and delivers IP packets to one or more of these 190 interfaces. ICN identifies units of data in the network with a 191 variable length name consisting of a hierarchical list of name 192 components. 194 * An IP-based network depends on the IP packets having source IP 195 addresses that are used as the destination address for replies. 196 On the other hand, ICN Interests do not have source addresses and 197 they are forwarded based on names, which do not refer to a unique 198 end-point. Data packets follow the reverse path of the Interests 199 based on hop-by-hop state created during Interest forwarding. 201 * An IP network supports multi-path, single destination, stateless 202 packet forwarding and delivery via unicast, a limited form of 203 multi-destination selected delivery with anycast, and group-based 204 multi-destination delivery via multicast. In contrast, ICN 205 supports multi-path and multi-destination stateful Interest 206 forwarding and multi-destination delivery of named data. This 207 single forwarding semantic subsumes the functions of unicast, 208 anycast, and multicast. As a result, consecutive (or 209 retransmitted) ICN Interest messages may be forwarded through an 210 ICN network along different paths, and may be forwarded to 211 different data sources (e.g., end-node applications, in-network 212 storage) holding a copy of the requested unit of data. This can 213 lead to a significant variance in round-trip times, which while 214 resulting in a more robust overall forwarding architecture, has 215 implications for a network troubleshooting mechanism like ping. 217 * In the case of multiple Interests with the same name arriving at a 218 forwarder, a number of Interests may be aggregated in a common 219 Pending Interest Table (PIT) entry and only one of them forwarded 220 onward. Depending on the lifetime of a PIT entry, the round-trip 221 time an Interest-Data exchange might significantly vary (e.g., it 222 might be shorter than the full round-trip time to reach the 223 original content producer). To this end, the round-trip time 224 experienced by consumers might also vary. 226 These differences introduce new challenges, new opportunities and new 227 requirements in the design of an ICN ping protocol. Following this 228 communication model, a ping client should be able to express ping 229 echo requests with some name prefix and receive responses. 231 Our goals are the following: 233 * Test the reachability and the operational state of an ICN 234 forwarder. 236 * Test the reachability of a producer or a data repository (in the 237 sense of whether Interests for a prefix that it serves can be 238 forwarded to it) and discover the forwarder with local 239 connectivity to (an instance of) this producer or repository. 241 * Test whether a specific named object is cached in some on-path CS, 242 and, if so, return the administrative name of the corresponding 243 forwarder. 245 * Perform some simple network performance measurements. 247 To this end, a ping name can represent: 249 * An administrative name that has been assigned to a forwarder. 251 * A name that includes an application's namespace as a prefix. 253 * A named object that might reside in some in-network storage. 255 In order to provide stable and reliable diagnostics, it is desirable 256 that the packet encoding of a ping echo request enable the forwarders 257 to distinguish a ping from a normal Interest, while also allowing for 258 forwarding behavior to be as similar as possible to that of an 259 Interest packet. In the same way, the encoding of a ping echo reply 260 should allow for forwarder processing as close as possible to that 261 used for data packets. 263 The ping protocol should also enable relatively robust round-trip 264 time measurements. To this end, it is important to have a mechanism 265 to steer consecutive ping echo requests for the same name towards an 266 individual path. Such a capability was initially published in 267 [PATHSTEERING] and has been specified for CCNx in 268 [I-D.oran-icnrg-pathsteering]. 270 It is also important, in the case of ping echo requests for the same 271 name from different sources to have a mechanism to avoid those 272 requests being aggregated in the PIT. To this end, we need some 273 encoding in the ping echo requests to make each request for a common 274 name unique, hence avoiding PIT aggregation and further enabling the 275 exact match of a response with a particular ping packet. 277 Note that ICN ping is a protocol that estimates the perceived RTT 278 based on a single request-reply exchange. A measurement application 279 is needed to make proper use of this protocol to explore multiple 280 paths and compute various statistics, such as the variance, average, 281 maximum and minimum RTT values as well as loss rates. 283 4. ICN Ping Echo CCNx Packet Formats 285 In this section, we describe the Echo Packet Format according to the 286 CCNx packet format [RFC8569], where messages exist within outermost 287 containments (packets). Specifically, we specify two types of ping 288 packets, an echo request and an echo reply packet type. 290 4.1. ICN Ping Echo Request CCNx Packet Format 292 The format of the ping echo request packet is presented below: 294 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 296 +---------------+---------------+---------------+---------------+ 297 | | | | 298 | Version | EchoRequest | PacketLength | 299 | | | | 300 +---------------+---------------+---------------+---------------+ 301 | | | | | 302 | HopLimit | Reserved | Flags | HeaderLength | 303 | | | | | 304 +---------------+---------------+---------------+---------------+ 305 / / 306 / Path label TLV / 307 / / 308 +---------------+---------------+---------------+---------------+ 309 | | 310 | Echo Request Message TLVs | 311 | | 312 +---------------+---------------+---------------+---------------+ 314 Figure 1: Echo Request CCNx Packet Format 316 The existing packet header fields have the same definition as the 317 header fields of a CCNx Interest packet. The value of the packet 318 type field is _Echo Request_. The exact numeric value of this field 319 type is to be assigned in the Packet Type IANA Registry for CCNx (see 320 section 4.1 of [RFC8569]. 322 Compared to the typical format of a CCNx packet header from 323 [RFC8569], in order to enable path steering of Echo Requests, there 324 is an optional fixed header Path label TLV as specified in 325 [I-D.oran-icnrg-pathsteering] added to the packet header: 327 The message format of an echo request is presented below: 329 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 331 +---------------+---------------+---------------+---------------+ 332 | | | 333 | MessageType = 1 | MessageLength | 334 | | | 335 +---------------+---------------+---------------+---------------+ 336 | | 337 | Name TLV | 338 | | 339 +---------------+---------------+---------------+---------------+ 341 Figure 2: Echo Request Message Format 343 The echo request message is of type Interest in order to leverage the 344 Interest forwarding behavior provided by the network. The Name TLV 345 has the structure described in [RFC8609]. The name consists of the 346 prefix that we would like to ping appended with a nonce typed name 347 component as its last component. The exact numeric value of this 348 field type is to be assigned in the Name Component Type IANA Registry 349 for CCNx (see section 4.5 of [RFC8609]. The value of this TLV is a 350 64-bit nonce. The purpose of the nonce is to avoid Interest 351 aggregation and allow client matching of replies with requests. As 352 described below, the nonce is ignored for CS checking. 354 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 356 +---------------+---------------+---------------+---------------+ 357 | | | 358 | Nonce_Type | Nonce_Length = 8 | 359 | | | 360 +---------------+---------------+---------------+---------------+ 361 | | 362 | | 363 | | 364 | Nonce_Value | 365 | | 366 | | 367 +---------------+---------------+---------------+---------------+ 369 Figure 3: Nonce Name component TLV for Echo Request messages 371 4.2. Ping Echo Reply CCNx Packet Format 373 The format of a ping echo reply packet is presented below: 375 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 377 +---------------+---------------+---------------+---------------+ 378 | | | | 379 | Version | EchoReply | PacketLength | 380 | | | | 381 +---------------+---------------+---------------+---------------+ 382 | | | | 383 | Reserved | Flags | HeaderLength | 384 | | | | 385 +---------------+---------------+---------------+---------------+ 386 | | 387 | Path label TLV | 388 | | 389 +---------------+---------------+---------------+---------------+ 390 | | 391 | Echo Reply Message TLVs | 392 | | 393 +---------------+---------------+---------------+---------------+ 395 Figure 4: Echo Reply CCNx Packet Format 397 The header of an echo reply consists of the header fields of a CCNx 398 Content Object and a hop-by-hop Path label TLV. The value of the 399 packet type field is Echo Reply. The exact numeric value of this 400 field type is to be assigned in the Packet Type IANA Registry for 401 CCNx (see section 4.1 of [RFC8569]. The Path label header TLV from 402 [I-D.oran-icnrg-pathsteering] is as defined for the echo request 403 packet. 405 A ping echo reply message is of type Content Object, contains a Name 406 TLV (name of the corresponding echo request), a PayloadType TLV and 407 an ExpiryTime TLV with a value of 0 to indicate that echo replies 408 must not be returned from network caches. 410 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 412 +---------------+---------------+---------------+---------------+ 413 | | | 414 | MessageType = 2 | MessageLength | 415 | | | 416 +---------------+---------------+---------------+---------------+ 417 | | 418 | Name TLV | 419 | | 420 +---------------+---------------+---------------+---------------+ 421 | | 422 | PayloadType TLV | 423 | | 424 +---------------+---------------+---------------+---------------+ 425 | | 426 | ExpiryTime TLV | 427 | | 428 +---------------+---------------+---------------+---------------+ 430 Figure 5: Echo Reply Message Format 432 The PayloadType TLV is presented below. It is of type 433 T_PAYLOADTYPE_DATA, and the data schema consists of 3 TLVs: 1) the 434 name of the sender of this reply (with the same structure as a CCNx 435 Name TLV), 2) the sender's signature of their own name (with the same 436 structure as a CCNx ValidationPayload TLV), 3) a TLV with a return 437 code to indicate what led to the generation of this reply (i.e., 438 existence of a local application, a CS hit or a match with a 439 forwarder's administrative name as specified in Section 6). 441 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 443 +---------------+---------------+---------------+---------------+ 444 | | | 445 | T_PAYLOADTYPE_DATA | Length | 446 | | | 447 +---------------+---------------+---------------+---------------+ 448 / / 449 / Sender's Name TLV / 450 / / 451 +---------------+---------------+---------------+---------------+ 452 / / 453 / Sender's Signature TLV / 454 / / 455 +---------------+---------------+---------------+---------------+ 456 / / 457 / Echo Reply Code TLV / 458 / / 459 +---------------+---------------+---------------+---------------+ 461 Figure 6: Echo Reply Message Format 463 The goal of including the name of the sender in the echo reply is to 464 enable the user to reach this entity directly to ask for further 465 management/administrative information using generic Interest-Data 466 exchanges or by employing a more comprehensive management tool such 467 as CCNInfo [I-D.irtf-icnrg-ccninfo] after a successful verification 468 of the sender's name. 470 The structure of the Echo Reply Code TLV is presented below (16-bit 471 value). The defined values are the following: 473 * 1: Indicates that the target name matched the administrative name 474 of a forwarder. 476 * 2: Indicates that the target name matched a prefix served by an 477 application. 479 * 3: Indicates that the target name matched the name of an object in 480 a forwarder's CS. 482 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 484 +---------------+---------------+---------------+---------------+ 485 | | | 486 | Echo_Reply_Code_Type | Echo_Reply_Code_Length = 2 | 487 | | | 488 +---------------+---------------+---------------+---------------+ 489 | | 490 | Echo_Reply_Code_Value | 491 +---------------+---------------+---------------+---------------+ 493 Figure 7: Echo Reply Code TLV 495 5. ICN Ping Echo NDN Packet Formats 497 In this section, we present the ICN Ping Echo Request and Reply 498 Format according to the NDN packet specification [NDNTLV]. 500 5.1. ICN Ping Echo Request NDN Packet Format 502 An echo request is encoded as an NDN Interest packet. Its format is 503 the following: 505 EchoRequest = INTEREST-TYPE TLV-LENGTH 506 Name 507 MustBeFresh 508 Nonce 509 ApplicationParameters? 511 Figure 8: Echo Request NDN Packet Format 513 The name field of an echo request consists of the name prefix to be 514 pinged, a nonce value (it can be the value of the Nonce field) and 515 the suffix "ping" to denote that this Interest is a ping request 516 (added as a KeywordNameComponent). When the "ApplicationParameters" 517 element is present, a ParametersSha256DigestComponent is added as the 518 last name component. 520 The "ApplicationParameters" field of the Request contains a Path 521 label TLV as specified in [I-D.oran-icnrg-pathsteering]. 523 Since the NDN packet format does not provide a mechanism to prevent 524 the network from caching specific data packets, we use the 525 MustBeFresh element for echo requests (in combination with a 526 Freshness Period TLV of value 1 for echo replies) to avoid fetching 527 cached echo replies with an expired freshness period [REALTIME]. 529 5.2. Ping Echo Reply NDN Packet Format 531 An echo reply is encoded as an NDN Data packet. Its format is the 532 following: 534 EchoReply = DATA-TLV TLV-LENGTH 535 Name 536 MetaInfo 537 Content 538 Signature 539 Path label TLV 541 Figure 9: Echo Reply NDN Packet Format 543 Compared to the format of a regular NDN Data packet, an echo reply 544 contains a Path label TLV field, which is not included in the 545 security envelope, since it might be modified in a hop-by-hop fashion 546 by the forwarders along the reverse path. 548 The name of an echo reply is the name of the corresponding echo 549 request, while the format of the MetaInfo field is the following: 551 MetaInfo = META-INFO-TYPE TLV-LENGTH 552 ContentType 553 FreshnessPeriod 555 Figure 10: MetaInfo TLV 557 The value of the ContentType TLV is 0. The value of the 558 FreshnessPeriod TLV is 1, so that the replies are treated as stale 559 data (almost instantly) as they are received by a forwarder. 561 The content of an echo reply consists of the following 2 TLVs: 562 Sender's name (with a structure similar as an NDN Name TLV) and Echo 563 Reply Code. There is no need to have a separate TLV for the sender's 564 signature in the content of the reply, since every NDN data packet 565 carries the signature of the data producer. 567 The Echo Reply Code TLV format is the following (with the values 568 specified in Section 4.2): 570 EchoReplyCode = ECHOREPLYCODE-TLV-TYPE TLV-LENGTH 2*OCTET 572 Figure 11: Echo Reply Code TLV 574 6. Forwarder Handling 576 We present the workflow of the forwarder's operation in Figure 12. 577 When a forwarder receives an echo request, it first extracts the 578 message's base name (i.e., the request name with the Nonce name 579 component excluded as well as the suffix "ping" and the 580 ParametersSha256DigestComponent in the case of an echo request with 581 the NDN packet format). 583 In some cases, the forwarder originates an echo reply, sending the 584 reply downstream through the face on which the echo request was 585 received. This echo reply includes the forwarder's own name and 586 signature and the appropriate echo reply code based on the condition 587 that triggered the reply generation. It also includes a Path label 588 TLV, initially containing a null value (since the echo reply 589 originator did not forward the request and, thus, does not make a 590 path choice). 592 The forwarder generates and returns an echo reply in the following 593 cases: 595 * Assuming that a forwarder has been given one or more 596 administrative names, the echo request base name exactly matches 597 any of the forwarder's administrative name(s). 599 * The echo request's base name exactly matches the name of a 600 content-object residing in the forwarder's CS (unless the ping 601 client application has chosen not to receive replies due to CS 602 hits as specified in Appendix A). 604 * The echo request base name matches (in a Longest Prefix Match 605 manner) a FIB entry with an outgoing face referring to a local 606 application. 608 If none of the conditions to reply to the echo request are met, the 609 forwarder will attempt to forward the echo request upstream based on 610 the path steering value (if present), the results of the FIB LPM 611 lookup and PIT creation (based on the name including the nonce typed 612 name component and the suffix "ping" in the case of an echo request 613 with the NDN packet format). If no valid next-hop is found, an 614 InterestReturn is sent downstream indicating "no route" (as with a 615 failed attempt to forward an ordinary Interest). 617 A received echo reply will be matched to an existing PIT entry as 618 usual. On the reverse path, the path steering TLV of an echo reply 619 will be updated by each forwarder to encode its next-hop choice. 620 When included in subsequent echo requests, this Path label TLV allows 621 the forwarders to steer the echo requests along the same path. 623 ------------------------------------------------------------------------ 624 FORWARD PATH 625 ------------------------------------------------------------------------ 627 Request +------+ +-----+ +-----+(path label) +--------+ (match) Request 628 ------> |Admin |->| CS |->| PIT | ------------>| Label |----------------> 629 | Name | +-----+ +-----+ | Lookup | 630 |Lookup| | | \ (no path label)+--------+ 631 +------+ | | \ |\ (path label mismatch) 632 Reply | | | \ | \ 633 <---------+ | v \ | \ 634 (base matches | aggregate \ | \ 635 admin name) | \ | \ 636 | (base \ | +------+ Request 637 Reply | matches +----------|---->| FIB | --------> 638 <---------+ cached object) | +------+ 639 | (no | | (base matches 640 Interest-Return (NACK) v route)| | local app 641 <----------------------------------------------+<-------+ | face) 642 <----------------------------------------------------------+ 643 Reply 644 ------------------------------------------------------------------------ 645 REVERSE PATH 646 ------------------------------------------------------------------------ 648 Interest-return(NACK) +-----+ (update path label) Interest-Return(NACK) 649 <---------------------| |<----------------------------------------- 650 | | 651 Reply +------+ | PIT | (update path label) Reply 652 <------| CS |<------| |<----------------------------------------- 653 +------+ | | 654 +-----+ 655 | 656 | (no match) 657 v 659 Figure 12: Forwarder Operation 661 7. Protocol Operation For Locally-Scoped Namespaces 663 In this section, we elaborate on 2 alternative design approaches in 664 cases that the pinged prefix corresponds to a locally-scoped 665 namespace not directly routable from the client's local network. 667 The first approach leverages the NDN Link Object [SNAMP]. 668 Specifically, the ping client attaches to the expressed request a 669 LINK Object that contains a number of routable name prefixes, based 670 on which the request can be forwarded until it reaches a network 671 region where the request name itself is routable. A LINK Object is 672 created and signed by a data producer allowed to publish data under a 673 locally-scoped namespace. The way that a client retrieves a LINK 674 Object depends on various network design factors and is out of the 675 scope of the current draft. 677 Based on the current usage of the LINK Object by the NDN team, a 678 forwarder at the border of the region where an Interest name becomes 679 routable must remove the LINK Object from incoming Interests. The 680 Interest state maintained along the entire forwarding path is based 681 on the Interest name regardless of whether it was forwarded based on 682 its name or a routable prefix in the LINK Object. 684 The second approach is based on prepending a routable prefix to the 685 locally-scoped name. The resulting prefix will be the name of the 686 echo requests expressed by the client. In this way, a request will 687 be forwarded based on the routable part of its name. When it reaches 688 the network region where the original locally-scoped name is 689 routable, the border forwarder rewrites the request name and deletes 690 its routable part. There are two conditions for a forwarder to 691 perform this rewriting operation on a request: 1) the routable part 692 of the request name matches a routable name of the network region 693 adjacent to the forwarder (assuming that a forwarder is aware of 694 those names) and 2) the remaining part of the request name is 695 routable across the network region of this forwarder. 697 The state maintained along the path, where the locally-scoped name is 698 not routable, is based on the routable prefix along with the locally- 699 scoped prefix. Within the network region that the locally-scoped 700 prefix is routable, the state is based only on it. To ensure that 701 the generated replies reach the ping client, the border forwarder has 702 also to rewrite the name of a reply and prepend the routable prefix 703 of the corresponding echo request. 705 8. Security Considerations 707 A reflection attack could be mounted by a compromised forwarder in 708 the case of an echo reply with the CCNx packet format if that 709 forwarder includes in the reply the name of a victim forwarder. This 710 could convince a client to direct the future administrative traffic 711 towards the victim. To foil such reflection attacks, the forwarder 712 that generates a reply must sign the name included in the payload. 713 In this way, the client is able to verify that the included name is 714 legitimate and refers to the forwarder that generated the reply. 715 Alternatively, the forwarder could include in the reply payload their 716 routable prefix(es) encoded as a signed NDN Link Object [SNAMP]. 718 Interest flooding attack amplification is possible in the case of the 719 second approach to deal with locally-scoped namespaces described in 720 Section 7. To eliminate such amplification, a border forwarder will 721 have to maintain extra state in order to prepend the correct routable 722 prefix to the name of an outgoing reply, since the forwarder might be 723 attached to multiple network regions (reachable under different 724 prefixes) or a network region attached to this forwarder might be 725 reachable under multiple routable prefixes. 727 9. IANA Considerations 729 The exact numeric values of the field types of Echo requests and Echo 730 replies are to be assigned in the Packet Type IANA Registry for CCNx 731 (see section 4.1 of [RFC8569]. 733 10. Acknowledgements 735 The authors would like to thank Mark Stapp for the fruitful 736 discussion on the objectives of the ICN ping protocol. 738 11. References 740 11.1. Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, 744 DOI 10.17487/RFC2119, March 1997, 745 . 747 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 748 Networking (CCNx) Semantics", RFC 8569, 749 DOI 10.17487/RFC8569, July 2019, 750 . 752 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 753 Networking (CCNx) Messages in TLV Format", RFC 8609, 754 DOI 10.17487/RFC8609, July 2019, 755 . 757 [RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 758 D., and C. Tschudin, "Information-Centric Networking 759 (ICN): Content-Centric Networking (CCNx) and Named Data 760 Networking (NDN) Terminology", RFC 8793, 761 DOI 10.17487/RFC8793, June 2020, 762 . 764 11.2. Informative References 766 [I-D.irtf-icnrg-ccninfo] 767 Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering 768 Content and Network Information in Content-Centric 769 Networks", Work in Progress, Internet-Draft, draft-irtf- 770 icnrg-ccninfo-08, 27 July 2021, 771 . 774 [I-D.oran-icnrg-pathsteering] 775 Moiseenko, I. and D. Oran, "Path Steering in CCNx and 776 NDN", Work in Progress, Internet-Draft, draft-oran-icnrg- 777 pathsteering-04, 25 October 2021, 778 . 781 [NDNTLV] "NDN Packet Format Specification.", 2021, 782 . 784 [PATHSTEERING] 785 Moiseenko, I. and D. Oran, "Path switching in content 786 centric and named data networks", in Proceedings of the 787 4th ACM Conference on Information-Centric Networking, 788 2017. 790 [REALTIME] Mastorakis, S., Gusev, P., Afanasyev, A., and L. Zhang, 791 "Real-Time Data Retrieval in Named Data Networking", in 792 Proceedings of the 1st IEEE International Conference on 793 Hot Topics in Information-Centric Networking, 2017. 795 [SNAMP] Afanasyev, A. and , "SNAMP: Secure namespace mapping to 796 scale NDN forwarding", 2015. 798 Appendix A. Ping Client Application (Consumer) Operation 800 This section is an informative appendix regarding the proposed ping 801 client operation. 803 The ping client application is responsible for generating echo 804 requests for prefixes provided by users. 806 When generating a series of echo requests for a specific name, the 807 first echo request will typically not include a Path label TLV, since 808 no TLV value is known. After an echo reply containing a Path label 809 TLV is received, each subsequent echo request can include the 810 received path steering value in the Path label header TLV to drive 811 the requests towards a common path as part of checking network 812 performance. To discover more paths, a client can omit the path 813 steering TLV in future requests. Moreover, for each new ping echo 814 request, the client has to generate a new nonce and record the time 815 that the request was expressed. It will also set the lifetime of an 816 echo request, which will have identical semantics to the lifetime of 817 an Interest. 819 Further, the client application might not wish to receive echo 820 replies due to CS hits. A mechanism to achieve that in CCNx would be 821 to use a Content Object Hash Restriction TLV with a value of 0 in the 822 payload of an echo request message. In NDN, the exclude filter 823 selector can be used. 825 When it receives an echo reply, the client would typically match the 826 reply to a sent request and compute the round-trip time of the 827 request. It should parse the Path label value and decode the reply's 828 payload to parse the the sender's name and signature. The client 829 should verify that both the received message and the forwarder's name 830 have been signed by the key of the forwarder, whose name is included 831 in the payload of the reply (by fetching this forwarder's public key 832 and verifying the contained signature). The client can also decode 833 the Echo Reply Code TLV to understand the condition that triggered 834 the generation of the reply. 836 In the case that an echo reply is not received for a request within a 837 certain time interval (lifetime of the request), the client should 838 time-out and send a new request with a new nonce value up to some 839 maximum number of requests to be sent specified by the user. 841 Authors' Addresses 843 Spyridon Mastorakis 844 University of Nebraska at Omaha 845 Omaha, NE 846 United States of America 847 Email: smastorakis@unomaha.edu 849 Jim Gibson 850 Cisco Systems 851 Cambridge, MA 852 United States of America 853 Email: gibson@cisco.com 855 Ilya Moiseenko 856 Apple Inc 857 Cupertino, CA 858 United States of America 859 Email: iliamo@mailbox.org 860 Ralph Droms 861 Unaffiliated 862 Hopkinton, MA 863 United States of America 864 Email: rdroms.ietf@gmail.com 866 Dave Oran 867 Network Systems Research and Design 868 Cambridge, MA 869 United States of America 870 Email: daveoran@orandom.net