RFC 9508

Information-Centric Networking (ICN) Ping Protocol Specification

📅 published March 2024, from ietf

RFC 9508: Information-Centric Networking (ICN) Ping Protocol Specification 🦋

Okay bestie, let's start with the ID card 🎀. This is RFC 9508, the Information-Centric Networking (ICN) Ping Protocol Specification, published in March 2024 by the Internet Research Task Force (IRTF) stream. It's marked Experimental and its ISSN is 2070-1721 ✨.

The authors are S. Mastorakis (University of Notre Dame), D. Oran (Network Systems Research and Design), J. Gibson (unaffiliated), I. Moiseenko (Apple Inc.), and R. Droms (unaffiliated) 💜. The header doesn't list anything it obsoletes or updates, so there's no older RFC being replaced or patched here 🙅‍♀️.

Abstract ✨

This document presents the design of an Information-Centric Networking (ICN) Ping protocol. It covers what both the client and the forwarder do 💅.

It's also a product of the Information-Centric Networking Research Group (ICNRG) of the IRTF 🌸.

Status of This Memo 📜

Lowkey important: this document is not an Internet Standards Track specification. It's being published so people can examine it, try it out experimentally, and evaluate it 🧪.

It defines an Experimental Protocol for the Internet community and comes from the IRTF, which shares research and development results that might not be ready for deployment 🔬. This RFC reflects the consensus of the ICNRG within the IRTF. Anything the IRSG approves for publication can't be a candidate for any level of Internet Standard, and you can read more about that in Section 2 of RFC 7841 💀.

For the latest status, errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9508 🔗.

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) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this document 📖.

Table of Contents 🗂️

1.  Introduction
  1.1.  Requirements Language
  1.2.  Terminology
2.  Background on IP-Based Ping Operation
3.  Ping Functionality Challenges and Opportunities in ICN
4.  ICN Ping Echo CCNx Packet Formats
  4.1.  ICN Ping Echo Request CCNx Packet Format
  4.2.  ICN Ping Echo Reply CCNx Packet Format
5.  ICN Ping Echo NDN Packet Formats
  5.1.  ICN Ping Echo Request NDN Packet Format
  5.2.  ICN Ping Echo Reply NDN Packet Format
6.  Forwarder Handling
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.  Ping Client Application (Consumer) Operation
Acknowledgements
Authors' Addresses

1. Introduction 🌷

Checking whether you can actually reach a destination, and getting rough Round-Trip Time (RTT) numbers, are the basics of network admin and troubleshooting 🔧. In IP, routing and forwarding run on IP addresses, so ICMP Echo Request and ICMP Echo Reply packets do the job, usually through the classic ping tool 🏓. In Information-Centric Networking (ICN), routing and forwarding run on name prefixes, so being able to check whether a name is reachable is required 🎯.

This document proposes protocol mechanisms for a ping equivalent in ICN networks, covering Content-Centric Networking (CCNx) [RFC8609] and Named Data Networking (NDN) [NDNTLV] 🦋. There's a non-normative section (Appendix A) that suggests handy properties for an ICN Ping client application, similar to IP ping, which sends Echo Requests and handles Echo Replies 💖.

To experiment with and deploy ICN protocols properly, the community needs new tools like ping and traceroute, the ones used for TCP/IP, to manage and debug ICN architectures and protocols 🛠️. This document describes a management and debugging protocol that works like the TCP/IP ping protocol, and it's meant to help with experimental deployments 🧚. Since experimentation with ICN is still ongoing, ICN Ping's design might change along the way ✨. ICN Ping is intended as a "first line of defense" for troubleshooting ICN architectures and protocols, which is why this document is classified as an Experimental RFC 🔥. Also, you'll need a measurement application to really use ICN Ping, because that's what computes stats like average, maximum, and minimum RTT, RTT variance, and loss rates 📊.

This RFC reflects 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 👑.

1.2. Terminology 📚

This specification uses the terminology defined in [RFC8793]. To make things easier, these extra terms are defined too 💅:

  • Producer's Name: The name prefix a request has to carry to reach a producer over an ICN network.
  • Named Data: A synonym for a Content Object.
  • Round-Trip Time (RTT): The time between sending a request for a specific piece of named data and getting back the matching piece of named data ⏱️.
  • Sender: An entity that sends a request for named data, or a piece of named data.
  • Name of a Sender: An alias of a producer's name.
  • Border Forwarder: The forwarder sitting at the border of a network region where a producer's name is directly routable, meaning the producer's name is in the FIB of forwarders inside that region 🚪.

