IPSEC 003 ---- IPSEC携手IKE，珠联璧合显神威_child sa

密钥管家IKE登场

上回说到手工方式的IPSec VPN帮助天地会解决了总舵和分舵之间秘密通信的问题，但随着分舵数量的增加新的问题又出现了。手工方式下防火墙的加密和验证所使用的密钥都是手工配置的，为了保证IPSec VPN的长期安全，需要经常修改这些密钥。分舵数量越多，密钥的配置和修改工作量越大。随着天地会的壮大，IPSec VPN的维护管理工作越来越让人吃不消了。
为了降低IPSec VPN管理工作量，天地会总舵主再访高人寻求灵丹妙药。灵丹已练，妙药天成――原来IPSec协议框架中早就考虑了这个问题――智能的密钥管家IKE（Internet Key Exchange）协议可以帮助解决这个问题。

IKE综合了三大协议：ISAKMP（Internet Security Association and Key Management Protocol）、Oakley协议和SKEME协议。ISAKMP主要定义了IKE伙伴（IKE Peer）之间合作关系（IKE SA，跟IPSec SA类似）的建立过程。Oakley协议和SKEME协议的核心是DH（Diffie-Hellman）算法，主要用于在Internet上安全地分发密钥、验证身份，以保证数据传输的安全性。有了IKE加盟，IPSec VPN的安全和管理问题不再困扰天地会，各地分舵申请建立VPN的流程终于可以进入“实施”状态了。

揭开ISAKMP本来面目

IKE协议的终极目标是通过协商在总舵和分舵之间动态建立IPSec SA，并能够实时维护IPSec SA。为建立IPSec SA而进行的IKE协商工作是由ISAKMP报文来完成的，所以在部署IKE之前，强叔先领大家认识一下ISAKMP报文。ISAKMP报文封装如下：

 IP报文头

• 源地址src：本端发起IKE协商的IP地址，可能是接口IP地址，也可能是通过命令配置的IP地址。
• 目的IP地址Dst：对端发起IKE协商的IP地址，由命令配置。

UDP报文头
IKE协议使用端口号500发起协商、响应协商。在总舵和分舵都有固定IP地址时，这个端口在协商过程中保持不变。当总舵和分舵之间有NAT设备时（NAT穿越场景），IKE协议会有特殊处理（后续揭秘）。
 

ISAKMP报文头

• Initiator’s Cookie（SPI）和responder’s Cookie（SPI）：在IKEv1版本中为Cookie，在IKEv2版本中Cookie为IKE的SPI，唯一标识一个IKE SA。
• Version：IKE版本号1。
• Exchange Type：IKE定义的交互类型2。交换类型定义了ISAKMP消息遵循的交换顺序。
• Next Payload：标识消息中下一个载荷的类型。一个ISAKMP报文中可能装载多个载荷，该字段提供载荷之间的“链接”能力。若当前载荷是消息中最后一个载荷，则该字段为0。
• Type Payload：载荷类型，ISAKMP报文携带的用于协商IKE SA和IPSec SA的“参数包”。载荷类型有很多种，不同载荷携带的“参数包”不同。不同载荷的具体作用我们后面会结合抓包过程逐一分析。

说明：

1：IKE诞生以来，有过一次大的改进。老的IKE被称为IKEv1，改进后的IKE被称为IKEv2。二者可以看做是父子关系，血脉相承，基本功能不变；但青胜于蓝，后者有了长足的进步。
2：IKEv1版本中可以在交换类型字段查看协商模式，阶段1分为两种模式：主模式和野蛮模式，阶段2采用快速模式。主模式是主流技术，野蛮模式是为解决现实问题而产生的。IKEv2版本中定义了查看创建IKE SA和CHILD SA（对应IKEv1的IPSec SA）的IKE_SA_INIT、IKE_AUTH（创建第一对CHILD SA）、CREATE_CHILD_SA（创建后续的CHILD SA）。
IKEv1和IKEv2的精华之处正是本文的重点，各位看官莫急，容强叔一一道来。

IKEv1小试牛刀

IKE最适合于在总舵和众多分舵之间建立IPSec VPN的场景，分舵越多IKE的优势越能凸显。为了讲解方便，这里仅给出总舵和一个分舵之间建立IPSec VPN的组网图。

 
相比手工方式，IKE方式仅增加了两步：配置IKE安全提议和IKE对等体。IKE安全提议主要用于配置建立IKE SA用到的加密和验证算法。IKE对等体主要配置IKE版本、身份认证和交换模式。 

 

