当前位置:首页 >> 信息与通信 >>

网络层安全协议 IPSec 及其 NAT 兼容性改进


论文分类号 TP393.06  密      级 内部 

  单  位  代  码  10183    研 究 生 学 号   19906007 


硕 士


学 位


论 文



网络层安全协议 IPSec 及其 NAT 兼容性改进
IPSec and Its Improvement of Compatibality with NAT

作者姓名:姚 志 林 专    业:计算机组织与系统结构 导师姓名:刘 淑 芬 及 职 称:教    授 论文起止年月:2001 年 1 月至 2002 年 4 月

内 容 提 要
无论在中国还是在世界范围,Internet/Intranet 的应用都高速发展, TCP/IP 协议在安全方面的不足,以及网络应用对于传输安全的需求,使 得对计算机网络安全技术的研究步伐也日趋加快。IPSec(IP Security)协议 是 IETF(Internet Engineering Task Force)提出的一系列安全标准, 是在网络 层对数据分组提供加密解密及安全鉴别,实现以下几个方面的安全服务: 数据源鉴别、数据完整性、信息保密、不可否认服务、抗重播、流量保 密。IPSec 已被定为 IPv6 的组成部分。然而由于 IPSec 对数据包的保护, 对数据包的改动会导致验证及解密的失败, 因此 IPSec 与目前广泛使用的 一种技术 NAT(Network Address Translation)网络地址翻译相抵触。网络地 址翻译的做法是,在内部网络中使用内部地址,通过 NAT 把内部地址翻 译成合法的 IP 地址在 Internet 上使用。具体来说就是把 IP 包内的地址域 用合法的 IP 地址来替换。 而作为 NAT 的一种, NAPT(Netwo rk Address Port Translation)还需要通过修改数据包中 TCP 或 UDP 协议的端口来实现地址 翻译,正因如此,NAT 与 IPSec 难以共存。NAT 在缓解 IP 地址紧张方面 起到了重要作用,在 IPv4 向 IPv6 过渡的时期,NAT 所起到的作用是不 可忽视的。本文是完成了吉林省的自然科学基金项目《基于 Internet 网 络层安全技术的研究》而写出的。我们在实现 IPSec 的基础上,综合考虑 了 NAT 与 IPSec 的兼容性问题,采用基于隧道技术的思想,并受 IETF 的关于 NAT 与 IPSec 的兼容性解决方案草案的启发,解决了实现中的一 些技术问题,最终给出了与 NAT 兼容的 IPSec 实例。    





 

目    录 

内容提要 ................................................................................................... 1 第 1 章 前 言 ........................................................................................... 1 1.1 TCP/IP 的各个层次 ........................................................................ 1 1.2 保密的层次 .................................................................................... 2 1.3 NAT 技术......................................................................................... 2 1.4 NAT 的优点..................................................................................... 3 1.5 IPSEC 协议....................................................................................... 3 1.6 本文的组织 .................................................................................... 4 第 2 章 IPSEC 及其 NAT 兼容解决方案................................................ 5 2.1 IPSEC 结构....................................................................................... 5 2.1.1 安全协议 ................................................................................. 5 2.1.2 安全关联和安全策略 ............................................................. 7 2.1.3 密钥管理 ................................................................................. 8 2.2 IPSEC 与 NAT 的不兼容问题 ......................................................... 9 2.3 IPSEC 的 NAT 兼容解决方案 ........................................................ 9 2.3.1 IETF 的一个草案 ..................................................................... 9 2.3.2 我们的方案 ............................................................................11 第 3 章 NAT 兼容的 IPSEC 的实现...................................................... 14 3.1 实施方案 ....................................................................................... 14 3.2 实施环境 ....................................................................................... 14 3.3 系统框架 ....................................................................................... 14 3.4 关键技术 ....................................................................................... 15 3.4.1 SPD 设计 ................................................................................ 15





3.4.2 SADB 设计............................................................................. 15 3.4.3 与 IKE 的通信....................................................................... 16 3.4.4 何时何处实施 IPSec 服务 .................................................... 16 3.4.5 NAT 兼容处理........................................................................ 16 3.4.6 验证及加密解密算法 ........................................................... 17 3.5 系统流程 ....................................................................................... 18 3.6 实现中的技术细节问题 .............................................................. 19 3.7 外出数据包与进入数据包处理 ................................................... 20 3.8 性能评价 ...................................................................................... 25 3.8.1 测试环境 ............................................................................... 25 3.8.2 测试结果及分析 ................................................................... 25 第4章 结 论 ....................................................................................... 26

4.1 国内外的研究情况 ...................................................................... 26 4.2 本文的特点及意义 ...................................................................... 26 4.3 应用前景 ...................................................................................... 27 4.4 不足之处及今后的研究课题 ...................................................... 27 参考文献 ................................................................................................. 28 摘 要 .................................................................................................... I

ABSTRACT ..............................................................................................V 致       谢 ................................................................................................. IX

第1章





 

第1章 前 言
1.1 TCP/IP 的各个层次
TCP/IP(Transmission Control Protocol/Internet Protocol)协议族中有 大量的协议,图 1-1 中显示了主要的协议及 TCP/IP 的四个层次。每一层 都负责不同的功能。 1、 数据链路层:其 目的是发送和接收 IP 模块的 IP 数据包,ARP 模 块的 ARP 请求和应答,RARP 模块的 RARP 请求和应答。 2、 网络层:用于提供点到点的无连接的服务,负责对数据包进行路 由选择。网络层包括网际协议(IP) 、网际控制报文协议 ICMP (Internet Control Messages Protocol) 、网际组管理协议 IGMP (Internet Group Management Protocol) 。 3、 传输层:为其上的应用层提供两主机之间的数据流服务,它提供 了两种协议:传输控制协议 TCP(Transfer Control Protocol)和 用户数据报协议 UDP(User Datagram Protocol) 。
用户进程 用户进程 用户进程 用户进程 应用层

TCP

UDP

传输层

ICMP

IP

IGMP

网络层

ARP

硬件接口

RARP

链路层

物理介质 图 1-1 TCP/IP 四层协议模型

4、 应用层: 直接为网络应用提供服务, 使其能够通过网络收发数据,
第 1 页

第1章





也定义了与操作系统无关的到传输层的接口。 包括 Telnet 远程登 录、文件传输协议 FTP(File Transfer Protocol) 、简单邮件传送 协议 SMTP(Simple Mail Transfer Protocol) 、简单网络管理协议 SNMP(Simple Network Management Protocol)等多种协议,这 些协议多是以 TCP 和 UDP 为基础的。

1.2 保密的层次
当前存在着各种不同协议用于保障各个层次的安全。如在应用层有 PGP(Pretty Good Privacy) ,PGP 是一个面向应用的事后加密程序,而不 是一个实时、在线的加密程序。SSL(Secure Socket Layer)协议是由 Netscape 公司开发出来的一种安全协议,它位于应用层和传输层之间。而 IPSec 是在网络层提供安全服务。 在网络层实现安全服务有以下一些优点: 1.由于多种传送协议和应用程序可共享由网络层提供的密钥管理架 构,减少了密钥协商的开销。 2.由于在较低的层次实现了安全服务,因此上层的应用甚至可以不 加修改的使用。 3.对于任何传送协议都可以透明地实现安全保障。 4.在网络层而非在数据链路层实现安全服务,使得安全服务具有良 好的可扩展性,可以跨越任何支持 TCP/IP 的网络。

1.3 NAT 技术
NAT 技术是 IETF 组织制定的标准,其目的是通过地址重用,以缓解 IP 地址枯竭,以及减小路由表大小。具体来说就是:NAT 将一组非法的 内部地址通过地址翻译,映射成为一组(或一个)合法的外部地址,在 Internet 上使用;NAPT 将一组网络地址映射成为一个 Internet 地址,并将 原数据包的 TCP/UDP 端口号映射为新数据包的 TCP/UDP 端口号,来达 到地址复用的目的。 NAT 有三种类型:静态 NAT、动态 NAT 和端口 NAT(NAPT) 。其 中静态 NAT 设置起来最为简单,内部网络中的每个主机都被永久映射成
第 2 页

第1章





外部网络中的某个合法的地址。而动态 NAT 则是在外部网络中定义了一 系列的合法地址,采用动态分配的方法映射到内部网络。 NAPT 则是把内 部地址映射到外部网络的一个 IP 地址的不同端口上。

1.4 NAT 的优点
由于 NAT 技术的使用,在一定程度上缓解了 IP 地址紧张的局面,推 迟了 IP 地址枯竭时限,为 IPv6 的研究与发布赢得了时间,因而得到了广 泛的应用。从 IPv4 向 IPv6 的过渡不是一朝一夕能够完成的,在此期间 NAT 仍将在 Internet 中发挥重要作用。 在 Internet 中使用 NAPT 时,所有不同的 TCP 和 UDP 信息流看起来 好像来源于同一个 IP 地址。这个优点在小型办公室内非常实用,通过从 ISP 处申请的一个 IP 地址,将多个连接通过 NAPT 接入 Internet。这样就 可以做到多个内部 IP 地址共用一个外部 IP 地址上 Internet,虽然这样会 导致信道的一定拥塞,但考虑到节省的 ISP 上网费用和易管理的特点, 用 NAPT 还是很值得的。