2. Background on IP-Based Ping Operation 🌙

In IP-based ping, the user gives an IP address directly or gives a domain name that gets translated through DNS 🌐. The ping client application sends several ICMP Echo Request packets. Each one has the specified IP address as its IP destination address and an IP address from the client's host as its IP source address 💜.

Each ICMP Echo Request gets forwarded across the network based on its destination IP address 🚀. If it finally reaches the destination, the destination sends an ICMP Echo Reply packet back to the IP source address from the ICMP Echo Request 🦋.

If an ICMP Echo Request never arrives or the Echo Reply gets lost, the ping client times out ⌛. Any ICMP error messages created in response to the ICMP Echo Request, like "No route to destination", are sent back to the client and reported to you 🙈.

3. Ping Functionality Challenges and Opportunities in ICN ✨

okay so in ICN, the whole communication vibe is based exclusively on named objects 🎀. An Interest message gets forwarded across the network based on the name prefix it carries 🦋. Eventually, a Content Object gets retrieved from either a producer application or some forwarder's Content Store (CS) 💅.

IP-based ping was built as an add-on measurement and debugging tool on top of an already-existing network architecture 🧚. In ICN, we get the chance to bake diagnostic mechanisms right into the network-layer protocol and, hopefully, get way more powerful diagnostic capability than the layered ICMP Echo approach can give us 🔥.

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 of these interfaces. ICN identifies units of data in the network with a variable-length name consisting of a hierarchical list of name components. 🌸
  • 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 delivery 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 and in-network storage) holding a copy of the requested unit of data. This can lead to a significant variance in RTTs; such variance, while resulting in a more robust overall forwarding architecture, has implications for a network troubleshooting mechanism like ping. 🔥
  • 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 and only one of them forwarded onward. Depending on the lifetime of a PIT entry, the RTT of an Interest-Data exchange might vary significantly (e.g., it might be shorter than the full RTT to reach the original content producer). To this end, the RTT experienced by consumers might also vary. 🌈

These differences bring new challenges, new opportunities, and new requirements regarding the design of an ICN Ping protocol 🫶. Following this communication model, a ping client should be able to express Ping Echo Requests with some name prefix and receive responses.

Our goals are as follows: 👑

  • Test the reachability and the operational state of an ICN forwarder.
  • Test the reachability of a producer or a data repository (in the sense of whether Interests for a prefix that it serves can be forwarded to it), and discover the forwarder with local connectivity to (an instance of) this producer or repository.
  • Test whether a specific named object is cached in some on-path CS (e.g., a video segment with the name /video/_seq=1), and, if so, return the administrative name of the corresponding forwarder (e.g., a forwarder with the administrative name /ISP/forwarder1).
  • Perform some simple network performance measurements, such as RTT and loss rate.

To this end, a ping name can represent: 💜

  • An administrative name that has been assigned to a forwarder.
  • 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 Ping Echo Request enable the forwarders to distinguish a ping from a normal Interest, while diverging as little as possible from the forwarding behavior for an Interest packet. In the same way, the encoding of a Ping Echo Reply should minimize any processing differences from those employed for a data packet by the forwarders. 🎀

The ping protocol should also enable relatively robust RTT measurements. To this end, it is valuable to have a mechanism to steer consecutive Ping Echo Requests for the same name towards an individual path. Such a capability was initially published in [PATHSTEERING] and has been specified for CCNx and NDN in [RFC9531]. 🦋

In the case of Ping Echo Requests for the same name from different sources, it is also important to have a mechanism to avoid those requests being aggregated in the PIT. To this end, we need some encoding in the Ping Echo Requests to make each request for a common name unique, hence avoiding PIT aggregation and further enabling the exact match of a response with a particular ping packet. However, avoiding PIT aggregation could lead to PIT DoS attacks. 😭

4. ICN Ping Echo CCNx Packet Formats 🍓

