摘要

  • LTP Cookie 是会话内可变状态。接收端接受更长的扩展值之后，原来的短值不再有效；重传要重新使用当时的当前值。
  • Cookie 只能提高盲目拒绝服务流量的成本，不能认证是谁改变了状态。AuthVal 认证分段，但密钥如何分发、KeyID 表示什么、旧密钥何时退役都不由 RFC 5327 决定。

重传不是把旧字节重新排队

假设一个分段带着正确 Cookie 离开发送端。它还在链路上时，对端给这个 Cookie 追加了随机位。计时器随后要求重传，系统从持久化队列中找到当初的完整编码。

如果原样发送，负载确实没有变化，安全状态却已经过期。RFC 5327 明确要求重传携带重传时正确的 Cookie；它可能与原始发送使用的值不同。重传因此是一次新的封装行为，而不是旧证据的复制。

审计需要同时保留逻辑负载哈希与编码分段哈希，记录每次尝试所用的 Cookie 状态、重传原因、接收结果和接触窗口。只有“同一 payload 重试三次”无法解释为什么第一次可接受、第三次应被静默丢弃。

这也改变故障归因。字节完全相同不表示网络损坏，旧值曾经有效也不表示现在仍然有效。接收端拒绝它，可能正是在正确执行状态迁移。

有效性来自前缀关系和本地时钟

任一 LTP 引擎都可以在会话中随时引入 Cookie。在考虑通信时延的宽限期过去之后，这个会话双向的所有分段都必须带有有效值。在更新还可能位于链路途中时，实现需要有限地接受尚未带值的旧在途分段。

宽限长度由实现判断。它依赖单程时延、接触计划、发送机会与本地政策，而不是分段里的自证字段。同一份无 Cookie 分段在一个时间点可能合理，稍后则必须丢弃。

Cookie 可以通过追加随机位延长。新值如果以当前存储值开头，就满足前缀规则；此前从未看见值时，也可以接受一个初始值。一旦更长值被接受，短前身就不再有效。这不是多个 token 并列存在，而是一条单调链。

记录必须包含前身、扩展后的受保护指纹、观察者、接收时间、生效截止点和首次强制使用。只保存“最新 Cookie”会把宽限判断和责任主体一起删除。

双方同时开始会产生两条状态链

时延允许两个引擎都在看到对方值之前发出自己的初始 Cookie。规范要求随后保留两个独立扩展字段；流量追上状态以后，两者都必须有效。

对端初始值还必须在有限窗口内抵达。超过这个窗口，一个此前未知值就不能无限期声称自己是“另一方早已发送但刚刚到达”的初始根。窗口把接触时序变成接纳权限的一部分。

单一 session_cookie 字段不能表示两个方向、两条前缀链和两个截止时间。把重复扩展归一化成键值表也可能覆盖真正通过或失败的那一项。

证据模型要保留扩展出现顺序、数量、方向和逐项判断，然后才生成摘要。

静默丢弃只能证明本地拒绝

宽限期后，缺失或错误的 Cookie 必须被静默丢弃。这个设计避免向攻击流量投入更多资源，却让发送端看到的只是没有回应。

沉默可能来自过期短值、更新丢失、截止时间误算、双 Cookie 编码错误、认证失败、扩展不受支持、资源限制或根本没有通信机会。发送端的超时不能选择其中一个作为事实。

接收端也只能陈述本地证据：某个分段在某时刻不符合存储的前缀规则。它不能仅凭这一事件断言对端恶意、链路重放或运维人员操作错误。

可用的事件链要合并两端日志、状态转换、计时依据、每次重新封装的哈希、丢弃计数与接触计划。

Cookie 能防盲猜，不能证明来源

难以预测的值提高了盲目注入的成本，但追加随机位的人未必是合法对端。RFC 5327 特别指出：缺少来源认证时，中间人可以延长现有 Cookie，从而把真正的对端锁在会话之外。

攻击利用的不是实现错误。接收端接受未认证的更长状态后，按规则拒绝合法对端仍持有的短值。一个正确状态机执行了一项没有权威来源的更新。

Cookie 与 AuthVal 因而不能互相替代。Cookie 证明分段与当前会话状态相容；AuthVal 证明编码分段在某个密码上下文下验证成功。两者都不证明应用授权、Bundle 送达、机构身份或任务结果。

Cookie 也不会跨越 LTP 会话存续。它不是跨会话或重启后的持久防重放清单。

验证成功仍可能依赖旧密钥

LTP-auth 头部携带 8 位套件号和可选 KeyID，尾部携带 AuthVal。KeyID 只是原始字节，其解释明确在规范范围之外。协议不负责密钥配送、托管、激活或退役。

认证会话的首个分段必须带头部；后续分段可以省略。为了减轻首段丢失，带宽允许时应重复上下文；重传首段时必须再次包含认证头部。

密钥切换期间，发送端可以同时加入新旧 AuthVal。接收端逐个搜索，只要一个验证正确就可以接受。这个规则支持不中断过渡，却让单一 verified=true 失去密钥世代信息。

若旧密钥仍在配置中，所有流量都可能“认证成功”，即使新密钥从未工作。必须记录成功的 AuthVal 实例、套件、KeyID、验证器与外部授权状态。另一方面，在预期重叠中一个候选失败、另一个成功，也不能把失败自动统计成攻击。

注册编号不等于当前安全建议

RFC 最初定义 HMAC-SHA1-80、RSA-SHA256 与 NULL。NULL 使用硬编码密钥，只提供强校验而不提供认证，仍会遭受主动攻击。计算结果匹配不能把它改写成身份已验证。

IANA 注册表记录编号归属，不证明算法适合今天的风险，不证明部署采用，也不证明密钥生命周期安全。RFC 5327 属于 Experimental，并明确把 DTN 密钥管理留作开放研究问题。现实系统必须提供独立的密码与运行证据。

来源与证据边界

这些来源证明规则、编号与发布状态，不证明当前部署、已配置密钥、攻击、会话历史、实现合规或应用结果。