IPSec組播概要
- 2021 年 8 月 10 日
- 筆記
IPSec作為主流IP安全協議之一，在單播環境下，特別是在VPN場景中應用廣泛。但是在組播環境貌似看到的不多，通過RFC4301了解到IPSec首先是支援組播的，即通過手動配置的方式可以實現組播包加密的功能，簡單來說就是在SPD手動添加一個策略，例如目標IP地址為224.11.11.11的組播包，通過SA1加密，SA1中又手動配置了組加密密鑰、組校驗密鑰等參數，這樣假如有10個組成員，就有10個相同的SA1，共同使用相同的組加密密鑰、組校驗密鑰等，從而實現了組播包的安全傳輸。這樣做的弊端也是顯而易見的，安全性低，沒有SA的更新，密鑰容易泄露。因此RFC4301中針對組播又引入了RFC3740，RFC3740其實是一個針對大型組播的安全框架文檔，並不是專門針對IPSec，而RFC5374才是正真的IPSec對組播的擴展說明文檔，對這幾個文檔稍微看來一下，IPSec組播的結論大致如下：
- IPSec與組播的關係
應該是組播的概念大於IPSec，即先有組播的環境，靠IPSec加密組播包，而不是通過IPSec實現組播的功能。在RFC3740中明確說明了安全組播與IP組播是獨立的關係，即加入安全組是由一個安全設備管理（GC）的，而加入IP組是由組播路由器管理的，這兩者是獨立的。這也就意味著一個發送者如果沒有加入安全組，他其實也能發送組播包，只不過沒有加密，或者被IPSec網關丟棄了，但並不影響他加IP組和收發IP組播包的功能。加入安全組後，就有組密鑰了，IP組播包被加密傳輸，其路由過程其實還是由組播路由協議和組播路由器完成的，IPSec和組播安全框架並不負責組播包的路由。如果原來的通訊節點不能使用組播通訊，那麼使用IPSec組播後，這些節點依然不能使用組播通訊，不像單播，使用隧道封裝可以使原來無法直接通訊的節點通過隧道連接起來。
- IPSec組播與單播的關係
IPSec組播與單播從通訊過程上說是沒有關係的，也就是IPSec組播通訊時可以完全不用實現IPSec單播通訊的過程，只用IPSec保護組播通訊，不需要實現IPSec的單播通訊過程。當然，也不可能是一點關係都沒有，SAD、SPD、PAD這些概念要擴展到組播上，形成組播通訊相關定義。
- GCKS
GCKS是RFC3740的概念，定義如下「The Group Controller and Key Server (GCKS) represent both the entity and functions relating to the issuance and management of cryptographic keys used by a multicast group. The GCKS also conducts user-authentication and authorization checks on the candidate members of the multicast group.」由此可見，GCKS主要負責組成員、組策略和組密鑰的管理，它並不屬於組成員，因此也不負責組播包的加密和轉發。GC和KS可以在不同的實體上，為了簡單部署，就把GCKS統一在一個實體上了。GCKS類似於一個伺服器，部署在組播網路中，唯一的要求是發送者和接收者都能訪問到他，以便執行認證過程，具體的組播數據包可以不經過GCKS。GCKS可以不具備IPSec功能。
- SA
SA是單播中重要的概念，組播SA相當於對單播SA進行了擴展，如上圖所示，組播SA可以分為三類：
註冊SA：由組播密鑰管理協議產生，發送者和接收者是IPSec設備（IPSec設備指具備IPSec定義SAD、SPD、PAD等功能，能進行AH/ESP的封裝），發送者和接收者要加入安全組時都要到GCKS進行認證，認證的協議是組播密鑰管理協議，有專門的RFC可以參考，不是單播的IKE。需要說明的是GCKS並不一定是IPSec設備，GCKS只要和組成員能跑組播密鑰管理協議就行了，它不負責組播包的轉發。發送者、接收者和GCKS通過組播密鑰管理協議進行認證，認證成功後組播密鑰管理協議會產生一個註冊SA，注意這個註冊SA和單播的IKE SA沒有關係。這個註冊SA就是一個安全通道，由組播密鑰管理協議定義，GCKS通過這個SA下發更新SA參數和數據SA參數到認證成功的組成員。這個SA是單播雙向的安全通道。
數據SA：這個就是加密組播包的SA，也就是IPSec ESP加密組播包時使用的SA。他由GCKS產生，發送者通過這個SA加密組播包，就是ESP封裝，完了接收者解封即可。注意GCKS自己不使用數據SA，組播包也不需要經過GCKS，因為GCKS是一個安全設備，不是組播路由設備，簡單的可理解為把GCKS從網路中拿掉，原來的IP組播通訊絲毫不受影響。
更新SA：這個SA參數是由GCKS在認證完成後通過註冊SA下方的，是由GCKS到組成員的一個組播，作用就是更新數據SA，類似與單播IPSec的SA更新，只不過過程更複雜，更新過程和方法是由組播密鑰管理協議定義。
- 數據SA的使用
組播中可以有多個發送者，此時對於組策略需要定義，是所有發送者使用同一個SA，還是每個發送者使用各自的SA，這兩種方案會影響到部分功能。
- 組播的隧道封裝
IPSec隧道封裝組播時，外層IP頭的目標地址必須和內層IP頭的一樣，也就是說必須是組播地址，外層IP頭的源地址一般情況下也必須和內層IP頭的一樣，因為要通過組播路由器的RPF檢測。在GSAD中有相關參數標識是否需要源地址要一樣。
- 組播認證時機
單播中IPSec是通過SPD觸發IKE的註冊過程，組播也一樣，通過GSPD觸發組播密鑰管理協議的認證過程，IPSec設備通過檢測特定的組播數據包、組播協議消息（IGMP）等向GCKS認證。SPD中的單播是雙向的，即源IP目標IP可以互換從而完成IKE過程，但是組播地址不可能是源，所以GSPD中添加僅源、僅目標的選項，同時GSPD添加對於入棧組播ESP包可以繼續路由到其他設備的選項。
- 組播數據轉發
如果IPSec是網關設備，則他負責下面組成員的認證過程和轉發組播數據包。
- 抗重放
IPSec只能對小規模的組實現抗重放，與單播的原理一樣，但是對大規模任意源的組的抗重放則不適用，因為一個抗重放狀態就是一個SA狀態，如果組的數量上百萬，對於每個接收方，可能就需要維護上百萬個SA，這是不現實的。
10. 源認證
單播的源認證通過MAC密鑰完成，組播中MAC密鑰是組共享的，是作為組認證的密鑰，無法認證到源，因此組播源認證一般通過數字簽名演算法和TESLA演算法完成，不過這些演算法都有可能引起DDoS攻擊。
11. SPI衝突
組播IPSec過程可以說和單播IPSec過程是獨立的，組播通過組播密鑰管理協議完成，單播通過IKE完成，組播SPI通過GCKS產生，單播通過兩端IKE協商產生，因此SPI可能會衝突，所以組播SPI的入棧查找必須有目標和源IP地址。
12. SA更新
IPSec單播中有SA更新過程，組播也有，通過組播密鑰管理協議在認證時產生的更新SA完成，更新SA就是一個由GCKS到組成員的組播安全通道，他專門負責更新IPSec SA，也就是在更新SA的安全通道中下發新IPSec SA的參數，它本身可能不更新。同時組播更新可能受延遲的影響，為保證組成員同步更新，GSAD有專門的參數保證SA更新時的同步。
組播安全相對與單播安全可能更複雜，一個組播密鑰管理協議複雜度就和單播IKE差不多，組播通訊過程也更複雜，如組成員的加入離開時的安全問題，組內攻擊者的問題等。深入了解的東西還有很多，上面只是簡單進行了說明，歡迎批評指正。
