　　為了完成整個SIP/SDP媒體協(xié)商概論，筆者花費了很多時間介紹關于WebRTC中的ICE處理流程。通過完整的詳解，筆者相信關于ICE處理流程的大部分內(nèi)容已經(jīng)解釋的比較清楚。在總結ICE部署安全問題之前，重復說明一下關于ICE部署-RFC5245的完整名稱：

　　Interactive Connectivity Establishment （ICE）：

A Protocol for Network Address Translator （NAT） Traversal for
Offer/Answer Protocols

　　在針對RFC5245的規(guī)范介紹中，筆者通過以下幾篇文章詳細說明了整個ICE流程處理的過程。如果讀者想了解完整ICE部署場景和協(xié)議詳解的話，讀者可以參考以下鏈接：

　　在本章節(jié)，筆者重點結合RFC8445官方為讀者補充一些關于ICE部署操作時應該注意的一些問題。這里先說一點題外話。和RFC3261規(guī)范或者其他規(guī)范相比，筆者認為RFC5245規(guī)范不是一個“非常好”的規(guī)范（可能筆者是錯誤看法，僅供參考），主要有以下幾個方面的原因：

　　多處定義和流程說明不是非常明晰完整（不具體舉例），有個別語言用詞不是非常規(guī)范，開發(fā)人員可能存在很多理解偏差。

　　因為WebRTC的發(fā)展太快，瀏覽器終端技術和開發(fā)語言也發(fā)展太快，很多新的其他技術在短短幾年發(fā)生了很多變化，導致協(xié)議規(guī)范本身的兼容性出現(xiàn)很多問題。這可能也是WebRTC部署使用存在很多問題的原因。

　　關于和SIP相關內(nèi)容調整有一點突然。如果SIP和ICE結合使用時，可能讓開發(fā)人員引起歧義。因為在RFC8445中移除了此部分的建議，因此開發(fā)人員如何實現(xiàn)和SIP具體業(yè)務的兼容性支持是一個挑戰(zhàn)。

　　當然，任何技術或者官方制定參與者都有其局限性，而且很多出現(xiàn)的新技術完全可能淘汰舊的技術，特別是一些基于瀏覽器的技術。因此，我們討論關于ICE處理流程的規(guī)范時也必須要結合RFC8445規(guī)范來討論，除了以上鏈接所介紹的文章以外，為了保證ICE處理流程討論的完整性，筆者這里重點針對RFC5245和RFC8445中關于ICE部署時需要注意的幾個問題進行補充討論。接下來的討論中，筆者將討論關于ICE部署時需要考慮的問題，ICE安全問題，WebRTC安全架構草案。

　　1ICE部署時需要考慮的問題

　　這里，我們首先簡單討論關于NAT和防火墻的環(huán)境問題。當初ICE的設計目標是基于當時現(xiàn)存NAT和防火墻設備而設計的。因此，為了部署ICE也沒有必要替換或者修改這些設備。另外，如果ICE部署在VOIP環(huán)境中的話包括了NAT和防火墻設備的話，語音質量的控制可能已經(jīng)不是ICE環(huán)境所能夠控制的。在兩個關于NAT和防火墻處理方面的關鍵的規(guī)范RFC4787和RFC5382中，根據(jù)規(guī)范建議ICE部署應該可以完美支持NAT設備和其終端。在“遵從NAT規(guī)范”的網(wǎng)絡環(huán)境中（實際上很難實現(xiàn)，很多場景仍然依賴于STUN，TURN服務器協(xié)助），無需STUN服務器端，ICE可以正常工作。其他一些呼叫應用的優(yōu)化，例如語音質量提升，降低呼叫創(chuàng)建時間，降低帶寬占用都取決于網(wǎng)絡運營者本身。

