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

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

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

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

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

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

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

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

　　來自于Jusin Uberti （Google） 測試結(jié)果

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　無響應(yīng)消息，因?yàn)榘l(fā)起方被啟用執(zhí)行DoS攻擊來針對一個(gè)可信任的目的地實(shí)體（此實(shí)體將無任何響應(yīng)）。

　　無響應(yīng)消息，因?yàn)閷Πl(fā)起方來說，IP地址和端口都是不可達(dá)狀態(tài)。

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

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

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

　　對終端資源進(jìn)行安全管理。WebRTC需要訪問終端麥克風(fēng)和攝像頭資源，所以用戶需要對此資源進(jìn)行充分的安全管理。調(diào)用這些資源前必須獲得認(rèn)可。

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

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

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

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

　　WebRTC Security Architecture

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

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

　　總結(jié)，通過以上關(guān)于ICE攻擊類型和安全條例，結(jié)合以前的歷史文檔，筆者已經(jīng)基本完成了關(guān)于ICE部署的詳解討論。在接下來關(guān)于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

　　融合通信/IPPBX商業(yè)解決方案：www.hiastar.com

　　最新Asterisk完整中文用戶手冊詳解及免費(fèi)slack支持：www.asterisk.org.cn

　　Freepbx/FreeSBC技術(shù)文檔： www.freepbx.org.cn

　　如何使用FreeSBC，qq技術(shù)分享群：334023047

　　關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的通信行業(yè)技術(shù)分享