《計算機網(wǎng)絡(luò)安全原理》第6章 IP與路由安全

本PPT是電子工業(yè)出版社出版的教材《計算機網(wǎng)絡(luò)安全原理》配套教學(xué)PPT（部分內(nèi)容的深度和廣度在教材的基礎(chǔ)上有所擴展），作者：吳禮發(fā)本PPT可能直接或間接采用了網(wǎng)上資源、公開學(xué)術(shù)報告中的部分PPT頁面、圖片、文字，引用時我們力求在該PPT的備注欄或標題欄中注明出處，如果有疏漏之處，敬請諒解。同時對被引用資源或報告的作者表示誠摯的謝意！本PPT可免費使用、修改，使用時請保留此頁。聲明第六章IP與路由安全內(nèi)容提綱IPsec2

IPv6協(xié)議及其安全性分析3路由安全4

IPv4協(xié)議及其安全性分析1IPv4安全性分析IPv4協(xié)議沒有認證機制：沒有消息源認證：源地址假冒沒有完整性認證：篡改IPv4安全性分析IPv4協(xié)議沒有認證機制：沒有消息源認證：源地址假冒沒有完整性認證：篡改IPv4安全性分析IPv4協(xié)議沒有認證機制：沒有消息源認證：源地址假冒沒有完整性認證：篡改IPv4安全性分析IPv4協(xié)議沒有認證機制：沒有消息源認證：源地址假冒沒有完整性認證：篡改IPv4沒有加密機制無機密性：監(jiān)聽應(yīng)用數(shù)據(jù)泄露拓撲等信息：網(wǎng)絡(luò)偵察無帶寬控制：DDoS攻擊IPv4內(nèi)容提綱IPsec2

IPv6協(xié)議及其安全性分析3路由安全4

IPv4協(xié)議及其安全性分析1IPsec

(IPSecurity)端到端的確保IP通信安全：認證、加密及密鑰管理為IPv6制定（必選），支持IPv4（可選）IPsecIPsec標準內(nèi)容IPsecIPSec安全體系A(chǔ)H協(xié)議ESP協(xié)議加密算法驗證算法DOI密鑰管理（IKE協(xié)議）RFC4301RFC4303RFC4302RFC5996IPsec標準內(nèi)容IPsecIPsec標準內(nèi)容IPsec通過允許系統(tǒng)選擇所需的安全協(xié)議（AH協(xié)議或ESP協(xié)議），決定服務(wù)所使用的加密或認證算法，提供任何服務(wù)需要的密鑰來提供IP級的安全服務(wù)。RFC4301中列出的安全服務(wù)包括：訪問控制、無連接完整性、數(shù)據(jù)源認證、拒絕重放包（部分順序完整性格式）、保密性（加密）以及限制流量保密性IPsec一、IPsec安全策略IPsec操作的基礎(chǔ)是應(yīng)用于每一個從源端到目的端傳輸?shù)腎P包上的安全策略。IPsec安全策略主要由兩個交互的數(shù)據(jù)庫，安全關(guān)聯(lián)數(shù)據(jù)庫（SecurityAssociationDatabase,SAD）和安全策略數(shù)據(jù)庫（SecurityPolicyDatabase,SPD)來確定安全策略IPsec操作的基礎(chǔ)是應(yīng)用于每一個從源端到目的端傳輸?shù)腎P包上的安全策略。安全策略IKEv2SPD安全策略數(shù)據(jù)庫SAD密鑰交換安全關(guān)聯(lián)數(shù)據(jù)庫IKE

SAIPsecv3SAD安全關(guān)聯(lián)數(shù)據(jù)庫IPsecv3IKEv2SPD安全策略數(shù)據(jù)庫IPsecSA對ESP保護數(shù)據(jù)IPsec安全體系安全關(guān)聯(lián)（SecurityAssociation,SA）一個SA：發(fā)送端和接收端之間的單向邏輯連接，為數(shù)據(jù)流提供安全服務(wù)；經(jīng)過同一SA的數(shù)據(jù)流會得到相同的安全服務(wù)，如AH或ESPSA對：雙向安全數(shù)據(jù)交換同時支持AH、ESP且雙向：需兩對SA安全關(guān)聯(lián)SA一個SA由以下參數(shù)確定安全參數(shù)索引（SecurityParametersIndex,SPI）：32位，，接收方根據(jù)SPI選擇合適的SA處理接收到的數(shù)據(jù)包IP目的地址：僅允許單播地址安全協(xié)議標識（SecurityProtocolIdentifier）：AH