　　首先需要一定的帶寬要求支持STUN和TURN服務器。在部署ICE時仍然需要很多和網(wǎng)絡環(huán)境本身的交互，因此很多因素都需要考慮。在現(xiàn)在比較大型的ICE部署環(huán)境中，典型的應用包括了ICE和STUN和TURN服務器的交互（一般應用可以借助于第三方的STUN服務器）。一般來說，這些服務器都部署在數(shù)據(jù)中心或者其他云服務平臺。STUN服務器要求相對比較小的帶寬服務。對于每個數(shù)據(jù)/媒體流的每個構件來說，從每個客戶端到STUN服務器端至少將會產(chǎn)生一個或者多個STUN事務。在IPv4的網(wǎng)絡環(huán)境中，基于語音呼叫的呼叫流程中，每個呼叫在呼叫方和被呼叫方之間至少生成4個事務，包括各自的RTP和RTCP。每個事務是一個請求和一個響應。前期的數(shù)據(jù)包長度是20 bytes，后期的將達到28 bytes。其實，如果按照每個用戶在繁忙時間，平均每個用戶呼叫4次的話，10用戶差不多需要10×1.7 bps，一百萬個用戶也差不多1.4Mbps。這個數(shù)據(jù)相對來說仍然是一個比較小的數(shù)據(jù)。當然，這是僅針對STUN 事務來說的，實際應用環(huán)境中還有很多其他因素需要考慮，這里不再討論。

　　來自于Jusin Uberti （Google）測試結果

　　相對于STUN來說，TRUN服務器可能需要更多的帶寬。在TRUN服務器端除了STUN數(shù)據(jù)以外，可能還有其他轉發(fā)的媒體數(shù)據(jù)。如果呼叫需要通過TRUN轉發(fā)的話，網(wǎng)絡環(huán)境還要考慮轉發(fā)到數(shù)據(jù)流量，最終處理方式仍然取決于網(wǎng)絡環(huán)境部署本身，例如，如何實現(xiàn)更加靈活的高并發(fā)語音和視頻會議轉發(fā)以及如何處理會議進行中人數(shù)動態(tài)增加的場景都是對帶寬處理的挑戰(zhàn)。

　　除了前面說的STUN和TURN服務器對帶寬的要求以外，候選地址采集和連接性檢查也對帶寬有一定的要求。事實上，場景候選地址和執(zhí)行連接性檢查也非常消耗帶寬。當然，這應該是一般的常識，和ICE創(chuàng)建以后相比，前期ICE執(zhí)行候選地址采集和執(zhí)行連接性檢查需要雙方不斷發(fā)送和接收交互請求響應消息，因此就會產(chǎn)生更多的數(shù)據(jù)流量。如果ICE檢查結束以后，帶寬的消耗也相對比較低，重新啟動ICE以后，帶寬消耗又隨著重新交互流程啟動，帶寬消耗也逐步增加。開始啟動ICE keepalives以后，帶寬僅局限于一定的邊際范圍，相當于總帶寬來說仍然是比較小的消耗數(shù)量。因此，網(wǎng)絡部署環(huán)境中需要考慮部分ICE候選地址采集和連接性檢查交互的數(shù)據(jù)帶寬，還要考慮媒體流傳輸所需帶寬，其余的ICE keepalvies的數(shù)據(jù)占比相對比較小，則無需太多考慮。

　　除了以上兩種需要考慮到因素以外，因為候選地址場景和連接性接觸引起的網(wǎng)絡擁塞也是一個在網(wǎng)絡部署中重要的考慮因素。很多網(wǎng)絡擁塞可能來自于終端的訪問，包括終端處理性能問題，訪問邊界的網(wǎng)絡環(huán)境問題導致網(wǎng)絡擁塞。網(wǎng)絡部署中，管理人員應該考慮ICE部署所引起的這些問題，并且最好確保ICE部署可以實現(xiàn)靈活調整的功能。當然，如果支持ICE靈活調整功能的話，肯定會同時帶來呼叫創(chuàng)建時間增加的風險，不過，這樣可以保證ICE的穩(wěn)定性和實現(xiàn)易部署方式。

　　在部署ICE時，用戶也要考慮STUN keepalives的設置，避免過長或者過短的keepalives 設置，另外，keepalives的數(shù)據(jù)無需太多帶寬支持，因此此參數(shù)應該不會影響網(wǎng)絡環(huán)境中ICE部署。

