完整SIPSDP媒体协商概论3通风设备

完整SIP/SDP媒体协商概论

为了完成整个SIP/SDP媒中国负极材料出货量到达 7.09万吨体协商概论，笔者花费了很多时间介绍关于WebRTC中的ICE处理流程。通过完整的详解，笔者相信关于ICE处理流程的大部分内容已经解释的比较清楚。在总结ICE部署安全问题之前，重复说明一下关于ICE部署-RFC5245的完整名称：

Interactive Connectivity Establishment （ICE）：

A Protocol for Network Address Translator （NAT） Traversal for

Offer/Answer Protocols

在针对RFC5245的规范介绍中，笔者通过以下几篇文章详细说明了整个ICE流程处理的过程。如果读者想了解完整ICE部署场景和协议详解的话，读者可以参考以下链接：

完整SIP/SDP媒体协商概论-WebRTC/ICE概览

完整SIP/SDP媒体协商概论-ICE初始offer发送详解

完整SIP/SDP媒体协商概论-ICE初始offer接收详解

完整SIP/SDP媒体协商概论-STUN连接性检查-客户端流程

完整SIP/SDP媒体协商概论-后续offer处理-Off被广泛的利用于多个行业当中er

完整SIP/SDP媒体协商概论-STUN连接检查-服务器端流程

完整SIP/SDP媒体协商概论-后续offer处理-answer生成

完整SIP/SDP媒体协商概论-ICE选项和keepalives讨论

在本章节，笔者重点结合RFC8445官方为读者补充一些关于ICE部署操作时应该注意的一些问题。这里先说一点题外话。和RFC3261规范或者其他规范相比，笔者认为RFC5245规范不是一个 非常好 的规范（可能笔者是错误看法，仅供参考），主要有以下几个方面的原因：

多处定义和流程说明不是非常明晰完整（不具体举例），有个别语言用词不是非常规范，开发人员可能存在很多理解偏差。

因为WebRTC的发展太快，浏览器终端技术和开发语言也发展太快，很多新的其他技术在短短几年发生了很多变化，导致协议规范本身的兼容性出现很多问题。这可能也是WebRTC部署使用存在很多问题的原因。

关于和SIP相关内容调整有一点突然。如果SIP和ICE结合使用时，可能让开发人员引起歧义。因为在RFC8445中移除了此部分的建议，因此开发人员如何实现和SIP具体业务的兼容性支持是一个挑战。

当然，任何技术或者官方制定参与者都有其局限性，而且很多出现的新技术完全可能淘汰旧的技术，特别是一些基于浏览器的技术。因此，我们讨论关于ICE处理流程的规范时也必须要结合RFC8445规范来讨论，除了以上链接所介绍的文章以外，为了保证ICE处理流程讨论的完整性，笔者这里重点针对RFC5245和RFC8445中关于ICE部署时需要注意的几个问题进行补充讨论。接下来的讨论中，笔者将讨论关于ICE部署时需要考虑的问题，ICE安全问题，WebRTC安全架构草案。

1ICE部署时需要考虑的问题

这里，我们首先简单讨论关于NAT和防火墙的环境问题。当初ICE的设计目标是基于当时现存NAT和防火墙设备而设计的。因此，为了部署ICE也没有必要替换或者修改这些设备。另外，如果ICE部署在VOIP环境中的话包括了NAT和防火墙设备的话，语音质量的控制可能已经不是ICE环境所能够控制的。在两个关于NAT和防火墙处理方面的关键的规范RFC4787和RFC5382中，根据规范建议ICE部署应该可以完美支持NAT设备和其终端。在 遵从NAT规范 的络然后再逐渐加速环境中（实际上很难实现，很多场景仍然依赖于STUN，TURN服务器协助），无需STUN服务器端，ICE可以正常工作。其他一些呼叫应用的优化，例如语音质量提升，降低呼叫创建时间，降低带宽占用都取决于络运营者本身。