1.5 IPSec 协议
IPSec(IP Security)协议是 IETF 提出的一系列安全标准,是在网络 层对数据分组提供加密解密及安全鉴别等服务,包括以下几个方面:  (1)数据源鉴别:保证数据的发送者是实际希望与之通信的对方;  (2)数据完整性:保证数据没有在传输的过程中被篡改;  (3)信息保密:保证数据在传输过程中不被偷看;  (4)不可否认服务:保证发送方和接收方不能否认自己的通信行为;   (5)抗重播:防止数据分组被复制后重复发送;  (6)流量保密:使攻击者不能了解通信的类型及数据流量。  IPSec 主要由四个部分组成:安全协议、安全关联、加密解密和鉴别 算法以及密钥管理。 

第 3 页

第1章





1.6 本文的组织
本文首先讲述了 IPSec 安全标准的结构(安全协议、安全关联、加密 解密和鉴别算法、密钥管理等)和 IPSec 的处理过程,分析了 IPSec 与 NAT 不能兼容的各个方面,介绍了我们的 IPSec 实现方案及方式,并在 此基础上,根据解决方案,分析了具体实施中遇到的问题及解决方法, 从而做出了 IPSec 与 NAT 兼容的完整实例。

第 4 页

第 2 章 IPSec 及其 NAT 兼容解决方案

第 2 章 IPSec 及其 NAT 兼容解决方案
IPSec 是在网络层对传输的数据提供加密和鉴别等安全服务。可有效 地保护数据包的安全,包括:数据源鉴别、数据完整性、信息保密、不 可否认服务、抗重播、流量保密。IPSec 保障主机之间、网络安全网关之 间或主机与安全网关之间的数据包安全。

2.1 IPSec 结构
IPSec 由安全协议验证头 AH(Authentication Header)、封装安全载荷 ESP(Encapsulating Security Payload)、安全关联 SA (Security Association) 、 密钥管理以及加密/解密和身份验证算法组成。

2.1.1 安全协议
要想对 IP 数据包或上层协议进行保护,其方法是使用某种 IPSec 协 议:ESP 和 AH 协议。 这两个安全协议都提供了两种模式:传送模式和通道模式。 (如图 2-1 所示) 传送模式用于保护某个 IP 载荷的上层协议,而通道模式用于保护整
原始包 IP 头 TCP/UDP 协议头 ESP/AH 头 数据 TCP/UDP 协议头 内部 IP 头

传送模式

IP 头

数据 TCP/UDP 协议头

通道模式

外部 IP 头

ESP/AH 头

数据

图 2-1 分别处于传送模式和通道模式下受保护的 IP 包格式

个 IP 数据包。在传送模式中,IP 头与上层协议头之间需插入一个特殊的 IPSec 头(AH 头或 ESP 头);在通道模式中,要保护的整个 IP 包都封装在 另一个数据包中,然后在外部 IP 头与内部 IP 头之间插入一个 IPSec 头。

第 5 页

第 2 章 IPSec 及其 NAT 兼容解决方案

2.1.1.1 ESP ESP 是插入数据包内的一个协议头,通过对数据的加密及散列运算 得到的验证数据,提供数据机密性、完整性、不可否认、数据起源认证
0 7 15 安全参数索引(SPI) 序列号 初始化向量(IV) TCP/UDP 头 已 加 密 要保护的数据 已 验 证 23 31

填充项

填充项长度 验证数据 图 2-2 ESP 头(与尾)

下一个头

及有限的抗重播等安全服务,而通道方式下的 ESP 将整个 IP 数据包封装 在内部,因而提供了一定的流量保密服务。ESP 头结构如图 2-2 所示。 1.安全参数索引 SPI(Security Parameter Index) :是一个任意数,一 般在 IKE 交换时由对方主机选定,它与 IP 头之前的目的地址以及传送协 议值一起,用来标识用于处理数据包的那个特定的安全关联 SA。 2.序列号:该字段是累加计数器,用来提供抗重播能力。 3.初始化向量(Initialization Vector,IV) :根据加密算法的不同, 该项也可以包含在数据部分中。但要注意它是未加密的。其作用是为加 密算法提供需要的初始化向量。 4.填充项:大多数加密算法要求输入的数据必须是 32 位数据块。 结果密文(包含填充项、 填充长度和下一个头字段)必须以 4 个字节为界限, 填充正是为了保证这种对齐的特性。此外,填充项为从 1 开始的单向递 增数值,可以用来检验解密结果的正确性。
第 6 页

第 2 章 IPSec 及其 NAT 兼容解决方案

5.填充项长度:指出填充项的字节数。 6.下一个头:指明 ESP 所封装的协议类型。 7.身份验证字段:用于保存数据完整性的验证结果,通常是一个密 钥化散列函数对从 SPI 到下一个头的计算结果。验证数据的长度由验证 算法决定。 2.1.1.2 AH AH 作为一种 IPSec 协议,用于为 IP 数据包提供数据完整性、数据起 源验证、不可抵赖性和有限的抗重播能力,它不提供机密性保证。与 ESP 的验证稍有区别,AH 提供的认证为从 IP 头开始到数据包的结束部分; 而 ESP 的验证不包括 IP 头部分。 AH 头结构如图 2-3 所示。
0 下一个头 7 载荷长度 安全参数索引(SPI) 序列号 验证数据 图 2-3 AH 头 15 23 保留 31

其中: 1.下一头:表明 AH 头之后协议类型; 2.载荷长度:表示 AH 头的长度。 3.保留字段:保留以供将来使用,发送时必需设置为全零。 4.SPI、序列号以及验证数据字段的作用与 ESP 头中相同。

2.1.2 安全关联和安全策略
安全策略决定了如何处理收到及要发送的数据包,对它们应用何种 IPSec 模式,使用何种协议,采用那些加密解密及验证算法。安全策略系 统即安全策略数据库 SPD(Security Policy Database)需要有外部表示与内
第 7 页

第 2 章 IPSec 及其 NAT 兼容解决方案

部表示,外部表示用于与用户的接口,便于用户管理;内部表示相对于 外部表示具有形式化的特点,有利于系统查找及维护安全策略。安全策 略系统的设计应满足以下一些要求: 1.能够在每个主机上配置多个策略 2.能够在每个网络中配置策略 3.能够为不同的应用配置不同安全策略 4.能够为每个通信流指定多个协议 5.能够为每个通信流指定想进行的动作:丢弃、保护或绕过 6.能够配置嵌套式的通道 7.能够提供对访问和验证不同的 IKE 的支持 8.能够支持手工处理 SA 来保护特定的通信 9.能够支持多种安全选择 安全关联 SA 是安全策略的实例,是两个应用 IPSec 实体(主机、路 由器)间的一个单向逻辑连接,决定保护什么、如何保护以及谁来保护 通信数据。SA 由三元组:安全参数索引 SPI、IPSec 协议值、及目的地址 唯一确定。SA 一般成对存在,一个用于定义外出方向的安全服务,另一 个用于定义相应的进入方向的安全服务。 SA 中应包含以下一些信息:序列号、抗重播窗口、生存期、目的地 址、IPSec 协议、SPI、通道目的地址、加密算法、验证算法、加密密钥、 验证密钥、初始化向量 IV。

2.1.3 密钥管理
密钥管理就是 SA 的建立、协商、修改、删除的过程。安全关联 SA 可以手工创建,然而在应用中需要有一种动态创建 SA 的方法。Internet 密钥交换 IKE(Internet Key Exchange)就是为了实现此项功能。 IKE 交换通 过在验证对方身份基础上的共享秘密,最终生成一个通过验证的密钥以 及建立在双方同意基础上的安全关联 SA。

第 8 页

第 2 章 IPSec 及其 NAT 兼容解决方案