　　在很多部署環(huán)境中，用戶可能混合使用ICE和lICE-lite。特別說明，ICE-lite的使用場景非常有限，建議用戶慎用。

　　因為很多ICE部署場景是端對端的用戶場景，在部署ICE場景時，ICE連接性檢查啟動端對端的執(zhí)行流程時涉及了很多的處理流程。這些流程的執(zhí)行對網(wǎng)絡運營人員是一個很大的挑戰(zhàn)，因此網(wǎng)絡運營人員就會面對兩個比較重要的問題：1）部署ICE時，如何通過工具來排查問題。2）如何通過工具來檢測ICE的執(zhí)行性能。ICE內(nèi)置功能支持了信令交互的中傳輸ICE傳輸?shù)脑O置，可以檢測這些參數(shù)和候選地址類型。但是，目前專業(yè)的ICE排查工具相對還是比較少，另外，因為ICE需要瀏覽器客戶端的支持，如果瀏覽器缺乏最新的規(guī)范支持，或者WebRTC缺乏最新官方支持的話，其工具可能會影響運維人員的排查效果。除了排查工具因為，另外一種排查手段是系統(tǒng)log或者瀏覽器的log日志。通過服務器端log和瀏覽器端的log可以提供豐富的log日志，可以檢測到ICE的執(zhí)行狀態(tài)。

　　ICE配合終端使用時，其中一個重要的終端就是SIP終端。ICE的配置依賴于SIP終端的配置信息。配置終端上需要考慮的幾個參數(shù)包括定時器，TURN服務器的用戶安全信息，STUN和TURN主機名等。ICE自己本身不會提供這些配置信息，ICE依賴于附加到ICE的終端認證機制來實現(xiàn)。這種機制管理終端的用戶配置信息，例如SIP終端使用的一個架構來傳輸SIP用戶profile。因為篇幅關系，筆者這里不再展開討論，如果讀者有興趣的話，可以參考RFC6080學習關于”Session Initiation Protocol User Agent Profile Delivery“。

　　2ICE安全問題討論

　　安全問題一直是通信環(huán)境中最重要的問題，并且確實也存在很多的安全漏洞。因為無論在初期的信令協(xié)商階段，還是在后期的語音視頻傳輸階段都可能存在數(shù)據(jù)暴露的問題。在ICE部署環(huán)境中也存在同樣的可能性。在起始階段中，偵測候選地址的流程就會暴露客戶端和對端peer的源地址，攻擊者就會不斷監(jiān)聽這些端口和地址來找出攻擊的漏洞。一些地址可能是比較敏感的地址，例如通過通過VPN用戶的本地網(wǎng)絡接口采集到的服務器端反射地址。

　　如果在部署ICE時，網(wǎng)絡運維人員不能杜絕這些潛在的安全問題，ICE會針對這些地址使用定義機制進行協(xié)商和偵測執(zhí)行流程，最終這些安全機制的核心信息就會被暴露出來。另外，WebRTC本質上來說是為了實現(xiàn)點對點的連接，如果用戶雙方通過web頁面實現(xiàn)連接的話，它們之間的web源數(shù)據(jù)中可能會出現(xiàn)雙方協(xié)商的其他相關地址信息，這些信息可能被其他第三方獲得來，這樣就會導致更多安全問題。為了針對WebRTC的地址安全問題進行優(yōu)化，Google在2019年提出來一個草案作為一個WebRTC地址的執(zhí)行要求：

WebRTC IP Address Handling Requirements
https://tools.ietf.org/id/draft-ietf-rtcweb-ip-handling-12.html

　　此份草案提出了4個基本規(guī)則和4個基本的模式（Enumerate all addresses，Default route associated local addresses，Default route only和Force proxy）。此草案提供了介于ICE和WEBRTC隱私暴露處理方面的要求和基本的原則。

　　以上背景說明總結了關于ICE中可能存在的安全問題，根據(jù)其環(huán)境部署，執(zhí)行連接檢測，偵測候選地址等不同階段，在ICE部署中存在以下幾種類型的攻擊方式：

