跳到主要内容

RFC 9401 - The Addition of the Death (DTH) Flag to TCP

  • 状态: Informational
  • 发布日期: April 2023
  • Stream: INDEPENDENT
  • 勘误: 无勘误

Abstract (摘要)​

本备忘录规定了向 TCP 添加死亡 (Death, DTH) 标志的规范,包括 DTH 在 TCP 头部中使用一个比特位.该标志旨在使 TCP 会话叙述更加流畅和引人入胜.

Status of This Memo (本备忘录的状态)​

本文档不是互联网标准跟踪规范 (Internet Standards Track specification);它的发布仅供参考.

这是对 RFC 系列的贡献,独立于任何其他 RFC 流.RFC 编辑器已选择自行发布本文档,并且不对其实施或部署价值做出任何声明.由 RFC 编辑器批准发布的文档不是任何级别的互联网标准的候选文档;请参见 RFC 7841 的第 2 节.

有关本文档当前状态、任何勘误表以及如何提供反馈的信息,可以从 https://www.rfc-editor.org/info/rfc9401 获取.

Copyright (c) 2023 IETF Trust 及文档作者.保留所有权利.

本文档受 BCP 78 和 IETF Trust 关于 IETF 文档的法律规定 (https://trustee.ietf.org/license-info) 的约束,这些规定在本文档发布之日有效.请仔细阅读这些文档,因为它们描述了您对本文档的权利和限制.

Contents (目录)​

重要说明​

本 RFC 发布于独立提交流 (Independent Submission stream).本 RFC 未得到 IETF 的认可,在 IETF 标准流程中没有正式地位.

注: 本文档是 2023 年愚人节 RFC,具有幽默性质,内容参考了动漫、漫画和轻小说中的"死亡标志"(Death Flag) 概念.

1. Introduction (简介)​

提议的死亡标志 (Death flag),简称 DTH,使用 TCP 头部中的第四个标志位来指示 TCP 会话可能即将终止.

该标志允许应用程序为突然的会话终止做好准备.网络工程师发现此功能有助于识别导致 TCP RST 的一个或多个根本原因.关键最终用户可以使用这些信息来更好地理解 TCP 叙述.

标志名称改编自动漫 (anime)、漫画 (manga) 或轻小说 (light novel) [NOVEL] 的习俗."死亡标志" (Death Flags) 指的是暗示角色即将死亡的提示 [CBR-FLAG].

例如,当邪恶科学家对其致命发明表现出过度自信时,他们的 DTH 标志就会被设置.该科学家通常会被自己的发明杀死.这种类型的叙述在传统电影中也很常见.一个值得注意的例子是战壕中的士兵.士兵在分享未婚妻的照片并讲述从战场返回后即将举行的婚礼之后,他的标志立即被设置为 1.另一个例子是为一对从偏僻小屋中偷偷溜出进行深夜远足的情侣设置标志.通常,这次远足会被一个手持电锯的人残酷地终止.

参考文献​

2. 要求语言 (Requirements Language)​

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和 "OPTIONAL", 当且仅当它们以此处所示的全大写形式出现时, 应按 BCP 14 [RFC2119] [RFC8174] 中的说明解释.

参考文献​

  • [RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997
  • [RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017

3. Specification (规范)​

3.1. TCP Packet Format (TCP 数据包格式)​

DTH 标志使用 TCP 头部中控制位字段 (Control bits field) 的第四个比特位,如图 1 [RFC9293] 所示.第四个比特位是特意选择的,因为中文中的"四"是 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: 带有 DTH 标志位的 TCP 头部

当 TCP 会话很可能即将终止时,TCP 会话对等体应该 (SHOULD) 传输 DTH 段.它可以从服务器和客户端双方发送.即使应用程序或 TCP 堆栈知道会话将被终止,也可以 (MAY) 选择不发送 DTH 段.这会给对等体带来戏剧性的惊喜;然而,最终用户可能会认为结局太过方便或过于简单.不鼓励使用与会话终止无关的 DTH 段,但这是允许的.(这通常被称为"戏弄"或假阳性 DTH 标志.)

DTH 标志是信息性的 (informational).不实现此功能的 TCP 软件可以安全地忽略此标志.然而,为了充分欣赏会话,用户应该意识到会话叙述的微妙迹象.

DTH 标志本身不会改变序列号或确认号.它不需要任何确认.

标志的接收者不需要在接收时采取不同的行动;但是,建议 (RECOMMENDED) 将信息传递给应用层,以便可以通知最终用户该事件.DTH 段的接收者不应该 (SHOULD NOT) 在接收时立即关闭套接字;它应该 (SHOULD) 等待 RST 或 FIN 段.

本规范未规定一个 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) 不时发送标志.它迟早会因效率低下而被操作系统(大反派)或 CTRL-C(最终用户)杀死.内存占用过多的应用程序也可能发生同样的情况,例如,试图获取所有宝藏的不择手段的角色通常会意外死亡(例如从悬崖上掉下来).

应用程序在访问"蜜罐"(honeypot) 或闹鬼服务器之前真的应该 (SHOULD) 三思而后行.如果您的选择有限(例如,您最喜欢的服务器在荒郊野外发生故障,而不在 DNS 上的黑暗服务器是您唯一可以庇护的地方),定期发送标志是个好主意.该会话很可能受到诅咒.

3.3. When Not to Send (何时不发送)​

DTH 标志不应该 (SHOULD NOT) 与 FIN 标志一起捎带 (piggybacked).如果存在,接收者应该 (SHOULD) 静默忽略 DTH 标志.唯一的例外是当接收者是北斗神拳 (Hokuto-Shinken, "Big Dipper Divine Fist") [WIKI-FNS] 的专家时.在这种情况下,发送方已经死了,但仍保持活跃几秒钟(这被非正式地称为"半僵尸打开"状态).

DTH 标志不应该 (SHOULD NOT) 与 URG 标志 [RFC6093] 一起发送.新实现中不建议使用 URG 标志 [RFC9293].

不建议 (NOT RECOMMENDED) 在 TCP 会话的早期阶段使用该标志.在早期阶段死亡的角色被认为是非必要的,因此他们的死亡不会对会话质量做出贡献.(显然,也有例外.)

3.4. Use with the IP Evil Bit (与 IP Evil Bit 配合使用)​

一些实验性实现使用 IP 头部的 Evil bit [RFC3514] 来指示会话是否描绘了一个邪恶角色.DTH 标志不是为表征 TCP 会话而设计的.它旨在显示会话的命运,而不管会话的性质如何.当 Evil bit 和 DTH 标志都存在时,它们必须 (MUST) 独立解释.

参考文献​

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

4. Security Considerations (安全考虑)​

TCP 会话不可避免的死亡(通常是暴力的)的前兆对于上层应用程序和最终用户很有用;然而,也应该考虑安全性与可用性的平衡.由于 DTH 标志可能暴露 TCP 会话的内部状态,它们可能被攻击者利用(例如,在侦探指出嫌疑人之前说出凶手的名字).剧透是一种邪恶行为.那些希望保守故事秘密的人应该温和地使用该标志.

风险分析​

  1. 信息泄露 (Information Disclosure): DTH 标志可能向攻击者透露会话即将终止的信息,这可能被用于时序攻击或其他恶意目的.

  2. 拒绝服务 (Denial of Service): 恶意行为者可能滥用 DTH 标志来误导接收方,导致不必要的资源分配或会话管理问题.

  3. 隐私考虑 (Privacy Considerations): 过度使用 DTH 标志可能泄露应用程序行为模式,从而影响用户隐私.

  4. 剧透效应 (Spoiler Effect): 提前知道会话将终止可能会降低用户体验的戏剧性和惊喜感.

建议​

  • 实现者应该谨慎使用 DTH 标志,避免在不必要的情况下设置该标志.
  • 网络管理员应该监控 DTH 标志的使用模式,以识别潜在的安全威胁.
  • 应用程序开发者应该考虑 DTH 标志可能带来的安全影响,并实施适当的防护措施.

5. IANA Considerations (IANA 考虑)​

本文档定义了 TCP 头部中当前保留 (Reserved, Rsrvd) 的控制位之一的行为.它被用作 TCP 会话命运的信息性指示器.第四个比特位(从 TCP 头部第十三个八位字节的开头算起)是特意选择来表示其含义的;然而,比特位位置的改变不会导致任何功能性退化.

此功能可能已经在好莱坞和/或日本动画工作室网络中以不同的方式实现;但是,据作者所知,该技术尚未获得专利.

TCP 头部控制位分配​

本规范使用了 TCP 头部控制位字段中的第四个比特位,该比特位之前处于保留状态.

比特位置: 第 4 位 (从控制位字段开始计数)
标志名称: DTH (Death)
用途: 指示 TCP 会话可能即将终止的信息性标志
参考: 本文档

注册要求​

虽然本文档定义了 DTH 标志的使用,但它被发布为信息性 RFC,不构成对 IANA TCP 参数注册表的正式更改请求.实现者如果希望在生产环境中使用此标志,应该注意其非标准性质.

实现注意事项​

  1. 向后兼容性 (Backward Compatibility): 不支持 DTH 标志的 TCP 实现将简单地忽略此比特位,因为它被视为保留位.

  2. 互操作性 (Interoperability): DTH 标志的使用不应影响与传统 TCP 实现的互操作性.

  3. 专利状态 (Patent Status): 据作者所知,本技术未受专利保护,但好莱坞或日本动画工作室可能已独立开发了类似的叙事技术.

6. References (参考文献)​

6.1. Normative References (规范性参考文献)​

6.2. Informative References (信息性参考文献)​

参考文献说明​

规范性参考文献 (Normative References)​

规范性参考文献是实现本规范所必需的文档.这些文档定义了 DTH 标志运行所需的关键协议元素和关键词解释.

信息性参考文献 (Informative References)​

信息性参考文献提供了有关 DTH 标志概念来源和相关背景的额外信息.这些参考文献有助于理解"死亡标志"概念的文化背景,但不是实现本规范所必需的.

相关 RFC 文档​

  • RFC 793 - Transmission Control Protocol (TCP 的原始规范)
  • RFC 9293 - Transmission Control Protocol (TCP 的最新更新)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit,另一个愚人节 RFC)
  • RFC 2119 - Key words for use in RFCs (RFC 关键词定义)
  • RFC 8174 - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words (RFC 2119 关键词的大小写说明)

Author's Address (作者地址)​

Satoshi Toyosawa
Independent
Email: [email protected]

关于作者​

Satoshi Toyosawa 是一名独立研究者,对网络协议和幽默性技术文档有浓厚兴趣.RFC 9401 是作者对 IETF 愚人节 RFC 传统的贡献,将动漫和漫画中的"死亡标志"概念创造性地应用到 TCP 协议中.

联系方式​

如有关于本 RFC 的问题、建议或评论,请通过以上电子邮件地址联系作者.

致谢​

感谢所有为本文档提供反馈和建议的人员.特别感谢那些理解并欣赏动漫、漫画和网络协议交叉点的幽默感的人们.

历史背景​

本文档于 2023 年 4 月 1 日发布,延续了 IETF 的愚人节 RFC 传统.这一传统始于 1978 年的 RFC 748,多年来产生了许多富有创意和幽默感的技术文档,包括:

  • RFC 1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers (鸽子传输 IP 数据报)
  • RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (超文本咖啡壶控制协议)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit)
  • RFC 7511 - Scenic Routing for IPv6 (IPv6 风景路由)
  • RFC 9401 - The Addition of the Death (DTH) Flag to TCP (本文档)

这些愚人节 RFC 虽然具有幽默性质,但通常包含对真实技术问题的深刻洞察,并展示了技术社区的创造力和幽默感.