idnits 2.17.1 draft-mastorakis-icnrg-icntraceroute-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 13, 2020) is 1524 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 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, Omaha 4 Intended status: Experimental J. Gibson 5 Expires: August 16, 2020 Cisco Systems 6 I. Moiseenko 7 Apple Inc 8 R. Droms 9 Google Inc. 10 D. Oran 11 Network Systems Research and Design 12 February 13, 2020 14 ICN Traceroute Protocol Specification 15 draft-mastorakis-icnrg-icntraceroute-06 17 Abstract 19 This document presents the design of an ICN Traceroute protocol. 20 This includes the operations both on the client and the forwarder 21 side. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 16, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 59 2. Background on IP-Based Traceroute Operation . . . . . . . . . 3 60 3. Traceroute Functionality Challenges and Opportunities in ICN 3 61 4. ICN Traceroute CCNx Packet Format . . . . . . . . . . . . . . 5 62 4.1. ICN Traceroute Request CCNx Packet Format . . . . . . . . 6 63 4.2. Traceroute Reply CCNx Packet Format . . . . . . . . . . . 8 64 5. ICN Traceroute NDN Packet Format . . . . . . . . . . . . . . 11 65 5.1. ICN Traceroute Request NDN Packet Format . . . . . . . . 11 66 5.2. Traceroute Reply NDN Packet Format . . . . . . . . . . . 12 67 6. Forwarder Handling . . . . . . . . . . . . . . . . . . . . . 13 68 7. Protocol Operation For Locally-Scoped Namespaces . . . . . . 14 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 72 9.2. Informative References . . . . . . . . . . . . . . . . . 16 73 Appendix A. Traceroute Client Application (Consumer) Operation . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 In TCP/IP, routing and forwarding are based on IP addresses. To 79 ascertain the route to an IP address and to measure the transit 80 delays, the traceroute utility is commonly used. In ICN, routing and 81 forwarding are based on name prefixes. To this end, the problem of 82 ascertaining the characteristics (i.e., transit forwarders and 83 delays) of at least one of the available routes to a name prefix is a 84 fundamendal requirement for instumentation and network management. 86 This document describes protocol mechanisms for a traceroute 87 equivalent in ICN networks based on CCN or NDN. This document 88 contains a non-normative appendix section suggesting useful 89 properties for an ICN traceroute client application that originates 90 traceroute requests and processes traceroute replies. 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Background on IP-Based Traceroute Operation 100 In IP-based networks, traceroute is based on the expiration of the 101 Time To Live (TTL) IP header field. Specifically, a traceroute 102 client sends consecutive packets (depending on the implementation and 103 the user-specified behavior such packets can be either UDP datagrams, 104 ICMP Echo Request or TCP SYN packets) with a TTL value increased by 105 1, essentially, performing a expanding ring search. In this way, the 106 first IP packet sent will expire at the first router along the path, 107 the second IP packet at the second router along the path, etc, until 108 the router with the specified destination IP address is reached. 109 Each router along the path towards the destination, responds by 110 sending back an ICMP Time Exceeded packet, unless explicitly 111 prevented from doing so by a security policy . 113 The IP-based traceroute utility operates on IP addresses, and in 114 particular depends on the IP packets having source IP addresses that 115 are used as the destination address for replies. Given that ICN 116 forwards based on names rather than destination IP addresses, that 117 the names do not refer to unique endpoints (multi-destination), and 118 that the packets do not contain source addresses, a substantially 119 different approach is needed. 121 3. Traceroute Functionality Challenges and Opportunities in ICN 123 In NDN and CCN protocols, the communication paradigm is based 124 exclusively on named objects. An Interest is forwarded across the 125 network based on its name. Eventually, it retrieves a content object 126 either from a producer application or some forwarder's Content Store 127 (CS). 129 An ICN network differs from an IP network in at least 4 important 130 ways: 132 o IP identifies interfaces to an IP network with a fixed-length 133 number, and delivers IP packets to one or more interfaces. ICN 134 identifies units of data in the network with a variable length 135 name consisting of a hierarchical list of components. 137 o An IP-based network depends on the IP packets having source IP 138 addresses that are used as the destination address for replies. 139 On the other hand, ICN Interests do not have source addresses and 140 they are forwarded based on names, which do not refer to a unique 141 end-point. Data packets follow the reverse path of the Interests 142 based on hop-by-hop state created during Interest forwarding. 144 o An IP network supports multi-path, single destination, stateless 145 packet forwarding and delivery via unicast, a limited form of 146 multi-destination selected delivery with anycast, and group-based 147 multi-destination delivery via multicast. In contrast, ICN 148 supports multi-path and multi-destination stateful Interest 149 forwarding and multi-destination data delivery to units of named 150 data. This single forwarding semantic subsumes the functions of 151 unicast, anycast, and multicast. As a result, consecutive (or 152 retransmitted) ICN Interest messages may be forwarded through an 153 ICN network along different paths, and may be forwarded to 154 different data sources (e.g., end-node applications, in-network 155 storage) holding a copy of the requested unit of data. The 156 ability to discover multiple available (or potentially all) paths 157 towards a name prefix is a desirable capability for an ICN 158 traceroute protocol, since it can be beneficial for congestion 159 control purposes. Knowing the number of available paths for a 160 name can also be useful in cases that Interest forwarding based on 161 application semantics/preferences is desirable. 163 o In the case of multiple Interests with the same name arriving at a 164 forwarder, a number of Interests may be aggregated in a common 165 Pending Interest Table (PIT) entry. Depending on the lifetime of 166 a PIT entry, the round-trip time an Interest-Data exchange might 167 significantly vary (e.g., it might be shorter than the full round- 168 trip time to reach the original content producer). To this end, 169 the round-trip time experienced by consumers might also vary even 170 under constant network load. 172 These differences introduce new challenges, new opportunities and new 173 requirements in the design of ICN traceroute. Following this 174 communication model, a traceroute client should be able to express 175 traceroute requests directed to a name prefix and receive responses. 177 Our goals are the following: 179 o Trace one or more paths towards an ICN forwarder (for 180 troubleshooting purposes). 182 o Trace one or more paths along which an application can be reached 183 in the sense that Interest packets can be forwarded toward it. 185 o Test whether a specific named object is cached in some on-path CS, 186 and, if so, trace the path towards it and return the identity of 187 the corresponding forwarder. 189 o Perform transit delay network measurements. 191 To this end, a traceroute target name can represent: 193 o An administrative name that has been assigned to a forwarder. 194 Assigning a name to a forwarder implies the presence of a 195 management application running locally, which handles Operations, 196 Administration and Management (OAM) operations. 198 o A name that includes an application's namespace as a prefix. 200 o A named object that might reside in some in-network storage. 202 In order to provide stable and reliable diagnostics, it is desirable 203 that the packet encoding of a traceroute request enable the 204 forwarders to distinguish this request from a normal Interest, while 205 also preserving forwarding behavior as similar as possible to that 206 for an Interest packet. In the same way, the encoding of a 207 traceroute reply should allow for processing as similar as possible 208 to that of a data packet by the forwarders. 210 The term "traceroute session" is used for an iterative process during 211 which an endpoint client application generates a number of traceroute 212 requests to successively traverse more distant hops in the path until 213 it receives a final traceroute reply from a forwarder. It is 214 desirable that ICN traceroute be able to discover a number of paths 215 towards the expressed prefix within the same session or subsequent 216 sessions. To discover all the hops in a path, we need a mechanism 217 (Interest Steering) to steer requests along different paths. The 218 mechanism described in [PATHSTEERING] can be used for this purpose. 220 It is also important, in the case of traceroute requests for the same 221 prefix from different sources, to have a mechanism to avoid 222 aggregating those requests in the PIT. To this end, we need some 223 encoding in the traceroute requests to make each request for a common 224 prefix unique, and hence avoid PIT aggregation and further enabling 225 the exact matching of a response with a particular traceroute packet. 227 The packet types and format are presented in Section 4. The 228 procedures, e.g. the procedures for determining and indicating that a 229 destination has been reached, are specified in Section 6. 231 4. ICN Traceroute CCNx Packet Format 233 In this section, we present the CCNx packet format [CCNMessages] of 234 ICN traceroute, where messages exist within outermost containments 235 (packets). Specifically, we propose two types of traceroute packets, 236 a traceroute request and a traceroute reply packet type. 238 4.1. ICN Traceroute Request CCNx Packet Format 240 The format of the traceroute request packet is presented below: 242 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 244 +---------------+---------------+---------------+---------------+ 245 | | | | 246 | Version | TrRequest | PacketLength | 247 | | | | 248 +---------------+---------------+---------------+---------------+ 249 | | | | | 250 | HopLimit | Reserved | Flags | HeaderLength | 251 | | | | | 252 +---------------+---------------+---------------+---------------+ 253 / / 254 / PathSteering TLV / 255 / / 256 +---------------+---------------+---------------+---------------+ 257 | | 258 | Traceroute Request Message TLVs | 259 | | 260 +---------------+---------------+---------------+---------------+ 262 Traceroute Request CCNx Packet Format 264 The existing packet header fields have similar functionality to the 265 header fields of a CCNx Interest packet. The value of the packet 266 type field is TrRequest. The exact numeric value of this field type 267 is to be assigned in the Packet Type IANA Registry for CCNx (see 268 section 4.1 of [CCNMessages]. 270 Compared to the typical format of a CCNx packet header [CCNMessages], 271 there is a new optional fixed header TLV added to the packet header: 273 o A Path Steering hop-by-hop header TLV, which is constructed hop- 274 by-hop in the traceroute reply and included in the traceroute 275 request to steer consecutive requests expressed by a client 276 towards a common or different forwarding paths. An example of 277 such a scheme is presented in [PATHSTEERING]. 279 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 281 +---------------+---------------+---------------+---------------+ 282 | | | 283 | PathSteering_Type | PathSteering_Length | 284 | | | 285 +---------------+---------------+---------------+---------------+ 286 | | 287 | PathSteering_Value | 288 | | 289 +---------------+---------------+---------------+---------------+ 291 Path Steering TLV 293 The message of a traceroute request is presented below: 295 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 297 +---------------+---------------+---------------+---------------+ 298 | | | 299 | MessageType = 1 | MessageLength | 300 | | | 301 +---------------+---------------+---------------+---------------+ 302 | | 303 | Name TLV | 304 | | 305 +---------------+---------------+---------------+---------------+ 307 Traceroute Request Message Format 309 The traceroute request message is of type Interest in order to 310 leverage the Interest forwarding behavior provided by the network. 311 The Name TLV has the structure described in [CCNMessages]. The name 312 consists of the target (destination) prefix appended with a nonce 313 typed name component as its last component (to avoid Interest 314 aggregation and allow exact matching of requests with responses). 315 The value of this TLV is a 64-bit nonce. 317 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 319 +---------------+---------------+---------------+---------------+ 320 | | | 321 | Name_Nonce_Type | Name_Nonce_Length = 8 | 322 | | | 323 +---------------+---------------+---------------+---------------+ 324 | | 325 | | 326 | | 327 | Name_Nonce_Value | 328 | | 329 | | 330 +---------------+---------------+---------------+---------------+ 332 Name Nonce Typed Component TLV 334 4.2. Traceroute Reply CCNx Packet Format 336 The format of a traceroute reply packet is presented below: 338 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 340 +---------------+---------------+---------------+---------------+ 341 | | | | 342 | Version | TrReply | PacketLength | 343 | | | | 344 +---------------+---------------+---------------+---------------+ 345 | | | | 346 | Reserved | Flags | HeaderLength | 347 | | | | 348 +---------------+---------------+---------------+---------------+ 349 | | 350 | PathSteering TLV | 351 | | 352 +---------------+---------------+---------------+---------------+ 353 | | 354 | Traceroute Reply Message TLVs | 355 | | 356 +---------------+---------------+---------------+---------------+ 358 Traceroute Reply CCNx Packet Format 360 The header of a traceroute reply consists of the header fields of a 361 CCNx Content Object and a hop-by-hop path steering TLV. The value of 362 the packet type field is TrReply. The exact numeric value of this 363 field type is to be assigned in the Packet Type IANA Registry for 364 CCNx (see section 4.1 of [CCNMessages]. 366 A traceroute reply message is of type Content Object, contains a Name 367 TLV (name of the corresponding traceroute request), a PayloadType TLV 368 and an ExpiryTime TLV with a value of 0 to indicate that replies must 369 not be returned from network caches. 371 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 373 +---------------+---------------+---------------+---------------+ 374 | | | 375 | MessageType = 2 | MessageLength | 376 | | | 377 +---------------+---------------+---------------+---------------+ 378 | | 379 | Name TLV | 380 | | 381 +---------------+---------------+---------------+---------------+ 382 | | 383 | PayloadType TLV | 384 | | 385 +---------------+---------------+---------------+---------------+ 386 | | 387 | ExpiryTime TLV | 388 | | 389 +---------------+---------------+---------------+---------------+ 391 Traceroute Reply Message Format 393 The PayloadType TLV is presented below. It is of type 394 T_PAYLOADTYPE_DATA, and the data schema consists of 2 TLVs: 1) the 395 name of the sender of this reply (with the same structure as a CCNx 396 Name TLV), 2) the sender's signature of their own name (with the same 397 structure as a CCNx ValidationPayload TLV), 3) a TLV with return 398 codes to indicate whether the request was satisfied due to the 399 existence of a local application, a CS hit or a match with a 400 forwarder's name, or the HopLimit value of the corresponding request 401 reached 0. 403 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 405 +---------------+---------------+---------------+---------------+ 406 | | | 407 | T_PAYLOADTYPE_DATA | Length | 408 | | | 409 +---------------+---------------+---------------+---------------+ 410 | | 411 | Sender's Name TLV | 412 | | 413 +---------------+---------------+---------------+---------------+ 414 | | 415 | Sender's Signature TLV | 416 | | 417 +---------------+---------------+---------------+---------------+ 418 | | 419 | TrReply Code TLV | 420 | | 421 +---------------+---------------+---------------+---------------+ 423 Traceroute Reply Message Format 425 The goal of including the name of the sender in the reply is to 426 enable the user to reach this entity directly to ask for further 427 management/administrative information using generic Interest-Data 428 exchanges or by employing a more comprehensive management tool such 429 as CCNInfo [CCNInfo] after a successful verification of the sender's 430 name. 432 The structure of the TrReply Code TLV is presented below (16-bit 433 value). The potential values are the following: 435 o 1: Indicates that the target name matched the administrative name 436 of a forwarder (as served by its internal management application). 438 o 2: Indicates that the target name matched a prefix served by an 439 application (other than the internal management application of a 440 forwarder). 442 o 3: Indicates that the target name matched the name of an object in 443 a forwarder's CS. 445 o 4: Indicates that the the Hop limit reached the 0 value. 447 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 449 +---------------+---------------+---------------+---------------+ 450 | | | 451 | TrReply_Code_Type | TrReply_Code_Length = 2 | 452 | | | 453 +---------------+---------------+---------------+---------------+ 454 | | 455 | TrReply_Code_Value | 456 +---------------+---------------+---------------+---------------+ 458 TrReply Code TLV 460 5. ICN Traceroute NDN Packet Format 462 In this section, we present the ICN traceroute Request and Reply 463 Format according to the NDN packet specification [NDNTLV]. 465 5.1. ICN Traceroute Request NDN Packet Format 467 A traceroute request is encoded as an NDN Interest packet. Its 468 format is the following: 470 TracerouteRequest ::= INTEREST-TYPE TLV-LENGTH 471 Name 472 MustBeFresh 473 Nonce 474 HopLimit 475 Parameters? 477 Traceroute Request NDN Packet Format 479 The name of a request consists of the target name, a nonce value (it 480 can be the value of the Nonce field) and the suffix "traceroute" to 481 denote that this Interest is a traceroute request. 483 The "Paremeters" field of the Request contains the following 484 PathSteering TLV: 486 PathSteering TLV ::= PATHSTEERING-TLV-TYPE TLV-LENGTH BYTE{8} 488 PathSteering TLV 490 Since the NDN packet format does provide a mechanism to prevent the 491 network from caching specific data packets, we will use the 492 MustBeFresh selector for requests (in combination with a Freshness 493 Period TLV of value 0 for replies) to avoid fetching cached 494 traceroute replies with a freshness period that has expired 495 [REALTIME]. 497 5.2. Traceroute Reply NDN Packet Format 499 A traceroute reply is encoded as an NDN Data packet. Its format is 500 the following: 502 TracerouteReply ::= DATA-TLV TLV-LENGTH 503 PathSteering TLV 504 Name 505 MetaInfo 506 Content 507 Signature 509 Traceroute Reply NDN Packet Format 511 Compared to the format of a regular NDN Data packet, a traceroute 512 reply contains a PathSteering TLV field, which is not included in the 513 security envelope, since it might be modified in a hop-by-hop fashion 514 by the forwarders along the reverse path. 516 The name of a traceroute reply is the name of the corresponding 517 traceroute request, while the format of the MetaInfo field is the 518 following: 520 MetaInfo ::= META-INFO-TYPE TLV-LENGTH 521 ContentType 522 FreshnessPeriod 524 MetaInfo TLV 526 The value of the ContentType TLV is 0. The same applies to the value 527 of the FreshnessPeriod TLV, so that the replies are treated as stale 528 data as soon as they are received by a forwarder. 530 The content of a traceroute reply consists of the following 2 TLVs: 531 Sender's name (an NDN Name TLV) and Traceroute Reply Code. There is 532 no need to have a separate TLV for the sender's signature in the 533 content of the reply, since every NDN data packet carries the 534 signature of the data producer. 536 The Traceroute Reply Code TLV format is the following (with the 537 values specified in Section 4.2): 539 TrReplyCode ::= TRREPLYCODE-TLV-TYPE TLV-LENGTH BYTE{2} 541 Traceroute Reply Code TLV 543 6. Forwarder Handling 545 When a forwarder receives a traceroute request, the hop limit value 546 is checked and decremented and the target name (i.e, the name of the 547 traceroute request without the last nonce name component and the 548 suffix "traceroute" in the case of a request with the NDN packet 549 format) is extracted. 551 If the HopLimit has not expired (its value is greater than 0), the 552 forwarder will forward the request upstream based on CS lookup, PIT 553 creation, LPM lookup and the path steering value, if present. If no 554 valid next-hop is found, an InterestReturn indicating "No Route" in 555 the case of CCNx or a network NACK in the case of NDN is sent 556 downstream. 558 If the HopLimit value is equal to zero, the forwarder generates a 559 traceroute reply. This reply includes the forwarder's administrative 560 name and signature, and a PathSteering TLV. This TLV initially has a 561 null value since the traceroute reply originator does not forward the 562 request and, thus, does not make a path choice. The reply will also 563 include the corresponding TrReply Code TLV. 565 A traceroute reply will be the final reply of a traceroute session if 566 any of the following conditions are met: 568 o If a forwarder has been given one or more administrative names, 569 the target name matches one of them. 571 o The target name exactly matches the name of a content-object 572 residing in the forwarder's CS (unless the traceroute client 573 application has chosen not to receive replies due to CS hits as 574 specified in Appendix A). 576 o The target name matches (in a Longest Prefix Match manner) a FIB 577 entry with an outgoing face referring to a local application. 579 The TrReply Code TLV value of the reply is set to indicate the 580 specific condition that was met. If none of those conditions was 581 met, the TrReply Code is set to 4 to indicate that the hop limit 582 value reached 0. 584 A received traceroute reply will be matched to an existing PIT entry 585 as usual. On the reverse path, the path steering TLV of a reply will 586 be updated by each forwarder to encode its choice of next-hop(s). 588 When included in subsequent requests, this path steering TLV allows 589 the forwarders to steer the requests along the same path. 591 7. Protocol Operation For Locally-Scoped Namespaces 593 In this section, we elaborate on 2 alternative design approaches in 594 cases that the traceroute target prefix corresponds to a locally- 595 scoped namespace not directly routable from the client's local 596 network. 598 The first approach leverages the NDN Link Object [SNAMP]. 599 Specifically, the traceroute client attaches to the expressed request 600 a LINK Object that contains a number of routable name prefixes, based 601 on which the request can be forwarded across the Internet until it 602 reaches a network region, where the request name itself is routable. 603 A LINK Object is created and signed by a data producer allowed to 604 publish data under a locally-scoped namespace. The way that a client 605 retrieves a LINK Object depends on various network design factors and 606 is out of the scope of the current draft. 608 Based on the current deployment of the LINK Object by the NDN team, a 609 forwarder at the border of the region, where an Interest name becomes 610 routable has to remove the LINK Object from the incoming Interests. 611 The Interest state maintained along the entire forwarding path is 612 based on the Interest name regardless of whether it was forwarded 613 based on this name or a prefix in the LINK Object. 615 The second approach is based on prepending a routable prefix to the 616 locally-scoped name. The resulting prefix will be the name of the 617 traceroute requests expressed by the client. In this way, a request 618 will be forwarded based on the routable part of its name. When it 619 reaches the network region where the original locally-scoped name is 620 routable, the border forwarder rewrites the request name and deletes 621 its routable part. There are two conditions for a forwarder to 622 perform this rewriting operation on a request: 1) the routable part 623 of the request name matches a routable name of the network region 624 adjacent to the forwarder (assuming that a forwarder is aware of 625 those names) and 2) the remaining part of the request name is 626 routable across the network region of this forwarder. 628 The state maintained along the path, where the locally-scoped name is 629 not routable, is based on the routable prefix along with the locally- 630 scoped prefix, while within the network region that the locally- 631 scoped prefix is routable is based only on it. To ensure that the 632 generated replies will reach the client, the border forwarder has 633 also to rewrite the name of a reply and prepend the routable prefix 634 of the corresponding request. 636 8. Security Considerations 638 A reflection attack could occur in the case of a traceroute reply 639 with the CCNx packet format if a compromised forwarder includes in 640 the reply the name of a victim forwarder. This could redirect the 641 future administrative traffic towards the victim. To foil such 642 reflection attacks, the forwarder that generates a traceroute reply 643 must sign the name included in the payload. In this way, the client 644 is able to verify that the included name is legitimate and refers to 645 the forwarder that generated the reply. Alternatively, the forwarder 646 could include in the reply payload their routable prefix(es) encoded 647 as a signed NDN Link Object [SNAMP]. 649 This approach does not protect against on-path attacks, where a 650 compromised forwarder that receives a traceroute reply replaces the 651 forwarder's name and the signature in the message with its own name 652 and signature to make the client believe that the reply was generated 653 by the compromised forwarder. To foil such attack scenarios, a 654 forwarder can sign the reply message itself. In such cases, the 655 forwarder does not have to sign its own name in reply message, since 656 the message signature protects the message as a whole and will be 657 invalidated in the case of an on-path attack. 659 Signing each traceroute reply message can be expensive and can 660 potentially lead to computation attacks against forwarders. To 661 mitigate such attack scenarios, the processing of traceroute requests 662 and the generation of the replies can be handled by a separate 663 management application running locally on each forwarder. Serving 664 traceroute replies therefore is thereby separated from load on the 665 forwarder itself. The approaches used by ICN applications to manage 666 load may also apply to the forwarder's management application. 668 Interest flooding attack amplification is possible in the case of the 669 second approach to deal with locally-scoped namespaces described in 670 Section 7. A border forwarder will have to maintain extra state to 671 prepend the correct routable prefix to the name of an outgoing reply, 672 since the forwarder might be attached to multiple network regions 673 (reachable under different prefixes) or a network region attached to 674 this forwarder might be reachable under multiple routable prefixes. 676 We also note that traceroute requests have the same privacy 677 characteristics as regular Interests. 679 9. References 680 9.1. Normative References 682 [CCNMessages] 683 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 684 Format.", 2018, . 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 9.2. Informative References 694 [CCNInfo] Asaeda, H. and X. Shao, "CCNinfo: Discovering Content and 695 Network Information in Content-Centric Networks.", 2018, 696 . 699 [NDNTLV] "NDN Packet Format Specification.", 2016, 700 . 702 [PATHSTEERING] 703 Moiseenko, I. and D. Oran, "Path switching in content 704 centric and named data networks in Proceedings of the 4th 705 ACM Conference on Information-Centric Networking", 2017. 707 [REALTIME] 708 Mastorakis, S., Gusev, P., Afanasyev, A., and L. Zhang, 709 "Real-Time Data Retrieval in Named Data Networking in 710 Proceedings of the 1st IEEE International Conference on 711 Hot Topics in Information-Centric Networking", 2017. 713 [SNAMP] Afanasyev, A. and , "SNAMP: Secure namespace mapping to 714 scale NDN forwarding, IEEE Conference on Computer 715 Communications Workshops (INFOCOM WKSHPS)", 2015. 717 Appendix A. Traceroute Client Application (Consumer) Operation 719 This section is an informative appendix regarding the proposed 720 traceroute client operation. 722 The client application is responsible for generating traceroute 723 requests for prefixes provided by users. 725 The overall process can be iterative: The first traceroute request of 726 each session will have a HopLimit of value 1 to reach the first hop 727 forwarder, the second of value 2 to reach the second hop forwarder 728 and so on and so forth. 730 When generating a series of requests for a specific name, the first 731 one will typically not include a PathSteering TLV, since no TLV value 732 is known. After a traceroute reply containing a PathSteering TLV is 733 received, each subsequent request might include the received path 734 steering value in the PathSteering header TLV to drive the requests 735 towards a common path as part of checking the network performance. 736 To discover more paths, a client can omit the PathSteering TLV in 737 future requests. Moreover, for each new traceroute request, the 738 client has to generate a new nonce and record the time that the 739 request was expressed. It will also set the lifetime of a request, 740 which will have semantics similar to the lifetime of an Interest. 742 Moreover, the client application might not wish to receive replies 743 due to CS hits. In CCNx, a mechanism to achieve that would be to use 744 a Content Object Hash Restriction TLV with a value of 0 in the 745 payload of a traceroute request message. In NDN, the exclude filter 746 selector can be used. 748 When it receives a traceroute reply, the client would typically match 749 the reply to a sent request and compute the round-trip time of the 750 request. It should parse the PathSteering value and decode the 751 reply's payload to parse the the sender's name and signature. The 752 client should verify that both the received message and the 753 forwarder's name have been signed by the key of the forwarder, whose 754 name is included in the payload of the reply (by fetching this 755 forwarder's public key and verifying the contained signature). In 756 the case that the client receives an TrReply Code TLV with a valid 757 value, it can stop sending requests with increasing HopLimit values 758 and potentially start a new traceroute session. 760 In the case that a traceroute reply is not received for a request 761 within a certain time interval (lifetime of the request), the client 762 should time-out and send a new request with a new nonce value up to a 763 maximum number of requests to be sent specified by the user. 765 Authors' Addresses 767 Spyridon Mastorakis 768 University of Nebraska, Omaha 769 Omaha, NE 770 US 772 Email: smastorakis@unomaha.edu 773 Jim Gibson 774 Cisco Systems 775 Cambridge, MA 776 US 778 Email: gibson@cisco.com 780 Ilya Moiseenko 781 Apple Inc 782 Cupertino, CA 783 US 785 Email: iliamo@mailbox.org 787 Ralph Droms 788 Google Inc. 789 Cambridge, MA 790 US 792 Email: rdroms.ietf@gmail.com 794 Dave Oran 795 Network Systems Research and Design 796 Cambridge, MA 797 US 799 Email: daveoran@orandom.net