概述
IPsec由四部分内容构成：负责密钥管理的Internet密钥交换协议（IKE，Internet Key Exchange Protocol），负责将安全服务与使用该服务的通信流相联系的安全关联（SA，Security Associations），直接操作数据包的认证头协议（AH，IP Authentication Header）和安全载荷协议（ESP，IP Encapsulating Security Payload），以及若干用于加密和认证的算法。
分别对IKE、AH和ESP的流程和数据格式进行解析。
IKE（RFC2407，RFC2408、RFC2409）
IKE属于一种混合型协议，由Internet安全关联和密钥管理协议（ISAKMP）和两种密钥交换协议OAKLEY与SKEME组成。IKE创建在由ISAKMP定义的框架上，沿用了OAKLEY的密钥交换模式以及SKEME的共享和密钥更新技术，还定义了它自己的两种密钥交换方式。
IKE使用了两个阶段的ISAKMP：第一阶段，协商创建一个通信信道（IKE SA），并对该信道进行验证，为双方进一步的IKE通信提供机密性、消息完整性以及消息源验证服务；第二阶段，使用已建立的IKE SA建立IPsec SA（V2中叫Child SA）。
IKE共定义了5种交换。阶段1有两种模式的交换：对身份进行保护的“主模式”交换以及根据基本ISAKMP 文档制订的“野蛮模式”交换。阶段2 交换使用“快速模式”交换。IKE 自己定义了两种交换：1为通信各方间协商一个新的Diffie-Hellman 组类型的“新组模式”交换；2在IKE 通信双方间传送错误及状态消息的ISAKMP信息交换。
目的：创建IKE SA，确定对下一阶段保护机制（主
要是交换密钥及身份认证）。
阶段1：六信息
实现方式：
三步
三信息IKE
目的：创建Child SA，确定协议（AH or ESP），
算法及参数。
阶段2
实现方式：快速交换。（新组交换，信息交换）
ISAKMP报头
ISAKMP 报文一般利用UDP协议传输，端口号500 。ISAKMP报头有固定格式，需要添加在每个IKE报文上进行交换；提供对会话的验证和版本信息、交换类型等说明。
之后跟各类载荷头，载荷头的格式为
载荷头之后，是载荷内容。载荷的类型有：
（注：各类载荷的内容格式在RFC2408中有详细描述）
第一阶段
1．主模式交换
步骤：
1．策略协商，在这一步中，就四个强制性参数值进行协商：
1）加密算法：选择DES或3DES
2）hash算法：选择MD5或SHA
3）认证方法：选择证书认证、预置共享密钥认证或Kerberos v5认证
4）Diffie-Hellman组的选择
2．DH交换
在彼此交换过密钥生成"材料"后，两端主机可以各自生成出完全一样的共享"主密钥"，保护紧接其后的认证过程。
3．认证
DH交换需要得到进一步认证，如果认证不成功，通信将无法继续下去。"主密钥"结合在第一步中确定的协商算法，对通信实体和通信信道进行认证。在这一步中，整个待认证的实体载荷，包括实体类型、端口号和协议，均由前一步生成的"主密钥"提供机密性和完整性保证。
（详见RFC2409）
2．野蛮模式交换
野蛮模式交换也分为三个步骤，但只交换三条消息：头两条消息协商策略，交换Diffie Hellman公开值必需的辅助数据以及身份信息；第二条消息认证响应方；第三条消息认证发起方，并为发起方提供在场的证据。
第二阶段
第二阶段协商消息受第一阶段SA保护，任何没有第一阶段SA保护的消息将被拒收。
步骤：
1．策略协商，双方交换保护需求：
·使用哪种IPSec协议：AH或ESP
·使用哪种hash算法：MD5或SHA
·是否要求加密，若是，选择加密算法：3DES或DES 在上述三方面达成一致后，将建立起两个SA，分别用于入站和出站通信。
2．会话密钥"材料"刷新或交换
在这一步中，将生成加密IP数据包的"会话密钥"。生成"会话密钥"所使用的"材料"可以和生成第一阶段SA中"主密钥"的相同，也可以不同。如果不做特殊要求，只需要刷新"材料"后，生成新密钥即可。若要求使用不同的"材料"，则在密钥生成之前，首先进行第二轮的DH交换。（新组交换：通信双方通过新组模式交换协商新的Diffie－Hellman组。新组模式交换属于一种请求/响应交换。发送方发送提议的组的标识符及其特征，如果响应方能够接收提议，就用完全一样的消息应答）
3．SA和密钥连同SPI，递交给IPSec驱动程序。
第二阶段协商过程与第一阶段协商过程类似，不同之处在于：在第二阶段中，如果响应超时，则自动尝试重新进行第一阶段SA协商。
第一阶段SA建立起安全通信信道后保存在高速缓存中，在此基础上可以建立多个第二阶段SA协商，从而提高整个建立SA过程的速度。只要第一阶段SA 不超时，就不必重复第一阶段的协商和认证。允许建立的第二阶段SA的个数由IPSec策略属性决定。
AH（RFC2402）
AH报头位置在IP报头和传输层协议报头之间。 AH由IP协议号" 51"标识，该值包含在AH报头之前的协议报头中，如IP报头。AH可以单独使用，也可以
与ESP协议结合使用。
AH报头的格式
具体结构如下：
●Next Header（下一个报头）：识别下一个使用IP协议号的报头，例如，Next
Header值等于"6"，表示紧接其后的是TCP报头。
●Length（长度）： AH报头长度。
●Security Parameters Index (SPI，安全参数索引)：这是一个为数据报识
别安全关联的 32 位伪随机值。SPI 值 0 被保留来表明"没有安全关联存在"。
●Sequence Number（序列号）：从1开始的32位单增序列号，不允许重复，
唯一地标识了每一个发送数据包，为安全关联提供反重播保护。接收端校验序列号为该字段值的数据包是否已经被接收过，若是，则拒收该数据包。
●Authentication Data（AD，认证数据）：包含完整性检查和。接收端接收
数据包后，首先执行hash计算，再与发送端所计算的该字段值比较，若两者相等，表示数据完整，若在传输过程中数据遭修改，两个计算结果不一致，则丢弃该数据包。
AH的实现
AH报头插在IP报头之后，TCP，UDP，或者ICMP等上层协议报头之前。一般AH为整个数据包提供完整性检查，但如果IP报头中包含“生存期（Time To Live）”或“服务类型（Type of Service）”等值可变字段，则在进行完整性检查时应将这些值可变字段去除。
AH也为IP头中的一部分提供验证，在某些情况下，这可能是必须的。例如，如果IPv4选项或IPv6扩展头的完整性在发送方和接收方之间的路程中必须被保护，AH可以提供这项服务（除了IP头中不可预知、易变的部分）。
在使用AH协议时，AH协议首先在原数据前生成一个AH报文头，报文头中