In this section, we describe the Echo packet formats according to the CCNx packet format [RFC8569], where messages exist within outermost containments (packets). Specifically, we propose two types of ping packets: an Echo Request and an Echo Reply. 🧚

4.1. ICN Ping Echo Request CCNx Packet Format 💅

The format of the Ping Echo 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_ECHO_REQUEST|         PacketLength          |
    |               |               |                               |
    +---------------+---------------+---------------+---------------+
    |               |               |               |               |
    |    HopLimit   |    Reserved   |     Flags     |  HeaderLength |
    |               |               |               |               |
    +---------------+---------------+---------------+---------------+
    /                                                               /
    /                   Path Label TLV                              /
    /                                                               /
    +---------------+---------------+---------------+---------------+
    |                                                               |
    |                   Echo Request Message TLVs                   |
    |                                                               |
    +---------------+---------------+---------------+---------------+

Figure 1: Echo Request CCNx Packet Format

The existing packet header fields have the same definition as the header fields of a CCNx Interest packet. The value of the packet type field is _PT_ECHO_REQUEST_. See Section 9 for the value assignment. 🌸

Compared 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 Ping Echo Reply and included in the Ping Echo 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 format of an Echo 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: Echo Request Message Format

The Echo Request message is of type T_DISCOVERY. The Name TLV has the structure described in [RFC8609]. The name consists of the prefix that we would like to ping appended with a nonce typed name segment (T_NONCE) 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. See Section 9 for the value assigned to this name segment type. The value of this TLV is a 64-bit nonce. 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
    +---------------+---------------+---------------+---------------+
    |                               |                               |
    |        T_NONCE_Type           |       T_NONCE_Length = 8      |
    |                               |                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    |                                                               |
    |                                                               |
    |                         T_NONCE_Value                         |
    |                                                               |
    |                                                               |
    +---------------+---------------+---------------+---------------+

Figure 3: T_NONCE Name Segment TLV for Echo Request Messages 🌈

4.2. ICN Ping Echo Reply CCNx Packet Format ✨

okay so here's what an Echo Reply packet looks like 💅

     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_ECHO_REPLY |         PacketLength          |
    |               |               |                               |
    +---------------+---------------+---------------+---------------+
    |                               |               |               |
    |            Reserved           |     Flags     | HeaderLength  |
    |                               |               |               |
    +---------------+---------------+---------------+---------------+
    /                                                               /
    /                        Path Label TLV                         /
    /                                                               /
    +---------------+---------------+---------------+---------------+
    |                                                               |
    |                    Echo Reply Message TLVs                    |
    |                                                               |
    +---------------+---------------+---------------+---------------+

Figure 4: Echo Reply CCNx Packet Format

the header of an Echo Reply is made of the header fields of a CCNx Content Object, plus a hop-by-hop Path Label TLV 🎀 The packet type field is set to PT_ECHO_REPLY, and you can find its value assignment in Section 9. The Path Label header TLV (Section 3.1 of [RFC9531]) works exactly the same as it did for the Echo Request packet, so no new drama there 🙌

A Ping Echo Reply message is of type T_OBJECT and holds a Name TLV (the name of the corresponding Echo Request), a PayloadType TLV, and an ExpiryTime TLV set to 0. That 0 is the signal that Echo Replies must not be returned from network caches. Main character energy, no cache hits for the replies 🙈

     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: Echo Reply Message Format

