SPD、SAD、Traffic Selector和IKE收发数据包的处理过程

在IPSec的安全体系中，有两个很重要的数据库。一个是SPD - Security Policy Database；另一个是SAD - Security Association Database。顾名思义，SPD中定义了若干策略，说明对于各个IP数据流应当做出怎样的处理，是透传、丢弃，还是执行IPSec加解密。SAD则负责保存已经建立的SA相关信息，比如SA的各种参数，如加密算法、认证算法、生存时间等。

下面以一个例子为线索，说明它们之间的关联关系。网络结构如下：

描述：

设备10.0.68.5在Spoke-2-East的局域网10.0.68.0/24内部。它想要跟另一台位于VPN-GW1-EAST的局域网10.1.1.0/24中的设备10.1.1.5进行通信。

通信过程如下：

1. 当一个IP包从10.0.68.5发往目的地址10.1.1.5，数据包首先通过局域网设备到达路由器SPOKE-2-EAST。它上面的配置信息确定了通过网络接口serial0/0来讲此数据包路由到Internet。

2. 在数据包被路由出去之前，路由器会首先检查serial0/0接口的SPD。

SPD的内容如下：

研究一下这个SPD。其中每一行代表一个SPD Entry。Local IP / Local Port / Remote IP / Remote Port / Protocol都是traffic selector。Action表示对满足条件的IP流执行怎样的策略，是DISCARD / BYPASS，或者是应用IPSEC加密？ Policy表示，一旦采用IPSec加密，那么在协商SA时应当建议怎样的算法等等。目前SA entry都为空，因为还没有建立任何SA。

再仔细观察，可以发现每个Traffic Selector都有一个sharing? 这表示什么意思呢？RFC4301规定，每个Selector都包含一个PFP flag（Populate from packet）。它可以设置成True或者False。当此标志被设定为True，则表示在创建一个SA时使用packet中的Traffic selector payload来作为selector，否则使用SPD中的Selector。举一个具体的例子，比如，现在10.0.68.5想要想10.1.1.5发送http请求。根据SPD，它满足最上面的index为9的规则。由于SA不存在，所以在IKE_AUTH交换后将生成必要的SA。在生成新的SA时，发现规则9中的Local IP / Remote IP的PFP flag都为false，也就是说允许SA sharing。那么将利用规则9中的Traffic Selector来生成一个共享SA，所有从10.0.68.5到10.1.1.0/24网段的TCP流都将使用这个新生成的SA来加密。相反的，如果PFP为True，也就是不允许SA sharing，那么在生成SA时将使用IKE_AUTH消息中的Traffic Selector Payload中协商好的Traffic Selector。假如Traffic Selector Payload中指定Tsi为10.0.68.5，而Tsr为10.1.1.5，那么新生成的SA只对10.0.68.8和10.1.1.5之间的TCP数据流提供IPSec保护。

稍作总结，PFP flag描述了在生成一个SA时是使用SPD Entry中的Traffic Selector还是使用IKE_AUTH / IKE_CREATE_CHILD消息的Traffic Selector Payload中的Traffic Selector。如果使用前者，意味着SPD中的每条规则将只对应一对SA，如此处的从10.0.68.5与10.1.1.0/24网段的一对SA。而如果使用后者，那么生成的新SA可能只是对应着SPD Entry中描述的一个子集，如此处，可能10.0.68.5和10.1.1.5之间就有一对专用SA，而10.0.68.5再与10.1.1.8通信可能会建立起另外一对SA。这样，一个SPD Entry所对应的Policy可能生成多个SA。

在这里，我们发现在SPD Entry中有一对SAD Entry的指针。但是，其实在RFC4301中对SPD Entry结构的定义中，并没有要求在SPD Entry中包含SAD Entry的指针。此处的SPD表只是实现的一种方式。在具体实现中，完全可以没有这个指针。当从SPD中了解到需要对一个IP流采用的策略后，再到SAD中查找是否有对应的SA。在SPD中包含SAD Entry的指针可以提高效率。但是如果一个SPD Entry对应多个SA，此处就需要有一种机制从多个SA Entry指针中找到最匹配的一个。

SAD:

SPD是一个策略数据库，描述了对每一个IP数据报应该采取的策略，是透传、丢弃或者做IPSec加解密。同时，它还为SA的建立提供协商用的参数，比如，加密套件，生存时间等。新生成的SA则被插入到SAD中。每当发出或者接收到一个数据包的时候，如果对它的策略是IPSec，那么就要去SAD中找到对应的SA，根据SA中提供的参数，对数据包进行加解密、生成校验和、封装成AH/ESP等操作。

3. 到目前为止，我们已经从SPD和SAD中了解到负责此IP数据报的SA还没有建立。Spoke-2-East将首先向远端的VPN-GW1-East发起第一个IKE的协商请求。协商成功后，两个安全网关之间将为从10.0.68.5和10.1.1.0/24之间的通信生成一个Ipsec SA。

4. 当VPN-GW1-East收到加密的数据包的时候。它将首先利用外层的目的地址、ESP协议号和ESP头部的SPI为索引，从SAD中检索SA。如果找到，利用SA的参数对数据包进行解密，然后对解密的数据包应用SPD规则。此时，使用的是内部IP，因为数据包已经被解密了。