说明：两条红色命令表示本例采用了IKEv1版本主模式。缺省同时开启IKEv1和IKEv2，关闭IKEv2后采用IKEv1版本进行协商。
配置完成之后，总舵和分舵之间有互访数据流时即可触发建立IPSec VPN隧道，下面强叔通过抓包来为大家详解一下IKEv1的精妙之处。

IKEv1招式拆解

IKEv1版本分两个阶段来完成动态建立IPSec SA的任务：
阶段1-建立IKE SA：阶段1采用主模式或野蛮模式协商。
阶段2-建立IPSec SA：阶段2此采用快速模式协商。
下面先介绍主模式+快速模式下的IPSec SA建立过程。

阶段1-建立IKE SA（主模式）

主模式下IKEv1采用3个步骤6条ISAKMP消息建立IKE SA。下面以网关A主动发起IKE协商为例进行讲解。
 

1. 协商IKE安全提议。
协商分两种情况：

• 发起方的IKE Peer中引用了IKE Proposal
• 发起方的IKE peer中没有引用IKE Proposal

二种情况下响应方都会在自己配置的IKE安全提议中寻找与发送方相匹配的IKE安全提议，如果没有匹配的安全提议则协商失败。IKE Peer双方安全提议匹配的原则为协商双方有相同的加密算法、认证算法、身份认证方法和DH组标识（不包括IKE SA生存周期）。
说明：通过IKEv1协议协商建立IPSec安全联盟时，采用本地生存周期和对端生存周期中较小的一个，不必保证隧道两端设备配置的生存周期相同（sa duration）。
通过抓包可以看出ISAKMP消息的SA载荷中携带用于协商的IKE安全提议。以消息1为例：

 
2. 使用DH算法交换密钥材料，并生成密钥。
网关A和B利用ISAKMP消息的Key Exchange和nonce载荷交换彼此的密钥材料。Key Exchange用于交换DH公开值，nonce用于传送临时随机数。由于DH算法中IKE Peer双方只交换密钥材料，并不交换真正的共享密钥，所以即使黑客窃取了DH值和临时值也无法计算出共享密钥，这一点正是DH算法的精髓所在。从抓包中可以看到IKE Peer双方交换密钥材料，以消息3为例：

 
密钥材料交换完成后，IKE Peer双方结合自身配置的身份验证方法各自开始复杂的密钥计算过程（预共享密钥或数字证书都会参与到密钥计算过程中），最终会产生三个密钥：

• SKEYID_a：ISAKMP消息完整性验证密钥――谁也别想篡改ISAKMP消息了，只要消息稍有改动，响应端完整性检查就会发现！
• SKEYID_e：ISAKMP消息加密密钥――再也别想窃取ISAKMP消息了，窃取了也看不懂！

以上两个密钥保证了后续交换的ISAKMP消息的安全性！

• SKEYID_d：用于衍生出IPSec报文加密和验证密钥――最终是由这个密钥保证IPSec封装的数据报文的安全性！

整个密钥交换和计算过程在IKE SA超时时间的控制下以一定的周期进行自动刷新，避免了密钥长期不变带来的安全隐患。
 

3. 身份认证
IKE Peer通过两条ISAKMP消息（5、6）交换身份信息，进行身份认证。目前有两种身份认证技术比较常用：

• 预共享密钥方式（pre-share）：设备的身份信息为IP地址或名称。
• 数字证书方式：设备的身份信息为证书和通过证书私钥加密的部分消息Hash值（俗称签名）。

以上身份信息都由SKEYID_e进行加密，所以在抓包中我们只能看到标识为“Encrypted”的ISAKMP消息，看不到消息的内容（身份信息）。以消息5为例：

 
预共享密钥是最简单、最常用的身份认证方法。这种方式下设备的身份信息可以用IP地址或名称（包括FQDN和USER-FQDN两种形式）来标识。当IKE Peer两端都有固定IP地址的时候，一般都用IP地址作为身份标识；当一端为动态获取IP地址的时候，没有固定IP地址的一端只能用名称来标识。本篇强叔给大家展示的案例为前者，后者晚些再讲。
这里有个小问题提醒大家关注：
总舵收到分舵1发来的身份信息后，需要用密钥（SKEYID_a和SKEYID_e）进行完整性验证和解密，只有先找到正确的预共享密钥才能计算出这两个密钥。但总舵网关为每个IKE Peer都配置了一个预共享密钥。怎么找呢？此时只能根据IKE Peer发来的ISAKMP报文的源IP地址（src）来查找预共享密钥，只要报文源地址与本端IKE Peer视图下remote-address命令配置的IP地址一致，就认为该视图下配置的pre-shared-key是分舵1的预共享密钥。
以上是IPSec协议内部处理过程，不需要大家操心。大家只要记住在IKE Peer两端都有固定IP地址的场景下，remote-address命令配置的IP地址要跟对端发起IKE协商的IP地址保持一致即可。这个IP地址的作用不仅仅是指定了隧道对端的IP地址，还参与了预共享密钥的查找。
阶段1协商完成后，进入阶段2。

阶段2-建立IPSec SA

在阶段2中IKEv1采用快速交换模式通过3条ISAKMP消息建立IPSec SA。由于快速交换模式使用IKEv1阶段1中生成的密钥SKEYID_e对ISAKMP消息进行加密，所以我们抓到的报文都是加密的，看不到载荷里面的具体内容。故下面只能文字介绍一下每一步的作用。
下面以网关A发起IPSec协商为例进行讲解。
 

1. 发起方发送IPSec安全提议、被保护的数据流（ACL）和密钥材料给响应方。
2. 响应方回应匹配的IPSec安全提议、被保护的数据流，同时双方生成用于IPSec SA的密钥。

IPSec对等体两端协商IPSec安全提议的过程跟协商IKE安全提议的过程类似，不再赘述。
IKEv1不协商ACL规则，建议两端设备配置的ACL规则互为镜像，避免IPSec SA协商失败。
IPSec对等体两端交换密钥材料（SKEYID_d、SPI和协议1、nonce等参数），然后各自进行密钥计算生成用于IPSec SA加密验证的密钥，这样可以保证每个IPSec SA都有自己独一无二的密钥。由于IPSec SA的密钥都是由SKEYID_d衍生的，一旦SKEYID_d泄露将可能导致IPSec VPN受到侵犯。为提升密钥管理的安全性，IKE提供了PFS（完美向前保密）功能。启用PFS后，在进行IPSec SA协商时会进行一次附加的DH交换，重新生成新的IPSec SA密钥，提高了IPSec SA的安全性。
说明：1、协议指AH和/或ESP协议。
3. 发起方发送确认结果。
协商完成后发送方开始发送IPSec（ESP）报文。
 

检查IPSec VPN状态信息
以总舵显示信息为例。

• 在总舵和分舵上查看IKE SA的建立情况。
  <FW_A> display ike sa
  current ike sa number: 2
  ---------------------------------------------------------------------
  conn-id    peer                    flag          phase vpn
  ---------------------------------------------------------------------
  40129      2.2.3.2                 RD|ST         v1:2  public
  40121      2.2.3.2                 RD|ST         v1:1  public
  这里统一显示了IKE SA（v1:1）和IPSec SA（v1:2）的状态，RD表示SA状态为READY。IKE Peer之间只有一个IKE SA，IKE SA是双向逻辑连接（不区分源和目的）。
• 在总舵和分舵上查看IPSec SA的建立情况。
  <FW_A> display ipsec sa brief
  current ipsec sa number: 2
  current ipsec tunnel number: 1
  ---------------------------------------------------------------------
  Src Address     Dst Address     SPI        Protocol  Algorithm
  ---------------------------------------------------------------------
  1.1.1.1         2.2.3.2         4090666525 ESP       E:DES;A:HMAC-MD5-96;
  2.2.3.2         1.1.1.1         2927012373 ESP       E:DES;A:HMAC-MD5-96;
  IPSec SA是单向的（区分源和目的），两个方向的IPSec SA共同组成一条IPSec隧道。
  说明：一般来说一条数据流对应一个IPSec SA。但当IPSec同时采用了ESP+AH封装时，一条数据流会对应两个IPSec SA。
