ipsec vpn技术详解

1VPN （Virtual Private Network）
虚拟专用网是一种业务,可以在共享的公共网络上提供安全可靠的连接通道.
1.1按层次分的VPN:
二层VPN：ATM/Frame Relay/DDN/ISDN
三层VPN：IPSEC/GRE/L2TP
应用层VPN：Web VPN/SSL VPN
1.2安全的含义
保证来源性-----------对数据来源进行认证
保证完整性-----------在传输过程中,不允许对数据包进行修改
保证私密性-----------对数据包进行加密,又称为:数据的机密性.
不可否认性-----------不允许发送方抵赖,说自己没有传过
1.3VPN技术种类
Site-to-Site(又称为:Lan-to-Lan,或者又为:gateway-to-gateway.在公网上使用IPSEC VPN连接两个物理上不相连的局域网.
Remote-access适用于远程用户通过cisco VPN client 软件客户端拨号到中心站点的情况根据中心站点设备的不同分为Router remote VPN 和
ASA。

remote VPN关键技术点是1.5阶段的Xauth；VPN group；cisco VPN
client.
2加密算法
1)对称加密
产生一条密钥(加密或解密都使用同一条密钥).
加密速度快,加密后的文件紧凑(加密前后的文件大小差不多),适用于大量数据的加密.
算法:DES(56bit)/ 3DES(168bit)/ AES
2)非对称加密
产生一对密钥{加密使用一条密钥(公钥),解密使用另一条密钥(私钥)}
加密速度慢,加密后的文件不紧凑(加密后的文件比加密前的文件大很多),适用于加密证书或KEY的管理.
算法:RSA
3HASH的算法
MD5 128bit
SHA-1 160bit
HASH的特点:
任意不同长度的输入,得到相同长度的输出.
只有完全相同的输入,才有完全相同的输出
雪崩效应(只要有一点更改,就会有非常大的改变)
HMAC ----- HASH Message Authentication Code (利用Hash检验数据完整性)HMAC 是一个密钥认证算法"MAC"是一个与Hash密切相关的名词，即信息授权码(Message Authority Code).它是与密钥相关的Hash值,必须拥有该密钥才能检验.该Hash值,只有密钥的拥有者可以计算出新的散列值.
MAC(message authentication codes)消息认证码，利用密钥来生成一个固定长度的短数据块,并且将该数据块附在消息之后。

将消息和MAC一起将被发送给接收方。

接收方对收到的消息用相同的密钥进行相同的计算得出新的MAC，并将接收到的MAC 与其计算出的MAC进行比较。

Digital Signatures ----- 先用私钥加密,然后用公钥解密. 用于认证源.
Peer Authentication ----- 只要是验证,就要对比HASH.
DH Key Exchange
Diffie-Hellman密钥交换(第一种公共密钥加密系统),在一个不安全的网络中
打通一条安全的隧道,用于交换密钥.
通信双方在不传输密钥的情况下通过交换一些数据,计算出共享的密钥.
Peer authentication methods:
Pre-shared keys ------ 由双方预先设置好
RSA signatures
RSA encrypted nonces ----- 不需要CA
4IKE----Internet Key Exchange(Internet密钥交换协议)
负责各种IPSec选项的协商、认证通信的每一端(应用时包括公钥交换),以及管理IPSEC隧道的会话密钥.IKE使用用户数据报协议(UDP)端口500(通常用于源和目的双方)进行通信.
一种在Internet Security Association and Key Management Protocol(ISAKMP)框架中使用Oakley和SKEME协议组的混合协议.IKE通常用来确定一个共享的安全策略和对需要密码服务的验证,在IPSEC流量能通过之前,先要router/firewall/host 这些对等体进行身份验证.可以在双边手工输入预共享(pre-share)key或者通过CA 获得KEY,通过双边协商双边获得统一IKE的SA,建立初步的安全通道,为接下来的IPSEC作准备.
ISAKMP定义了两个通信对等体如何能够通过一系列的过程来保护它们之间的通信信道.它为两个对等体提供了互相验证,交换密钥等管理信息以及协商安全服务的手段.
IKE是一个"元"(meta)协议: "ISAKMP" = "Oakley" + "SKEME"
1)ISAKMP----Internet Security Association and Key Management
Potocol(Internet安全连接和密钥管理协议).作用:定义了一个信息交换的体系架构,包括包的格式和分组在两个Peer之间的传送方式和状态.
2)Oakley----一种KEY交换协议,它的一个基本机制就是Diffie-Hellman KEY
交换算法.作用:提供了为在2个IPSec Peer之间达成一种相同的加密密钥,
而需要的一种基于模式的机制.用户从会话中得到加密密钥.
3)SKEME-----Security Key Exchange Mechanism(安全密钥交换机制)SKEME
([SKEME])中描述了一种提供匿名、否认、和快速密钥更新的通用密钥交换
技术。

