IPsec 图解指南_ipsec的详细图解-CSDN博客

An Illustrated Guide to IPsec

1. 这么多口味…

在这里插入图片描述
在尝试设置IPsec时，人们会注意到的第一件事是存在许多控制和设置选项：即使是一对完全符合标准的实现，也会有多种令人眼花缭乱的方式阻碍成功连接。它只是一套极其复杂的协议。

IPsec 复杂的原因之一是它提供的是机制（mechanism），而非策略（policy）：它并没有定义某种加密算法或特定的认证函数，而是提供了一个框架，允许实现提供双方都同意的几乎任何东西。

在本节中，我们将以词汇表的形式介绍一些项目，并通过比较和对比的方式展示这些术语之间的关系。这远远不是全部内容。

AH 与 ESP

“身份验证头” (AH：Authentication Header) 和 “封装安全负载”(ESP：Encapsulating Security Payload) 是 IPsec 中使用的两个主要的线路层（wire-level）协议，它们用于验证(AH) 和加密+验证(ESP)通过该连接传输的数据。它们通常是独立使用的，尽管可以同时使用它们两个，但这种情况比较少见。

隧道模式与传输模式

传输模式提供了两个端点之间的安全连接，因为它封装了 IP 的有效载荷，而隧道模式封装整个 IP 数据包，以在两个网关之间建立一个虚拟的“安全跳跃（secure hop）”。后者用于形成传统的 VPN，在这种情况下，隧道通常在不可信的互联网上创建一个安全通道。

MD5 与 SHA-1 与 DES 与 3DES 与 AES 与等等等

建立一个 IPsec 连接涉及各种加密选择，但由于每个连接最多可以同时使用两个或（很少）三个加密选项，这大大简化了问题。

身份验证通过计算数据包内容的完整性检查值(ICV：Integrity Check Value )来实现，它通常建立在加密哈希（如 MD5 或 SHA-1）之上。它包含一个两端都知道的密钥，这允许接收者以相同的方式计算 ICV。如果接收方获得相同的值，则发送方已有效地对自己进行了身份验证（依靠加密哈希无法被反向实现的原理）。AH 始终提供身份验证，而 ESP 可以选择这样做。

加密使用密钥在传输前对数据进行加密，这样可以隐藏数据包的实际内容，防止窃听者访问。这里的算法有很多选择，DES、3DES、Blowfish 和 AES 很常见。其他的也是可能的。

IKE密钥与手动密钥

由于会话的双方都需要知道用于哈希或加密的密钥值，所以数据交换的方式是一个问题。手动密钥需要在双方进行手动输入密钥值，通常通过某种带外（out-of-band）机制传递，而IKE（Internet Key Exchange）是一种在线进行此操作的复杂机制。

主模式和积极模式（又称快速模式）

这些模式在初始的IKE密钥交换过程中控制了效率与安全性之间的权衡。"主模式（Main mode）"需要来回传输六个数据包，但在建立IPsec连接期间提供了完全的安全性，而积极模式（Aggressive mode）则只需要一半的交换步骤，安全性稍低一些，因为一些信息以明文传输。

当我们深入研究IPsec时，我们肯定会面临更多选择。

IP 数据报

由于我们从底层开始研究IPsec，我们首先必须简要回顾一下IP头本身，它承载了我们将要考虑的所有流量。请注意，我们并不打算对IP头提供全面的覆盖，因为还有其他出色的资源可供参考（其中最好的是《TCP/IP详解》第一卷）。
在这里插入图片描述

ver

这是协议的版本，现在是 4=IPv4
hlen

IP头长度为4位数字，表示以32位字（words）为单位的字数，范围从0到15。标准的IPv4头始终为20个字节长（即5个字），如果有IP选项，则可以通过更大的hlen字段指示最多60个字节的长度。此头长度不包括其后跟随的有效负载或其他头的大小。
TOS

服务类型

此字段是一个位掩码，它提供了有关此数据报应接收的服务类型的一些线索：针对带宽进行优化？延迟？成本低？可靠性？
pkt len

总数据包长度以字节为单位，最多为65535字节。这个计数包括头部的字节，因此这意味着任何有效负载的最大大小至少要少20字节。绝大多数IP数据报要小得多。
ID

ID字段用于关联已经分段(fragment)的相关数据包（大数据包分成较小的数据包）。
flgs

这些是用于主要控制分段(fragment)的小标志：其中一个标志将数据包标记为不适合分段，另一个表示后续会有更多分段。
frag offset

当数据包被分段( fragmented)时，这个字段用于指示该分段在整个“虚拟”数据包中的位置。
TTL

这是生存时间（Time to Live），每个经过该数据包的路由器会递减该值。当该值减至零时，表明可能出现了某种路由循环，因此将其丢弃为了防止数据包永远在互联网上循环。
proto

这个字段代表了该数据包中承载的协议，它将是我们大多数讨论的核心。尽管数据报本身是IP协议，但它总是通过封装一个附属协议（如TCP、UDP、ICMP等）来传输数据。你可以将其理解为提供了随后头部的类型。
header cksum

这个字段保存整个IP头部的校验和，用于检测传输过程中的错误。它不是加密校验和，并且不包括IP头部后面任何数据报的部分。
src IP address

该字段为 32 位源 IP 地址，接收方可以使用该地址回复该数据报。通常情况下，攻击者可以伪造该地址（也就是伪造该数据报的来源地址）。
dst IP address

32 位目标 IP 地址，这是数据包要到达的位置。
IP Options

这些是IP头部的可选部分，包含应用程序特定的信息，尽管它们在常规流量中不常用。如果IP选项存在，它们以头部长度（hlen）大于5来标示，并且（如果存在）会包含在头部校验和中。
Payload

每种协议类型都有自己的格式，跟随在IP头部之后。我们在这里使用TCP只是为了举例说明。

这些协议代码由 IANA（互联网数字分配机构( Internet Assigned Numbers Authority)）定义，远远超过任何单个安装所使用的数量，但是大多数网络技术人员都会对其中的很多类型感到熟悉。这些代表性类型来自于 IANA 网站上列出的协议：

一些IP 协议代码

协议代码	协议描述
1	ICMP — Internet Control Message Protocol
2	IGMP — Internet Group Management Protocol
4	IP within IP (a kind of encapsulation)
6	TCP — Transmission Control Protocol
17	UDP — User Datagram Protocol
41	IPv6 — next-generation TCP/IP
47	GRE — Generic Router Encapsulation (used by PPTP)
50	IPsec: ESP — Encapsulating Security Payload
51	IPsec: AH — Authentication Header

我们将详细研究最后两个。

AH：仅认证

AH（认证头）用于对 IP 流量进行认证（authenticate），但不进行加密，它有三个主要目的：确保我们真正与我们认为的对方进行通信，检测在传输过程中的数据篡改，并且（可选地）防止攻击者捕获数据后进行重放攻击，将数据重新注入到网络中。

认证是通过对 IP 数据包的几乎所有字段(排除那些在传输过程中可能被修改的字段，如 TTL 或首部校验和(checksum))计算基于密码哈希的消息认证码来完成的，然后将其存储在新增的 AH 头部并发送到另一端。

这个 AH 头部仅包含五个有意义的字段，并且被插入在原始 IP 头部和有效载荷之间。我们在这里会简要介绍每个字段，尽管在看到它们在更大的情景中如何使用之前，它们的实用性可能不会完全显现出来。
在这里插入图片描述

next hdr

这个字段标识了接下来有效载荷的协议类型，并且它是被封装的原始数据包类型：这就是 IPsec 头部之间的链接方式。’
AH len

它定义了整个 AH 头部的长度，以 32 位字为单位，减去两个字（这个“减去两个字”的规定源自 IPv6 的 RFC 1883 扩展头部的格式，其中 AH 是其中之一）。

Reserved

这个字段保留供将来使用，必须为零。

Security Parameters Index

这是一个不透明的 32 位标识符，可帮助收件人选择此数据包可能应用的许多正在进行的对话中的哪一个。每个受 AH 保护的连接都意味着哈希算法（MD5、SHA-1 等）、某种机密数据和许多其他参数。SPI可以看作是这些设置表的索引，允许轻松地将数据包与参数关联起来。

Sequence Number

这是一个单调递增的标识符，用于帮助进行抗重放攻击的保护。这个值被包含在认证数据中，因此可以检测到修改（无论是有意还是无意）。

Authentication Data

这是对整个数据包进行计算的完整性校验值，包括大部分的头部。接收者重新计算相同的哈希值；不匹配的值将标记该数据包在传输过程中被损坏，或者没有正确的密钥。这些数据包将被丢弃。

传输模式