•  在总舵和分舵上查看会话表。
  <FW_A > display firewall session table
  11:01:45  2014/07/08
   Current Total Sessions : 6
    esp  VPN:public --> public 1.1.1.1:0-->2.2.3.2:0
    icmp  VPN:public --> public 172.16.2.2:7264-->192.168.0.2:2048
    icmp  VPN:public --> public 172.16.2.2:7520-->192.168.0.2:2048
    icmp  VPN:public --> public 172.16.2.2:7776-->192.168.0.2:2048
    icmp  VPN:public --> public 172.16.2.2:8032-->192.168.0.2:2048
    icmp  VPN:public --> public 172.16.2.2:8288-->192.168.0.2:2048
  防火墙会为IPSec VPN建立了会话表（1.1.1.1:0-->2.2.3.2:0）。

 

下面简单介绍一下野蛮模式

配置命令exchange-mode aggressive即可将IKEv1的协商模式改为野蛮模式。抓包看一下野蛮模式的情况：

 

野蛮模式只用了3条ISAKMP消息就完成了阶段1的协商过程，阶段2仍旧是快速模式不变。
 

发起方和响应方把IKE安全提议、密钥相关信息和身份信息一股脑地全放在一个ISAKMP消息中发送给对方，IKE协商效率提高了。但由于身份信息是明文传输，没有加密和完整性验证过程，IKE SA的安全性降低了。既然这样不够安全，为什么野蛮模式还会出现？
在IPSec VPN出现的早期，由于主模式+预共享密钥身份认证方式下，IPSec需要通过对端的IP地址来在本地查找预共享密钥（主模式中已经详细解释了这个问题）。这种密钥查找方式在对端没有固定IP地址的情况下（比如IPSec NAT穿越场景，网络出口动态获取IP地址场景）行不通。此时，野蛮模式可以“野蛮”地解决这个问题。野蛮模式中“身份信息”没有加密，IPSec就直接用对端发送来的身份信息来查找预共享密钥即可。所以在IPSec VPN应用初期，野蛮模式主要用于解决没有固定IP地址的节点部署IPSec VPN的问题。现在，IPSec VPN解决这个问题有很多方法，不安全的野蛮模式已经不是最好的选择了。具体方法待后续再呈现给大家。

 

IKEv2应运而生

IKEv1似乎已经很完美了，但用得久了仍旧会发现不尽人意之处。

• 协商建立IPSec SA的时间太长

IKEv1主模式协商一对IPSec SA，需要6（协商IKE SA）+3（协商IPSec SA）=9条消息。
IKEv1野蛮模式协商一对IPSec SA，需要3（协商IKE SA）+3（协商IPSec SA）=6条消息。

• 不支持远程用户接入

IKEv1不能对远程用户进行认证。若想支持远程用户接入，只能借助L2TP，通过PPP来对远程用户进行AAA认证。
这些问题怎么解决呢？办法总比问题多！IKEv2中完美的解决了这些问题。

IKEv2相比IKEv1： 

• 协商建立IPSec SA的速度大大提升
  正常情况IKEv2协商一对IPSec SA只需要2（协商IKE SA）+2（协商IPSec SA）=4条消息。后续每建立一对IPSec SA只会增加2条消息。
• 增加了EAP（Extensible Authentication Protocol）方式的身份认证。
  IKEv2通过EAP协议解决了远程接入用户认证的问题，彻底摆脱了L2TP的牵制。目前IKEv2已经广泛应用于远程接入网络中了。今天强叔只介绍IKEv2的基本协商过程，EAP认证留待后续再讲。

IKEv2的配置思路与IKEv1完全相同，只是细节稍有不同：

说明：红色命令与IKEv1不同。缺省情况下，防火墙同时开启IKEv1和IKEv2协议。本端发起协商时，采用IKEv2，接受协商时，同时支持IKEv1和IKEv2。可以不关闭IKEv1。
IKEv2协商IPSec SA的过程跟IKEv1有很大差别：
 

1. 初始交换4条消息同时搞定IKE SA和IPSec SA。
初始交换包括IKE安全联盟初始交换（IKE_SA_INIT交换）和IKE认证交换（IKE_AUTH交换）。

 

 
 