作用: 提供了以认证为目的而使用公钥加密的机制,用于认证IKE SA
的两端.
IKE (Internet Key Exchange): IKE is a hybrid protocol-a combination of ISAKMP、Oakley key exchange,and SKEME protocols-that defines a proper key exchange mechanism. IKE defines the mechanism for creating and exchanging keys. IKE derives authenticated keying material and negotiates SAs，that are used for ESP and AH protocols.IKE uses UDP port 500.
4.1Cookie值
cookie是通过散列算法计算出来的一个数值,为了避免伪造isakmp消息,散列算法以一个本地随机密钥,对方标识[对方的源/目的IP地址及源/目的端口号]及当前时间作为输入.
cookie可以是对通信对方的一个独一无二的标识符（比如它的IP地址／端口／协议）进行散列运算的结果；可以是只有生成者才知道的一项秘密；也可以是一些时间戳。

cookie成为留在IKE协商中交换信息的唯一标识,实际上cookie是用来防止DOS
攻击的，cookie的交换是在头两条消息的交换过程中进行的。

cookie的作用是保障密钥交换的有效性:
1)ISAKMP SA标识符是初始和应答cookie的组合(还有消息ID,消息ID是为了进
行多路复用);
2)防止过期的数据包进入新的数据流(拒绝服务攻击的保护);
3)也提供了一些抗阻塞保护。

4.2Isakmp头格式
Isakmp头部信息
发起者cookie（8字节）－－实体的cookie对应于一个SA建立请求，或SA通告，或SA删除。

应答cookie(8字节)－－实体的cookie用来应答一个SA建立请求，和SA通告，或SA删除。

下一个载荷（一个8位字节）――消息中下一个载荷的载荷类型的标识符。

如果当前载荷在消息中的最后，此字段将为0。

主版本（4 bit）－表示使用的ISAKMP协议的主版本。

实现是基于目前ISAKMP的Internet草案时,主版本号必须定为1。

实现是基于以前ISAKMP的Internet草案时，主版本号必须定为0。

实现永远也不能接受一个主版本号大于它自己的数据包。

微版本（4字节）－表示使用的ISAKMP协议的文版本。

实现是基于目前ISAKMP的Internet草案时,微版本号必须定为0。

实现是基于以前ISAKMP的Internet草案时,微版本号必须定为1。

给定同样的主版本号，实现永远不能接受一个微版本号大于它自己的数据包。

交换类型（1个八字节）－－表示所用的交换类型。

这表示消息和载荷遵循所用的交换顺序。

交换类型值
NONE 0
Base 1
Identity Protection 2
Authentication Only 3
Aggressive 4
Informational 5
ISAKMP Future Use 6 - 31
DOI Specific Use 32 - 239
Private Use 240 - 255
标志（1个八字节）－－表示特定的选项，用于设定ISAKMP交换。

以下在标志字段中指定的标志，从最低有效位开始，
如：在标志字段中加密位是0，提交位是1，鉴别位是2。

其他剩余位必须在传输前设为0。

⏹加密位（1位）－－如果设为1，ISAKMP头后面所有的载荷用ISAKMP SA中标
识的加密算法来加密。

ISAKMP SA标识符是初始和应答cookie的组合。

建议加密尽可能在对等体之间进行。

加密必须在双方都交换了密钥载荷之后进行。

如果加密位不是设为0，不对载荷进行加密。

⏹提交位（1位）－此位用于同步的单密钥交换。

它用来保证加密的内容不会
在sa建立之前被接收到。

提交位可由参与建立SA的任何一方（任何时刻）来进行设置，可用在ISAKMP SA建立的两个阶段。

然而，在阶段1协商之后，它的值必须复位。