2.2 IPSec 与 NAT 的不兼容问题
主要由于以下的一些问题,导致目前的 IPSec 与 NAT 难以共存: (1)AH 与 NAT。 由于 AH 验证信息中包括对源地址及目的地址的验证, NAT 对 IP 地址信息的修改,会导致验证失败。 (2)校验和与 NAT 的不兼容。 TCP/UDP 的校验和需要使用到源地址和 目的地址信息,而 NAT 的转换,会使得校验和检验出错。 (3)IKE 的识别地址和 NAT 之间的冲突。在 IKE 的实现中使用地址作 为标识,在协商端点间,如果有 NAT 服务,就会更改地址信息,导致标 识与 IP 包头中的地址不配,从而识别失败。 (4)固定的 IKE 目的端口与 NAPT 不相容。由于 IKE 采用固定的目的 端口号 500, 当在 NAPT网关内部向同一外部主机发起 IKE 请求时, NAPT 不能正确的分解返回的数据包。 (5)SPD 入口与 NAT 不相容。需要通过目的地址定位一个安全策略, 因为有 NAT 的存在,使得无法查找到对应的策略入口。 (6)SA 选择符与 NAT 不相容。目前,若想标识一个安全关联 SA 需要 通过目的地址、安全参数索引 SPI、和协议(AH,ESP)来标识,因为有 NAT 的存在,使得无法查找到对应的外出/进入 SA。 (7)NAT 处理协议类型有限,一些 NAPT 实现丢弃非 TCP/UDP 包,这 种 NAPT 将不能传输 ESP 及 AH 数据包。 我们的解决方案必须能够解决以上的这些问题。

2.3 IPSec 的 NAT 兼容解决方案
综合考虑以上的问题,一种可行的方案是按照数据封装的思想,对 数据进行 UDP 封装。

2.3.1 IETF 的一个草案
在 IETF 的一个草案[11]中,提出了一种封装的方法,并给出了数据包 的封装格式,如图 2-4 所示: 其中的前 8 个字节为标准的 UDP 报头,源端口与目的端口采用与 IKE 相
第 9 页

第 2 章 IPSec 及其 NAT 兼容解决方案

同的值,校验和为零。非 IKE 标志为全 0 的 8 个字节,以与发起者的 IKE 的 cookie 保持对齐。
0 7 源端口 长度 非 IKE 标志 非 IKE 标志 ESP 头 图 2-4 UDP 封装的 ESP 头 15 23 目的端口 校验和 31

由此传送模式封装后的包格式为: 非 IKE 标志

原 IP 头

UDP 头

ESP 头

TCP

数据

ESP 尾

ESP 验证数据

通道模式封装后的包格式为: 原 IP 头 UDP 头 非 IKE 标志 ESP 头 IP 头 TCP 数据 ESP 尾 ESP 验证数据

该草案概要介绍了封装及解封装的几个步骤,即封装时首先进行原 来的 ESP 操作,然后添加 UDP 头及非 IKE 标志,调整 IP 头的长度等信 息;解封装时去除 UDP 头及非 IKE 标志,调整 IP 头的长度等信息,及 原来的 ESP 操作。 考虑 NAT 的具体情况及 IPSec 的结构,我们觉得上述封装方案存在 着问题: (1) 如前所述,在 IPSec 中,进入的安全关联 SA 由三个参数确定,即< 地址,协议,安全参数索引 SPI>。以 NAPT 为例,采用该方案,在外部 主机上,会有多个地址相同,SPI 不同的 SA。在处理进入数据包的时候, 我们可以用 SPI 值的不同来定位 SA;但是在处理外出数据包的时候,就 无法从多个有相同地址的外出 SA 中选择出正确的 SA 了。 (2) 若 NAT 网关为 NAPT,而发往内部各主机数据包的 UDP 封装的目的
第 10 页

第 2 章 IPSec 及其 NAT 兼容解决方案

端口号都为 500,这样一来,NAPT 就无法分解各个数据包究竟应该发送 到内部的哪一台主机。 (3) 从外部主机向 NAT 网关内的主机发送数据时,需要用该主机的非法 的 IP 地址为目的地址来定位 SA, 因此对于进入外部主机的数据包必须将 其源地址恢复成非法的 IP 地址然后再传递给上层协议,从而才能让应用 程序响应的数据包以此非法的 IP 地址为目的地址。此方案不对进入数据 包的源地址进行处理,会导致在发送相应数据包时无法正确定位相应的 SA.

2.3.2 我们的方案
通过分析 NAT 的通讯方式,IPSec 的结构及标准,并借鉴以上方案, 我们就此问题给出了我们的方案。 我们认为,为了定位安全关联,有必要将主机自身的 IP 地址一同进 行封装,因此封装格式为:
0 7 源端口 长度 原始 IP 地址 原协议 保留(全零) ESP(AH)头 图 2-5 改进的 UDP 封装的 ESP(AH)头 15 23 目的端口 校验和 31

其中前 8 个字节为标准的 UDP 报头,源端口号及目的端口号视通讯的情 况而言,将其设为有别于 IKE 端口号 500 的特定值,我们不妨设此特定 值为 501,这种设置方法也是参考了一篇关于此问题的 IETF 草案[10]。原 协议指原来 IP 头中的协议值。 由此以 ESP 封装为例, 我们的封装格式为:
原 IP 头 UDP 头 原 IP 地址 原协议 ESP 头 TCP 数据 ESP 尾 ESP 验证数据

详细的封装与解封装过程如图 2-6 所示。 A. 由 NAT 网关内主机向外部主机发送数据包
第 11 页

第 2 章 IPSec 及其 NAT 兼容解决方案

A1. 经过 IPSec 封装后,数据包以本机地址 IPC1 为源地址,以外部主 机地址 IPS 为目的地址。 A2. 对数据包进行 UDP 封装,并将本机地址 IPC1 附加在 UDP 报头后 面。在 UDP 报头中,以 501 为源以及目的端口,IP 头中的 IP 协议 变为 UDP,附带的协议值为 ESP 的协议值 PESP 。 B. 数据包经过 NAT 网关后到达外部主机 B2.到达外部主机的数据包经过 NAT 转换后, 以一个合法的 IP 地址 IPG 为源 IP 地址,以外部主机 IP 地址 IP S 为目的地址。其 UDP 报头中 的源端口号为 PC1 。 若 NAT 网关使用 NAPT, 则 PC1<>501, 否则 PC1=501。目的端口为 501。据此可以知道此数据包为 UDP 封装的 IPSec 包。因为其 IP 头中的 IP 地址 IPG 与附带的 IP 地址 IPC1 不一 致,因此可以知道它是从 NAT 网关内部发出的。这时,我们去除 UDP 报头,并用附带的 IP 地址 IPC1 替换 IP 头中的源 IP 地址,用 附带的协议值 PESP 替换 IP 头中的协议值, 成(B1)所示的数据包。 B1.可以看出,处理后的数据包(B1)与 NAT 网关内部的主机数据包经 过 IPSec 处理后得到的数据包(A1)完全相同。此时,进行正常的 IPSec 处理即可。 C.数据包由外部主机发往 NAT 网关内的主机 C1.待发送的经 IPSec 处理后的数据包如(C1)所示,此时源地址为本机 地址 IPS,目的地址为 IPC1。在 IPSec 处理的过程中,检索策略库 时可以知道,此为发往 NAT 网关内部的数据包,并可以找到保存 在策略库中的其对应的合法 IP 地址 IPG 及目的端口 PC1。然后进行 UDP 封装,封装后的数据包如(C2)所示。 C2.待发送的数据包经 UDP 封装后,目的地址为对应的合法 IP 地址 IPG, 头中的协议变为 UDP 协议值,源地址为本机地址 IPS,UDP IP 报头中源端口为 501,目的端口为 PC1。并附带本机地址 IPS,附带 的协议值为 PESP 。

第 12 页

第 2 章 IPSec 及其 NAT 兼容解决方案 (D2)IP 头 UDP 头 (C2)IP 头 UDP 头

IPS IPC1
(D1)IP 头

501 501

IPS
PESP

ESP ......

IPS IPG
(C1)IP 头

501 PC1

IPS
PESP

ESP ......

IPS IPC1
IPC1

ESP

......

IPS IPC1

ESP

......

501 PC1 NAT 网关 IPN
(B1)IP 头

IPS

IPC2
(A1)IP 头

501

PC2

IPC1 IPS

ESP

......

IPC1 IPS

ESP

......

(A2)IP 头 UDP 头

(B2)IP 头 UDP 头

IPC1 IPS

501 501

IPC1

PESP ESP ......

IPG IPS

PC1 501

IPC1

PESP ESP ......

图 2-6 UDP 封装及解封装示意 D.数据包经过 NAT 网关到达内部主机 D2.经过 NAT 网关到达内部主机的数据包为(D2)。此时,数据包的目 的地址为经过 NAT 转换后的地址 IPC1, 源地址为外部主机地址 IP S, UDP 报头的源端口为 501,目的端口也为 501,据此判断此数据包 为 UDP 封装的 IPSec 数据包。 而数据包的源 IP 地址与附带的 IP 地 址一致,可知其为外部主机发来的数据包。 D1.去除此数据包的 UDP 报头及附带的 IP 地址,并用附带的协议值 PESP 替换 IP 头中的协议值得到(D1)。可以看出此数据包与外部主 机在 IPSec 处理完毕后的数据包(C1)是完全相同的。 然后进行 IPSec 的验证及解密过程即可。

第 13 页

第 3 章 NAT 兼容的 IPSec 的实现