第一个消息对（IKE_SA_INIT）：负责IKE安全联盟参数的协商，包括IKE Proposal，临时随机数（nonce）和DH值。

 
SA载荷主要用来协商IKE Proposal。

 
KE（Key Exchange）载荷和Nonce载荷主要用来交换密钥材料。

 
IKEv2通过IKE_SA_INIT交换后最终也生成三类密钥：
SK_e：用于加密第二个消息对。
SK_a：用于第二个消息对的完整性验证。
SK_d：用于为Child SA（IPSec SA）衍生出加密材料。
 

第二个消息对（IKE_AUTH）：负责身份认证，并创建第一个Child SA（一对IPSec SA）。
目前三种身份认证技术比较常用：

• 预共享密钥方式（pre-share）：设备的身份信息为IP地址或名称。
• 数字证书方式：设备的身份信息为证书和通过证书私钥加密的部分消息Hash值（签名）。
• EAP方式：采用EAP认证的交换过程属于扩展交换的内容，将在后面讲解。

以上身份信息都通过SKEYID_e加密。
创建Child SA时，当然也要协商IPSec安全提议、被保护的数据流。IKEv2通过TS载荷（TSi和TSr）来协商两端设备的ACL规则，最终结果是取双方ACL规则的交集（这点跟IKEv1不同，IKEv1没有TS载荷不协商ACL规则）。
当一个IKE SA需要创建多对IPSec SA时，例如两个IPSec对等体之间有多条数据流的时候，需要使用创建子SA交换来协商后续的IPSec SA。
2. 子SA交换2条消息建立一对IPSec SA。
 

子SA交换必须在IKE初始交换完成之后才能进行，交换的发起者可以是IKE初始交换的发起者，也可以是IKE初始交换的响应者。这2条消息由IKE初始交换协商的密钥进行保护。
IKEv2也支持PFS功能，创建子SA交换阶段可以重新进行一次DH交换，生成新的IPSec SA密钥。

IKEv1和IKEv2大PK

IKEv1和IKEv2的细节写了这么多，现在总结一下二者的异同点吧： 

显然IKEv2以其更加快捷、更加安全的服务胜出，长江后浪推前浪又成为了没有任何悬念的事实。 

 

IPSec协议框架总结

安全协议（AH和ESP）、加密算法（DES、3DES、AES）、验证算法（MD5、SHA1、SHA2）、IKE、DH，好多的缩写，大家搞清楚他们之间的关系了么？强叔做了一下总结，看看能否帮助大家：

l  安全协议（AH和ESP）――IP报文的安全封装。穿上AH或/和ESP马甲的IP报文称为IPSec报文。此“马甲”并非一般的马甲，是交织了“加密”和“验证”算法的刀枪不入的“软猬甲”。

 

说明：AH封装的验证范围实际要还更大一些，包括新的IP头。

l  加密算法（DES、3DES、AES）――IPSec报文的易容之术。IPSec数据报文采用对称加密算法进行加密，但只有ESP协议支持加密，AH协议不支持。另外，IKE协商报文也会进行加密。

l  验证（MD5、SHA1、SHA2）――IPSec报文的验明正身之法。加密后的报文经过验证算法处理生成数字签名，数字签名填写在AH和ESP报文头的完整性校验值ICV字段发送给对端；在接收设备中，通过比较数字签名进行数据完整性和真实性验证。

l  IKE――手握密钥管理大权的贴心管家。IPSec使用IKE协议在发送、接收设备之间安全地协商密钥、更新密钥。

l  DH算法――贴心管家的铁算盘。DH被称为公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息进行交换，并最终在收发两端计算出加密密钥和验证密钥。

这些概念一一梳理过来，强叔不得不感叹IPSec协议设计者的强大――这么多新的老的协议、算法拼接起来如此天衣无缝，自此Internet的险恶被屏蔽在隧道之外！为了方便大家记忆这些缩写，强叔用一张简图概括之：

写到这里，强叔心情舒畅，暗自为天地会网络的顺利推动得意。可是问题又来了――将IKE应用于IPSec VPN之后，那些有固定公网IP地址的大中型分舵的通信问题很快就解决了。但一些小型分舵IP地址不固定或只有私网IP地址，用常规的IKE方式部署IPSec VPN行不通。这种情况下怎么办呢？别担心，IKE的精彩之处还在于不出招则已、出招即能克敌；招招有戏、变化无穷，欲听详解请见下回分解。