diff options
Diffstat (limited to 'doc/rfc/rfc9507.txt')
| -rw-r--r-- | doc/rfc/rfc9507.txt | 863 |
1 files changed, 863 insertions, 0 deletions
diff --git a/doc/rfc/rfc9507.txt b/doc/rfc/rfc9507.txt new file mode 100644 index 0000000..19f7a32 --- /dev/null +++ b/doc/rfc/rfc9507.txt @@ -0,0 +1,863 @@ + + + + +Internet Research Task Force (IRTF) S. Mastorakis +Request for Comments: 9507 University of Notre Dame +Category: Experimental D. Oran +ISSN: 2070-1721 Network Systems Research and Design + I. Moiseenko + Apple Inc. + J. Gibson + R. Droms + Unaffiliated + March 2024 + + + Information-Centric Networking (ICN) Traceroute Protocol Specification + +Abstract + + This document presents the design of an Information-Centric + Networking (ICN) Traceroute protocol. This includes the operation of + both the client and the forwarder. + + This document is a product of the Information-Centric Networking + Research Group (ICNRG) of the IRTF. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the consensus of the + Information-Centric Networking Research Group of the Internet + Research Task Force (IRTF). Documents approved for publication by + the IRSG are not candidates for any level of Internet Standard; see + Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9507. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 1.1. Requirements Language + 2. Background on IP-Based Traceroute Operation + 3. Traceroute Functionality Challenges and Opportunities in ICN + 4. ICN Traceroute CCNx Packet Formats + 4.1. ICN Traceroute Request CCNx Packet Format + 4.2. ICN Traceroute Reply CCNx Packet Format + 5. ICN Traceroute NDN Packet Formats + 5.1. ICN Traceroute Request NDN Packet Format + 5.2. ICN Traceroute Reply NDN Packet Format + 6. Forwarder Operation + 7. Protocol Operation for Locally Scoped Namespaces + 8. Security Considerations + 9. IANA Considerations + 10. References + 10.1. Normative References + 10.2. Informative References + Appendix A. Traceroute Client Application (Consumer) Operation + Authors' Addresses + +1. Introduction + + In TCP/IP, routing and forwarding are based on IP addresses. To + ascertain the route to an IP address and to measure the transit + delays, the traceroute utility is commonly used. In Information- + Centric Networking (ICN), routing and forwarding are based on name + prefixes. To this end, the ability to ascertain the characteristics + of at least one of the available routes to a name prefix is a + fundamental requirement for instrumentation and network management. + These characteristics include, among others, route properties such as + which forwarders were transited and the delay incurred through + forwarding. + + In order to carry out meaningful experimentation and deployment of + ICN protocols, new tools analogous to ping and traceroute used for + TCP/IP are needed to manage and debug the operation of ICN + architectures and protocols. This document describes the design of a + management and debugging protocol analogous to the traceroute + protocol of TCP/IP; this new management and debugging protocol will + aid the experimental deployment of ICN protocols. As the community + continues its experimentation with ICN architectures and protocols, + the design of ICN Traceroute might change accordingly. ICN + Traceroute is designed as a tool to troubleshoot ICN architectures + and protocols. As such, this document is classified as an + Experimental RFC. + + This specification uses the terminology defined in [RFC8793]. + + This RFC represents the consensus of the Information-Centric + Networking Research Group (ICNRG) of the Internet Research Task Force + (IRTF). + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Background on IP-Based Traceroute Operation + + In IP-based networks, traceroute is based on the expiration of the + Time To Live (TTL) IP header field. Specifically, a traceroute + client sends consecutive packets (depending on the implementation and + the user-specified behavior, such packets can be either UDP + datagrams, ICMP Echo Request packets, or TCP SYN packets) with a TTL + value increased by 1, essentially performing an expanding ring + search. In this way, the first IP packet sent will expire at the + first router along the path, the second IP packet at the second + router along the path, etc., until the router (or host) with the + specified destination IP address is reached. Each router along the + path towards the destination responds by sending back an ICMP Time + Exceeded packet, unless explicitly prevented from doing so by a + security policy. + + The IP-based traceroute utility operates on IP addresses and in + particular depends on the IP packets having source IP addresses that + are used as the destination address for replies. Given that ICN + forwards based on names rather than destination IP addresses, that + the names do not refer to unique endpoints (multi-destination), and + that the packets do not contain source addresses, a substantially + different approach is needed. + +3. Traceroute Functionality Challenges and Opportunities in ICN + + In the Named Data Networking (NDN) and Content-Centric Networking + (CCNx) protocols, the communication paradigm is based exclusively on + named objects. An Interest message is forwarded across the network + based on its name. Eventually, it retrieves a Content Object from + either a producer application or some forwarder's Content Store (CS). + + An ICN network differs from an IP network in at least four important + ways (four of which are as follows): + + * IP identifies interfaces to an IP network with a fixed-length + address and delivers IP packets to one or more interfaces. ICN + identifies units of data in the network with a variable-length + name consisting of a hierarchical list of segments. + + * An IP-based network depends on the IP packets having source IP + addresses that are used as the destination address for replies. + On the other hand, ICN Interests do not have source addresses, and + they are forwarded based on names, which do not refer to a unique + endpoint. Data packets follow the reverse path of the Interests + based on hop-by-hop state created during Interest forwarding. + + * An IP network supports multi-path, single-destination, stateless + packet forwarding and delivery via unicast; a limited form of + multi-destination selected delivery with anycast; and group-based + multi-destination delivery via multicast. In contrast, ICN + supports multi-path and multi-destination stateful Interest + forwarding and multi-destination data delivery to units of named + data. This single forwarding semantic subsumes the functions of + unicast, anycast, and multicast. As a result, consecutive (or + retransmitted) ICN Interest messages may be forwarded through an + ICN network along different paths and may be forwarded to + different data sources (e.g., end-node applications, in-network + storage) holding a copy of the requested unit of data. The + ability to discover multiple available (or potentially all) paths + towards a name prefix is a desirable capability for an ICN + Traceroute protocol, since it can be beneficial for congestion + control purposes. Knowing the number of available paths for a + name can also be useful in cases where Interest forwarding based + on application semantics/preferences is desirable. + + * In the case of multiple Interests with the same name arriving at a + forwarder, a number of Interests may be aggregated in a common + Pending Interest Table (PIT) entry. Depending on the lifetime of + a PIT entry, the round-trip time of an Interest-Data exchange + might vary significantly (e.g., it might be shorter than the full + round-trip time to reach the original content producer). To this + end, the round-trip time experienced by consumers might also vary + even under constant network load. + + These differences introduce new challenges, new opportunities, and + new requirements regarding the design of ICN Traceroute. Following + this communication model, a traceroute client should be able to + express traceroute requests directed to a name prefix and receive + responses. + + Our goals are as follows: + + * Trace one or more paths towards an ICN forwarder (for + troubleshooting purposes). + + * Trace one or more paths through which a named data object can be + reached in the sense that Interest packets can be forwarded + towards the application hosting the object. + + * Test whether a specific named object is cached in some on-path CS, + and, if so, trace the path towards it and return the identity of + the corresponding forwarder. + + * Perform transit delay network measurements. + + To this end, a traceroute target name can represent: + + * An administrative name that has been assigned to a forwarder. + Assigning a name to a forwarder implies the presence of a + management application running locally that handles Operations, + Administration, and Maintenance (OAM) operations. + + * A name that includes an application's namespace as a prefix. + + * A named object that might reside in some in-network storage. + + In order to provide stable and reliable diagnostics, it is desirable + that the packet encoding of a traceroute request enable the + forwarders to distinguish this request from a normal Interest while + also diverging as little as possible from the forwarding behavior for + an Interest packet. In the same way, the encoding of a traceroute + reply should minimize any processing differences from those employed + for a data packet by the forwarders. + + The term "traceroute session" is used for an iterative process during + which an endpoint client application generates a number of traceroute + requests to successively traverse more distant hops in the path until + it receives a final traceroute reply from a forwarder. It is + desirable that ICN Traceroute be able to discover a number of paths + towards the expressed prefix within the same session or subsequent + sessions. To discover all the hops in a path, we need a mechanism + (Interest Steering) to steer requests along different paths. Such a + capability was initially published in [PATHSTEERING] and has been + specified for CCNx and NDN in [RFC9531]. + + In the case of traceroute requests for the same prefix from different + sources, it is also important to have a mechanism to avoid + aggregating those requests in the PIT. To this end, we need some + encoding in the traceroute requests to make each request for a common + prefix unique, hence avoiding PIT aggregation and further enabling + the exact matching of a response with a particular traceroute packet. + + The packet types and formats are presented in Section 4. Procedures + for determining and indicating that a destination has been reached + are included in Section 6. + +4. ICN Traceroute CCNx Packet Formats + + In this section, we present the CCNx packet formats [RFC8609] of ICN + Traceroute where messages exist within outermost containments + (packets). Specifically, we propose two types of traceroute packets: + a traceroute request and a traceroute reply. + +4.1. ICN Traceroute Request CCNx Packet Format + + The format of the traceroute request packet is presented below: + + 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 + +---------------+---------------+---------------+---------------+ + | | | | + | Version | PT_TR_REQUEST | PacketLength | + | | | | + +---------------+---------------+---------------+---------------+ + | | | | | + | HopLimit | Reserved | Flags | HeaderLength | + | | | | | + +---------------+---------------+---------------+---------------+ + / / + / Path Label TLV / + / / + +---------------+---------------+---------------+---------------+ + | | + | Traceroute Request Message TLVs | + | | + +---------------+---------------+---------------+---------------+ + + Figure 1: Traceroute Request CCNx Packet Format + + The existing packet header fields have functionality similar to that + of the header fields of a CCNx Interest packet. The value of the + packet type field is PT_TR_REQUEST. See Section 9 for the value + assignment. + + In contrast to the typical format of a CCNx packet header [RFC8609], + there is a new optional fixed header added to the packet header: + + * A Path Steering hop-by-hop header TLV, which is constructed hop by + hop in the traceroute reply and included in the traceroute request + to steer consecutive requests expressed by a client towards a + common forwarding path or different forwarding paths. The Path + Label TLV is specified in [RFC9531]. + + The message of a traceroute request is presented below: + + 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 + +---------------+---------------+---------------+---------------+ + | | | + | MessageType = 0x05 | MessageLength | + | | | + +---------------+---------------+---------------+---------------+ + | | + | Name TLV | + | | + +---------------+---------------+---------------+---------------+ + + Figure 2: Traceroute Request Message Format + + The traceroute request message is of type T_DISCOVERY. The Name TLV + has the structure described in [RFC8609]. The name consists of the + target (destination) prefix appended with a nonce typed name as its + last segment. The nonce can be encoded as a base64-encoded string + with the URL-safe alphabet as defined in Section 5 of [RFC4648], with + padding omitted. The format of this TLV is a 64-bit nonce. See + [RFC9508] for the value assignment. The purpose of the nonce is to + avoid Interest aggregation and allow client matching of replies with + requests. As described below, the nonce is ignored for CS checking. + + 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 + +---------------+---------------+---------------+---------------+ + | | | + | Name_Nonce_Type | Name_Nonce_Length = 8 | + | | | + +---------------+---------------+---------------+---------------+ + | | + | | + | | + | Name_Nonce_Value | + | | + | | + +---------------+---------------+---------------+---------------+ + + Figure 3: Name Nonce Typed Segment TLV + +4.2. ICN Traceroute Reply CCNx Packet Format + + The format of a traceroute reply packet is presented below: + + 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 + +---------------+---------------+---------------+---------------+ + | | | | + | Version | PT_TR_REPLY | PacketLength | + | | | | + +---------------+---------------+---------------+---------------+ + | | | | + | Reserved | Flags | HeaderLength | + | | | | + +---------------+---------------+---------------+---------------+ + | | + | Path Label TLV | + | | + +---------------+---------------+---------------+---------------+ + | | + | Traceroute Reply Message TLVs | + | | + +---------------+---------------+---------------+---------------+ + + Figure 4: Traceroute Reply CCNx Packet Format + + The header of a traceroute reply consists of the header fields of a + CCNx Content Object and a hop-by-hop Path Steering TLV. The value of + the packet type field is PT_TR_REPLY. See Section 9 for the value + assignment. + + A traceroute reply message is of type T_OBJECT and contains a Name + TLV (name of the corresponding traceroute request), a PayloadType + TLV, and an ExpiryTime TLV with a value of 0 to indicate that replies + must not be returned from network caches. + + 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 + +---------------+---------------+---------------+---------------+ + | | | + | MessageType = 0x06 | MessageLength | + | | | + +---------------+---------------+---------------+---------------+ + | | + | Name TLV | + | | + +---------------+---------------+---------------+---------------+ + | | + | PayloadType TLV | + | | + +---------------+---------------+---------------+---------------+ + | | + | ExpiryTime TLV | + | | + +---------------+---------------+---------------+---------------+ + + Figure 5: Traceroute Reply Message Format + + The PayloadType TLV is presented below. It is of type + T_PAYLOADTYPE_DATA, and the data schema consists of three TLVs: + + 1) the name of the sender of this reply (with the same structure as + a CCNx Name TLV), + + 2) the sender's signature of their own name (with the same structure + as a CCNx ValidationPayload TLV), and + + 3) a TLV with return codes to indicate whether the request was + satisfied due to the existence of a local application, a CS hit, + a match with a forwarder's name, or the HopLimit value of the + corresponding request reaching 0. + + 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 + +---------------+---------------+---------------+---------------+ + | | | + | T_PAYLOADTYPE_DATA | Length | + | | | + +---------------+---------------+---------------+---------------+ + | | + | Sender's Name TLV | + | | + +---------------+---------------+---------------+---------------+ + | | + | Sender's Signature TLV | + | | + +---------------+---------------+---------------+---------------+ + | | + | PT_TR_REPLY Code TLV | + | | + +---------------+---------------+---------------+---------------+ + + Figure 6: Traceroute Reply PayloadType TLV Format + + The goal of including the name of the sender in the reply is to + enable the user to reach this entity directly to ask for further + management/administrative information using generic Interest-Data + exchanges or by employing a more comprehensive management tool, such + as CCNinfo [RFC9344], after a successful verification of the sender's + name. + + The structure of the PT_TR_REPLY Code TLV is presented below (16-bit + value). The four assigned values are as follows: + + 1: Indicates that the target name matched the administrative name of + a forwarder (as served by its internal management application). + + 2: Indicates that the target name matched a prefix served by an + application (other than the internal management application of a + forwarder). + + 3: Indicates that the target name matched the name of an object in a + forwarder's CS. + + 4: Indicates that the HopLimit reached 0. + + 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 + +---------------+---------------+---------------+---------------+ + | | | + | PT_TR_REPLY_Code_Type | PT_TR_REPLY_Code_Length = 2 | + | | | + +---------------+---------------+---------------+---------------+ + | | + | PT_TR_REPLY_Code_Value | + | | + +---------------+---------------+---------------+---------------+ + + Figure 7: PT_TR_REPLY Code TLV + +5. ICN Traceroute NDN Packet Formats + + In this section, we present the ICN Traceroute Request and Reply + packet formats according to the NDN packet format specification + [NDNTLV]. + +5.1. ICN Traceroute Request NDN Packet Format + + A traceroute request is encoded as an NDN Interest packet. Its + format is as follows: + + TracerouteRequest = INTEREST-TYPE TLV-LENGTH + Name + MustBeFresh + Nonce + HopLimit + ApplicationParameters? + + Figure 8: Traceroute Request NDN Packet Format + + The name of a request consists of the target name, a nonce value (it + can be the value of the Nonce field), and the suffix "traceroute" to + denote that this Interest is a traceroute request (added as a + KeywordNameComponent [NDNTLV]). When the "ApplicationParameters" + element is present, a ParametersSha256DigestComponent (Section 6) is + added as the last name segment. + + A traceroute request MAY carry a Path Label TLV in the NDN Link + Adaptation Protocol [NDNLPv2] as specified in [RFC9531]. + + Since the NDN packet format does not provide a mechanism to prevent + the network from caching specific data packets, we instead use the + MustBeFresh TLV for requests (in combination with a FreshnessPeriod + TLV with a value of 1 for replies) to avoid fetching cached + traceroute replies with a freshness period that has expired + [REALTIME]. + +5.2. ICN Traceroute Reply NDN Packet Format + + A traceroute reply is encoded as an NDN Data packet. Its format is + as follows: + + TracerouteReply = DATA-TLV TLV-LENGTH + Name + MetaInfo + Content + Signature + + Figure 9: Traceroute Reply NDN Packet Format + + A traceroute reply MAY carry a Path Label TLV in the NDN Link + Adaptation Protocol [NDNLPv2] as specified in [RFC9531], since it + might be modified in a hop-by-hop fashion by the forwarders along the + reverse path. + + The name of a traceroute reply is the name of the corresponding + traceroute request while the format of the MetaInfo field is as + follows: + + MetaInfo = META-INFO-TYPE TLV-LENGTH + ContentType + FreshnessPeriod + + Figure 10: MetaInfo TLV + + The value of the ContentType TLV is 0. The value of the + FreshnessPeriod TLV is 1, so that the replies are treated as stale + data (almost instantly) as they are received by a forwarder. + + The content of a traceroute reply consists of the following two TLVs: + Sender's Name (an NDN Name TLV) and Traceroute Reply Code. There is + no need to have a separate TLV for the sender's signature in the + content of the reply, since every NDN Data packet carries the + signature of the data producer. + + The Traceroute Reply Code TLV format is as follows (with the values + specified in Section 4.2): + + PT_TR_REPLYCode = TRREPLYCODE-TLV-TYPE TLV-LENGTH 2*OCTET + + Figure 11: Traceroute Reply Code TLV + +6. Forwarder Operation + + When a forwarder receives a traceroute request, the HopLimit value is + checked and decremented, and the target name (i.e., the name of the + traceroute request without the last Nonce name segment as well as the + suffix "traceroute" and the ParametersSha256DigestComponent in the + case of a request with the NDN packet format) is extracted. + + If the HopLimit has not expired (i.e., is greater than 0), the + forwarder will forward the request upstream based on CS lookup, PIT + creation, Longest Name Prefix Match (LNPM) lookup, and (if present) + the path steering value. If no valid next hop is found, an + InterestReturn indicating "No Route" in the case of CCNx or a network + NACK in the case of NDN is sent downstream. + + If HopLimit equals 0, the forwarder generates a traceroute reply. + This reply includes the forwarder's administrative name and + signature, and a Path Label TLV. This TLV initially has a null + value, since the traceroute reply originator does not forward the + request and thus does not make a path choice. The reply will also + include the corresponding PT_TR_REPLY Code TLV. + + A traceroute reply will be the final reply of a traceroute session if + any of the following conditions are met: + + * If a forwarder has been given one or more administrative names, + the target name matches one of them. + + * The target name exactly matches the name of a Content Object + residing in the forwarder's CS (unless the traceroute client + application has chosen not to receive replies due to CS hits as + specified in Appendix A). + + * The target name matches (in an LNPM manner) a FIB entry with an + outgoing face referring to a local application. + + The PT_TR_REPLY Code TLV value of the reply is set to indicate the + specific condition that was met. If none of those conditions were + met, the PT_TR_REPLY Code is set to 4 to indicate that the HopLimit + reached 0. + + A received traceroute reply will be matched to an existing PIT entry + as usual. On the reverse path, the Path Steering TLV of a reply will + be updated by each forwarder to encode its choice of next hop(s). + When included in subsequent requests, this Path Steering TLV allows + the forwarders to steer the requests along the same path. + +7. Protocol Operation for Locally Scoped Namespaces + + In this section, we elaborate on two alternative design approaches in + cases where the traceroute target prefix corresponds to a locally + scoped namespace not directly routable from the client's local + network. + + The first approach leverages the NDN Link Object [SNAMP]. + Specifically, the traceroute client attaches to the expressed request + a Link Object that contains a number of routable name prefixes, based + on which the request can be forwarded across the Internet until it + reaches a network region where the request name itself is routable. + A Link Object is created and signed by a data producer allowed to + publish data under a locally scoped namespace. The way that a client + retrieves a Link Object depends on various network design factors and + is out of scope for this document. + + At the time of this writing, and based on the current deployment of + the Link Object by the NDN team [NDNLPv2], a forwarder at the border + of the region where an Interest name becomes routable has to remove + the Link Object from the incoming Interests. The Interest state + maintained along the entire forwarding path is based on the Interest + name regardless of whether it was forwarded based on this name or a + prefix in the Link Object. + + The second approach is based on prepending a routable prefix to the + locally scoped name. The resulting prefix will be the name of the + traceroute requests expressed by the client. In this way, a request + will be forwarded based on the routable part of its name. When it + reaches the network region where the original locally scoped name is + routable, the border forwarder rewrites the request name and deletes + its routable part. A forwarder will perform this rewriting operation + on a request if the following two conditions are met: + + 1) the routable part of the request name matches a routable name of + the network region adjacent to the forwarder (assuming that a + forwarder is aware of those names), and + + 2) the remaining part of the request name is routable across the + network region of this forwarder. + + The state along the path depends on whether the request is traversing + the portion of the network where the locally scoped name is routable. + In this case, the forwarding can be based entirely on the locally + scoped name. However, where a portion of the path lies outside the + region where the locally scoped name is routable, the border router + has to rewrite the name of a reply and prepend the routable prefix of + the corresponding request to ensure that the generated replies will + reach the client. + +8. Security Considerations + + A reflection attack could occur in the case of a traceroute reply + with the CCNx packet format if a compromised forwarder includes in + the reply the name of a victim forwarder. This could redirect the + future administrative traffic towards the victim. To foil such + reflection attacks, the forwarder that generates a traceroute reply + MUST sign the name included in the payload. In this way, the client + is able to verify that the included name is legitimate and refers to + the forwarder that generated the reply. Alternatively, the forwarder + could include in the reply payload their routable prefix(es) encoded + as a signed NDN Link Object [SNAMP]. + + This approach does not protect against on-path attacks where a + compromised forwarder that receives a traceroute reply replaces the + forwarder's name and the signature in the message with its own name + and signature to make the client believe that the reply was generated + by the compromised forwarder. To foil such attack scenarios, a + forwarder can sign the reply message itself. In such cases, the + forwarder does not have to sign its own name in the reply message, + since the message signature protects the message as a whole and will + be invalidated in the case of an on-path attack. Additionally, a + forwarder could swap out the name of a traceroute request with a name + of its choosing. In this case, however, the response with the + spoofed name will not be received by a client, since the change of + name would invalidate the state in the PIT on the path back to the + client. + + Signing each traceroute reply message can be expensive and can + potentially lead to computation attacks against forwarders. To + mitigate such attack scenarios, the processing of traceroute requests + and the generation of the replies SHOULD be handled by a separate + management application running locally on each forwarder. The + serving of traceroute replies is thereby separated from load on the + forwarder itself. The approaches used by ICN applications to manage + load may also apply to the forwarder's management application. + + Interest flooding attack amplification is possible in the case of the + second approach for dealing with locally scoped namespaces as + described in Section 7. A border forwarder will have to maintain + extra state to prepend the correct routable prefix to the name of an + outgoing reply, since the forwarder might be attached to multiple + network regions (reachable under different prefixes) or a network + region attached to this forwarder might be reachable under multiple + routable prefixes. + + We also note that traceroute requests have the same privacy + characteristics as regular Interests. + +9. IANA Considerations + + IANA has assigned 0x07 to "PT_TR_REQUEST" and 0x08 to "PT_TR_REPLY" + in the "CCNx Packet Types" registry established by [RFC8609]. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric + Networking (CCNx) Messages in TLV Format", RFC 8609, + DOI 10.17487/RFC8609, July 2019, + <https://www.rfc-editor.org/info/rfc8609>. + + [RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, + D., and C. Tschudin, "Information-Centric Networking + (ICN): Content-Centric Networking (CCNx) and Named Data + Networking (NDN) Terminology", RFC 8793, + DOI 10.17487/RFC8793, June 2020, + <https://www.rfc-editor.org/info/rfc8793>. + +10.2. Informative References + + [NDNLPv2] NDN team, "NDNLPv2: Named Data Networking Link Adaptation + Protocol v2", February 2023, <https://redmine.named- + data.net/projects/nfd/wiki/NDNLPv2>. + + [NDNTLV] NDN project team, "NDN Packet Format Specification", + February 2024, + <https://named-data.net/doc/NDN-packet-spec/current/>. + + [PATHSTEERING] + Moiseenko, I. and D. Oran, "Path switching in content + centric and named data networks", ICN '17: Proceedings of + the 4th ACM Conference on Information-Centric Networking, + pp. 66-76, DOI 10.1145/3125719.3125721, September 2017, + <https://dl.acm.org/doi/10.1145/3125719.3125721>. + + [REALTIME] Mastorakis, S., Gusev, P., Afanasyev, A., and L. Zhang, + "Real-Time Data Retrieval in Named Data Networking", 2018 + 1st IEEE International Conference on Hot Information- + Centric Networking (HotICN), Shenzhen, China, pp. 61-66, + DOI 10.1109/HOTICN.2018.8605992, August 2018, + <https://ieeexplore.ieee.org/document/8605992>. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + <https://www.rfc-editor.org/info/rfc4648>. + + [RFC9344] Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering + Content and Network Information in Content-Centric + Networks", RFC 9344, DOI 10.17487/RFC9344, February 2023, + <https://www.rfc-editor.org/info/rfc9344>. + + [RFC9508] Mastorakis, S., Oran, D., Gibson, J., Moiseenko, I., and + R. Droms, "Information-Centric Networking (ICN) Ping + Protocol Specification", RFC 9508, DOI 10.17487/RFC9508, + March 2024, <https://www.rfc-editor.org/info/rfc9508>. + + [RFC9531] Moiseenko, I. and D. Oran, "Path Steering in Content- + Centric Networking (CCNx) and Named Data Networking + (NDN)", RFC 9531, DOI 10.17487/RFC9531, March 2024, + <https://www.rfc-editor.org/info/rfc9531>. + + [SNAMP] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, + "SNAMP: Secure namespace mapping to scale NDN forwarding", + 2015 IEEE Conference on Computer Communications Workshops + (INFOCOM WKSHPS), Hong Kong, China, pp. 281-286, + DOI 10.1109/INFCOMW.2015.7179398, April 2015, + <https://ieeexplore.ieee.org/abstract/document/7179398>. + +Appendix A. Traceroute Client Application (Consumer) Operation + + This section is an informative appendix regarding the proposed + traceroute client operation. + + The client application is responsible for generating traceroute + requests for prefixes provided by users. + + The overall process can be iterative: the first traceroute request of + each session will have a HopLimit of 1 to reach the first hop + forwarder, the second request will have a HopLimit of 2 to reach the + second hop forwarder, and so on. + + When generating a series of requests for a specific name, the first + request will typically not include a Path Label TLV, since no TLV + value is known. After a traceroute reply containing a Path Label TLV + is received, each subsequent request might include the received path + steering value in the Path Label header TLV to drive the requests + towards a common path as part of checking network performance. To + discover more paths, a client can omit the Path Label TLV in future + requests. Moreover, for each new traceroute request, the client has + to generate a new nonce and record the time that the request was + expressed. The client also sets the lifetime of the traceroute + request, which carries the same semantics as the Interest Lifetime + [RFC8609] in an Interest. + + Moreover, the client application might not wish to receive replies + due to CS hits. In CCNx, a mechanism to achieve that would be to use + a Content Object Hash Restriction TLV with a value of 0 in the + payload of a traceroute request message. In NDN, the exclude filter + selector can be used. + + When it receives a traceroute reply, the client would typically match + the reply to a sent request and compute the round-trip time of the + request. It should parse the Path Label value and decode the reply's + payload to parse the sender's name and signature. The client should + verify that both the received message and the forwarder's name have + been signed by the key of the forwarder, whose name is included in + the payload of the reply (by fetching this forwarder's public key and + verifying the contained signature). In the case that the client + receives a PT_TR_REPLY Code TLV with a valid value, it can stop + sending requests with increasing HopLimit values and potentially + start a new traceroute session. + + In the case that a traceroute reply is not received for a request + within a certain time interval (lifetime of the request), the client + should time out and send a new request with a new nonce value up to a + maximum number of requests to be sent specified by the user. + +Authors' Addresses + + Spyridon Mastorakis + University of Notre Dame + South Bend, IN + United States of America + Email: smastor2@nd.edu + + + Dave Oran + Network Systems Research and Design + Cambridge, MA + United States of America + Email: daveoran@orandom.net + + + Ilya Moiseenko + Apple Inc. + Cupertino, CA + United States of America + Email: iliamo@mailbox.org + + + Jim Gibson + Unaffiliated + Belmont, MA + United States of America + Email: jcgibson61@gmail.com + + + Ralph Droms + Unaffiliated + Hopkinton, MA + United States of America + Email: rdroms.ietf@gmail.com |