如果设为1，未设置提交位的实体必须等待从设置了提交位的实体处的包含一个通知载荷(带有CONNECTED通知消息）的信息交换。

在这种情况下，信息交换的消息ID字段必须包含原始ISAKMP 阶段2SA协商的消息ID。

可以保证带有CONNECTED通知消息的信息交换可以和正确的阶段2 SA相连. 信息交换的接收和处理，表示SA的成功建立，并且任何一个实体现在可以处理加密的通信信息。

除了同步密钥交换，提交位可以用来保护在不可信网络上传输的丢失，还可以防止多次重发送的必要。

⏹唯一鉴别位（1 位）－这一位用在带有通知载荷的信息交换中，并且允许带
有完整性检查，但不加密的信息传送中(如：“紧急模式”)。

如果唯一鉴别
位设置为1,仅只有鉴别安全服务将被应用到实体中，以通报信息交换载荷,
并且不对信息交换载荷进行加密。

消息ID（4个八位字节）－唯一消息标识符用来标识在同步阶段2的协议状态。

这个值由同步阶段2的启动程序来随机产生。

在同步SA的建立中(也就是说冲突),此字段的值将会有所不同，因为它们是独立产生的。

并且，两个安全联盟将促进SA的建立。

然而，不可能由绝对同步的建立。

在阶段1的同步中，值必须置为0。

⏹由于多个快速模式交换可同时进行，所以必须采用某种方法，对IKE消
息进行多路复用，并能判断出哪一条消息对应哪一次交换。

ISAKMP头的
消息ID便是针对这一目的而设计的。

每个快速模式交换都有一个独一无
二的消息ID，它随ISAKMP头中的Cookie一道使用，以便标定一条特定的
消息对应的是哪一个状态。

⏹除此以外，由于所有快速模式消息都受相同的IKE SA的保护，所以必须
采取某种方式，对初始化矢量(IV）进行协调，以便进行加密与解密，
从而防范参与I K E通信的双方产生不同步的情况，同时防范它们不能
解密出由对方加密的消息。

消息ID也用于这个目的。

长度（4个八位字节）以八位字节来计的整个消息（头＋载荷）的长度，加密会扩大ISAKMP的大小。

4.3密钥材料
SKEYID是从密钥材料中衍生出的字符串,只有某次交换中的活跃双方才知道。

SKEYID_a 是用来为IKE消息保障数据的完整性以及对数据源的身份进行验证。

<====HASH时,使用.
SKEYID_e 是用来对IKE消息进行加密所使用的密钥材料。

<====第一阶段时,使用.
SKEYID_d 是用来为IPSec(和其他)衍生出密钥所使用的密钥材料。

<===衍生出ESP的密钥材料{即:也会根据前面的"SKEYID_d"衍生出新的
"SKEYID_a"(已经没用了)/"SKEYID_e"(已经没用了)/"SKEYID_d"(衍生出
ESP的密钥材料)}
//上述协商出来的密钥材料都是为IKE阶段2的快速模式进行服务的.
4.4DH算法
例子：
假如用户Alice和用户Bob希望交换一个密钥。

取一个素数p = 97和97的一个原根a = 5。

Alice和Bob分别选择秘密密钥XA = 36和 XB = 58，并计算各自的公开密钥：YA=a^XA mod p=5^36 mod 97= 50
YB=a^XB mod p=5^58 mod 97= 44
Alice和Bob交换了公开密钥之后，计算共享密钥如下：
Alice：K=(YB) ^XA mod p= 44^36 mod 97 = 75
Bob：K=(YA) ^XB mod p= 50^58 mod 97 = 75
4.5IKE简述
ISAKMP信息由一个ISAKMP报文头以及UDP(端口500)报文中的一个或多个ISAKMP 有效负载链在一起组成.发送者cookie(initiator cookie)以及应答
cookie(responder cookie)是ISAKMP对等体产生的特殊值(cookie是通过散列算法计算出来的一个数值, 为了避免伪造isakmp消息, Cookie使源/目的IP地址、随机数字、日期和时间进行MD5运算得取出，并且将其放入消息1的ISAKMP头中,用以标识一个单独的协商交换),它们提供一些对拒绝服务攻击的保护,在这种攻击中,攻击者可能设法产生大量伪造的ISAKMP信息并使ISAKMP处理器瘫痪.在太多的处理资源被浪费之前,cookie通过允许ISAKMP丢弃伪造的消息来提供某些保护.在成功完成协商之后,发送者cookie以及应答cookie也被用于标识在两个isakmp对等体之间的安全联盟.
A.本地生成一个cookie值,同时对此cookie值进行散列算法,把生成的hash值
存储于本地数据库.
B.将cookie值发送给对端(该cookie值会被对端发回给产生该cookie的端点).
C.从对端收到cookie值,重新进行散列算法. 比较重新得到的hash值是否与最
初的cookie值相同.
一个ISAKMP的SA是双向的(IKE SA). 为了减少协商的开销,一个ISAKMP的SA可能被用来协商多个IPsec的SA.
1)IKE Phase 1 --- The VPN devices negotiate an IKE security policy and
establish a secure channel.
--- Authenticate the peers
--- Negotiate a bidirectional SA
--- Main mode or aggressive mode
Main mode(6 Messages) : Site-to-Site 可以通过cookie值实现防止DOS攻击.
aggressive mode(3 Messages) : Remote-VPN 基于Pre-share Key.
不能阻止DOS攻击.
IKE阶段I对认证双方PEER和为了加密一部分Main mode和所有quick mode交换包,而协商一些参数.aggressive mode的包都没有加密.
认证双方对等体.
产生KEY材料,这个用于产生为了实际加密数据,而用到的KEY.
在协商过程中:IKE使用用户数据报协议(UDP)端口500(通常用于源和目的双方)进行通信.
2)IKE Phase II---第二阶段利用IKE阶段I所既定的安全联盟，为IPSec协商具
体的安全联盟。

