摘要

  • RFC 1457 把安全标签视为数据的属性，而不是一张自动生效的通行证；标签必须与数据保持可信绑定，其语法、语义和本地转换都要成立。
  • 标签放在哪一层，决定它能控制什么：路由器只需看与选路或丢弃有关的部分，终端可信组件则要在向进程交付数据之前获得足够完整的含义。
  • 标签被识别，不等于访问已授权、加密已启用或保密结果已发生；这些是由不同主体掌握的后续事实。

比特没有变，规则仍可能变

RFC 1457 由 Russell Housley 撰写，于 1993 年 5 月以 Informational 文档发布。它没有为整个互联网规定一套统一的安全等级，也没有要求所有协议都携带标签。它提供的是一组设计问题：某个协议是否需要安全标签，标签应当显式写入还是从环境中继承，应当随每个分组重复还是附着在连接上，又应放到哪一层，交给哪种设备处理。

这组问题从一个看似微小的区分开始。安全标签不是数据正文，而是数据的一个属性。它说明数据在收集、处理、转发、保存、检索、传播或销毁时需要怎样的保护。数据移动时，属性应当跟着移动；某个节点如果重新标记数据，那也是一次必须有权限依据的处理行为。

因此，“标签字段仍然存在”只是最低层的观察。真正需要保存的是标签与特定数据之间的关系。RFC 1457 把完整性保护列为维持这种绑定的一般方法；如果通信环境没有提供相应服务，就必须有别的机制。正确的标签贴到错误的数据上，比没有标签更危险，因为它会生成一条看似可信的错误指令。

标签抵达终端后，问题从传输变成解释。操作系统或数据管理系统可能使用自己的标签格式，和网络协议里的格式并不相同。接收端必须先把网络表示转换成本地表示，而且不能损失含义；可信计算基础随后才有条件判断某个进程是否拥有足够授权。

这条链上至少有四个不同事实：解析器认得字段形状；转换器找到了本地对应项；访问控制规则允许特定主体接触特定数据；可信组件确实执行了允许或拒绝。第一项成功不能替第四项作证。

语法统一不是政策统一

两个安全域可以使用相同的数字，却让它们代表不同保护义务；也可以用不同术语表达近似义务。源端的一组细分隔离区，在目标端可能只有一个笼统类别。转换器可以保留等级而丢掉例外，可以把多项限制压成一项，也可以把无法表达的语义默认为允许。

这种错误最棘手之处，是输出仍然可能完全符合目标语法。监控只会看到“转换成功”，而不会看到限制范围已经扩大。RFC 1457 因而主张尽量减少转换：使用共同的显式语法，再以登记的语义支持多种政策。这样解析软件可以稳定，政策空间仍可分开。

不过，登记语义不是产生全球权威。登记项只能告诉参与者应到哪里查定义，不能替本地系统作访问决定，也不能迫使两个安全域承认彼此等价。转换关系仍需由相关主体明确同意，本地规则仍由运行系统执行。

当端系统格式无法统一时，应用网关可以承担转换。此时它已经不只是搬运数据，而是在解释义务、选择对应关系并输出新的安全属性。它同时成为互操作节点和权力节点。RFC 1457 提醒这种网关会妨碍本来能够直接互通的协议，因此共同格式的价值之一，就是减少对这个中心翻译者的依赖。

完整性与敏感性是两张表

RFC 1457 还把“安全标签”拆成两个维度。完整性标签描述数据值得多少信任，以及需要怎样防止修改或毁坏。敏感性标签描述信息泄露会造成多大损害，以及需要怎样防止披露。

数据经过某些网络组件后，可相信程度可能下降；但泄露造成的损害不会因为它经过网络就自动降低。不同资料被组合时，泄露后果甚至可能增加。高完整性不等于低敏感性，低完整性也不等于可以公开。把二者压成一个“安全级别”，会让系统用错控制理由。

加密同样不能代替这两个维度。加密可以在某段路径上保护内容，认证或完整性机制可以帮助证明标签没有被篡改，但它们并不自动定义标签属于哪个语义域，也不决定解密后哪个进程可以读取数据。标签、密码学状态和授权决定必须分开记录。

路由器只该看到它需要看到的部分