首先需要一定的带宽要求支持STUN和TURN服务器。在部署ICE时仍然需要很多和络环境本身的交互，因此很多因素都需要考虑。在现在比较大型的ICE部署环境中，典型的应用包括了ICE和STUN和TURN服务器的交互（一般应用可以借助于第三方的STUN服务器）。一般来说，这些服务器都部署在数据中心或者其他云服务平台。STUN服务器要求相对比较小的带宽服务。对于每个数据/媒体流的每个构件来说，从每个客户端到STUN服务器端至少将会产生一个或者多个STUN事务。在IPv4的络环境中，基于语音呼叫的呼叫流程中，每个呼叫在呼叫方和被呼叫方之间至少生成4个事务，包括各自的RTP和RTCP。每个事务是一个请求和一个响应。前期的数据包长度是20 bytes，后期的将达到28 bytes。其实，如果按照每个用户在繁忙时间，平均每个用户呼叫4次的话，10用户差不多需要10 1.7 bps， 一百万个用户也差不多1.4Mbps。 这个数据相对来说仍然是一个比较小的数据。当然，这是仅针对STUN 事务来说的，实际应用环境中还有很多其他因素需要考虑，这里不再讨论。

来自于Jusin Uberti （Google） 测试结果

相对于STUN来说，TRUN服务器可能需要更多的带宽。在TRUN服务器端除了STUN数据以外，可能还有其他转发的媒体数据。如果呼叫需要通过TRUN转发的话，络环境还要考虑转发到数据流量，最终处理方式仍然取决于络环境部署本身，例如，如何实现更加灵活的高并发语音和视频会议转发以及如何处理会议进行中人数动态增加的场景都是对带宽处理的挑战。

除了前面说的STUN和TURN服务器对带宽的要求以外，候选地址采集和连接性检查也对带宽有一定的要求。事实上，场景候选地址和执行连接性检查也非常消耗带宽。当然，这应该是一般的常识，和ICE创建以后相比，前期ICE执行候选地址采集和执行连接性检查需要双方不断发送和接收交互请求响应消息，因此就会产生更多的数据流量。如果ICE检查结束以后，带宽的消耗也相对比较低，重新启动ICE以后，带宽消耗又随着重新交互流程启动，带宽消耗也逐步增加。开始启动ICE keepalives以后，带宽仅局限于一定的边际范围，相当于总带宽来说仍然是比较小的消耗数量。因此，络部署环境中需要考虑部分ICE候选地址采集和连接性检查交互的数据带宽，还要考虑媒体流传输所需带宽，其余的ICE keepalvies的数据占比相对比较小，则无需太多考虑。

除了以上两种需要考虑到因素以外，因为候选地址场景和连接性接触引起的络拥塞也是一个在络部署中重要的考虑因素。很多络拥塞可能来自于终端的访问，包括终端处理性能问题，访问边界的络环境问题导致络拥塞。络部署中，管理人员应该考虑ICE部署所引起的这些问题，并且最好确保ICE部署可以实现灵活调整的功能。当然，如果支持ICE灵活调整功能的话，肯定会同时带来呼叫创建时间增加的风险，不过，这样可以保证ICE的稳定性和实现易部署方式。

在部署ICE时，用户也要考虑STUN keepalives的设置，避免过长或者过短的keepalives 设置，另外，keepalives的数据无需太多带宽支持，因此此参数应该不会影响络环境中ICE部署。

在很多部署环境中，用户可能混合使用ICE和lICE-lite。特别说明，ICE-lite的使用场景非常有限，建议用户慎用。

因为很多ICE部署场景是端对端的用户场景，在部署ICE场景时，ICE连接性检查启动端对端的执行流程时涉及了很多的处理流程。这些流程的执行对络运营人员是一个很大的挑战，因此络运营人员就会面对两个比较重要的问题：1）部署ICE时，如何通过工具来排查问题。2）如何通过工具来检测ICE的执行性能。ICE内置功能支持了信令交互的中传输ICE传输的设置，可以检测这些参数和候选地址类型。但是，目前专业的ICE排查工具相对还是比较少，另外，因为ICE需要浏览器客户端的支持，如果浏览器缺乏最新的规范支持，或者WebRTC缺乏最新官方支持的话，其工具可能会影响运维人员的排查效果。除了排查工具因为，另外一种排查手段是系统log或者浏览器的log日志。通过服务器端log和浏览器端的log可以提供丰富的log日志，可以检测到ICE的执行状态。

