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差不多，組播通訊過程也更復雜，如組成員的加入離開時的安全問題，組內攻擊者的問題等。深入瞭解的東西還有很多，上面只是簡單進行了說明，歡迎批評指正。