IPSec组播概要

　　IPSec作为主流IP安全协议之一，在单播环境下，特别是在VPN场景中应用广泛。但是在组播环境貌似看到的不多，通过RFC4301了解到IPSec首先是支持组播的，即通过手动配置的方式可以实现组播包加密的功能，简单来说就是在SPD手动添加一个策略，例如目标IP地址为224.11.11.11的组播包，通过SA1加密，SA1中又手动配置了组加密密钥、组校验密钥等参数，这样假如有10个组成员，就有10个相同的SA1，共同使用相同的组加密密钥、组校验密钥等，从而实现了组播包的安全传输。这样做的弊端也是显而易见的，安全性低，没有SA的更新，密钥容易泄露。因此RFC4301中针对组播又引入了RFC3740，RFC3740其实是一个针对大型组播的安全框架文档，并不是专门针对IPSec，而RFC5374才是正真的IPSec对组播的扩展说明文档，对这几个文档稍微看来一下，IPSec组播的结论大致如下：

1. IPSec与组播的关系

应该是组播的概念大于IPSec，即先有组播的环境，靠IPSec加密组播包，而不是通过IPSec实现组播的功能。在RFC3740中明确说明了安全组播与IP组播是独立的关系，即加入安全组是由一个安全设备管理（GC）的，而加入IP组是由组播路由器管理的，这两者是独立的。这也就意味着一个发送者如果没有加入安全组，他其实也能发送组播包，只不过没有加密，或者被IPSec网关丢弃了，但并不影响他加IP组和收发IP组播包的功能。加入安全组后，就有组密钥了，IP组播包被加密传输，其路由过程其实还是由组播路由协议和组播路由器完成的，IPSec和组播安全框架并不负责组播包的路由。如果原来的通信节点不能使用组播通信，那么使用IPSec组播后，这些节点依然不能使用组播通信，不像单播，使用隧道封装可以使原来无法直接通信的节点通过隧道连接起来。

1. IPSec组播与单播的关系

IPSec组播与单播从通信过程上说是没有关系的，也就是IPSec组播通信时可以完全不用实现IPSec单播通信的过程，只用IPSec保护组播通信，不需要实现IPSec的单播通信过程。当然，也不可能是一点关系都没有，SAD、SPD、PAD这些概念要扩展到组播上，形成组播通信相关定义。

1. 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功能。

1. 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更新，只不过过程更复杂，更新过程和方法是由组播密钥管理协议定义。

1. 数据SA的使用

组播中可以有多个发送者，此时对于组策略需要定义，是所有发送者使用同一个SA，还是每个发送者使用各自的SA，这两种方案会影响到部分功能。

1. 组播的隧道封装

IPSec隧道封装组播时，外层IP头的目标地址必须和内层IP头的一样，也就是说必须是组播地址，外层IP头的源地址一般情况下也必须和内层IP头的一样，因为要通过组播路由器的RPF检测。在GSAD中有相关参数标识是否需要源地址要一样。

1. 组播认证时机

单播中IPSec是通过SPD触发IKE的注册过程，组播也一样，通过GSPD触发组播密钥管理协议的认证过程，IPSec设备通过检测特定的组播数据包、组播协议消息（IGMP）等向GCKS认证。SPD中的单播是双向的，即源IP目标IP可以互换从而完成IKE过程，但是组播地址不可能是源，所以GSPD中添加仅源、仅目标的选项，同时GSPD添加对于入栈组播ESP包可以继续路由到其他设备的选项。

1. 组播数据转发

如果IPSec是网关设备，则他负责下面组成员的认证过程和转发组播数据包。

1. 抗重放

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差不多，组播通信过程也更复杂，如组成员的加入离开时的安全问题，组内攻击者的问题等。深入了解的东西还有很多，上面只是简单进行了说明，欢迎批评指正。