终端系统与中间系统做的不是同一种决定。终端可能需要完整标签，才能把数据交给有资格的进程。路由器或网桥可能只需知道标签中与转发或丢弃有关的子集。要求每台设备理解每个应用的隔离区，会增加处理成本，也会把不必要的政策细节暴露给更低层。

RFC 1457 把信息隐藏原则用到了安全元数据本身。与路由有关的信息可以放在链路层或网络层，供真正执行相关决定的设备读取；只供端点使用的部分应放在更高层，避免无关节点承担解析负担。没有做标签访问控制的设备，不应仅因流量经过而成为政策解释者。

但标签也不能放得过高。如果目标是“可信分用”——由系统可信组件在数据交给普通进程前进行筛选——标签必须在交付边界之前可用。应用打开消息后才看见的标签，可以指导应用自己的处理，却无法撤销此前已经发生的进程交付。

所以，RFC 1457 对 OSI 七层的逐层讨论，本质上是一张控制权限图。物理层没有协议控制字段来承载显式标签，却能通过固定端口隐含一个等级。数据链路层可以帮助网桥作决定。网络层可以让路由器读取，也可能足够早地支持可信分用。传输层可把更丰富的属性绑定到连接，但普通中间设备不会处理。应用层最适合承载应用专用规则，却太晚，无法控制下层已经完成的动作。

正确答案不是“越低越安全”，而是让信息在相关决定发生前抵达相关执行者，同时不给无关设备更多语义和负担。

显式与隐式，逐包与随连接继承

RFC 1457 用两组选择描述标签如何存在。第一组是显式与隐式。显式标签写在协议控制信息里；隐式标签则从别的属性推断，例如物理端口、入站接口、连接或所选密码密钥。

隐式标签节省空间，在单一等级的封闭环境里尤其自然：某个受控端口进入的所有数据都继承同一属性。但证据也随之移出分组。要复原一次决定，审计者必须知道当时的端口绑定、连接状态、密钥映射或接口政策。只看抓包，可能什么也看不见。

第二组是无连接与面向连接。无连接标签随每个协议数据单元出现，允许逐包判断，但会反复占用有限头部空间。面向连接标签在建立虚电路、连接或关联时确定，后续数据自动继承，降低了重复开销，也提高了对状态连续性的依赖。

连接被错误复用、初始协商记录遗失、政策改变后旧连接仍存活，都会让格式完全正常的数据继承错误属性。此时故障不是字段畸形，而是上下文错位。“分组里没有标签”也不能证明没有标签，因为架构可能把它放到了带外状态中。

RFC 1108 展示了配置如何补完字段

RFC 1108 具体定义了美国国防部环境中的 IPv4 基本和扩展安全选项。基本选项包含分类等级和保护机关标志，是显式、无连接、网络层标签的实例。

即使在这个明确格式里，关键决定仍由本地配置补全。每个端口的参数可以规定发送或接收时是否必须带选项、是否接受未标记数据报，以及未标记数据从某端口进入时继承什么隐式标签。同一组比特并没有携带整个接收端政策。

RFC 1457 引用这项设计，是为了抽象出更广的问题，而不是把某个国家机构的分类体系变成互联网普遍政策。这也划清了它与 RFC 1455 的边界：RFC 1455 讨论发送方请求更难被外部观察的物理路径；RFC 1457 讨论数据携带怎样的处理属性。选路偏好不是分类，分类也不证明路线、加密和保密结果。

后来的 DOI 把语义域写得更清楚

2009 年的 RFC 5570 为 CALIPSO 定义 IPv6 显式分组敏感性标签时，把 Domain of Interpretation 放到核心位置。一个孤立的“SECRET”没有可执行含义；接收端还要知道是哪个组织的等级和隔离区体系在定义它。DOI 是指向政策语境的标识，不是政策全文，更不是自动执行器。

RFC 5570 同时明确限定场景：它面向受信任、可信赖的封闭式多级安全网络，不适用于全球公共互联网。历史比较必须保留这个范围，不能把专用机制包装成普遍部署建议。

RFC 4301 则从 IPsec 展示另一条链。分组选择条件与本地政策相遇，结果可以是保护、绕过或丢弃；安全关联再承载实际密码处理状态。标签可以成为政策输入，但标签本身不是安全关联，不证明算法已经运行、对端已经验证或接收者已经授权。

这三份文档共同揭示的边界很窄：元数据可以描述所需待遇，却不会因为被写入字段就完成待遇。