所有的主模式和主动模式协商的信息都存在IKE或ISAKMP安全关联(SA)里.每两个PEER之间有一个安全关联.
4.5.1IKE的功能
1)Negotiating protocol parameters 协商协议参数
2)Exchanging public keys 交换公钥
3)Authenticating both sides 认证PEER
4)Managing keys after the exchange 管理交换完成的KEY
4.5.2IKE第1阶段
主模式:
主模式在三次交换中总共用到了六条消息，最终建立了IKE SA。

这三个步骤分别是[协商安全参数]、[Diffie-Hellman和nonce交换]、以及[对方身份的验证]
A.第一次交换
Message 1---一个ISAKMP发起者向其他对等体发送一条包含一组或多组SA 安全提议,在策略提议中包括5元组(加密算法,散列算法,DH_Group,认证方
法,IKE SA寿命)
Message 2---接受者查看收到的IKE策略消息,并尝试在本地寻找与之匹配的策略,找到后,接受者选择一个SA提议,并把它回送给发送者，表示确认并且使用此策略。

注：发起者会将它的所有策略发送给接受者,接受者则在自己的策略中寻找与之匹配的策略(对比顺序从序列号由小到大的顺序)（默认策略实际就是个模版没作用，如果认证只配置预共享的话，其他参数就会copy默认策略里的）
在1&2消息中报错可能出现的原因
⏹peer路由不通
⏹crypto iskmp key没有设置
⏹一阶段的策略不匹配
Negotiate IKE policy (message types 1 and 2).
Information exchanges in these message types include ip addess.
Proposals，such as Diffie-Hellman group number and encryption algorithmn.
All messages are carried in UDP packets with a destination UDP port number of 500.The UDP payload comprises a header,an SA payload,and one or more proposals.
Message type 1 offers many proposals,and message type 2 contains a single proposal.(加密算法、散列算法、验证机制、DH组信息、key生存周期)
B.第二次交换
两个对等体通过DH生成公钥并交换DH公钥参数以及随机的称为nonces(伪随机数)的仅被使用一次的值. nonces用来预防重传攻击.
这2条消息,用于交换DH的公开信息和随机数
两个对等体根据DH的公开信息都算出了双方相等的密植后,两个nonce连通
预共享密钥生成第一个skeyID，随后便根据SKEY__ID来推算出其他几个skeyID skeyID_d---用来协商出后续IPSEC SA加密使用的密钥的
skeyID_a---为后续的IKE消息协商以及IPSEC SA协商进行完整性检查(HMAC 中的密钥)
skeyID_e---为后续的IKE消息协商以及IPSEC SA协商进行加密
Performs authenticated Diffie-Hellman exchange (message types 3 and 4). Message types 3 and 4 carry out the Diffie-Hellman(DH).
Message types 3 and 4 contain the key exchange payload，which is the DH public value and a random number(nonce: key value is usually a number of 1024 bit length).
Message types 3 and 4 also contain the remote peer's public key hash and the hashing algorithm.
A common session key created on both ends，and the remain IKE messages
exchanged from here are encrypted.
If perfect forward secrecy (PFS) is enabled another DH exchange will be completed.
C.第三次交换
这5&6条消息用于双方彼此验证,这个过程是受skeyID_e加密保护的
为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥(此时由于ID
还没到,彼此先用HASH来彼此验证对方)
Hash_I=PRF(SKEYID,CKY-I,CKY-R,Pre-shared Key,SA
Payload,Proposals+Transforms,ID_I)
所有被交换的信息通过三种验证机制(共享秘密,数字签名或者公共密钥加密)之一进行验证.当使用共享秘密机制时,两个对等体使用一个派生自共享秘
密的密钥来创建关键散列值,随后在两个对等体之间交换关键散列值并充当认
证者.
IKE Phase I Messages Types (message types 5 and 6)
Protects IKE peer's identities---identities are encrypted. Message type 5 and 6 are the last stage before traffic is sent over the IPSec tunnel.Message type 5 allows the responder to authenticate the initiating device. Message type 6 allows the initiator to authenticate the responder.
These message types are not sent as clear text. Message type 5 and 6 will now be encrypted using the agreed upon encryption methonds established in message types 1 and 2.
在主模式下,只对第五消息和第六消息加密.(即Verify the peer identity),认证对方时使用"SKEYID_a".
一.交换策略
1 packet-----Cookiei + SAi
2 packet-----Cookier + Cookiei + SAi + SAr
二.交换密钥
3 packet-----Cookiei + Cookier + Ni + X(密钥材料)
4 packet-----Cookiei + Cookier + Nr + Y
三.认证对方
5 packet-----Cookiei + Cookier + idi + hashi
6 packet-----Cookiei + Cookier + idr + hashr
积极模式：
积极模式在三个步骤中总共用到了四条消息，最终建立了IKE SA。

A.第一次交换-----几乎将所有的安全参数都挤在第一次交换机中：IKE策略协
商,DH公钥生成,nonce散列与交换识别数据包,可以用来通过第三方验证它
们的身份.
B.第二次交换-----接收者将上面的所有安全参数发回以完成这次交换及一个
验证载荷(即:验证响应者).
C.第三次交换-----就是发起者确认交换,即发起者回应一个"验证载荷".(即:
验证发起者).
发送者和接收者之间交换的验证信息并没有加密.
野蛮模式
⏹第一个报文 cookiei + sai + X + ni + idi
⏹第二个报文 packet cookiei + cookier + sai + sar + nr + Y + hash i +
idr
⏹第三个报文 hash r
ID负载
认证对方对等体
ID负载和报文头中的源IP地址可以检验对方对等体.
总结:
main mode中的问题
1)如果一直在交换Messages 1 and 2的数据包---有可能是对等体配置错误。

2)如果一直在交换Messages 5 and 6的数据包-可能是对等之间的密钥配置错误.
4.5.3IKE第2阶段
IKE Phase 2 --- The VPN devices negotiate an IPSec security policy used to protect IPSec data.
--- IPSec SAs/SPIs
Quick mode
IKE phase II negotiates the SA and the keys that will be used to protect the user data. IKE phase II messages occur more frequently and typically every few minutes，Where IKE phase I message might occur once a day.
A.Message type I allows the initiator to authenticate itself and selects
a random number (nonce) and proposes a security association to the
remote peer. Additionally，a public key is provided (can be different than a key exchanged in IKE phase I).
B.Message type II allows the responding peer to generate the hash.
Message type 2 allows the responder to authenticate itself and selects
a random number and accepts the SA offered by the initiating IPSec
peer.
C.Message type III acknowledges information sent from quick mode
message 2 so that the phase II tunnel can be established.
IKE Phase II Summary:
A.Negtiates IPSec SA parameters protected by an existing IKE SA (during
IKE phase 1).
B.Establishes IPSec security associations，SA periodically
renegotiates IPSec SAs to ensure security.
C.Optionally performs an additional Diffie-Hellman exchange if PFS
enabled.
D.IPSec SA is unidirectional.
在快速模式中,双方peer协商IPSec安全关联的属性值.用于加密(例如:ESP)两
个主机之间的通信数据.如果启用PFS,将重新进行一次DH交换,在产生IPSEC数据加密KEY之前,交换新的KEY材料.
在第2阶段期间,安全联盟代表服务进行协商,这些服务包括IPsec或任何其他的
服务,它们需要密钥材料或参数协商.因为在第1阶段中已经建立了一条安全信道,所以能更快地实现协商,它也被称为快速模式(quick mode).
在第1阶段已经验证了IKE对等体的身份,ISAKMP的SA已经对IKE对等体之间的交换进行了保护.因此,通过快速模式的身份不是IKE对等体的身份,而是在IPsec安全策略数据库中使用的选择开关的身份.
当协商第2阶段SA时,需要第1阶段ISAKMP的SA.一旦第2阶段SA建立了,它就能够不依赖于第1阶段的SA而存在,即使第1阶段的SA以后会遭到破坏.
Quick mode交换的消息全部是加密后的.
4.5.4SA-security association(安全关联)
SA是两个IPSec通信实体之间经协商建立起来的一种共同协定。