第 3 章 NAT 兼容的 IPSec 的实现
3.1 实施方案
IPSec 的实施有几种方案,可以与操作系统集成,可以嵌入到系统的 协议栈中作为堆栈中的块,也可以在路由器中用软件或硬件的方式实施。 我们采用的方案是: 利用 Linux 开放源代码, 通过修改内核的 TCP/IP 实现,在网络层实现 IPSec。采取这种方案,可以达到灵活配置的目的, 可以方便地根据实际需要把系统配置成为通道方式或传送方式,同时可 以较大程度的利用原系统的网络功能,避免相同功能的重复工作,采用 此种方案也避免了功能重复对系统性能造成的影响。

3.2 实施环境
在 Redhat 7.1 Linux,内核版本 2.4.2 下,用 C 语言实现。

3.3 系统框架
整个系统包括以下几个部分,各部分的关系如图 3-1 所示。 IPSec 功能模块 

SADB  /SPD 

SADB 管理模块 

加密解密及验证  算法模块 

IKE 模块 

图 3-1 各模块关系 IPSec 功能模块:用于根据安全关联 SA 完成数据的加密解密验证, 及数据包的封装与解封装操作。 SADB 安全关联库管理:维护与各个通信对象的安全关联。 IKE 动态密钥管理模块:用于协商共享密钥,完成 SA 的协商、建立、
第 14 页

第 3 章 NAT 兼容的 IPSec 的实现

修改等操作。 加密解密及验证算法模块:用于为 IPSec 功能模块及 IKE 模块提供 加密解密等算法接口。

3.4 关键技术 3.4.1 SPD 设计
在 SPD 的设计上,其外部表示采用配置文件的方式。用户可以通过 修改配置文件,来管理系统的安全策略。 综合考虑 SPD 设计的各项要求,可以看出其关于主机对主机、主机 对网络、网络对网络的配置要求,类似于路由表的匹配机制,因此我们 认为可以采用类似路由表匹配的方式进行安全策略的搜索。内部表示采 用路由表常用的 PATRICIA 树形结构存储,并采用相应的搜索算法搜索。 采用此种方案,可以节省存储空间,实现快速的搜索,并可以灵活 实现各种配置要求。

3.4.2 SADB 设计
SA 链头 . . . SA 链头 SA 块 SA 块 .. . SA 块

SA 块 SA 块 .. . SA 块

SA 块

.. .

SA 块

图 3-2 SADB 结构 SADB 的设计采用散列索引的链表方式,以协议值、SPI、目的地址 三个数据的综合,用散列算法计算索引,然后再相应的链上查找符合条 件的链头来定位需要的 SA。以 SA 链表的方式表示需要对数据包进行的 多次安全封装,即 SA 集束。数据的结构如图 3-2 所示。 采用此种方式,可以快速地搜索需要的 SA,并可以方便地表示 SA
第 15 页

第 3 章 NAT 兼容的 IPSec 的实现

集束。

3.4.3 与 IKE 的通信
利用消息机制来协调 IPSec 功能模块与 IKE 模块的运行,使得各模 块相对独立。当发现 SA 已经过期或要求的 SA 不存在时,向 IKE 发送消 息,申请建立新的 SA。

3.4.4 何时何处实施 IPSec 服务
1.外出方向。通过采用虚拟网络设备技术,在系统中增加虚拟的网 络接口设备。在注册虚拟设备时规定其发送处理函数,并修改系统的路 由信息表,使得外出数据包首先流经虚拟网络接口设备,从而获得对数 据包的控制权,对数据包进行 IPSec 处理,完成数据的加密验证封装处理 后,再到达与虚拟设备对应的实际网络设备。 2. 进入方向: 通过修改 LINUX 中的 IP 包处理函数 ip_local_deliver(), 首先检查是否是 UDP 封装的 IPSec 数据包,若是的话,剥除 UDP 封装, 并恢复 IP 包头中的地址及协议等信息, 然后交给上层协议处理函数处理。 在系统中定义新的协议 AH 与 ESP,并定义其处理函数 ipsec_rcv()。当系 统检查到 IP 头中的协议值为 ESP 或 AH,则调用 ipsec_rcv()来进行数据 包的处理,验证或解密成功后,把数据包交付给上层协议处理。

3.4.5 NAT 兼容处理
如前所述的方案,通过采用 UDP 封装以实现与 NAT 技术兼容。首 先需要知道是否存在 NAT 转换,这可以由改进后的 IKE 过程发现,并记 录在 SPDB 中。 发送数据包时如果查找 SPDB 发现需要 IPSec 处理并且存在 NAT 转 换,那么就需要在 IPSec 处理完后,进行 UDP 封装操作,根据 IKE 发现 的对方相应的合法 IP 地址及端口信息,设置外部 IP 头中的目的地址及 UDP 头中的目的端口号。同时把本机的 IP 地址及最外层的协议值一同封 装在数据包内,然后发送。 接收数据包时,如果收到的为一个 UDP 数据包,并且其源端口或目 的端口至少有一个为 501,则说明是一个 UDP 封装的 IPSec 数据包。此
第 16 页

第 3 章 NAT 兼容的 IPSec 的实现

时,需要用附带的 IP 地址替换 IP 头中的源地址,用附带的协议值替换 IP 头中的协议字段,并剔除 UDP 头及附带的 IP 地址及协议字段,然后交给 上层协议处理。

3.4.6 验证及加密解密算法
验证算法及加密解密算法设计成为函数的形式,在需要进行验证或 者加密解密操作时,向函数传递需处理数据的指针以及密钥、长度、初 始化向量等信息来调用相应的函数,然后读取返回指针处的处理后的数 据。 采用此种方法,可以使系统有较好的可扩充性能,当需要增加新的 加密解密或验证算法时,只需作很小的改动即可实现。

第 17 页

第 3 章 NAT 兼容的 IPSec 的实现

3.5 系统流程
数据流向如图 3-3 所示: 外出数据包 内核 IP 处理 上层协议

路由表查询 不 需 要 IPSec 处 理 需要 IPSec 处理 虚拟接口 安全策略库 IPSECDEV 搜索 Spdbtree,找到与 dst 对应的外 <src/dst> 出 SPI SA dst/SPI 根据 SPI 等信息找到 SA,决定对数 据包做何种操作。 Sa group Sa group 查看是否有其他的协议需要作用于 此数据包 IPSec 处理 如有 NAT 则用 UDP 封装 否 Dst=本机 是 地址? IPSec 处理 SPI 否 是 下一协议为 AH 或 ESP



解 UDP 封装 是

UDP501 数据包?

实际网络设备 进入数据包 图 3-3 外出及进入数据包的处理示意

第 18 页

第 3 章 NAT 兼容的 IPSec 的实现

3.6 实现中的技术细节问题
(1) MTU 问题。由于 ESP、AH 及 UDP 封装都占用了 IP 包数据部分 的长度,如果不考虑 MTU,会导致完成各种封装之后包长度大于 MTU。 虽然 IPSec 不会受分段的影响, 因为 IP 包的分段是在 IPSec 处理之后进行的,而分段的重组是在 IP 层调用 IPSec 功能之前进 行的,但是考虑到效率及可靠性问题,仍然需要尽量避免分段情 况的产生。因此在进行 IPSec 处理时,若各种封装的长度加上原有 数据的长度大于路径的 MTU,则用他们的差值修改最大段长度 MSS(Max Segment Size),以避免分段情况的出现。 (2) IKE 数据包处理。由于存在 NAPT 的情形,在判断一个数据包是 否为 IKE 数据包时,不能仅仅根据目的端口号为 500 来确定。从 NAT 网关内部向外部主机发送 IKE 数据包,外部主机的 IKE 响应 数据包为了穿越 NAPT,其 UDP 头中的目的端口应设置为 NAPT 网关上对内部主机的映射端口号,因此,这时的目的端口号不等 于 500,在进行 IPSec 的发送处理检查是否为一个 IKE 数据包时, 应检查当源端口或目的端口号其中任意一个为 500, 即认为是 IKE 数据包。 (3) 安全策略库中的 NAT 信息支持。 采用上文所述的 UDP 封装方案, 从 NAT 网关内部发往 NAT 网关外部的数据包,在经过 UDP 解封 装后,其源地址更改为原始 IP 地址,因此目标主机的 IP 层以上的 各层会认为通讯对方的 IP 地址为内部主机的原始 IP 地址, 它发送 的数据包也将以该原始 IP 地址为目的地址。然而,此原始的 IP 地址为一个非法的 IP 地址。要想正确地发送此数据包,必须在 IPSec 处理完成后,进行 UDP 封装时,将其目的地址更改为与此 原始 IP 地址相对应的合法 IP 地址,并将 UDP 包头中的目的端口 号设置为与此原始 IP 地址相对应的端口号。因此需要将这些合法 地址及端口信息添加到安全策略库中。 这个任务可由改进后的 IKE 来完成。
第 19 页