最容易理解的模式是传输模式（Transport Mode），它用于保护两个主机之间的端到端通信。这种保护可以是身份验证（authentication）、加密（encryption）或二者兼有，但它不是一种隧道协议。它与传统的 VPN 没有任何关系：它只是一个安全的 IP 连接。
在这里插入图片描述

在AH传输模式中，IP数据包只进行轻微修改，以在IP头部和协议负载（TCP、UDP等）之间包含新的AH头部，并且对将各种报头链接在一起的协议代码进行了重新排列。

这种协议重新排列是为了在另一端重新组装原始IP数据包。在接收到IPsec头部并经过验证后，它们将被剥离，原始协议类型（TCP、UDP等）将被存储回IP头部。在我们研究IPsec时，我们将一遍又一遍地看到这条 下一个头（ next header） 部字段的链。

当数据包到达目标位置并通过身份验证检查时，AH头部将被移除，IP头部的 Proto=AH 字段将被替换为保存的“Next Protocol”。这将使IP数据报恢复到其原始状态，并且可以将其传送到等待的进程。

隧道模式

隧道模式（Tunnel Mode）形成了更为常见的 VPN 功能，在这种模式中，整个IP数据包被封装在另一个包中，并传递到目的地。

与传输模式相似，数据包用完整性检查值进行封装以验证发送方并防止在传输过程中进行修改。但与传输模式不同的是，隧道模式封装了完整的 IP 头部以及有效载荷，这使得源地址和目标地址可以与封装数据包的地址不同：这允许创建一个隧道。
在这里插入图片描述
当隧道模式的数据包到达目的地时，它将像任何 AH 类型的数据包一样经过相同的身份验证检查，并且通过检查的数据包的整个 IP 和 AH 头将被剥离。这有效地重建了原始 IP 数据报，然后将其注入到常规的路由过程中。

大多数实现将隧道模式端点视为虚拟网络接口，就像以太网接口或本地主机一样，进入或离开它的流量受到所有普通路由决策的影响。

重新组装的数据包可以被传递到本地计算机或路由到其他位置（根据封装数据包中的目标 IP 地址），但在任何情况下都不再受 IPsec 的保护。此时，它只是一个常规的 IP 数据报。

虽然传输模式严格用于在两台计算机之间安全地建立端到端连接，但隧道模式更常用于网关（路由器、防火墙或独立的 VPN 设备）之间，以提供虚拟专用网络 (VPN)。

运输模式还是隧道模式？

奇怪的是，IPsec中没有显式的“模式”字段：传输模式与隧道模式的区别在于 AH 头部中的 下一个头部（next header） 字段。
在这里插入图片描述

当 next-header 值为 IP 时，表示此数据包封装了整个 IP 数据报（包括独立的源 IP 地址和目标 IP 地址，这些地址允许在解封装后进行单独的路由）。这就是隧道模式。

任何其他值（TCP、UDP、ICMP 等）都表示它处于传输模式，并且正在保护终点到终点(endpoint-to-endpoint)连接。

无论是哪种模式，IP 数据报的顶层结构都是相同的。中间路由器会以相同的方式对待所有类型的 IPsec/AH 流量，而不进行深入检查。

我们需要注意的是，主机(而不是网关)需要同时支持传输模式和隧道模式，但在创建主机到主机连接时，使用隧道模式似乎有点多余。

此外，网关（路由器、防火墙等）只需要支持隧道模式，尽管支持传输模式只有在创建与网关本身的端点时才有用，比如网络管理功能的情况。

身份验证算法

AH在头部的认证数据部分携带有 完整性校验值（ICV:Integrity Check Value），通常（但不总是）基于诸如MD5或SHA-1等标准的加密散列算法构建。

它使用了 哈希消息认证码（HMAC: Hashed Message Authentication Code），而不是使用简单的校验和，这样可以提供更好的安全性来防止故意篡改。HMAC在创建ICV时会结合一个秘密值。虽然攻击者可以轻易地重新计算哈希，但没有正确的秘密值，他将无法重建正确的ICV。

HMAC由RFC 2104描述，并且下面的示例说明了消息数据和秘密值是如何对最终完整性校验值产生影响的：

RFC 2104 描述了 HMAC，下图显示了消息数据和密钥如何影响最终的完整性检查值（ICV）：
在这里插入图片描述

