Independent Submission S. Toyosawa Request for Comments: 9401 Independent Category: Informational 1 April 2023 ISSN: 2070-1721 TCPへの死亡フラグの追加 概要 このメモは、TCPへの死亡フラグ(DTH)の組み込みを指定します。TCPヘッダの1ビットのDTHの使用法が含まれます。 このフラグは、TCPセッションの物語を滑らかで魅力的にするように設計されています。 このメモの位置付け この文書では、インターネット標準化過程の仕様ではありません、それは情報目的のために公開されています。 これは、他のいかなるRFCストリームに関係なく、RFCシリーズに貢献をしています。 RFC Editor は自らの裁量でこのドキュメントを公開することを選択しました。そして、実装や展開においてのその価値に関して何らかの声明を出すことはありません。 RFC Editorによって公表の承認をされたドキュメントはインターネット標準のいかなるレベルの候補でもありません。RFC7841のセクション2を見てください。 このドキュメントの現在の状況、正誤表、フィードバックの提供の仕方の情報については、https://www.rfc-editor.org/info/rfc9401 で得られるでしょう。 Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. 無断転載禁ず このドキュメントはBCP78とこのドキュメントの公表日に実施されているIETFドキュメントに関するIETF信託の法律条項 (https://trustee.ietf.org/license-info) の適用を受けます。 それらにこの文章に関する権利と制限が記述されていますので、慎重にこれらの文章を確認してください。 目次 1. はじめに 2. 必要条件 3. 仕様 3.1. TCPパケットのフォーマット 3.2. 送信する時 3.3. 送信しない時 3.4. IPイーブルビットとの併用 4. セキュリティ問題 5. IANA 問題 6. 参照 6.1. 参照する参考文献 6.2. 有益な参考文献 著者のアドレス 1. はじめに 提案された死亡フラグ、略してDTHは、TCPセッションの終了の可能性を示すために、TCPヘッダの4番目のフラグビットを使います。 フラグにより、アプリケーションは突然のセッションの終了に備えることができます。 ネットワークエンジニアは、TCPのRSTの1つ以上の根本的な原因を特定するのにこの機能が役立つと気づくでしょう。 批判的なエンドユーザはTCPの物語をより理解するためにこの情報を使うことができます。 フラグ名は、アニメ、漫画、ライトノベル[NOVEL]の習慣から採用されています。 "死亡フラグ"は、キャラクタがすぐに死ぬだろうことを暗に示します[CBR-FLAG]。 例えば、悪の科学者の死亡フラグは、彼らの破壊的な発明に過度の自信を示したときに設定されます。 多くの場合、科学者は独自の発明によって殺されます。 この種類の物語は、従来の映像でも一般的です。 注目すべき例は、塹壕にいる兵士です。 兵士のフラグは、彼らが婚約者の写真を共有し、戦いから戻った後で行われる結婚について話した直後に、1に設定されます。 別の例は、深夜の旅行で隔離された小屋からこっそり抜け出そうとするカップルに設定されます。 一般的に、この旅行はチェーンソーを持った人によって暴力的に終了されます。 2. 必要条件 この文章中の「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である(REQUIRED)」、「SHALL(するものとする)」、「しないものとする(SHALL NOT)」、「すべきである(SHOULD)」、「すべきではない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「推奨されない(NOT RECOMMENDED)」、「してもよい(MAY)」および「任意である(OPTIONAL)」のキーワードは、ここで示されるように全て大文字で現れる時のみ BCP 14 [RFC2119] [RFC8174]に記述されているとおりに解釈されます。 3. 仕様 3.1. TCPパケットのフォーマット DTHフラグは、図1に示されるTCPヘッダの制御ビットフィールドの4番目のビットを使います [RFC9293]。 4番目の中国語の"4"がSiで、"死"を意味するSiの音に似ているため、意図的に選ばれました。 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data |D| |C|E|U|A|P|R|S|F| | | Offset|T| Rsr |W|C|R|C|S|S|Y|I| Window | | |H| vd |R|E|G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Options] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : : Data : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1つのメモリは1つのビット位置を表すことに注意してください。 図1: DTHフラグビットを含むTCPヘッダ TCPセッションピアは、TCPセッションがすぐに終了する可能性がある場合にDTHセグメントを送信する必要があります。 サーバとクライアントの両方から送信できます。 アプリケーションまたはTCPスタックは、セッションが終了することを知っていても、DTHセグメントを送信試案ことを選択する場合があります。これはピアに激的な驚きをもたらします; ただし、エンドユーザはこの結末が便利すぎるまたは単純すぎると感じる場合があります。 セッションの終了に関連付けられていないDTHセグメントの使用は推奨されていませんが、許可されています(これは"からかい"または擬陽性のDTHフラグと呼ばれることがあります)。 DTHフラグは情報提供用です。 この機能を実装していないTCPソフトウェアは、このフラグを安全に無視できます。 ただし、セッションを十分に理解するために、ユーザはセッションの物語の微妙な兆候に注意する必要があります。 DTHフラグ自信はシーケンス番号または確認応答番号を変更しません。 確認応答を必要としません。 フラグの受信者は、受信時に別の動きをする必要はありません。ただし、エンドユーザにインシデントを通知できるように、情報をアプリケーション層に伝達することをお勧めします。 DTHセグメントの受信者は、受信直後にソケットを閉じるべきではありません。RSTまたはFINセグメントを待つべきです。 この仕様は、1つのTCPセッションで許可されるDTHセグメントの最大数を規定していません。ただし、劇的な効果を最大にするために、最大数を少なく制限することをお勧めします。 3.2. 送信する時 DTHは、送信者がTCPペアに必然的な終了を通知することが重要だと考える場合にいつでも使えます。 以下のシナリオ例はDTHセグメントをいつ送信するかを示しています。 悪意のあるアクターは、突然後悔したときにフラグを送信できます。例えば、送信者がDDoS攻撃の役割を突然公開し、予期せず攻撃を中止した場合です。 大悪党は通常行動が変更した直後に送信者を残酷かつ無慈悲に終了させます(または、ヒーローを守るために殺されます)。 DTHの転送のタイミングは実装に依存します。 裏切りの初期の兆候から行動の変化の直前までいつでも送信できます。 フラグは、送信者が暗号化保護の使用を止め、プレーンテキストの内容を明らかにした時に送信できます。例えば、マスクをかぶった謎のキャラクタが顔を露出した後に死ぬことがよくあります。 この例では、DTHセグメントは、HTRTPSからHTTPへのリダイレクト(30x)を送信する直前に送信されます[RFC9110] 同様に、偽造されたUser-AgentまたはServer HTTPヘッダフィールドが実際の値に変更された時、実際の身元が明かされた時(例えば、"生き別れの双子", "スパイである"など)に、フラグが送信できます。 これはキャラクタの死亡につながることがあります。 TCPピアは、メモリスペースや帯域の減少など、リソースの問題に気づいた時に、フラグを送信することをお勧めします。禁止されたプロトコルを使うAIボット、サイボーグ、魔法のアプリケーションなどは、エラーメッセージを大量に掃き始めた時に、フラグの送信を検討する必要があります。 タスクを実行する納涼の低いアプリケーションは、時々フラグを送信することができます。 その非効率性のために、それらは遅かれ早かれ、OS(悪役)またはCTRL-C(エンドユーザ)によって殺されます。 同じことが、メモリを大量に消費するアプリケーションでも発生することがあります。例えば、全ての宝物を奪おうとする不謹慎なキャラクタは、偶発的に死亡することがあります(例えば、崖から落ちます)。 アプリケーションは、"ハニーボット"または幽霊のでるサーバにアクセスする前に、よく考えるべきです。 選択肢が限られている場合(例えばお気に入りのサーバが人里離れた場所で故障し、DNSにないダークサーバが退避できる唯一の場所である場合)、定期的にフラグを送信することをお勧めします。 セッションはおそらく呪われています。 3.3. 送信しない時 DTHフラグはFINフラグに乗せるべきではありません。 DTHフラグがある場合、受信者はDTHフラグを黙って無視する必要があります。 唯一の例外は、受信者が北斗神拳("Big Dipper Divine Fist") [WIKI-FNS] の専門家である場合のみです。 その状況では、送信者はすでに死んでいますが、数秒間活動し続けます(これは非公式に"half-zombie open"と呼ばれます)。 DTHフラグはURGFフラグ[RFC6093]と共に送信されるべきではありません。 新しい実装では、URGフラグの使用は推奨されていません[RFC9293]。 TCPセッションの初期状態でのフラグの使用は推奨されません。 初期に死亡するキャラクタは重要ではないと見なされるため、彼らの死はセッションの質に影響しません。 3.4. IPイーブルビットとの併用 一部の実験的な実装では、セッションが悪のキャラクタを描写しているかを示すために、IPヘッダのEvilビット[RFC3514]を使います。 DTHフラグはTCPセッションを特徴づけるようには設計されていません。 それは、セッションの性質に関係なく、セッションの運命を示すことを目的としています。 EvilビットとDTHフラグの両方がある場合、それらは個別に解釈されなければなりません。 4. セキュリティ問題 TCPセッションの必然的な死(しばしば暴力的)の全長は、上位層のアプリケーションとエンドユーザにとって有用です。ただし、セキュリティと使いやすさのバランスも考慮する必要があります。 DTHフラグはTCPセッションの内部状態を公開する可能性があるため、攻撃者によって悪用される可能性があります(例えば、探偵が容疑者を指摘する前に殺人者を指名する)。 略奪は悪の行為です。 物語を秘密にしておきたい人は、フラグを穏やかに使う必要があります。 5. IANA 問題 この文章は、TCPヘッダで現在予約されている(Rsrvd)制御ビットの1つの動作を定義します。 TCPセッションの運命を示す有益な指標として使われます。 4番目のビット(TCPヘッダの13番目のオクテットの先頭から数えて)は、その意味を示すために意図的に選択されています。 この記号はハリウッドや日本のアニメーションスタジオネットワークで既に様々な方法で実装されている可能性があります。 6. 参照 6.1. 参照する参考文献 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header",RFC 3514, DOI 10.17487/RFC3514, April 2003, . [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . 6.2. 有益な参考文献 [CBR-FLAG] Stalberg, A., "10 Death Flags That Mean An Anime Character is Probably Going To Die", 2023, . [NOVEL] Wikipedia, "Light novel", February 2023, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [WIKI-FNS] Wikipedia, "List of Fist of the North Star characters", March 2023, . 著者のアドレス Satoshi Toyosawa Independent Email: s2.toyosawa@gmail.com