ICE配合终端使用时，其中一个重要的终端就是SIP终端。ICE的配置依赖于SIP终端的配置信息。配置终端上需要考虑的几个参数包括定时器，TURN服务器的用户安全信息，STUN和TURN主机名等。ICE自己本身不会提供这些配置信息，ICE依赖于附加到ICE的终端认证机制来实现。这种机制管理终端的用户配置信息，例如SIP终端使用的一个架构来传输SIP用户profile。因为篇幅关系，笔者这里不再展开讨论，如果读者有兴趣的话，可以参考RFC6080学习关于 Session Initiation Protocol User Agent Profile Delivery 。

2ICE安全问题讨论

安全问题一直是通信环境中最重要的问题，并且确实也存在很多的安全漏洞。因为无论在初期的信令协商阶段，还是在后期的语音视频传输阶段都可能存在数据暴露的问题。在ICE部署环境中也存在同样的可能性。在起始阶段中，侦测候选地址的流程就会暴露客户端和对端peer的源地址，攻击者就会不断监听这些端口和地址来找出攻击的漏洞。一些地址可能是比较敏感的地址，例如通过通过VPN用户的本地络接口采集到的服务器端反射地址。

如果在部署ICE时，络运维人员不能杜绝这些潜在的安全问题，ICE会针对这些地址使用定义机制进行协商和侦测执行流程，最终这些安全机制的核心信息就会被暴露出来。另外，WebRTC本质上来说是为了实现点对点的连接，如果用户双方通过web页面实现连接的话，它们之间的web源数据中可能会出现双方协商的其他相关地址信息，这些信息可能被其他第三方获得来，这样就会导致更多安全问题。为了针对WebRTC的地址安全问题进行优化，Google在2019年提出来一个草案作为一个WebRTC地址的执行要求：

WebRTC IP Address Handling Requirements

此份草案提出了4个基本规则和4个基本的模式（Enumerate all addresses，Default route associated local addresses，Default route only和Force proxy）。此草案提供了介于ICE和WEBRTC隐私暴露处理方面的要求和基本的原则。

以上背景说明总结了关于ICE中可能存在的安全问题，根据其环境部署，执行连接检测，侦测候选地址等不同阶段，在ICE部署中存在以下几种类型的攻击方式：

连接性检查攻击： 攻击者的目的是对连接性检查进行扰乱，攻击者让agent进入到一个错误的连接性检查的状态中。根据攻击类型的不同，攻击者需要不同的支持能力。在一些攻击场景中，攻击者需要置入到连接性检查的路径中。还有的场景中，攻击者也无需在连接性检查路径上，攻击者具备可以生成STUN连接检查的能力也可以进行攻击。攻击者在连接检查的络环境以后，它们可以被看作为一个络实体来控制agent，攻击者可以通过为连接性检查提供错误的检查结果或者测试结果进行攻击，具体的几种欺骗类型包括：

False Invalid：这种类型环境中，攻击者可以对一对agent进行欺骗，让agent认为候选地址是无效的地址。这样会引起agent的错误判断，让agent认为推荐的候选地址是有效地址（攻击者推荐的候选地址，已被注入），或者对呼叫进行干扰，强制候选地址采集失败。为了强制生成一个这样的结果，攻击者需要对端其中一方的agent发送对端连接检查。当连接性检查发送后，攻击者注入一个伪装的响应消息，携带一个不可恢复的错误响应，例如400或者故意丢弃此响应，响应就永远不会返回到agent。另外一种方式是如果候选地址是有效的，初始请求仍然可能会抵达对端agent，并且返回一个成功的响应。攻击者就需要强制数据包和其响应通过DoS的攻击的实体来干扰数据正常收发或者丢弃数据。攻击者通过伪装一个响应消息，使其具有能力通过STUN 短期安全机制生成用户信息。为了保证响应成功处理，攻击者需要密码，此刻，如果候选地址交互信令是加密的，攻击者就不会获得密码，不能获得密码然后就丢弃这个响应。当然，如果信令没有进行加密，攻击者就可能获得用户密码，进行进一步的攻击流程。伪装的Spoofed ICMP Hard Errors（Type 3, codes ）也可以用来生成False Invalid结果。攻击者也具有一定的能力生成ICMP错误响应消息来欺骗agent，agent会对攻击者暴露多个候选地址和端口信息。这样攻击者通过ICMP伪装的响应消息获得攻击权限。

