文章目录
前言
阅读本文前请注意最后编辑时间，文章内容可能与目前最新的技术发展情况相去甚远。欢迎各位评论与私信，指出错误或是进行交流等。
本文是关于《计算机网络：自顶向下方法（第七版）》的学习分享，内容书写顺序也是按照书中的顺序。本文并不会提及书中的所有内容，主要写重点的知识，以及自己感兴趣的内容。会对原文中的内容进行一定的精简，或者加上个人的理解。
计算机网络中的安全
使 TCP 连接安全： SSL
在前一节中，我们看到对一个特定的应用 （即电子邮件），密码技术是怎样提供机密性、数据完整性和端点鉴别的。 在这一节中，我们在协议栈中向下一层，考察密码技术如何用安全性服务加强TCP, 该安全性服务包括机密性、 数据完整性和端点鉴别。 TCP 的这种强化版本通常被称为安全套接字层 (Secure Socket Layer, SSL) 。 SSL版本 3 的一个稍加修改的版本被称为运输层安全性 (Transport Layer Security, TLS) , 已经由 IETF 标准化。
SSL 已经得到了广泛部署，SSL得到了所有流行Web浏览器和Web 服务器的支持，并基本上被用于所有因特网商业站点。每年经 SSL 花费了数百亿美元。 事实上，如果你使用信用卡通过因特网购买任何东西的话，在你的浏览器和服务器之间的通信几乎一定使用了SSL。 （当你使用浏览器时，若 URL以 https: 开始而不是以 http 开始，就能认定正在使用 SSL。)
为了理解SSL 的需求，我们浏览一下某典型的因特网商业的场景。 Bob在 Web上冲浪，到达了Alice 公司的站点，这个站点正在出售香水。 Alice 公司站点显示了一个表格，假定 Bob 可以在该表格中输入香水的类型和所希望的数量、他的地址和他的支付卡号等信息。 Bob 输入这些信息，点击"提交＂，就期待收到所购买的香水；他也期待着在他的下一次支付卡报表中收到对所购物品的支付信息。 所有这一切听起来不错，但是如果不采取安全措施, Bob也许会有一些意外。
- 如果没有使用机密性 （加密），一个入侵者可能截取Bob的订单并得到他的支付卡信息。 这个入侵者则可以用 Bob 的费用来购买商品。
- 如果没有使用完整性，入侵者可能修改Bob 的订单，让他购买比希望瓶数多 10倍的香水。
- 最后，如果没有使用服务器鉴别，这个显示 Alice公司著名徽标的服务器实际上是由 Trudy 维护的一个站点， Trudy 正在假冒 Alice 公司。 当 Trudy 收到 Bob 的订单后，可能拿了Bob 的钱一走了之。 或者Trudy 可能充当一名身份窃贼，收集 Bob的名字、 地址和信用卡号。
SSL通过采用机密性、数据完整性、服务器鉴别和客户鉴别来强化TCP, 就可以解决这些问题。
SSL 经常用来为发生在 HTTP 之上的事务提供安全性。 然而，因为 SSL使 TCP安全了，因此它能被应用于运行在TCP 之上的任何应用程序。 SSL提供了一个简单的具有套接字的应用编程接口 (API) 、该接口类似于TCP 的 API。 当一个应用程序要使用 SSL 时，它调用 SSL类／库。 如图中所示，尽管SSL 技术上位于应用层中，但从研发者的角度看，它是一个提供TCP服务的运输协议，而这里的TCP服务用安全性服务加强了
宏观描述
我们从描述一个简化的SSL版本开始，这将使我们从宏观上理解SSL 的工作原理和工作过程。 我们将这个SSL 的简化版本称之为＂类SSL''。 描述过类 SSL之后， 在下一小节中我们将描述真实的 SSL、填充细节。 类SSL (和 SSL) 具有三个阶段： 握手、密钥导出和数据传输。 我们现在描述针对一个客户 (Bob) 和一个服务器 (Alice) 之间的通信会话的这三个阶段、其中 Alice 具有私钥／公钥对和将她的身份与其公钥绑定的证书。
- 握手
在握手阶段， Bob 需要： 1.与 Alice创建一条TCP连接；2.验证Alice 是真实的 Alice;3.发送给Alice 一个主密钥、 Bob 和 Alice 用该主密钥生成 SSL 会话所需的所有对称密钥。这三个步骤显示在下图中。
注意到一旦创建了TCP连接， Bob 就向 Alice发送一个SSL hello 报文。 Alice 则用她的证书进行响应，证书中包含了她的公钥。 该证书已被某CA证实过， Bob 明白无误地知道该公钥属于 Alice。 然后， Bob 产生一个主密钥 (MS) (该 MS将仅用于这个SSL会话），用 Alice 的公钥加密该 MS 以生成加密的主密钥 (EMS) , 并将该 EMS 发送给Alice。 Alice 用她的私钥解密该 EMS 从而得到该 MS。 在这个阶段后， Bob 和Alice (无别的人）均知道了用于这次SSL 会话的主密钥。 - 密钥导出
从原则上讲， MS 此时已由 Bob 和Alice 共享，它能够用作所有后继加密和数据完整性检查的对称会话密钥。 然而，对于 Alice 和 Bob 每人而言，使用不同的密码密钥，并且对于加密和完整性检查也使用不同的密钥，通常认为更为安全。 因此， Alice 和 Bob 都使用 MS
生成4个密钥：
- EB, 用于从 Bob 发送到 Alice 的数据的会话加密密钥
• MB, 用于从 Bob 发送到 Alice 的数据的会话 MAC 密钥 （MAC，报文鉴别码）
• EA，用于从Alice 发送到 Bob 的数据的会话加密密钥
• MA, 用于从 Alice 发送到 Bob 的数据的会话MAC 密钥
Alice 和 Bob 每人都从 MS 生成4个密钥。这能够通过直接将该 MS 分为4 个密钥来实现。 （但在真实的 SSL 中更为复杂一些，我们后面将会看到。）在密钥导出阶段结束时Alice 和 Bob 都有了 4 个密钥。 其中的两个加密密钥将用于加密数据；两个MAC 密钥将用于验证数据的完整性。
- 数据传输
既然Alice 和 Bob 共享相同的4 个会话密钥 (EB, MB, EA和MA) , 他们就能够经TCP连接开始发送安全的数据。 因为TCP是一种字节流协议， 一种自然的方法是用SSL在传输中加密应用数据，然后将加密的数据在传输中传给TCP。 但是如果我们真的这样做，我们将用于完整性检查的MAC置于何处呢？我们无疑不希望等到TCP会话结束时才验证所有Bob 数据的完整性， Bob数据的发送要经历整个会话！为了解决这个问题， SSL将数据流分割成记录，对每个记录附加一个MAC用于完整性检查，然后加密该"记录+MAC"。 为了产生这个MAC, Bob将数据连同密钥MB放入一个散列函数中。 为了加密"记录+MAC" 这个包， Bob使用他的会话加密密钥 EB。 然后这个加密的包将传递给TCP经因特网传输。（此步骤对应 之前所学的 报文完整性和数字签名这一节内，报文鉴别码这一小节）
虽然这种方法几经周折，但它为整个报文流提供数据完整性时仍未达到无懈可击。 特别是，假定Trudy 是一名"中间人"，并且有在Alice 和 Bob之间发送的TCP报文段流中插入、删除和代替报文段的能力。 例如， Trudy 能够俘获由 Bob 发送的两个报文段，颠倒这两个报文段的次序，调整TCP报文段的序号（这些未被加密），然后将这两个次序翻转的报文段发送给Alice。假定每个TCP报文段正好封装了一个记录，我们现在看看Alice将如何处理这些报文段。
- 在 Alice 端运行的 TCP将认为一切正常，将这两个记录传递给SSL子层。
- 在 Alice 端的 SSL将解密这两个记录。
- 在 Alice 端的 SSL将使用在每个记录中的 MAC来验证这两个记录的数据完整性。
- 然后 SSL将解密的两条记录的字节流传递给应用层；但是Alice 收到的完整字节流由于记录的颠倒而次序不正确！
鼓励读者观察类似的场景，例如Trudy 删除报文段或当Trudy重放报文段时。对该问题的解决方案如你可能猜想的那样，那就是使用序号。 SSL采用如下的方式。Bob 维护一个序号计数器，计数器开始为0, Bob 每发送的一个SSL记录它都增加 1。 Bob并不在记录中写入一个序号，但当他计算MAC 时，他把该序号包括在MAC 的计算中。 所以，该MAC 现在是数据 加 MAC密钥MB 加 当前序号的散列。 Alice 跟踪Bob 的序号，通过在MAC 的计算中包括适当的序号，使她验证一条记录的数据完整性。 SSL序号的使用阻止了Trudy 执行诸如重排序或重放报文段等中间人攻击。
- SSL 记录
SSL 记录（以及类 SSL 记录）显示在下图中。 该记录由类型字段、版本字段长度字段、数据字段和 MAC 字段组成。 注意到前三个字段是不加密的。 类型字段指出了该字段是握手报文还是包含应用数据的报文，它也用于关闭 SSL连接。 在接收端的SSL使用长度字段以从到达的TCP字节流中提取SSL记录。
更完整的描述
前一小节涉及了类SSL 协议；其目的是让我们对SSL的工作原理和工作过程有一个基本理解。 既然我们已经对SSL有了基本了解，就能够更深入地研究实际SSL协议的要点了。 为了配合阅读对SSL协议的描述，鼓励读者完成Wireshark SSL 实验
- SSL 握手
SSL 并不强制 Alice 和 Bob 使用一种特定的对称密钥算法、一种特定的公钥算法或一种特定的 MAC。 相反， SSL允许Alice和Bob在握手阶段在 SSL会话开始时就密码算法取得一致。 此外，在握手阶段， Alice 和 Bob 彼此发送不重数，该数被用于会话密钥 (EB,MB，EA和MA）的生成中。 真正的SSL握手的步骤如下：
1 ) 客户发送它支持的密码算法的列表，连同一个客户的不重数。
- 从该列表中，服务器选择一种对称算法（例如AES)、 一种公钥算法（例如具有特定密钥长度的RSA) 和一种 MAC算法。 服务器把它的选择以及证书和一个服务器不重数返回给客户。
3 ) 客户验证该证书，提取服务器的公钥，生成一个前主密钥 (Pre-Master Secret, PMS), 用服务器的公钥加密该PMS, 并将加密的 PMS发送给服务器 - 使用相同的密钥导出函数 （就像SSL标准定义的那样），客户和服务器独立地从PMS 和不重数中计算出主密钥 (MasterSecret, MS) 。 然后该 MS 被切片以生成两个密码和两个MAC 密钥。 此外，当选择的对称密码应用于CBC (例如3DES或 AES), 则两个初始化向量 (Initialization Vector, IV) 也从该 MS 获得，这两个 IV 分别用于该连接的两端。 自此以后，客户和服务器之间发送的所有报文均被加密和鉴别（使用MAC)
5 ) 客户发送所有握手报文的一个MAC。 - 服务器发送所有握手报文的一个MAC。
最后两个步骤使握手免受篡改危害。 为了理解这一点，观察在第一步中，客户通常提供一个算法列表，其中有些算法强，有些算法弱。 因为这些加密算法和密钥还没有被协商好，所以算法的这张列表以明文形式发送。 Trudy 作为中间人，能够从列表中删除较强的算法，迫使客户选择一种较弱的算法。 为了防止这种篡改攻击．在步骤5 中客户发送一个级联它已发送和接收的所有握手报文的MAC。 服务器能够比较这个MAC 与它已接收和发送的握手报文的MAC。 如果有不一致，服务器能够终止该连接。 类似地，服务器发送一个它已经看到的握手报文的MAC, 允许客户检查不一致性。
你可能想知道在步骤1 和步骤2中存在不重数的原因。 序号不足以防止报文段重放攻击吗？答案是肯定的，但它们并不只是防止"连接重放攻击＂。 考虑下列连接重放攻击。假设Trudy 嗅探了 Alice 和 Bob 之间的所有报文。 第二天， Trudy 冒充 Bob 并向 Alice 发送正好是前一天Bob 向 Alice 发送的相同的报文序列。 如果 Alice 没有使用不重数，她将以前一天发送的完全相同的序列报文进行响应。 Alice 将不怀疑任何不规矩的事，因为她接收到的每个报文将通过完整性检查。 如果Alice是一个电子商务服务器，她将认为 Bob 正在进行第二次订购（正好订购相同的东西）。 在另一方面，在协议中包括了一个不重数，Alice 将对每个 TCP 会话发送不同的不重数，使得这两天的加密密钥不同。 因此，当 Alice接收到来自 Trudy 重放的 SSL记录时，该记录将无法通过完整性检查，并且假冒的电子商务事务将不会成功。 总而言之，在SSL中，不重数用于防御"连接重放"，而序号用于防御在一个进行中的会话中重放个别分组。
- 连接关闭
在某个时刻， Bob 或者Alice将要终止 SSL会话。一个方法是让 Bob 通过直接终止底层的TCP连接来结束该SSL会话，这就是说，通过让Bob 向 Alice 发送一个TCP FIN 报文段。 但是这种幼稚设计为截断攻击 (truncation attack) 创造了条件， Trudy 再一次介入一个进行中的SSL 会话中，并用 TCP FIN 过早地结束了该会话。 如果 Trudy 这样做的话，Alice 将会认为她收到了 Bob 的所有数据，而实际上她仅收到了其中的一部分。 对这个问题的解决方法是，在类型字段中指出该记录是否是用于终止该SSL会话的。 （尽管SSL类型是以明文形式发送的，但在接收方使用了记录的 MAC对它进行了鉴别。）通过包括这样一个字段， 如果Alice 在收到一个关闭 SSL记录之前突然收到了一个TCP FlN, 她可能知道正在进行着某些耍花招的事情。
到此为止完成了对SSL的介绍。 我们已经看到它使用了在前文讨论的许多密码学原则。 希望更深入地探讨SSL的读者可以阅读有关 SSL 的的书籍。
网络层安全性： IPsec 和虚拟专用网
IP 安全 (IP Security) 协议更常被称为 IPsec, 它为网络层提供了安全性。 IPsec 为任意两个网络层实体（包括主机和路由器）之间的 IP数据报提供了安全。 如我们很快要描述的那样，许多机构 （公司、 政府部门、非营利组织等等）使用IPsec创建了运行在公共因特网之上的虚拟专用网 (Virtual Private, Network, VPN) 。
在学习 lPsec 细节之前，我们后退一步来考虑为网络层提供机密性所包含的意义。 在网络实体对之间（例如，两台路由器之间，两台主机之间，或者路由器和主机之间）具有网络层机密性，发送实体加密它发送给接收实体的所有数据报的载荷。 这种载荷可以是一个TCP 报文段、 一个UDP报文段、 一个 ICMP 报文等等。 如果这样的网络层服务适当的话，从一个实体向其他实体发送的所有数据报将隐形于任何可能嗅探该网络的第三方，发送的数据报包括电子邮件、 Web 网页、 TCP握手报文和管理报文（例如 ICMP和SNMP)。正因为如此，网络层安全性被认为提供了地毯覆盖 。
除了机密性，网络层安全协议潜在地能够提供其他安全性服务。 例如，它能提供数据源鉴别，使得接收实体能够验证安全数据报的源。网络层安全协议能够提供数据完整性，使得接收实体能够核对在数据报传输过程中可能出现的任何篡改。 网络层安全服务也能提供防止重放攻击功能，这意味着接收方能够检测任何攻击者可能插入的任何冗余数据报。 我们将很快看到 IPsec 的确提供了用于这些安全服务的机制，即机密性、源鉴别、数据完整性和重放攻击防护。
IPsec 和虚拟专用网
跨越在多个地理区域上的某机构常常希望有自己的 IP 网络，使它的主机和服务器能够以一种安全和机密的方式彼此发送数据。 为了达到这个目标，该机构能够实际部署一个单独的物理网络，该网络包括路由器、链路和 DNS基础设施且与公共因特网完全分离。这样一种为特定的机构专用的分立网络被称为专用网络 (private network)。 毫不奇怪， 专用网络可能耗资巨大，因为该机构需要购买、安装和维护它自己的物理网络基础设施。
不同于部署和维护一个专用网络，如今许多机构在现有的公共因特网上创建VPN。 使用 VPN, 机构办公室之间的流量经公共因特网而不是经物理上独立的网络发送。 而为了提供机密性，办公室之间的流量在进入公共因特网之前进行加密。下图中显示了 VPN 的一个简单例子。这里的机构由一个总部、 一个分支机构和旅行中的销售员组成，销售员通常从他们的旅馆房间接入因特网。 （在该图中仅显示了一名销售员。）在这个VPN 中，无论何时，位于总部的两台主机相互发送IP数据报或位于分支机构的两台主机要通信，它们都使用经典的IPv4 ( 即无 IPsec 服务）。 然而，当两台机构的主机经过跨越公共因特网的路径时，这些流量在进入因特网之前进行加密。
为了感受VPN 的工作过程，我们假设一个简单的场景例子。 当总部中的一台主机向某旅馆中的某销售员发送一个IP数据报时，总部中的网关路由器将经典的IPv4转换成为 IPsec 数据报，然后将该 IPsec 数据报转发进因特网。 该 IPsec 数据报实际上具有传统的IPv4 首部，因此在公共因特网中的路由器处理该数据报，仿佛它对路由器而言是一个普通的IPv4 数据报。 但是如图所示， lPsec 数据报的载荷包括了一个IPsec 首部，该首部被用于IPsec 处理；此外， IPsec 数据报的载荷是被加密的。 当该IPsec 数据报到达销售员的便携机时，便携机的操作系统解密载荷 （并提供其他安全服务，如验证数据完整性），并将解密的载荷传递给上层协议（例如，给TCP或UDP)
AH 协议和 ESP协议
IPsec 是一个相当复杂的整体，即它被定义为 10 多个 RFC 文档。 两个重要的文档是RFC 4301 和 RFC 6071, 前者描述了总体 IP 安全体系结构，后者提供了一个 IPsec 协议集的概述。
在 IPsec 协议族中，有两个主要协议：鉴别首部 (Authentication Header, AH) 协议和封装安全性载荷 (Encapsulation Security Payload, ESP) 协议。 当某源 IPsec 实体（通常是一台主机或路由器）向一个目的实体（通常也是一台主机或路由器）发送安全数据报时，它可以使用AH协议或ESP协议来做到。 AH 协议提供源鉴别和数据完整性服务，但不提供机密性服务。 ESP 协议提供了源鉴别、数据完整性和机密性服务。 因为机密性通常对VPN 和其他IPsec 应用是至关重要的，所以 ESP协议的使用比 AH协议要广泛得多。
安全关联
IPsec 数据报在网络实体对之间发送，例如两台主机之间、两台路由器之间或一台主机和一台路由器之间。 在从源实体向目的实体发送IPsec数据报之前，源和目的实体创建了一个网络层的逻辑连接。 这个逻辑连接称为安全关联 (Security Association, SA)。 一个SA 是一个单工逻辑连接；也就是说，它是从源到目的地单向的。如果两个实体要互相发送安全数据报，则需创建两个SA, 每个方向一个。
例如，再次考虑上图中那个机构的 VPN。 该机构由一个总部、一个分支机构和 n个旅行销售员组成。 我们假设在总部和分支机构之间有双向 IPsec 流量，并且总部和销售员之间也有双向 IPsec 流量。 在这个VPN 中，有多少个SA 呢？ 为了回答这个问题， 注意到在总部网关路由器和分支机构网关路由器之间有两个SA (一个方向一个）；对每个销售员的便携机而言，在总部网关和便携机之间有两个SA (仍是一个方向一个） 。 因此，总计为 (2+2n) 个SA。 然而记住，并非从网关路由器或便携机发送进因特网的所有流量都将是IPsec 安全的。 例如，总部中的一台主机可能要访问公共因特网中的某Web 服务器 （例如 Amazon或谷歌）。 因此，该网关路由器 （或该便携机） 将发送经典
的 IPv4 数据报和安全的 lPsec 数据报进人因特网。
我们现在观察SA 的"内部"。 为了使讨论明确和具体，我们在上图中的一个场景下进行观察。路由器 R1 到路由器R2 的SA。 （你能够认为路由器R1 是总部网关路由器，而路由器R2 是分支机构网关路由器。）路由器R1 将维护有关该SA 的状态信息，这将包括：
- SA 的 32 比特的标识符，称为安全参数索引 (Security Parameter Index , SPI) 。
- SA 的初始接口（在此例中为 200. 168. I. 100) 和 SA 的目的接 口（在此例中为193. 68. 2. 23 )
- 将使用的加密类型 （例如，具有CBC 的3DES)。
- 加密密钥。
- 完整性检查的类型（例如，具有MD5 的 HMAC)。
- 鉴别密钥。
无论何时路由器R1 需要构建一个[Psec- 数据报经过这个SA 转发， 它访问该状态信息以决定它应当如何鉴别和加密该数据报。 类似地，路由器R2将维护对此SA 的相同的状态信息， 并将使用该信息鉴别和加密任何从该SA到达的IPsec数据报。
一个IPsec 实体 （路由器或主机）经常维护许多SA 的状态信息。 例如，在具有n个销售员的VPN例子中，总部网关路由器维护 (2 +2n）个SA 的状态信息。 一个IPsec 实体在它的安全关联数据库 (Security Association Database, SAD) 中存储其所有 SA的状态信息， SAD是实体操作系统内核中的一个数据结构。
IPsec 数据报
在描述了 SA后，我们现在能够描述实际的IPsec 数据报了。 IPsec有两种不同的分组形式，一种用于所谓隧道模式 (tunnel mode) , 另一种用于所谓运输模式 (transport mode) 。 更为适合 VPN 的隧道模式比运输模式部署得更为广泛。为了进一步讲清 IPsec 和避免许多难题，我们因此专门关注隧道模式。 一旦已经牢牢地掌握了隧道模式，应当能够容易地自学运输模式。
IPsec 数据报的分组格式显示在下图中。 你也许认为分组格式是枯燥乏味的，但我们将很快看到IPsec 数据报实际上尝起来像美式墨西哥风味 (Tex-Mex) 美食！我们考察上图SA的场景中的IPsec 字段。 假设路由器R1 接收到一个来自主机172. 16. 1. 17 (在总部网络中）的普通IPv4 数据报，该分组的目的地是主机172. 16. 2. 48 (在分支机构网络中） 。路由器R1 使用下列方法将这个"普通IPv4数据报"转换成一个IPsec 数据报：
• 在初始 IPv4 数据报 （它包括初始IP首部、初始IP数据报荷载）后面附上一个"ESP尾部"字段。
• 使用算法和由 SA规定的密钥加密该结果。
• 在这个加密量的前面附加上一个称为 "ESP首部"的字段，得到的包称为 "enchilada" (以辣椒调味的一种墨西哥菜。 ）
• 使用算法和由 SA规定的密钥生成一个覆盖整个 enchilada 的鉴别 MAC。
• 该 MAC 附加到 enchilada 的后面。
• 最后，生成一个具有所有经典IPv4 首部字段 （通常共20字节长） 的全新IP首部，该新首部附加到载荷之前。
注意，得到的IPsec 数据报是一个货真价实的IPv4 数据报，它具有传统的 IPv4 首部字段后跟一个载荷。 但在这个场合，该载荷包含一个ESP首部、 初始IP数据报、 一个ESP尾部和一个ESP鉴别字段（具有加密的初始数据报和ESP 尾部）。初始的 IP数据报具有源IP 地址 172. 16. 1. 17 和目的地址 172. 16.2. 48。 因为 lPsec 数据报包括了该初始 IP 数据报，这些地址被包含和被加密作为IPsec 分组负载部分。 但是在新IP首部中的源和目的地 IP地址，即在IPsec 数据报的最左侧首部又该如何处理呢？如你所猜测、它们被设置为位于隧道两个端点的源和目的地路由器接口，也就是200. 168. 1. l 00 和 193.68.2.23。同时，这个新IPv4 首部字段中的协议号不被设置为TCP、 UDP或 SMTP, 而是设置为50,指示这是一个使用ESP协议的 IPsec数据报
在R1 将IPsec 数据报发送进公共因特网之后，它在到达 R2 之前将通过许多路由器。这些路由器中的每个将处理该数据报，就像它是一个普通数据报一样，即它们被完全忘记这样的事实： 该数据报正在承载IPsec 加密的数据。 对于这些公共因特网路由器，因为在新IP首部中的目的地址是R2, 所以该数据报的最终目的地是 R2。
在考察了如何构造一个lPsec 数据报的例子后，我们现在更仔细地观察enchilada 的组成。 我们看到在图中的 ESP 尾部由三个字段组成： 填充、 填充长度和下一个首部。前面讲过块密码要求被加密的报文必须为块长度的整数倍。 使用填充（由无意义的字节组成），使得当其加上初始数据报（连同填充长度字段和下一个首部字段）形成的＂报文"是块的整数倍。 填充长度字段指示接收实体 插入的填充是多少（并且需要被删除）。 下一个首部字段指示包含在载荷数据字段中数据的类型（例如 UDP)。 载荷数据（通常是初始IP 数据报）和ESP尾部级联起来并被加密
附加到这个加密单元前面的是 ESP 首部，该首部以明文发送，它由两个字段组成：SPI 字段和序号字段。SPI字段指示接收实体该数据报属于哪个SA; 接收实体则能够用该SPI 索引 其 SAD 以确定适当的鉴别／解密算法和密钥。 序号字段用于防御重放攻击。
发送实体也附加一个鉴别 MAC。 如前所述、发送实体使用整个enchilada (由 ESP 首部、 初始IP数据报和ESP尾部组成， 即具有加密的数据报和尾部）计算一个 MAC。 前面讲过为了计算一个MAC, 发送方附加一个秘密 MAC密钥到该enchilada, 进而计算该结果的一个固定长度散列。
当 R2 接收到 IPsec 数据报时, R2 看到该数据报的目的 IP地址是R2 自身。 R2 因此处理该数据报。 因为协议字段（位于 IP 首部最左侧）是50, R2 明白应当对该数据报施加IPsec ESP 处理。 第一，针对 enchilada, R2也使用 SPI 以确定该数据报属于哪个 SA。 第二，它计算该enchilada 的 MAC 并且验证该 MAC 与在 ESP MAC 字段中的值一致。 如果两者一致，它知道该enchilada 来自 R1 并且未被第改。 第三，它检查序号字段以验证该数据报是新的（并且不是重放的数据报）。第四，它使用与 SA关联的解密算法和密钥解密该加密单元。 第五，它删除填充并抽取初始的普通IP报文。 最后，它朝着其最终目的地，将该初始数据报转发进分支机构网络。
实际上还有另一个重要的细微差别需要处理。 它以下列问题为中心：当 R1 从位于总部网络中的一台主机收到一个（未加密的）数据报时， 并且该数据报目的地为总部以外的某个目的IP地址， R1 怎样才能知道它应当将其转换为一个IPsec 数据报呢？并且如果它由 lPsec 处理， R1 如何知道它应当使用（在其SAD 中的许多 SA 中）哪个 SA来构造这个IPsec 数据报呢？该问题以如下方式解决。 除了 SAD 外， IPsec 实体也维护另一个数据结构，它称为安全策略库 (security Policy Database, SPD) 。 该 SPD 指示哪些类型的数据报（ 作为源 IP 地址、 目的 IP 地址和协议类型的函数）将被 IPsec 处理；并且对这些将被IPsec 处理的数据报应当使用哪个SA。 从某种意义上讲，在 SPD 中的信息指示对于一个到达的数据报做"什么＂； 在SAD 中的信息指示"怎样"去做。
IPsec 服务的小结
IPsec 究竟提供什么样的服务呢？我们从某攻击者 Trudy 的角度来考察这些服务，Trudy 是一个中间人，位于上图中 R1 和 R2 之间路径上的某处。 假设通过这些讨论，Trudy 不知道 SA 所使用的鉴别和加密密钥.Trudy 能够做些什么和不能够做些什么呢？第一、 Trudy 不能看到初始数据报。如果事实如此， 不仅Trudy 看不到在初始数据报中的数据，而且也看不到协议号、 源IP地址和目的 IP地址。 对于经该SA 发送的数据报， Trudy仅知道该数据报源下172. 16. l. 0/24 的某台主机以及目的地为 172. 16.2.0/24 的某台主机。她不知道它是否携带TCP、 UDP或 ICMP数据；她不知道它是否携带了 HTTP、 SMTP或某些其他类型的应用程序数据。 因此这种机密性比SSL范围更为宽广。 第二，Trudy试图用反转数据报的某些比特来篡改在SA 中的某个数据报， 当该篡改的数据报到达R2 时，它将难以通过完整性核查（使用 MAC), 再次挫败了Trudy 的恶意尝试。第三，假设Trudy试图假冒 R1, 生成一个源为 200. 168. 1. 100 和目的地为 193.68.2. 23 的 IPsec 数据报。Trudy 的攻击将是无效的，因为这个数据报将再次通不过在R2 的完整性核查。 最后，因为IPsec 包含序号， Trudy 将不能够生成一个成功的重放攻击。 总而言之，正如本节开始所言， IPsec 在任何通过网络层处理分组的设备对之间，提供了机密性、源鉴别、数据完整性和重放攻击防护。
IKE: IPsec 中的密钥管理
当某VPN 具有少量的端点时，网络管理员能够在该端点的SAD 中人工输入SA信息（加密／鉴别算法和密钥及SPI)。 这样的"人工密钥法"对于一个大型VPN 显然是不切实际的，因为大型 VPN 可能由成百甚至上千台 IPsec路由器和主机组成。 大型的、地理上分散的部署要求一个自动的机制来生成SA。 IPsec使用因特网密钥交换 (Internet Key Exchange , lKE) 协议来从事这项工作， IKE 由 RFC 5996 定义。
IKE 与 SSL 中的握手具有某些类似。 每个 IPsec 实体具有一个证书，该证书包括了该实体的公开密钥。 如同使用SSL一样， IKE协议让两个实体交换证书，协商鉴别和加密算法，并安全地交换用于在IPsec SA 中生成会话密钥的密钥材料。 与SSL不同的是， IKE应用两个阶段来执行这些任务。
我们来研究两台路由器R1 和R2 场景下的这两个阶段－ 第一个阶段由 R1 和R2 之间报文对的两次交换组成：
• 在报文的第一次交换期间，两侧使用 Djffie-Hellman 在路由器之间生成一个双向的 IKE SA。 为了防止混淆，这个双向 IKE SA 完全不同于之前所讨论的 IPsec SA。 该 IKE SA在这两台路由器之间提供了一个鉴别的和加密的信道。 在首个报文对交换期间，创建用于IKE SA 的加密和鉴别的密钥。 还创建了将用于计算后期在阶段2使用的IPsec SA 密钥的一个主密钥。 观察在第一步骤期间，没有使用RSA公钥和私钥。 特别是， R1 或R2 都没有通过用它们的私钥对报文签字而泄露其身份。
• 在报文的第二次交换期间，两侧通过对其报文签名而透漏了它们的身份。 然而，这些身份并未透漏给被动的嗅探者，因为这些报文是经过安全的IKE SA信道发送的。 同时在这个阶段期间，两侧协商由 IPsec SA 应用的 IPsec加密和鉴别算法。在 IKE 的第二个阶段，两侧生成在每个方向的一个SA。 在阶段2结束时，对这两个SA 的每一侧都建立了加密和鉴别会话密钥。 然后这两侧都能使用 SA 来发送安全的数据
报样。 在 IKE 中有两个阶段的基本动机是计算成本即因为第二阶段并不涉及任何公钥密码， IKE能够以相对低的计算成本在两个IPsec实体之间生成大量SA。
参考目录
书籍：《计算机网络：自顶向下方法（第七版）》