第 3 章 NAT 兼容的 IPSec 的实现

(4) UDP 封装后,IP 包头校验和重计算。在 UDP 封装后或者在解除 UDP 封装之后,IP 头中的 IP 地址可能改变,这时需要重新计算 IP 头的校验和,否则系统会认为 IP 数据包的校验和错误。

3.7 外出数据包与进入数据包处理
外出数据包处理流程如图 3-4 所示: 1. 2. 3. 4. 计算硬件头长度 根据源地址与目的地址查 SPDBTREE,得到 SPI 检查是否是端口为 500 的 UDP 数据包,若是则设置通过标志, 转到通过处 开始封装循环 4.1 检查 SPDBTREE 搜索结果是否为放弃或拒绝,若是,则转清 除处 4.2 检查 SPDBTREE 搜索结果是否为通过,若是,则转通过处 4.3 查找取得 SADBL 链头 4.4 检查 SPDBTREE 搜索结果是否为 NAT 方式,若是,则计算 所占的头长度,并保存相应的合法地址及端口 4.5 保存 SADBL 链头,开始计算封装长度的循环 4.5.1 检查 SA 是否过期,如果已经过期则发送消息给 IKE, 要求建立新的 SA。如果已经超出硬生存期,则删除 SADBL 链,转到清除处 4.5.2 根据 SA 规定的协议类型,相应地计算所占的头长度 4.5.3 根据 SA 规定的协议类型,相应地计算所占用的尾部长 度 4.5.4 取下一个节点 4.6 检查增加了以上各种封装后长度是否满足 MTU 要求,如果 超出则调整最大段长度 MSS,丢弃数据包,转到清除处 4.7 如果有硬件头则将其保存起来,再将其剥除 4.8 恢复指向 SADBL 头,开始封装 4.8.1 扩展数据包,使其增加封装头加封装尾的大小,将数据
第 20 页

第 3 章 NAT 兼容的 IPSec 的实现

部分向后移动封装的头大小 4.8.2 如果为 ESP 协议,填写封装头,更新序列号,提取 IV 数据,尾部填充,调用加密函数进行加密,更新 IV, 调用验证函数进行验证 4.8.3 如果为 AH 协议,填写封装头,更新序列号,调用验证 函数进行验证 4.8.4 如果为 IPIP,则设置 IP 头信息,设置其源地址与目的 地址为 SA 中指定的源地址与目的地址 4.8.5 重新计算 IP 头的校验值,更新 SA 的生存期数据,取下 一个 SADBL 节点 4.9 以新地址搜索 SPDBTREE,如果找到匹配项,并且目的地址 发生了变化则回到循环开始处,再次进行以上操作 5. 如果是 NAT 的情况,则添加 UDP 头及附带的 IP 地址并设置 IP 头中的地址为检索 SPDBTREE 得到的地址,设置 UDP 头中的目 的端口号为检索 SPDBTREE 得到的端口号,源端口号为 501。 6. 如果剥除了硬件头则恢复之 7. [通过]设置数据包关联设备为实际网络设备 8. 发送数据包 9. [清除]释放数据包占用的空间

第 21 页

第 3 章 NAT 兼容的 IPSec 的实现

路由表查询 路由到 IPSec 虚拟设备吗? 是 搜索 spdbtree 得 SPI,根据 SPI,地 址及协议取得 sadbl 链 sadbl 所指的 SA, 过期吗? 否 根据协议类型计算并 累计长度。 是 有下一个 sa 吗? 否 有 NAT 吗? 否 总长度大于 MTU 吗? 否 回到 sadbl 头,开始 IPSec 处理 如有 NAT 则进行 UDP 封装处理 根据 sadb 中 SA 的协议及加密算法字段 调用相应的加密算法处理数据 是 有下一个 sa 吗? 否 设置实际网络设备 是 是 发送 SA 过期消息的给 IKE, 若大于硬生存期 则丢弃包返回,否则继 续发送操作 否



总长度增加 UDP 封装的长度值

调整 MSS, 丢弃包返回

发送数据
图 3-4 IPSec 外出数据包处理

第 22 页

第 3 章 NAT 兼容的 IPSec 的实现

进入数据包处理流程如图 3-5 所示: 1. 2. 3. 4. 如果是端口为 501 的 UDP 数据包,则根据附带的 IP 地址更改 IP 头中的源地址,并剥除 UDP 报头。 检查协议值是否为 ESP 或 AH 确定到达的网络设备 开始解封装循环 4.1 取地址、协议及 SPI 信息 4.2 根据地址、协议及 SPI 信息查找 SADBL 得到 SADBL 链头 4.3 检查 SA 的状态是否正常,如果不正常则丢弃数据包 4.4 检查生存期是否正常,如果过期则发送消息给 IKE 要求建立 新的 SA,如果已经超过硬生存期则丢弃数据包 4.5 读取验证数据及序列号 4.6 检查序列号是否是重播序列号 4.7 根据 SA 中的信息,计算收到数据的验证值,并与收到的验证 值相比较,如果不相同则说明验证失败,丢弃数据包 4.8 更新抗重播窗口 4.9 若是 ESP 协议,则根据 SA 中的信息,调用相应的解密函数进 行解密操作 4.10 剥除 ESP 或 AH 封装,设置 IP 头中的协议为下一个头的协 议,调整指针,并重新计算 IP 头的校验和 4.11 更新生存期数据,当下一协议为 ESP 或 AH 则继续解封装循 环 5. 6. 如果还有 IPIP,则剥除一层 IP 头。 传递数据包给下一个协议

第 23 页

第 3 章 NAT 兼容的 IPSec 的实现

是 UDP501 包吗? 否 正确性判断,有无数据, 头长度等 是 AH 或 ESP 格式吗? 是 根据协议类型,提取 SPI,并根据 SPI 搜索 sadb



去除 UDP 报头并 更改 IP 头中的地址



丢弃数据包

否 SA 状态正确吗? 是 根据 SA 指定的验证 算法进行验证 否

若已经超过生存期发送 SA 过期消息的给 IKE, 若 大于硬生存期或者 SA 未 完全生成,则丢弃包返回, 否则继续接收操作

验证成功吗?
是 根据 SA 指定的解密 算法进行解密 是 有下一个 sa 吗? 否 把解开的包交给上层协议

丢弃数据包

图 3-5 接收到 IPSec 数据包的处理

第 24 页

第 3 章 NAT 兼容的 IPSec 的实现

3.8 性能评价
为了评价 IPSec 的性能,我们在实验室的环境下进行了测试。 

3.8.1 测试环境
将 IPSec 配置在两台主机上,一台称为 Linux,一台称为 Linux1。保 护方式为采用 3DES 加密,采用 SHA1 验证,通道方式的 ESP 封装协议。 两台主机均为:Pentium II 350, 128M RAM, 10M Ethernet, Redhat 7.1。分 别在配置 IPSec 与不配置 IPSec 的情况下, 比较从 Linux1 Ping Linux 的时 延,并测试两种情况下的用 FTP 传送大文件的时延差别。

3.8.2 测试结果及分析
1. Ping 时延比较: 
组 号 1 2 3 4 5 200 400 600 800 1000 包规格 0.522 0.710 1.074 1.477 1.803 无 IPSec 有 IPSec

Min(ms)Avg(ms) Max(ms) Min(ms) Avg(ms) Max(ms) 0.529 0.833 1.158 1.487 1.817 0.580 0.891 1.226 1.533 1.927 0.936 1.200 1.868 2.343 2.789 0.952 1.328 1.893 2.365 2.804 1.106 1.440 1.953 2.595 2.880

图 3-6 有无 IPSec 的 Ping 时延比较  2. 用 FTP 从 Linux 上复制一个 120.6M (126494720Bytes)的文件到 Linux1,  配置有 IPSec 时:用时 203 秒  配置无 IPSec 时:用时 172 秒  从以上的比较结果可以看出,配置了 IPSec 之后对系统处理数据包 的速度及网络的带宽利用造成了一定的影响,但是综合考虑实现的安全 服务,这种影响是在可容忍范围之内的。 

第 25 页

第4章 结



 

第4章 结
4.1 国内外的研究情况