連接性檢查攻擊： 攻擊者的目的是對連接性檢查進行擾亂，攻擊者讓agent進入到一個錯誤的連接性檢查的狀態(tài)中。根據(jù)攻擊類型的不同，攻擊者需要不同的支持能力。在一些攻擊場景中，攻擊者需要置入到連接性檢查的路徑中。還有的場景中，攻擊者也無需在連接性檢查路徑上，攻擊者具備可以生成STUN連接檢查的能力也可以進行攻擊。攻擊者在連接檢查的網(wǎng)絡環(huán)境以后，它們可以被看作為一個網(wǎng)絡實體來控制agent，攻擊者可以通過為連接性檢查提供錯誤的檢查結果或者測試結果進行攻擊，具體的幾種欺騙類型包括：
False Invalid：這種類型環(huán)境中，攻擊者可以對一對agent進行欺騙，讓agent認為候選地址是無效的地址。這樣會引起agent的錯誤判斷，讓agent認為推薦的候選地址是有效地址（攻擊者推薦的候選地址，已被注入），或者對呼叫進行干擾，強制候選地址采集失敗。為了強制生成一個這樣的結果，攻擊者需要對端其中一方的agent發(fā)送對端連接檢查。當連接性檢查發(fā)送后，攻擊者注入一個偽裝的響應消息，攜帶一個不可恢復的錯誤響應，例如400或者故意丟棄此響應，響應就永遠不會返回到agent。另外一種方式是如果候選地址是有效的，初始請求仍然可能會抵達對端agent，并且返回一個成功的響應。攻擊者就需要強制數(shù)據(jù)包和其響應通過DoS的攻擊的實體來干擾數(shù)據(jù)正常收發(fā)或者丟棄數(shù)據(jù)。攻擊者通過偽裝一個響應消息，使其具有能力通過STUN 短期安全機制生成用戶信息。為了保證響應成功處理，攻擊者需要密碼，此刻，如果候選地址交互信令是加密的，攻擊者就不會獲得密碼，不能獲得密碼然后就丟棄這個響應。當然，如果信令沒有進行加密，攻擊者就可能獲得用戶密碼，進行進一步的攻擊流程。偽裝的Spoofed ICMP Hard Errors（Type 3, codes 2-4）也可以用來生成False Invalid結果。攻擊者也具有一定的能力生成ICMP錯誤響應消息來欺騙agent，agent會對攻擊者暴露多個候選地址和端口信息。這樣攻擊者通過ICMP偽裝的響應消息獲得攻擊權限。
False Valid：這種類型的欺騙環(huán)境中，攻擊者可以對一對agent進行欺騙，當候選地址不是有效地址時，攻擊者欺騙agent，認為候選地址配對是有效。這樣會引起agent通過配對生成一個會話，最后，agent接收不到任何返回的數(shù)據(jù)。如何實現(xiàn)強制生成False Valid的具體流程和以上討論的非常相似。
False Peer-Reflexive Candidate：這種類型的欺騙場景中，攻擊者誘導agent發(fā)現(xiàn)一對新的候選地址配對，實際上這一對配對不是agent所期望獲得的候選配對。這樣可能導致攻擊者通過數(shù)據(jù)轉發(fā)的方式，讓數(shù)據(jù)進入到DoS目的地，然后進行監(jiān)聽等攻擊流程。這種方式的實現(xiàn)是通過偽造請求，偽造響應或偽造轉發(fā)地址來實現(xiàn)。
False Valid on False Candidate：這種類型的欺騙采集中，agent已經(jīng)相信了攻擊者的身份，攻擊者已經(jīng)置入了一個候選地址，這個地址實際上不會路由到agent端地址。例如，注入錯誤的peer-reflexive candidate或者錯誤的false server-reflexive candidate。當然，如果攻擊者注入任何其他的錯誤地址，攻擊者可以進行任何方式的攻擊。涉及到具體的安全攻擊類型可以參考RFC5389-16。

