メインコンテンツまでスキップ

3. 仕様 (Specification)

3.1. TCP パケットフォーマット (TCP Packet Format)​

DTH フラグは、図 1 [RFC9293] に示すように、TCP ヘッダーの制御ビットフィールドの 4 番目のビットを使用します。4 番目のビットは意図的に選択されました。なぜなら、中国語で「四」は Sì であり、「死」を意味する Sǐ と似た音だからです。

 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 セグメントを送信すべきです (SHOULD)。これはサーバーとクライアントの両方から送信できます。アプリケーションまたは TCP スタックは、セッションが終了することを知っていても、DTH セグメントを送信しないことを選択してもかまいません (MAY)。これにより、ピアに劇的な驚きがもたらされます。ただし、エンドユーザーは結末が便利すぎるか、過度に単純であると認識する可能性があります。セッション終了に関連しない DTH セグメントの使用は推奨されませんが、許可されています。（これはしばしば「ティージング」または偽陽性 DTH フラグと呼ばれます。）

DTH フラグは情報提供です。この機能を実装していない TCP ソフトウェアは、このフラグを安全に無視できます。ただし、セッションを完全に理解するには、ユーザーはセッションナラティブの微妙な兆候を認識する必要があります。

DTH フラグ自体は、シーケンス番号または確認応答番号を変更しません。確認応答は必要ありません。

フラグの受信者は、受信時に異なる動作をする必要はありません。ただし、エンドユーザーにインシデントを通知できるように、情報をアプリケーション層に伝達することが推奨されます (RECOMMENDED)。DTH セグメントの受信者は、受信時にすぐにソケットを閉じるべきではありません (SHOULD NOT)。RST または FIN セグメントを待つべきです (SHOULD)。

この仕様では、1 つの TCP セッションで許可される DTH セグメントの最大数は規定されていません。ただし、劇的な効果を最大化するために、数個に制限することが推奨されます (RECOMMENDED)。

3.2. 送信するタイミング (When to Send)​

送信者が TCP ピアに避けられない終わりを知らせることが重要であると考える場合はいつでも、DTH を使用できます。以下のシナリオ例は、DTH セグメントを送信するタイミングを示しています。

悪意のあるアクターは、突然悔い改めるときにフラグを送信できます。たとえば、送信者が DDoS 攻撃への関与を突然後悔し、予期せず攻撃を停止する場合です。大悪党は通常、行動の変化の直後に送信者を残酷かつ無慈悲に終了させます（または、ヒーローを保護したために殺されます）。DTH 送信のタイミングは実装に依存します。裏切りの早期兆候から行動変化の直前までのいつでも送信できます。

送信者が暗号化保護の使用を停止し、平文コンテンツを明らかにする場合、フラグを送信できます。たとえば、顔を露出した後によく死ぬマスクをかぶった謎のキャラクターなどです。この例では、DTH セグメントは HTTPS から HTTP [RFC9110] へのリダイレクト (30x) を送信する直前に送信されます。同様に、偽造された User-Agent または Server HTTP ヘッダーフィールドが実際の値に変更されたとき、真のアイデンティティが明らかになるとき（たとえば、「私はあなたの長く失われた双子です」、「私はスパイです」など）にフラグを設定できます。これは時折、キャラクターの死につながります。

TCP ピアは、リソースの問題に気付いたとき、たとえばメモリ空間や帯域幅の減少などに気付いたときに、フラグを送信することが推奨されます (RECOMMENDED)。AI ボット、サイボーグ、禁じられたプロトコルを持つ魔術師アプリケーションなどは、エラーメッセージを激しく咳き込み始めたときにフラグを送信することを検討すべきです (SHOULD)。

タスクを実行する能力が低いアプリケーションは、時々フラグを送信してもかまいません (MAY)。非効率性のため、遅かれ早かれ OS（大悪党）または CTRL-C（エンドユーザー）によって殺されます。メモリを大量に消費するアプリケーションでも同じことが起こる可能性があります。たとえば、すべての宝物を奪おうとする不誠実なキャラクターは、しばしば偶然死にます（たとえば、崖から落ちる）。

アプリケーションは、「ハニーポット」または幽霊サーバーにアクセスする前に本当によく考えるべきです (SHOULD)。選択肢が限られている場合（たとえば、お気に入りのサーバーが人里離れた場所で故障し、DNS にない暗いサーバーが避難できる唯一の場所である場合）、定期的にフラグを送信することは良い考えです。セッションはおそらく呪われています。

3.3. 送信しないタイミング (When Not to Send)​

DTH フラグは FIN フラグにピギーバックすべきではありません (SHOULD NOT)。存在する場合、受信者は DTH フラグを静かに無視すべきです (SHOULD)。唯一の例外は、受信者が北斗神拳 (Hokuto-Shinken, "Big Dipper Divine Fist") [WIKI-FNS] の専門家である場合です。その状況では、送信者はすでに死んでいますが、数秒間アクティブなままです（これは非公式に「半ゾンビオープン」状態と呼ばれます）。

DTH フラグは URG フラグ [RFC6093] と一緒に送信すべきではありません (SHOULD NOT)。URG フラグの使用は、新しい実装では推奨されません [RFC9293]。

TCP セッションの初期段階でフラグを使用することは推奨されません (NOT RECOMMENDED)。初期段階で死ぬキャラクターは非必須と見なされるため、その死はセッションの質に貢献しません。（明らかに、例外があります。）

3.4. IP Evil Bit との使用 (Use with the IP Evil Bit)​

一部の実験的実装では、IP ヘッダーの Evil ビット [RFC3514] を使用して、セッションが悪のキャラクターを描写しているかどうかを示します。DTH フラグは TCP セッションを特徴付けるように設計されていません。セッションの性質に関係なく、セッションの運命を示すことを意図しています。Evil ビットと DTH フラグの両方が存在する場合、それらは独立して解釈されなければなりません (MUST)。

参考文献​

  • [RFC3514]: Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, 2003年4月
  • [RFC6093]: Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, 2011年1月
  • [RFC9110]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, 2022年6月
  • [RFC9293]: Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, 2022年8月
  • [WIKI-FNS]: Wikipedia, "List of Fist of the North Star characters", 2023年3月
に最終更新