NAT域隧道模式IPsec安全模型

正文共:3333 字 7 图,预估阅读时间:3 分钟
RFC2709:Security Model with Tunnel-mode IPsec for NAT Domains,October 1999

本备忘录的状态

这份备忘录为互联网社区提供了信息。它没有指定任何类型的互联网标准。这份备忘录的分发是无限的。

版权声明

版权所有(C)互联网协会(1999)。保留所有权利。

摘要

如[参考文献1]所述,NAT有多种变体。在NAT支持的域中,只有特定领域的IP客户端能够进行端到端的IPsec安全会话。然而,所有类型的NAT都能够为与外部领域中的节点对等的私有域主机提供隧道模式IPsec安全。本文档描述了一种安全模型,通过该模型可以在NAT设备上构建隧道模式IPsec安全。有一节专门描述在快速模式下如何将安全策略透明地传达给IKE(用于自动KEY交换)。还概述了可以从所述安全模型中受益的应用程序。

1、引言和概述

NAT设备通过在路由过程中修改IP和传输报文头,为试图从不同地址域进行通信的终端主机提供透明的路由。当最终用户标识符(如主机名)与用于定位最终用户的地址不同时,此解决方案效果最佳。

可以为那些不在对最终用户毫无意义的有效载荷中嵌入特定领域信息的应用程序提供端到端的应用程序级有效载荷安全。在有效载荷中嵌入特定领域信息的应用程序将需要应用层网关(application level gateway,ALG)来使有效载荷在两个领域都有意义。然而,在途中需要ALG协助的应用程序无法追求端到端的应用程序级安全。

当NAT设备充当IPsec隧道端点时,所有穿越NAT设备的应用程序,无论是否需要ALG的帮助,都可以从IPsec隧道模式安全中受益。

下文第2节定义了本文件特有的术语。

第3节描述了如何在NAT设备上识别隧道模式IPsec安全。IPsec安全架构、各种类型安全机制的格式和操作可以在[参考文献2](IPsec:RFC2401-互联网协议的安全架构)、[参考文献3](ESP:RFC2406-IP Encapsulating Security Payload)和[参考文献4](AH:RFC2402-IP Authentication Header)中找到。本节不讨论如何在充当IPsec网关的NAT设备和外部对等节点之间交换会话密钥和策略。交换可以手动进行,也可以使用任何已知的自动交换技术进行。

第4节假设基于公钥的IKE协议[参考文献5]可用于自动交换安全策略、会话密钥和其他安全联盟(Security Association,SA)属性。本节描述了一种方法,通过该方法可以转换为私有域管理的安全策略,以便与外部节点通信。IKE协议操作的详细说明见[参考文献5](IKE:互联网密钥交换)和[参考文献6]。

第5节描述了文档中描述的安全模型的应用。列出的应用程序包括专用域主机的安全外部域连接和对企业移动主机的安全远程访问。

2、术语

本文档中使用的大多数术语的定义可以在以下文件之一中找到:(a)NAT术语和考虑因素文件[参考1],(b)IP安全架构文件[参考2](IPsec:RFC2401-互联网协议的安全架构),或(c)互联网密钥交换(Internet Key Exchange,IKE)文件[参考5](IKE:互联网密钥交换)。以下是专门为本文档定义的术语。

2.1、常规NAT
引入术语“常规NAT”是为了将常规NAT处理与用于嵌入IPsec安全隧道中的安全数据包的NAT处理区分开来。“常规NAT”是指[参考文献1]中描述的常规NAT处理。

2.2、IPsec策略控制NAT(IPC-NAT)
术语“受IPsec策略控制的NAT”(IPsec Policy Controlled NAT,简称IPC-NAT)被定义为描述作为IPsec转换的扩展应用于嵌入IP-IP隧道内的数据包的NAT转换,NAT节点是隧道端点。IPC-NAT功能本质上是NAT扩展对隧道模式IPsec的嵌入式数据包的适配。经过IPC-NAT处理的数据包是NAT设备和外部对等实体(无论是主机还是网关节点)之间IPsec安全的受益者。

IPsec策略对使用哪些NAT映射施加了限制。例如,对等网关的IPsec访问控制安全策略可能会将通信限制在某些地址和/或端口号。因此,当NAT执行转换时,它必须确保其执行的转换符合安全策略。

与普通NAT一样,IPC-NAT功能可以采用任何NAT类型,包括传统NAT、双向NAT和两次NAT。IPC-NAT设备将支持IPC-NAT和普通NAT功能。

3、IPC-NAT的安全模型

IP安全架构文档[参考2]描述了如何在全球唯一的地址域内实现IP网络级安全。讨论了传输和隧道模式安全。在本文档中,除非另有说明,否则我们将假设IPsec安全是指隧道模式IPsec安全。此安全架构的基本要素是(a)安全策略,确定允许哪些数据包进行安全处理,以及(b)安全联盟属性,标识安全处理的参数,包括要应用的IPsec协议、算法和会话密钥。