　　以上多種場景可能發(fā)生有很多前提條件。除非偽裝的候選地址確認了攻擊者的身份，否則攻擊很難實現(xiàn)。因為雙方agent可能在不同的網(wǎng)絡環(huán)境，結構不同的轉發(fā)地址，在不同網(wǎng)絡，不同終端那個同時協(xié)調，并且對攻擊者實現(xiàn)了成功認證，這種概率相對比較低。即使攻擊者被偽裝的候選地址確認為一個正常用戶，如果數(shù)據(jù)路徑是加密的，攻擊者也很難實現(xiàn)攻擊，但是可能會對連接性檢查流程造成干擾。

　　第二種攻擊方式就是此服務器的反射地址進行攻擊-服務器反射地址采集攻擊。因為ICE終端使用STUN綁定請求從STUN服務器端來采集服務器反射候選地址，不會以任何方式來進行簽權認證。因此，攻擊者可以使用很多方式進行攻擊，例如，使用一些攻擊方式為客戶端提供錯誤的服務器反射候選地址。攻擊者可以和DNS服務達成一個偽數(shù)據(jù)，這樣，DNS查詢以后返回一個偽裝的STUN服務器地址，這個STUN服務器地址然后對客戶端提供一個偽裝的服務器反射地址。另外一種方式是通過攻擊者監(jiān)控STUN信息，發(fā)現(xiàn)網(wǎng)絡漏洞或者其他共享資源，例如WIFI等，然后攻擊者注入自己的偽響應消息，客戶端接受為有效的信息。還有一種攻擊方式是攻擊者通過偽造方式，構建一個STUN服務器，STUN服務器返回一個不正確的響應消息，攜帶錯誤的映射地址。

　　第三種方式是對轉發(fā)候選地址采集攻擊。攻擊者試圖干擾轉發(fā)候選地址采集的消息，強制客戶端相信客戶端有一個錯誤的轉發(fā)候選地址。TURN簽權交互的機制是使用的長期安全機制，因此，如果注入偽裝的響應消息或者請求消息不會很多成功的注入。另外，不像綁定請求的處理流程，因為為客戶端提供轉發(fā)候選地址時沒有使用源IP地址和端口，因此，分配請求不會允許轉發(fā)攻擊（攜帶了已修改的源IP地址或端口）信息。最后，即使攻擊者強制客戶端認為其轉發(fā)地址是無效轉發(fā)候選地址，連接檢查也成功確認其候選地址是成功的配對地址。攻擊者仍然需要每次在錯誤的候選地址發(fā)起一個錯誤的有效結果，成功協(xié)調以上的狀態(tài)對攻擊者來說也是一個極大的挑戰(zhàn)，因此這種攻擊方式的成功概率也非常低。

　　最后一種攻擊方式是內(nèi)部攻擊。很多時候，往往內(nèi)部安全問題是安全措施中最為薄弱的地方。攻擊者通過第三方工具注入偽候選地址或STUN信息。當攻擊者在交互流程中是一個已認證用戶和有效參與方時，攻擊者可以發(fā)送攻擊信息來配合ICE部署。一些內(nèi)部軟件或者第三方業(yè)務和ICE集成時可能會導致安全問題。比較常見的一種攻擊方式是STUN放大攻擊。攻擊者會讓agent轉發(fā)候選地址或者語音數(shù)據(jù)包到一個目的地地址。攻擊者發(fā)送大量的候選地址，相應的響應agent收到候選地址消息以后就會啟動檢查。就會轉發(fā)到目的地地址，當然，最終這些目的地地址不會返回任何響應消息，agent因此也從來收不到響應消息。放大攻擊的方式也可能使用在定時器的設置中。在WebRTC的使用場景中，攻擊執(zhí)行可能已經(jīng)在后臺執(zhí)行，WebRTC用戶可能根本沒有意識已經(jīng)被攻擊，因為攻擊執(zhí)行可能通過瀏覽器訪問已經(jīng)獲取到了攻擊代碼。同時，在每Ta毫秒內(nèi)，answerer端將會啟動一個新的連接性檢查，因為攻擊者發(fā)送了大量的候選地址（例如提供50個候選地址），重傳定時器就會對大量候選地址設置一個非常大的定時器數(shù)值。因為網(wǎng)絡資源的限定，或者agent端的資源能力，放大攻擊的手段可能最終導致處理時延和其他相關流程的延遲。當然，這種放大攻擊的手段也可以通過其他的手段來避免，例如，agent終端限制接受候選地址最大數(shù)量，或者限制連接性檢查的并發(fā)數(shù)量等方式。很多研究人員也試圖通過升級或者拓展相關的協(xié)議來避免攻擊發(fā)生，例如強制發(fā)起方發(fā)送第一個消息以后，等待一段時間，收到回復響應以后，再進行下一個消息發(fā)送。這種思路事實上在ICE部署環(huán)境中非常難以實現(xiàn)，ICE不可能區(qū)分以下兩種場景的處理：

