Internet Engineering Task Force (IETF) A. Antony
Request for Comments: 9611 secunet
Category: Standards Track T. Brunner
ISSN: 2070-1721 codelabs
S. Klassert
secunet
P. Wouters
Aiven
July 2024
In order to increase the bandwidth of IPsec traffic between peers, this document defines one Notify Message Status Types and one Notify Message Error Types payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support the negotiation of multiple Child Security Associations (SAs) with the same Traffic Selectors used on different resources, such as CPUs.
ピア間のIPSECトラフィックの帯域幅を増やすために、このドキュメントでは、1つの通知メッセージステータスタイプと、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）のメッセージエラータイプの通知エラータイプを定義して、複数の子供セキュリティ協会（SAS）の交渉をサポートします。CPUなどの異なるリソースで使用される同じトラフィックセレクターを使用します。
The SA_RESOURCE_INFO notification is used to convey information that the negotiated Child SA and subsequent new Child SAs with the same Traffic Selectors are a logical group of Child SAs where most or all of the Child SAs are bound to a specific resource, such as a specific CPU. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular negotiated Traffic Selector combination.
SA_RESOURCE_INFO通知は、交渉された子SAとその後の新しい子SASが同じトラフィックセレクターを持つ新しい子SASが、特定のCPUなどの特定のリソースにバインドされる子SASの論理的なグループであるという情報を伝えるために使用されます。。TS_MAX_QUEUE NOTIFYは、この特定の交渉されたトラフィックセレクターの組み合わせのために、より多くの子SASを作成することをピアが作成したくないことを伝えます。
Using multiple Child SAs with the same Traffic Selectors has the benefit that each resource holding the Child SA has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their cryptographic state or disable their packet replay protection.
同じトラフィックセレクターで複数の子SASを使用すると、Child SAを保持している各リソースに独自のシーケンス番号カウンターがあるという利点があり、CPUが暗号化状態を同期させたり、パケットリプレイ保護を無効にしたりする必要がないことを確認します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc9611.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9611で取得できます。
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Performance Bottlenecks
3. Negotiation of Resource-Specific Child SAs
4. Implementation Considerations
5. Payload Format
5.1. SA_RESOURCE_INFO Notify Message Status Type Payload
5.2. TS_MAX_QUEUE Notify Message Error Type Payload
6. Operational Considerations
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
Most IPsec implementations are currently limited to using one hardware queue or a single CPU resource for a Child SA. Running packet stream encryption in parallel can be done, but there is a bottleneck of different parts of the hardware locking or waiting to get their sequence number assigned for the packet being encrypted. The result is that a machine with many such resources is limited to using only one of these resources per Child SA. This severely limits the throughput that can be attained. For example, at the time of writing, an unencrypted link of 10 Gbps or more is commonly reduced to 2-5 Gbps when IPsec is used to encrypt the link using AES-GCM. By using the implementation specified in this document, aggregate throughput increased from 5Gbps using 1 CPU to 40-60 Gbps using 25-30 CPUs.
現在、ほとんどのIPSEC実装は、1つのハードウェアキューまたは子供SAに単一のCPUリソースを使用することに限定されています。パケットストリームの暗号化を並行して実行することはできますが、ハードウェアロックのさまざまな部分のボトルネックがあり、暗号化されているパケットのシーケンス番号を割り当てるのを待っています。その結果、このようなリソースの多くを備えたマシンは、子供SAごとにこれらのリソースの1つのみを使用することに限定されます。これにより、達成できるスループットが厳しく制限されます。たとえば、執筆時点では、IPSECを使用してAES-GCMを使用してリンクを暗号化する場合、10 gbps以上の暗号化されていないリンクが2〜5 Gbpsに一般的に縮小されます。このドキュメントで指定された実装を使用することにより、1 CPUを使用して25-30 CPUを使用して1 cpuを使用して5Gbpsから5Gbpsから増加しました。
While this could be (partially) mitigated by setting up multiple narrowed Child SAs (for example, using Populate From Packet (PFP) as specified in IPsec architecture [RFC4301]), this IPsec feature would cause too many Child SAs (one per network flow) or too few Child SAs (one network flow used on multiple CPUs). PFP is also not widely implemented.
これは（部分的に）複数の狭い子SASをセットアップすることで緩和できますが（たとえば、IPSECアーキテクチャ[RFC4301]、Packet（PFP）からPopulate [RFC4301]）を使用して））または小児SASが少なすぎます（複数のCPUで使用される1つのネットワークフロー）。PFPも広く実装されていません。
To make better use of multiple network queues and CPUs, it can be beneficial to negotiate and install multiple Child SAs with identical Traffic Selectors. IKEv2 [RFC7296] already allows installing multiple Child SAs with identical Traffic Selectors, but it offers no method to indicate that the additional Child SA is being requested for performance increase reasons and is restricted to some resource (queue or CPU).
複数のネットワークキューとCPUをより適切に使用するために、同一のトラフィックセレクターで複数の子SASを交渉およびインストールすることが有益です。IKEV2 [RFC7296]は、同じトラフィックセレクターを備えた複数の子SASを既にインストールすることを許可していますが、パフォーマンスの理由で追加の子SAがリクエストされ、リソース（キューまたはCPU）に制限されていることを示す方法はありません。
When an IKEv2 peer is receiving more additional Child SAs for a single set of Traffic Selectors than it is willing to create, it can return an error notify of TS_MAX_QUEUE.
IKEV2ピアが、作成するよりも単一のトラフィックセレクターセットに対してより多くの追加の子SASを受信している場合、TS_MAX_QUEUEのエラー通知を返すことができます。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the following terms defined in IKEv2 [RFC7296]: Notification Data, Traffic Selector (TS), Traffic Selector initiator (TSi), Traffic Selector responder (TSr), Child SA, Configuration Payload (CP), IKE SA, CREATE_CHILD_SA, and NO_ADDITIONAL_SAS.
このドキュメントでは、IKEV2 [RFC7296]で定義されている次の用語を使用します：通知データ、トラフィックセレクター（TS）、トラフィックセレクターイニシエーター（TSI）、トラフィックセレクターレスポンダー（TSR）、チャイルドSA、構成ペイロード（CP）、IKE SA、Create_Child_sa、およびno_additional_sas。
This document also uses the following terms defined in [RFC4301]: Security Policy Database (SPD), SA.
このドキュメントでは、[RFC4301]で定義されている次の用語も使用しています。セキュリティポリシーデータベース（SPD）、SA。
There are several pragmatic reasons why most implementations must restrict a Child Security Association (SA) to a single specific hardware resource. A primary limitation arises from the challenges associated with sharing cryptographic states, counters, and sequence numbers among multiple CPUs. When these CPUs attempt to simultaneously utilize shared states, it becomes impractical to do so without incurring a significant performance penalty. It is necessary to negotiate and establish multiple Child SAs with identical Traffic Selector initiator (TSi) and Traffic Selector responder (TSr) on a per-resource basis.
ほとんどの実装が児童セキュリティ協会（SA）を単一の特定のハードウェアリソースに制限する必要があるいくつかの実用的な理由があります。主要な制限は、複数のCPUの間で暗号化状態、カウンター、およびシーケンス番号の共有に関連する課題から生じます。これらのCPUが共有状態を同時に利用しようとすると、重要なパフォーマンスペナルティを発生させずにそうすることは非現実的になります。リソースごとに、同一のトラフィックセレクターイニシエーター（TSI）およびトラフィックセレクターレスポンダー（TSR）を使用して複数の子SASを交渉して確立する必要があります。
An initial IKEv2 exchange is used to set up an IKE SA and the initial Child SA. If multiple Child SAs with the same Traffic Selectors that are bound to a single resource are desired, the initiator will add the SA_RESOURCE_INFO notify payload to the Exchange negotiating the Child SA (e.g., IKE_AUTH or CREATE_CHILD_SA). If this initial Child SA will be tied to a specific resource, it MAY indicate this by including an identifier in the Notification Data. A responder that is willing to have multiple Child SAs for the same Traffic Selectors will respond by also adding the SA_RESOURCE_INFO notify payload in which it MAY add a non-zero Notification Data.
初期のIKEV2 Exchangeを使用して、IKE SAと初期子SAをセットアップします。単一のリソースにバインドされている同じトラフィックセレクターを持つ複数の子SASが望ましい場合、イニシエーターはSA_Resource_infoに、子SAを交渉する交換にペイロードを通知します（例：ike_authまたはcreate_child_sa）。この最初の子SAが特定のリソースに結び付けられる場合、通知データに識別子を含めることでこれを示す場合があります。同じトラフィックセレクターの複数の子SASを希望するレスポンダーは、SA_RESOURCE_INFOがゼロ以外の通知データを追加する可能性のあるペイロードを追加することで応答します。
Additional resource-specific Child SAs are negotiated as regular Child SAs using the CREATE_CHILD_SA exchange and are similarly identified by an accompanying SA_RESOURCE_INFO notification.
追加のリソース固有の子SASは、create_child_sa Exchangeを使用して通常の子SASとして交渉され、付随するsa_resource_info通知によって同様に識別されます。
Upon installation, each resource-specific Child SA is associated with an additional local selector, such as the CPU. These resource-specific Child SAs MUST be negotiated with identical Child SA properties that were negotiated for the initial Child SA. This includes cryptographic algorithms, Traffic Selectors, Mode (e.g., transport mode), compression usage, etc. However, each Child SA does have its own keying material that is individually derived according to the regular IKEv2 process. The SA_RESOURCE_INFO notify payload MAY be empty or MAY contain some identifying data. This identifying data SHOULD be a unique identifier within all the Child SAs with the same TS payloads, and the peer MUST only use it for debugging purposes.
インストールすると、各リソース固有の子SAは、CPUなどの追加のローカルセレクターに関連付けられています。これらの資源固有の子SASは、最初の子SAのために交渉された同一の子SA特性と交渉する必要があります。これには、暗号化アルゴリズム、トラフィックセレクター、モード（輸送モードなど）、圧縮使用量などが含まれます。ただし、各子供SAには、通常のIKEV2プロセスに従って個別に導出される独自のキーイング材料があります。sa_resource_infoは、ペイロードが空であるか、識別データが含まれている場合がある場合があります。この識別データは、同じTSペイロードを持つすべての子供SAS内の一意の識別子である必要があり、ピアはデバッグ目的でのみ使用する必要があります。
Additional Child SAs can be started on demand or can be started all at once. Peers may also delete specific per-resource Child SAs if they deem the associated resource to be idle.
追加の子SASは、オンデマンドで開始するか、一度に開始することができます。また、ピアは、関連するリソースがアイドル状態であると判断した場合、特定のリソースごとの子SASを削除する場合があります。
During the CREATE_CHILD_SA rekey for the Child SA, the SA_RESOURCE_INFO notification MAY be included, but regardless of whether or not it is included, the rekeyed Child SA should be bound to the same resource(s) as the Child SA that is being rekeyed.
子SAのCreate_Child_Sa Rekeyの間、SA_Resource_Info通知が含まれる場合がありますが、それが含まれているかどうかに関係なく、再キーイングされた子供SAは、再キーにされている子SAと同じリソースにバインドされるべきです。
There are various considerations that an implementation can use to determine the best procedure to install multiple Child SAs.
複数の子SASをインストールするための最良の手順を決定するために実装が使用できるさまざまな考慮事項があります。
A simple procedure could be to install one additional Child SA on each CPU. An implementation can ensure that one Child SA can be used by all CPUs, so that while negotiating a new per-CPU Child SA, which typically takes 1 RTT delay, the CPU with no CPU-specific Child SA can still encrypt its packets using the Child SA that is available for all CPUs. Alternatively, if an implementation finds it needs to encrypt a packet but the current CPU does not have the resources to encrypt this packet, it can relay that packet to a specific CPU that does have the capability to encrypt the packet, although this will come with a performance penalty.
簡単な手順は、各CPUに1つの追加の子SAを設置することです。実装では、1人の子供SAをすべてのCPUで使用できるようにすることができます。そのため、通常1 RTT遅延が必要な新しいCPU子SAと交渉中に、CPU固有の子供SAがないCPUはパケットを使用してパケットを暗号化できます。すべてのCPUで利用可能な子SA。あるいは、実装でパケットを暗号化する必要があるが、現在のCPUにはこのパケットを暗号化するリソースがない場合、パケットを暗号化する機能を持つ特定のCPUにそのパケットを中継することができますが、パフォーマンスペナルティ。
Performing per-CPU Child SA negotiations can result in both peers initiating additional Child SAs simultaneously. This is especially likely if per-CPU Child SAs are triggered by individual SADB_ACQUIRE messages [RFC2367]. Responders should install the additional Child SA on a CPU with the least amount of additional Child SAs for this TSi/TSr pair.
CPUごとの子どもSAの交渉を行うと、両方のピアが同時に追加の子SASを開始することになります。これは、個々のsadb_acquireメッセージ[RFC2367]によってCPUごとの子SASがトリガーされる場合に特にありそうです。レスポンダーは、このTSI/TSRペアの追加の子SASの量が少ないCPUに追加の子SAをインストールする必要があります。
When the number of queue or CPU resources are different between the peers, the peer with the least amount of resources may decide to not install a second outbound Child SA for the same resource, as it will never use it to send traffic. However, it must install all inbound Child SAs because it has committed to receiving traffic on these negotiated Child SAs.
キューまたはCPUリソースの数がピア間で異なる場合、リソースの量が少ないピアは、トラフィックを送信するために使用しないため、同じリソースに2番目のアウトバウンド子SAをインストールしないことを決定する場合があります。ただし、これらの交渉された子SASのトラフィックを受け取ることを約束しているため、すべてのインバウンドチャイルドSASをインストールする必要があります。
If per-CPU packet trigger (e.g., SADB_ACQUIRE) messages are implemented (see Section 6), the Traffic Selector (TSi) entry containing the information of the trigger packet should be included in the TS set similarly to regular Child SAs as specified in IKEv2 [RFC7296], Section 2.9. Based on the trigger TSi entry, an implementation can select the most optimal target CPU to install the additional Child SA on. For example, if the trigger packet was for a TCP destination to port 25 (SMTP), it might be able to install the Child SA on the CPU that is also running the mail server process. Trigger packet Traffic Selectors are documented in IKEv2 [RFC7296], Section 2.9.
CPUごとのパケットトリガー（SADB_ACQUIREなど）メッセージが実装されている場合（セクション6を参照）、トリガーパケットの情報を含むトラフィックセレクター（TSI）エントリは、IKEV2で指定された通常の子供SASと同様に設定されたTSに含まれる必要があります。[RFC7296]、セクション2.9。トリガーTSIエントリに基づいて、実装は、追加の子SAをインストールする最も最適なターゲットCPUを選択できます。たとえば、トリガーパケットがTCP宛先用のポート25（SMTP）の場合、メールサーバープロセスも実行されているCPUにチャイルドSAをインストールできる場合があります。トリガーパケットトラフィックセレクターは、IKEV2 [RFC7296]、セクション2.9で文書化されています。
As per IKEv2, rekeying a Child SA SHOULD use the same (or wider) Traffic Selectors to ensure that the new Child SA covers everything that the rekeyed Child SA covers. This includes Traffic Selectors negotiated via Configuration Payloads such as INTERNAL_IP4_ADDRESS, which may use the original wide TS set or use the narrowed TS set.
IKEV2によると、子SAの再キーイングは、同じ（またはより広い）トラフィックセレクターを使用して、新しい子供SAが再キーリングされた子供SAがカバーするすべてを覆うことを確認する必要があります。これには、元のワイドTSセットを使用するか、狭められたTSセットを使用する場合があるInternal_IP4_Addressなどの構成ペイロードを介して交渉されたトラフィックセレクターが含まれます。
The Notify Payload format is defined in IKEv2 [RFC7296], Section 3.10, and is copied here for convenience.
Notifyペイロード形式は、IKEV2 [RFC7296]のセクション3.10で定義されており、便利なためにここにコピーされています。
All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first", or "network byte order").
整数を表すすべてのマルチオクテットフィールドは、エンド順にレイアウトされています（「最も重要なバイト」または「ネットワークバイト順」とも呼ばれます）。
1 2 3
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
+-------------------------------+-------------------------------+
| Next Payload |C| RESERVED | Payload Length |
+---------------+---------------+-------------------------------+
| Protocol ID | SPI Size | Notify Message Type |
+---------------+---------------+-------------------------------+
| |
~ Resource Identifier (optional) ~
| |
+-------------------------------+-------------------------------+
(C)ritical flag -
（クリティカルフラグ -
MUST be 0.
0でなければなりません。
Protocol ID (1 octet) -
プロトコルID（1オクテット） -
MUST be 0. MUST be ignored if not 0.
0ではない場合は無視する必要があります。
SPI Size (1 octet) -
SPIサイズ（1オクテット） -
MUST be 0. MUST be ignored if not 0.
0ではない場合は無視する必要があります。
Notify Status Message Type value (2 octets) -
ステータスメッセージタイプ値（2オクテット）に通知 -
set to 16444.
16444に設定。
Resource Identifier (optional) -
リソース識別子（オプション） -
This opaque data may be set to convey the local identity of the resource.
この不透明なデータは、リソースのローカルアイデンティティを伝えるように設定される場合があります。
1 2 3
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
+---------------+---------------+-------------------------------+
| Next Payload |C| RESERVED | Payload Length |
+---------------+---------------+-------------------------------+
| Protocol ID | SPI Size | Notify Message Type |
+---------------+---------------+-------------------------------+
(C)ritical flag -
（クリティカルフラグ -
MUST be 0.
0でなければなりません。
Protocol ID (1 octet) -
プロトコルID（1オクテット） -
MUST be 0. MUST be ignored if not 0.
0ではない場合は無視する必要があります。
SPI Size (1 octet) -
SPIサイズ（1オクテット） -
MUST be 0. MUST be ignored if not 0.
0ではない場合は無視する必要があります。
Notify Message Error Type (2 octets) -
メッセージエラータイプ（2オクテット）に通知 -
set to 48.
48に設定します。
There is no data associated with this Notify type.
このNotifyタイプに関連付けられたデータはありません。
Implementations supporting per-CPU SAs SHOULD extend their local SPD selector, and the mechanism of on-demand negotiation that is triggered by traffic to include a CPU (or queue) identifier in their packet trigger (e.g., SADB_ACQUIRE) message from the SPD to the IKE daemon. An implementation that does not support receiving per-CPU packet trigger messages MAY initiate all its Child SAs immediately upon receiving the (only) packet trigger message it will receive from the IPsec stack. Such an implementation also needs to be careful when receiving a Delete Notify request for a per-CPU Child SA, as it has no method to detect when it should bring up such a per-CPU Child SA again later. Also, bringing the deleted per-CPU Child SA up again immediately after receiving the Delete Notify might cause an infinite loop between the peers. Another issue with not bringing up all its per-CPU Child SAs is that if the peer acts similarly, the two peers might end up with only the first Child SA without ever activating any per-CPU Child SAs. It is therefore RECOMMENDED to implement per-CPU packet trigger messages.
CPUごとのSASをサポートする実装は、ローカルSPDセレクターを拡張する必要があります。また、トラフィックによってトリガーされるオンデマンド交渉のメカニズムは、SPDからPacketトリガー（例：SADB_ACQUIRE）にCPU（またはキュー）識別子を含めるようにトリガーします。Ike Daemon。CPUごとのパケットトリガーメッセージの受信をサポートしていない実装は、IPSECスタックから受信する（のみ）パケットトリガーメッセージを受信するとすぐにすべての子供SASを開始する場合があります。このような実装は、CPUごとの子SAの削除通知リクエストを受信するときにも注意する必要があります。これは、後でこのようなCPUの子SAを再び育てるのかを検出する方法がないためです。また、削除された通知を削除するとすぐに削除された一人当たりの子SAを再度上にすると、ピア間に無限のループが生じる可能性があります。CPUごとの子どものSASをすべて育てないことのもう1つの問題は、ピアが同様に行動する場合、2人のピアがCPUごとの子SASをアクティブにすることなく、最初の子供SAのみに終わる可能性があることです。したがって、CPUごとのパケットトリガーメッセージを実装することをお勧めします。
Peers SHOULD be flexible with the maximum number of Child SAs they allow for a given TSi/TSr combination in order to account for corner cases. For example, during Child SA rekeying, there might be a large number of additional Child SAs created before the old Child SAs are torn down. Similarly, when using on-demand Child SAs, both ends could trigger multiple Child SA requests as the initial packet causing the Child SA negotiation might have been transported to the peer via the first Child SA, where its reply packet might also trigger an on-demand Child SA negotiation to start. As additional Child SAs consume little additional resources, allowing at the very least double the number of available CPUs is RECOMMENDED. An implementation MAY allow unlimited additional Child SAs and only limit this number based on its generic resource protection strategies that are used to require COOKIES or refuse new IKE or Child SA negotiations. Although having a very large number (e.g., hundreds or thousands) of SAs may slow down per-packet SAD lookup.
ピアは、コーナーケースを説明するために、特定のTSI/TSRの組み合わせに可能な子供SAの最大数で柔軟に対応する必要があります。たとえば、子どもが再キーリングしている間、老児のSAが取り壊される前に作成された多くの追加の子供のSAがあるかもしれません。同様に、オンデマンドの子供SASを使用する場合、両端は、子SAの交渉を引き起こす最初のパケットが最初の子SAを介してピアに運ばれたため、複数の子SA要求をトリガーする可能性があります。子SAの交渉を開始するように要求します。追加の子SASは追加のリソースをほとんど消費しないため、利用可能なCPUの数を少なくとも2倍にすることをお勧めします。実装により、無制限の追加の子SASが許可され、Cookieを必要とするか、新しいIKEまたはChild SAの交渉を拒否するために使用される一般的なリソース保護戦略に基づいて、この数値のみを制限する場合があります。非常に多くの（たとえば、数百または数千）のSASを持つことは、パケットあたりのSADルックアップが遅くなる可能性があります。
Implementations might support dynamically moving a per-CPU Child SA from one CPU to another CPU. If this method is supported, implementations must be careful to move both the inbound and outbound SAs. If the IPsec endpoint is a gateway, it can move the inbound SA and outbound SA independently of each other. It is likely that for a gateway, IPsec traffic would be asymmetric. If the IPsec endpoint is the same host responsible for generating the traffic, the inbound and outbound SAs SHOULD remain as a pair on the same CPU. If a host previously skipped installing an outbound SA because it would be an unused duplicate outbound SA, it will have to create and add the previously skipped outbound SA to the SAD with the new CPU ID. The inbound SA may not have a CPU ID in the SAD. Adding the outbound SA to the SAD requires access to the key material, whereas updating the CPU selector on an existing outbound SAs might not require access to key material. To support this, the IKE software might have to hold on to the key material longer than it normally would, as it might actively attempt to destroy key material from memory that the IKE daemon no longer needs access to.
実装は、CPUごとの子SAをあるCPUから別のCPUに動的に移動することをサポートする場合があります。この方法がサポートされている場合、実装は、インバウンドSAとアウトバウンドSAの両方を移動するように注意する必要があります。IPSECエンドポイントがゲートウェイである場合、インバウンドSAとアウトバウンドSAを互いに独立して移動できます。ゲートウェイの場合、IPSECトラフィックは非対称になる可能性があります。IPSECエンドポイントがトラフィックを生成する責任者と同じホストである場合、インバウンドおよびアウトバウンドSASは同じCPUのペアとして残る必要があります。以前にアウトバウンドSAのインストールをスキップした場合、使用されていない重複したアウトバウンドSAになるため、新しいCPU IDを使用して、以前にスキップしたアウトバウンドSAをSADに作成して追加する必要があります。インバウンドSAは、悲しいことにCPU IDを持っていない場合があります。Autbound SAをSADに追加するには、キーマテリアルにアクセスする必要がありますが、既存のアウトバウンドSAでCPUセレクターを更新すると、キーマテリアルへのアクセスが必要ない場合があります。これをサポートするために、IKEソフトウェアは、IKEデーモンがもはやアクセスを必要としないメモリから重要な素材を積極的に破壊しようとする可能性があるため、通常よりも長く重要な素材を保持する必要があるかもしれません。
An implementation that does not accept any further resource-specific Child SAs MUST NOT return the NO_ADDITIONAL_SAS error because it could be misinterpreted by the peer to mean that no other Child SA with a different TSi and/or TSr is allowed either. Instead, it MUST return TS_MAX_QUEUE.
さらなるリソース固有の子SASを受け入れない実装は、NO_ADDITIONAL_SASエラーを返してはなりません。これは、ピアによって誤って解釈される可能性があるため、別のTSIおよび/またはTSRを持つ他の子供SAが許可されていないことを意味するためです。代わりに、ts_max_queueを返す必要があります。
Similar to how an implementation should limit the number of half-open SAs to limit the impact of a denial-of-service attack, it is RECOMMENDED that an implementation limits the maximum number of additional Child SAs allowed per unique TSi/TSr.
実装が半分のオープンSASの数を制限してサービス拒否攻撃の影響を制限する方法と同様に、実装により、一意のTSI/TSRごとに許可される追加の子SASの最大数を制限することをお勧めします。
Using multiple resource-specific child SAs makes sense for high-volume IPsec connections on IPsec gateway machines where the administrator has a trust relationship with the peer's administrator and abuse is unlikely and easily escalated to resolve.
複数のリソース固有の子SASを使用することは、管理者がピアの管理者と信頼関係を持っているIPSECゲートウェイマシンでの大量のIPSEC接続に理にかなっており、虐待はありそうもなく、簡単にエスカレートして解決します。
This trust relationship is usually not present for the deployments of remote access VPNs, and allowing per-CPU Child SAs is NOT RECOMMENDED in these scenarios. Therefore, it is also NOT RECOMMENDED to allow per-CPU Child SAs by default.
この信頼関係は通常、リモートアクセスVPNの展開には存在せず、これらのシナリオではCPUごとの子SASを許可することは推奨されません。したがって、デフォルトでCPUごとの子供SASを許可することもお勧めしません。
The SA_RESOURCE_INFO notify contains an optional data payload that can be used by the peer to identify the Child SA belonging to a specific resource. Notification data SHOULD NOT be an identifier that can be used to gain information about the hardware. For example, using the CPU number itself as the identifier might give an attacker knowledge of which packets are handled by which CPU ID, and it might optimize a brute-force attack against the system.
SA_RESOURCE_INFO NOTIFYには、特定のリソースに属する子SAを特定するためにピアが使用できるオプションのデータペイロードが含まれています。通知データは、ハードウェアに関する情報を取得するために使用できる識別子であってはなりません。たとえば、識別子としてCPU番号自体を使用すると、どのパケットがどのCPU IDによって処理されるかについての攻撃者の知識が得られ、システムに対するブルートフォース攻撃を最適化する可能性があります。
IANA has registered one new value in the "IKEv2 Notify Message Status Types" registry.
IANAは、「IKEV2通知メッセージステータスタイプ」レジストリに1つの新しい値を登録しています。
+=======+============================+===========+
| Value | Notify Message Status Type | Reference |
+=======+============================+===========+
| 16444 | SA_RESOURCE_INFO | RFC 9611 |
+-------+----------------------------+-----------+
Table 1
IANA has registered one new value in the "IKEv2 Notify Message Error Types" registry.
IANAは、「IKEV2通知メッセージエラータイプ」レジストリに1つの新しい値を登録しています。
+=======+===========================+===========+
| Value | Notify Message Error Type | Reference |
+=======+===========================+===========+
| 48 | TS_MAX_QUEUE | RFC 9611 |
+-------+---------------------------+-----------+
Table 2
[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>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[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>.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367,
DOI 10.17487/RFC2367, July 1998,
<https://www.rfc-editor.org/info/rfc2367>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
The following people provided reviews and valuable feedback: Roman Danyliw, Warren Kumari, Tero Kivinen, Murray Kucherawy, John Scudder, Valery Smyslov, Gunter van de Velde, and Éric Vyncke.
次の人々は、Roman Danyliw、Warren Kumari、Tero Kivinen、Murray Kucherawy、John Scudder、Valery Smyslov、Gunter Van de Velde、およびEric Vynckeのレビューと貴重なフィードバックを提供しました。
Antony Antony
secunet Security Networks AG
Email: antony.antony@secunet.com
Tobias Brunner
codelabs GmbH
Email: tobias@codelabs.ch
Steffen Klassert
secunet Security Networks AG
Email: steffen.klassert@secunet.com
Paul Wouters
Aiven
Email: paul.wouters@aiven.io