False Valid：这种类型的欺骗环境中，攻击者可以对一对agent进行欺骗，当候选地址不是有效地址时，攻击者欺骗agent，认为候选地址配对是有效。这样会引起agent通过配对生成一个会话，最后，agent接收不到任何返回的数据。如何实现强制生成False Valid的具体流程和以上讨论的非常相似。

False Peer-Reflexive Candidate：这种类型的欺骗场景中，攻击者诱导agent发现一对新的候选地址配对，实际上这一对配对不是agent所期望获得的候选配对。这样可能导致攻击者通过数据转发的方式，让数据进入到DoS目的地，然后进行监听等攻击流程。这种方式的实现是通过伪造请求，伪造响应或伪造转发地址来实现。

False Valid on False Candidate：这种类型的欺骗采集中，agent已经相信了攻击者的身份，攻击者已经置入了一个候选地址，这个地址实际上不会路由到agent端地址。例如，注入错误的peer-reflexive candidate或者错误的false server-reflexive candidate。当然，如果攻击者注入任何其他的错误地址，攻击者可以进行任何方式的攻击。涉及到具体的安全攻击类型可以参考RFC。

以上多种场景可能发生有很多前提条件。除非伪装的候选地址确认了攻击者的身份，否则攻击很难实现。因为双方agent可能在不同的络环境，结构不同的转发地址，在不同络，不同终端那个同时协调，并且对攻击者实现了成功认证，这种概率相对比较低。即使攻击者被伪装的候选地址确认为一个正常用户，如果数据路径是加密的，攻击者也很难实现攻击，但是可能会对连接性检查流程造成干扰。

第二种攻击方式就是此服务器的反射地同时测力机构、导航、夹头等涂油包装利用煤油或汽油清洗址进行攻击-服务器反射地址采集攻击。因为ICE终端使用STUN绑定请求从STUN服务器端来采集服务器反射候选地址，不会以任何方式来进行签权认证。因此，攻击者可以使用很多方式进行攻击，例如，使用一些攻击方式为客户端提供错误的服务器反射候选地址。攻击者可以和DNS服务达成一个伪数据，这样，DNS查询以后返回一个伪装的STUN服务器地址，这个STUN服务器地址然后对客户端提供一个伪装的服务器反射地址。另外一种方式是通过攻击者监控STUN信息，发现络漏洞或者其他共享资源，例如WIFI等，然后攻击者注入自己的伪响应消息，客户端接受为有效的信息。还有一种攻击方式是攻击者通过伪造方式，构建一个STUN服务器，STUN服务器返回一个不正确的响应消息，携带错误的映射地址。

第三种方式是对转发候选地址采集攻击。攻击者试图干扰转发候选地址采集的消息，强制客户端相信客户端有一个错误的转发候选地址。TURN签权交互的机制是使用的长期安全机制，因此，如果注入伪装的响应消息或者请求消息不会很多成功的注入。另外，不像绑定请求的处理流程，因为为客户端提供转发候选地址时没有使用源IP地址和端口，因此，分配请求不会允许转发攻击（携带了已修改的源IP地址或端口）信息。最后，即使攻击者强制客户端认为其转发地址是无效转发候选地址，连接检查也成功确认其候选地址是成功的配对地址。攻击者仍然需要每次在错误的候选地址发起一个错误的有效结果，成功协调以上的状态对攻击者来说也是一个极大的挑战，因此这种攻击方式的成功概率也非常低。

