RFC 9507

Information-Centric Networking (ICN) Traceroute Protocol Specification

📅 published March 2024, from ietf

Information-Centric Networking (ICN) Traceroute Protocol Specification 🦋

  • Series: Internet Research Task Force (IRTF) 🌈
  • RFC number: 9507 ✨
  • Category: Experimental 🧪
  • ISSN: 2070-1721
  • Date: March 2024 📅
  • Obsoletes / Updates: none listed in this title block 🙅‍♀️
  • Authors: S. Mastorakis (University of Notre Dame), D. Oran (Network Systems Research and Design), I. Moiseenko (Apple Inc.), J. Gibson (Unaffiliated), and R. Droms (Unaffiliated) 💜

Abstract 🌸

okay so this doc lays out the design of an Information-Centric Networking (ICN) Traceroute protocol 💖 and it covers how both the client and the forwarder operate. it's giving full blueprint energy 🫶

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 (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. 👀 read the fine print, bestie 🙈

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 ✨

okay so in TCP/IP, routing and forwarding are based on IP addresses. 🌐 to figure out the route to an IP address and measure the transit delays, people usually reach for the traceroute utility 🗺️

In Information-Centric Networking (ICN), routing and forwarding are based on name prefixes. 🏷️ so the ability to find out the characteristics of at least one of the available routes to a name prefix is a fundamental requirement for instrumentation and network management. 🔥 those characteristics include, among other things, route properties like which forwarders were transited and the delay incurred through forwarding. ⏱️

To carry out meaningful experimentation and deployment of ICN protocols, we need new tools analogous to ping and traceroute (the ones used for TCP/IP) to manage and debug how ICN architectures and protocols operate. 🛠️ this document describes the design of a management and debugging protocol analogous to the traceroute protocol of TCP/IP. this new protocol will help the experimental deployment of ICN protocols. 🦋 as the community keeps experimenting 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, so 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. 🎀 these only count as the official keywords when they're in ALL CAPS, so lowercase versions are just regular words, iykyk 🙈

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 with the TTL value increased by 1, which is basically an expanding ring search 💫 the packets can be UDP datagrams, ICMP Echo Request packets, or TCP SYN packets, depending on the implementation and the user-specified behavior. 🍓 so the first IP packet sent expires at the first router along the path, the second IP packet expires at the second router along the path, and so on, 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 it's explicitly prevented from doing so by a security policy. 🔒

The IP-based traceroute utility operates on IP addresses. it especially depends on IP packets having source IP addresses, because those get used as the destination address for replies. 📬 but ICN forwards based on names rather than destination IP addresses, the names don't refer to unique endpoints (they're multi-destination), and the packets don't contain source addresses. 🙅‍♀️ so a substantially different approach is needed. 💀✨

3. Traceroute Functionality Challenges and Opportunities in ICN ✨

okay so, in Named Data Networking (NDN) and Content-Centric Networking (CCNx) protocols, everything runs on named objects 🧚. An Interest message gets forwarded across the network based on its name, and eventually it snags a Content Object from either a producer application or some forwarder's Content Store (CS) 💅.

ICN is lowkey a whole different vibe from IP, and there are at least four big differences (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 made of a hierarchical list of segments 🌸.
  • An IP-based network depends on IP packets having source IP addresses that get used as the destination address for replies. ICN Interests? No source addresses! They get forwarded based on names, and names don't point to one unique endpoint 😭. Data packets follow the reverse path of the Interests, using hop-by-hop state that got created during Interest forwarding 🔥.
  • An IP network does multi-path, single-destination, stateless packet forwarding and delivery via unicast 💜. It also does a limited form of multi-destination selected delivery with anycast, plus group-based multi-destination delivery via multicast 🌈. ICN, meanwhile, does multi-path and multi-destination stateful Interest forwarding, and multi-destination data delivery to units of named data ✨. This single forwarding semantic subsumes unicast, anycast, and multicast, all in one go 👑. So consecutive (or retransmitted) ICN Interest messages might take different paths through the network and might go to different data sources (like end-node applications or in-network storage) holding a copy of the requested unit of data 🙈. Being able to discover multiple available (or potentially all) paths towards a name prefix is a seriously desirable capability for an ICN Traceroute protocol, because it can help with congestion control 💖. Knowing how many paths exist for a name is also handy when Interest forwarding based on application semantics or preferences is wanted 🎀.
  • When multiple Interests with the same name hit a forwarder, a bunch of them may get aggregated into one common Pending Interest Table (PIT) entry 🍓. Depending on how long that PIT entry lives, the round-trip time of an Interest-Data exchange can vary a lot (it might be shorter than the full round-trip time to reach the original content producer) 💀. So the round-trip time consumers experience can also vary, even when the network load stays constant 🫶.

These differences bring new challenges, new opportunities, and new requirements for designing ICN Traceroute 🔥. Following this communication model, a traceroute client should be able to express traceroute requests directed at 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 lets forwarders tell this request apart 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 minimise any processing differences from those used 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's desirable that ICN Traceroute be able to discover a number of paths towards the expressed prefix within the same session or in subsequent sessions 👑. To discover all the hops in a path, we need a mechanism (Interest Steering) to steer requests along different paths 🌸. That capability was first published in [PATHSTEERING] and has been specified for CCNx and NDN in [RFC9531] 💖.

For traceroute requests for the same prefix coming from different sources, it's also important to have a mechanism that stops those requests from being aggregated in the PIT 🙈. So we need some encoding in the traceroute requests that makes each request for a common prefix unique, which avoids PIT aggregation and also enables 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 work similarly to 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, with a nonce typed name as its last segment 🎀. The nonce can be encoded as a base64-encoded string using 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 to let the client match 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 🎀

okay so the reply packet is where the magic happens 🦋 here's how it's laid out:

     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 is made of the header fields of a CCNx Content Object plus a hop-by-hop Path Steering TLV 💅 The packet type field is PT_TR_REPLY, and you can find its value in Section 9.

A traceroute reply message is of type T_OBJECT and has a Name TLV (the name of the traceroute request it's answering), a PayloadType TLV, and an ExpiryTime TLV set to 0, which signals 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 up next ✨ It is of type T_PAYLOADTYPE_DATA, and its data schema has three TLVs inside:

  1. the name of the sender of this reply (same structure as a CCNx Name TLV),
  2. the sender's signature of their own name (same structure as a CCNx ValidationPayload TLV), and
  3. a TLV with return codes that says whether the request was satisfied because of a local application, a CS hit, a match with a forwarder's name, or the HopLimit value of the corresponding request hitting 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

Why put the sender's name in the reply? Because it lets the user reach that entity directly and ask for more management or admin info using generic Interest-Data exchanges, or with a fancier management tool like CCNinfo [RFC9344], once the sender's name has been successfully verified 🧚

The PT_TR_REPLY Code TLV is next, and it's a 16-bit value. Here are the four assigned values:

  1. 1: the target name matched the administrative name of a forwarder (as served by its internal management application).
  2. 2: the target name matched a prefix served by an application (other than the internal management application of a forwarder).
  3. 3: the target name matched the name of an object in a forwarder's CS.
  4. 4: 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 get the ICN Traceroute Request and Reply packet formats for NDN, following the NDN packet format specification [NDNTLV] 🌸

5.1. ICN Traceroute Request NDN Packet Format 💖

a traceroute request is encoded as an NDN Interest packet. Here's the format:

        TracerouteRequest = INTEREST-TYPE TLV-LENGTH
              Name
              MustBeFresh
              Nonce
              HopLimit
              ApplicationParameters?

Figure 8: Traceroute Request NDN Packet Format

The name of a request is made of the target name, a nonce value (which can be the value of the Nonce field), and the suffix "traceroute" to show that this Interest is a traceroute request (added as a KeywordNameComponent [NDNTLV]). When the "ApplicationParameters" element is present, a ParametersSha256DigestComponent (Section 6) gets 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].

Okay, this part is kinda clever 🧠 The NDN packet format doesn't give us a way to stop the network from caching specific data packets. So instead, we use the MustBeFresh TLV on requests (together with a FreshnessPeriod TLV set to 1 on replies) to avoid fetching cached traceroute replies whose freshness period has already expired [REALTIME] ⭐

5.2. ICN Traceroute Reply NDN Packet Format 🦋

a traceroute reply is encoded as an NDN Data packet. Its format is:

        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 forwarders along the reverse path might modify it hop by hop 🔄

The name of a traceroute reply is the name of the corresponding traceroute request. The MetaInfo field is formatted like this:

      MetaInfo = META-INFO-TYPE TLV-LENGTH
               ContentType
               FreshnessPeriod

Figure 10: MetaInfo TLV

The ContentType TLV is set to 0. The FreshnessPeriod TLV is set to 1, so the replies get treated as stale data (almost instantly) as soon as a forwarder receives them 💀

The content of a traceroute reply has two TLVs: Sender's Name (an NDN Name TLV) and Traceroute Reply Code. There's no need for a separate TLV for the sender's signature in the content, because every NDN Data packet already carries the signature of the data producer 🫶

The Traceroute Reply Code TLV looks like this (with the values from Section 4.2):

        PT_TR_REPLYCode = TRREPLYCODE-TLV-TYPE TLV-LENGTH 2*OCTET

Figure 11: Traceroute Reply Code TLV

6. Forwarder Operation ✨

okay so when a forwarder gets a traceroute request, it checks the HopLimit value and decrements it 💅. Then it pulls out the target name. That's the request name minus the last Nonce name segment, minus the traceroute suffix, and (for requests in the NDN packet format) minus the ParametersSha256DigestComponent too 🧚.

If the HopLimit hasn't expired (so it's greater than 0), the forwarder sends the request upstream using a CS lookup, PIT creation, a Longest Name Prefix Match (LNPM) lookup, and the path steering value if there is one 🦋. If there's no valid next hop, it sends an InterestReturn downstream saying No Route (CCNx) or a network NACK (NDN) 😭.

If HopLimit equals 0, the forwarder makes a traceroute reply 🎀. The reply has the forwarder's administrative name and signature, plus a Path Label TLV. That TLV starts out with a null value, because the reply originator never forwards the request, so it never makes a path choice 🙈. The reply also carries the matching PT_TR_REPLY Code TLV.

A traceroute reply is the final reply of a session if any of these are true:

  • 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 sitting in the forwarder's CS. (Unless the traceroute client app has chosen not to receive replies from CS hits, as specified in Appendix A 🙅‍♀️.)
  • The target name matches (in an LNPM way) a FIB entry whose outgoing face points to a local application.

The PT_TR_REPLY Code TLV value gets set to show exactly which condition was met 👑. If none of those conditions applied, the PT_TR_REPLY Code is set to 4, which means the HopLimit hit 0 💜.

A received traceroute reply gets matched to an existing PIT entry, just like normal 🌸. On the way back, every forwarder updates the Path Steering TLV in the reply to record its choice of next hop(s) ✨. Later requests can include that Path Steering TLV, so the forwarders keep the requests on the same path. Main character energy 👑🔥.

7. Protocol Operation for Locally Scoped Namespaces

so this section is about two different ways to handle things when the traceroute target prefix lives in a locally scoped namespace that the client's local network can't route to directly 🌈.

The first approach uses the NDN Link Object [SNAMP] 🦋. The traceroute client attaches a Link Object to the request it sends. That Link Object has a bunch of routable name prefixes, so the request can get forwarded across the Internet until it reaches a region where the request name itself is routable 🧚. A data producer that's allowed to publish under the locally scoped namespace creates and signs the Link Object 🔐. How a client actually gets a Link Object depends on a bunch of network design factors, and that's out of scope for this document 🙃.