/ESP安全關(guān)聯(lián)SASAD定義了所有SA相關(guān)的參數(shù)，每個SA：安全參數(shù)索引序列號計算器序列計數(shù)器溢出反重放窗口AH信息ESP信息安全關(guān)聯(lián)的生存期IPsec協(xié)議模式：：隧道、傳輸或通配符最大傳輸單元路徑（pathMTU）安全關(guān)聯(lián)SASAD定義了所有SA相關(guān)的參數(shù)，每個SA：安全關(guān)聯(lián)SA不同SA可以用多種方式組合以獲得理想的用戶配置。此外，IPsec對需要IPsec保護的流量和不需要IPsec保護的流量提供多種粒度的控制安全關(guān)聯(lián)SA安全策略（SecurityPolicy,SP）指定對IP數(shù)據(jù)包提供何種保護，并以何種方式實施保護主要根據(jù)源IP、目的IP、入數(shù)據(jù)還是出數(shù)據(jù)等來標識用戶設(shè)定自己的安全策略的粒度：IP地址，傳輸層協(xié)議，TCP/UDP端口號操作：Discard、Bypass、Protect安全策略SPSPD中的每一條SP包括：本地IP遠程IP下一層協(xié)議名稱本地或遠程端口安全策略SP基于SAD和SPD，IPsec對IP包的處理IP包處理過程

外向IP包（來自TCP或UDP）丟棄報文查詢SPD確定策略發(fā)現(xiàn)匹配丟棄查詢SAD保護網(wǎng)絡(luò)密鑰交換無匹配匹配處理(AH/ESP)通過IP傳輸報文通過無匹配外向(Outboud)IP包處理過程基于SAD和SPD，IPsec對IP包的處理IP包處理過程內(nèi)向(Inboud)IP包處理過程將報文傳輸?shù)缴蠈樱ㄈ鏣CP、UDP）查詢SPD丟棄

報文查詢SAD報文類型不通過處理(AH/ESP)匹配無匹配IPIPsec

內(nèi)向IP包（來自因特網(wǎng)）通過二、IPsec運行模式兩種模式：傳輸模式和隧道模式IPsec運行模式傳輸模式隧道模式傳輸模式和隧道模式比較三、AH協(xié)議學(xué)習(xí)AH和ESP要關(guān)注以下幾個問題:加密、認證的范圍（即對IP協(xié)議報文的哪些部分進行保護）傳輸模式與隧道模式在保護對象、提供的服務(wù)、性能等方面的差別AH、ESP的傳輸模式和隧道模式各自適用于什么樣的場景與NAT的兼容性問題AH協(xié)議AH協(xié)議功能：IP包的數(shù)據(jù)完整性、數(shù)據(jù)來源認證和抗重放攻擊服務(wù)完整性：采用HMAC算法：HMAC-MD5（必須）、HMAC-SHA1（必須）、HAMC-RIPEMD-160等抗重放：序列號AH協(xié)議AH首部AH協(xié)議下一個首部

認證數(shù)據(jù)（變長）載荷長度保留SPI

序列號

071531AH運行模式：傳輸模式AH協(xié)議IP首部（含選項字段）TCP首部（含選項字段）數(shù)據(jù)IP首部（含選項字段）TCP首部（含選項字段）數(shù)據(jù)AH首部認證區(qū)域（可變字段除外）（a）應(yīng)用AH之前（b）應(yīng)用AH（傳輸模式）之后AH運行模式：傳輸模式AH協(xié)議AH運行模式：隧道模式AH協(xié)議IP首部（含選項字段）TCP首部（含選項字段）數(shù)據(jù)IP首部（含選項字段）TCP首部（含選項字段）數(shù)據(jù)AH首部認證區(qū)域（可變字段除外）（a）應(yīng)用AH之前（b）應(yīng)用AH（隧道模式）之后新IP首部（含選項字段）AH運行模式：隧道模式AH協(xié)議抗重放攻擊：序列號+滑動窗口機制AH協(xié)議…NN+1N－

