RFC 9531
Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN)
RFC 9531 🦋
Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN)
okay bestie, here's the paperwork glow-up 💅
- Stream: Internet Research Task Force (IRTF) 🌈
- Authors: I. Moiseenko (Apple, Inc.) and D. Oran (Network Systems Research and Design) 🎀
- Category: Experimental 🧪
- ISSN: 2070-1721
- Date: March 2024 🌸
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates ⭐
Abstract
okay so path steering is a way to find paths to the producers of ICN Content Objects and then steer later Interest messages down a path you already found 🛣️✨ it's giving multi-path congestion control, plus network measurement and management, all in one 💖 this spec comes straight from the design in "Path Switching in Content Centric and Named Data Networks" (4th ACM Conference on Information-Centric Networking), so it doesn't redo the motivations, implementation details, or evaluation 🙈 BUT some technical details are different, and wherever they differ, this document is the definitive one 👑
this doc is a product of the IRTF Information-Centric Networking Research Group (ICNRG). it is not an IETF product and it is not an Internet Standard 🫶
Status of This Memo
this one is not an Internet Standards Track spec. it's published so people can examine it, try it out as an experimental implementation, and evaluate it 🧪
it defines an Experimental Protocol for the Internet community 🌸 it's an IRTF product, and the IRTF shares results of Internet-related research and development 💜 those results might not be ready for deployment, so keep that in mind 🙈 this RFC reflects the consensus of the ICNRG. documents approved for publication by the IRSG aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 🫶
for the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9531 🔗
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) as in effect on the date of publication. please read those carefully, because they spell out your rights and restrictions for this document 📜
Table of Contents
1. Introduction
1.1. Path Steering as an Experimental Extension to ICN Protocol
Architectures
1.2. Requirements Language
1.3. Terminology
2. Essential Elements of ICN Path Discovery and Path Steering
2.1. Path Discovery
2.2. Path Steering
2.3. Handling Path Steering Errors
2.4. Interactions with Interest Aggregation
2.5. How to Represent the Path Label
3. Mapping to CCNx and NDN Packet Encodings
3.1. Path Label TLV
3.2. Path Label Encoding for CCNx
3.3. Path Label Encoding for NDN
4. IANA Considerations
5. Security Considerations
5.1. Cryptographic Protection of a Path Label
6. References
6.1. Normative References
6.2. Informative References
Authors' Addresses1. Introduction ✨
okay this section is the "why do we even care" part 💅 path steering is a mechanism for discovering paths to the producers of ICN Content Objects, and then steering later Interest messages along a path you already found 🛣️ it's useful for state-of-the-art multi-path congestion control and for network measurement and management 📊 this spec derives directly from the design in [Moiseenko2017], so it doesn't rehash the design motivations, implementation details, or evaluation. that publication should be considered a normative reference, because honestly nobody's going to understand this design without reading it first 📚 and again, where some technical details differ, this document is definitive 👑
path discovery and path steering in ICN networks work because forward and reverse paths are symmetric in the Content-Centric Networking (CCNx) and Named Data Networking (NDN) architectures 🦋 here's the lowkey genius bit: a consumer sends an ordinary Interest message and gets back a Content (Data) message that carries an end-to-end path label, which the forwarding plane built on the reverse path 💖 then, for path steering, the consumer puts a path label in the Interest message. that Interest gets forwarded to each nexthop through the matching egress interfaces, working together with Longest Name Prefix Match (LNPM) lookup in the Forwarding Information Base (FIB) 🌈
this document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). it was supported by ICNRG participants during development and through Research Group Last Call, and it got detailed review from experts in both the CCNx and NDN communities 🫶
1.1. Path Steering as an Experimental Extension to ICN Protocol Architectures
there are a bunch of important use cases that justify extending ICN architectures like CCNx [RFC8569] or NDN [NDN] with these capabilities 🎀 the big ones:
- support discovery, monitoring, and troubleshooting of multi-path network connectivity, based on names and name prefixes. this has been shown to be crucial for multicast and multi-path IP topologies too. the canonical tools are the well-known _traceroute_ and _ping_. for point-to-multipoint MPLS, the more recent MPLS traceroute [RFC8029] protocol is used. CCNx has equivalent diagnostics through the ICN Ping [RFC9508] and ICN Traceroute [RFC9507] specs, and both can exploit path steering when it's available 🔍
- perform accurate online measurement of network performance, which generally needs multiple consecutive packets to follow the same path under application control 📈
- improve the performance and flexibility of multi-path congestion control algorithms. schemes like [Mahdian2016] and [Song2018] depend on a consumer being able to explicitly steer packets onto individual paths in a multi-path and/or multi-destination topology 🚦
- let a consumer endpoint mitigate content poisoning attacks by directing its Interests onto network paths that bypass poisoned caches 🛡️
the path discovery machinery here may (and likely will) discover paths with varying properties 🌸 [RFC9217] covers a bunch of open questions in path-aware networking, including how to assess and exploit paths with different properties. experimenting with ICN path steering might help answer those questions and show which path properties matter most for the use cases above 🧪
one nuance compared to other path-aware networking approaches: ICN path steering piggybacks path discovery on the base ICN data exchange, instead of having a separate path advertisement or discovery mechanism 🎀 so when the recorded path comes back in an ICN Data message response, the consumer only knows the path's properties implicitly, not because they were explicitly labeled. that makes choosing a path a matter of observation or measurement, rather than advance selection based on an explicit, advertised property (e.g., SCION [SCION]) 👀
the utility and overall technical quality of this capability can be judged by how well it enables the use cases above, and what performance and robustness effects it has on the underlying ICN protocols and their use in various applications. a few open questions to tackle through experimentation with path steering include:
- how much more accurate and useful are measurements of RTT, packet loss, etc. through ping and traceroute when path steering is used? 🤔
- how much does explicit path steering enhance the performance and robustness of multi-path forwarding? 💅
1.2. 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. ⭐ so the caps are the rules, and lowercase is just regular words 🙈
1.3. Terminology
this doc uses the general ICN terms defined in [RFC8793] 📖 it also defines these path steering terms:
Path Discovery: the process of sending an Interest message requesting discovery of a path and, if successful, receiving a Data message containing a path label for the path the corresponding Interest traversed 🔎
Path Steering: the process of sending an Interest message containing the path label of a previously discovered path, so the forwarders use that path when forwarding that particular Interest message 🧭
Path Label: an optional field in the packet indicating a particular path from a consumer to either a producer or a forwarder cache that can respond with the requested item. in an Interest message, the path label gets built up hop by hop as the Interest traverses a path. in a Data message, the path label carries the full path information back to the consumer, for use in one or more subsequent Interest messages 🏷️
Nexthop Label: one entry in a path label representing the next hop for the corresponding forwarder to use when a path-steered Interest message arrives at that forwarder. a sequence of Nexthop Labels makes up a full path label 🪜
2. Essential Elements of ICN Path Discovery and Path Steering 💖
okay so this is where we get into the design 🧠 we explain it using CCNx semantics [RFC8569], and we extend its CCNx Message Formats [RFC8609] as defined in Section 3.2. the terminology is a little different in NDN, but this design can also be applied there by extending its bespoke packet encodings [NDNTLV] (see Section 3.3) 🌈
2.1. Path Discovery 🧚
okay so End-to-end Path Discovery for CCNx works by making a path label and tucking it in as a hop-by-hop TLV inside a CCNx Content (Data) message 💖. The label gets built one hop at a time as the message rides back along the reverse path of the transit CCNx forwarders (see the first example in Figure 1 🦋). Each forwarder adds the Nexthop Label of the interface where the Content (Data) message arrived to the path label that's already there. Once the message reaches the consumer, the path label spells out the complete route it took 👑. And here's the lowkey clever part (second example in Figure 1): when there's more than one path available, later Interests can find new paths by leaving out a path steering TLV, so they get a fresh path label on the returning Interest 🤭.
Discover and use first path:
Consumer Interest 1 ___ Interest 2
| | ^ |
| | | |
| | | |
Forwarder 1 v | V
| (nexthop 1) (nexthop 1) ^ (nexthop 1)
| | | |
| | | |
Forwarder 2 v | v
(nexthop 3) / \ (nexthop 2) (nexthop 2) ^ (nexthop 2)
/ \ | | |
/ \ | | |
/ \ | | |
/ \ | | |
/ \ | | |
Forwarder 4 Forwarder 3 v | v
(nexthop 5)\ / (nexthop 4) (nexthop 4) ^ (nexthop 4)
\ / | | |
\ / | | |
\ / | | |
\ / | | |
\ / | | |
\ / v | v
Producer ___ Data 1 ___
or
Content Store
Discover and use second path:
Consumer Interest 3 ___ Interest 4
| | ^ |
| | | |
| | | |
Forwarder 1 v | V
| (nexthop 1) (nexthop 1) ^ (nexthop 1)
| | | |
| | | |
Forwarder 2 v | v
(nexthop 3) / \ (nexthop 2) (nexthop 3) ^ (nexthop 3)
/ \ | | |
/ \ | | |
/ \ | | |
/ \ | | |
/ \ | | |
Forwarder 4 Forwarder 3 v | v
(nexthop 5)\ / (nexthop 4) (nexthop 5) ^ (nexthop 5)
\ / | | |
\ / | | |
\ / | | |
\ / | | |
\ / | | |
\ / v | v
Producer ___ Data 2 ___
or
Content StoreFigure 1: Basic Example of Path Discovery and Steering 🌸
2.2. Path Steering 🦋
bestie, this is the good part 😭. Because forward and reverse paths are symmetric in CCNx, a consumer app can reuse a discovered path label to fetch the same Content (Data) message, or a similar one like the next chunk, the next Application Data Unit, or the next pointer in a Manifest [FLIC], over that same network path ✨. This is called path steering. It works because every transit ICN forwarder reads the Interest's path label and forwards the Interest out the specified nexthop, as long as that nexthop is one of the ones LNPM FIB lookup says are feasible (Figure 2 💅).
----------------------------------------------------------------------
FORWARD PATH
----------------------------------------------------------------------
Interest +---------+ +-----+ (path label) +--------+ (match) Interest
-------->| Content |->| PIT | ------------>| Label |---------------->
| Store | +-----+ | Lookup |
+---------+ | \ (no path label) +--------+
| | \ |\(path label mismatch)
Data | | \ | \
<---------+ v \ | \
aggregate \ | \
\ | \
\ | +-----+ Interest
+--------------|---->| FIB | -------->
| +-----+
InterestReturn (NACK) v | (no route)
<----------------------------------------------+<-------+
----------------------------------------------------------------------
REVERSE PATH
----------------------------------------------------------------------
InterestReturn(NACK) +-----+(update path label) InterestReturn(NACK)
<---------------------| |<----------------------------------------
| |
Data +---------+ | PIT | (update path label) Data
<------| Content |<---| |<----------------------------------------
| Store | | |
+---------+ +-----+
|
| (no match)
vFigure 2: Path Steering CCNx/NDN Data Plane 🧚
2.3. Handling Path Steering Errors 💅
real talk, the network changes over time 😩. The state of interfaces and the FIB on forwarders can shift, so at some forwarder a given nexthop might stop being valid for a given prefix. When that happens, the path label is pointing at a now-invalid nexthop 🙈. A forwarder catches this when it can't find a match between the decoded nexthop ID and the nexthops of the FIB entry after LNPM FIB lookup.
On detecting an invalid path label, the forwarder SHOULD respond to the Interest with an InterestReturn. So we define a brand new invalid path label response code for the InterestReturn message and include the current path label as a hop-by-hop header 🎀. Every transit forwarder that processes the InterestReturn updates the path label the same way it does for Content (Data) messages, so the consumer who gets the InterestReturn (NACK) can easily tell which path label is no longer valid 👑.
A consumer can also ask a forwarder that spots the inconsistency to forward the Interest through normal LNPM FIB lookup instead of sending back an error 🦋. If the consumer cares, it can keep enough info about its outstanding Interests to figure out whether the path label it sent fails to match the path label in the returned Content (Data), and use that to replace stale path labels 🫶. To ask for this, it sets the FALLBACK_MODE flag of the path label TLV in its Interest message.
2.4. Interactions with Interest Aggregation 🌈
so if two or more Interests matching the same Pending Interest Table (PIT) entry hit a forwarder, under current behavior they get aggregated whether or not they carry identical path label TLVs 😵💫. That might or might not be what you want! For example, Interests with different modes (like one with DISCOVERY_MODE and one without) get aggregated anyway, which means the forwarder's behavior can depend on which Interest showed up first 💀. In particular:
- If the DISCOVERY_MODE Interest arrives first, it gets forwarded and can potentially discover a new path, while the other Interest gets aggregated. If that other Interest carried no path label, its behavior is essentially unchanged. But if it carried a path label without specifying DISCOVERY_MODE, the consumer's intent for the Interest to traverse the specified path gets ignored, and it's indeterminate whether the chosen path will actually be used 🥺.
- If the two Interests arrive in the reverse order, the DISCOVERY MODE Interest gets aggregated, and the consumer issuing it won't achieve its goal of discovering a new path 😭.
Multiple Interests intended to discover paths (i.e., by carrying the DISCOVERY_MODE flag defined in Section 3.1) might also get aggregated by a forwarder 🙃. That limits the ability to discover multiple paths in parallel, so they have to be discovered incrementally across later exchanges. In other words, aggregated Interests will all discover only one single path, carried by one single Data packet. This matters for management apps like traceroute [RFC9507], which would likely perform way better if they discovered paths in parallel 🧚. So when employing path steering, it is RECOMMENDED that such applications craft their Interests with unique name suffixes so they don't get aggregated 💜.
While path steering still operates correctly if DISCOVERY MODE Interests are aggregated, after further experimentation, it may be appropriate to advise that a forwarder: - SHOULD NOT aggregate Interests carrying different path labels and - SHOULD apply a rate limit to DISCOVERY_MODE Interests in order to limit redundant traffic.
2.5. How to Represent the Path Label 🎀
Okay so [Moiseenko2017] lays out a bunch of ways to represent a path label, and each one trades off flexibility, performance, and space efficiency differently. For this spec we pick the _polynomial encoding_ 💅. It's super space efficient, but it comes with a hard limit on how long a path can be, so bestie, keep that in mind 🙈.
The polynomial encoding runs on a fixed-size bit array. Every transit ICN forwarder gets its own fixed-size slice of that array. This design gives each intermediate ICN forwarder 12 bits (so 4095 as a _generator polynomial_) 🧚. That's honestly giving real router energy: today's commercial routers can handle up to 4096 physical and logical interfaces, and they usually don't have more than a few hundred active ones 💖.
+------------------------------------------------------------------+
| path label bitmap |
+----------+-----------------+-----------------+-------------------+
| index | Nexthop Label | Nexthop Label | |
+----------+-----------------+-----------------+-------------------+
|<- 8bit ->|<---- 12bit ---->|<---- 12bit ---->|<----------------->|
Figure 3: Fixed-Size Path LabelSo here's how it flows: a forwarder that gets a Content (Data) message encodes its Nexthop Label in the next available slot and bumps the label index up by one. An Interest message does the opposite. The forwarder reads the current Nexthop Label and decrements the label index ✨. Either way, the extra work per hop is super minimal, a pretty trivial add-on next to FIB lookup and all the other stuff you already have to do 🦋.
Each path label TLV instance ends up being a fixed, pre-computed size. Yes, that puts a hard ceiling on how many hops can be represented 😭, but in NDN and CCNx it's not really a big deal. The size can be preset during Content (Data) message encoding, based on the exact number of network hops the Interest message traveled. Even a 24-hop path fits in a 36-byte path label bitmap when the Nexthop Label is encoded in 12 bits 👑.
3. Mapping to CCNx and NDN Packet Encodings 🧚
3.1. Path Label TLV
A path label TLV is basically a tuple: {[Flags], [Path Label Hop Count], [Nexthop Label], [path label bitmap]} 🎀
+================+=============+
| Flag | Value (hex) |
+================+=============+
| DISCOVERY_MODE | 0x00 |
+----------------+-------------+
| FALLBACK_MODE | 0x01 |
+----------------+-------------+
| STRICT_MODE | 0x02 |
+----------------+-------------+
| Unassigned | 0x03-0xFF |
+----------------+-------------+
Table 1: Path Label FlagsOkay, this part is important, so listen up 👀. The Path Label Hop Count (PLHC) MUST be incremented by NDN and CCNx forwarders if the Interest packet carries a path label and the DISCOVERY_MODE flag is set. A producer node, or a forwarder with a cached Data packet, MUST use the PLHC when it calculates a path label bitmap size that can encode the entire path to the consumer. The PLHC MUST be set to zero in newly created Data or InterestReturn (NACK) packets. And a consumer node MUST reuse the PLHC together with the path label bitmap (PLB) so the Interest(s) get forwarded along the correct network path 🫶.
If an NDN or CCNx forwarder supports path labeling, the Nexthop Label MUST be used to determine the correct egress interface for an Interest packet carrying either the FALLBACK_MODE or the STRICT_MODE flag. If a particular NDN or CCNx forwarder is configured to decrypt path labels of Interest packets (see Security Considerations), then the forwarder MUST:
- decrypt the path label with its own symmetric key,
- update the Nexthop Label with the outermost label in the path label,
- decrement the PLHC, and
- remove the outermost label from the path label.
If a particular NDN or CCNx forwarder is NOT configured to decrypt path labels of Interest packets, then path label decryption SHOULD NOT be performed 🙅♀️.
The Nexthop Label MUST be ignored by NDN and CCNx forwarders if it shows up in Data or InterestReturn (NACK) packets. If a particular NDN or CCNx forwarder is configured to encrypt path labels of Data and InterestReturn (NACK) packets (see Security Considerations), then the forwarder MUST encrypt the existing path label with its own symmetric key, append the Nexthop Label of the ingress interface to the path label, and increment the PLHC. If a particular NDN or CCNx forwarder is NOT configured to encrypt path labels of Interest packets, then path label encryption SHOULD NOT be performed 💀.
NDN and CCNx forwarders MUST fall back to Longest Name Prefix Match (LNPM) FIB lookup if an Interest packet carries an invalid Nexthop Label and the FALLBACK_MODE flag is set 🌈.
CCNx forwarders MUST respond with an InterestReturn packet specifying a T_RETURN_INVALID_PATH_LABEL code if the Interest packet carries an invalid path label and the STRICT_MODE flag is set. This is a brand-new InterestReturn code defined right here (see Section 4 for the value allocation) ⭐.
CCNx forwarders MUST respond with an InterestReturn packet specifying the existing T_RETURN_MALFORMED_INTEREST code if the Interest packet carries a path label TLV with both the FALLBACK_MODE and STRICT_MODE flags set 🚫.
3.2. Path Label Encoding for CCNx
Path label is an optional hop-by-hop header TLV that can show up in CCNx Interest, InterestReturn, and Content Object packets 🦋.
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_PATH_LABEL | Length + 4 |
+---------------+---------------+---------------+---------------+
| Flags | Path Label | Nexthop Label |
| | Hop Count | |
+---------------+---------------+---------------+---------------+
/ /
/ Path label bitmap (Length octets) /
/ /
+---------------+---------------+---------------+---------------+
Figure 4: Path Label Hop-by-Hop Header TLV for CCNx3.3. Path Label Encoding for NDN
Path label is an optional TLV for NDN Interest and Data packets 🌸. It rides inside the NDN Link Adaptation Protocol [NDNLPv2], the wrapper that lets NDN packets travel over all sorts of link layer protocols. NDNLPv2 got picked over the NDN packet itself because it can carry hop-by-hop info that might change at every hop, which means that info can't be part of the secured hash or the signature of an NDN packet 🔐. It can also take over for the existing NextHopFaceId TLV. That's because it doesn't just name the one outgoing face for a consumer, it manages the selection and forwarding across the entire path 👑. The path label TLV in NDNLPv2 looks like this:
PathLabel = PATH-LABEL-TYPE TLV-LENGTH
PathLabelFlags
PathLabelBitmap
PathLabelFlags = PATH-LABEL-FLAGS-TYPE
TLV-LENGTH ; == 1
OCTET
NexthopLabel = PATH-LABEL-NEXTHOP-LABEL-TYPE
TLV-LENGTH ; == 2
2 OCTET
PathLabelHopCount = PATH-LABEL-HOP-COUNT-TYPE
TLV-LENGTH ; == 1
OCTET
PathLabelBitmap = PATH-LABEL-BITMAP-TYPE
TLV-LENGTH ; == 64
64 OCTET
Figure 5: Path Label TLV for NDN +============================+=========================+
| Flag | (Suggested) Value (hex) |
+============================+=========================+
| T_PATH_LABEL | 0x0A |
+----------------------------+-------------------------+
| T_PATH_LABEL_FLAGS | 0x0B |
+----------------------------+-------------------------+
| T_PATH_LABEL_BITMAP | 0x0D |
+----------------------------+-------------------------+
| T_PATH_LABEL_NEXTHOP_LABEL | 0x0E |
+----------------------------+-------------------------+
| T_PATH_LABEL_HOP_COUNT | 0x0F |
+----------------------------+-------------------------+
Table 2: TLV-TYPE Number Assignments for NDN4. IANA Considerations 📋
IANA has made the following assignments 🎉:
- The value 0x000A has been assigned to T_PATH_LABEL in the "CCNx Hop-by-Hop Types" registry, established by [RFC8609].
- The value 0x0A has been assigned to T_RETURN_INVALID_PATH_LABEL in the "CCNx Interest Return Code Types" registry, established by [RFC8609].
5. Security Considerations 🔐💀
okay so a path gets invalidated whenever one or more Nexthop Labels get renumbered 😭. A sneaky consumer could send Interests whose path labels differ only in one now-invalid Nexthop Label, basically trying to brute-force a valid one 🕵️♀️. If that works, the attacker could steer Interests over a network path that doesn't match the paths the routing algorithm computed or the forwarders learned adaptively. absolutely not 🙅♀️
When a label lookup fails, by default, an invalid path label InterestReturn (NACK) message gets sent back to the consumer. It carries a path label identical to the one in the Interest 📨. So a malicious consumer can check the Hop Count field to work out which Nexthop Label failed, and then aim the attack at that hop. yikes 😬 But there are some countermeasures you can use:
- Bigger Nexthop Labels are harder to crack 💪. If routers don't allocate them in a predictable way, brute-forcing a 32-bit Nexthop Label takes on average O(2^31) Interests. BUT this spec uses Nexthop Labels with way less entropy (12 bits), so relying on computational hardness is not workable 🙃
- An ICN forwarder can keep updating Nexthop Labels to limit the maximum lifetime of paths ⏰. It is RECOMMENDED that forwarders update path labels at least every few minutes 🔄
- A void Hop Count field in an invalid path label InterestReturn (NACK) message won't give away which Nexthop Label failed 🙈. The attacker might need to brute-force all Nexthop Labels in all combinations 🧩. The tradeoff is that some useful diagnostic capability is lost, since the locus of routing churn is harder to pin down through path-steered pings or traceroutes 🍓. A forwarder MAY choose to void the hop count in addition to changing Nexthop Labels periodically as described above 🎀
ICN forwarders keep per-face state and forwarding state for Interest messages, so state inflation attacks are a general concern 😰. The addition of path steering capabilities in Interest and Data messages doesn't meaningfully increase susceptibility to them, though, and here's why:
- The labels that identify each forwarding face are state O(number of faces), which is a small increase on top of the state already needed to represent a face 📈
- Interest message data goes into the PIT. The path steering header does inflate the size of the Interest message and therefore the PIT state, but not by an amount that's a concern 🙆♀️ The forwarder still needs to protect against state inflation attacks on the PIT in general, and an attacker can mount one just as easily, or even more easily, by issuing Interests with long names and/or by including Interest payload data 🫠
ICN protocols can be susceptible to a variety of cache poisoning attacks 🧪, where a colluding consumer and producer arrange for bogus content (with either invalid or inappropriate signatures) to populate forwarder caches. These are generally confined to on-path attacks. It's also theoretically possible to launch a similar attack without a cooperating producer, so the caches of on-path routers become poisoned with content from off-path routers (i.e., physical connectivity but no route in a FIB for a given prefix) 👀. We estimate that, without any prior knowledge of the network topology, the complexity of this type of attack is in the ballpark of Breadth-First-Search and Depth-First-Search algorithms, with the additional burden of transmitting 2^31 Interests in order to crack a Nexthop Label on each hop 🥵. A relatively short periodic update of Nexthop Labels, together with heuristics implemented in the ICN forwarder to foil label scans, may successfully mitigate this type of attack 🛡️✨
5.1. Cryptographic Protection of a Path Label 🔒
If the countermeasures listed above don't provide sufficient protection against malicious mis-steering of Interests, the path label can be made opaque to the consumer endpoint via hop-by-hop symmetric cryptography applied to the path labels (Figure 6) 🫶. This works because of the symmetry of forward and reverse paths in CCNx and NDN architectures, combined with ICN path steering only requiring reads and writes of the topmost Nexthop Label (i.e., the active Nexthop Label) in the path label 💜. Here's the flow: a path-steering-capable ICN forwarder receiving a Content (Data) message encrypts the current path label with its own non-shared symmetric key before adding a new Nexthop Label to the path label. The Content (Data) message is forwarded downstream with an unencrypted topmost (i.e., active) Nexthop Label and the remaining encrypted content of the path label. So a consumer endpoint receives a Content (Data) message with a unique path label that exposes only the topmost Nexthop Label as cleartext 👑. A path steering forwarder receiving an Interest message performs a label lookup using the topmost Nexthop Label, decrypts the path label with its own non-shared symmetric key, and forwards the message upstream 🔁
Cryptographic protection of a path label does not require any key negotiation among ICN forwarders, and it's no more expensive than Media Access Control Security (MACsec) or IPsec 💅. It's also quite possible that strict hop-by-hop path label encryption isn't necessary, and that path label encryption only on the border routers of the trusted administrative or routing domains may suffice 🌸
Producer
| ^
| |
Path Label TLV | | Path Label TLV
+-----------------------+ | | +-----------------------+
|nexthop label=456 | v | |nexthop label=456 |
|encrypted path label={}| Forwarder 3 |encrypted path label={}|
+-----------------------+ | ^ +-----------------------+
| |
path label is encrypted | | path label is decrypted
with Forwarder 3 | | with Forwarder 3
symmetric key | | symmetric key
| |
| |
| |
| |
| |
Path Label TLV | | Path Label TLV
+-----------------------+ | | +-----------------------+
|nexthop label=634 | v | |nexthop label=634 |
|encrypted path label= | Forwarder 2 |encrypted path label= |
| {456} | | ^ | {456} |
+-----------------------+ | | +-----------------------+
| |
path label is encrypted | | path label is decrypted
with Forwarder 2 | | with Forwarder 2
symmetric key | | symmetric key
| |
| |
| |
| |
| |
Path Label TLV | | Path Label TLV
+-----------------------+ | | +-----------------------+
|nexthop label=912 | v | |nexthop label=912 |
|encrypted path label= | Forwarder 1 |encrypted path label= |
| {634, encrypted path | | ^ | {634, encrypted path |
| label {456}} | | | | label {456}} |
+-----------------------+ | | +-----------------------+
| |
path label is encrypted | | path label is decrypted
with Forwarder 1 | | with Forwarder 1
symmetric key | | symmetric key
| |
| |
| |
| |
v |
Consumer Figure 6: Path Label Protection with Hop-by-Hop Symmetric
Cryptography6. References 📚
6.1. Normative References
[Moiseenko2017] Moiseenko, I. and D. Oran, "Path Switching in Content Centric and Named Data Networks", Proceedings of the 4th ACM Conference on Information-Centric Networking, Pages 66-76, DOI 10.1145/3125719.3125721, DOI 10.1145/3125719.3125721, September 2017, <https://conferences.sigcomm.org/acm-icn/2017/proceedings/icn17-2.pdf>.
[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>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[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>.
6.2. Informative References 📚✨
okay bestie, these are the extra reads 🤓💖 nothing here is required to implement the spec, but they're the receipts for where the ideas came from. the list is in alphabetical order by tag, and the URLs are copied exactly, line breaks and all 🔗
[FLIC] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, Ed.,
"File-Like ICN Collections (FLIC)", Work in Progress,
Internet-Draft, draft-irtf-icnrg-flic-05, 22 October 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
flic-05>.
[Mahdian2016]
Mahdian, M., Arianfar, S., Gibson, J., and D. Oran,
"MIRCC: Multipath-aware ICN Rate-based Congestion
Control", Proceedings of the 3rd ACM Conference on
Information-Centric Networking, Pages 1-10,
DOI 10.1145/2984356.2984365, September 2016,
<http://conferences2.sigcomm.org/acm-icn/2016/proceedings/
p1-mahdian.pdf>.
[NDN] NDN, "Named Data Networking: Executive Summary",
<https://named-data.net/project/execsummary/>.
[NDNLPv2] NFD, "NDNLPv2", <https://redmine.named-
data.net/projects/nfd/wiki/NDNLPv2>.
[NDNTLV] NDN, "NDN Packet Format Specification v0.3",
<https://named-data.net/doc/NDN-packet-spec/current/>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[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>.
[RFC9217] Trammell, B., "Current Open Questions in Path-Aware
Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022,
<https://www.rfc-editor.org/info/rfc9217>.
[RFC9507] Mastorakis, S., Oran, D., Moiseenko, I., Gibson, J., and
R. Droms, "Information-Centric Networking (ICN) Traceroute
Protocol Specification", RFC 9507, DOI 10.17487/RFC9507,
March 2024, <https://www.rfc-editor.org/info/rfc9507>.
[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>.
[SCION] de Kater, C., Rustignoli, N., and A. Perrig, "SCION
Overview", Work in Progress, Internet-Draft, draft-
dekater-panrg-scion-overview-05, 5 November 2023,
<https://datatracker.ietf.org/doc/html/draft-dekater-
panrg-scion-overview-05>.
[Song2018] Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level
Multi-path Interest Control for Information Centric
Networking", Proceedings of the 5th ACM Conference on
Information-Centric Networking, Pages 77-87,
DOI 10.1145/3267955.3267971, September 2018,
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/
icn18-final62.pdf>.these are the ones that go deep on multipath, traceroute, and ping 🦋 if you want the big picture of path-aware networking, [RFC9217] is the one to read first 💅
Authors' Addresses 🎀
these are the two people who wrote the whole thing, so if you have questions, these are the girlies to ask 🫶
Ilya Moiseenko
Apple, Inc.
Cupertino, CA
United States of America
Email: iliamo@mailbox.org
Dave Oran
Network Systems Research and Design
4 Shady Hill Square
Cambridge, MA 02138
United States of America
Email: daveoran@orandom.netand that's a wrap on RFC 9531 🌈✨👑 💜
📦 where this page comes from
- ietf: rfc9531 2024-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms