IPSec
一次性进群，长期免费索取教程，没有付费教程。
教程列表见微信公众号底部菜单
进微信群回复公众号：微信群；QQ群：16004488
微信公众号：计算机与网络安全
ID：Computer-network
一、IPSec 体系结构
在TCP/IP体系结构中，IP层本身并不提供任何安全保证：IP 包可能会被监听、拦截或者重放，地址可以被伪造，内容可能会被修改。因此，IP层本身不提供源认证，也无法保证包含的是发送方当初放在其中的原始数据，更无法保证原始数据保密性。IPSec就是为了解决这些问题而提出来的。它采取的具体保护形式包括：源验证、无连接数据的完整性验证、数据内容的保密性、抗重放攻击以及有限的数据流机密性保证。IPSec的本意是希望在IP层统一解决目前TCP/IP体系结构中的各个安全问题。这样，就不必要在传输层和应用层考虑复杂的安全通道的问题了。然而，事与愿违的是，在IPSec提出多年之后，IPSec似乎并没有取得预料中的成功，传输层安全通道TLS/SSL、SSH等一大批传输层、应用层的安全协议似乎得到了更为广泛的应用。甚至在VPN的各种可选方案中，IPSec似乎也没有占据明显的优势。这种情况产生的原因，可以大致归纳为几点，一方面，IP层是网络中进行路由的核心一层，IPSec的使用，不可避免地加重了路由器的负担，在TCP/IP的架构中，一个核心的设计思想就是将安全留给端系统去进行考虑，因此，对于IP层的一些安全扩展，很难得到一些将吞吐率放到首位的网络运营商和设备商的支持，而TLS/SSL/SSH等，在这方面则有很大的优势；另一方面，IPSec 体系结构的复杂也给自己的使用增加了人为的障碍，IPSec 对 NAT的排斥，以及密钥分布协议的复杂，使得IPSec的应用出现很多问题。
IPSec协议族主要由三个协议构成：头认证（AH）协议、封装安全负载（ESP）协议以及公钥基础设施协议。IP 头认证（AH）提供无连接的完整性验证、数据源认证、选择性抗重播服务。当不需要保密（或不允许，例如政府限制加密的使用）时，使用AH协议是适合的。AH也为IP头选项部分提供认证。这在某些情况下是有必要的，例如如果在收发双方间，IPv4选项或IPv6扩展头的完整性必须被保护到路由时，AH能提供这种服务（除了IP头不可预料的、易变的部分）。
封装安全负载（ESP）提供加密、有限传输流加密。它也提供无连接的完整性验证、数据源认证、抗重播服务。ESP可有选择地为传输提供保密。ESP也可以有选择地提供认证服务、增强抗重播服务。由ESP提供的认证范围比AH所提供的要窄，例如，ESP头外部的IP头就不受保护。如果仅上层协议需要被认证，那么ESP认证是个合适的选择并且它具有比使用AH封装ESP时更高的空间效率。要注意的是尽管保密和认证均是可选的，但是它们不能都被省略。它们中至少有一个必须被选择。
为正确封装及提取IPSec 数据包，有必要采取一套专门的方案，将安全服务/密钥与要保护的通信数据联系到一起；同时要将远程通信实体与要交换密钥的IPSec 数据传输联系到一起。换言之，要解决如何保护通信数据、保护什么样的通信数据以及由谁来实行保护的问题。这样的构建方案称为安全关联（Security Association，SA）。在IPSec中，AH、ESP都使用安全关联进行管理，所有AH和ESP的实现都必须支持下面描述的安全关联的概念。所谓安全关联（SA），就是一个单向连接，它为通过它的传输提供安全服务。SA通过AH或ESP（但不是两者同时）来提供安全服务。如果AH和ESP同时用于传输流的保护，那么应该创建两个或多个 SA为传输流提供保护。通常为了安全，两台主机间或两个安全网关间或两个安全连接间（每个方向一个）都需要双向通信。安全关联由三方面的因素决定：
第一个是安全参数索引（SPI），该索引存在于IPSec 协议头内，是一个任意的32位值，它与目的IP地址和安全协议结合，惟一地标识这个数据报的SA。从1至255的这组SPI值是由Internet Assigned Numbers Authority（IANA）保留给将来使用的；在建立SA时目的系统可以在其他的值中选择。SPI 的值为 0是保留给本地、特定实现使用的，不允许在线路上发送。例如，密钥管理实现可以使用SPI的0值表示当IPSec实现要求它的密钥管理实体建立新SA，但SA仍然没有建立时，没有SA存在。
第二个是IPSec 协议值，即ESP或者AH。
第三个是要向其应用SA 的目标地址——它同时决定了方向。
通常，SA 是以成对的形式存在的，每个朝一个方向。既可人工创建它，亦可采用动态创建方式。SA驻留在安全关联数据库（SADB）内。若用人工方式加以创建，SA 便没有存活时间的说法。除非再用人工方式将其删除，否则便会一直存在下去。若用动态方式创建，则SA 有一个存活时间与其关联在一起。这个存活时间通常是由密钥管理协议在IPSec 通信双方之间加以协商而确立下来的。存活时间（TTL）非常重要，因为受一个密钥保护的通信量（或者类似地，一个密钥保持活动以及使用的时间）必须加以谨慎地管理。若超时使用一个密钥，会为攻击者侵入系统提供更多的机会。
穿过独立SA的IP数据报通过严密的安全协议（AH或ESP）受到保护。对于特殊的传输流，而仅采用单一的SA是不能实现的。在这种情况下，使用多重SAs以实现安全策略是必要的。术语安全关联束或SA束定义为一个SA序列（sequence），传输必须通过它来满足一个安全策略。策略定义了序列的顺序（值得注意的是由束组成的 SA可能终止于不同的端点。例如，一个 SA可以在移动主机、网关和另一个网关之间延展，嵌套的 SA 可以延展到网关后的主机）。
IPSec 策略由安全策略数据库（Security Policy Database，SPD）加以维护。在SPD 这个数据库中，每个条目都定义了要保护的是什么通信、怎样保护它以及和谁共享这种保护。对于进入或离开 IP 堆栈的每个包，都必须检索 SPD 数据库，调查可能的安全应用。对一个 SPD条目来说，它可能定义了下述几种行为：丢弃、绕过以及应用。其中，丢弃表示不让这个包进入或外出；绕过表示不对一个外出的包应用安全服务，也不指望一个进入的包进行了保密处理；而应用是指对外出的包应用安全服务，同时要求进入的包已应用了安全服务。对那些定义了应用行为的SPD 条目，它们均会指向一个或一套SA，表示要将其应用于数据包。
IPSec 通信到IPSec 策略的映射关系是由选择符（Selector）来建立的。选择符标识通信的一部分组件，它既可以是一个粗略的定义，也可以是一个非常细致的定义。IPSec 选择符包括：目标IP地址、源IP 地址、名字、上层协议、源和目标端口以及一个数据敏感级（假如也为数据流的安全提供了一个IPSec系统）。这些选择符的值可能是特定的条目、一个范围或者是待定。在策略规范中，选择符之所以可能出现待定的情况，是由于在那个时刻，相关的信息也许不能提供给系统。举个例子来说，假定一个安全网关同另一个安全网关建立了IPSec 通道，它可指定在该通道内传输的（部分）数据是网关背后的两个主机之间的IPSec通信。在这种情况下，两个网关都不能访问上层协议或端口，因为它们均被终端主机进行了加密。待定也可作为一个通配符使用，表明选择符可为任意值。假定某个 SPD 条目将行为定义为应用，但并不指向SADB 数据库内已有的任何一个SA，那么在进行任何实际的通信之前，首先必须创建那些SA。如果这个规则用于自外入内的进入（Inbound）通信，而且SA尚不存在，则按照IPSec 基本架构的规定，必须丢弃该数据包。假如该规则用于自内向外的外出（Outbound）通信，则通过Internet 密钥交换便可。IPSec 结构定义了SPD 和SADB 这两种数据库之间如何沟通，这是通过IPSec 处理功能——封装与拆封来实现的。此外，它还定义了不同的IPSec 实施方案如何共存。
SA 的管理可以有两种方式，手动管理是最简单的管理方式。个人可以使用键入数据和与安全通信有关的安全连接管理数据，来手动地配置每一个系统。手动技术适用于较小的静态的环境下，但是扩展性不好。例如，一个公司可能在几个站点的安全网关使用IPSec建立一个虚拟专用网。如果站点数目少，因为所有站点都在一个单一的管理域，为手动管理技术提供一个可行的上下文环境。此例中，在使用一个手动配置密钥的组织中，安全网关可以有选择地保护来自和发向其他站点的传输，而不会保护其他目的地的传输。当只有选中的通信需要安全传输时，此法也是合适的。IPSec的使用完全限制在一个只有少量主机或者网关的组织中时，相同的观点也适用。尽管存在其他方法，手动管理技术经常使用静态配置的对称的密钥。
IPSec的广泛传播和使用要求一个Internet标准的、可升级的自动SA管理协议。这样的支持为面向用户和面向会议的加密，可以使AH和ESP抗重播特性的使用更容易，可以供应SA的随选生成（注意对SA二次加密的概念实际上意味着用一个新的SPI生成一个新的SA，通常意味着一个自动 SA/密钥管理协议的使用的过程）。IPSec 使用的缺省自动密钥管理协议是IPSec域解释的Internet 密钥交换（Internet Key Exchange）IKE协议。其他自动SA管理协议也可以使用。当使用一个自动SA/密钥管理协议时，对于一个单一ESP SA，此协议的输出可用来生成多个密钥。出现这种情况是因为：一方面，加密算法或认证算法有可能使用多个密钥（例如，三层的DES）；另一方面，当加密算法和认证算法都被使用时，也需要有多个密钥。密钥管理系统为每一个密钥提供了一个独立的比特串，或者生成一个比特串，所有密钥都从其中取出。如果提供一个单一比特串，则需要保证：将比特串映射到密钥的系统部分在SA两端以相同方式工作。为了保证IPSec实现在SA的每一端为相同密钥使用相同比特，而且不管系统哪部分将比特串分为单个的密钥，加密密钥必须从第一个比特取出而且认证密钥必须从剩下的比特取出。每一个密钥的比特数由相关RFC规范定义。在多加密密钥或者多认证密钥情况下，算法规范必须指定使用提供给算法的单一比特串的相关选择顺序。
二、Internet密钥交换
如上所述，如果对安全关联不进行手动管理，就必须有 Internet 密钥交换（IKE）协议来进行自动的管理。IKE的用途就是在IPSec 通信双方之间，建立起共享安全参数及验证过的密钥（亦即建立安全关联关系）。IKE协议是Oakley和SKEME协议的一种混合，并在由ISAKMP 规定的一个框架内运作。ISAKMP是Internet安全关联和密钥管理协议的简称，即Internet Security Association and Key Management Protocol。ISAKMP定义了包格式、重发计数器以及消息构建要求。事实上，它定义了整套加密通信语言。Oakley和SKEME定义了通信双方建立一个共享的验证密钥所必须采取的步骤。IKE 利用 ISAKMP 语言对这些步骤以及其他信息交换措施进行表述。
IKE 实际上是一种常规用途的安全交换协议，可用于策略的磋商，以及验证加密材料的建立，适用于多方面的需求，如SNMP v3、OSPF v2等。IKE采用的规范是在解释域（Domain of Interpretation，DOI）中制订的。针对IPSec存在着一个名为RFC 2407的解释域，它定义了IKE 具体如何与IPSec SA进行协商。如果其他协议要用到IKE，每种协议都要定义各自的DOI。IKE 采用了安全关联的概念，但IKE SA的物理构建方式却与IPSec SA不同。IKE SA定义了双方的通信形式。举例来说，用哪种算法来加密IKE通信；怎样对远程通信方的身份进行验证；等等。随后，便可用IKE SA在通信双方之间提供任何数量的IPSec SA。因此，假如一个SPD条目含有一个NULL SADB指针，那么IPSec 方案采取的行动就是将来自SPD 的安全要求传达给IKE，并指示它建立IPSec SA。而且如果愿意，亦可使通信对方的身份具有同样的特性。通过一次IKE密钥交换，可创建多对IPSec SA。而且单独一个IKE SA可进行任意数量这种交换。正是由于提供了丰富的选择，才使得IKE除了包容面广以外，还具有高度的复杂性。IKE协议由打算执行IPSec的每一方执行；IKE通信的另一方也是IPSec 通信的另一方。换言之，假如想随远程通信实体一道创建IPSec SA，那么必须将IKE 传达给那个实体，而非传达给一个不同的IKE实体。
IKE协议是基于请求响应来设计的，要求同时存在一个发起者（Initiator）和一个响应者（RESPonder）。其中，发起者要从IPSec 那里接收指令，以便建立一些SA。这是由于某个外出的数据包同一个SPD条目相符所产生的结果。它负责为响应者对协议进行初始化。IPSec的SPD会向IKE指出要建立的是什么，但却不会指示IKE 怎样做。至于IKE以什么方式来建立IPSec SA，要由它自己的策略设定所决定。IKE 以保护组（Protection suite）的形式来定义策略。每个保护组都至少需要定义采用的加密算法、散列算法。由于通信双方决定了一个特定的策略组后，它们以后的通信便必须根据它进行，所以这种形式的协商是两个IKE通信实体第一步所需要做的。双方建立一个共享的秘密时，尽管事实上有多种方式都可以做到，但IKE无论如何都只使用一个Diffie-Hellman交换。进行Diffie-Hellman交换这一事实是必须的。但是，对其中采用的具体参数而言，却是可以商量的。
IKE从Oakley文档中借用了五个组。其中三个是传统交换，对一个大质数进行乘幂模数运算；另外两个则是椭圆曲线组。Diffie-Hellman 交换以及一个共享秘密的建立是 IKE 协议的第二步。Diffie-Hellman交换完成后，通信双方已建立了一个共享的秘密，只是尚未验证通过。它们可利用该秘密（在IKE的情况下，则使用自它衍生的一个秘密）来保护自家的通信。但在这种情况下，却不能保证远程通信方事实上真是自己所信任的。因此，IKE 交换的下一个步骤便是对Diffie-Hellman 共享秘密进行验证，同时理所当然地，还要对IKE SA本身进行验证。IKE定义了五种验证方法：预共享密钥；使用数字签名标准，即DSS的数字签名；使用RSA公钥算法的数字签名；用RSA进行加密的nonce 交换；以及用加密nonce进行的一种校验，它与其他加密的nonce方法稍有区别。我们将IKE SA 的创建称为阶段一，阶段一完成后，阶段二便开始了。
在这个阶段中，要创建IPSEC SA。针对阶段一，可选择执行两种交换。一种叫作主模式（Main Mode）交换，另一种叫作主动模式（Aggressive Mode）交换。其中，主动模式的速度较快，但主模式更显灵活。而阶段二仅能选择一种交换模式，即Quick Mode （快速模式）。
这种交换会在特定的IKE SA 的保护之下，协商拟定IPSec SA（IKE SA 是由阶段一的某种交换所创建的）。在默认情况下，IPSec SA使用的密钥是自IKE 秘密状态衍生的。伪随机nonce 会在快速模式下进行交换，并与秘密状态进行散列处理，以生成密钥，并确保所有SA都拥有独一无二的密钥。
为正确地构建IPSec SA，协议的发起者必须向IKE 指出：在自己的SPD中，哪些选择符与通信的类别相符。这方面的信息将采用身份载荷，在快速模式下进行交换。它对哪些通信可由这些SA 保护进行了限制。
三、安全关联的使用模式
AH和ESP协议可以独立使用，也可以组合使用以提供IPv4和IPv6环境下所需的安全服务。每一个协议支持两种使用模式：传输模式和隧道模式。传输模式 SA是两台主机间的安全连接。在IPv4环境中，原IP数据包如图1所示。传输模式安全协议头紧接在IP 头和任何选项之后，在任何更高层协议之前（例如 TCP 或 UDP），见图2。在 IPv6环境中，安全协议头出现在基本IP头和扩展之后，但也许出现在目的选项的前或后，并在更高层协议之前。在采用ESP时，传输模式SA仅为更高层协议安全服务提供，而不为IP头或任何ESP头以前的扩展头提供服务，见图3。在采用AH时，这种保护也被扩展到IP头的可选部分、扩展头的可选部分和可选项（包括IPv4头、IPv6 Hop-by-Hop扩展头，或IPv6目的扩展头）。
图1 原IP数据包（IPv4）
图2 使用AH之后（IPv4，传输模式）
图3 使用ESP后（IPv4，传输模式）
在 IPv6 环境中，AH/ESP 头被看作是一个端到端的载荷，因而应该出现在逐跳（hop-by-hop）、路由（routing）和分片扩展头（fragmentation extension headers）之后。目的选项扩展头（destination options extension header）既可以出现在AH/ESP头之前，也可以在AH/ESP头之后，这依赖于期望的语义。但是，因为ESP仅保护ESP之后的字段，通常它可能愿意把目的选项头放在ESP头之后。图4～图6图示了典型IPv6分组中AH/ESP传输模式位置。
图4 原IP数据包（IPv6）
图5 使用AH之后（IPv6，传输模式）
图6 使用ESP之后（IPv6，传输模式）
隧道模式SA必然是运用于IP隧道的SA。只要安全连接的任意一端是安全网关，SA就必须是隧道模式。因此两个安全网关之间、主机和安全网关间也必然是隧道模式。注意当安全网关是作为主机提供服务时，例如SNMP命令，这时传输模式是允许的，但在这种情况下，安全网关不再扮演网关的角色，例如它不再转发传输流，两个主机间也可以建立隧道模式SA。由于为了避免IPSec包分段、重组时出现的潜在问题以及这一环境中安全网关后同一目的地存在多重到达路径（例如通过不同的安全网关），对于任意（转发传输流）SA，包括安全网关都应该可以支持隧道模式。
对于隧道模式SA，有外部（outer）IP头、内部（inner）IP头。外部IP头定义了IPSec处理的目的地，内部IP头定义了包最终地址。安全协议头出现在外部IP头后内部IP头前。如果在隧道模式中使用 AH，外部 IP 头的部分将受到保护。同样所有隧道化（tunneled）IP包也受到保护（即所有内部IP头、更高层协议受到保护）。如果使用ESP，则仅对隧道化的包给予保护而不保护外部头。隧道模式中，内部 IP头携带最终的源和目的地址，而外部 IP头可能包含不同的IP地址，例如安全网关地址。隧道模式中，AH保护整个内部IP报文，包括整个内部IP头。相对于外部IP头，隧道模式中AH的位置与传输模式中AH的位置相同。图7～图12说明了典型IPv4和IPv6报文的AH隧道模式的布局。
图7 原IP数据包（IPv4）
图8 使用AH之后（IPv4，隧道模式）
图9 使用ESP之后（IPv4，隧道模式）
图10 原IP数据包（IPv6）
图11 使用AH之后（IPv6，隧道模式）
图12 使用ESP之后（IPv6，隧道模式）
有时需要将AH和ESP联合在一起来提供服务，这时就存在不止一个IPSec头。如果需要不止一个 IPSec 头/扩展，安全头的应用顺序必须被安全策略定义。为了简化处理，每个IPSec头都应该（SHOULD）忽略随后要被应用的IPSec头的存在（即不关心内容或设法预知内容）。IPSec的基本架构定义了用户能以多大的精度来设定自己的安全策略，这样一来，某些通信便可统一设置某一级的基本安全措施；而对其他通信则可谨慎对待，为其应用完全不同的安全级别。举个例子来说，我们可在一个网络安全网关上制订IPSec策略，对在其本地保护的子网与远程网关的子网间通信的所有数据，全部采用DES加密，并用HMAC-MD5进行验证；另外，从远程子网发给一个邮件服务器的所有Telnet 数据均用3DES进行加密，同时用HMAC-SHA 进行验证；最后对于需要加密的、发给另一个服务器的所有Web通信数据，则用IDEA满足其加密要求，同时用HMAC-S安全策略数据库。
安全关联可以通过两种方式组合成束：传输串接（transport adjacency）和嵌套隧道（iterated tunneling）。传输串接指的是对同一个IP报文使用多于一个安全协议，使用传输方式。这种联合AH和ESP的方法只允许一级联合；更多的嵌套并不能增加效益（假设每一个协议中使用了足够强壮的算法），因为这一过程仅被执行于 IPSec最终目的地的 IP 实例处。以传输串接方式组合的安全关联见图13～图15。
图13 原IP数据包（IPv4）
图14 传输串接后的数据包
图15 传输串接
嵌套隧道指的是一种对安全协议的多层次应用，这一安全协议是通过IP隧道实现的。这种方法允许多重叠代，这是因为每一个隧道可能沿着一路径在不同的IPSec站点（IPSec site）开始、结束。除了那些能通过合适的SPD入口被定义的以外，在中间安全网关处对于ISAKMP传输不希望采用特殊的处理。有三种基本的隧道迭代情况，但是只有情况（2），（3）是必须要支持的：
（1）两个SA的两个端点都相同，内部隧道和外部隧道采用 AH或ESP，当然不可能采用两个AH或者两个ESP，如图16所示。
图16 类型1
（2）两个SA的一端是相同的，内部隧道和外部隧道采用AH或ESP，如图17所示。
图17 类型2
（3）两个SA的两个端点都不同，内部隧道和外部隧道采用AH或ESP，如图18所示。
图18 类型3
嵌套隧道也可以和传输串接组合起来提供服务。例如，一个 SA束能由一个隧道模式SA和一个或两个传输模式SA构成应用序列。值得注意的是嵌套的隧道也能发生在任何隧道源或目的端点都不相同的地方。在这种情况下，没有与嵌套隧道相关的带有束的主机或网关存在。
四、ESP
ESP（Encapsulating Security Payload ）属于IPSec 的一种协议，可用于确保IP 包数据的保密性、完整性以及源认证。此外，它也可以用来防范重放攻击。ESP 在 IP 头（以及任何IP 选项）之后，并在要保护的数据之前，插入一个新头，亦即ESP头。受保护的数据可以是一个上层协议，或者是整个IP 数据包。最后，还要在最后追加一个ESP尾。ESP是一种新的 IP 协议，对ESP 数据包的标识是通过IP 头的协议字段来进行的。假如它的值为50，就表明这是一个ESP包，而且紧接在IP头后面的是一个ESP头。RFC 2406对ESP进行了详细的定义。此外，RFC 1827 还定义了一个早期版本的ESP。该版本的ESP没有提供对数据完整性的支持，IPSec工作组现在强烈反对继续使用它。由于ESP同时提供了机密性以及身份验证机制，所以在其 SA中必须同时定义两套算法，一套用来确保机密性的算法（通常被称作 Cipher），另外一套用来进行身份验证（通常用做 authenticator验证器）。每个ESP的SA 都至少有一个加密器和一个验证器。我们也可定义 NULL 加密器或NULL验证器，分别表示ESP不作加密或不作验证。但在一个ESP的SA内，不能同时定义加密器和验证器均为NULL。因为这样做不仅为系统带来了无谓的负担，也毫无安全保证可言。
随ESP 使用的所有加密算法必须以CBC模式工作，CBC要求加密的数据量刚好是加密算法的块长度的整数倍。进行加密时，可在数据尾填充适当的数据来满足这项要求。随后，填充数据会成为包密文的一部分，并在完成了IPSec处理后，由接收端予以剔除。假如数据已经是加密器的块长度的一个整数倍，则不需增加填充内容。CBC模式中的加密器要求一个初始矢量（IV）来启动加密过程，这个 IV 包含在载荷字段内，通常是第一批字节。然而，最终还是要由特定的算法规范来定义IV 在什么地方及其大小。对DES的CBC来说，IV是受保护数据字段的头8个字节。
如前所述，ESP既有一个头，也有一个尾，中间封装了要保护的数据。其中，头部分包含了SPI和序列号；而尾部则包含了填充数据（如果有的话）、与填充数据的长度有关的一个指示符、ESP后的数据采用的协议以及相关的校验码。校验码的长度取决于采用的是何种验证器。此时需采用恰当的实施方案，以同时提供对HMAC-MD5和HMAC-SHA 这两种验证器的正确支持，输出数据的长度是96位。不过，由于HMAC-MD5产生一个128位的摘要，而HMAC-SHA产生一个 160位的摘要，只有摘要的高 96位才被用作ESP的校验码，ESP头格式如图19所示。之所以决定使用96位，是由于它能与IPv6很好地协调。至于将MAC的输出截去一部分是否安全，目前仍然颇有争议。但大多数人都认为，这种做法并不存在先天性的安全问题，而且事实上，它或许还能增大一定的安全系数。ESP规范对随ESP使用的转换方案提出了具体要求，目前，已经有一份文件描述了如何将DES-CBC作为ESP的加密算法使用；另外两份文件则描述了如何利用对 HMAC-MD5和HMAC-SHA输出的截取，来实现对ESP的验证。其他加密算法文档包括Blowfish CBC、CAST-CBC以及3DES-CBC（均可选为最终的实施方案）。
图19 ESP头
下面的部分定义了头格式中的字段。
1、有效数据内容
有效数据内容是变长字段，它包含下一个头字段描述的数据。有效数据内容字段是强制性的，它的长度是字节的整数倍。如果加密算法必须同时加密其他同步数据，如初始化向量（IV），那么这个数据也可以放在有效数据内容字段，但是需要指出同步数据的长度、结构和位置。
2、序列号
序列号是一个32位整数，用来提供抗重播服务。当SA建立时，发送方的计数器初始化为0。发送方为这个SA增加序列号，把新值插入到序列号字段中。因此使用一个给定的SA发送的第一个报文具有的序列号为1。如果抗重播服务被禁止（如手工密钥管理情况下），发送方不需要监视或者把计数器置位。但是，发送方仍然增加计数器的值，当它达到最大值时，计数器返回0开始。
如果激活抗重放服务（默认），发送方要检查以确保在序列号字段插入新值之前计数器没有循环。换言之，发送方不能在一个 SA上发送一个引起序列号循环的报文。企图发送一个可能导致序列号溢出的报文，是一个审计事件（注意这种序列号管理方式不需要使用模运算）。发送方假定抗重放服务是一种默认支持，除非接收方另外通告。因此，如果计数器已经循环，发送方将建立一个新的SA和密钥（除非该SA是由手工密钥管理配置的）。
如果接收方不激活 SA的抗重播服务，将不对序列号进行入站检查。但是从发送方观点来看，默认的是假定接收方激活抗重播服务。为了避免接收方做不必要的序列号监视和 SA建立，如果使用SA建立协议如IKE，在SA建立期间，如果接收方不提供抗重播保护，则接收方应该通告发送方。
接收方使用一个滑动的接收窗口来接收数据，窗口必须支持32位的最小窗口大小；但是首选64位窗口大小，且应该是默认使用的。其他窗口大小（大于最小窗口）由接收方选择，接收方不会通告发送方窗口大小。从性能考虑，窗口大小最好是最终实施IPSec 的那台计算机的字长度的整数倍。窗口最左端对应于窗口起始位置的序列号，而最右端对应于将来的窗口长度个数据包。接收到的数据包必须是新的，且必须落在窗口内部，或靠在窗口右侧。否则将其丢弃。那么，如何判断一个数据包是新的呢？只要它在窗口内是从未出现过的，我们便认为它是新的。假如收到的一个数据包靠在窗口右侧，那么只要它未能通过真实性测试，也会将其丢弃。如通过了真实性检查，窗口便会向右移动，将那个包包括进来。注意数据包的接收顺序可能被打乱，但仍会得到正确的处理。还要注意的是那些接收迟的数据包（也就是说，在一个有效的数据包之后接收，但其序列号大于窗口的长度），会被丢弃。假设一个长度为16位的接收窗口（注意真正的实现中这个长度是不符合规定的）假设最左端的序列号为 N，最右端的序列号自然为N+15 。编号为N+16和N+18以及之后的数据包尚未收到。如果最近收到的数据包 N+17 通过了真实性检查，窗口便会向右滑动一个位置，使窗口左侧变成 N+2，右侧变成 N+17 。这样便会造成数据包 N 无可挽回地被丢弃，因为它现在变成靠在滑动接收窗口的左侧。要注意的一个重点是，除非造成窗口向前滑动的那个包通过了真实性检查，否则窗口是不会真的前进的。不然的话，攻击者便可生成伪造的包，为其植入很大的序列号，令窗口错误移至有效序列号的范围之外，造成我们将有效的数据包错误地丢弃。
3、填充数据
发送方可以增加0～255个字节的填充。ESP分组的填充字段是可选的，但是所有实现必须支持填充字段的产生和消耗。几种因素要求或者激活填充字段的使用：
如果采用的加密算法要求明文是某个数量字节的倍数，例如块加密算法的块大小，使用填充字段填充明文（包含有效数据内容、填充长度和下一个头字段，以及填充）以达到算法要求的长度。
不管加密算法要求如何，也可以要求填充字段来确保结果密文以4字节边界终止。特别是，填充长度字段和下一个头字段必须在4字节字内右对齐，如图19所示的ESP头格式，从而确保校验码字段（如果存在）以4字节边界对齐。
除了算法要求或者上面提及的对齐原因之外，填充字段可以用于隐藏有效数据实际长度，支持（部分）信息流机密性。但是，包含这种额外的填充字段占据一定的带宽，因而应当在必要的时候使用。
如果需要填充字节，但是加密算法没有指定填充内容，则必须采用下列默认处理。填充字节使用一系列（无符号、1字节）整数值初始化。附加在明文之后的第一个填充字节为1，后面的填充字节按单调递增：1，2，3，…。当采用这种填充方案时，接收方应该检查填充字段。选择这种方案是由于它相对简单，硬件实现容易。在没有其他完整性措施实施的情况下，接收方可以通过检查解密的填充值来避免简单的剪切粘贴攻击。
填充长度字段指明紧接其前的填充字节的个数。有效值范围是0～255，0表明没有填充字节。填充长度字段是必须有的。
4、下一个头
下一个头是一个8位字段，它标识有效数据内容字段中包含的数据类型，例如，IPv6中的扩展头或者上层协议标识符。该字段值从IANA定义的IP协议号集当中选择。下一个头字段是必须有的。
5、校验码
校验码是可变长字段，它包含一个完整性校验值（ICV），ESP分组中该值的计算不包含校验码本身。字段长度由选择的校验函数指定。校验码字段是可选的，只有 SA 选择校验服务，才包含校验码字段。校验算法规范必须指定ICV长度、校验的比较规则和处理步骤。
如果选择校验，校验之前首先执行加密，而加密并不包含校验码字段。这种处理顺序易于在分组解密之前，接收方迅速检测和拒绝分组重播或伪造分组，因而潜在地降低拒绝服务攻击的影响。同时它也考虑了接收方并行分组处理的可能性，即加密可以与校验并发执行。校验码基于SPI、序列号、有效数据内容、填充（如果存在）、填充长度和下一个头字段都包含在ICV计算中。由于加密比验证先执行，最后4个字段将是密文形式。
一些验证算法中，ICV计算实现所使用的字节串必须是算法指定的块大小的倍数。如果这个字节串长度与算法要求的块大小不匹配，必须在ESP分组末端添加隐含填充（下一个头字段之后），在ICV 计算之前添加。填充八位组必须是 0值。算法规范指定块大小（和因此的填充长度）。这个填充不随分组传输。注意MD5和SHA-1内部填充协定，它们被看作有1字节的块大小。
构建ESP头的确切步骤依赖于模式（传输或者隧道），首先将数据封装到ESP有效数据内容字段，在传输模式中，这些数据只包含原始上层协议信息，而对于隧道模式，则包含整个原始IP数据包。然后将增加所有需要的填充。在使用SA指明的密钥、加密算法、算法模式和加密同步数据（如果需要）加密结果后，如果需要进行校验，再生成校验码。
如果需要，IPSec实现内部ESP处理之后执行分片。因此传输模式ESP应用于整个IP数据报（而不是IP片段）。ESP处理过的分组本身可以在途中由路由器分片，这样的片段接收方必须在ESP处理之前重组。隧道模式时，ESP应用于一个IP分组，它的有效数据内容可能是一个已分片的IP分组。
在收到ESP数据包之后，如果提供给ESP处理的分组是一个IP分片，即OFFSET字段值非0，或者MF 标志位置位，接收方必须丢弃分组；这是可审核事件。该事件的核查日志表项应该包含SPI的值、接收日期/时间、源地址、目的地址、序列号和（IPv6）信息流ID。收到一个（已重组的）包含ESP头的分组时，根据目的IP地址、安全协议（ESP）和SPI，接收方确定适当的（不定向的）SA。SA指出序列号字段是否被校验，校验码字段是否存在，它将指定解密和ICV计算（如果适用）使用的算法和密钥。
如果本次会话没有有效的SA存在（例如接收方没有密钥），接收方必须丢弃分组；这是可审核事件。该事件的核查日志表项应该包含SPI的值、接收的日期/时间、源地址、目的地址、序列号和（IPv6）明文信息流ID。
如果选择验证，接收方采用指定的验证算法对ESP分组计算ICV但不包含校验码字段，确认它与分组校验码字段中包含的ICV相同。如果计算得来的与接收的ICV匹配，那么数据包有效，可以被接收。如果测试失败，接收方必须将接收的IP数据包丢弃；这是可审核事件。日志数据应该包括SPI值、接收的日期/时间、源地址、目的地址、序列号和（IPv6中）明文信息流ID。
最后，接收方采用 SA指明的密钥、加密算法、算法模式和加密同步数据（如果存在）解密ESP有效数据内容、填充、填充长度和下一个头。在这里，如果指明显式加密同步数据，例如IV，则从有效数据字段得到加密同步数据，并按照算法规范将其输入到解密算法中；如果指明是隐式加密同步数据，例如 IV，则构建本地版本 IV，并按照算法规范将其输入到解密算法中。然后接收方处理所有加密算法规范中指定的填充：如果采用默认的填充方案，接收方应该在把已解密数据传送给下一层之前，以及删除填充之前，检查填充字段。这样就可以重新构建原始IP数据包了。
重新构建原始数据包的确切步骤依赖于模式（传输或者隧道），最小程度上，IPv6 环境中，接收方应该确保已解密数据是8字节对齐，使下一个头字段标识的协议更容易进行处理。
五、验证头（AH）
与ESP类似，AH也提供了数据完整性、数据源验证以及抗重播攻击的能力，但注意不能用它来保证数据的机密性。正是由于这个原因，AH头比ESP简单得多。AH只有一个头，而非头尾皆有。除此以外，AH头内的所有字段都是一目了然的。RFC 2402定义了最新版本的AH，而RFC 1826定义的是AH的一个老版本，现已明确不再推荐对它提供支持。在那份RFC文件中指定的AH 的重要特性仍在新文件中得到了保留：亦即保证数据的完整性以及对数据源的验证。此外，自RFC 1826问世以来，还出现了一些新的特性和概念上的澄清，它们都已加入新文件。例如，抗重播保护现已成为规范不可分割的一部分，同时增加了在隧道模式中使用AH 的定义。
和 ESP 头相似，AH 头也包含一个 SPI，为要处理的包定位 SA；一个序列号，提供对重播攻击的抵抗；另外还有一个校验码字段，包含着用于保留数据包的加密 MAC 的摘要。和ESP 相同，摘要字段的长度由采用的具体编码方案决定。但不太一样的是，AH默认的、强制实施的加密MAC是HMAC-MD5和HMAC-SHA，两者均被截短为刚好96位。定义了如何将 MAC 应用于 ESP 的同样两份文件（定义 HMAC-MD5-96 的 RFC 2403 以及定义HMAC-SHA-96的RFC 2404）也定义了如何将它们应用于AH。由于AH并不通过CBC模式下的一个对称加密算法来提供对数据机密性的支持，所以没有必要对其强行填充数据，以满足长度要求。有些MAC可能需要填充（如DES-CBC-MAC），但至于具体的填充技术资料，则留待对MAC 本身进行描述的文件加以定义。
AH 的验证范围与ESP有区别。AH验证的是IPSec包的外层IP头。因此，AH文件对IPv4 及 IPv6 那些不定的字段进行了说明，比如，在包从源传递到目的地的过程中，可能会由路由器进行修改。在对校验码进行计算之前，这些字段首先必须置零。AH 文件定义了AH头的格式、采用传输模式或隧道模式时头的位置、对输出数据如何处理、对输入数据如何处理以及另外一些相关信息，比如分段及重组。相对于ESP来说，AH的必要性在于在不采用隧道模式的情况下，ESP不保护任何IP头字段。
AH协议头（IPv4、IPv6，或者扩展）格式如图20所示，它的协议值为51。下一个头（Next Header）、SPI、序列号都已经在前面描述过了，我们这里只介绍一下内容长度字段、保留字段和校验码字段。
图20 AH
1、内容长度（Payload Length）
这个8比特的字段指定了AH的长度减去2，以32比特（4个字节）为单位。这是因为，所有的IPv6扩展头，按照RFC 1883，首先从头长度（以64比特量度）减1（64比特），再编码头扩展长度（Hdr Ext Len）字段。AH是一个IPv6扩展头，但是它的长度是以32比特量度，计算内容长度（Payload Length）时应该减2（32比特为单位）。在一般情况下，一个96比特认证值加上3个32比特的固定部分，则这个长度将会是“4”（3+3-2=4）。一个为空（NULL）的认证算法可能只用于调试目的。使用它会导致这个字段的值在 IPv4 中为 1 或者在IPv6中为2。
2、保留（Reserved）
这个16比特的字段保留给将来使用。它必须被设置成“零”（注意，这个值被包括进认证数据的计算，但是它会被接收者忽略）。
3、校验码（Authentication Data）
这是一个变长的字段，其包含这个报文的完整性校验值（Integrity Check Value，ICV）。这个字段的长度必须是32比特的整数倍。这个字段可以包含显式的填充，该填充被包括进来以确保AH头的长度是32比特（IPv4）或64比特（IPv6）的整数倍，所有实现必须支持这种填充。关于如何计算必须的填充长度的细节将在下面提供。认证算法规范必须规定ICV的长度、比较规则和验证的处理步骤。
AH的ICV是对下面数据进行计算：
IP头字段，其或者在传输中不变，或者其在到达AH的SA的端点上的值是可预测的
AH 头（下一个头、载荷长度、保留、SPI，序列号、认证数据（其在这个计算中设置成0）和显式的填充字节（无论什么））
上层协议数据，假定其在传输过程中是不变的
如果一个字段在传输期间可以被修改，则用于计算ICV时该字段的值被设置成0。如果一个字段是可变的，但该字段的值在（IPSec）接收方是可预知的，那么用于计算ICV时那个值要被填入到该字段中。在准备计算ICV时认证数据字段也被设置成 0。注意，通过用 0替换每个字段中的值，而不是忽略这些字段，是为ICV计算保持对齐。同样，填0的方法确保了这些因此而处理的字段的长度不会在传输期间被改变，即使它们的内容不是显式地被ICV所覆盖。
（1）IPv4中的ICV计算
IPv4基本头的字段按下面来分类：
①不变的：版本、头长度、总长度、ID值、协议（其值应该是AH）、源地址、目的地址（没有松散的或严格的源路由）。
②可变但可预知的：目的地址（没有松散的或严格的源路由）。
③可变的（在计算 ICV 之前设置为零）：服务类型（TOS）、标志、片偏移、生存时间（TTL）、首部校验和。理由是：
TOS：这个字段被排除在外是因为已知一些路由器会改变这个字段的值，尽管 IP 规范不认为TOS是一个可变的头字段。
标志：这个字段被排除在外是因为一个中间的路由器可能会设置DF位，即使报文源并没有设置它。
片偏移：因为AH只被应用于非分片的IP报文，所以片偏移必须总是零，因此该字段被排除在外（即使该字段是可预知的）。
TTL：这个字段的值在路由期间会被路由器作为一个标准处理过程而改变，因此该字段在接收方的值对发送方是不可预知的。
首部校验和：这个字段的值会因为任何其他字段的改变而改变，因此该字段在接收方的值对发送方是不可预知的。
对于IPv4（不同于IPv6），没有机制来标记在传送中可变的选项。因此IPv4的选项被分类成不变的、可变的但又可预知的，或可变的。对于IPv4，整个选项被看作一个单元；所以即使大多数选项中的类型和长度字段在传送中是不变的，但如果有一个选项是属于可变的，则整个选项用于计算ICV时都要清为零。
（2）IPv6中的ICV计算
IPv6基本头的字段可以分成下面几类：
①不变的：版本、载荷长度、下一个头（其值应该是AH）、源地址（Source Address）、目的地址（没有路由扩展头）。
②可变但可预知的：目的地址（没有路由扩展头）。
③可变的（在ICV计算之前清零）：类别、流标签、跳极限。
在逐跳（Hop-by-Hop）和目的扩展头（Destination Extension Headers）中的IPv6选项包含有一个比特，该比特指出选项在传送过程中是否会改变（不可预知的）。对于在路由过程中内容可能变换的任何选项，整个选项数据（Option Data）字段在计算和校验ICV时必须被当作零值的字节串对待。选项类型（Option Type）和选项数据长度（Opt Data Len）被包括进ICV计算。由比特位确定为不变的所有选项都被包括进ICV计算。
由于认证数据字段显式地包括了填充，以确保AH头是32比特（IPv4）或64比特（IPv6）的整数倍。如果需要填充，其长度由下面两个因素决定：ICV 的长度和 IP 协议版本（v4或v6）。
例如，如果所选择的算法的输出是96比特，则对于IPv4和IPv6都不需要填充。但是，如果产生了一个不同长度的 ICV，由于使用了一个不同的算法，那么根据 ICV 长度和IP协议版本可能就需要填充。填充字段的内容由发送方任意选择（填充是任意的，但不必是满足安全性的随机数）。这些填充字节被包括进认证数据计算，作为载荷长度的一部分被计算在内，并且放在认证数据字段的最末端传送，使得接收方能够执行ICV计算。
对于某些认证算法，进行ICV计算所需要的字符串必须是由算法指定的块大小的整数倍长。如果IP报文长度（包括AH）并不匹配算法要求的块大小，隐式的填充就必须被添加到报文的结尾，在ICV计算之前。填充的字节必须置为零。块大小（和由此而来的填充长度）是由算法规范指定的。这个填充并不随着报文一同被发送出去。注意，由于 MD5和 SHA-1内在的填充惯例，它们被看作是只有1个字节的块大小。
接收方在AH处理之前要进行重组。如果提供给AH处理的一个报文看来是一个IP分片，即偏移量（OFFSET）字段值非0，或者MF（MORE FRAGMENTS）标志位置位，接收方必须丢弃该报文；这是一个可审计的事件。该事件的审计日志表项应该包含SPI值、接收日期/时间、源地址、目的地址和（IPv6中的）流ID。
然后接收方根据目的IP地址、安全协议（AH）和SPI，来确定适当的（单向的）SA。如果本次会话没有有效的安全关联存在（例如接收方没有密钥），接收方必须丢弃该报文；这是一个可审计的事件。该事件的审计日志表项应该包含SPI值、接收的日期/时间、源地址、目的地址和（IPv6中的）流ID。最后接收方采用指定的认证算法对报文适当的字段计算ICV，并且校验它与报文的认证数据字段中包含的 ICV 是否相同。如果计算得到的 ICV 与收到的ICV匹配，那么数据包是有效的，可以被接受。如果检验失败，接收方必须将收到的IP数据包作为非法的而丢弃；这是一个可审计的事件。该审计日志数据应该包括SPI值、接收的日期/时间、源地址、目的地址和（IPv6 中的）明文流 ID。接收方采用的基于序列号的抗重播方法和ESP中基本相同。
微信公众号：计算机与网络安全
ID：Computer-network