不支持网络地址转换的设备上的隧道模式IPsec安全操作可以在图1和图2中描述如下。

图1、对出方向数据包执行隧道模式IPsec操作。

图2、隧道模式IPsec对入方向数据包的操作

需要提供隧道模式IPsec安全性的NAT设备来管理基于私有领域寻址的安全策略。此外,安全策略确定IPsec隧道端点对等体。因此,根据IPsec节点与之对等的隧道端点,数据包可能需要经历不同类型的NAT转换。换句话说,IPC-NAT需要为每个配置的安全策略提供一组唯一的NAT映射。IPC-NAT将根据安全策略,对每个对等体进行不同的地址转换和IPsec处理。下图(图3和图4)说明了IPsec隧道与NAT结合的操作。IPC-NAT设备的操作可以与不支持NAT的IPsec网关的操作区分如下。

(1) IPC-NAT设备具有使用私有域寻址管理的安全策略。传统的IPsec网关将使用单个域(例如外部域)寻址来管理其安全策略。

(2) IPC-NAT设备安全模型的基本要素包括IPC-NAT地址映射(和其他NAT参数定义)以及安全策略和SA属性。传统IPsec网关的基本元素仅限于安全策略和SA属性。

图3、IPC-NAT设备上用于出方向报文的隧道模式IPsec

图4、IPC-NAT设备上用于入方向报文的隧道模式IPsec

传统的NAT是面向会话的,只允许转换出方向会话。所有其他类型的NAT都是双向的。任何和所有类型的NAT映射都可以与IPC-NAT设备上的安全策略和安全处理结合使用。为了在本文档中进行说明,我们将假设在双向NAT设备上采用隧道模式IPsec。

但是请注意,能够跨IPsec隧道提供安全性的NAT设备可以继续为不需要IPC-NAT的数据包支持普通NAT。普通NAT和IPC-NAT中的地址映射和其他NAT参数定义是不同的。图3确定了NAT设备如何区分需要通过普通NAT和IPC-NAT处理的出方向数据包。至于从外部领域入方向的数据包,图4概述了可能受IPC-NAT影响的数据包。所有其他数据包仅被普通NAT处理。

4、IKE协议在IPC-NAT设备上的操作

前一节中描述的IPC-NAT操作可以基于手动会话密钥交换或使用对等实体之间的自动密钥交换协议来实现。在本节中,我们将考虑在IPC-NAT设备上采用IETF推荐的互联网密钥交换(IKE)协议,以自动交换安全策略和SA参数。换句话说,我们将重点介绍IKE与NAT设备上的隧道模式IPsec的结合操作。为了提醒本节,除非另有说明,否则我们将NAT设备称为IPC-NAT设备。

IKE基于UDP协议,使用公钥加密在地址域内安全地交换会话密钥和其他属性。IKE在IP环境中的详细协议和操作可以在[参考文献3]和[参考文献4]中找到。从本质上讲,IKE有两个阶段。

在第一阶段,IKE对等体以主模式或野蛮模式运行,以相互验证并在它们之间建立安全通道。NAT设备有一个到外部领域的接口,与领域中的任何其他节点没有区别,可以与对等外部节点协商第一阶段。NAT设备可以采用与领域中的对等体通信和认证所需的任何有效身份类型和认证方法。NAT设备还可以与领域中的证书颁发机构(Certification Authority,CA)对接,以检索证书并执行签名验证。

在第二阶段,IKE对等体以快速模式运行,交换策略和IPsec安全建议,以协商和商定安全转换算法、策略、密钥、生命周期和其他安全属性。在此阶段,IKE进程必须与IPsec引擎通信,以(a)收集安全会话属性和其他参数,与对等IKE节点进行协商,并(b)通知协商期间(与对等方)商定的安全参数。

作为IPsec网关运行的IPC-NAT设备具有基于私有领域寻址管理的安全策略。需要ALG将策略从私有领域寻址转换为外部寻址,因为IKE进程需要将这些策略传达给外部领域中的对等体。注意,IKE数据包不受任何NAT处理。IKE-ALG只是根据为策略匹配定义的NAT映射转换IKE有效载荷的选定部分。下图说明了IKE-ALG进程如何与IPC-NAT接口,以获取安全策略和IPC-NAT映射,并生成IKE可以在快速模式下与外部领域中的对等体通信的安全策略。

快速模式下的策略作为IDci和IDcr有效载荷的组合与对等体交换。每个对等体交换的ID(策略)组合必须匹配,以便统一应用任一端的SA参数。如果不交换ID,则假设快速模式协商的SA参数适用于主模式假设的IP地址之间。

根据现有安全策略的性质(例如:一对节点之间的端到端会话与具有地址范围的会话),IKE-ALG可能需要请求NAT在会话协商的生命周期(以秒或千字节为单位)内设置地址绑定和/或传输绑定。如果ALG无法设置必要的地址绑定或传输绑定,IKE-ALG将无法转换安全策略,这将导致IKE不对受影响的策略进行第二阶段协商。