我们需要注意的是，IPsec/AH并没有定义必须使用什么样的身份验证函数，而是提供了一个框架，允许双方协商一致后使用任何合理的身份验证实现。只要双方都支持，就可以使用其他身份验证函数，例如数字签名或加密函数。

AH 和 NAT 不可能发生

虽然AH提供了非常强大的数据包内容保护，因为它覆盖了一切可能被视为不可变的内容，但是这种保护是有代价的：AH与NAT（网络地址转换，Network Address Translation）不兼容。
在这里插入图片描述

NAT被用于将一个范围的私有地址（例如，192.168.1.X）映射到（通常是）较小的一组公共地址，并因此减少了对可路由的公共 IP 空间的需求。在这个过程中，NAT设备会在传输过程中实时修改 IP 头，改变源 IP 地址和/或目标 IP 地址。

当更改源或目标IP地址时，会强制重新计算标头校验和。这个过程必须进行，因为NAT设备通常在源和目标之间作为路径中的一个"跃点（hop）"，这需要减少TTL（存活时间:Time To Live）字段。

由于TTL和头部校验和字段总是在传输过程中被修改，因此 AH 知道将它们排除在覆盖范围之外，但这不适用于 IP 地址。IP 地址将包含在完整性校验值（ICV）中，任何修改都将导致接收方在验证时失败。由于ICV包含了一个对中间方不知道的私有密钥，NAT路由器无法重新计算ICV。

同样的困难也适用于PAT（端口地址转换：Port Address Translation），它将多个私有IP地址映射到一个外部IP地址。不仅要实时修改IP地址，还要修改UDP和TCP端口号（甚至可能包括有效负载）。这需要 NAT 设备具有更高的智能性，并对整个 IP 数据报进行更广泛的修改。

因此，无论是隧道模式还是传输模式下，AH 都与 NAT 完全不兼容。只有当源和目标网络可以无需转换即可到达时，才能使用 AH。

需要注意的是，这个特定的困难并不适用于 ESP，因为 ESP 的认证和加密不包含被 NAT 修改的 IP 标头。尽管如此，NAT 仍然给 ESP 带来了一些挑战。

NAT 会即时转换 IP 地址，但它必须跟踪哪些连接流经它，以便回复可以与源正确关联。使用 TCP 或 UDP 时，这通常使用端口号（无论是否动态重写）来完成，但IPsec没有提供允许此操作的接口。

起初，人们可能会怀疑SPI，因为它似乎是一个有用的标识符，但由于SPI在两个方向上都不同，NAT设备无法将返回的数据包与出站连接关联起来。

解决此问题需要特殊的 NAT 遍历工具，本文未对此进行介绍。

ESP — 封装安全负载

添加加密使得ESP（Encapsulating Security Payload）更加复杂，因为封装围绕有效负载，而不是像AH一样在其之前：ESP包括头部和尾部字段以支持加密和可选的认证。它还提供了隧道模式和传输模式，使用的方式已经很熟悉了。
在这里插入图片描述

IPsec的RFC并不坚持使用特定的加密算法，但我们通常会使用DES、3DES、AES和Blowfish来保护有效负载不受窥视。用于特定连接的算法由安全关联（在后面的章节中介绍）指定，该安全关联（Security Association）不仅包括算法，还包括使用的密钥。

与AH不同，AH在有效负载之前提供了一个小的头部，而ESP将其保护的有效负载包围起来。安全参数索引（Security Parameters Index）和序列号的作用与 AH 中的用途相同，但是我们发现填充（padding）、下一个头部（next header）和可选的认证数据（Authentication Data）位于ESP Trailer的末尾。

可以使用ESP而不进行任何实际加密（使用NULL算法），但它仍然以相同的方式构建数据包。这不提供机密性，并且只有在与 ESP 身份验证结合使用时才有意义。在没有加密或身份验证的情况下使用 ESP 是没有意义的（除非只是进行协议测试）。

填充是为了使基于块的加密算法（block-oriented encryption algorithms）具有其块大小的倍数的空间，填充长度在 pad len 字段中提供。下一个头部（next hdr）字段以通常的方式给出有效负载的类型（IP、TCP、UDP等），尽管它可以被认为是指向数据包的“后方（backwards）”，而不是我们在AH中所看到的向前指向。

除了加密之外，ESP还可以选择性地提供认证，其 HMAC 与 AH 中的 HMAC 相同。然而，与 AH 不同的是，此认证仅适用于ESP头部和加密的有效负载：它不涵盖整个IP数据包。令人惊讶的是，这并不会实质性地削弱认证的安全性，但它确提供了一些重要的好处。
在这里插入图片描述
当外部人士检查包含ESP数据的IP数据包时，除了IP头中的常用数据（特别是源IP地址和目标IP地址）之外，基本上不可能对内部的内容做出任何真实的猜测。攻击者肯定会知道这是ESP数据（也在头部中），但有效负载类型是使用有效负载进行加密的。

即使通过查看数据包本身，也无法确定认证数据的存在与否（这个确定是通过使用安全参数索引来引用对于此连接的 预共享参数（preshared set of parameters） 和算法集合来实现的）。

然而，值得注意的是，有时封包提供了有效负载没有的提示。随着越来越多的人通过互联网发送VoIP，QoS标签位于外部头部，并且非常明显地知道哪些流量是 VoIP 信令（IP 优先级 3），哪些是 RTP 流量（IP 优先级 5）。尽管这并非确定的事实，但在某些情况下，它可能足以成为重要的线索。

传输模式下的 ESP

与AH一样，传输模式仅封装数据报的有效负载，专为主机到主机通信设计。原始的IP头保持不变（除了重新设置的协议字段），这意味着源IP地址和目标IP地址等信息保持不变。
在这里插入图片描述

隧道模式下的 ESP

我们最后来看一下独立的ESP的隧道模式，它将整个IP数据报封装在加密外壳内：
在这里插入图片描述

提供加密的隧道模式连接非常接近于传统的VPN（虚拟专用网络），当我们大多数人想到IPsec时，VPN是我们首先想到的，但我们必须添加某种类型的身份验证来完成整个过程：这将在接下来的部分中介绍。

与AH不同，对于AH观察者可以很容易地判断流量是处于隧道模式还是传输模式，而此信息在这里不可用：这是因为隧道模式（通过 next=IP）的事实是加密有效负载的一部分，对于无法解密数据包的人来说根本不可见。

将它们整合在一起：建立一个真正的VPN

在对认证头部和封装安全负载进行了全面的介绍后，我们已准备启用加密和身份验证来构建一个真正的VPN。虚拟专用网络（VPN, Virtual Private Network ）的全部目的是通过不受信任的中间网络连接两个受信任的网络，就像在两者之间串起一根很长的以太网电缆一样。这通常用于连接分支机构和公司总部，允许所有用户共享敏感资源，而不必担心被拦截。
在这里插入图片描述

显然，安全的VPN需要身份验证和加密。我们知道 ESP 是提供加密的唯一方法，但 ESP 和 AH 都可以提供身份验证：我们使用哪一个？

在技术上，将ESP封装在AH内部显然是可行的解决方案，但在实际中并不常见，这是因为AH相对于网络地址转换存在一些限制。如果使用AH+ESP，该隧道将无法成功通过进行NAT处理的设备。

取而代之的是，在隧道模式中使用ESP+Auth来完全封装穿越不可信网络的流量，同时使用加密和身份验证来保护它们。
在这里插入图片描述

以这种方式保护的流量对于入侵者几乎没有提供有用的信息，除了这两个站点通过VPN连接的这一事实。这些信息可能有助于攻击者了解信任关系，但是实际流量本身的信息则不会被透露。即使是封装协议的类型（TCP、UDP 或 ICMP）也对外界隐藏。

这种操作模式的一个特别好处是，最终用户主机通常对所采取的VPN或其他安全措施一无所知。由于由网关设备实现的VPN将VPN视为另一个接口，因此发送到目标端的流量将按正常路由。

这种 “套娃” 的封包实际上可以嵌套更多层级：主机 A 和主机 B 可以建立自己的身份验证连接（通过 AH），并通过 VPN 路由。这将使得AH内部的封包嵌套在一个包含ESP+认证的封包中。

更新 - 即使使用加密，使用身份验证也很重要，因为仅加密实现会受到有效攻击，如论文 Cryptography in Theory and Practice： The Case of Encryption in IPsec 中所述;有关更多信息，请参见参考资料部分。

涉及其他事项

IPsec是一个非常复杂的协议套件，本技术提示无法对其的大部分内容做出详尽的介绍。在本节中，我们将提及一些需要更详细探讨的领域。

安全关联和 SPI