目前世界上对 IPSec 的研究是网络技术研究的一个热点, IETF 的 IPSec 工作组给出了 IPSec 的结构框架和相应的建议, 他们制定的一系列 关于 IPSec 的 RFC 文档,为实现 IPSec 系统提供了一定的依据和方向。 而且关于 IPSec 改进的各种文章也正在大量涌现。  当前国内外已经有一些 IPSec 的实现,其中包括各种方式。有的在 路由器中实现,如 Cisco 7140VPN 路由器等产品,也有的与操作系统集 成,例如 WIN2000 中的 IPSec 实现。国内见诸文献的是东南大学顾冠群 老 师 在 LINUX 下的实现,其课题是国家 863 高 科 技 发 展 计 划 项 目 “Extranet 关键技术研究”资助的。  关于 IPSec 的 NAT 兼容性改进的研究现在刚刚起步,现在是 IETF 的 短期研究目标之一,关于此问题的草案刚发布不久,也正处于研究改进 阶段,目前尚未见关于此问题的具体实现。  本文是吉林省的自然科学基金项目《基于 Internet 网络层安全技术 的研究》的一部分,该项目已于日前通过了吉林省科委组织的鉴定。我 们在实现 IPSec 的基础上,综合考虑了 NAT 与 IPSec 的兼容性问题,基 于隧道技术的思想, 及受 IETF 的关于 NAT 与 IPSec 的兼容性解决方案草 案的启发,解决了实现中的一些技术问题,最终给出了与 NAT 兼容的 IPSec 实例。

4.2 本文的特点及意义
本文在研究 IPSec 结构框架的基础上,综合考虑 TCP/IP 的协议处理 流程,提出了建立安全关联数据库和安全策略数据库实际实施方案,与 IKE 及加密解密模块的接口方式,更进一步地,在此基础之上,提出了一 种 NAT 兼容的封装方法,实现了 IPSec 与 NAT 的兼容。  本文的研究为 IPSec 以后的研究工作奠定了坚实的基础。本文的实 现基于开放源代码的操作系统 Linux 之上,为今后的 IPSec 的研究工作
第 26 页

第4章 结



构筑了一个试验平台。 

4.3 应用前景
IPSec  有着广阔的应用天地, 在各种需要安全服务的应用场合, IPSec 都可以提供强有力的安全支持,例如在 VPN 的构建,及远程移动办公等 方面。  本文的研究成果已经达到实用的水平,LINUX 系统的价格优势,使得 任何用户可以用较低的费用获得优质的安全服务。而 NAT 的兼容更使得 用较少的 IP 地址实现 IPSec 功能成为可能,从而进一步压缩了安全服务 的成本。 

4.4 不足之处及今后的研究课题
1. 目前的 NAT 兼容方案,实现的是 NAT 网关内部与外部主机之间 的安全通信,对于通信双方都处于 NAT 网关内部的情况,需要进一步的 研究。 2. 若 NAT 网关的 NAT 映射是动态的,那么如果其上的映射关系发 生变化过于频繁的话,会导致通讯对方的 IPSec 维护费用增加。对此种情 况的解决方案是,NAT 网关内部的主机定时地向 NAT 网关发送保持活性 的数据包,以使映射关系稳定。这部分工作尚未完成,需要进一步实现。 在 IPSec 领域中,尚有许多待解决的问题。如的同主机多身份的安全 服务问题,其他还有多播情况下的安全服务问题,实现安全服务的同时 提高 QoS 的问题等等,这些都需要进一步的研究。

第 27 页

参 考 文 献

参 考 文 献
  1.  [RFC-2401] Stephen Kent and Randall Atkinson,  ” Security  Architecture for the Internet Protocol” , RFC 2401,November  1998  2.  [RFC-2402] Stephen Kent and Randall Atkinson,  ” IP  Authentication Header” , November 1998  3.  [RFC-2406] Stephen Kent and Randall Atkinson,  ” IP  Encapsulating Security Payload (ESP)” , RFC 2406,November 1998  4.  [RFC-2407] Derrell Piper, ” The Internet IP Security Domain of  Interpretation for ISAKMP” , November 1998  5.  [RFC-2408] Douglas Maughan, Mark Schneider, Mark Schertler and  Jeff Turner, ” Internet Security Association and Key Management  Protocol ISAKMP” , November 1998  6.  [RFC-2409] Dan Harkins and Dave Carrel,  ” The Internet Key  Exchange (IKE)” , November 1998  7.  [RFC-1631]  K.Egevang and  P.Francis,"The IP Network Address  Translator (NAT)", May 1994  8.  [RFC-3022]  P.Srisuresh and  K.Egevang,"Traditional NAT",  January 2001  9.  [IETF-DRAFT]  Bernard Aboba,"IPsec-NAT Compatibility  Requirements",March 2002  10.  [IETF-DRAFT] W. Dixon, B. Swander  and  A. Huttunen and  J.  Sierwald and V. Volpe and L. DiBurro and M. Stenberg and T.  Kivinen,"IPsec over NAT Justification for UDP Encapsulation",  June 2001  11.  [IETF-DRAFT] A. Huttunen and W. Dixon and B. Swander and T.  Kivinen and  M. Stenberg and  V. Volpe   and  L. DiBurro,"UDP 
第 28 页

参 考 文 献

Encapsulation of IPsec Packets",October 2001  12.  《IPSec-新一代因特网安全标准》 ,Naganand Doraswamy and Dan  Harkins, 机械工业出版社 2000  13.  《Internet 网络层安全协议的研究与实现》 ,赵阿群 袁媛 吉逸 顾 冠群, 《第一届信息和通信安全— CCTCS’ ,2000 年  99》 14.  《基于 Internet 安全策略的研究与实现》 ,陈志雨,吉林大学硕士研 究生毕业论文,2001 年 

第 29 页









现在 Internet/Intranet 的应用高速增长,但是 TCP/IP 协议在安全方面 存在着不足。网络应用对于传输安全的需求,使得对计算机网络安全技 术的研究步伐也日趋加快。 IPSec(IP Security)协议是 IETF(Internet Engineering Task Force)提出的 一系列安全标准,是在网络层对数据分组提供加密解密及安全鉴别以实 现数据源鉴别、数据完整性、信息保密、不可否认服务、抗重播、流量 保密等安全服务。 IPSec 主要由四个部分组成:安全协议、安全关联、加密解密和鉴别 算法以及密钥管理。 IPSec 已被定为 IPv6 的组成部分。然而由于 IPSec 对数据包的保护, 对数据包的改动会导致验证及解密的失败, 因此 IPSec 与目前广泛使用的 一种技术 NAT(Network Address Translation)网络地址翻译相抵触。 网络地址翻译的做法是,在内部网络中使用内部地址,通过 NAT 把 内部地址翻译成合法的 IP 地址在 Internet 上使用。具体来说就是把 IP 包 内的 IP 地址用合法的 IP 地址来替换, 而作为 NAT 的一种, NAPT(Network Address Port Translation)还需要通过修改数据包中 TCP 或 UDP 协议的端 口来实现地址翻译,正因如此,NAT 与 IPSec 在以下几个方面难以共存: (1)AH 与 NAT。 由于 AH 验证信息中包括对源地址及目的地址的验证, NAT 对 IP 地址信息的修改,会导致验证失败。 (2)校验和与 NAT 的不兼容。 TCP/UDP 的校验和需要使用到源地址和 目的地址信息,而 NAT 的转换,会使得校验和检验出错。 (3)IKE 的识别地址和 NAT 之间的冲突。在 IKE 的实现中使用地址作 为标识,在协商端点间,如果有 NAT 服务,就会更改地址信息,导 致标识与 IP 包头中的地址不配,从而识别失败。 (4)固定的 IKE 目的端口与 NAPT 不相容。由于 IKE 采用固定的目的 端口号 500,当在 NAPT 网关内部向同一外部主机发起 IKE 请求时, NAPT 不能正确的分解返回的数据包。
I





(5)SPD 入口与 NAT 不相容。需要通过目的地址定位一个安全策略, 因为有 NAT 的存在,使得无法查找到对应的策略入口。 (6)SA 选择符与 NAT 不相容。目前,若想标识一个安全关联 SA 需要 通过目的地址、安全参数索引 SPI、和协议(AH,ESP)来标识,因 为有 NAT 的存在,使得无法查找到对应的外出/进入 SA。 (7)NAT 处理协议类型有限,一些 NAPT 实现丢弃非 TCP/UDP 包,这 种 NAPT 将不能传输 ESP 及 AH 数据包。 就以上的问题,解决的基本思想是采用隧道的思想,把 IPSec 保护的 数据包再次封装在 UDP 包中发送,以达到穿越 NAT 的目的。IETF 已经有 一个这样的草案,其封装格式如图 1 所示: 
0         1         2         3  01234567890123456789012345678901  ++++++++++++++++++++++++++++++++  | Source Port  |   Dest Port   |  ++++++++++++++++++++++++++++++++  |    Length    |   Checksum    |  ++++++++++++++++++++++++++++++++  |       Non-IKE Marker         |  ++++++++++++++++++++++++++++++++  |       Non-IKE Marker         |  ++++++++++++++++++++++++++++++++  |    ESP header [RFC 2406]     |  ++++++++++++++++++++++++++++++++  0         1         2         3  01234567890123456789012345678901  ++++++++++++++++++++++++++++++++  | Source Port  |   Dest Port   |  ++++++++++++++++++++++++++++++++  |    Length    |   Checksum    |  ++++++++++++++++++++++++++++++++  |    Original IP address       |  ++++++++++++++++++++++++++++++++  | proto|        reserved       |  ++++++++++++++++++++++++++++++++  |    ESP header [RFC 2406]     |  ++++++++++++++++++++++++++++++++ 

  图 1  IETF 草案封装方案 

     图 2  我们的封装方案 