W接收到有效包時標記未接收到有效包時不標記固定窗口大小W若接收到右邊的有效包，則窗口前進完整性檢驗算法：在SA中指定AH協(xié)議完整性檢驗?zāi)男┳侄螀⑴c計算？如何處理IPv4和IPv6首部中的三種字段：不變字段，可變但可預(yù)測字段，可變不可預(yù)測字段？AH協(xié)議完整性檢驗值ICVIPv4首部三種字段：AH協(xié)議完整性檢驗值ICVIPv6基本首部三種字段：IPv6擴展首部三種字段：AH協(xié)議討論：AH傳輸模式和隧道模式的區(qū)別AH與NAT的兼容性問題AH協(xié)議四、ESP協(xié)議ESP協(xié)議功能：除了提供IP包的數(shù)據(jù)完整性、數(shù)據(jù)來源認證和抗重放攻擊服務(wù)，還提供數(shù)據(jù)包加密和數(shù)據(jù)流加密服務(wù)完整性：采用HMAC算法：HMAC-MD5（必須）、HMAC-SHA1（必須）、HAMC-RIPEMD-160，NULL（無認證）等；ESP認證的數(shù)據(jù)范圍要小于AH協(xié)議加密：對稱密碼，必須支持：DES-CBC和NULL算法（認證和加密不能同時為NULL）ESP協(xié)議ESP首部ESP協(xié)議填充長度

載荷數(shù)據(jù)（變長）填充（0～255字節(jié)）SPI

序列號

071531

認證數(shù)據(jù)（變長）

下一個首部ESP運行模式：傳輸模式ESP協(xié)議ESP運行模式：傳輸模式ESP協(xié)議ESP運行模式：傳輸模式ESP協(xié)議ESP運行模式：傳輸模式ESP協(xié)議ESP協(xié)議ESP運行模式：隧道模式ESP協(xié)議ESP運行模式：隧道模式ESP協(xié)議ESP運行模式：隧道模式ESP協(xié)議討論：ESP傳輸模式和隧道模式的區(qū)別ESP傳輸模式下：如果修改了IP包的首部，IPsec是否能檢測出來這種修改ESP與NAT的兼容性問題ESP與AH的區(qū)別ESP協(xié)議ESP傳輸模式與隧道模式對比隧道模式對整個IP包進行認證和加密，因此可以提供數(shù)據(jù)流加密服務(wù)，而傳輸模式由于IP包首部不被加密，因此無法提供數(shù)據(jù)流加密服務(wù)。但是，隧道模式由于增加了一個新IP首部，降低了鏈路的帶寬利用率。傳輸模式適合于保護支持ESP協(xié)議的主機之間的通信連接，而隧道模式則在包含防火墻或其它用于保護可信內(nèi)網(wǎng)不受外網(wǎng)攻擊的安全網(wǎng)關(guān)的配置中比較有效ESP協(xié)議與NAT兼容問題：AH與NAT不兼容，而ESP不對IP包首部（含選項字段）進行認證，因此不存在和NAT不兼容的問題。如果通信的任何一方具有私有地址或在安全網(wǎng)關(guān)后面，仍然可以用ESP來保護其安全，因為NAT網(wǎng)關(guān)或安全網(wǎng)關(guān)可以修改IP首部中的源／目的IP地址來確保雙方的通信不受影響ESP協(xié)議AH與ESP比較ESP協(xié)議ESP與AH比較五、網(wǎng)絡(luò)密鑰交換IPsec支持以下兩種密鑰管理方式：手動（manual）：管理員為每個系統(tǒng)手動配置所需密鑰，只適用于規(guī)模相對較小且結(jié)點配置相對穩(wěn)定的環(huán)境自動（automated）：系統(tǒng)通過IKE（InternetKeyExchange）協(xié)議自動為SA創(chuàng)建密鑰，適用于大型分布式系統(tǒng)中的密鑰管理IPsec密鑰管理IKEv1：默認的IPsec自動型密鑰管理協(xié)議是ISAKMP/Oakley，包括：互聯(lián)網(wǎng)安全關(guān)聯(lián)和密鑰管理協(xié)議（InternetSecurityAssociationandKeyManagementProtocol,ISAKMP）Oakley密鑰確定協(xié)議（OakleyKeyDeterminationProtocol），基于Diffie-Hellman算法的密鑰交換協(xié)議IKE在IKEv2中，不再使用術(shù)語ISAKMP和Oakley，并且對ISAKMP和Oakley的使用方式也發(fā)生了變化，但是基本功能還是相同的。后面介紹的內(nèi)容是IKEv2IKEDiffie-Hellman回顧兩個優(yōu)點：①僅當(dāng)需要時才生成密鑰，減小了將密鑰存儲很長一段時間而致使遭受攻擊的機會；②除對全局參數(shù)的約定外，密鑰交換不需要事先存在的基礎(chǔ)設(shè)施兩個缺點：①沒有提供雙方身份的任何信息，因此易受中間人攻擊；②算法是計算密集型的，容易遭受阻塞性攻擊密鑰確定協(xié)議IKE對Diffie-Hellman的改進：采用Cookie機制來防止擁塞攻擊；允許雙方協(xié)商得到一個組（group），相錄于Diffie-Hellman密鑰交換的全局參數(shù)；使用現(xiàn)時值來阻止重放攻擊；允許交換Diffie-Hellman的公鑰值；對Diffie-Hellman交換進行身份認證，以阻止中間人攻擊密鑰確定協(xié)議Cookie交換（Cookieexchange）要求各方在初始消息中發(fā)送一個偽隨機數(shù)Cookie，并要求對方確認。此確認必須在Diffie-Hellman密鑰交換的第一條消息中重復(fù)。如果源地址被偽造，則攻擊者就不會收到應(yīng)答。這樣，攻擊者僅能讓用戶產(chǎn)生應(yīng)答而不會進行Diffie-Hellman計算Cookie機制ISAKMP規(guī)定Cookie的產(chǎn)生必須滿足：Cookie必須依賴于特定的通信方，從而防止攻擊者得到一個正在使用真正的IP地址和UDP端口的Cookie時，也無法用該Cookie向目標主機發(fā)送大量的來自隨機選取的IP地址和端口號的請求來浪費目標主機的資源Cookie機制ISAKMP規(guī)定Cookie的產(chǎn)生必須滿足：除了發(fā)起實體以外的任何實體都不可能產(chǎn)生被它承認的Cookie。這就意味著發(fā)起實體在產(chǎn)生和驗證Cookie時，要使用本地的秘密信息，而且根據(jù)任何特定的Cookie都不可能推斷出該秘密信息Cookie機制ISAKMP規(guī)定Cookie的產(chǎn)生必須滿足：Cookie的產(chǎn)生和驗證必須盡可能地快速完成，從而阻止企圖通過占用處理器資源的阻塞攻擊一種產(chǎn)生Cookie的方法是對以下信息進行HASH運算后，取前64位：

源IP地址+目的IP地址+UDP源端口+UDP目的端口

+

隨機數(shù)+當(dāng)前日期+當(dāng)前時間Cookie機制使用不同的組（group）進行Diffie-Hellman密鑰交換。每個組包含兩個全局參數(shù)的定義和算法標識。當(dāng)前的規(guī)范包括如下幾個組：GroupIKE使用現(xiàn)時值（nonce）來反重放攻擊。每個現(xiàn)時值是本地產(chǎn)生的偽隨機數(shù)，在應(yīng)答中出現(xiàn)，并在交換時被加密以保護它的可用性防重放攻擊IKE使用三種不同的身份認證方法：數(shù)字簽名：用雙方均可以得到的散列值進行簽名來進行身份認證，每一方都用自己的私鑰加密散列值。散列值使用重要的身份參數(shù)（如用戶ID、現(xiàn)時值）來生成。公鑰加密：利用對方公鑰對用戶身份參數(shù)（如用戶ID、現(xiàn)時值）加密來進行身份認證。對稱密鑰加密：通過帶外機制得到密鑰，并且該密鑰對交換的身份參數(shù)進行加密。身份認證IKEv1密鑰交換過程密鑰交換過程發(fā)送IKE安全提議接受提議發(fā)送密鑰生成信息生成密鑰發(fā)送身份和驗證數(shù)據(jù)身份驗證和交換過程驗證查找匹配的提議發(fā)送確認的IKE安全提議生成密鑰發(fā)送密鑰生成消息身份驗證和交換過程驗證發(fā)送身份和驗證數(shù)據(jù)協(xié)商發(fā)起方協(xié)商響應(yīng)方①②③④⑤⑥發(fā)送IKE安全提議、密鑰生成和身份信息查找匹配的提議算法，生成密鑰和身份驗證協(xié)商發(fā)起方協(xié)商響應(yīng)方①接受提議和生成密鑰發(fā)送密鑰生成信息、身份信息和驗證數(shù)據(jù)②發(fā)送驗證數(shù)據(jù)交換過程驗證③（a）主模式（b）積極模式IKEv2密鑰交換過程密鑰交換過程密鑰交換過程發(fā)送IKE安全提議接受參數(shù)發(fā)送身份信息身份驗證和交換過程驗證查找匹配的提議發(fā)送確認的IKE安全參數(shù)身份驗證和交換過程驗證發(fā)送身份信息協(xié)商發(fā)起方協(xié)商響應(yīng)方①②③④發(fā)送控制信息根據(jù)控制信息進行相應(yīng)操作協(xié)商發(fā)起方協(xié)商響應(yīng)方①接受信息回應(yīng)控制信息②（a）初始交換過程（b）信息交換過程IKE協(xié)議定義了建立、協(xié)商、修改和刪除安全關(guān)聯(lián)的過程和報文格式。IKE報文由首部和一個或多個載荷組成，并包含在傳輸協(xié)議（規(guī)范要求在實現(xiàn)時必須支持UDP協(xié)議）IKE消息格式IKE消息格式

發(fā)起方SPI

應(yīng)答方SPI

071531消息ID鄰接載荷主版本次版本交換類型標記23長度

07

81531鄰接載荷C保留載荷長度(a)

