Internet Research Task Force (IRTF) I. Moiseenko
Request for Comments: 9531 Apple, Inc.
Category: Experimental D. Oran
ISSN: 2070-1721 Network Systems Research and Design
March 2024
Path steering is a mechanism to discover paths to the producers of Information-Centric Networking (ICN) Content Objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multi-path congestion control algorithms and for network measurement and management. This specification derives directly from the design published in "Path Switching in Content Centric and Named Data Networks" (4th ACM Conference on Information-Centric Networking) and, therefore, does not recapitulate the design motivations, implementation details, or evaluation of the scheme. However, some technical details are different, and where there are differences, the design documented here is to be considered definitive.
パスステアリングは、情報中心のネットワーキング（ICN）コンテンツオブジェクトの生産者へのパスを発見し、以前に発見されたパスに沿ってその後の関心メッセージをステアリングするメカニズムです。最先端のマルチパス輻輳制御アルゴリズムの操作や、ネットワーク測定と管理など、さまざまな用途があります。この仕様は、「コンテンツ中心および名前のデータネットワークのパススイッチング」（情報中心のネットワークに関する第4回ACM会議）に掲載された設計から直接派生しているため、スキームの設計動機、実装の詳細、または評価を再現しません。ただし、いくつかの技術的な詳細は異なり、違いがある場合、ここに文書化された設計は決定的であると見なされます。
This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). It is not an IETF product and is not an Internet Standard.
このドキュメントは、IRTF情報中心のネットワーキング研究グループ（ICNRG）の製品です。IETF製品ではなく、インターネット標準でもありません。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の情報中心のネットワーキング研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9531で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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' Addresses
Path steering is a mechanism to discover paths to the producers of ICN Content Objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multi-path congestion control algorithms and for network measurement and management. This specification derives directly from the design published in [Moiseenko2017] and, therefore, does not recapitulate the design motivations, implementation details, or evaluation of the scheme. That publication should be considered a normative reference as it is not likely a reader will be able to understand all elements of this design without first having read the reference. However, some technical details are different, and where there are differences, the design documented here is to be considered definitive.
パスステアリングは、ICNコンテンツオブジェクトの生産者へのパスを発見し、以前に発見されたパスに沿ってその後の関心メッセージを操縦するメカニズムです。最先端のマルチパス輻輳制御アルゴリズムの操作や、ネットワーク測定と管理など、さまざまな用途があります。この仕様は、[Moiseenko2017]で公開されている設計から直接派生しているため、スキームの設計動機、実装の詳細、または評価を再現しません。この出版物は、読者が最初に参照を読んでもこのデザインのすべての要素を理解することができない可能性が高いため、規範的な参照と見なされるべきです。ただし、いくつかの技術的な詳細は異なり、違いがある場合、ここに文書化された設計は決定的であると見なされます。
Path discovery and subsequent path steering in ICN networks is facilitated by the symmetry of forward and reverse paths in the Content-Centric Networking (CCNx) and Named Data Networking (NDN) architectures. Path discovery is achieved by a consumer endpoint transmitting an ordinary Interest message and receiving a Content (Data) message containing an end-to-end path label constructed on the reverse path by the forwarding plane. Path steering is achieved by a consumer endpoint including a path label in the Interest message, which is forwarded to each nexthop through the corresponding egress interfaces in conjunction with Longest Name Prefix Match (LNPM) lookup in the Forwarding Information Base (FIB).
ICNネットワークのパス発見とその後のパスステアリングは、コンテンツ中心のネットワーク（CCNX）および名前付きデータネットワーク（NDN）アーキテクチャの前方および逆パスの対称性によって促進されます。パスディスカバリーは、通常の関心メッセージを送信する消費者エンドポイントによって達成され、転送面によって逆パスに構築されたエンドツーエンドパスラベルを含むコンテンツ（データ）メッセージを受信します。パスステアリングは、興味のあるメッセージのパスラベルを含む消費者エンドポイントによって実現されます。これは、転送情報ベース（FIB）の最長名プレフィックスマッチ（LNPM）ルックアップと組み合わせて、対応する出口インターフェイスを介して各Nexthopに転送されます。
This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). It was supported by the ICNRG participants during its development and through Research Group Last Call. It has received detailed review by experts in both the CCNx and NDN communities.
このドキュメントは、IRTF情報中心のネットワーキング研究グループ（ICNRG）の製品です。ICNRG参加者の開発中に、および研究グループの最後の呼び出しを通じてサポートされていました。CCNXコミュニティとNDNコミュニティの両方の専門家から詳細なレビューを受けています。
There are a number of important use cases to justify extending ICN architectures such as CCNx [RFC8569] or NDN [NDN] to provide these capabilities. These are summarized as follows:
これらの機能を提供するために、CCNX [RFC8569]やNDN [NDN]などの拡張ICNアーキテクチャを正当化するための多くの重要なユースケースがあります。これらは次のように要約されています。
* Support the discovery, monitoring, and troubleshooting of multi-path network connectivity, based on names and name prefixes. Analogous functions have been shown to be a crucial operational capability in multicast and multi-path topologies for IP. The canonical tools are the well-known _traceroute_ and _ping_. For point-to-multipoint MPLS, the more recent MPLS traceroute [RFC8029] protocol is used. Equivalent diagnostic functions have been defined for CCNx through the ICN Ping [RFC9508] and ICN Traceroute [RFC9507] specifications; both of which are capable of exploiting path steering, if available.
* 名前と名前のプレフィックスに基づいて、マルチパスネットワーク接続の発見、監視、トラブルシューティングをサポートします。類似の機能は、IPのマルチキャストおよびマルチパストポロジの重要な運用機能であることが示されています。標準的なツールは、よく知られている_traceroute_および_ping_です。Point-to-Multipoint MPLSの場合、最近のMPLS Traceroute [RFC8029]プロトコルが使用されます。ICN Ping [RFC9508]およびICN Traceroute [RFC9507]仕様を介してCCNXに対して同等の診断機能が定義されています。どちらもパスステアリングを悪用することができます。
* Perform accurate online measurement of network performance, which generally requires multiple consecutive packets to follow the same path under control of an application.
* ネットワークパフォーマンスの正確なオンライン測定を実行します。これは、一般に、アプリケーションの制御下で同じパスをたどるために複数の連続したパケットが必要です。
* Improve the performance and flexibility of multi-path congestion control algorithms. Congestion control schemes, such as [Mahdian2016] and [Song2018], depend on the ability of a consumer to explicitly steer packets onto individual paths in a multi-path and/or multi-destination topology.
* マルチパス混雑制御アルゴリズムのパフォーマンスと柔軟性を向上させます。[Mahdian2016]や[song2018]などの混雑制御スキームは、マルチパスおよび/またはマルチデスティングトポロジの個々のパスにパケットを明示的に導く能力に依存します。
* Allow a consumer endpoint to mitigate content poisoning attacks by directing its Interests onto the network paths that bypass poisoned caches.
* 消費者のエンドポイントが、毒のキャッシュをバイパスするネットワークパスにその利益を向けることにより、コンテンツ中毒攻撃を緩和できるようにします。
The path discovery machinery described here may (and likely will) discover paths with varying properties. [RFC9217] discusses a number of open questions in path-aware networking, among which is how to assess and exploit paths having different properties. Experimenting with ICN path steering may be helpful in further elucidating these questions and perhaps shedding light on which path properties are most useful for the use cases cited above.
ここで説明する経路発見機械は、さまざまな特性を持つパスを発見する可能性があります（そしておそらくそうなるでしょう）。[RFC9217]は、パスアウェアネットワーキングにおける多くのオープンな質問について説明しています。その中には、異なるプロパティを持つパスを評価および悪用する方法があります。ICNパスステアリングを実験することは、これらの質問をさらに解明し、おそらく上記のユースケースに最も役立つパスプロパティに光を当てるのに役立つ場合があります。
One nuance compared to other path-aware networking approaches is that ICN path steering piggybacks path discovery on the base ICN data exchange rather than having a separate path advertisement or discovery mechanism. That means when the recorded path comes back in an ICN Data message response, the properties of the path are known only implicitly to the consumer as opposed to being explicitly labeled. That makes the question of what properties a consumer uses to choose a path one of observation or measurement rather than advance selection based on an explicit, advertised property (e.g., SCION [SCION]).
他のパスアウェアネットワーキングアプローチと比較した1つのニュアンスは、ICNパスステアリングピギーバックパスディスカバリーで、別のパス広告や発見メカニズムを持つのではなく、ベースICNデータ交換のパスディスカバリーです。つまり、録画されたパスがICNデータメッセージの応答に戻ると、パスのプロパティは、明示的にラベル付けされるのではなく、消費者に対してのみ暗黙的に知られています。これにより、消費者がどのようなプロパティを使用して、明示的で宣伝されたプロパティ（例：Scion [Scion]）に基づいて前進選択ではなく、観測または測定の1つを選択するパスを選択します。
The utility and overall technical quality of this path steering capability can be assessed by how well it enables the above use cases and what performance and robustness effects it has on the underlying ICN protocols and their use in various applications. A few of the open questions that should be addressed through experimentation with path steering include:
このパスステアリング機能のユーティリティと全体的な技術的品質は、上記のユースケースをどれだけうまく実現できるか、基礎となるICNプロトコルとさまざまなアプリケーションでの使用にどの程度のパフォーマンスと堅牢性の影響があるかによって評価できます。パスステアリングの実験を通じて対処する必要がある未解決の質問のいくつかは次のとおりです。
* How much more accurate and useful are measurements of RTT, packet loss, etc. through ping and traceroute when utilizing path steering?
* パスステアリングを使用するときに、PingやTracerouteを介したRTT、パケット損失などの測定値はどれほど正確で有用ですか？
* How much is the performance and robustness of multi-path forwarding enhanced by the use of this explicit path steering capability?
* この明示的なパスステアリング機能を使用することにより、マルチパス転送のパフォーマンスと堅牢性はどれくらいですか？
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the general ICN terms that are defined in [RFC8793]. In addition, we define the following terms specific to path steering:
このドキュメントでは、[RFC8793]で定義されている一般的なICN用語を使用します。さらに、パスステアリングに固有の次の用語を定義します。
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 that 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.
パケット内のオプションフィールドは、消費者から生産者またはリクエストされたアイテムで応答できる転送業者キャッシュのいずれかまでの特定のパスを示すものです。関心のあるメッセージでは、関心がパスを横断するにつれて、パスラベルがホップによってホップを構築します。データメッセージでは、パスラベルは、1つ以上の後続の関心メッセージで使用するために、消費者にフルパス情報を返します。
Nexthop Label:
Nexthopレーベル：
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 constitutes a full path label.
パスステアの関心メッセージがそのフォワーダーに到着したときに使用する対応するフォワーダーの次のホップを表すパスラベルの1つのエントリ。Nexthopラベルのシーケンスは、フルパスラベルを構成します。
We elucidate the design using CCNx semantics [RFC8569] and extend its CCNx Message Formats [RFC8609] defined in Section 3.2. While the terminology is slightly different, this design can also be applied to NDN by extending its bespoke packet encodings [NDNTLV] (see Section 3.3).
CCNXセマンティクス[RFC8569]を使用して設計を解明し、セクション3.2で定義されているCCNXメッセージ形式[RFC8609]を拡張します。用語はわずかに異なりますが、この設計は、オーダーメイドのパケットエンコーディング[ndntlv]を拡張することにより、NDNにも適用できます（セクション3.3を参照）。
_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) message. The path label is constructed hop by hop as the message traverses the reverse path of transit CCNx forwarders, as shown in the first example in Figure 1. The path label is updated by adding the Nexthop Label of the interface at which the Content (Data) message has arrived to the existing path label. Eventually, when the Content (Data) message arrives at the consumer, the path label identifies the complete path the Content (Data) message took to reach the consumer. As shown in the second example in Figure 1, when multiple paths are available, subsequent Interests may be able to discover additional paths by omitting a path steering TLV and obtaining a new path label on the returning Interest.
_ End-to-End Path Discovery _ for CCNXは、_Path Label_を作成し、CCNXコンテンツ（データ）メッセージにホップバイホップTLVとして配置することで実現されます。図1の最初の例に示すように、メッセージがトランジットCCNX転送業者の逆パスを通過すると、PATHラベルがホップによって構築されます。メッセージが既存のパスラベルに届きました。最終的に、コンテンツ（データ）メッセージが消費者に到着すると、パスラベルはコンテンツ（データ）メッセージが消費者に到達するために取った完全なパスを識別します。図1の2番目の例に示すように、複数のパスが利用可能な場合、その後の関心は、パスステアリングTLVを省略し、戻ってくる関心に関する新しいパスラベルを取得することにより、追加のパスを発見できる可能性があります。
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 Store
Figure 1: Basic Example of Path Discovery and Steering
図1：パスの発見とステアリングの基本的な例
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 a similar (e.g., next chunk, next Application Data Unit, or next pointer in a Manifest [FLIC]) Content (Data) message over the discovered network path. This _path steering_ is achieved by processing the Interest message's path label at each transit ICN forwarder and forwarding the Interest through the specified nexthop among those identified as feasible by LNPM FIB lookup (Figure 2).
CCNXのフォワードパスと逆パスの対称性により、消費者アプリケーションは発見されたパスラベルを再利用して、同じまたは同様のものを取得することができます（例えば、次のチャンク、次のアプリケーションデータユニット、またはマニフェスト[FLIC]コンテンツの次のポインター）（データ）発見されたネットワークパスを介したメッセージ。この_Path Steering_は、各トランジットICNフォワーダーでTents Messageのパスラベルを処理し、LNPM FIB検索で実行可能であると特定されたものの中で指定されたNexthopを通じて関心を転送することによって達成されます（図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)
v
Figure 2: Path Steering CCNx/NDN Data Plane
図2：パスステアリングCCNX/NDNデータプレーン
Over time, the state of interfaces and the FIB on forwarders may 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 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 entry after LNPM FIB lookup.
時間が経つにつれて、インターフェースの状態とフォワーダーのFIBは、特定のフォワーダーで特定のNEXTHOPが特定のプレフィックスに対して有効でないように変化する可能性があります。この場合、パスラベルは、現在無効なNexthopを指します。これは、lnpm fib lookupの後に、デコードされたNexthop IDとFIBエントリのNexthopsとの一致を見つけることができないことによって検出されます。
On detecting an invalid path label, the forwarder SHOULD respond to the Interest with an InterestReturn. Therefore, we define a new _invalid path label_ response code for the InterestReturn message and include the current path label as a hop-by-hop header. Each transit forwarder processing the InterestReturn message updates the path label in the same manner as Content (Data) messages so that the consumer receiving the InterestReturn (NACK) can easily identify which path label is no longer valid.
無効なパスラベルを検出すると、転送者は興味深い関心に対応する必要があります。したがって、TentReturnメッセージの新しい_Invalid Pathラベル_応答コードを定義し、現在のパスラベルをホップバイホップヘッダーとして含めます。Transit Forwarderを処理する各Transit Returnメッセージは、コンテンツ（データ）メッセージと同じ方法でパスラベルを更新し、TentReturn（NACK）を受け取る消費者がどのパスラベルが有効でないかを簡単に識別できるようにします。
A consumer may alternatively request that a forwarder detecting the inconsistency forward the Interest by means of normal LNPM FIB lookup rather than return an error. The consumer endpoint, if it cares, can keep enough information about outstanding Interests to determine if the path label sent with the Interest fails to match the path label in the corresponding returned Content (Data) and use that information to replace stale path labels. It does so by setting the FALLBACK_MODE flag of the path label TLV in its Interest message.
消費者は、エラーを返すのではなく、通常のLNPM FIB検索によって、矛盾を検出する転送者に利子を検出することを代わりに要求する場合があります。消費者のエンドポイントは、それが気をつけている場合、関心とともに送信されたパスラベルが対応する返されたコンテンツ（データ）のパスラベルと一致できないかどうかを判断するために、優れた利益に関する十分な情報を保持でき、その情報を使用して古いパスラベルを置き換えることができます。パスラベルTLVのFallback_modeフラグをその関心メッセージに設定することにより、これを行います。
If two or more Interests matching the same Pending Interest Table (PIT) entry arrive at a forwarder, under current behavior, they will be aggregated whether or not they carry identical path label TLVs. This may or may not be appropriate. For example, multiple Interests with different modes (e.g., one with DISCOVERY_MODE and one without) will get aggregated; therefore, the behavior of the forwarder might be dependent on the arrival order of those Interests. In particular:
現在の動作の下で、同じ係争中の利息テーブル（PIT）エントリに一致する2つ以上の利益がフォワーダーに到着した場合、同一のパスラベルTLVを運ぶかどうかにかかわらず、集約されます。これは適切かもしれないし、そうでないかもしれません。たとえば、異なるモードを持つ複数の関心（例：discovery_modeを持つものとなし）が集約されます。したがって、フォワーダーの動作は、それらの利益の到着命令に依存する可能性があります。特に：
* If the DISCOVERY_MODE Interest arrives first, it will be forwarded and potentially discover a new path, while the other Interest will be aggregated. If that 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 will be ignored, and it is indeterminate if the chosen path will actually be used.
* discovery_modeの関心が最初に到着した場合、それは転送され、潜在的に新しいパスを発見しますが、他の利息は集約されます。その関心にパスラベルがない場合、その動作は本質的に変更されていませんが、discovery_modeを指定せずにパスラベルを運んだ場合、指定されたパスを横断する関心に対する消費者の意図は無視され、実際に選択されたパスが実際に選択される場合は不確定です。利用される。
* If the two Interests arrive in the reverse order, the DISCOVERY MODE Interest will be aggregated, and the consumer issuing it will not achieve its desire to discover a new path.
* 2つの利益が逆の順序で到着した場合、発見モードの関心が集約され、それを発行する消費者は新しいパスを発見したいという欲求を達成しません。
Multiple Interests intended to discover paths (i.e., by carrying the DISCOVERY_MODE flag defined in Section 3.1) might also be aggregated by a forwarder. This limits the ability to discover multiple paths in parallel and, instead, must be discovered incrementally in subsequent exchanges. In other words, aggregated Interests will all discover only one single path carried by one single Data packet. This has implications for management applications, like traceroute [RFC9507], which would likely perform much better if they discover paths in parallel. Hence, when employing path steering, it is RECOMMENDED that such applications craft their Interests with unique name suffixes in order to avoid being aggregated.
パスを発見することを目的とした複数の利益（つまり、セクション3.1で定義されているdiscovery_modeフラグを運ぶことにより）も、フォワーダーによって集約される可能性があります。これにより、複数のパスを並行して発見する能力が制限され、代わりにその後の交換で段階的に発見する必要があります。言い換えれば、集約された関心はすべて、1つのデータパケットによって運ばれる1つのパスのみを発見します。これは、Traceroute [RFC9507]のような管理アプリケーションに影響を与えます。したがって、パスステアリングを使用する場合、そのようなアプリケーションは、集約されないように、ユニークな名前の接尾辞で興味を作ることをお勧めします。
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.
* 冗長なトラフィックを制限するために、discovery_modeの利子にレート制限を適用する必要があります。
[Moiseenko2017] presents various options for how to represent a path label, with different trade-offs in flexibility, performance, and space efficiency. For this specification, we choose the _polynomial encoding_, which achieves reasonable space efficiency at the cost of establishing a hard limit on the length of paths that can be represented.
[Moiseenko2017]は、柔軟性、パフォーマンス、およびスペース効率が異なるさまざまなトレードオフを備えたパスラベルを表現する方法に関するさまざまなオプションを提示しています。この仕様では、_ polynomial Encoding_を選択します。これは、表現できるパスの長さに厳しい制限を確立するための妥当なスペース効率を達成します。
The polynomial encoding utilizes a fixed-size bit array. Each transit ICN forwarder is allocated a fixed-size portion of the bit array. This design allocates 12 bits (i.e., 4095 as a _generator polynomial_) to each intermediate ICN forwarder. This matches the scalability of today's commercial routers that support up to 4096 physical and logical interfaces and usually do not have more than a few hundred active ones.
多項式エンコーディングは、固定サイズビットアレイを使用します。各トランジットICNフォワーダーには、ビットアレイの固定サイズの部分が割り当てられます。この設計には、各中間ICNフォワーダーに12ビット（_generator Polynomial_として4095）を割り当てます。これは、最大4096の物理的および論理的なインターフェイスをサポートする今日の商用ルーターのスケーラビリティと一致し、通常は数百以上のアクティブなインターフェイスを持っていません。
+------------------------------------------------------------------+
| path label bitmap |
+----------+-----------------+-----------------+-------------------+
| index | Nexthop Label | Nexthop Label | |
+----------+-----------------+-----------------+-------------------+
|<- 8bit ->|<---- 12bit ---->|<---- 12bit ---->|<----------------->|
Figure 3: Fixed-Size Path Label
図3：固定サイズのパスラベル
A forwarder that receives a Content (Data) message encodes the Nexthop Label in the next available slot and increments the label index. Conversely, a forwarder that receives an Interest message reads the current Nexthop Label and decrements the label index. Therefore, the extra computation required at each hop to forward either an Interest or Content Object message with a path label is minimized and constitutes a fairly trivial additional overhead compared to FIB lookup and other required operations.
コンテンツ（データ）メッセージを受信するフォワーダーは、次の使用可能なスロットでNexthopラベルをエンコードし、ラベルインデックスを増分します。逆に、興味のメッセージを受信するフォワーダーは、現在のNexthopラベルを読み取り、ラベルインデックスを減少させます。したがって、パスラベルを使用して関心またはコンテンツオブジェクトメッセージを転送するために各ホップで必要な追加の計算は最小化され、FIB検索やその他の必要な操作と比較して、かなり些細な追加オーバーヘッドを構成します。
This approach results in individual path label TLV instances being of 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 significant practical problem in NDN and CCNx, since the size can be preset during Content (Data) message encoding based on the exact 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 the Nexthop Label is encoded in 12 bits.
このアプローチにより、個々のパスラベルTLVインスタンスは、事前に計算されたサイズが固定されています。これにより、表現できるネットワークホップの最大数にハード上限がありますが、これはNDNおよびCCNXでは重要な実用的な問題ではありません。興味のあるメッセージによって横断されるネットワークホップ。Nexthopラベルが12ビットでエンコードされている場合、24ホップの長いパスでも36バイトのパスラベルビットマップに収まります。
A path label TLV is the tuple: {[Flags], [Path Label Hop Count], [Nexthop Label], [path label bitmap]}.
パスラベルTLVはタプルです：{[flags]、[パスラベルホップカウント]、[Nexthopラベル]、[パスラベルビットマップ]}。
+================+=============+
| Flag | Value (hex) |
+================+=============+
| DISCOVERY_MODE | 0x00 |
+----------------+-------------+
| FALLBACK_MODE | 0x01 |
+----------------+-------------+
| STRICT_MODE | 0x02 |
+----------------+-------------+
| Unassigned | 0x03-0xFF |
+----------------+-------------+
Table 1: Path Label Flags
表1：パスラベルフラグ
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 in calculation of a path label bitmap size that is suitable for encoding the entire path to the consumer. The PLHC MUST be set to zero in newly created Data or InterestReturn (NACK) packets. A consumer node MUST reuse the PLHC together with the path label bitmap (PLB) in order to correctly forward the Interest(s) along the corresponding network path.
Path Label Hopカウント（PLHC）は、NDNおよびCCNXフォワーダーによってインクリメントする必要があります。キャッシュされたデータパケットを備えたプロデューサーノードまたはフォワーダーは、消費者へのパス全体をエンコードするのに適したパスラベルビットマップサイズの計算でPLHCを使用する必要があります。PLHCは、新しく作成されたデータまたはInteresturn（NACK）パケットでゼロに設定する必要があります。消費者ノードは、対応するネットワークパスに沿って関心を正しく転送するために、PATHラベルビットマップ（PLB）と一緒にPLHCを再利用する必要があります。
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 any particular NDN or CCNx forwarder is configured to decrypt path labels of Interest packets (see Security Considerations), then the forwarder MUST:
NDNまたはCCNX転送業者がパスラベルをサポートする場合、NEXTHOPラベルを使用して、Fallback_ModeまたはStrict_Modeフラグのいずれかを運ぶ目的パケットの正しい出力インターフェイスを決定する必要があります。特定のNDNまたはCCNX転送業者が、関心のあるパケットのパスラベルを復号化するように構成されている場合（セキュリティ上の考慮事項を参照）、フォワーダーは以下を行う必要があります。
1. decrypt the path label with its own symmetric key,
1. 独自の対称キーでパスラベルを復号化します。
2. update the Nexthop Label with outermost label in the path label,
2. パスラベルに最も外側のラベルを使用して、Nexthopラベルを更新します。
3. decrement the PLHC, and
3. plhcを減らします
4. remove the outermost label from the path label.
4. パスラベルから最も外側のラベルを削除します。
If any particular NDN or CCNx forwarder is NOT configured to decrypt path labels of Interest packets, then path label decryption SHOULD NOT be performed.
特定のNDNまたはCCNX転送業者が関心のあるパケットのパスラベルを復号化するように構成されていない場合、パスラベルの復号化を実行しないでください。
The Nexthop Label MUST be ignored by NDN and CCNx forwarders if it is present in Data or InterestReturn (NACK) packets. If any 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 any particular NDN or CCNx forwarder is NOT configured to encrypt path labels of Interest packets, then path label encryption SHOULD NOT be performed.
Nexthopラベルは、データまたはTentReturn（NACK）パケットに存在する場合、NDNおよびCCNXフォワーダーによって無視する必要があります。特定のNDNまたはCCNX転送業者がデータとTentReturn（NACK）パケットのパスラベルを暗号化するように構成されている場合（セキュリティ上の考慮事項を参照）、フォワーダーは既存のパスラベルに独自の対称キーを暗号化する必要があります。パスラベルに、PLHCを増分します。特定のNDNまたはCCNX転送業者が関心のあるパケットのパスラベルを暗号化するように構成されていない場合、パスラベル暗号化は実行されないでください。
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.
NDNとCCNXのフォワーダーは、興味のあるパケットが無効なNexthopラベルを持ち、Fallback_Modeフラグが設定されている場合、最長の名前プレフィックスマッチ（LNPM）FIBルックアップに戻る必要があります。
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 new InterestReturn code defined herein (see Section 4 for the value allocation).
CCNXフォワーダーは、T_RETURN_INVALID_PATH_LABELコードを指定するT_RETURNパケットで応答する必要があります。これは、本明細書で定義されている新しいTentReturnコードです（値割り当てについてはセクション4を参照）。
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.
CCNXフォワーダーは、既存のT_RETURN_MALFORMED_INTERESTコードを指定するTERTRETURNパケットで応答する必要があります。
Path label is an optional hop-by-hop header TLV that can be present in CCNx Interest, InterestReturn, and Content Object packets.
パスラベルは、CCNXの関心、TentReturn、およびコンテンツオブジェクトパケットに存在できるオプションのホップバイホップヘッダーTLVです。
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 CCNx
図4：CCNXのパスラベルホップバイホップヘッダーTLV
Path label is an optional TLV for NDN Interest and Data packets. It is carried in the NDN Link Adaptation Protocol [NDNLPv2], which is used to wrap NDN packets for carriage over various link layer protocols. NDNLPv2 was chosen over the NDN packet itself since it can carry hop-by-hop information that potentially mutates at each hop and, therefore, cannot be included in the secured hash computation or the signature of NDN packets. Further, it can be used instead of the existing NextHopFaceId TLV since it not only can specify the single outgoing face for a consumer but manages the selection and forwarding over an entire path. The path label TLV in NDNLPv2 is defined below:
パスラベルは、NDNの関心とデータパケットのためのオプションのTLVです。これは、さまざまなリンクレイヤープロトコル上のキャリッジ用のNDNパケットをラップするために使用されるNDNリンク適応プロトコル[NDNLPV2]で運ばれます。Ndnlpv2は、各ホップで潜在的に変異する可能性があり、したがって、NDNパケットのセキュリティハッシュ計算または署名に含めることができないホップバイホップ情報を運ぶことができるため、NDNパケット自体に選択されました。さらに、既存のNexthopfaceID TLVの代わりに使用できます。これは、消費者に単一の発信面を指定できるだけでなく、パス全体にわたって選択と転送を管理するからです。Ndnlpv2のパスラベルTLVを以下に定義します。
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
図5：NDNのパスラベルTLV
+============================+=========================+
| 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 NDN
表2：NDNのTLVタイプ番号割り当て
IANA has made the following assignments:
IANAは次の割り当てを行いました。
1. The value 0x000A has been assigned to T_PATH_LABEL in the "CCNx Hop-by-Hop Types" registry, established by [RFC8609].
1. 値0x000Aは、[RFC8609]によって確立された「CCNXホップバイホップタイプ」レジストリでT_PATH_LABELに割り当てられています。
2. The value 0x0A has been assigned to T_RETURN_INVALID_PATH_LABEL in the "CCNx Interest Return Code Types" registry, established by [RFC8609].
2. 値0x0aは、[rfc8609]によって確立された「ccnx利息リターンコードタイプ」レジストリでt_return_invalid_path_labelに割り当てられています。
A path is invalidated by renumbering one or more Nexthop Labels. A malicious consumer can attempt to mount an attack by transmitting Interests with path labels that differ only in a single now-invalid Nexthop Label in order to _brute-force_ a valid Nexthop Label. If such an attack succeeds, a malicious consumer would be capable of steering Interests over a network path that may not match the paths computed by the routing algorithm or learned adaptively by the forwarders.
パスは、1つ以上のNexthopラベルを変更することにより無効になります。悪意のある消費者は、有効なNexthopラベルを_Brute-Force_にするために、単一の現在のNexthopラベルでのみ異なるパスラベルを使用して関心を送信することにより、攻撃の取り付けを試みることができます。そのような攻撃が成功した場合、悪意のある消費者は、ルーティングアルゴリズムによって計算されたパスと一致しないか、フォワーダーによって適応的に学習したネットワークパスを介して利益を操縦することができます。
When a label lookup fails, by default, an _invalid path label_ InterestReturn (NACK) message is returned to the consumer. This contains a path label identical to the one included in the corresponding Interest message. Therefore, a malicious consumer can analyze the message's Hop Count field to infer which specific Nexthop Label had failed and direct an attack to influence path steering at that hop. This threat can be mitigated by the following countermeasures:
ラベルのルックアップが失敗した場合、デフォルトでは、_Invalid Path Label_ TentReturn（NACK）メッセージが消費者に返されます。これには、対応する関心メッセージに含まれるパスラベルと同じパスラベルが含まれています。したがって、悪意のある消費者はメッセージのホップカウントフィールドを分析して、どの特定のNexthopラベルが失敗したかを推測し、そのホップでパスステアリングに影響を与えるために攻撃を指示できます。この脅威は、次の対策によって軽減できます。
* A Nexthop Label that is larger in size is harder to crack. If Nexthop Labels are not allocated in a predictable fashion by the routers, brute-forcing a 32-bit Nexthop Label requires on average O(2^31) Interests. However, this specification uses Nexthop Labels with much less entropy (12 bits), so depending on computational hardness is not workable.
* サイズが大きいNexthopラベルは、ひび割れにくいです。Nexthopラベルがルーターによって予測可能な方法で割り当てられていない場合、32ビットNexthopラベルをブルートフォーチングするには、平均してO（2^31）の利益が必要です。ただし、この仕様では、エントロピーがはるかに少ない（12ビット）のNexthopラベルを使用するため、計算硬度に応じて実行できません。
* An ICN forwarder can periodically update Nexthop Labels to limit the maximum lifetime of paths. It is RECOMMENDED that forwarders update path labels at least every few minutes.
* ICNフォワーダーは、Nexthopラベルを定期的に更新して、パスの最大寿命を制限できます。フォワーダーは、少なくとも数分ごとにパスラベルを更新することをお勧めします。
* A void Hop Count field in an _invalid path label_ InterestReturn (NACK) message would not give out the information on which a specific Nexthop Label had failed. An attacker might need to brute-force all Nexthop Labels in all combinations. However, some useful diagnostic capability is lost by obscuring the hop count. For example, the locus of routing churn is harder to pin down through analysis of path-steered pings or traceroutes. A forwarder MAY choose to invalidate the hop count in addition to changing Nexthop Labels periodically as described above.
* _Invalid Path Label_ TentReturn（NACK）メッセージのボイドホップカウントフィールドは、特定のNexthopラベルが失敗した情報を提供しません。攻撃者は、すべての組み合わせですべてのNexthopラベルをブルートフォースする必要がある場合があります。ただし、ホップ数を不明瞭にすることにより、いくつかの有用な診断機能が失われます。たとえば、ルーティングチャーンの軌跡は、パスステアリングされたpingまたはトレーサーアウトの分析を介してピン留めするのが困難です。上記のように、Nexthopラベルを定期的に変更することに加えて、フォワーダーはホップ数を無効にすることを選択できます。
Because ICN forwarders maintain per-face state and forwarding state for Interest messages, state inflation attacks are a general concern. The addition of path steering capabilities in Interest and Data messages does not, however, constitute a meaningful increase in susceptibility to such attacks. This is because:
ICNフォワーダーは、関心メッセージのためにフェイスごとの状態と転送状態を維持しているため、状態のインフレ攻撃は一般的な懸念事項です。ただし、関心とデータメッセージにパスステアリング機能を追加することは、そのような攻撃に対する感受性の意味のある増加を構成しません。それの訳は：
* The labels that identify each forwarding face is state O(number of faces) and constitutes a small increase to the existing state needed to represent a face.
* 各転送面を識別するラベルは状態o（顔の数）であり、顔を表すために必要な既存の状態のわずかな増加を構成します。
* Interest message data is placed in the PIT. The path steering header does, in fact, inflate the size of the Interest message and, hence, the PIT state but not by an amount that is a concern. The forwarder needs to protect against state inflation attacks on the PIT in general, and an attacker can mount one just as or more easily by issuing Interests with long names and/or by including Interest payload data.
* 関心のあるメッセージデータはピットに配置されます。パスステアリングヘッダーは、実際、関心のあるメッセージのサイズ、したがってピット状態を膨らませますが、懸念事項ではありません。フォワーダーは、一般的にピットに対する州のインフレ攻撃から保護する必要があり、攻撃者は、長い名前で利息を発行したり、利息ペイロードデータを含めることで、1つまたは簡単にマウントできます。
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 is also theoretically possible to launch a similar attack without a cooperating producer such that the caches of on-path routers become poisoned with the 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.
ICNプロトコルは、さまざまなキャッシュ中毒攻撃の影響を受けやすい場合があります。このキャッシュ中毒攻撃では、共謀する消費者と生産者が偽のコンテンツ（無効または不適切な署名を使用）を手配して、転送キャッシュを埋めます。これらは一般に、パス上の攻撃に限定されます。また、協力的な生産者なしで同様の攻撃を開始することも理論的には可能です。そのため、パスオンパスルーターのキャッシュがオフパスルーターのコンテンツで毒されるようになります（つまり、物理的な接続性ですが、特定のプレフィックスのFIBのルートはありません）。ネットワークトポロジの事前知識がなければ、このタイプの攻撃の複雑さは、2^31の利益を追加するために2^31の利益を追加する追加の負担を伴う幅広い最初の検索と深さ最初の検索アルゴリズムの球場にあると推定しています。各ホップでNexthopラベルをクラックします。Nexthopラベルの比較的短い周期的な更新と、ICNフォワーダーに_ Label scans_をフォイルするために実装されたヒューリスティックは、このタイプの攻撃をうまく緩和する可能性があります。
If the countermeasures listed above do not 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 method is viable due to the symmetry of forward and reverse paths in CCNx and NDN architectures combined with ICN path steering requiring only reads and writes of the topmost Nexthop Label (i.e., active Nexthop Label) in the path label. This way, a path-steering-capable ICN forwarder receiving a Content (Data) message encrypts the current path label with its own non-shared symmetric key prior to 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. As a result, a consumer endpoint receives a Content (Data) message with a unique path label exposing only the topmost Nexthop Label as cleartext. A path steering forwarder receiving an Interest message performs label lookup using the topmost Nexthop Label, decrypts the path label with its own non-shared symmetric key, and forwards the message upstream.
上記の対策が、悪意のある誤った関心に対する十分な保護を提供しない場合、パスラベルに適用されるホップバイホップ対称暗号化を介して、パスラベルを消費者エンドポイントに不透明にすることができます（図6）。この方法は、パスラベルの最上位Nexthopラベル（つまり、アクティブNexthopラベル）の読み取りと書き込みのみを必要とするICNパスステアリングと組み合わせたCCNXおよびNDNアーキテクチャの前方および逆パスの対称性により、実行可能です。このようにして、コンテンツ（データ）メッセージを受信するパスステアリング対応のICN転送業者は、パスラベルに新しいNexthopラベルを追加する前に、現在のパスラベルを独自の非共有対称キーで暗号化します。コンテンツ（データ）メッセージは、暗号化されていない最上部（つまり、アクティブ）Nexthopラベルとパスラベルの残りの暗号化されたコンテンツを備えた下流に転送されます。その結果、消費者のエンドポイントは、一意のパスラベルがClearTextとして最上位のNexthopラベルのみを公開するコンテンツ（データ）メッセージを受信します。興味のあるメッセージを受信するパスステアリングフォワーダーは、最上位Nexthopラベルを使用してラベルルックアップを実行し、独自の非共有対称キーでパスラベルを復号化し、メッセージを上流に転送します。
Cryptographic protection of a path label does not require any key negotiation among ICN forwarders and is no more expensive than Media Access Control Security (MACsec) or IPsec. It is also quite possible that strict hop-by-hop path label encryption is not necessary and path label encryption only on the border routers of the trusted administrative or routing domains may suffice.
パスラベルの暗号化保護は、ICNフォワーダー間の重要な交渉を必要とせず、Media Access Control Security（MACSEC）またはIPSECよりも高価ではありません。また、厳格なホップバイホップパスラベル暗号化は必要ありません。また、信頼できる管理ドメインまたはルーティングドメインの境界ルーターでのみパスラベル暗号化が十分である可能性があります。
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 Cryptography
図6：ホップバイホップ対称暗号化によるパスラベル保護
[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>.
[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>.
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.net