9. 安全考虑

RTP 载荷格式会受到通常与 RTP 载荷格式相关的安全威胁影响, 也会受到触觉设备与物理世界交互所特有的威胁, 以及编解码器使用压缩所关联的威胁影响. [RFC3550] 概述了通常与 RTP 载荷格式相关威胁的安全考虑, RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] 和 RTP/SAVPF [RFC5124] 等 RTP profile 也包含相关讨论.

触觉传感器和执行器运行在物理环境中. 这带来通过传感器泄露信息的可能, 也可能因数据篡改而损坏执行器. 此外, 滥用执行器功能 (例如力, 位置, 温度, 振动, 电触觉等) 可能对用户造成伤害风险, 例如将 keyframe 参数 (如 amplitude, position 和 frequency) 或 channel gain 设置为超出允许范围的值. 虽然单个设备可以逐设备实现安全措施来降低或消除这些风险, 但在某些情况下, 即使设置的值对单个设备而言是允许的, 仍可能造成伤害. 例如, 造成与物理环境接触或触发意外 force feedback 都可能伤害用户. 因此, 每个触觉系统都应该实现依赖系统的安全措施, 而这类措施更容易出错. 为限制攻击者利用触觉系统弱点的风险, 保护触觉传输免受恶意流量注入或篡改非常重要.

不过, 正如 "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] 所讨论的, RTP 载荷格式本身并不负责讨论或强制要求使用哪些方案来满足 RTP 一般所需的基本安全目标, 如机密性, 完整性和源真实性. 实现安全机制的责任在应用开发者. 开发者可以在 "Options for Securing RTP Sessions" [RFC7201] 中找到可用安全机制和重要考虑的指导, 尽管 [RFC7201] 现在被认为已有年代, 其中描述的若干机制后来也已演进.

应用应该使用适当且当前足够强的安全机制. 对于现代最佳实践, 应用可以考虑以下选项:

基于 (D)TLS 的保护: 关于使用 TLS 1.3 和 DTLS 的指导, 应用应该参考 [BCP195], 该 BCP 提供最新建议.
基于 IPsec 的保护: 相关且当前有效的协议规范包括 [RFC4303] ("IP Encapsulating Security Payload (ESP)") 和 [RFC7296] ("Internet Key Exchange Protocol Version 2 (IKEv2)").

本文档不强制规定某一种特定安全机制. 相反, 应用负责选择遵循当前机密性, 完整性和源认证最佳实践的机制, 并反映超出 [RFC7201] 覆盖范围的不断演进的安全形势.

与此载荷格式一起使用的触觉编解码器采用压缩算法 (见 [ISO.IEC.23090-31] 第 8.2.8.5 和第 8.3.3.2 节). 攻击者可能向流中注入病态数据报, 这些数据报解码复杂, 并可能像 [RFC3551] 中描述的情况那样导致接收方过载.

带认证, 完整性或机密性保护的端到端安全会阻止 Media-Aware Network Element (MANE) 执行除丢弃完整 packets 之外的媒体感知操作. 在采用机密性保护的情况下, MANE 甚至无法以媒体感知方式丢弃 packets. 若要允许 MANE 执行此类操作, MANE 必须是纳入安全上下文建立过程的受信实体.