当协商完成并成功时,IKE将直接将协商的安全参数传递给IPC-NAT网关引擎,如下图所示。

图5、IKE-ALG使用NAT映射转换安全策略

5、IPC-NAT安全模型的应用

到目前为止描述的IPC-NAT操作模型说明了NAT设备如何用作IPsec隧道端点,以在外部领域提供安全的数据传输。本节将尝试说明这种模型的两个应用。

5.1、安全的外联网连接
IPC-NAT模型的直接应用是能够使用NAT设备提供与外部领域的清晰安全连接。特别是,位于私有领域边界的IPC-NAT设备可以与外部域的IPsec网关对等,以保护外联网连接。外联网是指对等网关节点之间穿过互联网的路径部分。

5.2、企业移动用户的安全远程访问
例如,企业中的节点移出企业,并尝试使用临时服务提供商分配的地址(转交地址)从远程站点连接到企业。在这种情况下,移动用户可以使用商定的用户ID和身份验证机制与公司IPC-NAT设备建立IPsec隧道会话。此外,用户可以配置企业DNS服务器,作为IKE第一阶段后身份验证的扩展。这将允许用户按名称访问企业资源。

然而,许多企业服务器和应用程序依赖于源IP地址进行身份验证,并拒绝访问非来自企业地址空间的数据包。在这些场景中,IPC-NAT具有为远程访问用户执行网络地址转换(Network Address Translation,NAT)的能力(与传统的IPsec网关不同),因此他们在外部领域的临时地址被转换为企业域地址,而数据包在私有领域内。IPC-NAT的风格将是传统的NAT(即,假设移动用户地址空间是私有领域,企业地址空间是外部领域),它可以是基本NAT(使用一组企业地址进行转换)或NAPT(使用单个企业地址进行翻译)。

所描述的安全远程访问应用程序适用于所有企业,无论企业是否使用IANA注册地址。

所描述的安全远程访问应用程序与移动IP的不同之处在于,移动节点(在本申请中描述)不保留家庭网络地址,而只是将转交地址用于通信目的。可以想象,IPC-NAT网关通过将移动节点的转交地址与其归属地址绑定,透明地向移动节点提供移动IP类型的连接。然而,提供到IPC-NAT网关的这种地址映射不在本文档的范围内。

6、安全注意事项

如果NAT和ALG不在受信任的边界内,这是一个主要的安全问题,因为ALG会监听最终用户的流量有效载荷。应用程序级有效载荷可以端到端加密,只要有效载荷不包含仅在一个领域有效的IP地址和/或传输标识符。除了领域特定IP之外,当前IPsec技术保证的端到端IP网络级安全无法通过NAT实现。本文档中描述的IPC-NAT模型概述了一种在外部领域内获得网络级安全的方法。

当NAT与ALG结合时,可以确保注入互联网的数据包在报文头或有效载荷中没有私有地址。不符合这些要求的应用程序可能会使用防火墙过滤器删除。因此,IPC NAT、ALG和防火墙共存以在专用网络边界提供安全保障的情况并不少见。

7、参考文献

[1] Srisuresh, P. and M. Holdrege, “IP Network Address Translator (NAT) Terminology and Considerations”, RFC 2663, August 1999.
[2] Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol”, RFC 2401, November 1998
[3] Kent, S. and R. Atkinson, “IP Encapsulating Security Payload (ESP)”, RFC 2406, November 1998
[4] Kent, S. and R. Atkinson, “IP Authentication Header”, RFC 2402, November 1998.
[5] Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE)”, RFC 2409, November 1998.
[6] Piper, D., “The Internet IP Security Domain of Interpretation for ISAKMP”, RFC 2407, November 1998.
[7] Carpenter, B., Crowcroft, J. and Y. Rekhter, “IPv4 Address Behavior Today”, RFC 2101, February 1997.
[8] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G. and E.Lear, “Address Allocation for Private Internets”, BCP 5, RFC 1918, February 1996.

完整版权声明

版权所有(C)互联网协会(1999)。保留所有权利。

本文件及其翻译可复制并提供给他人,对其进行评论或以其他方式解释或协助其实施的衍生作品可全部或部分制作、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权声明或对互联网协会或其他互联网组织的引用,除非是为了制定互联网标准而需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或者需要将其翻译成英语以外的语言。

上述授予的有限权限是永久性的,互联网协会或其继承人或受让人不会撤销。

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于使用本文件中的信息不会侵犯任何权利或对适销性或特定用途适用性的任何暗示保证。

致谢

RFC编辑器功能的资金目前由互联网协会提供。

声明:文中观点不代表本站立场。本文传送门:http://eyangzhen.com/422155.html

(0)
联系我们
联系我们
分享本页
返回顶部