其中:前 8 个字节为标准的 UDP 头,源端口与目的端口采用与 IKE 相同的值,校验和为零。非 IKE 标志为全 0 的 8 个字节,以与发起者的 IKE 的 cookie 保持对齐。 考虑 NAT 的具体情况及 IPSec 的结构,我们觉得上述封装方案存在 着问题: (1) 在 IPSec 中,进入的安全关联 SA 由三个参数确定,即<地址,协议, 安全参数索引 SPI>。以 NAPT 为例,采用该方案,在外部主机上,会有 多个地址相同,SPI 不同的 SA。在处理进入数据包的时候,我们可以用
II





SPI 值的不同来定位 SA;但是在处理外出数据包的时候,就无法从多个 有相同地址的外出 SA 中选择出正确的 SA 了。 (2) 若 NAT 网关为 NAPT,而发往内部各主机数据包的 UDP 封装的目的 端口号都为 500,这样一来,NAPT 就无法分解各个数据包究竟应该发送 到内部的哪一台主机。 (3) 从外部主机向 NAT 网关内的主机发送数据时,需要用该主机的非法 的 IP 地址为目的地址来定位 SA。 此方案不对进入数据包的源地址进行处 理,则上层应用程序响应的数据包不会以此非法的 IP 地址为目的地址, 从而会导致在发送相应数据包时无法正确定位相应的 SA. 我们认为,为了定位安全关联,有必要将主机自身的 IP 地址一同进 行封装,因此封装格式如图 2 所示。 其中前 8 个字节为标准的 UDP 报头,源端口号及目的端口号视通讯 的情况而言,将其设为有别于 IKE 端口号 500 的特定值,我们不妨设此 特定值为 501,这种设置方法也是参考了一篇关于此问题的 IETF 草案。  以 ESP 协议的 UDP 封装为例,详细的封装与解封装过程为: A. 由 NAT 网关内主机向外部主机发送数据包 1. 经过 IPSec 封装后,数据包以本机地址 IPC1 为源地址,以外部主机 地址 IPS 为目的地址。 2. 对数据包进行 UDP 封装, 并将本机地址 IPC1 附加在 UDP 报头后面。 在 UDP 报头中,以 501 为源以及目的端口,IP 头中的 IP 协议变为 UDP,附带的协议值为 ESP 的协议值 PESP 。 B. 数据包经过 NAT 网关后到达外部主机 1. 到达外部主机的数据包经过 NAT 转换后, 以一个合法的 IP 地址 IPG 为源 IP 地址,以外部主机 IP 地址 IP S 为目的地址。其 UDP 报头中 的源端口号为 PC1 。 若 NAT 网关使用 NAPT, 则 PC1<>501, 否则 PC1=501。目的端口为 501。据此可以知道此数据包为 UDP 封装的 IPSec 包。这时,我们去除 UDP 报头,并用附带的 IP 地址 IPC1 替 换 IP 头中的源 IP 地址, 用附带的协议值 PESP 替换 IP 头中的协议值。 2. 可以看出,处理后的数据包与 NAT 网关内部的主机数据包经过
III





IPSec 处理后得到的数据包完全相同。此时,进行正常的 IPSec 处 理即可。 C.数据包由外部主机发往 NAT 网关内的主机 1. 待发送的经 IPSec 处理后的数据包源地址为本机地址 IPS,目的地 址为 IPC1。在 IPSec 处理的过程中,检索策略库时可以知道,此为 发往 NAT 网关内部的数据包,并可以找到保存在策略库中的其对 应的合法 IP 地址 IPG 及目的端口 PC1。然后进行 UDP 封装。 2.待发送的数据包经 UDP 封装后, 目的地址为对应的合法 IP 地址 IPG, IP 头中的协议变为 UDP 协议值,源地址为本机地址 IP S,UDP 报 头中源端口为 501,目的端口为 PC1。并附带本机地址 IPS,附带的 协议值为 PESP 。 D.数据包经过 NAT 网关到达内部主机 1. 经过 NAT 网关到达内部主机的数据包的目的地址为经过 NAT 转换 后的地址 IPC1,源地址为外部主机地址 IPS,UDP 报头的源端口为 501,目的端口也为 501,据此判断此数据包为 UDP 封装的 IPSec 数据包。 2. 去除此数据包的 UDP 报头及附带的 IP 地址, 并用附带的协议值PESP 替换 IP 头中的协议值。 可以看出此数据包与外部主机在 IPSec 处理 完毕后的数据包是完全相同的。然后进行 IPSec 的验证及解密过程 即可。 对于我们的 UDP 封装方案,从 NAT 网关内部发往 NAT 网关外部的 数据包,在经过 UDP 解封装后,其源地址更改为原始 IP 地址,因此目标 主机的 IP 层以上的各层会认为通讯对方的 IP 地址为内部主机的原始 IP 地址,它发送的数据包也将以该原始 IP 地址为目的地址。然而,此原始 的 IP 地址为一个非法的 IP 地址。 要想正确地发送此数据包, 必须在 IPSec 处理完成后,进行 UDP 封装时,将其目的地址更改为与此原始 IP 地址相 对应的合法 IP 地址,并将 UDP 包头中的目的端口号设置为与此原始 IP 地址相对应的端口号。因此需要将这些合法地址及端口信息添加到安全 策略库中。这个任务可由改进后的 IKE 来完成。 
IV

ABSTRACT

Abstract
The applications based on Internet/Intranet have largely increased today, but TCP/IP has its shortage on security. The security transport that demand by applications based on network accelerates the study on the security technology of computer network. IPSec(IP Security) is the combination of series security standards. It encrypts and makes authentication at network layer in order to provide the security services such as data origin authentication ,data integrity, confidentiality , undeniable communication, protection against replays, and limited traffic flow confidentiality. IPSec is combined with four parts, they are: Security Protocols, Security Association, Encryption and Authentication Algorithms and Key Management. IPSec has been defined as a part of IPv6. Because of the security protection of IPSec, any changes make on the packet will lead to the failure of decryption and authentication. That's why IPSec is in conflict with a widely adapted network technology, which named NAT(Network Address Translation). We can use illegal IP address in a private network. NAT translate the illegal address of our private network to a legal address and use it on Internet. It substitutes legal address for the illegal address in the head of IP packet. As for NAPT, a sort of NAT, it changes the port value of TCP or UDP additionally to implement the translation of address. Because of that, there are several incompatibilities between NAT and IPSec: (1) Incompatibility between IPSec AH and NAT. Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT devices’ making changes to address fields will invalidate the message integrity check. (2) Incompatibility between checksums and NAT. TCP/UDP checksums has a dependency on the IP source and destination addresses. As a result, where checksums are calculated and checked on receipt, they will be invalidated by passage through a NAT or reverse NAT device. (3) Incompatibility between IKE addressess identifiers and NAT. Where IP addresses are used as identifiers in IKE, modification of the IP source or destination addresses by NATs will result in a mismatch between the identifiers and the addresses in the IP header. (4) Incompatibility between fixed IKE destination ports and NAPT. Because IKE use fixed IKE destination port value 500, where multiple hosts behind the NAPT initiate IKE SAs to the same responder, a mechanism is needed to allow the NAPT to demultiplex the incoming IKE packets. (5) Incompatibilities between overlapping SPD entries and NAT. Since IPSec SAs
V

ABSTRACT

existing between the same endpoints appear to be equivalent, when hosts behind a NAT negotiate overlapping SPD entries with the same destination, packets may be sent down to the wrong IPSec SA. (6) Incompatibilities between IPSec SPI selection and NAT. At present, the combination of Destination IP, SPI, and Security Protocol (AH, ESP) uniquely identifies a Security Association. Because of existance of NAT, it is unable to allocate the inbound and outbound SAs. (7) Incapatability to handle non-UDP/TCP traffic. Some NAPTs discard non-UDP/TCP traffic. Such NAPTs are unable to pass ESP (protocol 50) or AH (protocol 51) traffic. The idea to solve those problems is derived from tunnel idea. Encapsulate the packet which has been protect by IPSec in a UDP packet to provide IPSec a NA(P)T traversal capability. There is an IETF draft talking about this, the encapsulation format is described as follows as figure 1: 01234567890123456789012345678901  ++++++++++++++++++++++++++++++++  | Source Port  |   Dest Port   |  ++++++++++++++++++++++++++++++++  |    Length    |   Checksum    |  ++++++++++++++++++++++++++++++++  |       Non-IKE Marker         |  ++++++++++++++++++++++++++++++++  |       Non-IKE Marker         |  ++++++++++++++++++++++++++++++++  |    ESP header [RFC 2406]     |  ++++++++++++++++++++++++++++++++  01234567890123456789012345678901  ++++++++++++++++++++++++++++++++  | Source Port  |   Dest Port   |  ++++++++++++++++++++++++++++++++  |    Length    |   Checksum    |  ++++++++++++++++++++++++++++++++  |    Original IP address       |  ++++++++++++++++++++++++++++++++  | proto|        reserved       |  ++++++++++++++++++++++++++++++++  |    ESP header [RFC 2406]     |  ++++++++++++++++++++++++++++++++ 