The PayloadType TLV is next, and it's giving structure 🦋 It is of type T_PAYLOADTYPE_DATA, and its data schema holds three TLVs:

  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 a return code that tells you what led to the reply being generated (a local application, a CS hit, or a match with a forwarder's administrative name, as specified in Section 6).
     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                     /
    /                                                               /
    +---------------+---------------+---------------+---------------+
    /                                                               /
    /                     Echo Reply Code                           /
    /                                                               /
    +---------------+---------------+---------------+---------------+

Figure 6: Echo Reply PayloadType TLV Format

Why put the sender's name in the Echo Reply? So the user can reach that entity directly and ask for more management or admin info, using generic Interest-Data exchanges or a fancier management tool like CCNinfo [RFC9344]. But only after the sender's name has been successfully verified 🔥 Verify first, slay later.

The types of the Echo Reply Code field are:

  • T_ECHO_RETURN_FORWARDER: Indicates that the target name matched the administrative name of a forwarder.
  • T_ECHO_RETURN_APPLICATION: Indicates that the target name matched a prefix served by an application.
  • T_ECHO_RETURN_OBJECT: Indicates that the target name matched the name of an object in a forwarder's CS.

5. ICN Ping Echo NDN Packet Formats 🌈

In this section we show off the ICN Ping Echo Request and Reply packet formats, following the NDN packet format specification [NDNTLV]. Same vibes, new wardrobe 👑

5.1. ICN Ping Echo Request NDN Packet Format

An Echo Request gets encoded as an NDN Interest packet 🍓 It looks like this:

           EchoRequest = INTEREST-TYPE TLV-LENGTH
                 Name
                             MustBeFresh
                             Nonce
                             ApplicationParameters?

Figure 7: Echo Request NDN Packet Format

The name of an Echo Request is built from three pieces: the name prefix you want to ping, a nonce value (which can be the value of the Nonce field), and the suffix "ping" that says "hey, this Interest is a ping request" 💖 That suffix gets added as a KeywordNameComponent [NDNTLV]. When the "ApplicationParameters" element is present, a ParametersSha256DigestComponent (Section 6) gets tacked on as the last name segment. Layers of cute 🧚

An Echo Request MAY carry a Path Label TLV in the NDN Link Adaptation Protocol [NDNLPv2], as specified in [RFC9531].

The NDN packet format doesn't have a built-in way to stop the network from caching specific data packets. So for Echo Requests we use the MustBeFresh TLV, paired with a FreshnessPeriod TLV set to 1 for Echo Replies. The goal is to avoid fetching cached Echo Replies whose freshness period has already expired [REALTIME]. Lowkey genius 🧠

5.2. ICN Ping Echo Reply NDN Packet Format

An Echo Reply is encoded as an NDN Data packet ✨ The format is:

           EchoReply = DATA-TLV TLV-LENGTH
                           Name
                           MetaInfo
                           Content
                           Signature

Figure 8: Echo Reply NDN Packet Format

An Echo Reply MAY carry a Path Label TLV in the NDN Link Adaptation Protocol [NDNLPv2], as specified in [RFC9531]. Why? Because forwarders along the reverse path might modify it hop-by-hop 🦋

The name of an Echo Reply is the name of the corresponding Echo Request. The MetaInfo field looks like this:

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

Figure 9: MetaInfo TLV

The ContentType TLV is set to 0. The FreshnessPeriod TLV is set to 1, so the replies are treated as stale data (almost instantly) once a forwarder receives them 💀 Instant expiry, zero drama.

The content of an Echo Reply has two TLVs: the Sender's Name (with a structure similar to an NDN Name TLV) and the Echo Reply Code. There's no need for a separate sender's signature TLV in the content, because every NDN Data packet already carries the signature of the data producer 🫶 Efficiency is the whole brand.

The Echo Reply Code TLV format is below, with the values specified in Section 4.2:

           EchoReplyCode = ECHOREPLYCODE-TLV-TYPE TLV-LENGTH 2*OCTET

Figure 10: Echo Reply Code TLV

6. Forwarder Handling 💅

Here's the forwarder's workflow, shown in Figure 11 below 🌸 When a forwarder receives an Echo Request, it first extracts the message's base name. That means the request name with the Nonce name segment removed, along with the suffix "ping" and, for an Echo Request in the NDN packet format, the ParametersSha256DigestComponent.

Sometimes the forwarder originates an Echo Reply and sends it downstream through the face the Echo Request came in on. This reply includes the forwarder's own name and signature, plus the right Echo Reply Code for whatever triggered it. It also carries a Path Label TLV, initially holding a null value. Why null? The Echo Reply originator doesn't forward the request, so it never makes a path choice 🙈

The forwarder generates and returns an Echo Reply in these cases:

  • Assuming that a forwarder has been given one or more administrative names, the Echo Request base name exactly matches any of the forwarder's administrative names.
  • The Echo Request's base name exactly matches the name of a Content Object residing in the forwarder's CS (unless the ping client application has chosen not to receive replies due to CS hits, as specified in Appendix A).
  • The Echo Request base name matches (in a Longest Name Prefix Match (LNPM) manner) a FIB entry with an outgoing face referring to a local application.

If none of those conditions are met, the forwarder will try to forward the Echo Request upstream. It uses the Path Steering value (if present), the results of the FIB LNPM lookup, and PIT creation to decide. These lookups include the Nonce and the suffix "ping" as name segments of the Name, for an Echo Request in the NDN packet format. If no valid next hop is found, an InterestReturn is sent downstream indicating "No Route", just like a failed attempt to forward an ordinary Interest 😭

A received Echo Reply gets matched to an existing PIT entry as usual. On the reverse path, the Path Steering TLV of an Echo Reply is updated by each forwarder to encode its next-hop choice. When that Path Label TLV shows up in later Echo Requests, the forwarders can steer those requests along the same path. Path memory, but make it networking 🧚✨

------------------------------------------------------------------------
                              FORWARD PATH
------------------------------------------------------------------------

Request +------+  +-----+  +-----+(path label)  +--------+(match)Request
------> |Admin |->| CS  |->| PIT | ------------>| Label  |------------->
        | Name |  +-----+  +-----+              | Lookup |
        |Lookup|     |       | \ (no path label)+--------+
        +------+     |       |  \                |\(path label mismatch)
Reply       |        |       |   \               | \
  <---------+        |       v    \              |  \
  (base matches      |   aggregate \             |   \
   admin name)       |              \            |    \
                     | (base         \           |     +------+ Request
             Reply   |  matches       +----------|---->| FIB  | ------->
           <---------+  cached object)           |     +------+
                                                 |  (no   |  | (base
  InterestReturn (NACK)                          v  route)|  | matches
  <----------------------------------------------+<-------+  | local app
  <----------------------------------------------------------+ face)
  Reply

------------------------------------------------------------------------
                              REVERSE PATH
------------------------------------------------------------------------

InterestReturn (NACK) +-----+ (update path label) InterestReturn (NACK)
<---------------------|     |<-----------------------------------------
                      |     |
Reply  +------+       | PIT |  (update path label)                Reply
<------|  CS  |<------|     |<-----------------------------------------
       +------+       |     |
                      +-----+
                         |
                         | (no match)
                         v

                    Figure 11: Forwarder Operation

7. Protocol Operation for Locally Scoped Namespaces ✨

okay so this section is all about the tricky case 🧩 where the pinged prefix is a locally scoped namespace, meaning the client's own network can't just route to it directly. no cap, it's a whole vibe, and the spec gives us two alternative approaches to deal with it 💅

Approach number one leans on the NDN Link Object [SNAMP]. The ping client sticks a Link Object onto its request, and that Link Object holds a bunch of routable name prefixes. The request then hops along based on those prefixes until it finally lands in a network region where the request name itself is routable 🦋 A Link Object gets created and signed by a data producer that's allowed to publish under that locally scoped namespace. How a client actually goes about getting one depends on a bunch of network design stuff, and that's out of scope for this doc, so don't come for me about it 🙈

Now, at the time of writing, and based on how the NDN team uses the Link Object [NDNLPv2], a forwarder sitting on the border of the region where an Interest name becomes routable has to strip the Link Object off incoming Interests. The Interest state kept along the whole forwarding path is based on the Interest name, no matter whether the thing got forwarded by its name or by a routable prefix in the Link Object. Iconic consistency 👑

Approach number two is giving the locally scoped name a routable prefix glow-up 🌸 The prefix you stick on becomes the name of the Echo Requests the client sends, so the request gets forwarded based on that routable part. Once it reaches the region where the original locally scoped name is routable, the border forwarder rewrites the request name and deletes the routable part. For a forwarder to do that rewrite, two conditions have to be true:

  1. the routable part of the request name matches a routable name of the network region next door 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 moving through the part of the network where the locally scoped name is routable. In that zone, forwarding can be based entirely on the locally scoped name, easy peasy ✨ But if some of the path sits outside the region where that name is routable, the border router has to rewrite the name of a reply and prepend the routable prefix from the matching request. That's how the replies make it back to the client 🎀

8. Security Considerations 🔥

Okay, serious moment, bestie 🥺 A reflection attack could be pulled off by a compromised forwarder when an Echo Reply uses the CCNx packet format, if that forwarder puts the name of a victim forwarder into the reply. That could trick a client into sending future administrative traffic toward the victim. To shut down reflection attacks like this, the forwarder that generates a reply must sign the name it includes in the payload. That way the client can verify the included name is legit and actually refers to the forwarder that made the reply. Another option is for the forwarder to include its routable prefix(es) in the reply payload, encoded as a signed NDN Link Object [SNAMP].

Interest flooding attack amplification is possible with the second approach for locally scoped namespaces that we covered in Section 7. To get rid of that amplification, a border forwarder will have to keep extra state so it can prepend the correct routable prefix to the name of an outgoing reply. Why? Because the forwarder might be attached to multiple network regions (each reachable under different prefixes), or a network region attached to this forwarder might be reachable under multiple routable prefixes. Plot twist, it gets messy 😭

And one more attack to watch out for: the ICN version of port knocking, where an attacker pokes around trying to discover certain forwarder implementations so they can go after potential vulnerabilities 🙈 Stay alert, babes 💜

9. IANA Considerations 🌈

IANA has assigned 0x05 to "PT_ECHO_REQUEST" and 0x06 to "PT_ECHO_REPLY" in the "CCNx Packet Types" registry, which was set up by [RFC8609]. Two new types, slay 💅

IANA has assigned 0x0003 to "T_NONCE" in the "CCNx Name Segment Types" registry, also set up by [RFC8609] ✨

IANA has also created a brand new registry called "CCNx Echo Reply Codes" 🧁 The registration procedure for it is Specification Required [RFC8126]. Inside this registry, IANA has assigned 0x01 to "T_ECHO_RETURN_FORWARDER", 0x02 to "T_ECHO_RETURN_APPLICATION", and 0x03 to "T_ECHO_RETURN_OBJECT". Main character registry energy 👑

10. References 📚

10.1. Normative References

10.2. Informative References

Appendix A. Ping Client Application (Consumer) Operation ✨

okay bestie, this appendix is informative 🧚 so it's not normative, but it's the ping client's game plan. The ping client app is the one generating Echo Requests for prefixes that users hand it 💖

when you're sending a whole series of Echo Requests for one specific name, the first Echo Request usually doesn't have a Path Label TLV, because no TLV value is known yet 🙈 once an Echo Reply comes back with a Path Label TLV, every request after that can include the Path Steering value you got in the Path Label header TLV. This "drives" the requests toward a common path so you can check network performance on that one route 🛣️✨ want to discover more paths? Just leave the Path Steering TLV out of future requests 🦋

also, every new Ping Echo Request needs a brand new nonce 🔐 and the client has to record the time the request was expressed ⏰ it also sets the lifetime of the Echo Request, which works exactly like the lifetime of an Interest, no difference at all 💅

Now the client app might not want to get Echo Replies that come from CS hits 👀 in CCNx, the way to do that is a Content Object Hash Restriction TLV with a value of 0 in the payload of the Echo Request. In NDN, you use the exclude filter selector instead 🌸

when an Echo Reply shows up, the client usually matches it to the request it sent and computes the RTT of that request ⚡ 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. The forwarder's name is in the reply's payload, so you check it by fetching that forwarder's public key and verifying the signature in there 🔥 and the Echo Reply Code TLV can be decoded to find out what condition triggered the reply 💀 (that's the "why did this happen" clue, bestie 🕵️‍♀️)

and if an Echo Reply doesn't come back for a request within a certain time interval (the request's lifetime), the client should time out and send a new request with a new nonce value 🔁 It keeps doing that until it hits the maximum number of requests the user specified 🛑 ngl this is giving retry-with-a-purpose energy 👑

Acknowledgements

The authors would like to thank Mark Stapp for the fruitful discussion on the objectives of the ICN Ping protocol 💜🫶 he helped shape the whole vibe of this protocol, periodt ✨

Authors' Addresses

The authors' contact details are listed below, so you know exactly who to send your bug-hunting questions to 🎀

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
Jim Gibson
Unaffiliated
Belmont, MA
United States of America
Email: jcgibson61@gmail.com
Ilya Moiseenko
Apple Inc.
Cupertino, CA
United States of America
Email: iliamo@mailbox.org
Ralph Droms
Unaffiliated
Hopkinton, MA
United States of America
Email: rdroms.ietf@gmail.com
📦 where this page comes from