显而易见的是，如果两个端点或网关要建立安全连接，则需要某种共享密钥来为身份验证功能和/或加密算法提供密钥。这些秘密是如何建立的，这是一个有待在其他地方讨论的重要话题，为了这次讨论的目的，我们只假设钥匙已经神奇地落在了它们所属的地方。

当一个IPsec数据报（无论是AH还是ESP）到达一个接口时，接口如何知道要使用哪组参数（密钥、算法和策略）？任何一个主机都可能有多个正在进行的会话，每个会话都有不同的密钥和算法，必须有某种方式指导这个过程。

这由安全关联（Security Association，SA）来指定，SA是包含特定连接参数的集合，每个合作伙伴可以拥有一个或多个安全关联。当一个数据报到达时，将使用三条数据在安全关联数据库（SADB:Security Associations Database）中查找正确的 SA：

Partner IP address （合作伙伴 IP 地址）
IPsec Protocol (ESP or AH) （IPsec 协议（ESP 或 AH））
Security Parameters Index （安全参数索引）

在许多方面，这个三元组可以类比为一个IP套接字，它通过远程IP地址、协议和端口号来唯一标识。

安全关联是单向的，因此双向连接（典型情况）至少需要两个。此外，每个协议（ESP/AH）在每个方向上都有自己的 SA，因此完整的 AH+ESP VPN 需要四个安全关联。这些都保存在安全关联数据库(SADB)中。

在SADB中储存了大量的信息，我们只能触及其中的一部分：

AH: authentication algorithm (认证算法)
AH: authentication secret (认证秘钥)
ESP: encryption algorithm (加密算法)
ESP: encryption secret key (加密秘钥)
ESP: authentication enabled yes/no (是否启用认证（是/否)
Many key-exchange parameters (许多密钥交换参数)
Routing restrictions (路由限制)
IP filtering policy (IP过滤策略)

一些实现使用命令行工具维护 SPD（安全策略数据库:Security Policy Database），其他实现使用 GUI，而另一些则通过网络提供基于 Web 的界面。任何特定实现维护的细节量取决于所提供的功能，以及它是在主机模式还是网关模式下运行（或两者兼而有之）。

密钥管理

最后，我们简要介绍密钥管理这个非常复杂的问题。这个领域涉及多个协议和众多选项，其中大部分内容将在未来的文章中详细介绍。本节内容必然是高度不完整的。

如果没有身份验证和加密等加密设施，IPsec几乎毫无用处，而这些设施要求使用参与者知道但其他人不知道的密钥。

建立这些密钥的最明显和最直接的方法是手动配置：一方生成一组密钥，并将其传达给所有合作伙伴。所有参与方都将这些密钥安装在 SPD 中相应的安全关联(SA)中。

但是，这个过程不易扩展，也不总是非常安全：仅仅是将密钥传递给另一个站点的安全策略数据库(SPD)就可能在传输中暴露密钥。在安装了许多设备使用相同的预共享密钥的更大规模的部署中，如果该密钥被破解，将需要重新部署新密钥，这会造成非常大的破坏。

IKE（Internet Key Exchange）的存在是为了允许两个端点正确设置其安全关联，包括要使用的密钥。IKE使用ISAKMP（Internet Security Association Key Management Protocol）作为框架，支持建立兼容两端的安全关联。

它本身支持多种密钥交换协议，其中Oakley协议使用最广泛。我们注意到，IPsec密钥交换通常发生在端口500/udp上。

资源

互联网上有很多与IPsec相关的资源，有些比其他资源更好。当然，起点总是RFC（请求评论），这些RFC构成了定义协议的互联网标准。这些是所有其他文档的主要参考资料，包括本文档在内。

更新： 2005 年 12 月，IETF 发布了一套全新的 RFC，43xx 系列在很大程度上淘汰了 24xx 系列。我们在下面引用了所有 RFC（旧的和新的），尽管本文档尚未真正针对新文档进行更新。

RFC 2401 — Security Architecture for IPsec — obsolete
RFC 4301 — Security Architecture for IPsec — new Dec 2005

This is the overview of the entire IPsec protocol suite from the point of view of the RFCs. This, and the Documentation Roadmap (RFC 2411) are good places to start.
RFC 2402 — AH: Authentication Header — obsolete
RFC 4302 — AH: Authentication Header — new Dec 2005

This defines the format of the IPsec Authentication Header, in both Tunnel and Transport modes.
RFC 2403 — Use of HMAC-MD5-96 within ESP and AH
RFC 2404 — Use of HMAC-SHA-1-96 within ESP and AH