　　無響應消息，因為發(fā)起方被啟用執(zhí)行DoS攻擊來針對一個可信任的目的地實體（此實體將無任何響應）。

　　無響應消息，因為對發(fā)起方來說，IP地址和端口都是不可達狀態(tài)。

　　以上這兩種情況中，第一種情況下無進一步的檢查發(fā)送，第二種情況下，在下一個機會中還會再發(fā)送一次檢查消息。

　　3WebRTC安全初探

　　在本文章中，筆者重點討論的是關于ICE的安全問題和其攻擊手段的一些詳解。但是，因為討論ICE部署必須結合WebRTC來進行討論，因此，筆者在本章節(jié)結合最近發(fā)布的一些WebRTC安全草案簡單討論一下關于WebRTC的業(yè)務功能中的一些安全問題。根據(jù)最新的關于WebRTC安全的草案和專家針對瀏覽器安全提出的建議，用戶需要考慮以下幾個方面的安全問題：

　　對信令加密，對媒體加密。筆者在以前很多文章中針對信令和媒體加密做了很多技術，這里不再討論。

　　對終端資源進行安全管理。WebRTC需要訪問終端麥克風和攝像頭資源，所以用戶需要對此資源進行充分的安全管理。調用這些資源前必須獲得認可。

　　應用/屏幕關系的訪問許可。確保對端用戶是安全用戶，可以確保本地信息不會被泄漏。

　　確保本地IP地址和隱私不會被輕易訪問獲取。

　　確保WebRTC訪問策略返回企業(yè)內(nèi)部的安全訪問策略。

　　在最新的關于WebRTC安全架構的建議中，通過可信任命模式下針對已確認實體和未確認實體進行區(qū)別處理，并且增加了針對SIP SDP的拓展說明，WebRTC關于終端安全訪問模式細節(jié)，通信認可處理，Web安全討論和IP位置隱私處理等內(nèi)容。這些最新的細節(jié)基本上符合了目前WebRTC中所遇到的各種安全問題，在ICE部署環(huán)境中，網(wǎng)絡運營人員可以通過此草案來做進一步學習。讀者可以通過以下鏈接做更多了解：

　　WebRTC Security Architecture

　　https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#section-6.4

　　本章節(jié)首先介紹了關于ICE運營環(huán)境的要求，然后介紹了關于ICE攻擊的類型，最后介紹了WebRTC的安全問題以及關于WebRTC安全架構的簡述。

　　總結，通過以上關于ICE攻擊類型和安全條例，結合以前的歷史文檔，筆者已經(jīng)基本完成了關于ICE部署的詳解討論。在接下來關于SIP/SDP的概論討論中，筆者將繼續(xù)討論其他和SIP/SDP的內(nèi)容。

　　參考資料：

　　https://tools.ietf.org/id/draft-thomson-tram-turn-bandwidth-01.xml

　　https://tools.ietf.org/html/draft-wing-tram-turn-mobility-03

　　https://github.com/coturn/rfc5766-turn-server/

　　https://bloggeek.me/is-webrtc-safe/

　　https://webrtc-security.github.io/

　　https://tools.ietf.org/html/draft-ietf-rtcweb-security-12#section-3