Figure 1 the encapsulation of draft
The UDP header is a standard header, where

Figure2our encapsulation format

Source Port and Destination Port are the same as used by IKE traffic. Checksum is zero. Non-IKE Marker is 8 bytes of zero aligning with the Initiator Cookie of an IKE packet. Considering of NAT and IPSec architecture, I think that there are still some problems to that solution: (1)In IPSec, the inbound SA is uniquely identified by the combination of Destination IP, SPI, and Security Protocol (AH, ESP). When the NAT device is an NAPT device, there will be several SAs whose addresses are the same. When handle the inbound packets we can pick out the SA by using deferent SPIs, but when we handle with
VI

ABSTRACT

the outbound packets, we can’ pick out the right SA from SAs whose addresses are the t same. (2) If the NAT device is an NAPT device, because the destination port of IKE packet is 500, the NAT device will be unable to demultiplex the incoming packets. (3) When we send the packet from the host outside to the host behind the NAT device, we should use the illegal address of that host to allocate the SA. If we use that encapsulation format, the source address of the packet that arrived at the host outside will not be changed back to the illegal address. So the above layers will not destine its responding packet to the illegal address. That will result in a wrong allocation of SA. To my opinion, in order to allocate the SA, it is necessary to encapsulate the IP address of the sender into the packet. So we have the encapsulation format shown in figure 2. The UDP header is a standard header, where Source Port and Destination Port are particular values deferent from IKE port value 500. According to another IETF draft related to this topic, we temporally set the value to 501. Checksum is zero. Taking the UDP encapsulation of ESP for example, the encapsulation and decapsulation procedures are shown as below: A. Send the packet from the host behind the NAT device to the host outside. 1. After encapsulation of IPSec, the packet's source address is its own address IPC1 and its destination address is the address of the host outside IPS. IPC1 2. Encapsulate the packet with UDP, and attach with the IP address o its own f after the UDP head. The attached protocol will be PESP . The source and the

destination port is 501. The protocol field in the IP head set to UDP. B. The packet travels through the NAT device and arrives at the host outside. 1. After transformed by the NAT device, the packet has a legal address IPG as its source address; its destination address is IPS, which is the IP address of the host outside. The source port in the UDP head is PC1 . If the NAT device is a NAPT device then PC1 <>501, else PC1 =501.The destination port in the UDP head is 501. Check the port values we can perceive that the packet is a UDP encapsulated IPSec packet, so we should strip off the UDP head and replace the source address in the IP head with IPC1 which is the IP address attached after the UDP head, replace the protocol in IP head with PESP which is the protocol attached after the UDP head. 2. After strip off the UDP head, we get a packet that is just as same as the packet that has been dealt with by IPSec at the host behind the NAT device. Now we can handle it by using the regular IPSec procedure. C. Send the packet from the host outside to the host behind the NAT device. 1. The packet has source address IPS, which is its own IP address, and
VII

ABSTRACT

destination address IPC1. When handle it with IPSec, we know it is a packet that will be send to a host behind the NAT device according to the information in the SPD (Security Policy Database). So we encapsulate it with UDP, using IP address IPG and port value PC1 that are recorded in the SPD. 2. After UDP encapsulation, the packet's source address is a legal address , which is IP G , its protocol in the IP head is UDP, and its source address is IPS, which is its own IP address. The source port in its UDP head is 501 and the destination port in its UDP head is PC1 . The attached IP address is IPS and the attached protocol is PESP . D. The packet travels through the NAT device and arrives at the host behind the NAT device. 1. After the transformation of the NAT device, the packet's destination address is IPC1 and its source address is IPS, which is the IP address of the host outside. The source port and destination port of the UDP head are both 501, so we know that it is an IPSec packet encapsulated with UDP. 2. Strip off the UDP head of the packet, replace the protocol in the IP head with PESP which is the attached after the UDP head, we get a packet that is just as same as the packet which has been dealt with by IPSec at the host outside, so we can handle it by using the regular IPSec procedure. If we use the encapsulation method that is discussed above, the packet's source address will be changed from a illegal address to an legal address when it is sent out from the host behind the NAT device, and changed back from a legal address to an illegal original address after being striped of the UDP head at the host outside. So the upper protocol layers above the network layer of the host outside will think that they are communicating with a host with that illegal address and the packet it send out will have the destination to that illegal address. In order to send out the packet correctly, we must set the destination address to a legal address which corresponding to the illegal address and set the port value of the UDP head to the corresponding port of the illegal address. We should find these address and port information in SPD, and the information can be recorded in SPD by IKE which has been improved to solve the NAT problem.

VIII





 
致 谢

从一个懵懂的顽童,到今天能够略窥科学殿堂的门径,是许许多多 的老师、亲人、朋友给了我今天的荣幸。我想真心地感谢曾经教导过我 的各位尊敬的老师,他们以无私奉献的精神教导我;以一丝不苟的治学态 度影响我;以从不放弃的意志鼓励我,尤其我要感谢我的导师刘淑芬老 师,她的勤奋和学识的广博令我非常敬佩,而且她还把我当亲人一样处 处关心我,及时纠正我犯的错误。  我希望把这篇论文献给我敬爱的父亲、母亲、爷爷、奶奶、姑姑是 他们抚养我长大,教我做人。同时,我还要把这篇文章献给我的妻子, 在我求学期间,是她挑起了家庭的重担,还要照顾我的生活起居。  在这里我要特别感谢我的朋友们,付宁、李兵、李庆新、冯伟、方 英兰、陈志雨、韩冰,还有许多许多,是他们在我遇到困难挫折的时候, 主动伸出热情的双手,帮助我渡过一个又一个难关。   

IX


相关文章:
IPSec与NAT协同工作的研究
工作研究 作者:许杰星 来源:《现代电子技术》2008 年第 19 期 摘要:因特网网络层安全协议( IPSec)网络地址翻译 (NAT)不兼容,这严重限制了 IPSec 应用...
基于IPSec和NAT协同工作的UDP封装方案研究
然而 IPSecNAT 存在本质上兼容性,IPSec ...同时分析了它的一个改进方案,并找出其存在 不足...关键词:IP 安全协议 网络地址翻译 NAT 穿越 UDP ...
IPSec穿越NAT的原理
IPSec 穿越 NAT 的原理 IPSec 穿越 NAT 的应用已经很多,但是从协议层分析说明...的兼容性问题 IPSec 作为一种重要的安全技术得到越来越广泛的应用,但客户网络...
IPSec和NAT工作模式的冲突和解决办法
网络安全 IPsec(IP Security)和网络地址转换 NAT(...从 IP 角度来看,NAT 对 IP 低层进行了修改...然而,由于 IPsec 协议架构本身以及缺 乏支持 IPsec ...
IPSEC VPN配置与NAT兼容配置
VPN 1、IPSec 在 3 个方面保证了网络数据包的安全:机密性、完整性、认证性。...二/校验和与 NAT 传输模式,如果 IP 包中封装了上一层协议(传输层)是 TCP ...
IPv4 IPv6过渡安全研究
协议,而 基于 NAT-PT 转换机制的网络IPSec ...不兼容,因此,研究 IPSecNAT-PT 之间的不兼容...增强了协议的安全性,提供了更加可靠的传输层安全服务...
IPSec穿越NAT的原理 介绍IPSEC 技术中,封装的之后的包,...
IPSec 穿越 NAT 的应用已经很多,但是从协议层分析说明...IPSec 穿越 NAT 存在的兼容性问题 IPSec 作为一种重要的安全技术得到越来越广泛的应用,但客户网络边缘...
IPSEC VPN 的NAT穿越详解
IPSEC VPN 的 NAT 穿越详解 IPSEC VPN 的 NAT 穿越 IPSec 是基于网络层的,...设计 AH 认证协议的目的是用来增加 IP 数据报的安全性。AH 协议提供无连接的...
网络安全练习题(选择、填空)
A.防火墙 B.IDS C.Sniffer D.IPSec 8. 下列不...防火墙及 NAT 机制存在兼容性问题,导致安全隧道建 ...利用 IPSec 等阿络层安全协议和建立 在 PKI 上的...
浅析IPSec与NAT兼容性
:《科技探索》2012 年第 11 期 摘要:网络地址转换技术(NAT) 与 IP 安全协议(IPSec)两项技术在互联网领域被广泛应 用,在应用中他们二者又具有一定的不兼容。...
更多相关标签: