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

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

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

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

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

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

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

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

　　來(lái)自于Jusin Uberti （Google） 測試結果

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　應用/屏幕關(guān)系的訪(fǎng)問(wèn)許可。確保對端用戶(hù)是安全用戶(hù)，可以確保本地信息不會(huì )被泄漏。

　　確保本地IP地址和隱私不會(huì )被輕易訪(fǎng)問(wèn)獲取。

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

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

　　WebRTC Security Architecture

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

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

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

　　參考資料：

　　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完整中文用戶(hù)手冊詳解及免費slack支持：www.asterisk.org.cn

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

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

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