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

端对端场景

典型的端对端方案涉及两个互相通信的网络运营商.

一个端对端方案例子如图2所示. 运营商A的网络中的发起网关（GW-A1）发送一个INVITE,该INVITE请求通过SBC被路由到运营商B的网络中的软交换(SS-B)中,软交换响应重定向（3xx）消息到SBC中,然后SBC路由INVITE请求到运营商B网络中的相应终端网关（GW-B1）. 如果运营商B没有SBC，则重定向消息将转发到运营商A的发起网关,在收到重定向消息后,这样运营商A就知道运营商B终端网关信息了.

从SBC的角度来看,运营商A是外部网络,运营商B是内部网络. 运营商B可以使用SBC来控制对其网络的访问,保护其网关和软交换免受未经授权的使用和拒绝服务（DoS）攻击，并监控信令和媒体流量.它还通过最小化网关中ACL（访问控制列表）条目的数量来简化网络管理.网关不需要暴露给对端网络,并且它们可以限制对SBC的访问（媒体和信令.SBC有助于确保只有来自SBC授权的会话的媒体才能到达网关.

2.2.访问控制场景

访问控制场景架构在图3中显示,SBC位于接入网络（外部网络）和运营商网络（内部网络）之间的边界,以控制对运营商网络的访问, 保护其组件（媒体服务器、应用服务器、网关等）免受未经授权的使用和DoS攻击,并监控信令和媒体流量. 此外,由于SBC是有呼叫状态的,因此它可以提供访问控制功能以防止访问链路的超额订阅.端点配置可以将SBC作为其出站代理地址,将呼叫请求路由到运营商网络中的一个或多个代理.

SBC可以安装在接入网络中（例如，这在接入网络是是常见的企业网络类型）,或者在运营商专有网络中（接入网络是住宅或小型商业网络时这是常见的）.尽管SBC是托管的，但它的维护同程也由运营商网络的组织管理.

在有些场景下终端可能位于企业或住宅NAT的网络后.这种情况下,SBC要负责网络的NAT转化(值得注意的是,SIP消息可能需要经过多次NAT). SIP代理通常对注册和呼叫进行身份验证和/或授权.SBC修需要改REGISTER请求,以便对注册的记录地址的后续请求被路由到SBC.这可以通过Path头字段[3]或通过修改Contact指向SBC来完成.

本节中介绍的方案是一般通用方案，它也适用于其他类似网络设置.例如接入网络是开放的互联网,运营商网络是SIP服务提供商的情况也可以参考上述设置.

SBC的功能

本节列出了SBC在当前通信网络中常用的功能.每个小节描述了一个特定的功能,包含运营商对其的要求、对端到端SIP架构的影响的说明，以及具体的实现示例.每个部分还讨论了对于该特定实现方式的潜在问题.对于可能在结构上与SIP更兼容的替代实现技术的建议超出了本文档的讨论范围.

本节给出的所有例子都是简化的;仅显示来自SIP和SDP（会话描述协议）[7]消息的相关标题.

3.1.   拓扑隐藏

3.1.1.  功能说明和要求

拓扑隐藏是指限制暴露给外部的SIP信息.运营商需要此功能，因为他们不希望其设备的IP地址（代理，网关，应用服务器等）暴露给外部网络.

这可能是因为他们不希望将他们的设备暴露给DoS攻击，同时他们可能会使用其他运营商的某些交互,并且不希望他们的客户意识到这一,或者他们可能想要将他们的内部网络架构向竞争对手或合作伙伴隐藏起来.

在某些环境中，运营商的某些客户可能希望隐藏其设备的地址，或者SIP消息可能包含私有的，不可路由的地址.

最常见的拓扑隐藏形式是头部隐藏（参见[2]的第5.1节）,其中包括剥离Via和Record-Route头,替换Contact头,甚至更改Call-ID.

但是在无法删除的标头中（如From和To标头）,如果使用IP地址而不是域名,SBC可以用自己的IP地址或域名替换这些IP地址.

作为参考，除了将诸如SBC的中间件插入信令路径之外,还存在隐藏拓扑信息的其他方式. 其中一种方法是UA驱动的隐私机制[8]，其中UA可以促进隐藏拓扑信息/

3.1.2.  风险说明

如上所述,由未经用户同意的SBC执行拓扑隐藏会出现一些问题.

1. 此功能基于逐跳信任模型,而不是端到端信任模型.在未经用户同意的情况下修改消息，并且可能修改或删除有关用户的隐私信息、安全要求以及使用SIP端到端通信的高层应用程序的信息.
2. 端到端呼叫中的用户代理都无法区分SBC操作与中间人模拟（a man-in-the-middle  MITM）攻击操作.

在SBC没有得到用户同意的情况下,拓扑隐藏功能与用户身份认证机制(Authenticated Identity Management) [4]不兼容.Authenticated Identity Management机制基于哈希值,该哈希值是从From、To、Call-ID、CSeq、Date和Contact头字段以及整个邮件正文的部分计算得出的.如果SBC本身没有提供认证服务，则上述报头字段和消息体的修改违反了[4].某些形式的拓扑隐藏是错误的，因为它们例如替换了SIP消息的Contact头.

3.1.3.  例子

当前实现拓扑隐藏的方式是用SBC充当B2BUA（背对背用户代理）并从发出的消息中移除所有拓扑信息的痕迹（如Via和Record-Route条目）.

想象一下以下示例场景：SBC（p4.domain.example.com）从内部网络接收INVITE请求，在这种情况下,收到的SIP消息如图4所示

图4: 在拓扑隐藏之前INVITE请求

然后,SBC执行拓扑隐藏功能.在这种情况下,SBC删除并存储所有现有的Via和Record-Route标头,然后使用自己的SIP URI插入Via和Record-Route标头字段.在拓扑隐藏功能之后,消息可能如图5所示.

INVITE sip:callee@u2.domain.example.com SIP/2.0

Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w230129.1

Contact: sip:caller@u1.example.com

Record-Route: <sip:p4.domain.example.com;lr>

图5: 在拓扑隐藏之后INVITE请求

与插入Record-Route头信息的通用代理服务器一样,SBC需要处理指定SIP对话的每条SIP消息.如果SBC丢失状态（例如，由于某种原因SBC重新启动）,它可能无法正确地路由消息（注意：一些SBC在重启时也保留状态信息）.例如，如果SBC从请求中删除Via条目然后重新启动，则会丢失状态; SBC可能无法路由对该请求的响应（具体取决于SBC重新启动时丢失的信息）.

这只是拓扑隐藏的一个示例.除了拓扑隐藏（隐藏与网络元素相关的信息）之外,SBC还可以进行身份隐藏（隐藏与订户身份相关的信息）.在执行身份隐藏时,SBC可以修改Contact头字段值和包含身份信息的其他头字段.包含身份信息的头字段列在[2]的第4.1节中.自[2]发布以来，已经定义了包含身份信息的以下头字段：”P-Asserted-Identity”，”Referred-By”，”Identity” 和 ”Identity-Info.