[要約] DTLS 1.2および1.3において、接続ID（CID）使用時にピアのアドレス変更を検証するためのリターンルータビリティチェック（RRC）サブプロトコルを規定しています。攻撃者による増幅攻撃やオフパス攻撃を防ぐため、path_challengeやpath_responseメッセージを用いた経路検証手順を定義し、TLS拡張を介してネゴシエーションを行います。以前のRFC 9146およびRFC 9147を更新し、ピアの到達可能性を動的に確認することで、データグラム通信におけるセキュリティと信頼性を向上させています。
Internet Engineering Task Force (IETF) H. Tschofenig, Ed.
Request for Comments: 9853 UniBw M.
Updates: 9146, 9147 A. Kraus
Category: Standards Track
ISSN: 2070-1721 T. Fossati
Linaro
March 2026
This document specifies a Return Routability Check (RRC) subprotocol for use in the context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3.
この文書では、データグラム トランスポート層セキュリティ (DTLS) プロトコル バージョン 1.2 および 1.3 の接続 ID (CID) 構造のコンテキストで使用するリターン ルータビリティ チェック (RRC) サブプロトコルを指定します。
Implementations offering the CID functionality described in RFCs 9146 and 9147 are encouraged to also provide the RRC functionality described in this document. For this reason, this document updates RFCs 9146 and 9147.
RFC 9146 および 9147 で説明されている CID 機能を提供する実装では、この文書で説明されている RRC 機能も提供することが推奨されます。このため、この文書では RFC 9146 および 9147 を更新します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9853.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9853 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions and Terminology
3. RRC Extension
3.1. RRC and CID Interplay
4. Return Routability Check Message Types
5. Path Validation Procedure
5.1. Basic
5.2. Enhanced
5.3. Path Challenge Requirements
5.4. Path Response/Drop Requirements
5.5. Timer Choice
6. Example
7. Operational Considerations
7.1. Logging Anomalous Events
7.2. Middlebox Interference
8. Security Considerations
8.1. Attacker Model
8.1.1. Amplification
8.1.2. Off-Path Packet Forwarding
9. Privacy Considerations
10. IANA Considerations
10.1. New TLS ContentType
10.2. New TLS ExtensionType
10.3. New "TLS RRC Message Type" Registry
10.3.1. Designated Expert Instructions
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Authors' Addresses
A Connection ID (CID) is an identifier carried in the record layer header of a DTLS datagram that gives the receiver additional information for selecting the appropriate security context. The CID mechanism has been specified in [RFC9146] for DTLS 1.2 and in [RFC9147] for DTLS 1.3.
接続 ID (CID) は、DTLS データグラムのレコード層ヘッダーで伝送される識別子で、適切なセキュリティ コンテキストを選択するための追加情報を受信者に提供します。CID メカニズムは、DTLS 1.2 については [RFC9146] で、DTLS 1.3 については [RFC9147] で規定されています。
Section 6 of [RFC9146] describes how the use of CID increases the attack surface of DTLS 1.2 and 1.3 by providing both on-path and off-path attackers an opportunity for DoS or DDoS. It also describes the steps a DTLS principal must take when a record with a CID is received that has a source address different from the one currently associated with the DTLS connection. However, the actual mechanism for ensuring that the new peer address is willing to receive and process DTLS records is left open. To address the gap, this document defines a Return Routability Check (RRC) subprotocol for DTLS 1.2 and 1.3, inspired by the path validation procedure defined in Section 8.2 of [RFC9000]. As such, this document updates [RFC9146] and [RFC9147].
[RFC9146] のセクション 6 では、CID の使用により、パス上とパス外の両方の攻撃者に DoS または DDoS の機会が与えられ、DTLS 1.2 および 1.3 の攻撃対象領域がどのように増加するかが説明されています。また、DTLS 接続に現在関連付けられている送信元アドレスとは異なる送信元アドレスを持つ CID を持つレコードを受信したときに、DTLS プリンシパルが実行する必要がある手順についても説明します。ただし、新しいピア アドレスが DTLS レコードを受信して処理できることを確認するための実際のメカニズムはオープンのままです。このギャップに対処するために、この文書は、[RFC9000] のセクション 8.2 で定義されたパス検証手順に触発された、DTLS 1.2 および 1.3 のリターン ルータビリティ チェック (RRC) サブプロトコルを定義します。そのため、この文書は [RFC9146] および [RFC9147] を更新します。
The return routability check is performed by the receiving endpoint before the CID-address binding is updated in that endpoint's session state. This is done in order to give the receiving endpoint confidence that the sending peer is in fact reachable at the source address indicated in the received datagram. For an illustration of the handshake and address validation phases, see Section 6.
リターン ルーティング可能性チェックは、CID アドレス バインディングがエンドポイントのセッション状態で更新される前に、受信エンドポイントによって実行されます。これは、受信したデータグラムに示されている送信元アドレスに送信ピアが実際に到達可能であるという確信を受信エンドポイントに与えるために行われます。ハンドシェイクおよびアドレス検証フェーズの図については、セクション 6 を参照してください。
Section 5.1 of this document explains the fundamental mechanism that aims to reduce the DDoS attack surface. Additionally, Section 5.2 discusses a more advanced address validation mechanism. This mechanism is designed to counteract off-path attackers trying to place themselves on-path by racing packets that trigger address rebinding at the receiver. To gain a detailed understanding of the attacker model, please refer to Section 8.1.
このドキュメントのセクション 5.1 では、DDoS 攻撃対象領域を削減することを目的とした基本的なメカニズムについて説明します。さらに、セクション 5.2 では、より高度なアドレス検証メカニズムについて説明します。このメカニズムは、受信側でアドレスの再バインドをトリガーするパケットを競合させることで、パス上に自分自身を置こうとするオフパス攻撃者に対抗するように設計されています。攻撃者モデルを詳しく理解するには、セクション 8.1 を参照してください。
Apart from of its use in the context of CID-address binding updates, the path validation capability offered by RRC can be used at any time by either endpoint. For instance, an endpoint might use RRC to check that a peer is still reachable at its last known address after a period of quiescence.
CID アドレス バインディング更新のコンテキストでの使用とは別に、RRC によって提供されるパス検証機能は、どちらのエンドポイントでもいつでも使用できます。たとえば、エンドポイントは RRC を使用して、静止期間の後もピアが最後の既知のアドレスにまだ到達可能であることを確認する場合があります。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document assumes familiarity with the CID format and protocol defined for DTLS 1.2 [RFC9146] and for DTLS 1.3 [RFC9147]. The presentation language used in this document is described in Section 4 of [RFC8446].
この文書は、DTLS 1.2 [RFC9146] および DTLS 1.3 [RFC9147] 用に定義された CID 形式とプロトコルに精通していることを前提としています。この文書で使用されるプレゼンテーション言語は、[RFC8446] のセクション 4 で説明されています。
In this document, the term "anti-amplification limit" means three times the amount of data received from an unvalidated address. This includes all DTLS records originating from that source address, excluding those that have been discarded. This follows the pattern of [RFC9000], applying a similar concept to DTLS.
この文書では、「増幅防止制限」という用語は、未検証のアドレスから受信するデータ量の 3 倍を意味します。これには、破棄されたものを除く、その送信元アドレスから発信されるすべての DTLS レコードが含まれます。これは [RFC9000] のパターンに従い、同様の概念を DTLS に適用します。
The term "address" is defined in Section 1.2 of [RFC9000].
「アドレス」という用語は、[RFC9000] のセクション 1.2 で定義されています。
The terms "client", "server", "peer", and "endpoint" are defined in Section 1.1 of [RFC8446].
「クライアント」、「サーバー」、「ピア」、および「エンドポイント」という用語は、[RFC8446] のセクション 1.1 で定義されています。
The use of RRC is negotiated via the rrc extension. The rrc extension is only defined for DTLS 1.2 and 1.3. On connecting, a client wishing to use RRC includes the rrc extension in its ClientHello. If the server is capable of meeting this requirement, it responds with an rrc extension in its ServerHello. The extension_type value for this extension is 61, and the extension_data field of this extension is empty. A client offering the rrc extension MUST also offer the connection_id extension [RFC9146]. If the client includes the rrc extension in its ClientHello but omits the connection_id extension, the server MUST NOT include the rrc extension in its ServerHello. A client offering the connection_id extension SHOULD also offer the rrc extension, unless the application using DTLS has its own address validation mechanism. The client and server MUST NOT use RRC unless both sides have successfully exchanged rrc extensions.
RRC の使用は、rrc 拡張機能を介してネゴシエートされます。rrc 拡張子は、DTLS 1.2 および 1.3 に対してのみ定義されています。接続時に、RRC を使用したいクライアントは、ClientHello に rrc 拡張子を含めます。サーバーがこの要件を満たすことができる場合、ServerHello の rrc 拡張子で応答します。この拡張機能の extension_type 値は 61 で、この拡張機能の extension_data フィールドは空です。rrc 拡張を提供するクライアントは、connection_id 拡張も提供しなければなりません (MUST) [RFC9146]。クライアントが ClientHello に rrc 拡張子を含めるが connection_id 拡張子を省略する場合、サーバーは ServerHello に rrc 拡張子を含めてはなりません (MUST NOT)。DTLS を使用するアプリケーションが独自のアドレス検証メカニズムを備えていない限り、connection_id 拡張機能を提供するクライアントは、rrc 拡張機能も提供すべきです (SHOULD)。クライアントとサーバーは、双方が rrc 拡張子の交換に成功しない限り、RRC を使用してはなりません (MUST NOT)。
RRC offers an in-protocol mechanism to perform peer address validation that complements the "peer address update" procedure described in Section 6 of [RFC9146]. Specifically, when both CID [RFC9146] and RRC have been successfully negotiated for the session, if a record with CID is received that has the source address of the enclosing UDP datagram different from what is currently associated with that CID value, the receiver SHOULD perform a return routability check as described in Section 5, unless an application-specific address validation mechanism can be triggered instead (e.g., Constrained Application Protocol (CoAP) Echo [RFC9175]).
RRC は、[RFC9146] のセクション 6 で説明されている「ピア アドレス更新」手順を補完するピア アドレス検証を実行するためのプロトコル内メカニズムを提供します。具体的には、CID [RFC9146] と RRC の両方がセッションに対して正常にネゴシエートされたとき、その CID 値に現在関連付けられているものとは異なる、囲んでいる UDP データグラムの送信元アドレスを持つ CID を持つレコードを受信した場合、受信者は、代わりにアプリケーション固有のアドレス検証メカニズム (例: Constrained Application Protocol (CoAP) Echo) がトリガーされない限り、セクション 5 で説明されているリターン ルータビリティ チェックを実行する必要があります (SHOULD)。[RFC9175])。
This document defines the return_routability_check content type (Figure 1) to carry Return Routability Check messages.
このドキュメントでは、リターン ルータビリティ チェック メッセージを伝送する return_routability_check コンテンツ タイプ (図 1) を定義します。
The RRC subprotocol consists of three message types: path_challenge, path_response, and path_drop. These message types are used for path validation and selection as described in Section 5.
RRC サブプロトコルは、path_challenge、path_response、および path_drop の 3 つのメッセージ タイプで構成されます。これらのメッセージ タイプは、セクション 5 で説明されているように、パスの検証と選択に使用されます。
Each message carries a Cookie, an 8-byte field containing 64 bits of entropy (e.g., obtained from the cryptographically secure pseudorandom number generator (CSPRNG) used by the TLS implementation; see Appendix C.1 of [RFC8446]).
各メッセージは、64 ビットのエントロピーを含む 8 バイトのフィールドである Cookie を運びます (たとえば、TLS 実装で使用される暗号的に安全な擬似乱数生成器 (CSPRNG) から取得されます。[RFC8446] の付録 C.1 を参照)。
The return_routability_check message MUST be authenticated and encrypted using the currently active security context.
return_routability_check メッセージは、現在アクティブなセキュリティ コンテキストを使用して認証および暗号化されなければなりません (MUST)。
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
heartbeat(24), /* RFC 6520 */
tls12_cid(25), /* RFC 9146, DTLS 1.2 only */
return_routability_check(27), /* NEW */
(255)
} ContentType;
uint64 Cookie;
enum {
path_challenge(0),
path_response(1),
path_drop(2),
(255)
} rrc_msg_type;
struct {
rrc_msg_type msg_type;
select (return_routability_check.msg_type) {
case path_challenge: Cookie;
case path_response: Cookie;
case path_drop: Cookie;
};
} return_routability_check;
Figure 1: Return Routability Check Message and Content Type
図 1: リターン ルータビリティ チェック メッセージとコンテンツ タイプ
Future extensions to the RRC subprotocol may define new message types. Implementations MUST be able to parse and understand the three RRC message types defined in this document. In addition, implementations MUST be able to parse and gracefully ignore messages with an unknown msg_type.
RRC サブプロトコルの将来の拡張では、新しいメッセージ タイプが定義される可能性があります。実装は、この文書で定義されている 3 つの RRC メッセージ タイプを解析して理解できなければなりません。さらに、実装は、不明な msg_type を持つメッセージを解析し、正常に無視できなければなりません (MUST)。
A receiver that observes the peer's address change MUST stop sending any buffered application data or limit the data sent to the unvalidated address to the anti-amplification limit. It then initiates the return routability check.
ピアのアドレス変更を監視した受信者は、バッファリングされたアプリケーション データの送信を停止するか、未検証のアドレスに送信されるデータを増幅防止制限に制限しなければなりません (MUST)。次に、リターンのルーティング可能性チェックを開始します。
This document describes two kinds of checks: basic (Section 5.1) and enhanced (Section 5.2). The choice of one or the other depends on whether the off-path attacker scenario described in Section 8.1.2 is to be considered. (The decision on what strategy to choose depends mainly on the threat model but may also be influenced by other considerations. Examples of impacting factors include the need to minimise implementation complexity, privacy concerns, and the need to reduce the time it takes to switch path. The choice may be offered as a configuration option to the user of the TLS implementation.)
この文書では、基本チェック (セクション 5.1) と拡張チェック (セクション 5.2) の 2 種類のチェックについて説明します。どちらを選択するかは、セクション 8.1.2 で説明されているオフパス攻撃者のシナリオを考慮するかどうかによって異なります。(どの戦略を選択するかの決定は、主に脅威モデルに依存しますが、他の考慮事項によって影響を受ける場合もあります。影響要因の例としては、実装の複雑さを最小限に抑える必要性、プライバシーの問題、パスの切り替えにかかる時間を短縮する必要性などが挙げられます。この選択は、TLS 実装のユーザーに構成オプションとして提供される場合があります。)
After the path validation procedure is complete, any pending send operation is resumed to the bound peer address.
パス検証手順が完了すると、保留中の送信操作がバインドされたピア アドレスに対して再開されます。
Sections 5.3 and 5.4 list the requirements for the initiator and responder roles, broken down per protocol phase.
セクション 5.3 と 5.4 では、イニシエーターとレスポンダーの役割の要件をプロトコル フェーズごとに分類してリストします。
Please note that the presented algorithms are not designed to handle nested rebindings, i.e. rebindings that may occur while a path is being validated following a previous rebinding. This should rarely occur, but if it happens, the path_response message is dropped, the address validation times out, and the address will not be updated. A new path validation will start when new data is received.
提示されたアルゴリズムは、ネストされた再バインド、つまり、以前の再バインドに続いてパスが検証されている間に発生する可能性のある再バインドを処理するように設計されていないことに注意してください。これが発生することはほとんどありませんが、発生した場合は、path_response メッセージがドロップされ、アドレス検証がタイムアウトになり、アドレスは更新されません。新しいデータを受信すると、新しいパスの検証が開始されます。
Also, note that in the event of a NAT rebind, the initiator and responder will have different views of the path: The initiator will see a new path, while the responder will still see the old one.
また、NAT 再バインドの場合、イニシエーターとレスポンダーはパスについて異なるビューを持つことになることに注意してください。イニシエーターには新しいパスが表示されますが、レスポンダーには古いパスが表示されたままになります。
The basic return routability check comprises the following steps:
基本的なリターン ルーティング可能性チェックは次の手順で構成されます。
1. The receiver (i.e., the initiator) creates a return_routability_check message of type path_challenge and places the unpredictable cookie into the message.
1. 受信側 (つまり、開始側) は、タイプ path_challenge の return_routability_check メッセージを作成し、予測不可能な Cookie をメッセージに配置します。
2. The message is sent to the observed new address and a timer T (see Section 5.5) is started.
2. メッセージは監視された新しいアドレスに送信され、タイマー T (セクション 5.5 を参照) が開始されます。
3. The peer (i.e., the responder) cryptographically verifies the received return_routability_check message of type path_challenge and responds by echoing the cookie value in a return_routability_check message of type path_response.
3. ピア (つまり、レスポンダ) は、受信した path_challenge タイプの return_routability_check メッセージを暗号的に検証し、path_response タイプの return_routability_check メッセージ内の cookie 値をエコーすることで応答します。
4. When the initiator receives the return_routability_check message of type path_response and verifies that it contains the sent cookie, it updates the peer address binding.
4. イニシエータは、path_response タイプの return_routability_check メッセージを受信し、送信された Cookie が含まれていることを確認すると、ピア アドレス バインディングを更新します。
5. If T expires, the peer address binding is not updated.
5. T の有効期限が切れると、ピア アドレス バインディングは更新されません。
The enhanced return routability check comprises the following steps:
強化されたリターン ルーティング可能性チェックは次の手順で構成されます。
1. The receiver (i.e., the initiator) creates a return_routability_check message of type path_challenge and places the unpredictable cookie into the message.
1. 受信側 (つまり、開始側) は、タイプ path_challenge の return_routability_check メッセージを作成し、予測不可能な Cookie をメッセージに配置します。
2. The message is sent to the previously valid address, which corresponds to the old path. Additionally, a timer T is started (see Section 5.5).
2. メッセージは、古いパスに対応する、以前に有効だったアドレスに送信されます。さらに、タイマー T が開始されます (セクション 5.5 を参照)。
3. If the path is still functional, the peer (i.e., the responder) cryptographically verifies the received return_routability_check message of type path_challenge. The action to be taken depends on whether the path through which the message was received remains the preferred one.
3. パスがまだ機能している場合、ピア (つまり、レスポンダー) は、受信した path_challenge タイプの return_routability_check メッセージを暗号的に検証します。実行されるアクションは、メッセージを受信したパスが優先パスのままであるかどうかによって異なります。
* If the path through which the message was received is preferred, a return_routability_check message of type path_response MUST be returned. (Note that, from the responder's perspective, the preferred path and the old path coincide in the event of a NAT rebind.)
* メッセージが受信されたパスが優先される場合、path_response タイプの return_routability_check メッセージを返さなければなりません (MUST)。(レスポンダの観点から見ると、NAT 再バインドが発生した場合、優先パスと古いパスが一致することに注意してください。)
* If the path through which the message was received is no longer preferred, a return_routability_check message of type path_drop MUST be returned. (Note that the responder must have initiated a voluntary path migration in order to know that this path is no longer the preferred one.)
* メッセージを受信したパスが優先されなくなった場合、path_drop タイプの return_routability_check メッセージを返さなければなりません (MUST)。(このパスが優先パスではなくなったことを知るために、レスポンダは自発的なパス移行を開始する必要があることに注意してください。)
In either case, the peer echoes the cookie value in the response.
どちらの場合も、ピアは応答内の Cookie 値をエコーします。
4. The initiator receives and verifies that the return_routability_check message contains the previously sent cookie. The actions taken by the initiator differ based on the received message:
4. イニシエーターは受信し、return_routability_check メッセージに以前に送信された Cookie が含まれていることを確認します。イニシエーターが実行するアクションは、受信したメッセージに基づいて異なります。
* When a return_routability_check message of type path_response is received, the initiator MUST continue using the previously valid address, i.e., no switch to the new path takes place and the peer address binding is not updated.
* path_response タイプの return_routability_check メッセージを受信した場合、イニシエータは以前に有効だったアドレスを使用し続けなければなりません (MUST)。つまり、新しいパスへの切り替えは行われず、ピア アドレス バインディングは更新されません。
* When a return_routability_check message of type path_drop is received, the initiator MUST perform a basic return routability check on the observed new address, as described in Section 5.1.
* path_drop タイプの return_routability_check メッセージを受信した場合、イニシエータはセクション 5.1 で説明されているように、観測された新しいアドレスに対して基本的なリターン ルータビリティ チェックを実行しなければなりません (MUST)。
5. If T expires, the peer address binding is not updated. In this case, the initiator MUST perform a basic return routability check on the observed new address, as described in Section 5.1.
5. T の有効期限が切れると、ピア アドレス バインディングは更新されません。この場合、イニシエータはセクション5.1で説明されているように、観察された新しいアドレスに対して基本的なリターンルータビリティチェックを実行しなければなりません(MUST)。
* The initiator MAY send multiple return_routability_check messages of type path_challenge to account for packet loss on the probed path.
* イニシエータは、プローブされたパスでのパケット損失を考慮して、タイプ path_challenge の return_routability_check メッセージを複数送信してもよい(MAY)。
- Each path_challenge SHOULD go into different transport packets. (Note that the DTLS implementation may not have control over the packetization done by the transport layer.)
- 各 path_challenge は異なるトランスポート パケットに入る必要があります (SHOULD)。(DTLS 実装では、トランスポート層によって行われるパケット化を制御できない場合があることに注意してください。)
- The transmission of subsequent path_challenge messages SHOULD be paced to decrease the chance of loss.
- 後続の path_challenge メッセージの送信は、損失の可能性を減らすように調整される必要があります (SHOULD)。
- Each path_challenge message MUST contain random data.
- 各 path_challenge メッセージにはランダム データが含まれなければなりません (MUST)。
- In general, the number of "backup" path_challenge messages depends on the application, since some are more sensitive than others to latency caused by changes in the path. In the absence of application-specific requirements, the initiator can send a path_challenge message once per round-trip time (RTT), up to the anti-amplification limit.
- 一般に、「バックアップ」path_challenge メッセージの数はアプリケーションによって異なります。これは、パスの変更によって生じる遅延の影響を他のメッセージよりも受けやすいためです。アプリケーション固有の要件がない場合、開始側はラウンドトリップ時間 (RTT) ごとに 1 回、増幅防止制限まで path_challenge メッセージを送信できます。
* The initiator MAY use the record padding mechanism available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the sending direction) to add padding up to the anti-amplification limit to probe if the Path MTU (PMTU) for the new path is still acceptable.
* イニシエータは、DTLS 1.3 (送信方向で CID が有効な場合は DTLS 1.2) で利用可能なレコード パディング メカニズムを使用して、新しいパスのパス MTU (PMTU) がまだ受け入れられるかどうかを調べるために、増幅防止制限までパディングを追加してもよい(MAY)。
* The responder MUST NOT delay sending an elicited path_response or path_drop messages.
* レスポンダは、引き出した path_response または path_drop メッセージの送信を遅らせてはなりません (MUST NOT)。
* The responder MUST send exactly one path_response or path_drop message for each valid path_challenge it received.
* レスポンダは、受信した有効な path_challenge ごとに、path_response または path_drop メッセージを 1 つだけ送信しなければなりません (MUST)。
* The responder MUST send the path_response or the path_drop to the address from which the corresponding path_challenge was received. This ensures that the path is functional in both directions.
* レスポンダは、対応する path_challenge を受信したアドレスに path_response または path_drop を送信しなければなりません (MUST)。これにより、パスが両方向で機能することが保証されます。
* The initiator MUST silently discard any invalid path_response or path_drop it receives.
* イニシエーターは、受信した無効な path_response または path_drop を黙って破棄しなければなりません (MUST)。
Note that RRC does not account for PMTU discovery on the reverse path. If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure.
RRC は、リバース パスでの PMTU 検出を考慮していないことに注意してください。レスポンダが RRC を使用して PMTU 検出を実行したい場合は、新しいパス検証手順を開始する必要があります。
When setting T, implementations are cautioned that the new path could have a longer RTT than the original.
T を設定する場合、実装では、新しいパスの RTT が元のパスよりも長くなる可能性があることが警告されます。
In settings where there is external information about the RTT of the active path (i.e., the old path), implementations SHOULD use T = 3xRTT.
アクティブなパス (つまり、古いパス) の RTT に関する外部情報がある設定では、実装は T = 3xRTT を使用する必要があります (SHOULD)。
If an implementation has no way to obtain information regarding the RTT of the active path, T SHOULD be set to 1 second.
実装がアクティブパスの RTT に関する情報を取得する方法がない場合、T は 1 秒に設定すべきです (SHOULD)。
Profiles for specific deployment environments -- for example, constrained networks [IOT-PROFILE] -- MAY specify a different, more suitable value for T.
特定の展開環境用のプロファイル (制約されたネットワーク [IOT-PROFILE] など) では、T に別の、より適切な値を指定してもよい(MAY)。
Figure 2 shows an example of a DTLS 1.3 handshake in which a client and a server successfully negotiate support for both the CID and RRC extensions.
図 2 は、クライアントとサーバーが CID 拡張と RRC 拡張の両方のサポートを正常にネゴシエートする DTLS 1.3 ハンドシェイクの例を示しています。
Client Server
Key ^ ClientHello
Exch | + key_share
| + signature_algorithms
| + rrc
v + connection_id=empty
-------->
ServerHello ^ Key
+ key_share | Exch
+ connection_id=100 |
+ rrc v
{EncryptedExtensions} ^ Server
{CertificateRequest} v Params
{Certificate} ^
{CertificateVerify} | Auth
<-------- {Finished} v
^ {Certificate}
Auth | {CertificateVerify}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the
previously noted message.
{} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N.
Figure 2: Message Flow for Full DTLS Handshake
図 2: 完全な DTLS ハンドシェイクのメッセージ フロー
Once a connection has been established, the client and the server exchange application payloads protected by DTLS with a unilaterally used CID. In this case, the client is requested to use CID 100 for records sent to the server.
接続が確立されると、クライアントとサーバーは、一方的に使用される CID を使用して、DTLS によって保護されたアプリケーション ペイロードを交換します。この場合、クライアントは、サーバーに送信されるレコードに CID 100 を使用するように要求されます。
At some point in the communication interaction, the address used by the client changes, and thanks to the CID usage, the security context to interpret the record is successfully located by the server. However, the server wants to test the reachability of the client at its new address.
通信対話のある時点で、クライアントによって使用されるアドレスが変更され、CID の使用のおかげで、レコードを解釈するためのセキュリティ コンテキストがサーバーによって正常に特定されます。ただし、サーバーは新しいアドレスでクライアントの到達可能性をテストしたいと考えています。
Figure 3 shows the server initiating a basic RRC exchange (see Section 5.1) that establishes reachability of the client at the new address.
図 3 は、新しいアドレスでのクライアントの到達可能性を確立する基本的な RRC 交換 (セクション 5.1 を参照) を開始するサーバーを示しています。
Client Server
------ ------
Application Data ========>
<CID=100>
Src-IP=A
Dst-IP=Z
<======== Application Data
Src-IP=Z
Dst-IP=A
<<------------->>
<< Some >>
<< Time >>
<< Later >>
<<------------->>
Application Data ========>
<CID=100>
Src-IP=B
Dst-IP=Z
<<< Unverified IP
Address B >>
<-------- Return Routability Check
path_challenge(cookie)
Src-IP=Z
Dst-IP=B
Return Routability Check -------->
path_response(cookie)
Src-IP=B
Dst-IP=Z
<<< IP Address B
Verified >>
<======== Application Data
Src-IP=Z
Dst-IP=B
Figure 3: Basic Return Routability Example
図 3: 基本的なリターン ルータビリティの例
Logging of RRC operations at both ends of the protocol can be generally useful for the users of an implementation. In particular, for Security Information and Event Management (SIEM) and troubleshooting purposes, it is strongly advised that implementations collect statistics about any unsuccessful RRC operations, as they could represent security-relevant events when they coincide with attempts by an attacker to interfere with the end-to-end path. It is also advisable to log instances where multiple responses to a single path_challenge are received, as this could suggest an off-path attack attempt.
プロトコルの両端での RRC 操作のログは、実装のユーザーにとって一般に役立ちます。特に、セキュリティ情報およびイベント管理 (SIEM) およびトラブルシューティングの目的では、失敗した RRC 操作に関する統計を実装で収集することを強くお勧めします。これは、攻撃者によるエンドツーエンド パスへの干渉の試みと同時に発生したセキュリティ関連のイベントを表す可能性があるためです。また、パス外攻撃の試みを示唆する可能性があるため、単一の path_challenge に対する複数の応答を受信したインスタンスをログに記録することをお勧めします。
In some cases, the presence of frequent path probes could indicate a problem with the stability of the path. This information can be used to identify any issues with the underlying connectivity service.
場合によっては、頻繁なパス プローブの存在は、パスの安定性に問題があることを示している可能性があります。この情報は、基盤となる接続サービスの問題を特定するために使用できます。
Since the DTLS 1.3 encrypted packet's record type is opaque to on-path observers, RRC messages are immune to middlebox interference when using DTLS 1.3. In contrast, DTLS 1.2 RRC messages that are not wrapped in the tls12_cid record (e.g., in the server-to-client direction if the server negotiated a zero-length CID) have the return_routability_check content type in plain text, making them susceptible to interference (e.g., dropping of path_challenge messages), which would hinder the RRC functionality altogether. Therefore, when RRC is used in DTLS 1.2 and middlebox interference is a concern, it is recommended to enable CID in both directions.
DTLS 1.3 暗号化パケットのレコード タイプはパス上のオブザーバーに対して不透明であるため、DTLS 1.3 を使用する場合、RRC メッセージはミドルボックス干渉の影響を受けません。対照的に、tls12_cid レコードでラップされていない DTLS 1.2 RRC メッセージ (たとえば、サーバーが長さ 0 の CID をネゴシエートした場合のサーバーからクライアント方向) は、return_routability_check コンテンツ タイプをプレーン テキストで持つため、干渉 (たとえば、path_challenge メッセージのドロップ) の影響を受けやすくなり、RRC 機能が完全に妨げられます。したがって、RRC が DTLS 1.2 で使用されており、ミドルボックス干渉が懸念される場合は、両方向で CID を有効にすることをお勧めします。
Note that the return routability checks do not protect against flooding of third parties if the attacker is on-path, as the attacker can redirect the return routability checks to the real peer (even if those datagrams are cryptographically authenticated). On-path adversaries can, in general, pose a harm to connectivity.
攻撃者がリターン ルーティング可能性チェックを実際のピアにリダイレクトできるため (データグラムが暗号的に認証されている場合でも)、攻撃者がパス上にある場合、リターン ルーティング可能性チェックは第三者のフラッディングを防ぐことはできないことに注意してください。一般に、経路上の敵対者は接続に損害を与える可能性があります。
If the RRC challenger reuses a cookie that was previously used in the same connection and does not implement anti-replay protection (see Section 4.5.1 of [RFC9147] and Section 4.1.2.6 of [RFC6347]), an attacker could replay a previously sent path_response message containing the reused cookie to mislead the challenger into switching to a path of the attacker's choosing. To prevent this, RRC cookies must be _freshly_ generated using a reliable source of entropy [RFC4086]. See Appendix C.1 of [RFC8446] for guidance.
RRC チャレンジャーが同じ接続で以前に使用された Cookie を再利用し、リプレイ防止保護を実装していない場合 ([RFC9147] のセクション 4.5.1 および [RFC6347] のセクション 4.1.2.6 を参照)、攻撃者は、再利用された Cookie を含む以前に送信された path_response メッセージをリプレイして、チャレンジャーを誤解させ、攻撃者が選択したパスに切り替える可能性があります。これを防ぐには、信頼できるエントロピー ソースを使用して RRC Cookie を_新しく_生成する必要があります [RFC4086]。ガイダンスについては、[RFC8446] の付録 C.1 を参照してください。
Two classes of attackers are considered, off-path and on-path, with increasing capabilities (see Figure 4). The following descriptions of these attackers are based on those introduced in QUIC (Section 21.1 of [RFC9000]):
オフパスとオンパスの 2 つのクラスの攻撃者が考えられ、その能力は増大しています (図 4 を参照)。これらの攻撃者に関する以下の説明は、QUIC ([RFC9000] のセクション 21.1) で紹介されたものに基づいています。
* An off-path attacker is not on the original path between the DTLS peers, but it is able to observe packets on the original path and has a faster forwarding path compared to the DTLS peers, which allows it to make copies of the observed packets, race its copies to either peer, and consistently win the race.
* オフパス攻撃者は、DTLS ピア間の元のパス上にはいませんが、元のパス上のパケットを監視でき、DTLS ピアと比較して高速な転送パスを持っているため、監視したパケットのコピーを作成し、そのコピーをどちらかのピアと競合させて、常に競争に勝つことができます。
* An on-path attacker is on the original path between the DTLS peers and is therefore capable, compared to the off-path attacker, to also drop and delay records at will.
* オンパス攻撃者は DTLS ピア間の元のパス上に存在するため、オフパス攻撃者と比較して、レコードを自由に削除したり遅延したりする可能性があります。
Note that, in general, attackers cannot craft DTLS records in a way that would successfully pass verification, due to the cryptographic protections applied by the DTLS record layer.
一般に、DTLS レコード層によって適用される暗号化保護のため、攻撃者は検証に合格する方法で DTLS レコードを作成できないことに注意してください。
.--> .------------------------------------. <--.
| | Inspect unencrypted portions | |
| +------------------------------------+ |
| | Inject | |
off-path +------------------------------------+ |
| | Reorder | |
| +------------------------------------+ |
| | Modify unauthenticated portions | on-path
'--> +------------------------------------+ |
| Delay | |
+------------------------------------+ |
| Drop | |
+------------------------------------+ |
| Manipulate the packetization layer | |
'------------------------------------' <--'
Figure 4: Attacker Capabilities
図 4: 攻撃者の能力
RRC is designed to defend against the following attacks:
RRC は、次の攻撃を防御するように設計されています。
* On-path and off-path attackers that try to create an amplification attack by spoofing the source address of the victim (Section 8.1.1).
* 被害者の送信元アドレスをスプーフィングして増幅攻撃を作成しようとするオンパスおよびオフパスの攻撃者 (セクション 8.1.1)。
* Off-path attackers that try to put themselves on-path (Section 8.1.2), provided that the enhanced path validation algorithm is used (Section 5.2).
* 強化されたパス検証アルゴリズム (セクション 5.2) が使用されている場合に、自身をパス上に置こうとするオフパス攻撃者 (セクション 8.1.2)。
Both on-path and off-path attackers can send a packet (either by modifying it on the fly or by copying, injecting, and racing it, respectively) with the source address modified to that of a victim host. If the traffic generated by the server in response is larger compared to the received packet (e.g., a CoAP server returning an MTU's worth of data from a 20-byte GET request [AMP-ATTACKS]), the attacker can use the server as a traffic amplifier toward the victim.
パス上攻撃者とパス外攻撃者はどちらも、被害ホストのソース アドレスに変更された送信元アドレスを持つパケットを (実行中に変更するか、コピー、挿入、競合することによって) 送信する可能性があります。応答としてサーバーによって生成されたトラフィックが、受信したパケットと比較して大きい場合（たとえば、CoAP サーバーが 20 バイトの GET リクエスト [AMP-ATTACKS] から MTU 相当のデータを返す場合）、攻撃者はサーバーを被害者へのトラフィック増幅器として使用する可能性があります。
When receiving a packet with a known CID that has a source address different from the one currently associated with the DTLS connection, an RRC-capable endpoint will not send a (potentially large) response but instead a small path_challenge message to the victim host. Since the host is not able to decrypt it and generate a valid path_response, the address validation fails, which in turn keeps the original address binding unaltered.
現在 DTLS 接続に関連付けられている送信元アドレスとは異なる送信元アドレスを持つ既知の CID を持つパケットを受信すると、RRC 対応エンドポイントは (潜在的に大きな) 応答を送信せず、代わりに小さな path_challenge メッセージを被害ホストに送信します。ホストはそれを復号化して有効な path_response を生成できないため、アドレス検証は失敗し、元のアドレス バインディングが変更されないままになります。
Note that in the case of an off-path attacker, the original packet still reaches the intended destination; therefore, an implementation could use a different strategy to mitigate the attack.
オフパス攻撃者の場合、元のパケットは依然として意図した宛先に到達することに注意してください。したがって、実装では攻撃を軽減するために別の戦略を使用する可能性があります。
An off-path attacker that can observe packets might forward copies of genuine packets to endpoints over a different path. If the copied packet arrives before the genuine packet, this will appear as a path change, like in a genuine NAT rebinding occurrence. Any genuine packet will be discarded as a duplicate. If the attacker is able to continue forwarding packets, it might be able to cause migration to a path via the attacker. This places the attacker on-path, giving it the ability to observe or drop all subsequent packets.
パケットを監視できるオフパス攻撃者は、本物のパケットのコピーを別のパス経由でエンドポイントに転送する可能性があります。コピーされたパケットが本物のパケットより先に到着した場合、これは、本物の NAT リバインディングが発生した場合と同様に、パスの変更として現れます。本物のパケットは複製として破棄されます。攻撃者がパケットの転送を継続できる場合、攻撃者を経由するパスへの移行を引き起こす可能性があります。これにより、攻撃者がパス上に配置され、後続のすべてのパケットを監視またはドロップできるようになります。
This style of attack relies on the attacker using a path that has the same or better characteristics (e.g., due to a more favourable service level agreements) as the direct path between endpoints. The attack is more effective if relatively few packets are sent or if packet loss coincides with the attempted attack.
このスタイルの攻撃は、攻撃者がエンドポイント間の直接パスと同じかそれ以上の特性を持つパス (たとえば、より有利なサービス レベル アグリーメントによる) を使用することに依存しています。送信されるパケットが比較的少ない場合、または攻撃の試みと同時にパケット損失が発生した場合、攻撃はより効果的です。
A data packet received on the original path that increases the maximum received packet number will cause the endpoint to move back to that path. Therefore, eliciting packets on this path increases the likelihood that the attack is unsuccessful. However, note that, unlike QUIC, DTLS has no "non-probing" packets so this would require application-specific mechanisms.
元のパスでデータ パケットを受信すると、最大受信パケット数が増加し、エンドポイントはそのパスに戻ります。したがって、このパス上でパケットを引き出すと、攻撃が失敗する可能性が高くなります。ただし、QUIC とは異なり、DTLS には「非プローブ」パケットがないため、アプリケーション固有のメカニズムが必要になることに注意してください。
Figure 5 illustrates the case where a receiver receives a packet with a new source address. In order to determine that this path change was not triggered by an off-path attacker, the receiver will send an RRC message of type path_challenge (1) on the old path.
図 5 は、受信機が新しい送信元アドレスを持つパケットを受信する場合を示しています。このパス変更がオフパス攻撃者によって引き起こされたものではないことを確認するために、受信側は古いパス上でタイプ path_challenge (1) の RRC メッセージを送信します。
new old
path .----------. path
| |
.-----+ Receiver +-----.
| | | |
| '----------' |
| 1
| |
| |
.----+------. v
/ Attacker? / |
'------+----' |
| |
| |
| |
| .----------. |
| | | |
'-----+ Sender +-----'
| |
'----------'
Figure 5: Off-Path Packet Forwarding Scenario
図 5: オフパス パケット転送のシナリオ
Three cases need to be considered:
次の 3 つのケースを考慮する必要があります。
Case 1: The old path is dead (e.g., due to a NAT rebinding), which leads to a timeout of (1).
ケース 1: 古いパスが無効になり (NAT 再バインドなどにより)、(1) のタイムアウトが発生します。
As shown in Figure 6, a path_challenge (2) needs to be sent on the new path. If the sender replies with a path_response on the new path (3), the switch to the new path is considered legitimate.
図 6 に示すように、path_challenge (2) を新しいパスに送信する必要があります。送信者が新しいパス (3) で path_response で応答した場合、新しいパスへの切り替えは正当であると見なされます。
new old
path .----------. path
.------>| +-------.
| .-----+ Receiver +...... |
| | .---+ | . |
| | | '----------' . |
path- 3 | | . 1 path-
response | | | . | challenge
| | | . |
.--|-+-|----------------------v--.
/ | | NAT X / timeout
'----|-+-|-----------------------'
| | | .
| | 2 path- .
| | | challenge .
| | | .----------. .
| | '-->| | .
| '-----+ Sender +.....'
'-------+ |
'----------'
Figure 6: Old Path Is Dead
図 6: 古いパスは死んだ
Case 2: The old path is alive but not preferred.
ケース 2: 古いパスは生きていますが、優先されません。
This case is shown in Figure 7 whereby the sender replies with a path_drop message (2) on the old path. This triggers the receiver to send a path_challenge (3) on the new path. The sender will reply with a path_response (4) on the new path, thus providing confirmation for the path migration.
このケースは図 7 に示されており、送信者は古いパス上で path_drop メッセージ (2) で応答します。これにより、受信側が新しいパス上で path_challenge (3) を送信するようになります。送信者は新しいパスに関する path_response (4) で応答し、パスの移行の確認を提供します。
new old
path .----------. path
.------>| |<------.
| .-----+ Receiver +-----. |
| | .---+ +---. | |
| | | '----------' | | |
path- 4 | | path- 1 | |
response | | | challenge | | |
| | | | | |
.---------|-+-|----. .--|-+-|-----------.
/ NAT A | | / / | | NAT B /
'-----------|---|--' '----|-+-|---------'
| | | | | |
| | 3 path- | | 2 path-
| | | challenge | | | drop
| | | .----------. | | |
| | '-->| |<--' | |
| '-----+ Sender +-----' |
'-------+ +-------'
'----------'
Figure 7: Old Path Is Not Preferred
図 7: 古いパスは優先されません
Case 3: The old path is alive and preferred.
ケース 3: 古いパスが生きており、優先されます。
This is most likely the result of an off-path attacker trying to place itself on-path. As shown in Figure 8, the receiver sends a path_challenge (1) on the old path, and the sender replies with a path_response (2) on the old path. This results in the connection not being migrated to the new path, thus thwarting the attack.
これは、パス外の攻撃者が自身をパス上に配置しようとした結果である可能性が高くなります。図 8 に示すように、受信者は古いパスで path_challenge (1) を送信し、送信者は古いパスで path_response (2) で応答します。これにより、接続は新しいパスに移行されず、攻撃が阻止されます。
new old
path .----------. path
| +-------.
.-----+ Receiver +-----. |
| | |<--. | |
| '----------' | | |
| | | 1 path-
| | | | challenge
| | | |
.---+------. .--|-+-|-----.
/ off-path / / |NAT| /
/ attacker / '----|-+-|---'
'------+---' | | |
| | | |
| path- 2 | |
| response | | |
| .----------. | | |
| | +---' | |
'-----+ Sender +-----' |
| |<------'
'----------'
Figure 8: Old Path Is Preferred
図 8: 古いパスが優先される
Note that this defense is imperfect, but this is not considered a serious problem. If the path via the attacker is reliably faster than the old path despite multiple attempts to use that old path, it is not possible to distinguish between an attack and an improvement in routing.
この防御は不完全ですが、これは重大な問題とはみなされないことに注意してください。古いパスの使用を複数回試みたにもかかわらず、攻撃者を経由するパスが古いパスよりも確実に高速である場合、攻撃とルーティングの改善を区別することはできません。
An endpoint could also use heuristics to improve detection of this style of attack. For instance, NAT rebinding is improbable if packets were recently received on the old path. Endpoints can also look for duplicated packets. Conversely, a change in CID is more likely to indicate an intentional migration rather than an attack. Note that changes in CIDs are supported in DTLS 1.3 but not in DTLS 1.2.
エンドポイントはヒューリスティックを使用して、このスタイルの攻撃の検出を向上させることもできます。たとえば、パケットが古いパスで最近受信された場合、NAT 再バインドは起こりそうにありません。エンドポイントは重複したパケットを探すこともできます。逆に、CID の変更は、攻撃ではなく意図的な移行を示す可能性が高くなります。CID の変更は DTLS 1.3 ではサポートされていますが、DTLS 1.2 ではサポートされていないことに注意してください。
When using DTLS 1.3, peers SHOULD avoid using the same CID on multiple network paths, in particular when initiating connection migration or when probing a new network path, as described in Section 5, as an adversary can otherwise correlate the communication interaction across those different paths. DTLS 1.3 provides mechanisms to ensure that a new CID can always be used. In general, an endpoint should proactively send a RequestConnectionId message to ask for new CIDs as soon as the pool of spare CIDs is depleted (or goes below a threshold). Also, in case a peer might have exhausted available CIDs, a migrating endpoint could include NewConnectionId in packets sent on the new path to make sure that the subsequent path validation can use fresh CIDs.
DTLS 1.3 を使用する場合、ピアは複数のネットワーク パスで同じ CID を使用することを避ける必要があります。特に、セクション 5 で説明されているように、接続の移行を開始するときや新しいネットワーク パスを調査するときは、敵対者がこれらの異なるパス間の通信の相互作用を相関付ける可能性があるためです。DTLS 1.3 は、新しい CID を常に使用できるようにするメカニズムを提供します。一般に、エンドポイントは、スペア CID のプールが使い果たされると (またはしきい値を下回ると)、すぐに RequestConnectionId メッセージを積極的に送信して新しい CID を要求する必要があります。また、ピアが使用可能な CID を使い果たした可能性がある場合、移行エンドポイントは、新しいパスで送信されるパケットに NewConnectionId を含めて、後続のパス検証で新しい CID を使用できるようにすることができます。
Note that DTLS 1.2 does not offer the ability to request new CIDs during the session lifetime since CIDs have the same lifespan of the connection. Therefore, deployments that use DTLS in multihoming environments SHOULD refuse to use CIDs with DTLS 1.2 and switch to DTLS 1.3 if the correlation privacy threat is a concern.
CID は接続の存続期間が同じであるため、DTLS 1.2 ではセッションの存続期間中に新しい CID を要求する機能が提供されないことに注意してください。したがって、マルチホーミング環境で DTLS を使用する展開では、相関プライバシーの脅威が懸念される場合、DTLS 1.2 での CID の使用を拒否し、DTLS 1.3 に切り替える必要があります。
IANA has allocated an entry in the "TLS ContentType" registry within the "Transport Layer Security (TLS) Parameters" registry group [IANA.tls-parameters] for the return_routability_check (27) message defined in this document. IANA set the DTLS_OK column to "Y" and added the following note to the registry:
IANA は、この文書で定義されている return_routability_check (27) メッセージ用に、「トランスポート層セキュリティ (TLS) パラメータ」レジストリ グループ [IANA.tls-parameters] 内の「TLS ContentType」レジストリにエントリを割り当てました。IANA は DTLS_OK 列を「Y」に設定し、次のメモをレジストリに追加しました。
Note: The return_routability_check content type is only applicable to DTLS 1.2 and 1.3.
注: return_routability_check コンテンツ タイプは、DTLS 1.2 および 1.3 にのみ適用されます。
IANA has allocated the extension code point (61) for rrc in the "TLS ExtensionType Values" registry as described in Table 1.
IANA は、表 1 に示すように、「TLS ExtensionType Values」レジストリ内の rrc に拡張コード ポイント (61) を割り当てました。
+=====+=========+===+===========+=============+===========+=======+
|Value|Extension|TLS| DTLS-Only | Recommended | Reference |Comment|
| |Name |1.3| | | | |
+=====+=========+===+===========+=============+===========+=======+
|61 |rrc |CH,| Y | N | RFC 9853 | |
| | |SH | | | | |
+-----+---------+---+-----------+-------------+-----------+-------+
Table 1: New Entry in the TLS ExtensionType Values Registry
表 1: TLS ExtensionType 値レジストリの新しいエントリ
IANA has created the "TLS RRC Message Types" registry within the "Transport Layer Security (TLS) Parameters" registry group [IANA.tls-parameters]. This registration procedure is "Expert Review" (Section 4.5 of [RFC8126]).
IANA は、「Transport Layer Security (TLS) Parameters」レジストリ グループ [IANA.tls-parameters] 内に「TLS RRC Message Types」レジストリを作成しました。この登録手順は「エキスパートレビュー」([RFC8126]のセクション4.5)です。
To submit registration requests, follow the procedures in Section 16 of [RFC9847].
登録リクエストを送信するには、[RFC9847] のセクション 16 の手順に従ってください。
Each entry in the registry must include the following fields:
レジストリ内の各エントリには、次のフィールドが含まれている必要があります。
Value:
値：
A (decimal) number in the range 0 to 253.
0 ～ 253 の範囲の (10 進数)。
Description:
説明：
A brief description of the RRC message.
RRC メッセージの簡単な説明。
DTLS-Only:
DTLS のみ:
Indication of whether the message only applies to DTLS. Since RRC is only available in DTLS, this column is set to "Y" for all the initial entries in this registry. Future work may define new RRC message types that also apply to TLS.
メッセージが DTLS にのみ適用されるかどうかを示します。RRC は DTLS でのみ使用できるため、このレジストリのすべての初期エントリについてこの列は「Y」に設定されます。将来の作業では、TLS にも適用される新しい RRC メッセージ タイプが定義される可能性があります。
Recommended:
推奨：
Indication of whether the message is recommended for implementations to support. The semantics for this field is defined in Section 5 of [RFC8447] and updated in Section 3 of [RFC9847].
実装がサポートするメッセージが推奨されるかどうかを示します。このフィールドのセマンティクスは [RFC8447] のセクション 5 で定義され、[RFC9847] のセクション 3 で更新されます。
Reference:
参照：
A reference to a publicly available specification for the value.
値の公開されている仕様への参照。
Comment:
コメント：
Any relevant notes or comments that relate to this entry.
このエントリに関連するメモやコメント。
Table 2 shows the initial contents of this registry:
表 2 は、このレジストリの初期内容を示しています。
+=======+================+=========+=============+=========+=======+
|Value | Description |DTLS-Only| Recommended |Reference|Comment|
+=======+================+=========+=============+=========+=======+
|0 | path_challenge |Y | Y |RFC 9853 | |
+-------+----------------+---------+-------------+---------+-------+
|1 | path_response |Y | Y |RFC 9853 | |
+-------+----------------+---------+-------------+---------+-------+
|2 | path_drop |Y | Y |RFC 9853 | |
+-------+----------------+---------+-------------+---------+-------+
|3-253 | Unassigned | | | | |
+-------+----------------+---------+-------------+---------+-------+
|254-255| Reserved for |Y | |RFC 9853 | |
| | Private Use | | | | |
+-------+----------------+---------+-------------+---------+-------+
Table 2: Initial Entries in TLS RRC Message Type Registry
表 2: TLS RRC メッセージ タイプ レジストリの初期エントリ
IANA added the following note to provide additional information regarding the use of RRC message codepoints in experiments:
IANA は、実験における RRC メッセージ コードポイントの使用に関する追加情報を提供するために、次の注記を追加しました。
Note: As specified in [RFC8126], assignments made in the Private Use space are not generally useful for broad interoperability. Those making use of the Private Use range are responsible for ensuring that no conflicts occur within the intended scope of use. For widespread experiments, provisional registrations (Section 4.13 of [RFC8126]) are available.
注: [RFC8126] で規定されているように、私的使用スペースで行われた割り当ては、一般に広範な相互運用性には役に立ちません。私的使用の範囲を使用する人は、意図された使用範囲内で矛盾が発生しないようにする責任があります。広範囲にわたる実験のために、暫定登録 ([RFC8126] のセクション 4.13) が利用可能です。
To enable a broadly informed review of registration decisions, it is recommended that multiple designated experts be appointed to represent the perspectives of both the transport and security areas.
幅広い情報に基づいた登録決定の審査を可能にするために、運輸分野と安全保障分野の両方の観点を代表する複数の指定された専門家を任命することが推奨されます。
In cases where a registration decision could be perceived as creating a conflict of interest for a particular expert, that expert SHOULD defer to the judgment of the other experts.
登録決定が特定の専門家にとって利益相反を引き起こすとみなされる可能性がある場合、その専門家は他の専門家の判断に従うべきである(SHOULD)。
[IANA.tls-parameters]
IANA, "Transport Layer Security (TLS) Parameters",
<https://www.iana.org/assignments/tls-parameters>.
[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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>.
[RFC9146] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and
A. Kraus, "Connection Identifier for DTLS 1.2", RFC 9146,
DOI 10.17487/RFC9146, March 2022,
<https://www.rfc-editor.org/info/rfc9146>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025,
<https://www.rfc-editor.org/info/rfc9847>.
[AMP-ATTACKS]
Preuß Mattsson, J., Selander, G., and C. Amsüss,
"Amplification Attacks Using the Constrained Application
Protocol (CoAP)", Work in Progress, Internet-Draft, draft-
irtf-t2trg-amplification-attacks-05, 18 June 2025,
<https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-
amplification-attacks-05>.
[IOT-PROFILE]
Tschofenig, H., Fossati, T., Richardson, M., and D.
Migault, "TLS/DTLS 1.3 Profiles for the Internet of
Things", Work in Progress, Internet-Draft, draft-ietf-uta-
tls13-iot-profile-19, 20 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-uta-
tls13-iot-profile-19>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander,
"Constrained Application Protocol (CoAP): Echo, Request-
Tag, and Token Processing", RFC 9175,
DOI 10.17487/RFC9175, February 2022,
<https://www.rfc-editor.org/info/rfc9175>.
We would like to thank Colin Perkins, Deb Cooley, Eric Rescorla, Éric Vyncke, Erik Kline, Hanno Becker, Hanno Böck, Joe Clarke, Manuel Pégourié-Gonnard, Marco Tiloca, Martin Thomson, Mike Bishop, Mike Ounsworth, Mohamed Boucadair, Mohit Sahni, Rich Salz, Russ Housley, Sean Turner, and Yaron Sheffer for their input to this document.
Colin Perkins、Deb Cooley、Eric Rescorla、Éric Vyncke、Erik Kline、Hanno Becker、Hanno Böck、Joe Clarke、Manuel Pégourié-Gonard、Marco Tiloca、Martin Thomson、Mike Bishop、Mike Ounsworth、Mohamed Boucadair、Mohit Sahni、Rich Salz、Russ Housley、Sean に感謝します。Turner と Yaron Sheffer にこの文書への意見を提供していただきました。
Hannes Tschofenig (editor)
University of the Bundeswehr Munich
Institute of Distributed Intelligent Systems
Werner-Heisenberg-Weg 39
85577 Neubiberg
Germany
Email: Hannes.Tschofenig@gmx.net
Achim Kraus
Email: achimkraus@gmx.net
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org