These two RFCs define authentication algorithms used in AH and ESP: MD5 and SHA-1 are both cryptographic hashes, and they are part of a Hashed Message Authentication Code. AH always performs authentication, while ESP does so optionally.
RFC 2104 — HMAC: Keyed-Hashing for Message Authentication

This RFC defines the authentication algorithm that uses a cryptographic hash along with a secret to verify the integrity and authenticity of a message. It’s not written to be part of IPsec, but it’s referenced in RFC 2403 and RFC 2404.
RFC 2405 — The ESP DES-CBC Cipher Algorithm With Explicit IV

This defines the use of DES (the Data Encryption Standard) as a confidentiality algorithm in the context of ESP.
RFC 2406 — ESP: Encapsulating Security Payload obsolete
RFC 4303 — ESP: Encapsulating Security Payload new Dec 2005

ESP is the encrypting companion to AH, and it affords confidentiality to the contents of its payload. ESP by itself does not define any particular encryption algorithms but provides a framework for them.
RFC 2407 — The Internet IP Security Domain of Interpretation for ISAKMP

This RFC describes the use of ISAKMP — Internet Security Association and Key Management Protocol — in the context of IPsec. It’s a framework for key exchange at the start of a conversation, and its use obviates the poor practice of using manual keys.
RFC 2408 — Internet Security Association and Key Management Protocol (ISAKMP)

Hand in hand with RFC 2407, this RFC dives into much more detail on the ISAKMP protocol used to support key exchange (though it doesn’t define the key exchange protocols themselves).
RFC 2409 — The Internet Key Exchange (IKE) Protocol obsolete
RFC 4306 — The Internet Key Exchange (IKE) Protocol new Dec 2005

Though ISAKMP provides a framework for key-exchange, it doesn’t define the protocols themselves: this RFC does that. IKE includes initial authentication, as well as Oakley key exchange.
RFC 2410 — The NULL Encryption Algorithm and Its Use With IPsec

IPsec’s ESP protocol performs encryption of payload using one of several available algorithms, but a NULL encryption algorithm is typically made available for testing. Of course, this provides no confidentiality for the “protected” data, but it may be useful for developers or those attempting to understand IPsec by sniffing the wire. This RFC is written humorously and could have been (but was not) written on April 1.
RFC 2411 — IP Security Document Roadmap

This RFC provides an layout of the various IPsec-related RFCs, as well as provides a framework for new RFCs of particular types (“authentication algorithms”, “encryption algorithms”). It’s a good starting point.
RFC 2412 — The OAKLEY Key Determination Protocol

OAKLEY forms part of IKE (Internet Key Exchange), and it provides a service where two authenticated parties can agree on the secrets required for IPsec communications.
An Illustrated Guide to Cryptographic Hashes - Unixwiz.net Tech Tip
An introductory paper on the use of cryptographic hashes such as MD5 or SHA-1, which are used in AH’s HMAC for authentication.
IPsec Technical Reference by Microsoft

This provides information on Microsoft’s implementation of IPsec in the Windows Server 2003 product, including a great deal about the larger infrastructure required to support IPsec in the enterprise.
TCP/IP Illustrated, Volume 1, by W. Richard Stevens.

This is the classic textbook on the TCP/IP protocol, covering down to the packet header in exquisite detail: This is an extraordinary resource.
A Cryptographic Evaluation of IPsec, by Bruce Schneier and Niels Ferguson.

An interesting paper on the security of IPsec, whose main point is that IPsec is far too complex to ever really be secure (something which has crossed our minds as well). Among their proposals are to eliminate both Transport Mode and AH: ESP in Tunnel mode can provide all this same functionality.
RFC 3884 — Use of IPsec Transport Mode for Dynamic Routing

In contrast to the Schneier paper, it’s also been suggested that Transport Mode is the only one that’s strictly required to accomplish everything, and RFC 3884 shows a way of providing tunnel mode. It’s been suggested to us that this makes some implementation issues much easier, though we’ve not really investigated any of it.
Cryptography in Theory and Practice: The Case of Encryption in IPsec ; Paterson & Yau

This very interesting paper discusses some of the dangers of encrypted but not authenticated IPsec connections, with effective attacks on real systems (including the Linux kernel’s implementation of IPsec). It’s a very clever paper.
Protocolo IPsec — Alexandru Ionut Grama

This paper was translated into Spanish!