rfc9531.original   rfc9531.txt 
ICNRG I. Moiseenko Internet Research Task Force (IRTF) I. Moiseenko
Internet-Draft Apple, Inc. Request for Comments: 9531 Apple, Inc.
Intended status: Experimental D. Oran Category: Experimental D. Oran
Expires: 1 April 2024 Network Systems Research and Design ISSN: 2070-1721 Network Systems Research and Design
29 September 2023 February 2024
Path Steering in CCNx and NDN Path Steering in Content-Centric Networking (CCNx) and Named Data
draft-irtf-icnrg-pathsteering-07 Networking (NDN)
Abstract Abstract
Path Steering is a mechanism to discover paths to the producers of Path steering is a mechanism to discover paths to the producers of
ICN content objects and steer subsequent Interest messages along a Information-Centric Networking (ICN) Content Objects and steer
previously discovered path. It has various uses, including the subsequent Interest messages along a previously discovered path. It
operation of state-of-the-art multipath congestion control algorithms has various uses, including the operation of state-of-the-art multi-
and for network measurement and management. This specification path congestion control algorithms and for network measurement and
derives directly from the design published in _Path Switching in management. This specification derives directly from the design
Content Centric and Named Data Networks_ (4th ACM Conference on published in "Path Switching in Content Centric and Named Data
Information-Centric Networking - ICN'17) and therefore does not Networks" (4th ACM Conference on Information-Centric Networking) and,
recapitulate the design motivations, implementation details, or therefore, does not recapitulate the design motivations,
evaluation of the scheme. Some technical details are different implementation details, or evaluation of the scheme. However, some
however, and where there are differences, the design documented here technical details are different, and where there are differences, the
is to be considered definitive. design documented here is to be considered definitive.
This document is a product of the IRTF Information-Centric Networking This document is a product of the IRTF Information-Centric Networking
Research Group (ICNRG). It is not an IETF product and is not an Research Group (ICNRG). It is not an IETF product and is not an
Internet Standard. Internet Standard.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Research Task
time. It is inappropriate to use Internet-Drafts as reference Force (IRTF). The IRTF publishes the results of Internet-related
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 1 April 2024. 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/rfc9531.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Path Steering as an experimental extension to ICN protocol 1.1. Path Steering as an Experimental Extension to ICN Protocol
architectures . . . . . . . . . . . . . . . . . . . . . . 3 Architectures
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology
2. Essential elements of ICN path discovery and path steering . 5 2. Essential Elements of ICN Path Discovery and Path Steering
2.1. Path Discovery . . . . . . . . . . . . . . . . . . . . . 5 2.1. Path Discovery
2.2. Path Steering . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Path Steering
2.3. Handling Path Steering errors . . . . . . . . . . . . . . 8 2.3. Handling Path Steering Errors
2.4. Interactions with Interest Aggregation . . . . . . . . . 9 2.4. Interactions with Interest Aggregation
2.5. How to represent the Path Label . . . . . . . . . . . . . 10 2.5. How to Represent the Path Label
3. Mapping to CCNx and NDN packet encodings . . . . . . . . . . 11 3. Mapping to CCNx and NDN Packet Encodings
3.1. Path label TLV . . . . . . . . . . . . . . . . . . . . . 11 3.1. Path Label TLV
3.2. Path label encoding for CCNx . . . . . . . . . . . . . . 12 3.2. Path Label Encoding for CCNx
3.3. Path label encoding for NDN . . . . . . . . . . . . . . . 13 3.3. Path Label Encoding for NDN
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations
5.1. Cryptographic protection of a path label . . . . . . . . 16 5.1. Cryptographic Protection of a Path Label
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.1. Normative References
6.2. Informative References . . . . . . . . . . . . . . . . . 18 6.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses
1. Introduction 1. Introduction
Path Steering is a mechanism to discover paths to the producers of Path steering is a mechanism to discover paths to the producers of
ICN content objects and steer subsequent Interest messages along a ICN Content Objects and steer subsequent Interest messages along a
previously discovered path. It has various uses, including the previously discovered path. It has various uses, including the
operation of state-of-the-art multipath congestion control algorithms operation of state-of-the-art multi-path congestion control
and for network measurement and management. This specification algorithms and for network measurement and management. This
derives directly from the design published in [Moiseenko2017] and specification derives directly from the design published in
therefore does not recapitulate the design motivations, [Moiseenko2017] and, therefore, does not recapitulate the design
implementation details, or evaluation of the scheme. That motivations, implementation details, or evaluation of the scheme.
publication should be considered a normative reference as it is not That publication should be considered a normative reference as it is
likely a reader will be able to understand all elements of this not likely a reader will be able to understand all elements of this
design without first having read the reference. Some technical design without first having read the reference. However, some
details are different however, and where there are differences, the technical details are different, and where there are differences, the
design documented here is to be considered definitive. design documented here is to be considered definitive.
Path discovery and subsequent path steering in ICN networks is Path discovery and subsequent path steering in ICN networks is
facilitated by the symmetry of forward and reverse paths in the CCNx facilitated by the symmetry of forward and reverse paths in the
and NDN architectures. Path discovery is achieved by a consumer Content-Centric Networking (CCNx) and Named Data Networking (NDN)
endpoint transmitting an ordinary Interest message and receiving a architectures. Path discovery is achieved by a consumer endpoint
Content (Data) message containing an end-to-end path label transmitting an ordinary Interest message and receiving a Content
constructed on the reverse path by the forwarding plane. Path (Data) message containing an end-to-end path label constructed on the
steering is achieved by a consumer endpoint including a path label in reverse path by the forwarding plane. Path steering is achieved by a
the Interest message, which is forwarded to each nexthop through the consumer endpoint including a path label in the Interest message,
corresponding egress interfaces in conjunction with longest name which is forwarded to each nexthop through the corresponding egress
prefix match (LNPM) lookup in the Forwarding Information Base (FIB). interfaces in conjunction with Longest Name Prefix Match (LNPM)
lookup in the Forwarding Information Base (FIB).
This document is a product of the IRTF Information-Centric Networking This document is a product of the IRTF Information-Centric Networking
Research Group (ICNRG). It was supported by the ICNRG participants Research Group (ICNRG). It was supported by the ICNRG participants
during its development and through Research Group last call. It has during its development and through Research Group Last Call. It has
received detailed review by experts in both the CCNx and NDN received detailed review by experts in both the CCNx and NDN
communities. communities.
1.1. Path Steering as an experimental extension to ICN protocol 1.1. Path Steering as an Experimental Extension to ICN Protocol
architectures Architectures
There are a number of important use cases to justify extending ICN There are a number of important use cases to justify extending ICN
architectures such as CCNx [RFC8569] or NDN [NDN] to provide these architectures such as CCNx [RFC8569] or NDN [NDN] to provide these
capabilities. These are summarized as follows: capabilities. These are summarized as follows:
* Support the discovery, monitoring and troubleshooting of multi- * Support the discovery, monitoring, and troubleshooting of multi-
path network connectivity based on names and name prefixes. path network connectivity, based on names and name prefixes.
Analogous functions have been shown to be a crucial operational Analogous functions have been shown to be a crucial operational
capability in multicast and multi-path topologies for IP. The capability in multicast and multi-path topologies for IP. The
canonical tools are the well-known _traceroute_ and _ping_. For canonical tools are the well-known _traceroute_ and _ping_. For
point-to-multipoint MPLS the more recent tree trace [RFC8029] point-to-multipoint MPLS, the more recent MPLS traceroute
protocol is used. Equivalent diagnostic functions have been [RFC8029] protocol is used. Equivalent diagnostic functions have
defined for CCNx through the ICN Ping [I-D.irtf-icnrg-icnping] and been defined for CCNx through the ICN Ping [RFC9508] and ICN
ICN Traceroute [I-D.irtf-icnrg-icntraceroute] specifications, both Traceroute [RFC9507] specifications; both of which are capable of
of which are capable of exploiting path steering if available. exploiting path steering, if available.
* Perform accurate online measurement of network performance, which * Perform accurate online measurement of network performance, which
generally requires multiple consecutive packets follow the same generally requires multiple consecutive packets to follow the same
path under control of an application. path under control of an application.
* Improve the performance and flexibility of multi-path congestion * Improve the performance and flexibility of multi-path congestion
control algorithms. Congestion control schemes such as control algorithms. Congestion control schemes, such as
[Mahdian2016] and [Song2018] depend on the ability of a consumer [Mahdian2016] and [Song2018], depend on the ability of a consumer
to explicitly steer packets onto individual paths in a multi-path to explicitly steer packets onto individual paths in a multi-path
and/or multi-destination topology. and/or multi-destination topology.
* A consumer endpoint can mitigate content poisoning attacks by * Allow a consumer endpoint to mitigate content poisoning attacks by
directing its Interests onto the network paths that bypass directing its Interests onto the network paths that bypass
poisoned caches. poisoned caches.
The path discovery machinery described here may (and likely will) The path discovery machinery described here may (and likely will)
discover paths with varying properties. [RFC9217] discusses a number discover paths with varying properties. [RFC9217] discusses a number
of open questions in path aware networking, among which is how to of open questions in path-aware networking, among which is how to
assess and exploit paths having different properties. Experimenting assess and exploit paths having different properties. Experimenting
with ICN path steering may be helpful in further elucidating these with ICN path steering may be helpful in further elucidating these
questions and perhaps shedding light on which path properties are questions and perhaps shedding light on which path properties are
most useful for the use cases cited above. most useful for the use cases cited above.
One nuance compared to other path aware networking approaches is that One nuance compared to other path-aware networking approaches is that
ICN path steering piggybacks path discovery on the base ICN data ICN path steering piggybacks path discovery on the base ICN data
exchange, rather than having a separate path advertisement or exchange rather than having a separate path advertisement or
discovery mechanism. That means when the recorded path comes back in discovery mechanism. That means when the recorded path comes back in
an ICN Data message response, the properties of the path are known an ICN Data message response, the properties of the path are known
only implicitly to the consumer as opposed to being explicitly only implicitly to the consumer as opposed to being explicitly
labeled. That makes the question of what properties a consumer uses labeled. That makes the question of what properties a consumer uses
to choose a path one of observation or measurement rather than to choose a path one of observation or measurement rather than
advance selection based on an explicit advertised property (e.g SCION advance selection based on an explicit, advertised property (e.g.,
[I-D.dekater-panrg-scion-overview]). SCION [SCION]).
The utility and overall technical quality of this path steering The utility and overall technical quality of this path steering
capability can be assessed by how well it enables the above use cases capability can be assessed by how well it enables the above use cases
and what performance and robustness effects it has on the underlying and what performance and robustness effects it has on the underlying
ICN protocols and their use in various applications. A few of the ICN protocols and their use in various applications. A few of the
open questions that should be addressed through experimentation with open questions that should be addressed through experimentation with
path steering include: path steering include:
* how much more accurate and useful are measurements of RTT, packet * How much more accurate and useful are measurements of RTT, packet
loss, etc. through ping and traceroute when utilizing path loss, etc. through ping and traceroute when utilizing path
steering? steering?
* how much is the performance and robustness of multi-path * How much is the performance and robustness of multi-path
forwarding enhanced by the use of this explicit path steering forwarding enhanced by the use of this explicit path steering
capability? capability?
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14 [RFC2119] "OPTIONAL" in this document are to be interpreted as described in
[RFC8174] when, and only when, they appear in all capitals, as shown BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
here. capitals, as shown here.
1.3. Terminology 1.3. Terminology
This document uses the general ICN terms that are defined in This document uses the general ICN terms that are defined in
[RFC8793]. In addition we define the following terms specific to [RFC8793]. In addition, we define the following terms specific to
path steering: path steering:
Path Discovery: The process of sending an Interest requesting Path Discovery: The process of sending an Interest message
discovery of a path and if successful, receiving a Data containing requesting discovery of a path and, if successful, receiving a
a Path Label for the path the corresponding Interest traversed Data message containing a path label for the path the
corresponding Interest traversed.
Path Steering: The process of sending an Interest message containing Path Steering: The process of sending an Interest message containing
the Path Label of a previously discovered path in order that the the path label of a previously discovered path so that the
forwarders use that path when forwarding that particular Interest forwarders use that path when forwarding that particular Interest
message. message.
Path Label: An optional field in the packet indicating a particular Path Label: An optional field in the packet indicating a particular
path from a consumer to either a producer, or a forwarder cache path from a consumer to either a producer or a forwarder cache
that can respond with the requested item. In an Interest message, that can respond with the requested item. In an Interest message,
the Path Label gets built up hop by hop as the interest traverses 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 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 information back to the consumer for use in one or more subsequent
Interest messages. Interest messages.
Nexthop Label: One entry in a Path Label representing the next hop Nexthop Label: One entry in a path label representing the next hop
for the corresponding forwarder to use when a path-steered for the corresponding forwarder to use when a path-steered
Interest message arrives at that forwarder. A sequence of Nexthop Interest message arrives at that forwarder. A sequence of Nexthop
Labels constitutes a full Path Label. Labels constitutes a full path label.
2. Essential elements of ICN path discovery and path steering 2. Essential Elements of ICN Path Discovery and Path Steering
We elucidate the design using CCNx semantics [RFC8569] and extend its We elucidate the design using CCNx semantics [RFC8569] and extend its
Packet Encoding [RFC8609] as defined in Section 3.2. While the CCNx Message Formats [RFC8609] defined in Section 3.2. While the
terminology is slightly different, this design can be applied also to terminology is slightly different, this design can also be applied to
NDN, by extending its bespoke packet encodings [NDNTLV] (See NDN by extending its bespoke packet encodings [NDNTLV] (see
Section 3.3). Section 3.3).
2.1. Path Discovery 2.1. Path Discovery
_End-to-end Path Discovery_ for CCNx is achieved by creating a _path _End-to-end Path Discovery_ for CCNx is achieved by creating a _path
label_ and placing it as a hop-by-hop TLV in a CCNx Content (Data) label_ and placing it as a hop-by-hop TLV in a CCNx Content (Data)
message. The path label is constructed hop-by-hop as the message message. The path label is constructed hop by hop as the message
traverses the reverse path of transit CCNx forwarders as shown in the traverses the reverse path of transit CCNx forwarders, as shown in
first example in Figure 1. The path label is updated by adding to the first example in Figure 1. The path label is updated by adding
the existing path label the nexthop label of the interface at which the Nexthop Label of the interface at which the Content (Data)
the Content (Data) message has arrived. Eventually, when the message has arrived to the existing path label. Eventually, when the
Content(Data) message arrives at the consumer, the path label Content (Data) message arrives at the consumer, the path label
identifies the complete path the Content (Data) message took to reach identifies the complete path the Content (Data) message took to reach
the consumer. As shown in the second example in the figure, when the consumer. As shown in the second example in Figure 1, when
multiple paths are available, subsequent Interests may be able to multiple paths are available, subsequent Interests may be able to
discover additional paths by omitting a path steering TLV and discover additional paths by omitting a path steering TLV and
obtaining a new path label on the returning interest. obtaining a new path label on the returning Interest.
Discover and use first path: Discover and use first path:
Consumer Interest 1 ___ Interest 2 Consumer Interest 1 ___ Interest 2
| | ^ | | | ^ |
| | | | | | | |
| | | | | | | |
Forwarder 1 v | V Forwarder 1 v | V
| (nexthop 1) (nexthop 1) ^ (nexthop 1) | (nexthop 1) (nexthop 1) ^ (nexthop 1)
| | | | | | | |
skipping to change at page 7, line 34 skipping to change at line 306
\ / | | | \ / | | |
\ / | | | \ / | | |
\ / | | | \ / | | |
\ / | | | \ / | | |
\ / | | | \ / | | |
\ / v | v \ / v | v
Producer ___ Data 2 ___ Producer ___ Data 2 ___
or or
Content Store Content Store
Figure 1: Basic example of path discovery and steering Figure 1: Basic Example of Path Discovery and Steering
2.2. Path Steering 2.2. Path Steering
Due to the symmetry of forward and reverse paths in CCNx, a consumer Due to the symmetry of forward and reverse paths in CCNx, a consumer
application can reuse a discovered path label to fetch the same or application can reuse a discovered path label to fetch the same or a
similar (e.g. next chunk, or next Application Data Unit, or next similar (e.g., next chunk, next Application Data Unit, or next
pointer in a Manifest [I-D.irtf-icnrg-flic]) Content (Data) message pointer in a Manifest [FLIC]) Content (Data) message over the
over the discovered network path. This _Path Steering_ is achieved discovered network path. This _path steering_ is achieved by
by processing the Interest message's path label at each transit ICN processing the Interest message's path label at each transit ICN
forwarder and forwarding the Interest through the specified nexthop forwarder and forwarding the Interest through the specified nexthop
among those identified as feasible by LNPM FIB lookup (Figure 2). among those identified as feasible by LNPM FIB lookup (Figure 2).
---------------------------------------------------------------------- ----------------------------------------------------------------------
FORWARD PATH FORWARD PATH
---------------------------------------------------------------------- ----------------------------------------------------------------------
Interest +---------+ +-----+ (path label) +--------+ (match) Interest Interest +---------+ +-----+ (path label) +--------+ (match) Interest
-------->| Content |->| PIT | ------------>| Label |----------------> -------->| Content |->| PIT | ------------>| Label |---------------->
| Store | +-----+ | Lookup | | Store | +-----+ | Lookup |
+---------+ | \ (no path label) +--------+ +---------+ | \ (no path label) +--------+
| | \ |\(path label mismatch) | | \ |\(path label mismatch)
Data | | \ | \ Data | | \ | \
<---------+ v \ | \ <---------+ v \ | \
aggregate \ | \ aggregate \ | \
\ | \ \ | \
\ | +-----+ Interest \ | +-----+ Interest
+--------------|---->| FIB | --------> +--------------|---->| FIB | -------->
| +-----+ | +-----+
Interest-Return (NACK) v | (no route) InterestReturn (NACK) v | (no route)
<----------------------------------------------+<-------+ <----------------------------------------------+<-------+
---------------------------------------------------------------------- ----------------------------------------------------------------------
REVERSE PATH REVERSE PATH
---------------------------------------------------------------------- ----------------------------------------------------------------------
Interest-return(NACK) +-----+(update path label) Interest-Return(NACK) InterestReturn(NACK) +-----+(update path label) InterestReturn(NACK)
<---------------------| |<---------------------------------------- <---------------------| |<----------------------------------------
| | | |
Data +---------+ | PIT | (update path label) Data Data +---------+ | PIT | (update path label) Data
<------| Content |<---| |<---------------------------------------- <------| Content |<---| |<----------------------------------------
| Store | | | | Store | | |
+---------+ +-----+ +---------+ +-----+
| |
| (no match) | (no match)
v v
Figure 2: Path Steering CCNx / NDN data plane Figure 2: Path Steering CCNx/NDN Data Plane
2.3. Handling Path Steering errors 2.3. Handling Path Steering Errors
Over time, the state of interfaces and the FIB on forwarders may Over time, the state of interfaces and the FIB on forwarders may
change such that, at any particular forwarder, a given nexthop is no change such that, at any particular forwarder, a given nexthop is no
longer valid for a given prefix. In this case, the path label will longer valid for a given prefix. In this case, the path label will
point to a now-invalid nexthop. This is detected by failure to find point to a now-invalid nexthop. This is detected by failure to find
a match between the decoded nexthop ID and the nexthops of the FIB a match between the decoded nexthop ID and the nexthops of the FIB
entry after LNPM FIB lookup. entry after LNPM FIB lookup.
On detecting an invalid path label, the forwarder SHOULD respond to On detecting an invalid path label, the forwarder SHOULD respond to
the Interest with an Interest-Return. We therefore define a new the Interest with an InterestReturn. Therefore, we define a new
_Invalid path label_ response code for the Interest Return message _invalid path label_ response code for the InterestReturn message and
and include the current path label as a hop-by-hop header. Each include the current path label as a hop-by-hop header. Each transit
transit forwarder processing the Interest-Return message updates the forwarder processing the InterestReturn message updates the path
path label in the same manner as Content (Data) messages, so that the label in the same manner as Content (Data) messages so that the
consumer receiving the Interest-Return (NACK) can easily identify consumer receiving the InterestReturn (NACK) can easily identify
which path label is no longer valid. which path label is no longer valid.
A consumer may alternatively request that a forwarder detecting the A consumer may alternatively request that a forwarder detecting the
inconsistency forward the Interest by means of normal LNPM FIB lookup inconsistency forward the Interest by means of normal LNPM FIB lookup
rather than returning an error. The consumer endpoint, if it cares, rather than return an error. The consumer endpoint, if it cares, can
can keep enough information about outstanding Interests to determine keep enough information about outstanding Interests to determine if
if the path label sent with the Interest fails to match the path the path label sent with the Interest fails to match the path label
label in the corresponding returned Content (Data), and use that in the corresponding returned Content (Data) and use that information
information to replace stale path labels. It does so by setting the to replace stale path labels. It does so by setting the
FALLBACK MODE flag of the path label TLV in its Interest message. FALLBACK_MODE flag of the path label TLV in its Interest message.
2.4. Interactions with Interest Aggregation 2.4. Interactions with Interest Aggregation
If two or more Interests matching the same PIT entry arrive at a If two or more Interests matching the same Pending Interest
forwarder, under current behavior they will be aggregated whether or Table (PIT) entry arrive at a forwarder, under current behavior, they
not they carry identical Path Labels TLVs. This may or may not be will be aggregated whether or not they carry identical path label
appropriate. For example, multiple Interests with different MODES TLVs. This may or may not be appropriate. For example, multiple
(e.g. one with DISCOVERY MODE and one without) will get aggregated, Interests with different modes (e.g., one with DISCOVERY_MODE and one
and the behavior of the forwarder might therefore be dependent on the without) will get aggregated; therefore, the behavior of the
arrival order of those Interests. In particular, forwarder might be dependent on the arrival order of those Interests.
In particular:
* If the DISCOVERY MODE Interest arrives first, it will be forwarded * If the DISCOVERY_MODE Interest arrives first, it will be forwarded
and potentially discover a new path, while the other Interest and potentially discover a new path, while the other Interest will
would be aggregated. If that Interest carried no Path Label, its be aggregated. If that Interest carried no path label, its
behavior is essentially unchanged, but if it carried a non behavior is essentially unchanged, but if it carried a path label
DISCOVERY MODE Path Label, the consumer's intent for the Interest without specifying DISCOVERY_MODE, the consumer's intent for the
to traverse the specified path will be ignored and it is Interest to traverse the specified path will be ignored, and it is
indeterminate if the chosen path will actually be used. indeterminate if the chosen path will actually be used.
* If the two Interests arrive in the reverse order, the DISCOVERY * If the two Interests arrive in the reverse order, the DISCOVERY
MODE Interest will be aggregated and the consumer issuing it does MODE Interest will be aggregated, and the consumer issuing it will
not achieve its desire to discover a new path. not achieve its desire to discover a new path.
Multiple Interests intended to discover paths (i.e. by carrying the Multiple Interests intended to discover paths (i.e., by carrying the
DISCOVERY MODE flag defined in Section 2.5) might also be aggregated DISCOVERY_MODE flag defined in Section 3.1) might also be aggregated
by a forwarder. This limits the ability to discover multiple paths by a forwarder. This limits the ability to discover multiple paths
in parallel and instead must be discovered incrementally in in parallel and, instead, must be discovered incrementally in
subsequent exchanges. In other words, aggregated Interests will all subsequent exchanges. In other words, aggregated Interests will all
discover only one single path carried by one single Data packet. discover only one single path carried by one single Data packet.
This has implications for management applications like Traceroute This has implications for management applications, like traceroute
[I-D.irtf-icnrg-icntraceroute] which would likely perform much better [RFC9507], which would likely perform much better if they discover
if they discover paths in parallel. Hence, it is RECOMMENDED when paths in parallel. Hence, when employing path steering, it is
employing Path Steering that such applications craft their Interests RECOMMENDED that such applications craft their Interests with unique
with unique name suffixes in order to avoid being aggregated. name suffixes in order to avoid being aggregated.
| While path steering still operates correctly if DISCOVERY MODE | While path steering still operates correctly if DISCOVERY MODE
| Interests are aggregated, after further experimentation it may | Interests are aggregated, after further experimentation, it may
| be appropriate to advise that: | be appropriate to advise that a forwarder:
| |
| * a forwarder SHOULD NOT aggregate Interests carrying | * SHOULD NOT aggregate Interests carrying different path
| different Path Labels, and | labels and
| |
| * SHOULD apply a rate limit to DISCOVERY MODE Interests in | * SHOULD apply a rate limit to DISCOVERY_MODE Interests in
| order to limit redundant traffic. | order to limit redundant traffic.
2.5. How to represent the Path Label 2.5. How to Represent the Path Label
[Moiseenko2017] presents various options for how to represent a path [Moiseenko2017] presents various options for how to represent a path
label, with different tradeoffs in flexibility, performance and space label, with different trade-offs in flexibility, performance, and
efficiency. For this specification, we choose the _Polynomial space efficiency. For this specification, we choose the _polynomial
encoding_ which achieves reasonable space efficiency at the cost of encoding_, which achieves reasonable space efficiency at the cost of
establishing a hard limit on the length of paths that can be establishing a hard limit on the length of paths that can be
represented. represented.
The polynomial encoding utilizes a fixed-size bit array. Each The polynomial encoding utilizes a fixed-size bit array. Each
transit ICN forwarder is allocated a fixed sized portion of the bit transit ICN forwarder is allocated a fixed-size portion of the bit
array. This design allocates 12 bits (i.e. 4095 as a _generator array. This design allocates 12 bits (i.e., 4095 as a _generator
polynomial_) to each intermediate ICN forwarder. This matches the polynomial_) to each intermediate ICN forwarder. This matches the
scalability of today's commercial routers that support up to 4096 scalability of today's commercial routers that support up to 4096
physical and logical interfaces and usually do not have more than a physical and logical interfaces and usually do not have more than a
few hundred active ones. few hundred active ones.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Path Label bitmap | | path label bitmap |
+----------+-----------------+-----------------+-------------------+ +----------+-----------------+-----------------+-------------------+
| index | nexthop label | nexthop label | | | index | Nexthop Label | Nexthop Label | |
+----------+-----------------+-----------------+-------------------+ +----------+-----------------+-----------------+-------------------+
|<- 8bit ->|<---- 12bit ---->|<---- 12bit ---->|<----------------->| |<- 8bit ->|<---- 12bit ---->|<---- 12bit ---->|<----------------->|
Figure 3: Fixed size path label Figure 3: Fixed-Size Path Label
A forwarder that receives a Content (Data) message encodes the A forwarder that receives a Content (Data) message encodes the
nexthop label in the next available slot and increments label index. Nexthop Label in the next available slot and increments the label
Conversely, a forwarder that receives an Interest message reads the index. Conversely, a forwarder that receives an Interest message
current nexthop label and decrements label index. Therefore, the reads the current Nexthop Label and decrements the label index.
extra computation required at each hop to forward either an interest Therefore, the extra computation required at each hop to forward
or Content Object message with a path label is minimized and either an Interest or Content Object message with a path label is
constitutes a fairly trivial additional overhead compared to FIB minimized and constitutes a fairly trivial additional overhead
lookup and other required operations. compared to FIB lookup and other required operations.
This approach results in individual path label TLV instances being of This approach results in individual path label TLV instances being of
fixed pre-computed size. While this places a hard upper bound on the fixed pre-computed size. While this places a hard upper bound on the
maximum number of network hops that can be represented, this is not a maximum number of network hops that can be represented, this is not a
significant a practical problem in NDN and CCNx, since the size can significant practical problem in NDN and CCNx, since the size can be
be pre-set during Content(Data) message encoding based on the exact preset during Content (Data) message encoding based on the exact
number of network hops traversed by the Interest message. Even long number of network hops traversed by the Interest message. Even long
paths of 24 hops will fit in a path label bitmap of 36 bytes if paths of 24 hops will fit in a path label bitmap of 36 bytes if the
nexthop label is encoded in 12 bits. Nexthop Label is encoded in 12 bits.
3. Mapping to CCNx and NDN packet encodings 3. Mapping to CCNx and NDN Packet Encodings
3.1. Path label TLV 3.1. Path Label TLV
A Path label TLV is the tuple: {[Flags], [Path Label Hop Count], A path label TLV is the tuple: {[Flags], [Path Label Hop Count],
[Nexthop Label], [Path label bitmap]}. [Nexthop Label], [path label bitmap]}.
+================+=============+ +================+=============+
| Flag | Value (hex) | | Flag | Value (hex) |
+================+=============+ +================+=============+
| DISCOVERY_MODE | 0x00 | | DISCOVERY_MODE | 0x00 |
+----------------+-------------+ +----------------+-------------+
| FALLBACK_MODE | 0x01 | | FALLBACK_MODE | 0x01 |
+----------------+-------------+ +----------------+-------------+
| STRICT_MODE | 0x02 | | STRICT_MODE | 0x02 |
+----------------+-------------+ +----------------+-------------+
| Unassigned | 0x03-0xFF | | Unassigned | 0x03-0xFF |
+----------------+-------------+ +----------------+-------------+
Table 1: Path label flags Table 1: Path Label Flags
The Path Label Hop Count (PLHC) MUST be incremented by NDN and CCNx The Path Label Hop Count (PLHC) MUST be incremented by NDN and CCNx
forwarders if the Interest packet carries a path label and DISCOVERY forwarders if the Interest packet carries a path label and the
mode flag is set. A producer node or a forwarder with cached data DISCOVERY_MODE flag is set. A producer node or a forwarder with a
packet MUST use PLHC in calculation of a path label bitmap size cached Data packet MUST use the PLHC in calculation of a path label
suitable for encoding the entire path to the consumer. The Path bitmap size that is suitable for encoding the entire path to the
Label Hop Count (PLHC) MUST be set to zero in newly created Data or consumer. The PLHC MUST be set to zero in newly created Data or
Interest-Return (NACK) packets. A consumer node MUST reuse Path InterestReturn (NACK) packets. A consumer node MUST reuse the PLHC
Label Hop Count (PLHC) together with the Path label bitmap (PLB) in together with the path label bitmap (PLB) in order to correctly
order to correctly forward the Interest(s) along the corresponding forward the Interest(s) along the corresponding network path.
network path.
If an NDN or CCNx forwarder supports path labeling, the Nexthop label If an NDN or CCNx forwarder supports path labeling, the Nexthop Label
MUST be used to determine the correct egress interface for an MUST be used to determine the correct egress interface for an
Interest packet carrying either the FALLBACK MODE or STRICT MODE Interest packet carrying either the FALLBACK_MODE or the STRICT_MODE
flag. If any particular NDN or CCNx forwarder is configured to flag. If any particular NDN or CCNx forwarder is configured to
decrypt path labels of Interest packets (Section Security decrypt path labels of Interest packets (see Security
Considerations (Section 5)), then the forwarder MUST Considerations), then the forwarder MUST:
1. decrypt the path label with its own symmetric key, 1. decrypt the path label with its own symmetric key,
2. update the nexthop label with outermost label in the path label, 2. update the Nexthop Label with outermost label in the path label,
3. decrement Path Label Hop Count (PLHC), and 3. decrement the PLHC, and
4. remove the outermost label from the path label. 4. remove the outermost label from the path label.
If any particular NDN or CCNx forwarder is NOT configured to decrypt If any particular NDN or CCNx forwarder is NOT configured to decrypt
path labels of Interest packets, then path label decryption SHOULD path labels of Interest packets, then path label decryption SHOULD
NOT be performed. NOT be performed.
The Nexthop label MUST be ignored by NDN and CCNx forwarders if The Nexthop Label MUST be ignored by NDN and CCNx forwarders if it is
present in Data or Interest-Return (NACK) packets. If any particular present in Data or InterestReturn (NACK) packets. If any particular
NDN or CCNx forwarder is configured to encrypt path labels of Data NDN or CCNx forwarder is configured to encrypt path labels of Data
and Interest-Return (NACK) packets (Section Security Considerations and InterestReturn (NACK) packets (see Security Considerations), then
(Section 5)), then the forwarder MUST encrypt existing path label the forwarder MUST encrypt the existing path label with its own
with its own symmetric key, append the nexthop label of the ingress symmetric key, append the Nexthop Label of the ingress interface to
interface to the path label, and increment Path Label Hop Count the path label, and increment the PLHC. If any particular NDN or
(PLHC). If any particular NDN or CCNx forwarder is NOT configured to CCNx forwarder is NOT configured to encrypt path labels of Interest
encrypt path labels of Interest packets, then path label encryption packets, then path label encryption SHOULD NOT be performed.
SHOULD NOT be performed.
NDN and CCNx forwarders MUST fallback to longest name prefix match NDN and CCNx forwarders MUST fall back to Longest Name Prefix Match
(LNPM) FIB lookup if an Interest packet carries an invalid nexthop (LNPM) FIB lookup if an Interest packet carries an invalid Nexthop
label and the FALLBACK MODE flag is set. Label and the FALLBACK_MODE flag is set.
CCNx forwarders MUST respond with an Interest Return packet CCNx forwarders MUST respond with an InterestReturn packet specifying
specifying a T_RETURN_INVALID_PATH_LABEL code if Interest packet a T_RETURN_INVALID_PATH_LABEL code if the Interest packet carries an
carries an invalid path label and the STRICT MODE flag is set. This invalid path label and the STRICT_MODE flag is set. This is a new
is a new Interrest return code defined herein (see Section 4 for the InterestReturn code defined herein (see Section 4 for the value
value allocation). allocation).
CCNx forwarders MUST respond with an Interest Return packet CCNx forwarders MUST respond with an InterestReturn packet specifying
specifying the existing T_RETURN_MALFORMED_INTEREST code if the the existing T_RETURN_MALFORMED_INTEREST code if the Interest packet
Interest packet carries a path label TLV with both FALLBACK MODE and carries a path label TLV with both the FALLBACK_MODE and STRICT_MODE
STRICT MODE flags set. flags set.
3.2. Path label encoding for CCNx 3.2. Path Label Encoding for CCNx
Path Label is an optional Hop-by-Hop header TLV that can be present Path label is an optional hop-by-hop header TLV that can be present
in CCNx Interest, InterestReturn and Content Object packets. 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 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 | | T_PATH_LABEL | Length + 4 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Flags | Path Label | Nexthop Label | | Flags | Path Label | Nexthop Label |
| | Hop Count | | | | Hop Count | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ / / /
/ Path label bitmap (Length octets) / / Path label bitmap (Length octets) /
/ / / /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 4: Path label Hop-by-Hop header TLV for CCNx Figure 4: Path Label Hop-by-Hop Header TLV for CCNx
3.3. Path label encoding for NDN 3.3. Path Label Encoding for NDN
Path Label is an optional TLV for NDN Interest and Data packets which Path label is an optional TLV for NDN Interest and Data packets. It
is carried in the NDN Link Adaptation Protocol [NDNLPv2] used to wrap is carried in the NDN Link Adaptation Protocol [NDNLPv2], which is
NDN packets for carriage over various link layer protocols. NDNLPv2 used to wrap NDN packets for carriage over various link layer
was chosen over the NDN packet itself since it can carry hop-by-hop protocols. NDNLPv2 was chosen over the NDN packet itself since it
information that potentially mutates at each hop and therefore cannot can carry hop-by-hop information that potentially mutates at each hop
be included in the secured hash computation or the signature of NDN and, therefore, cannot be included in the secured hash computation or
packets. Further, it can be used instead of the existing the signature of NDN packets. Further, it can be used instead of the
NextHopFaceId TLV since it not only can specify the single outgoing existing NextHopFaceId TLV since it not only can specify the single
face for a consumer, but manages the selection and forwarding over an outgoing face for a consumer but manages the selection and forwarding
entire path. The Path Label TLV in NDNLPv2 is defined below: over an entire path. The path label TLV in NDNLPv2 is defined below:
PathLabel = PATH-LABEL-TYPE TLV-LENGTH PathLabel = PATH-LABEL-TYPE TLV-LENGTH
PathLabelFlags PathLabelFlags
PathLabelBitmap PathLabelBitmap
PathLabelFlags = PATH-LABEL-FLAGS-TYPE PathLabelFlags = PATH-LABEL-FLAGS-TYPE
TLV-LENGTH ; == 1 TLV-LENGTH ; == 1
OCTET OCTET
NexthopLabel = PATH-LABEL-NEXTHOP-LABEL-TYPE NexthopLabel = PATH-LABEL-NEXTHOP-LABEL-TYPE
skipping to change at page 13, line 52 skipping to change at line 598
2 OCTET 2 OCTET
PathLabelHopCount = PATH-LABEL-HOP-COUNT-TYPE PathLabelHopCount = PATH-LABEL-HOP-COUNT-TYPE
TLV-LENGTH ; == 1 TLV-LENGTH ; == 1
OCTET OCTET
PathLabelBitmap = PATH-LABEL-BITMAP-TYPE PathLabelBitmap = PATH-LABEL-BITMAP-TYPE
TLV-LENGTH ; == 64 TLV-LENGTH ; == 64
64 OCTET 64 OCTET
Figure 5: Path label TLV for NDN Figure 5: Path Label TLV for NDN
+============================+=========================+ +============================+=========================+
| Flag | (Suggested) Value (hex) | | Flag | (Suggested) Value (hex) |
+============================+=========================+ +============================+=========================+
| T_PATH_LABEL | 0x0A | | T_PATH_LABEL | 0x0A |
+----------------------------+-------------------------+ +----------------------------+-------------------------+
| T_PATH_LABEL_FLAGS | 0x0B | | T_PATH_LABEL_FLAGS | 0x0B |
+----------------------------+-------------------------+ +----------------------------+-------------------------+
| T_PATH_LABEL_BITMAP | 0x0D | | T_PATH_LABEL_BITMAP | 0x0D |
+----------------------------+-------------------------+ +----------------------------+-------------------------+
| T_PATH_LABEL_NEXTHOP_LABEL | 0x0E | | T_PATH_LABEL_NEXTHOP_LABEL | 0x0E |
+----------------------------+-------------------------+ +----------------------------+-------------------------+
| T_PATH_LABEL_HOP_COUNT | 0x0F | | T_PATH_LABEL_HOP_COUNT | 0x0F |
+----------------------------+-------------------------+ +----------------------------+-------------------------+
Table 2: TLV-TYPE number assignments for NDN Table 2: TLV-TYPE Number Assignments for NDN
4. IANA Considerations 4. IANA Considerations
IANA is requested to make the following assignments: IANA has made the following assignments:
1. Please assign the value 0x000A (if still available) for 1. The value 0x000A has been assigned to T_PATH_LABEL in the "CCNx
T_PATH_LABEL in the *CCNx Hop-by-Hop Types* registry established Hop-by-Hop Types" registry, established by [RFC8609].
by [RFC8609].
2. Please assign the value 0x0A (if still available) for the 2. The value 0x0A has been assigned to T_RETURN_INVALID_PATH_LABEL
T_RETURN_INVALID_PATH_LABEL in the *CCNx Interest Return Code in the "CCNx Interest Return Code Types" registry, established by
Types"* registry established by [RFC8609]. [RFC8609].
5. Security Considerations 5. Security Considerations
A path is invalidated by renumbering nexthop label(s). A malicious A path is invalidated by renumbering one or more Nexthop Labels. A
consumer can attempt to mount an attack by transmitting Interests malicious consumer can attempt to mount an attack by transmitting
with path labels which differ only in a single now-invalid nexthop Interests with path labels that differ only in a single now-invalid
label in order to _brute force_ a valid nexthop label. If such an Nexthop Label in order to _brute-force_ a valid Nexthop Label. If
attack succeeds, a malicious consumer would be capable of steering such an attack succeeds, a malicious consumer would be capable of
Interests over a network path that may not match the paths computed steering Interests over a network path that may not match the paths
by the routing algorithm or learned adaptively by the forwarders. computed by the routing algorithm or learned adaptively by the
forwarders.
When a label lookup fails, by default an _Invalid path label_ When a label lookup fails, by default, an _invalid path label_
Interest-Return (NACK) message is returned to the consumer. This InterestReturn (NACK) message is returned to the consumer. This
contains a path label identical to the one included in the contains a path label identical to the one included in the
corresponding Interest message. A malicious consumer can therefore corresponding Interest message. Therefore, a malicious consumer can
analyze the message's Hop Count field to infer which specific nexthop analyze the message's Hop Count field to infer which specific Nexthop
label had failed and direct an attack to influence path steering at Label had failed and direct an attack to influence path steering at
that hop. This threat can be mitigated by the following that hop. This threat can be mitigated by the following
countermeasures: countermeasures:
* A nexthop label of larger size is harder to crack. If nexthop * A Nexthop Label that is larger in size is harder to crack. If
labels are not allocated in a predictable fashion by the routers, Nexthop Labels are not allocated in a predictable fashion by the
brute forcing a 32-bit nexthop label requires on average O(2^31) routers, brute-forcing a 32-bit Nexthop Label requires on average
Interests. However, this specification uses nexthop labels with O(2^31) Interests. However, this specification uses Nexthop
much less entropy (12 bits), so depending on computational Labels with much less entropy (12 bits), so depending on
hardness is not workable. computational hardness is not workable.
* An ICN forwarder can periodically update nexthop labels to limit * An ICN forwarder can periodically update Nexthop Labels to limit
the maximum lifetime of paths. It is RECOMMENDED that forwarders the maximum lifetime of paths. It is RECOMMENDED that forwarders
update path labels at least every few minutes. update path labels at least every few minutes.
* A void Hop Count field in an _Invalid path label_ Interest-Return * A void Hop Count field in an _invalid path label_ InterestReturn
(NACK) message would not give out the information on which (NACK) message would not give out the information on which a
specific nexthop label had failed. An attacker might need to specific Nexthop Label had failed. An attacker might need to
brute force all nexthop labels in all combinations. However, some brute-force all Nexthop Labels in all combinations. However, some
useful diagnostic capability is lost by obscuring the hop count. useful diagnostic capability is lost by obscuring the hop count.
For example the locus of routing churn is harder to pin down For example, the locus of routing churn is harder to pin down
through analysis of path-steered pings or traceroutes. A through analysis of path-steered pings or traceroutes. A
forwarder MAY choose to invalidate the hop count in addition to forwarder MAY choose to invalidate the hop count in addition to
changing nexthop labels periodically as above. changing Nexthop Labels periodically as described above.
Because ICN forwarders maintain per-face state and forwarding state Because ICN forwarders maintain per-face state and forwarding state
for Interest messages, state inflation attacks are a general concern. for Interest messages, state inflation attacks are a general concern.
The addition of path steering capabilities in Interest and Data The addition of path steering capabilities in Interest and Data
messages does not, however, constitute a meaningful increase in messages does not, however, constitute a meaningful increase in
susceptibility to such attacks. This is because: susceptibility to such attacks. This is because:
* The labels that identify each forwarding face is state O(number of * The labels that identify each forwarding face is state O(number of
faces) and constitutes a small increase to the existing state faces) and constitutes a small increase to the existing state
needed to represent a face. needed to represent a face.
* Interest message data is placed in the PIT. The path steering * Interest message data is placed in the PIT. The path steering
header does in fact inflate the size of the Interest message and header does, in fact, inflate the size of the Interest message
hence the PIT state, but not by an amount that is a concern. The and, hence, the PIT state but not by an amount that is a concern.
forwarder needs to protect against state inflation attacks on the The forwarder needs to protect against state inflation attacks on
PIT in general, and an attacker can mount one as or more easily the PIT in general, and an attacker can mount one just as or more
just by issuing interests with long names and/or by including easily by issuing Interests with long names and/or by including
Interest payload data. Interest payload data.
ICN protocols can be susceptible to a variety of cache poisoning ICN protocols can be susceptible to a variety of cache poisoning
attacks, where a colluding consumer and producer arrange for bogus attacks, where a colluding consumer and producer arrange for bogus
content (with either invalid or inappropriate signatures) to populate content (with either invalid or inappropriate signatures) to populate
forwarder caches. These are generally confined to on-path attacks. forwarder caches. These are generally confined to on-path attacks.
It is also theoretically possible to launch a similar attack without It is also theoretically possible to launch a similar attack without
a cooperating producer such that the caches of on-path routers become a cooperating producer such that the caches of on-path routers become
poisoned with the content from off-path routers (i.e. physical poisoned with the content from off-path routers (i.e., physical
connectivity, but no route in a FIB for a given prefix). We estimate connectivity but no route in a FIB for a given prefix). We estimate
that without any prior knowledge of the network topology, the that, without any prior knowledge of the network topology, the
complexity of this type of attack is in the ballpark of Breadth- complexity of this type of attack is in the ballpark of Breadth-
First-Search and Depth-First-Search algorithms with the additional First-Search and Depth-First-Search algorithms with the additional
burden of transmitting 2^31 Interests in order to crack a nexthop burden of transmitting 2^31 Interests in order to crack a Nexthop
label on each hop. Relatively short periodic update of nexthop Label on each hop. A relatively short periodic update of Nexthop
labels and anti- _label scan_ heuristics implemented in the ICN Labels, together with heuristics implemented in the ICN forwarder to
forwarder may successfully mitigate this type of attack. foil _label scans_, may successfully mitigate this type of attack.
5.1. Cryptographic protection of a path label 5.1. Cryptographic Protection of a Path Label
If the countermeasures listed above do not provide sufficient If the countermeasures listed above do not provide sufficient
protection against malicious mis-steering of Interests, the path protection against malicious mis-steering of Interests, the path
label can be made opaque to the consumer endpoint via hop-by-hop label can be made opaque to the consumer endpoint via hop-by-hop
symmetric cryptography applied to the path labels (Figure 6). This symmetric cryptography applied to the path labels (Figure 6). This
method is viable due to the symmetry of forward and reverse paths in method is viable due to the symmetry of forward and reverse paths in
CCNx and NDN architectures combined with ICN path steering requiring CCNx and NDN architectures combined with ICN path steering requiring
only reads/writes of the topmost nexthop label (i.e. active nexthop only reads and writes of the topmost Nexthop Label (i.e., active
label) in the path label. This way a path steering capable ICN Nexthop Label) in the path label. This way, a path-steering-capable
forwarder receiving a Data (Content) message encrypts the current ICN forwarder receiving a Content (Data) message encrypts the current
path label with its own non-shared symmetric key prior to adding a path label with its own non-shared symmetric key prior to adding a
new nexthop label to the path label. The Data (Content) message is new Nexthop Label to the path label. The Content (Data) message is
forwarded downstream with unencrypted topmost (i.e active) nexthop forwarded downstream with an unencrypted topmost (i.e., active)
label and encrypted remaining content of the path label. As a Nexthop Label and the remaining encrypted content of the path label.
result, a consumer endpoint receives a Data (Content) message with a As a result, a consumer endpoint receives a Content (Data) message
unique path label exposing only the topmost nexthop label as with a unique path label exposing only the topmost Nexthop Label as
cleartext. A path steering forwarder receiving an Interest message cleartext. A path steering forwarder receiving an Interest message
performs label lookup using the topmost nexthop label, decrypts the performs label lookup using the topmost Nexthop Label, decrypts the
path label with its own non-shared symmetric key, and forwards the path label with its own non-shared symmetric key, and forwards the
message upstream. message upstream.
Cryptographic protection of a path label does not require any key Cryptographic protection of a path label does not require any key
negotiation among ICN forwarders, and is no more expensive than negotiation among ICN forwarders and is no more expensive than Media
MACsec or IPsec. It is also quite possible that strict hop-by-hop Access Control Security (MACsec) or IPsec. It is also quite possible
path label encryption is not necessary and path label encryption only that strict hop-by-hop path label encryption is not necessary and
on the border routers of the trusted administrative or routing path label encryption only on the border routers of the trusted
domains may suffice. administrative or routing domains may suffice.
Producer Producer
| ^ | ^
| | | |
Path Label TLV | | Path Label TLV Path Label TLV | | Path Label TLV
+-----------------------+ | | +-----------------------+ +-----------------------+ | | +-----------------------+
|nexthop label=456 | v | |nexthop label=456 | |nexthop label=456 | v | |nexthop label=456 |
|encrypted path label={}| Forwarder 3 |encrypted path label={}| |encrypted path label={}| Forwarder 3 |encrypted path label={}|
+-----------------------+ | ^ +-----------------------+ +-----------------------+ | ^ +-----------------------+
| | | |
skipping to change at page 17, line 42 skipping to change at line 781
path label is encrypted | | path label is decrypted path label is encrypted | | path label is decrypted
with Forwarder 1 | | with Forwarder 1 with Forwarder 1 | | with Forwarder 1
symmetric key | | symmetric key symmetric key | | symmetric key
| | | |
| | | |
| | | |
| | | |
v | v |
Consumer Consumer
Figure 6: Path label protection with hop-by-hop symmetric Figure 6: Path Label Protection with Hop-by-Hop Symmetric
cryptography Cryptography
6. References 6. References
6.1. Normative References 6.1. Normative References
[Moiseenko2017] [Moiseenko2017]
Moiseenko, I. and D. Oran, "Path Switching in Content Moiseenko, I. and D. Oran, "Path Switching in Content
Centric and Named Data Networks, in 4th ACM Conference on Centric and Named Data Networks", Proceedings of the 4th
Information-Centric Networking (ICN 2017)", ACM Conference on Information-Centric Networking, Pages
66-76, DOI 10.1145/3125719.3125721,
DOI 10.1145/3125719.3125721, September 2017, DOI 10.1145/3125719.3125721, September 2017,
<https://conferences.sigcomm.org/acm-icn/2017/proceedings/ <https://conferences.sigcomm.org/acm-icn/2017/proceedings/
icn17-2.pdf>. icn17-2.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 18, line 30 skipping to change at line 818
DOI 10.17487/RFC8569, July 2019, DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>. <https://www.rfc-editor.org/info/rfc8569>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Messages in TLV Format", RFC 8609, Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019, DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>. <https://www.rfc-editor.org/info/rfc8609>.
6.2. Informative References 6.2. Informative References
[I-D.dekater-panrg-scion-overview] [FLIC] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, Ed.,
de Kater, C., Rustignoli, N., and A. Perrig, "SCION
Overview", Work in Progress, Internet-Draft, draft-
dekater-panrg-scion-overview-04, 7 September 2023,
<https://datatracker.ietf.org/doc/html/draft-dekater-
panrg-scion-overview-04>.
[I-D.irtf-icnrg-flic]
Tschudin, C., Wood, C. A., Mosko, M., and D. R. Oran,
"File-Like ICN Collections (FLIC)", Work in Progress, "File-Like ICN Collections (FLIC)", Work in Progress,
Internet-Draft, draft-irtf-icnrg-flic-04, 24 October 2022, Internet-Draft, draft-irtf-icnrg-flic-05, 22 October 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
flic-04>.
[I-D.irtf-icnrg-icnping]
Mastorakis, S., Oran, D. R., Gibson, J., Moiseenko, I.,
and R. Droms, "ICN Ping Protocol Specification", Work in
Progress, Internet-Draft, draft-irtf-icnrg-icnping-12, 28
August 2023, <https://datatracker.ietf.org/doc/html/draft-
irtf-icnrg-icnping-12>.
[I-D.irtf-icnrg-icntraceroute]
Mastorakis, S., Oran, D. R., Moiseenko, I., Gibson, J.,
and R. Droms, "ICN Traceroute Protocol Specification",
Work in Progress, Internet-Draft, draft-irtf-icnrg-
icntraceroute-11, 17 August 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg- <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
icntraceroute-11>. flic-05>.
[Mahdian2016] [Mahdian2016]
Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, Mahdian, M., Arianfar, S., Gibson, J., and D. Oran,
"MIRCC: Multipath-aware ICN Rate-based Congestion Control, "MIRCC: Multipath-aware ICN Rate-based Congestion
in Proceedings of the 3rd ACM Conference on Information- Control", Proceedings of the 3rd ACM Conference on
Centric Networking", DOI 10.1145/2984356.2984365, 2022, Information-Centric Networking, Pages 1-10,
DOI 10.1145/2984356.2984365, September 2016,
<http://conferences2.sigcomm.org/acm-icn/2016/proceedings/ <http://conferences2.sigcomm.org/acm-icn/2016/proceedings/
p1-mahdian.pdf>. p1-mahdian.pdf>.
[NDN] "Named Data Networking", various, [NDN] NDN, "Named Data Networking: Executive Summary",
<https://named-data.net/project/execsummary/>. <https://named-data.net/project/execsummary/>.
[NDNLPv2] "Named Data Networking Link Adaptation Protocol v2", [NDNLPv2] NFD, "NDNLPv2", <https://redmine.named-
various, <https://redmine.named-
data.net/projects/nfd/wiki/NDNLPv2>. data.net/projects/nfd/wiki/NDNLPv2>.
[NDNTLV] "NDN Packet Format Specification 0.3.", 2022, [NDNTLV] NDN, "NDN Packet Format Specification v0.3",
<https://named-data.net/doc/NDN-packet-spec/current/>. <https://named-data.net/doc/NDN-packet-spec/current/>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029, Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017, DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>. <https://www.rfc-editor.org/info/rfc8029>.
[RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, [RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
D., and C. Tschudin, "Information-Centric Networking D., and C. Tschudin, "Information-Centric Networking
(ICN): Content-Centric Networking (CCNx) and Named Data (ICN): Content-Centric Networking (CCNx) and Named Data
Networking (NDN) Terminology", RFC 8793, Networking (NDN) Terminology", RFC 8793,
DOI 10.17487/RFC8793, June 2020, DOI 10.17487/RFC8793, June 2020,
<https://www.rfc-editor.org/info/rfc8793>. <https://www.rfc-editor.org/info/rfc8793>.
[RFC9217] Trammell, B., "Current Open Questions in Path-Aware [RFC9217] Trammell, B., "Current Open Questions in Path-Aware
Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022, Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022,
<https://www.rfc-editor.org/info/rfc9217>. <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,
February 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,
February 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 [Song2018] Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level
Multi-path Interest Control for Information Centric Multi-path Interest Control for Information Centric
Networking, in 5th ACM Conference on Information-Centric Networking", Proceedings of the 5th ACM Conference on
Networking", DOI 10.1145/3267955.3267971, 2018, Information-Centric Networking, Pages 77-87,
DOI 10.1145/3267955.3267971, September 2018,
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/ <https://conferences.sigcomm.org/acm-icn/2018/proceedings/
icn18-final62.pdf>. icn18-final62.pdf>.
Authors' Addresses Authors' Addresses
Ilya Moiseenko Ilya Moiseenko
Apple, Inc. Apple, Inc.
Cupertino, CA Cupertino, CA
United States of America United States of America
Email: iliamo@mailbox.org Email: iliamo@mailbox.org
 End of changes. 117 change blocks. 
351 lines changed or deleted 352 lines changed or added

This html diff was produced by rfcdiff 1.48.