它规定了通信双方使用哪种安全协议来保护数据的安全、应用哪种加密算法、加密和验证的密钥取值以及密钥的生存周期等安全属性值。

IPSec SA是单向的,故欲进行双向通信需建立两个SA(in out各为一个方向)。

这些SA通过ISAKMP协商或可人工定义。

安全关联(SA)是目的IP地址、安全协议标识符与安全参数索引(SPI))的组合,它们一起定义用于保护从发送方到接收方的通讯安全.
安全参数索引(SPI)是SA中的唯一标识值,用于区分存在于接收端设备上的多个安全关联.例如,如果一台设备同时与多台设备进行安全通讯,就会存在多个关联。

当设备作为文件服务器或作为远程访问服务器(为多个客户机提供服务)时,通常会出现这种情况,在这些情况下,接收端设备使用SPI来决定将使用哪种SA 处理传入的数据包.
对于SA,目的IP地址是目的端点的IP地址。

SPI通常是SA的目的端点选择的一个32位数字,它仅在那个目的端点内具有本地的有效性.
安全协议标识符是针对AH(51)和ESP(50)的协议号.
SA包括以下两个数据库:
1)Security Policy Database
Encryption Algorithm
Authentication Algorithm
Encapsulation Mode
Key Lifetime
2)SA DataBase
Destination IP address <===用于新的IP包头和目的地址
SPI(安全参数索引) <===用于标识IPSEC通道.
Protocol(ESP or AH)
数据包输入处理：
系统收到IP包后，判断该数据是否是IPSec包，如果是则从头部信息中提取SPI 值，对应搜索SADB。

若找不到SA，触发IKE或丢弃包。

如果找到SA,根据其进行解封装，得到去封装后的原始IP包，再从IP包中提取选择符，搜索到SPD中某一条目，检查收到包的安全处理是否符合描述规则，不符合则丢弃包，符合则转入系统IP协议栈进行后继处理。

对于入站IP报文的过程,通过匹配三个值(目的IP地址、IPsec协议类型、SPI值)在SAD中找到适当的SA。

目的IP地址和IPsec协议类型包含在IP报文头中,SPI来自AH 或者ESP报文头。

如果对于输入的报文找到了一个SA,将会根据给定的安全服务来处理这个报文，被处理的报文服从SPD规则的处理。

数据包输出处理：
数据包被网关设备发送出去之前，截取到IP包，然后从中提取选择符信息，依据SPD，产生三种结果中的一种。

SPD决定丢弃该数据包、直接放行或应用IPSec进行处理，如果需要进行IPSec处理，则SPD指定向一个SA，可以根据它进行安全处理(需要的SA不存在，则触发IKE进行协商并建立sa，协商周期内数据包进入等待队列等待协商完成，若协商超时，将丢弃该数据包)。

对于出站IP报文的过程,首先进行SPD处理。

如果一个输出报文匹配某个策略(它指出了需要的IPsec处理)，则检索SAD以决定是否已经建立了一个安全联盟。

如果找到匹配的条目，将根据SA对报文进行处理。

如果没有找到，将为报文协商一个新的SA，随后被协商的SA将存储在SAD中。

SPD能够为报文指定三个处理选项中的一个。

4.5.5IKE Other Functions
DPD --- Dead peer detection
在两台安全网关之间通过IKE协商使IPSec协议进行安全通信，当网络和网关工作正常的情况下，两个网关之间可以正确通信。

当删除SA时可以发出通知/删除消息，通知对端作相应的处理。

当网络不通或其它原因导致数据包不能正确到达对端，或者对端网关由于非正常原因删除了SA但没有发送通知删除/消息(如设备故障重启)。

在上述情况下本端网关不知道对端发生的情况，会继续使用原来的SA处理与对端网关的安全通信直到手工删除SA或SA超时重新发起协商。

上述情况可能会导致两个安全网关在相当长的一段时间内不能进行正确的安全通信，这在某些情况下可能会导致严重后果。

而IKE协议本身对此无能为力。

DPD设计目的就是能够及时探测对端网关可能存在的这种非正常状态，并且在探测与对端不能正常进行IPSec通信时能够主动删除本端SA，重新发起IKE协商，恢复安全通信。

DPD的主要原理:
A.采用了查询和应答机制，通过查询报文和应答报文两条消息的交互来确定对
端状态。

B.通信双方都要维护自己的定时器，发送探测报文旋涡状的时间间隔和重传次
数可以根据对端状态变化所导致后果的严重程度来自行设置；
C.为减少网络流量，DPD只在需要与对端通信时才探测对端是否存活，通常并
不需要定时发送查询报文，它会首先检查对端是否有持续的IPSec数据向自
己发送，如果有说明对端存活，则无需查询报文。

如果IPSec数据流空闲时
间超过设定时间间隔，则发送查询报文，检查对端状态，这种机制有效的减
少了双方报文交换的数量，避免了在某些情况下可能导致的网络阻塞。

D.DPD双方采用已经建立的IKE SA对报文进行加密和认证保护，如果IKE SA不
存在或出现故障，则无法发送或响应DPD报文，也就意味着需要重新协商建
立新的IKE SA和IPSec SA,恢复正常状态；
E.在DPD报文中采用序列号标识报文顺序，从而能够有效地防止重放攻击，也
能表明正常通信状态的连续性。

NAT traversal
Encapsulates IPSEC packet in UDP packet
因为IPSEC包为三层包是没有端口信息,所以要将IPSEC的包封装进UDP包的4500号端口里面。

IPSEC的包分两种: AH (不支持 NAT Traversal) ESP (支持 NAT Traversal) 所有主机的数据在没有穿越PAT设备，源端口和目标端口都是4500号端口；当第一台主机数据穿越PAT设备时,源端口或目标端口号不发生改变，但当第二台主机数据穿越PAT设备时，源端口会随机更改.
PFS（Perfect Forward Secrecy）
与密钥生命期不同，PFS决定新密钥的生成方式，而不是新密钥的生成时间。

PFS 保证无论在哪一阶段，一个密钥只能使用一次，而且，生成密钥的"材料"也只能使用一次。

某个"材料"在生成了一个密钥后，即被弃，绝不用来再生成任何其他密钥。

这样可以确保一旦单个密钥泄密，最多只可能影响用该密钥加密的数据，而不会危及整个通信。

主模式主密钥PFS需要重新进行身份验证，且资源消耗很大。

启用这种 PFS 时，IKE必须重新进行身份验证。

快速模式会话密钥PFS可在不重新进行身份验证的情况下进行使用，其资源消耗很小。

会话密钥PFS会导致进行DH交换，以生成新的密钥材料。

它仅需要四条消息，且无需进行身份验证。

4.5.6封装模式
隧道模式
通过将其当作AH或者ESP有效负载，隧道模式提供对整个IP数据包的保护.使用隧道模式时，会通过AH或ESP报头与其他IP报头来封装整个IP数据包。

外部IP报头的IP地址是隧道终结点，封装的IP报头的IP地址是最终源地址与目标地址.
Protects data in network-to-network or site-to-site scenarios. In tunnel。