您的位置: 首页  >  文章  >  SBC功能部署规范 - RFC5853中文翻译（5）

SBC功能部署规范 - RFC5853中文翻译（5）

分类: 文章 • 2024-05-24 16:53:34

 3.7 媒体加密

3.7.1.  功能说明和要求

SBC用于在网络边缘执行媒体加密/解密.当媒体加密（例如，安全实时传输协议（SRTP））仅在接入网络（外部网络）侧使用并且媒体在内部网络中未加密地传送时就是这种情况. 一些运营商提供了进行合法拦截的能力，同时仍然使其客户能够加密接入网络中的媒体. 一种可能的方法是执行媒体加密功能.

3.7.2.  风险说明

在执行媒体加密功能时，SBC需要能够将自己或某个其他实体注入媒体路径.必须指出的是，这种行为与传统的MITM攻击相同.因此，SBC具有与3.2节中所述相同的架构问题.

3.7.3.  例子

图14示出了SBC执行与媒体加密相关的功能的示例（为简洁起见省略了ACK）.

SBC功能部署规范 - RFC5853中文翻译（5）

首先，UAC发送INVITE请求,并且第一个SBC以将其自身注入媒体路径的方式修改会话描述符.第二个SBC也是如此.然后,用户代理服务器（UAS）回复200 OK响应,并且SBC将自己注入返回的媒体路径.在发信号之后,媒体开始流动,并且两个SBC执行媒体加密和解密.

4.  未来SIP标准化工作的衍生要求

本节中列出的某些功能比其他功能更不友好.此要求列表源自在未经用户同意的情况下由SBC执行的以某种方式违反SIP原则的功能.派生的要求是:

要求-1:   应该有一种SIP友好的方式来隐藏网络拓扑信息.目前，这是通过剥离和替换头字段来完成的，这代表了某些头字段的SIP原则（参见第3.1节）.

要求-2:   应该有一种SIP友好的方式来通过中介来引导媒体流量.目前，这是通过修改会话描述符来完成的，这违反了SIP的原则（参见第3.2,3.4,3.5和3.7节）.

要求-3:   应该有一种SIP友好的方法来修复SIP消息中的功能不匹配.在复杂的不匹配情况下，例如3GPP / SIP [1]网络不匹配，这个要求更难实现.目前，这是通过修改SIP消息来完成的，这些消息可能代表某些标头字段违反了端到端安全性（参见第3.3和3.6节.

要求-1和要求-3至今没有现成的标准化解决方案。 IETF正在进行处理要求-2的工作，例如SIP会话策略[10]，使用NAT周围的中继（TURN）[11]和交互式连接建立（ICE）[12]。 尽管如此，为了开发满足这些要求的解决方案，还需要进一步开展工作.

5.  安全考虑因素

本文档描述的许多功能都具有重要的安全和隐私含义。 一个主要的安全问题是由SBC实现的许多功能（例如，拓扑隐藏和媒体流量管理）在没有用户代理同意的情况下修改SIP消息及其主体。 结果是用户代理可以将SBC采取的动作解释为MITM攻击。 SBC修改SIP消息，因为它允许它们例如保护内部网络中的元素免受直接攻击.

将自己（或其他实体）置于媒体路径上的SBC可用于窃听对话. 由于用户代理通常无法区分攻击者的行为和SBC的行为，因此用户无法知道他们是否被窃听，或者路径上的SBC是否正在执行某些其他功能.SBC将自己放在媒体路径上，因为它允许它们例如执行合法拦截.

在一般情况下，SBC阻止使用端到端身份验证。 这是因为SBC需要能够执行看起来像MITM攻击的操作，并且为了使用户代理进行通信，它们必须允许这些类型的攻击。 换句话说，用户代理不能使用端到端安全性。 这尤其有害，因为除了SBC之外，其他网络元素也可以进行类似的攻击。 但是，在某些情况下，用户代理可以在彼此之间建立加密的媒体连接。 一个例子是SBC用于启用媒体监控但不用于拦截的场景.

从架构的角度来看，SBC是单点故障。 这使其成为DoS攻击的有吸引力的目标。 SBC的某些功能要求那些SBC维持会话特定信息的事实使情况更糟。 如果SBC崩溃（或被攻击者摧毁），正在进行的会话会遇到不确定的行为.

如果IETF决定开发标准机制来满足第4节中提出的要求，那么这些机制的安全和隐私相关方面当然需要加以考虑.

6.  致谢

2004年11月9日在第61届IETF会议期间在华盛顿举行的关于SBC的特别会议为本文件提供了宝贵的意见。 作者还要感谢Sridhar Ramachandran，Gaurav Kulshreshtha和Rakendu Devdhar。 评论家Spencer Dawkins和Francois Audet也值得特别感谢.

7.  附录

规范性参考文献

  1. Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
  2. Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
  3. Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
  4. Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
  5. Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

7.2.  信息参考

  1. 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 10.0.0, March 2010.
  2. Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
  3. Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, 四月 2010.
  4. Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
  5. Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", Work in Progress, February 2010.
  6. Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, 四月 2010.
  7. Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, MonthTBD 2010.

 

相关推荐