摘要

  • RFC 5164 设想在信息、事件和命令服务之下复用一个通用传输容器；载荷保持不透明，传输层因此不能越权判断命令语义。
  • 服务发现、对端认证、安全关联、字节送达、事务关联、服务授权与切换结果必须分别留证，前一项成功不能替代后一项。

一条命令可以来自经过认证的对端，经过保密和完整性保护，未触发重放检查，并被可靠传输确认。所有灯都是绿色的，设备仍然可能不该执行它。

RFC 5164 讨论的正是这种容易被公共基础层掩盖的差异。它是 2008 年发布的 Informational 问题陈述，不是一个已经选定线协议的标准。动机来自 IEEE 802.21 媒体无关切换：不同接入技术之间的切换，需要终端和网络节点交换邻居信息、变化事件和操作命令。

文档把问题拆成两层。上层是特定移动服务的信令；下层是基于 IP 的 Mobility Service Transport Layer。下层提供容器、发现、传输和安全功能，却“不考虑”具体服务数据的协议语义。图中的结构很直接：传输头之后是一段不透明载荷。

不透明保护了扩展性，也限制了权力。看不懂命令的层，不能替命令签发授权。

三类消息不应被压成一个平均值

RFC 5164 使用 Information、Event 和 Command 三类服务。它们不只是三个标签。信息服务帮助终端理解候选网络；事件服务报告环境变化；命令服务可能触发信令或无线操作。

时间尺度明显不同。事件和命令预计以数百毫秒间隔到达，用来捕捉快速变化或处理切换；信息服务可能只在进入新网络时交换，相隔数小时或数日。典型事件/命令只有约 50 至 100 字节，信息响应通常小于 64 KB，却可能更大。

于是不存在一条万能传输曲线。按需建立可靠连接会付出握手延迟；长期连接要维持状态，并假定服务关系稳定；无连接方式减少准备，却把可靠性问题推给服务。大响应还涉及拥塞控制、分片与重组，小命令则更在意期限和重复执行。

把这些流量汇总成“移动信令成功率”，会消掉最重要的风险：一条 80 字节命令晚了 300 毫秒，与一份 70 KB 信息晚了 300 毫秒，意义完全不同。

发现只是获得候选位置

文档列出三种发现路径：在终端中预置节点地址；通过 DHCP 或 Router Discovery 等其他配置过程推送；由终端动态查询。移动服务节点的位置没有预设，发现可能跨越管理边界。

因此发现记录必须包含方法、来源、服务粒度、签发时间与失效时间。预置配置证明曾经写入，不证明今天仍有效；配置推送证明某个网络给出了地址，不证明该节点支持所需服务；动态返回证明查询命中了候选，不证明候选有权为这个访客发出命令。

RFC 5164 要求信息来自可信来源，并建议复用 AAA 或 SEND 建立的信任关系。它又单独指出，网络侧服务实体通常还需要证明自己有权服务来访设备。这不是重复要求。认证回答“谁持有密钥”，授权回答“这个身份此刻能对这个目标做什么”。

公共安全关联不能吞掉服务授权

文档希望 MSTP 端点之间使用与具体服务用户无关的公共安全关联协商，并要求方案在终端移动时也能工作。传输应在不可信中间网络上提供完整性和保密性，并考虑重放与拒绝服务。

这些能力都属于公共层合理的最小集合。但公共安全关联越成功，越容易被误读成通行证。Event 或 Command 的载荷可能要求改变无线状态，其影响由上层服务解释。传输层既然不检查载荷，就无法知道签名者是否只获准提供信息，还是也获准下达命令；无法知道命令是否过期；也无法知道设备是否处在允许执行的状态。

正确链条至少包括：发现凭据、对端和信任锚、安全关联、完整性/保密性/重放结果、传输确认、服务类型、事务标识、签发者权限、目标与时效、设备执行记录、链路变化以及用户可见结果。

请求和响应可以走不同链路

多宿场景把事务证据从地址中解放出来。RFC 5164 明确设想：请求从当前链路发出，响应可能从新链路回来。传输要能从多条链路接收，而 MSTP 用户负责把同一会话或事务的信息组合起来；需要时，底层 IP 移动机制提供会话连续性。

所以接口相同不是事务证明，地址相同也不是。系统需要一个在限定窗口内有效的事务键，并保存请求链路、响应链路、服务身份和授权上下文。否则新链路上的正确响应会被当作陌生流量，旧链路上的错误响应反而可能因路径熟悉而被接受。

隐私不能只看载荷是否加密

切换消息可能暴露设备在小区间的移动，甚至让观察者预测后续移动。文档要求具备保密性和完整性，在建立安全关联时尽可能保护身份，并强调用户不应为获取移动服务披露超过认证阶段所需的身份。

公共传输最容易引入“为了排障”的稳定标识。它短期方便关联日志，长期却把多个访问网络拼成移动轨迹。事务键应足以在请求与响应之间建立关系，并在审计期限结束后失效；订阅资格也不必暴露真实身份。

拒绝服务则要求分层成本控制。节点可能在发现、建立关联或解析服务载荷时遭到计算消耗。能在不理解语义的情况下廉价拒绝的请求应尽早处理；只有理解命令的服务层才能做的授权不能被硬塞进传输头。

问题陈述没有创造部署事实

RFC 5164 明确不选择复用现有协议还是开发新协议。它要求依据可行部署和既有经验制定现实性能目标，再向其他标准组织提供输入。RFC 编号证明问题被整理过，不证明 MSTP 已部署，不证明某个实现被采用，更不证明任何节点拥有生产授权。

公共层只应承担可共同验证的运输事实。语义、授权与是否执行，必须留在能够承担后果的本地服务边界。

来源