IKE首部(b)一般載荷首部載荷類型IKE消息格式載荷類型IKE消息格式IPsecv3和IKEv3協(xié)議依賴于多種密碼算法。每種應(yīng)用可能需要使用多種密碼算法，而每種密碼算法也有很多參數(shù)。為了提高互操作性，IETF通過RFC4308和RFC4869定義了各種應(yīng)用的推薦密碼算法和參數(shù)IKE密碼組件RFC4308IKE密碼組件RFC4869IKE密碼組件同RFC4308一樣，使用的密鑰算法包括：加密：對于ESP，認證加密使用128位或256位的AES密碼的GCM模式；對于IKE加密，與VPN密碼組一樣，使用密碼分組鏈（CBC）模式；消息認證：對于ESP，如果只認證，則用GMAC；對于IKE，消息認證由使用SHA-3的HMAC來提供。偽隨機數(shù)：同VPN密碼組一樣，IKEv2通過對重復(fù)使用消息認證的MAC來產(chǎn)生偽隨機數(shù)。IKE密碼組件對于Diffie-Hellman算法，規(guī)定使用橢圓曲線群上對素數(shù)求模。對于認證，也使用了橢圓曲線上的數(shù)字簽名。早期的IKEv2文檔使用的是基于RSA的數(shù)字簽名。與RSA相比，使用ECC可以用更短的密鑰就能達到相當(dāng)或更高的安全強度IKE密碼組件IKE交互過程抓包分析主模式第1條報文（6->4）IKE交互過程抓包分析主模式第2條報文（4->6）IKE交互過程抓包分析主模式的第3條報文（6->4）：密鑰交換（KeyExchange）IKE交互過程抓包分析主模式第4條報文（4->6）IKE交互過程抓包分析主模式的第5條報文（6->4）IKE交互過程抓包分析主模式第6條報文（4->6）IKE交互過程抓包分析快速模式第1條報文（6->4）IKE交互過程抓包分析快速模式第2條報文（4->6）IKE交互過程抓包分析快速模式第3條報文（6->4）IKE交互過程抓包分析快速模式第4條報文（4->6）IKE交互過程抓包分析六、SA組合為什么要組合SA？單個SA只能實現(xiàn)AH協(xié)議或ESP協(xié)議，而不能同時實現(xiàn)這兩者。但在實際應(yīng)用中，一些流量需要同時調(diào)用由AH和ESP提供的服務(wù)，某些流量可能需要主機間的IPsec服務(wù)的同時還需要在安全網(wǎng)關(guān)（如防火墻）間得到IPsec提供的服務(wù)。在這些情況下，同一個流量可能需要多個SA才能獲得想要的IPsec服務(wù)SA組合提供特定IPsec服務(wù)集而組合在一起的SA系列稱為“安全關(guān)聯(lián)束（SecurityAssociationBundle）”安全關(guān)聯(lián)束中的SA可以在不同節(jié)點上終止，也可在同一個節(jié)點上終止兩種方式將多個SA組合成安全關(guān)聯(lián)束：傳輸鄰接（transportadjacency）與隧道迭代（IteratedTunneling）SA組合在組合多個SA形成安全關(guān)聯(lián)束時，需要考慮認證和加密的順序問題先加密后認證先認證后加密SA組合SA組合SA組合SA組合SA組合SA組合七、IPsec的應(yīng)用IPsec在IP層對所有流量進行加密和/或認證，因此能夠保護各種基于IP的應(yīng)用終端用戶通過互聯(lián)網(wǎng)實現(xiàn)安全的遠程訪問分支機構(gòu)通過互聯(lián)網(wǎng)構(gòu)建一個安全的虛擬專用網(wǎng)絡(luò)與合作者建立企業(yè)間聯(lián)網(wǎng)和企業(yè)內(nèi)聯(lián)網(wǎng)接入將IPsec應(yīng)用于上述場景的實質(zhì)就是構(gòu)建基于IPsec的虛擬專用網(wǎng)（VirtualPrivateNetwork,VPN）IPsec的應(yīng)用IPsec應(yīng)用IPsec的應(yīng)用IPsec的應(yīng)用利用IPsec實現(xiàn)安全通信有以下優(yōu)點：當(dāng)在路由器或防火墻等邊界設(shè)備中啟用IPsec時，認證和加密過程均在路由器或防火墻中進行，而其后面的公司或者工作組內(nèi)部的通信不會引起與安全相關(guān)的開銷IPsec位于傳輸層之下，所以對應(yīng)用是透明的IPsec對終端用戶是透明的若有必要，IPsec給個人用戶提供安全性IPsec的應(yīng)用內(nèi)容提綱IPsec2

IPv6協(xié)議及其安全性分析3路由安全4

IPv4協(xié)議及其安全性分析1IPv6IPv6從IPv4向IPv6過渡采用逐步演進的方法，IETF推薦的過渡方案主要有：雙協(xié)議棧(dualstack)隧道(tunneling)網(wǎng)絡(luò)地址轉(zhuǎn)換IPv6IPv6部署情況（APNIC，2019.6）：IPv6IPv6通過IPsec來保證IP層的傳輸安全，提高了網(wǎng)絡(luò)傳輸?shù)谋Ｃ苄?、完整性、可控性和抗否認性IPv6安全安全問題IPv4向IPv6過渡技術(shù)的安全風(fēng)險無狀態(tài)地址自動配置的安全風(fēng)險IPv6中PKI管理系統(tǒng)的安全風(fēng)險IPv6編址機制的隱患IPv6安全安全問題IPv6的安全機制對網(wǎng)絡(luò)安全體系的挑戰(zhàn)所帶來的安全風(fēng)險：正在服役的IDS/IPS/WAF不一定支持，于是可以暢行無阻IPv6安全IPv6安全內(nèi)容提綱IPsec2

IPv6協(xié)議及其安全性分析3路由安全4

IPv4協(xié)議及其安全性分析1路由協(xié)議R1H1H2內(nèi)部網(wǎng)關(guān)協(xié)議IGP（例如，RIP）自治系統(tǒng)A自治系統(tǒng)B自治系統(tǒng)CIGPIGPIGPIGPIGPIGPIGPIGPIGPIGPIGPIGPEGPEGPEGP內(nèi)部網(wǎng)關(guān)協(xié)議IGP（例如，OSPF）外部網(wǎng)關(guān)協(xié)議EGP（例如，BGP-4）IGPR3R2路由協(xié)議的脆弱性：協(xié)議設(shè)計上的問題，即協(xié)議機制上的不完善（如認證機制、防環(huán)路機制、路由度量機制等）導(dǎo)致的安全問題協(xié)議實現(xiàn)上的問題，即許多協(xié)議規(guī)范中的協(xié)議行為在實際網(wǎng)絡(luò)環(huán)境中并沒有實現(xiàn)或做的不夠完善而導(dǎo)致的安全問題管理配置產(chǎn)生的安全問題，很多網(wǎng)絡(luò)管理員在配置路由協(xié)議器時，沒有或錯誤地配置相應(yīng)的加密和認證機制，帶來了很多安全風(fēng)險路由協(xié)議路由協(xié)議的安全保障：IPv4網(wǎng)絡(luò)中，路由安全主要依靠路由協(xié)議本身提供的安全機制來保障，如認證和加密機制。而在IPv6網(wǎng)絡(luò)中，路由安全則主要依靠前面介紹的IPsec協(xié)議提供的認證和加密服務(wù)來保障路由協(xié)議一、RIP協(xié)議及其安全性分析RIP一種內(nèi)部網(wǎng)關(guān)協(xié)議分布式的基于距離向量的路由選擇三個版本：RIPv1（RFC1058）、RIPv2（RFC1723）和RIPng。RIPv2新增了變長子網(wǎng)掩碼的功能，支持無類域間路由、支持組播、支持認證功能，同時對RIP路由器具有后向兼容性。RIPng主要用于IPv6網(wǎng)絡(luò)RIP協(xié)議路由策略和哪些路由器交換信息？僅和相鄰路由器交換信息交換什么信息？當(dāng)前本路由器所知道的全部信息，即自己的路由表在什么時候交換信息？按固定的時間間隔交換路由信息RIP協(xié)議協(xié)議報文兩類報文：更新報文和請求報文。更新報文用于路由表的分發(fā)，請求報文用于路由器發(fā)現(xiàn)網(wǎng)上其它運行RIP協(xié)議的路由器。RIP協(xié)議報文使用UDP協(xié)議進行傳送RIP協(xié)議RIPv1不支持認證，且使用不可靠的UDP協(xié)議作為傳輸協(xié)議，安全性較差。如果在沒有認證保護的情況下，攻擊者可以輕易偽造RIP路由更新信息，并向鄰居路由器發(fā)送，偽造內(nèi)容為目的網(wǎng)絡(luò)地址、子網(wǎng)掩碼地址與下一條地址，經(jīng)過若干輪的路由更新，網(wǎng)絡(luò)通信將面臨癱瘓的風(fēng)險RIP協(xié)議安全RIPv2在其報文格式中增加了一個可以設(shè)置16個字符的認證選項字段，支持明文認證和MD5加密認證兩種認證方式，字段值分別是16個字符的明文密碼字符串或者MD5簽名。RIP認證以單向為主，R2發(fā)送出的路由被R1授受，反之無法接受。另外，RIPv2協(xié)議路由更新需要配置統(tǒng)一的密碼明文認證的安全性仍然較弱RIP協(xié)議安全對于不安全的RIP協(xié)議，中小型網(wǎng)絡(luò)通?？刹扇〉姆婪洞胧┌ǎ孩賹⒙酚善鞯哪承┙涌谂渲脼楸粍咏涌冢渲脼楸粍咏涌诤?，該接口停止向它所在的網(wǎng)絡(luò)廣播路由更新報文，但是允許它接收來自其他路由器的更新報文；②配置路由器的訪問控制列表，只允許某些源IP地址的路由更新報文進入列表RIP協(xié)議安全RIPng為IPv6環(huán)境下運行的RIP協(xié)議，采用和RIPv2完全不同的安全機制。RIPng使用和RIPv1相似的報文格式，充分利用IPv6中IPsec提供的安全機制，包括AH認證、ESP加密以及偽報頭校驗等，保證了RIPng路由協(xié)議交換路由信息的安全。RIP協(xié)議安全二、OSPF協(xié)議及其安全性分析路由策略和哪些路由器交換信息？向本自治系統(tǒng)中所有路由器發(fā)送信息，通常洪泛法交換什么信息？與本路由器相鄰的所有路由器的鏈路狀態(tài)，只是路由器所知部分信息表在什么時候交換信息？當(dāng)鏈路狀態(tài)發(fā)生變化時，路由器向所有路由器發(fā)送此信息；定期同步鏈路狀態(tài)OSPF協(xié)議OSPF使用分布式鏈路狀態(tài)協(xié)議(linkstateprotocol)由于OSPF依靠各路由器之間頻繁地交換鏈路狀態(tài)信息，因此所有的路由器都能建立一個鏈路狀態(tài)數(shù)據(jù)庫（LinkStateDatabase,LSDB），這個數(shù)據(jù)庫實際上就是全網(wǎng)拓撲結(jié)構(gòu)圖每一個路由器使用LSDB中的數(shù)據(jù)，構(gòu)造自己的路由表（例如，使用Dijkstra算法）OSPF協(xié)議OSPF協(xié)議報文類型1，問候(Hello)報文，用來發(fā)現(xiàn)和維持鄰站的可達性類型2，數(shù)據(jù)庫描述(DatabaseDescription)報文，向鄰站給出自己的鏈路狀態(tài)數(shù)據(jù)庫中的所有鏈路狀態(tài)項目的摘要信息類型3，鏈路狀態(tài)請求(LinkStateRequest,LSR)報文，向?qū)Ψ秸埱蟀l(fā)送某些鏈路狀態(tài)項目的詳細信息OSPF協(xié)議OSPF協(xié)議報文類型4，鏈路狀態(tài)更新(LinkStateUpdate,LSU)報文，用洪泛法向全網(wǎng)發(fā)送更新的鏈路狀態(tài)類型5，鏈路狀態(tài)確認(LinkStateAcknowledgment,LSAck)報文，對鏈路更新報文的確認OSPF協(xié)議OSPF不用UDP而是直接用IP數(shù)據(jù)報傳送（其IP數(shù)據(jù)報首部的協(xié)議字段值為89）其報文OSPF協(xié)議OSPF協(xié)議可以對接口、區(qū)域、虛鏈路進行認證接口認證要求在兩個路由器之間必須配置相同的認證口令。區(qū)域認證是指所有屬于該區(qū)域的接口都要啟用認證，因為OSPF以接口作為區(qū)域分界。區(qū)域認證接口與鄰接路由器建立鄰居需要有相同的認證方式與口令，但在同一區(qū)域中不同網(wǎng)絡(luò)類型可以有不同的認證方式和認證口令。配置區(qū)域認證的接口可以與配置接口認證的接口互相認證，使用MD5認證口令I(lǐng)D要相同OSPF安全OSPF認證方式空認證（NULL，即不認證，類型為0），默認認證方式簡單口令認證（類型為1）MD5加密身份認證（類型為2）OSPF報文格式中有二個與認證有關(guān)的字段：認證類型（AuType,16位）、認證數(shù)據(jù)（Authentication,64位）OSPF安全同RIPng一樣，OSPFv3協(xié)議自身不再有加密認證機制，取而代之的是通過IPv6的IPsec協(xié)議來保證安全性，路由協(xié)議必須運行在支持IPsec的路由器上。IPsec可確保路由器報文來自于授權(quán)的路由器；重定向報文來自于被發(fā)送給初始包的路由器；路由更新未被偽造OSPF安全OSPF攻擊方式最大年齡（MaxAgeattack）攻擊序列號加1（Sequence++）攻擊最大序列號攻擊重放攻擊篡改攻擊OSPF安全三、BGP協(xié)