摘要

  • RFC 3436 把编号相同的相反方向 SCTP 流配成双向通道，每个通道建立独立 TLS 连接；会话可以复用，握手可以延后，但每条受保护流仍须完成自己的握手。
  • TLS 要求严格有序且不可放弃的记录，只保护 SCTP 用户数据，不覆盖全部控制块；RFC 6083 后来正面列出这些限制，用一条 DTLS 连接保留无序递送、部分可靠性和更多流。

一个关联里没有一个统一的安全状态

设想一个拥有三十二条流的 SCTP 关联。第 0 流已经完成完整握手，第 1 流正用同一 TLS 会话做缩短握手，第 2 流直到应用真正使用时才开始握手；若干单向流根本不能按 RFC 3436 承载 TLS，另一些双向流仍在传原生 SCTP 数据。此时“这个关联有 TLS”虽然不全错，却隐藏了最重要的事实：安全状态属于具体连接和具体流。

RFC 3436于 2002 年 12 月发布，说明怎样把 TLS 1.0 放在 SCTP 之上。纯文本、RFC Editor 条目、IETF 文档页、历史与引用图证明规范记录，不证明某个产品实现、互操作成功或生产采用。

TLS 要字节河流，SCTP 给有边界的包裹

TLS 1.0假定下层提供可靠且按序的字节流；原始 SCTP提供有消息边界的多流、多宿传输，RFC 3309则更新了校验和。RFC 3436 没有修改两种协议，而是规定一条 TLS 记录成为一条 SCTP 用户消息。

SCTP 必须负责分片和重组，让 TLS 不必知道 MTU，并避免 IP 分片。实现至少要支持 18,437 字节的用户消息，即 2^14 + 2048 + 5。这也可能要求部分递送 API。网络分片不是 TLS 记录；重组后的记录也不等于应用已经执行了请求。

两个方向中相同编号的流被配成双向流，因此可用双向流数量是两边流数的较小值，多出来的只能保持单向。每个双向流拥有一条 TLS 连接和一次独立握手。这样，一条流被阻塞不会让关联中的其他安全流一起停止；代价是流数越大，连接状态与握手开销越线性增长。

规范允许完整握手、复用其他连接会话的缩短握手，以及等到流首次使用才握手。在长时延网络上，并行完整握手可能更快；计算资源紧张时，会话复用可能更便宜。但“同一会话”不等于“同一连接”：第 0 流已就绪，不能替第 1 流完成握手。

加密保留不了所有 SCTP 自由

TLS 记录必须严格按序。因此，受保护流不得使用 SCTP 的无序递送，也不得给记录设置有限寿命后让发送端放弃。单向流不能按此方案承载 TLS。与此同时，同一关联内的其他流仍可不受这些限制地发送原生 SCTP 数据。

这形成了混合边界：有序、完全可靠的加密用户数据与可无序、可采用其他策略的原生数据并存。RFC 3758后来定义部分可靠性，RFC 7496仍明确指出 TLS over SCTP 不能用于 PR-SCTP。

更关键的边界来自RFC 4895：RFC 3436 的 TLS 只保护 SCTP 用户数据，不能证明 SCTP 控制块来自原始对端。于是 SCTP-AUTH 必须另行认证选定块。加密载荷、TLS 对端身份、DATA 块认证和控制块认证是四种不同凭据。

多宿同样不能替代身份。SCTP 记录可能从与最初认证时不同的 IP 地址到达。RFC 3436 要求安全决定依赖经认证的对端身份，而不是传输层地址。地址改变未必代表身份改变；占有地址也不等于拥有身份。

DTLS 把边界移到关联层

2011 年的RFC 6083直接列出四项严重限制：不能无序递送、不能部分可靠、只能使用两个方向数量相同的流，并且每条双向流都要一条 TLS 连接，大规模时资源与消息开销显著。

它改用关联内的一条 DTLS 连接。握手、告警等控制消息走第 0 流，保持有序和无限可靠；应用数据可走其他多条流，保留消息边界、无序递送和部分可靠性。DATA 块必须用 SCTP-AUTH；使用部分可靠性时，FORWARD-TSN 也必须认证。这不是“换一个密码套件”，而是重新划定安全与传输的责任面。

RFC 8996后来废弃 TLS 1.0 与 1.1，因此 RFC 3436 的原始密码套件要求只能作为历史机制阅读。IANA 的SCTP 参数注册表证明编号得到协调，不证明代码正在运行。

Heng Lu 关于现实层的分析提醒我们：规范发布、握手完成、控制块认证和应用结果各自作证。运行代码优先要求实测实现，而最小初始规范解释了为何早期方案可以复用既有协议，同时坦白舍弃一部分能力。这是后见编辑分析，不是对 RFC 作者动机的宣称。

RFC 3436 最耐久的价值，是没有把边界藏起来。准确说法不是“SCTP 已被保护”，而是“这条流以这个身份完成了这次握手，遵守这些递送规则，而关联控制仍需要另一张证明”。

来源

其他冻结记录