At the time of writing, and based on how the NDN team currently deploys the Link Object [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 kept along the whole forwarding path is based on the Interest name, no matter whether it got forwarded using that name or using a prefix from the Link Object 🫶.

The second approach is to prepend a routable prefix onto the locally scoped name 🎀. That new prefix becomes the name of the traceroute requests the client sends. This way, a request gets forwarded based on its routable part 🌸. When it reaches the network region where the original locally scoped name is routable, the border forwarder rewrites the request name and deletes the routable part ✂️. A forwarder does this rewrite on a request only if both of these are true:

  1. the routable part of the request name matches a routable name of the network region next to the forwarder (assuming the forwarder knows about those names), and
  2. the remaining part of the request name is routable across that forwarder's network region.

The state along the path depends on whether the request is crossing the part of the network where the locally scoped name is routable 🧚‍♀️. In that case, forwarding can be based entirely on the locally scoped name. But if some of the path sits 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 from the matching request, so the replies can still get back to the client 💌.

8. Security Considerations

okay this section is the serious one, so buckle up 😭🔐.

A reflection attack could happen with a traceroute reply in the CCNx packet format if a compromised forwarder puts the name of a victim forwarder into the reply 💀. That could redirect future administrative traffic toward the victim. To stop these reflection attacks, the forwarder that generates a traceroute reply MUST sign the name included in the payload 🛡️. That way the client can check that the included name is legit and really refers to the forwarder that made the reply ✅. The other option is for the forwarder to put its routable prefix(es) in the reply payload, encoded as a signed NDN Link Object [SNAMP] 🦋.

This approach does not protect against on-path attacks, where a compromised forwarder that handles a traceroute reply swaps out the forwarder's name and signature for its own, so the client thinks the compromised forwarder made the reply 😱. To stop that kind of attack, a forwarder can sign the reply message itself 🔏. In that case the forwarder doesn't have to sign its own name in the reply, because the message signature protects the whole message, and it becomes invalid if someone tampers with it during an on-path attack 🙅‍♀️. A forwarder could also swap out the name of a traceroute request for a name of its choosing 🫠. But then the spoofed response never reaches the client, since changing the name would break the PIT state on the path back to the client 🚫.

Signing every traceroute reply can get expensive, and it can open the door to computation attacks against forwarders 🥵. To help with that, handling the traceroute requests and generating the replies SHOULD be done by a separate management application that runs locally on each forwarder 🧁. That keeps serving traceroute replies separate from the load on the forwarder itself. The approaches ICN apps use to manage load may also work for the forwarder's management application 💜.

Interest flooding amplification is possible with the second approach for locally scoped namespaces (the one described in Section 7) 📢. A border forwarder has to keep extra state so it knows which routable prefix to prepend to an outgoing reply name. That's because the forwarder might be attached to several network regions (reachable under different prefixes), or a network region attached to the forwarder might be reachable under several routable prefixes 🌀.

Also, traceroute requests have the same privacy characteristics as regular Interests 🕵️‍♀️.

9. IANA Considerations

okay the IANA part is short and sweet 🍓. IANA has assigned 0x07 to PT_TR_REQUEST and 0x08 to PT_TR_REPLY in the "CCNx Packet Types" registry, which was set up by [RFC8609] 🎉✨.

10. References

10.1. Normative References

10.2. Informative References

Appendix A. Traceroute Client Application (Consumer) Operation ✨

okay so this appendix is informative 🦋 It's all about how the traceroute client app should behave, the bestie who actually sends the requests and reads the replies.

The client app makes traceroute requests for prefixes that users give it 💅

The whole thing runs iteratively, kinda like a slow glow-up 🌸 The first request of each session has a HopLimit of 1 so it reaches the first hop forwarder. The second has a HopLimit of 2 so it reaches the second hop, and so on, one hop at a time 🧚

When you send a bunch of requests for one specific name, the first one usually won't have a Path Label TLV, because nobody knows the value yet 🙈 Once a traceroute reply with a Path Label TLV comes back, the later requests can put that received path steering value in the Path Label header TLV. This steers them down a common path, which is perfect for checking network performance 💖 If you want to find more paths, just leave the Path Label TLV out of future requests. Also, every new traceroute request needs a brand new nonce, and the client has to record the time the request was expressed ⏰ The client also sets the request's lifetime. That lifetime works exactly like the Interest Lifetime [RFC8609] in an Interest, so no surprises there 🎀

Sometimes the client doesn't want replies that come from CS hits, and honestly, same 😭 In CCNx, you can do that by putting a Content Object Hash Restriction TLV with a value of 0 in the payload of a traceroute request. In NDN, you use the exclude filter selector instead 🍓

When a traceroute reply shows up, the client usually matches it to the request it sent and works out the round-trip time 🔥 It should parse the Path Label value and decode the reply's payload to pull out the sender's name and signature 👑 The client should also verify that both the received message and the forwarder's name were signed by the forwarder's key. That forwarder's name is in the reply's payload, so the client fetches the forwarder's public key and checks the signature against it 🔐 If the client gets a PT_TR_REPLY Code TLV with a valid value, it can stop sending requests with increasing HopLimit values, and it can even start a fresh traceroute session if it wants ✨

And if a reply doesn't come back for a request within the request's lifetime, the client should time out and send a new request with a new nonce value. It keeps doing this until it hits the maximum number of requests the user specified 💜

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

📦 where this page comes from