最后一种攻击方式是内部攻击。很多时候，往往内部安全问题是安全措施中最为薄弱的地方。攻击者通过第三方工具注入伪候选地址或STUN信息。当攻击者在交互流程中是一个已认证用户和有效参与方时，攻击者可以发送攻击信息来配合ICE部署。一些内部软件或者第三方业务和ICE集成时可能会导致安全问题。比较常见的一种攻击方式是STUN放大攻击。攻击者会让agent转发候选地址或者语音数据包到一个目的地地址。攻击者发送大量的候选地址，相应的响应agent收到候选地址消息以后就会启动检查。就会转发到目的地地址，当然，最终这些目的地地址不会返回任何响应消息，agent因此也从来收不到响应消息。放大攻击的方式也可能使用在定时器的设置中。在WebRTC的使用场景中，攻击执行可能已经在后台执行，WebRTC用户可能根本没有意识已经被攻击，因为攻击执行可能通过浏览器访问已经获取到了攻击代码。同时，在每Ta毫秒内，answerer端将会启动一个新的连接性检查， 因为攻击者发送了大量的候选地址（例如提供50个候选地址），重传定时器就会对大量候选地址设置一个非常大的定时器数值。因为络资源的限定，或者agent端的资源能力，放大攻击的手段可能最终导致处理时延和其他相关流程的延迟。当然，这种放大攻击的手段也可以通过其他的手段来避免，例如，agent终端限制接受候选地址最大数量，或者限制连接性检查的并发数量等方式。很多研究人员也试图通过升级或者拓展相关的协议来避免攻击发生，例如强制发起方发送第一个消息以后，等待一段时间，收到回复响应以后，再进行下一个消息发送。这种思路事实上在ICE部署环境中非常难以实现，ICE不可能区分以下两种场景的处理：

无响应消息，因为发起方被启用执行DoS攻击来针对一个可信任的目的地实体（此实体将无任何响应）。

无响应消息，因为对发起方来说，IP地址和端口都是不可达状态。

以上这两种情况中，第一种情况下无进一步的检查发送，第二种情况下，在下一个机会中还会再发送一次检查消息。

3WebRTC安全初探

在本文章中，笔者重点讨论的是关于ICE的安全问题和其攻击手段的一些详解。但是，因为讨论ICE部署必须结合WebRTC来进行讨论，因此，笔者在本章节结合最近发布的一些WebRTC安全草案简单讨论一下关于WebRTC的业务功能中的一些安全问题。根据最新的关于WebRTC安全的草案和专家针对浏览器安全提出的建议，用户需要考虑以下几个方面的安全问题：

对信令加密，对媒体加密。笔者在以前很多文章中针对信令和媒体加密做了很多技术，这里不再讨论。

对终端资源进行安全管理。WebRTC需要访问终端麦克风和摄像头资源，所以用户需要对此资源进行充分的安全管理。调用这些资源前必须获得认可。

应用/屏幕关系的访问许可。确保对端用户是安全用户，可以确保本地信息不会被泄漏。

确保本地IP地址和隐私不会被轻易访问获取。

确保WebRTC访问策略返回企业内部的安全访问策略。

在最新的关于WebRTC安全架构的建议中，通过可信任命模式下针对已确认实体和未确认实体进行区别处理，并且增加了针对SIP SDP的拓展说明，WebRTC关于终端安全访问模式细节，通信认可处理，Web安全讨论和IP位置隐私处理等内容。这些最新的细节基本上符合了目前WebRTC中所遇到的各种安全问题，在ICE部署环境中，络运营人员可以通过此草案来做进一步学习。读者可以通过以下链接做更多了解：

WebRTC Security Architecture

本章节首先介绍了关于ICE运营环境的要求，然后介绍了关于ICE攻击的类型，最后介绍了WebRTC的安全问题以及关于WebRTC安全架构的简述。

总结，通过以上关于ICE攻击类型和安全条例，结合以前的历史文档，笔者已经基本完成了关于ICE部署的详解讨论。在接下来关于SIP/SDP的概论讨论中，笔者将继续讨论其他和SIP/SDP的内容。

参考资料：

融合通信/IPPBX商业解决方案：

最新Asterisk完整中文用户手册详解及免费slack支持：

Freepbx/FreeSBC技术文档：

如何使用FreeSBC，技术分享群：

关注公众号：asterisk-cn，获得有价值的通信行业技术分享