RFC2401

组织:中国互动出版网(https://www.360docs.net/doc/c05421407.html,/)
RFC文档中文翻译计划(https://www.360docs.net/doc/c05421407.html,/compters/emook/aboutemook.htm)
E-mail:ouyang@https://www.360docs.net/doc/c05421407.html,
译者:尹欣 袁磊 陈代兵(theredfox xyin@https://www.360docs.net/doc/c05421407.html,)
译文发布时间:2001-4-3
版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。

Network Working Group S. Kent
Request for Comments: 2401 BBN Corp
Obsoletes: 1825 R. Atkinson
Category: Standards Track @Home Network
November 1998

RFC2401 IP层协议安全结构
(RFC2401 Security Architecture for the Internet Protocol)

本备忘录状态:
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.

版权声明

Copyright (C) The Internet Society (1998). All Rights Reserved.

目录:
1.介绍 4
1.1文档内容摘要 4
1.2阅读对象 4
1.3 相关文档 5
2设计目标 5
2.1目的/目标/需求/问题描述 5
2.2警告和假设 5
3.系统概况 6
3.1IPsec能做什么 6
3.2IPsec怎样工作 6
3.3IPsec实现方式 7
4.安全连接(SECURITY ASSOCIATION) 7
4.1定义和范围 7
4.2安全连接的功能性 8
4.3安全连接的组合 9
4.4安全连接数据库 10
4.4.1安全策略数据库(SPD) 10
4.4.2选择符 12
4.4.3安全连接数据库(SAD) 14
4.5 安全连接的基本组合 16
4.6 SA和密钥管理 18
4.6.1 手动技术 18
4.6.2 自动SA和密钥管理 18
4.6.3 定位一个安全网关 19
4.7 安全连接和多播 19
5.IP传输处理 20
5.1输出IP传输处理 20
5.1.1选择使用一个SA或者SA束 20
5.1.2隧道模式的头结构 20
5.2 输入IP传输处理 22
5.2.1 选择使用一个SA或者SA束 22
5.2.2 AH和ESP隧道的处理 23
6.ICMP处理(IPSEC相关内容) 23
6.1 PMTU/DF的处理 23
6.1.1 DF 位 23
6.1.2 Path MTU发现 (PMTU) 23
7.审查 25
8.在支持信息流安全的系统中的运用 25
8.1 安全连接与灵敏性数据的关系 26
8.2 灵敏度一致校验 26
8.3 SPD的附加MLS属性 26
9.性能问题 27
10.遵守的要求 27
11.安全考虑 27
12.与RFC1825的不同 28
附录A--词汇表 28
附录B PMTU/DF/分段问题的分析与讨论 29
B.1 DF 位 29
B.2 分段 30
B.3 Path MTU 发现 32
B.3.1 标识原始(originating)主机 33
B.3.2 PMTU的计

算 34
B.3.3 维护PMTU数据的粒度(granularity) 35
B.3.4 PMTU的每个套接口维护 36
B.3.5 通向传输层的PMTU数据的传输 36
B.3.6 PMTU数据的生命期 36
附录C 序列空间窗口代码(SEQUENCE SPACE WINDOW CODE)例子 36
APPENDIX D -- CATEGORIZATION OF ICMP MESSAGES 38
REFERENCES 38
DISCLAIMER 40
AUTHOR INFORMATION 40
版权说明 41

1.介绍
1.1文档内容摘要
本备忘录定义了IPsec适应系统的基本结构。这一结构的目的是为IP层传输提供多种安全服务。它包括IPv4和IPv6两种环境。本文档描述了这种系统的目的,它们的构成和它们如何彼此结合以及如何嵌入IP环境。本文档还描述了IPsec协议提供的安全服务以及如何在IP环境中使用这些服务。本文档不涉及IPsec结构的所有方面。后续文档将涉及额外的具有更多高级特性的的结构细节。例如,在NAT环境下IPsec的使用,对IP多播更完善的支持等等。本文将根据潜在的必须的功能讨论IPsec安全结构的基本构成。额外的RFCs(参看1.3节指向的文档)定义了下面四个方面的协议:
a.安全协议――头部认证(AH)和封装安全负载(ESP)
b.安全连接――它们是什么,如何工作,怎样管理,怎样联合
c.密钥管理――手动的,自动的(The Internet Key Exchange(IKE))
d.认证和加密算法

本文档不是因特网安全结构的综述。仅涉及IP层的安全,这种安全是通过加密和协议安全机制的组合来实现的。
1.2阅读对象
本文档的阅读对象包括IP安全技术的实现者和其他对获得这一系统背景知识感兴趣的读者,特别是这一技术的预期用户(最终用户或系统管理员)。附录提供了术语表以帮助阅读对象弥补背景/词汇中的不足。本文档假设读者熟悉IP层协议,相关网络技术,一般安全术语和概念。
1.3 相关文档
如上面所提及的,其他文档提供了一些IPsec组件以及他们相互关系的细节定义。它们包括在下面列出的RFCs中:
a."IP Security Document Roadmap"[TDG97]――该文档为本系统中使用到的加密和认证算法的描述提供了指南
b.安全协议――RFCs描述了头部认证(AH)[KA98a]和封装安全负载协议(ESP)[KA98b]
c.认证和加密算法――每一个算法都有一个独立的RFC
d.自动密钥管理――"The Internet Key Exchange (IKE)"[HC98],"Internet Security Association and Key Mangement Protocol (ISAKMP)"[MSST97],"The OAKLEY Key Determination Protocol"[Orm97],"The Internet IP Security Domain of Interpretation for ISAKMP"[Pip98]
2设计目标
2.1目的/目标/需求/问题描述
IPsec被设计成为能够为IPv4和IPv6提供可交互操作的高质量的基于加密的安全。安全服务集提供包括访问控制、无连接的完整性、数据源认证、抗重播(replay)保护(序列完整性(sequence integrity)的

一个组成部分)、保密性和有限传输流保密性在内的服务。这些服务是基于IP层的,提供对IP及其上层协议的保护。
这些目标是通过两大传输协议:头部认证(AH)、封装安全负载(ESP)和通过密钥管理过程和协议的使用来完成的。使用于任何环境中的IPsec协议集及其使用的方式是由用户、应用程序、和/或站点、组织对安全和系统的需求来决定。
当正确的实现、使用这些机制时,它们不应该对不使用这些安全机制保护传输的用户、主机和其他英特网部件产生负面的影响。这些机制也被设计成算法独立的。这一模块性允许选择不同的算法集而不影响其他部分的实现。例如:如果需要,不同的用户通讯可以采用不同的算法集。
定义一个缺省的标准集使全球英特网更容易交互。这些算法辅以IPsec传输保护和密钥管理协议的使用为系统和应用开发者采用基于IP层的高质量的加密的安全技术提供了途径。
2.2警告和假设
IPsec协议及相关缺省算法为英特网传输提供高质量的安全。但是,采用这些协议所提供的安全最终依赖于它们实现的质量,其外在表现为标准集的范围。此外,一个计算机系统或网络的安全是由许多因素决定的,它包括人、物、流程、有危险的散发(compromising emanations)以及计算机安全经验(practice)。因此IPsec仅仅只是综合性系统安全结构的一个组成部分。
最终,使用IPsec提供的安全很大程度上依赖于IPsec实现执行时操作所处操作环境中的诸多因素。例如,操作系统安全缺陷,较差质量的随机数源、不良的系统管理协议和经验等等都能降低使用IPsec所提供的安全。以上这些环境因素均不在这一或其他IPsec标准的讨论范围内。
3.系统概况
本节提供IPsec工作原理、系统构成以及如何组合提供上述安全服务的进一步说明。这一描述的目的是使读者对整个流程、系统有一个全貌,了解它是怎样适应IP环境的,为本文档的后续章节提供一个简述。在后续章节中将对每一个部分作更详细的描述。
IPsec实现工作于一个主机或一个安全网关的环境中,对IP传输提供保护。所提供的保护是基于:由用户或系统管理员建立和维护的安全策略数据库(SPD)所定义的需求;由用户或系统的管理员建立的具有约束性应用操作所定义的需求。通常,通过基于同数据库(SPD)入口相匹配的IP层和传输层头部信息的三种处理模式之一来选择包。 每一个包或被给予IPsec安全服务或被丢弃或被允许通过IPsec,这都基于选择符定义的相应数据库策略。
3.1IPsec能做什么
IPsec为IP层提供安全服务,它使系统能按需选择安全协议,决定服务所使用的算法及放置服务所需密钥到相应位

置。IPsec用来保护一条或多条主机与主机间、安全网关与安全网关间、安全网关与主机间的路径。(在IPsec 文档中,“安全网关”指的是执行IPsec协议的中间系统(intermediate system)。例如,路由器或实现了IPsec的防火墙,我们称之为“安全网关”)
IPsec能提供的安全服务包括访问控制、无连接的完整性、数据源认证、抗重播(replay)保护、保密性和有限传输流保密性在内的服务。因为这些服务均在IP层提供,所以任何高层协议均能使用它们。例如,TCP,UDP,ICMP,BGP等等。
IPsec DOI也支持IP压缩协商[SMPT98]。当在IPsec中使用加密而阻碍低层压缩的有效性时,IP压缩协商被激活。
3.2IPsec怎样工作
IPsec使用两个协议来提供传输安全――头部认证(AH)、封装安全负载(ESP)。这两个协议都在各自的RFCs[KA98a,KA98b]中有详细的描述。
* IP头部认证(AH) [KA98a]提供无连接的完整性验证、数据源认证、选择性抗重播服务。
* 封装安全负载(ESP) [KA98b]提供加密、有限传输流加密。它也提供无连接的完整性验证、数据源认证、抗重播服务。(无论ESP什么时间被调用,这些安全服务的某一集合必须被应用)
* AH和ESP均是基于密钥的分布和与这些安全协议相关的传输流管理,AH和ESP均可作为访问控制的媒介物
这些协议或者独立使用或者组合使用以提供IPv4和IPv6环境下所需的安全服务集。每一个协议支持两种使用模式:传输模式,隧道模式。在传输模式下,协议为高层提供基本的保护;在隧道模式下,协议使IP包通过隧道传输。两种模式的区别将在第4章节讨论。
IPsec允许用户(系统管理员)控制安全服务的粒度(granularity)。例如,用户可以在两个安全网关间创建单一加密隧道传输所有信息,也可以为每一通过这些网关通讯的主机对的每一个TCP连接创建一个独立的加密隧道。IPsec管理必须体现下列特性:
* 使用哪些安全服务及在哪种组合中被使用
* 指定安全保护应该使用的粒度
* 对基于加密的安全产生影响的算法
因为这些安全服务使用共享的安全值(密钥),IPsec依赖一组独立的机制来存放这些密钥。(这些密钥用作认证、完整性验证及加密服务。)本文档需要支持手动、自动两种分配方式。它为自动密钥管理定义了一个特殊的基于公共密钥的方法(IKE-[MSST97,Orm97,HC98]),但其他自动密钥分配技术也可以(MAY)使用。
3.3IPsec实现方式
在主机上或路由器、防火墙(创建安全网关)的连接处,IPsec可以有几种实现方式。下面提供几个几个通常的例子:
a. IPsec完全嵌入原有的IP层实现。这需要涉及IP源码和这对主机和网关要都是适用的。
b. “Bump-in-the-stack"(BITS)实现。IPsec实

现于原有IP协议栈的下部,处于原有的IP和网络设备驱动之间。在这种情况下并不需要涉及IP协议栈的源码,所以该实现方法适于遗留系统。这种方法多在主机上采用。
c. 采用外接加密处理设备是军方、金融系统常用的网络安全系统设计方案。它有时被称为“Bump-in-the-wire”(BITW)实现。这种设计方案设计来服务于主机或网关(或两者兼有)。通常这种BITW设备是可设定IP地址的。(be IP addressable)当只支持一个单独的主机时,它和BITS方案就十分相似。但作为支持一个路由器或防火墙时,它必须象个网关一样操作。
4.安全连接(Security Association)
这节定义了基于IPv4和IPv6环境下实现AH、ESP对安全连接管理的需求。安全连接的概念是IPsec的基础。AH和ESP都使用了SAs,IKE的主要功能是建立和维护安全连接。所有AH和ESP的实现都必须支持下面描述的安全连接的概念。本节余下部分描述了安全连接管理的各个方面,定义了SA策略管理、传输处理、SA管理技术所需的特性。
4.1定义和范围
安全连接(SA)是一个单向“连接”,它为通过它的传输提供安全服务。SA通过AH或ESP但不是两者同时使用而提供安全服务。如果AH和ESP同时用于传输流的保护,那么应该创建两个或多个SA为传输流提供保护。通常为了安全,两台主机间或两个安全网关间或两个安全连接间(每个方向一个)都需要双向通讯。
安全连接由三个部分内容唯一标识――安全参数索引(SPI),IP目的地址,安全协议(AH和ESP)标识符。原则上,目的地址可以是一个点播地址,IP广播地址,或多播组地址。然而,当前IPsec SA管理机制只为点播SAs作了定义。因此,在接下来的讨论中,SAs将只描述点到点通讯的内容,即使这一概念也可以适用点到多的情况。
如上所述我们定义了两种类型的SAs:传输模式,隧道模式。传输模式SA是两台主机间的安全连接。在IPv4环境中,传输模式安全协议头紧接在IP头和任何选项之后,在任何更高层协议之前(例如TCP或UDP)。在IPv6环境中,安全协议头出现在基本IP头和扩展之后,但也许出现在目的选项的前或后,并在更高层协议之前。在采用ESP时,传输模式SA仅为更高层协议安全服务提供,而不为IP头或任何ESP头以前的扩展头提供服务。在采用AH时,这种保护也被扩展到IP头的可选部分、扩展头的可选部分和可选项(包括IPv4头,IPv6 Hop-by-Hop扩展头,或IPv6目的扩展头)。为了解更多关于AH给予的有效区域,请参看AH规范[KA98a]。
隧道模式SA必然是运用于IP隧道的SA。只要安全连接的任意一端是安全网关,SA就必须是隧道模式。因此两个安全网关之间总是隧道模式,同样主机和安全网关

间也必然是隧道模式。注意在传输是指向安全网关的情况下,例如SNMP命令,安全网关是作为主机提供服务的,因而传输模式是被允许的。但在这种情况下,安全网关不再扮演网关的角色,例如它不再转发传输流。两个主机间也可以建立隧道模式SA。由于为了避免IPsec包分段、重组时出现的潜在问题以及这一环境中安全网关后同一目的地存在多重到达路径(例如通过不同的安全网关),对于任意(转发传输流)SA包括安全网关都应该可以支持隧道模式。
对于隧道模式SA,有外部(outer)IP头,内部(inner)IP头。外部IP头定义了IPsec处理的目的地,内部IP头定义了包最终地址。安全协议头出现在外部IP头后内部IP头前。如果在隧道模式中使用AH,外部IP头的部分将受到保护。同样所有隧道化(tunneled)IP包也受到保护(即所有内部IP头、更高层协议受到保护)。如果使用ESP,则仅对隧道化的包给予保护而不保护外部头。
总而言之:
1. 主机必须支持传输模式和隧道模式;
2. 安全网关仅需要支持隧道模式即可。如果它支持传输模式,仅当安全网关作为主机时使用,例如作为网络管理。
4.2安全连接的功能性
由SA提供的安全服务集依赖于安全协议的选择,SA模式,SA端点以及在协议范围内可选服务的选择。例如,AH提供数据源认证和IP数据报无连接的完整性验证(以后均称为认证)。准确的讲,认证服务是使用AH的安全连接粒度的功能。这将在4.4.2节讨论――选择符。
对于分离的接收者,AH提供抗重播(部分序列完整性)服务以防范拒绝服务的攻击。当不需要保密(或不允许,例如政府限制加密的使用)时,使用AH协议是适合的。AH也为IP头可选部分提供认证。这在某些情况下是有必要的。例如,如果在收发双方间,IPv4选项或IPv6扩展头的完整性必须被保护到路由时,AH能提供这种服务(除了IP头不可预料的,易变的部分)。
ESP可有选择的为传输提供保密。(保密服务的长度部分的依赖于所使用的加密算法。)ESP也可以有选择的提供认证服务(正如上面所定义的)。如果一个ESP SA认证经过协商,接受方也可以选择具有和AH抗重播服务一样特性的增强抗重播服务。由ESP提供的认证范围比AH所提供的要窄。例如,ESP头外部的IP头就不受保护。如果仅上层协议需要被认证,那么ESP认证是个合适的选择并且它具有比使用AH封装ESP时更高的空间效率。要注意的是尽管保密和认证均是可选的,但是他们不能都被省略。它们中至少有一个必须被选择。
如果选择保密服务,则两个安全网关间的ESP(隧道模式) SA能提供局部传输流保密。隧道模式的使用允许内部IP头倍加密

,隐藏(最终的)传输源和目的的标识。而且,也可能调用ESP负载填充(ESP payload padding)隐藏包的尺寸,甚至隐藏传输的外部特性。在拨号环境下,当一个移动用户被指定一个动态IP地址并对一个联合防火墙(corporate firewall )建立一个(隧道模式)ESP SA时,也可以提供类似的传输流保密服务。值得注意的是粒度(granularity)较精巧的SAs通常比那些来自很多用户传输流粒度较粗糙的SAs更容易受到传输分析。
4.3安全连接的组合
穿过独立SA的IP数据报通过严密的安全协议(AH或ESP)受到保护。对于特殊的传输流,而仅采用单一的SA时不能实现的。在这种情况下,使用多重SAs以实现安全策略是必要的。术语“安全连接束”或“SA束”定义为一个SAs序列(sequence),传输必须通过它来满足一个安全策略。策略定义了序列的顺序。(值得注意的是由束组成的SAs可能终止于不同的端点。例如,一个SA可以在移动主机、网关和另一个网关之间延展,嵌套的SA可以延展到网关后的主机。)
安全连接可以通过两种方式组合成束:传输邻接(transport adjacency)和隧道迭代(iterated tunneling )。

* 传输邻接指的是对同一个IP报文使用多于一个安全协议,而不采用隧道方式。这种联合AH和ESP的方法只允许一级联合;更多的嵌套并不能增加效益(假设每一个协议中使用了足够强壮的算法),因为这一过程仅被执行于IPsec最终目的地的IP实例处。
主机 1------------安全网关 1-------------Internet-----------安全网关 2------------主机 2
| | | |
| | | |
| --------------------------------安全连接 1(ESP传输)------------------------------- |
--------------------------------------安全连接 2(AH 传输)-------------------------------------

* 隧道迭代指的是一种对安全协议的多层次应用,这一安全协议是通过IP隧道实现的。这种方法允许多重叠代,这是因为每一个隧道可能沿着一路径在不同的IPsec站点(IPsec site)开始、结束。除了那些能通过合适的SPD入口被定义的以外,在中间安全网关处对于ISAKMP传输不希望采用特殊的处理。(参看4.5节的例3)
有三种基本的隧道迭代情况――仅情况2,3需要支持:


1. 对于SAs两个端点都是同样的――内部隧道和外部隧道采用AH或ESP,但主机1几乎是不可能把两个指定成一样的。即AH的内部不可能是AH,ESP的内部不可能是ESP。
主机 1------------安全网关 1-------------Internet-----------安全网关 2------------主机 2
| | | |
| | | |
| --------------------------------安全连接 1(隧道)------------------------------------- |
--------------------------------------安全连接 2(隧道)----------------------------------------

--
2. 对于SAs一个端点是一样的――内部隧道和外部隧道采用AH或ESP。
主机 1------------安全网关 1-------------Internet-----------安全网关 2------------主机 2
| | | |
| | | |
| ------------------------安全连接 1(隧道)-------------------------- |
--------------------------------------安全连接 2(隧道)------------------------------------------
3. 任意一个端点都不同――内部隧道和外部隧道采用AH或ESP。
主机 1------------安全网关 1-------------Internet-----------安全网关 2------------主机 2
| | | |
| | | |
| ------------ ----安全连接 1(隧道)---------------- |
--------------------------------------安全连接 2(隧道)------------------------------------------
这两种方式也可以被组合。例如,一个SA束能由一个隧道模式SA和一个或两个传输模式SAs构成应用于序列。(参看4.5节“安全连接的基本组合”。)值得注意的是嵌套的隧道也能发生在任何隧道源或目的端点都不相同的地方。在这种情况下,没有与嵌套隧道相关的带有束的主机或网关存在。
对于传输模式SAs,只有一个安全协议序是合适的。AH应用于更高层协议和IP头。因此在和ESP联合使用时,如果AH使用传输模式AH应该在IP后作为第一个头出现,并应在ESP出现之前。在这种情况下,AH被使用于ESP的输出的密文。相对应的,对于隧道模式的SAs,人们可以使用多个AH和ESP次序。所需要的SA束类型集将在4.5节中描述,这些类型必须被一个适当的IPsec实现所支持。
4.4安全连接数据库
在一个IPsec实现中,和IP传输处理相关的大量细节是一个本地化的问题,它并不受标准的约束。然而,一些处理的外部特性(external aspects)必须标准化以保证相互可操作性,以提供一个最基本的管理能力,这对于IPsec产品化使用时非常必要。这一节描述了和安全连接相关的IP传输处理的通常模式,以达到相互可操作性和功能性的目标。下面所描述的模式仅作参考,适合的实现并不需要在细节上和这一仅作示例的模式相一致,但这一实现的外部特性必须和这一模式外部的显著特征能构成一种映射。
这一模型中有两个数据库:安全策略数据库和安全连接数据库。前者定义了一个决定从主机、安全网关、BITS或BITW IPsec实现输入、输出IP传输的部署。后者包括和每一个安全连接相关的参数。这一节也定义了选择符、IP集和高层协议域值的概念。该值被策略数据库用来把传输映射到一个策略,即SA(或SA束)。
每一个被激活IPsec的接口需要内部和外部数据库(SAD和SPD)表面上的分离,这是因为大量作为选择使用的域具有有向性。典型的,对于主机或安全网关(SG)就

有一个这样的接口。注意安全网关中有至少两个接口,但面对合作网(corporate net)的“内部”接口通常没有被激活的IPsec,因此它仅需要一对SADs和一对SPDs。另一方面,如果一台主机有多个接口或一个安全网关有多个外部接口,那么每一个接口有独立的SAD和SPD对也许是有必要的。
4.4.1安全策略数据库(SPD)
根本上,安全连接是一个用来在IPsec环境中增加安全策略的管理结构。因此SA处理必不可少的元素是一个下层的安全策略数据库,它定义哪些服务将被提供给IP数据报,用什么方式把哪些服务提供给IP数据报。数据库和其接口的形式超出了这一规范的讨论范围。然而,这一节定义了一个必须被提供的最小管理功能,它允许用户或系统管理员控制IPsec如何应用于主机或一个安全网关收发传输。
在所有传输(输入和输出)包括非IPsec传输的处理过程中,SPD必须被考虑。为了支持这,对于输入、输出传输SPD需要不同的入口。我们可以把这看成彼此独立的SPDs(输入和输出)。另外,对于每一个被激活IPsec接口,必须提供一个表面上独立的SPD。
SPD必须区分受IPsec保护的传输和允许通过IPsec的传输。这运用于由发送者使用的IPsec保护和必须有接收者参与的IPsec保护。对于任何输出或输入的数据报有三种可能的选择:丢弃、穿过IPsec或使用IPsec。第一种选择是指根本不允许退出主机、穿过安全网关,或最终传递到某一应用程序。第二种选择指的是允许通过而不用额外IPsec保护的传输。第三种选择指的是需要IPsec保护的传输并且对于这样的传输SPD必须规定提供的安全服务,所使用的协议、算法等等。
对于每一个IPsec实现,必须由一个可供管理的接口。它允许用户或系统管理员管理SPD。特别的,每一个输入或输出包受制于IPsec的处理,SPD必须定义在每一种情况下什么行为将被接受。因此可供管理的接口必须允许用户(或系统管理者)定义安全处理,这一安全处理被运用于任何进出系统的包,基于包基的包。(在一个利用套接口的主机中IPsec实现里,SPD也许不必要在每一个包基(packet basis)上考虑,但效果是同样的。)对SPD的管理接口必须允许创建和4.4.2节定义的选择符相一致的入口,并且必须支持这些入口的顺序(ordering)匹配。通过各种选择符中通配符的使用,又由于一个基于单一UDP或TCP连接的所有包趋于匹配一个单一的SPD入口,可以减少对SPD规范过分细节化的需求。选择符和在无状态防火墙或过滤路由器中能发现的以及用当前方式可管理的相类似。
在主机系统中,应用程序可以为其产生和使用传输选择安全处理方法。(对于IPsec实现,提出(signalling)需求的方

法超出了本标准的范围)然而,系统管理员必须能够规定用户或应用程序是否可以覆盖(缺省)系统策略。值得注意的是应用程序定义的策略可以满足系统需求以至于系统不必作额外的超出系统需要的IPsec处理,但要满足应用程序需要。本文档不定义管理接口的形式。对于主机与安全网关管理接口形式可以不同,对于主机接口也有基于socket的也有BITS实现的。但本文档定义了一个所有IPsec实现必须支持的SPD元素集标准。
SPD包括策略入口的有序列表。每一个策略入口由一个或多个选择符标识,这些选择符定义了被这一策略入口包含的IP传输。(所需选择符类型在4.4.2节定义)这些选择符定义了策略或IPsec处理的粒度。每一个入口包括一个标识,它标识匹配这一策略的传输是允许通过,丢弃,还是进行IPsec处理。如果运用IPsec处理,入口应包括SA(或SA束)的规范。该规范列举了IPsec协议、模式和使用的算法,包括了任何嵌套需求。例如,入口需要对所匹配的传输进行保护,在传输模式时,ESP使用3DES-CBC(3DES-CBC with an explicit IV),在隧道模式时,AH内嵌套的ESP使用HMAC/SHA-1。对于每一个选择符,策略入口规定怎样为新的安全连接数据库(SAD,参看4.4.3节)从SPD和包中得到相应的值(注意现在对于IP地址仅支持值域;对于所用选择符可以使用通配符表达):
a.使用包自有的值――这将限制SA使用到一些包。这些包对此选择符有这个包的值,即使对于此策略入口选择符有一个允许值范围或有一个通配符。
b.使用和策略入口相关的值――如果仅是个单值,则(a)和(b)没什么区别。但是,选择符取值允许是域值或统配符时,在是域值的情况下,(b)能使SA使用于在范围内任何带有选择符值的包,而不仅仅是用于带有可以触发SA创建选择符值的包。在通配符的情况下,(b)允许SA使用于带有任何此选择符值的包。
例如,假设有一个SPD入口允许源地址是主机地址范围内的任意值(192.168.2.1到192.168.2.10)。并假设待送包源地址为192.168.2.3。根据此选择符策略入口描述的是选择符值的源,对于SA下列任何值可以使用。
Source for the value to be used in the SA example of new SAD selector value
------------------------------------------------- --------------------------------------------
a. packet 192.168.2.3 (one host)
b. SPD entery 192.168.2.1 to 192.168.2.10(range of hosts)
注意如果对于源地址SPD入口有一个允许的通配符值,SAD选择符值可能是通配符(任何主机)。情况(a)能使用于禁止共享,甚至在和同一个SPD入口相匹配的包之间。
正如下面4.4.3节所描述的,选择符可以包括“通配符”入口,因此对于两个入口的选择

符可能重复。(这和ACLs之间、路由器过滤入口之间、包过滤防火墙出现的重复相类似。)因此为了确保SPD入口的一致性、处理的可推断性,SPD入口必须有序,必须总以相同顺序查找以便一致的选择首次匹配入口。(此需求是是必要的,因为通过SPD入口的传输处理结果必须唯一确定,但如果对于某些选择符使用通配符则无法规定SPD的入口。)关于对于SPD入口包匹配的更多细节将在第5节提供。
注意如果ESP被规定,认证与加密必须也只能取其一。因此必须能对初值为NULL的认证或加密算法设置SPD值。但是这些服务中必须有至少一个被选择,即不能把它们都配置成空值。
SPD能把传输映射到特殊的SAs或SA束。因此它既能作为安全策略的参考数据库又能作为以存在SAs(或SA束)的映射。(为容纳上述通过、丢弃的策略,SPD也必须提供一个能把传输映射到这些功能上的方法,即使(per se)没有IPsec处理。)SPD操作的方式对于输入、输出传输是不同的,对于主机、安全网关、BITS和BITW实现也是不同的。5.1和5.2节分别描述SPD在输入、输出处理的使用。
由于安全策略也许需要多余一个SA应用于一个特定序列集合的传输,SPD的策略入口必须保护这些当前的有序需求。因此对于一个确定的IPsec实现必须有可能使输入、输出包通过SAs序列进行处理。从概念上讲,对于输出处理,可以想象成来自于一个有活动SAs的SPD入口链(到SAD),并且每一个入口由单一SA或由一构成SA束的有序SAs列表组成。当某一包匹配于某一SPD入口,并且一个已存在SA或SA束能用于此传输时,此包的处理就被列表中的SA或SA束入口所控制。对于一个采用多重IPsec SAs输入的IPsec包,基于目的地址、IPsec协议和SPI的查找应定义成一个单一SA。
SPD用以控制所有通过IPsec系统的传输流,包括来自/到安全网关后入口的安全和密钥管理传输(例如,ISAKMP)。这意味着ISAKMP传输必须在SPD中有明确的解释,否则它将被丢弃。注意安全网关能以多种方式禁止加密报文通过,例如,对于ESP包在SPD中有DISCARD入口,或提供代理密钥交换。后一种选择中,传输在安全网关内部路由到密钥管理模块。
4.4.2选择符
SA(或SA束)或许是详细的或许是粗略的,这有赖于选择符所定义的SA的传输集。例如,两主机之间所有的传输可以通过单一SA来传输,并且给予一个统一的安全服务集。另外,一对主机间的传输可以通过多重SAs,而不同的SAs提供不同的安全服务,这有赖于使用的应用程序(正如下一代协议和端口域中定义)。同样,一对安全网关之间的所有传输能基于单一SA,或为每一个通讯主机对指派一个SA。为了SA管理有利于SA粒度的

控制,必须支持接下来的选择符参数。注意在带有ESP头的包接收情况下,例如一个封装的安全网关或BITW实现处,传输层协议、源/目的端口和名字(如果有)可能是“OPAQUE”,即因为加密或分片而不可达的。还要注意源和目的地址应该既可以是IPv4的也可以是IPv6的。
* 目的IP地址(IPv4或IPv6):这或许是单一IP地址(点播的,多播,广播或多重组播),或许是一个地址范围(包含的高或低值),地址加掩码或一个通配符地址。最后三种被用来支持共享同一个SA的多目的地系统。(例如,一个安全网关后)。注意这一选择符同用以唯一表示一个SA的元组中的“目的地IP地址”域有概念上的不同。当一个隧道化的包到达了隧道的终点时,它的SPI/Destination address/Protocoal常常用来在SAD中寻找此包的SA。这一目的地址来自于封装的IP头。一旦包通过隧道模式的SA处理和传出隧道后,将在输入SPD中查找它的选择符。输入SPD有一个称之为目的地址的选择符。这一IP目的地址是内部(封装后的)IP头中的一个。在传输包的情况,只有一个IP头并且是明确的。[所有的实现均需要]
* 源IP地址(IPv4或IPv6):这或许是一个单一IP地址(点播的,多播,广播或多重组播),或许是一个地址范围(包含的高或低值),地址加掩码或一个通配符地址。最后三种被用来支持共享同一个SA的多源地地址的系统。(例如一个安全网关后或一个多宿主主机中)。[所有的实现均需要]
* 名称:有两个情况(注意这些名称格式在IPSec DOI支持。)
1. 用户ID
a. 一个有完全权限的用户名称串(DNS),例如,mozart@https://www.360docs.net/doc/c05421407.html,
b. X.500 著名的名称,例如,C = US,SP = MA,O = GTE网际互连,CN = Stephen T.Kent
2. 系统名称(主机,安全网关,)
a. 一个有完全权限的DNS名称,例如,https://www.360docs.net/doc/c05421407.html,
b. X.500 著名的名称
c. X.500 一般的名称
注意:此选择符的一个可能取值是“OPAQUE”(不透明)。
[以下实例的需要,注意手动密钥的SAs不需要名称格式的支持而非地址。
* 用户ID
—本地主机实现
—仅有一个用户,BITW和BITS作为主机实现
—对于输入处理的安全网关实现
* 系统名称—所有实现]
* 数据灵敏级:(IPSO/CIPSO 标记)
[对于所有如在8节描述的提供信息流安全的系统需要,对于所有其他系统可选]
* 传输层协议:从IPv4“协议”或者IPv6“Next Header”域得到。这可以是一个单个协议数。这些包域可以不包含传输协议,因为IP扩展头的存在,例如,一个路由器头,AH,ESP,分片头,目的选项,跳连跳选项。注意在一个具有ESP头的包的接收实例中可以不提供传输协议,

因此“OPAQUE”的一个值应该得到支持。
[所有实现都需要]
注意:为了探明传输协议,一个系统必须检查报头的“协议”或者“下个头”域,直到遇到它认为是一个传输协议,或者遇到不在其扩展头列表中的报头,或者遇到一个表示传输协议不透明的ESP头。

* 源端口和目的端口(如TCP/IP):这些可能是个别的UDP/TCP端口或者通配端口。(下个协议域和源/目的端口域(在和源/目的地址域的连接中),作为一个SA选择符有时当作“面向会话的加密”)。注意在一个具有ESP头的包的接收实例中可以不提供源端口和目的端口,因为“OPAQUE”的一个值应该得到支持。
下面的表总结了包和SPD中“Next Header”的值与SPD和SAD的源端口选择符值的关系。

包的下个头 SPD的传输层协议 SPD和SAD的源端口选择符值
--------------- ------------------------ -----------------------------------------
ESP ESP或者任何 任何(例如,不顾它)
不管 任何 任何(例如,不顾它)
特定值 特定值 不是任何(例如,丢弃包)
分片
特定值 特定值 实际端口选择符
不分片。
如果包分段了,端口信息就不能在当前分段中获得。若这样就丢弃这个分段。首分段应该发送ICMP PMTU,这个分段含有端口信息。[可以被支持]
IPsec实现信息内容决定怎样使用选择符。例如,集成到栈中的主机实现可以利用套接口。当新的连接建立时,SPD可能协商并且把SA(或SA束)绑定到套接口。所以通过那个套接口发送的传输不必导致对SPD/SAD额外的查询。相反,BITS,BITW或安全网关实现需要查看每个套接口,完成基于选择符的SPD/SAD查询。在传输流、安全连接和安全策略之间选择符域的允许值是不同的。
下面的表总结了在SPD和SAD中需要表示的入口的类型。它显示了这些入口怎样同数据传输中属于IPsec屏蔽的域关联起来。(注释:源和目的地址的“wild”和“wildcard”入口包含掩码,范围等。
域 通信值 SAD 入口 SPD 入口
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
dst addr single IP addr single,range,wild single,range,wildcard
xpt protocol* xpt protocol single,wildcard single,wildcard
src port* single src port single,wildcard single,wildcard
dst port* single dst port single,wildcard single,wildcard
user id* single user id single,wildcard single,wildcard
sec. labels single value single,wildcard single,wildcard

* 这些域的SAD和SPD入口可能是“不透明的”的,因为传输值是加密的。
注意:原则

上,一个能够在SPD中有选择符和选择符值的入口不能对SA或SA束绑定协商。
例子包含了选择符值,这些选择符用来选择丢弃的传输或枚举列表,这个列表引起为列表中的项(item)创建独立的SA项。现在,这个为本文档的未来版本留下,对SPD和SAD来说,需要的选择符列表和选择符值是相同的。但是,如果可以不误导用户相信管理接口正在创建带有这些选择符值的SA,有一个“支持”使用不能协商的选择符值的管理接口是可以接受的。例如,接口可以规定一个枚举列表的值,但将引起为列表中入口创建独立策略和SA。厂家可以支持这样的接口,该接口让它的用户制定清晰简明的策略规范更加容易。
4.4.3安全连接数据库(SAD)
每个IPsec实现都有一个名义上的安全连接数据库,在数据库里,每个入口定义了一个SA联合的参数。每个SA在SAD中有一个入口。对于输出处理,SAD入口被SPD中的入口指定。注意,如果当前SPD入口不指向对包合适的SA,实现就创建一个适当的SA(或SA束)并把SPD入口链接到SAD入口(参看5.1.1节)。对输入处理,SAD中的每个入口由目的IP地址,Ipsec协议类型和SPI索引。下面的参数与SAD中的每个入口相关联。这个描述并不意味是MIB库,只是作为一个用来支持在IPsec实现中的SA所需的最小数据入口的规范。
对于输入处理:下面的报文域用来查找SAD中的SA:
* 外部头的目的IP地址:IPv4或IPv6的目的地址。
[所有实现需要]
* IPsec协议:AH或ESP,在数据库中用做SA查询的索引。制定用在这个SA之上的传输的IPsec协议。
[所有实现需要]
* SPI:32位值,用于区分不同的SA,这些SA在相同的目的地结束并使用相同的IPsec协议。
[所有实现需要]
对于在4.4.2节中定义的每个选择符,SAD中的SA入口必须包含一个或多个在创建SA时协商的值。对于发送者,这些值用于决定给定的SA对于输出报文是否适当,这是检查是否一个可以使用的存在的SA的一部分。对于接收者,这些值用于核对输入报文的选择符值与SA的那些值是否的匹配(也间接检查了匹配策略的那些值是否与之匹配)。对于接收者,这是证实SA适合于这个报文的一部分。(参看6节的ICMP消息策略),这些域可能有一个特殊值、范围、通配符,或在4.4.2节描述的"OPAQUE","Selectors"。注意对一个ESP SA,加密算法或认证算法可能是空的,但不能都为空。
下面SAD域用于IPsec处理:
* 序列号计数器(Sequence Number Counter):用于产生在AH或ESP头中Sequence number域的32位值 。
[所有实现需要,但只用在输出传输里。]
* 序列号计数器溢出(Sequence Counter Overflow):表明序列号计数器溢出是否应该产生审查事件并且阻止SA

上额外包的传输的标志。
[所有实现需要,但只用在输出传输里。]
* 抗重播窗口(Anti-Replay Window):用于决定输入AH或ESP报文是否是重播的32位计数器和位示图(或等效物)。
[所有实现需要,但只用在输入通信里。注意:如果抗重播已经被接收者禁止,例如手动密钥SA的情况下,那么就不用抗重播窗口。]
* AH认证算法、关键字(AH Authentication algorithm,keys)等。
[所有AH实现需要]
* ESP加密算法、关键字、IV模式IV(ESP Encription algorithm,keys,IV mode,IV)等。
[所有ESP实现需要]
* ESP认证算法、关键字(ESP Authentication algorithm,keys)等。若未选认证服务,这个域就为空。[ESP实现需要]
* 安全连接的生命期(Lifetime of this Security Association): 时间间隔,在这段时间间隔之后,SA必须被新的SA(和新SPI)替换或者终止,并加上这个动作发生的标志。这可以作为时间或字节计数表示,或同时做两个用途,第一个生命期呼出优先(expire to taking precedence)。一个合适的实现必须既支持生命期的类型,又支持两种类型同时起作用。如果时间被占用,和如果IKE占用了SA建立的X.509认证,那么SA生命周期必定被认证的有效间隔和用于SA的IKE交换的CRL的NextIssueDate所限制。创始者和反应器都应该对这个时样中限制的生命期负责。
[所有实现需要]
注意:当SA到期(expire)是本地事件时,这个细节是怎么处理关键字刷新的细节。但是,合理的方法是:
(a)如果用字节计数,实现就应该计算IPsec算法应用的字节数。对于ESP,这是一个加密算法(包括空加密),对于AH,这是一个认证算法。这包括填补(pad)字节等。注意实现应该能让SA末端的计数器去掉同步(synch),例如,因为包丢失或者因为在每个SA末端的实现没有用同样的方法。
(b)应该有两种类型的生命周期-软生命周期,用来警告实现的初始化动作如设置SA替代,和在当前SA结束时的硬生命周期。
(c)如果到期报文不能得到传输,在SAs的存活时间内,则该包应该被丢弃。
* IPSec协议模式:隧道,传输或者通配符。表示AH或者ESP的哪种模式适合在此SA上的传输。注意如果SA发送端该域是通配符,那么应用程序必须为IPSec实现指定模式。通配符的使用允许,在每一个包的基础上,为隧道模式或者传输模式的传输使用相同的SA,例如不同的sockets。接收者不需要为了正确处理该包的IPSec头而知道模式。
[需要:如下,除非上下文直接定义:
—-主机实现必须支持所有模式
——网关实现必须支持隧道模式]
注意:输入SA协议模式中通配符的使用增加了接收端(仅限主机)形势的复杂度。因为这样SA上的包既可以以隧道模式传

递,也可以以传输模式传递,输入包的安全性可能一定程度上依赖于采用的传递模式。因此,如果应用程序关心给定包的SA模式,那么它需要一种机制来获取此模式信息。
* Path MTU:任何观察到的Path MTU和计时变量。可参见6.1.2.4节
[所有实现均需要,但是仅用于输出传输。]
4.5 安全连接的基本组合
本节讲述了安全连接组合的四个实例,它们必须由顺应的IPSec主机或者安全网关支持。是否支持隧道模式/传输模式与AH/ESP相互结合的多种组合由实现者斟酌决定。顺应的实现必须有能力生成这四个结合并在接收时可以处理它们,而且应该能够接收并处理任何组合。下面的数据报和报文体描述了其基本实例。有关数据报的想法是:
===== = 一个或者多个安全连接(AH或者ESP,传输模式或者隧道模式)
===== = 连通性(或者如果已经标记,管理的界限)
Hx = 主机x
SGx = 安全网关x
X* = X支持IPSec
注意:下面的安全连接可以是AH,或者ESP。模式(隧道模式或者传输模式)由终点性质决定。对于主机到主机的SAs,模式既可以是传输模式,也可以是隧道模式。
例1. 此例通过Internet或者Intranet在两个主机之间提供点到点安全。
===========================================
| |
H1*------------------(Internet/Intranet)------------------------*H2
注意:传输模式或者隧道模式可以由主机选择。因此H1和H2之间的报文头可以看作以下任一种:
传输模式 隧道模式
------------------------------ ------------------------------------
1.[IP1] [AH] [upper] 4.[IP2] [AH] [IP1][upper]
2.[IP1] [ESP] [upper] 5.[IP2] [ESP] [IP1] [upper]
3.[IP1] [AH] [ESP] [upper]
注意这里没有要求支持一般的嵌套,但是在传输模式下,AH和ESP都能用于该包。在此例中,SA的建立过程必须保证先将ESP运用于该包,再运用AH。
例2. 此例描述了简单虚拟专用网的支持。


==========================
----------------------|----- ---|------------------------
| H1-(本地-SGI* | ---------(Internet)--------- | SG2*--(本地--H2 |
| Intranet) | | Intranet) |
--------------------------- ----------------------------
管理界限 管理界限
这里只需要隧道模式。所以SG1和SG2之间的包的头可以看作下面两种中的一种:
隧道模式
----------------------------------------
4.[IP2] [AH] [IP1] [upper]
5.[IP2] [ESP] [IP1] [upper]
例3.此例结合例1和例2,在发送主机和接收主机之间增加了端

到端安全。它对主机或者安全网关没有新的要求,除了要求安全网关的配置允许传向其后主机的IPSec传输通过(包括ISAKMP传输)。
=================================================
| |
| |
| ========================== |
---|------------------|------ ---|-------------------|---------
| H1*-(本地-SGI*|---------(Internet)--------- | SG2*--(本地--H2* |
| Intranet) | | Intranet) |
--------------------------- --------------------------------
管理界限 管理界限
例4.此例包含了这种情况:远程主机(H1)通过Internet到达一个组织的防火墙(G2),并得到权限访问某个服务器或者其它机器(H2)。远程主机可以是移动主机(H1),它通过拨号在Internet上连接到本地PPP/ARA服务器(未显示),它可以通过Internet到达组织的防火墙。此例细节在4.6.3节“定位一个安全网关”中讨论。(H1如何定位SG2,认证它,并确定其认证可以代表H2)
==================================================
| |
| |
|=======================================| |
---|-|------ ----------------------|-----------------|
H1*--------------------(Internet)---------------------- | SG2*--(本地--H2* |
^ | Intranet) |
| ---------------------------
可以拨号连接到PPP/ARA服务器 管理界限
H1和SG2之间只需要隧道模式。所以,H1和SG2之间的SA的选择是例2的事。H1和H2之间的SA的选择是例1的事。
注意此例中,发送方必须在隧道头之前运用传输头。因此,IPSec实现的管理接口必须支持SPD和SAD的配置,以保证IPSec头的运用顺序。
正如上面提到的,对AH和ESP组合的支持是可选的。其他使用,可选组合会反过来影响协同工作的能力。
4.6 SA和密钥管理
IPSec命令既支持手动SA和自动SA也支持加密密钥管理。尽管其中的技术会影响这些协议提供的某些安全服务,但是 AH和ESP,以及IPSec协议依然在很大程度上独立于联合SA管理技术。例如,为AH和ESP提供的可选的抗重播服务需要自动SA管理。而且,IPSec使用的密钥分配的粒度决定所提供的认证的粒度。(相关内容参见4.7节)一般地,AH和ESP中的数据源认证受限于多个可能源共享的认证算法(或者生成机密的密钥管理协议)的秘密范围。
以下内容讲述两种SA管理的最小要

求。
4.6.1 手动技术
手动管理是最简单的管理方式。个人可以使用键入数据和与安全通信有关的安全连接管理数据,来手动的配置每一个系统。手动技术适用于较小的静态的环境下,但是扩展性不好。例如,一个公司可能在几个站点的安全网关使用IPSec建立一个虚拟专用网。如果站点数目少,因为所有站点都在一个单一的管理域,为手动管理技术提供一个可行的上下文环境。此例中,在使用一个手动配置密钥的组织中,安全网关可以有选择地保护来自和发向其他站点的传输,而不会保护其他目的地的传输。当只有选中的通信需要安全传输时,此法也是合适的。IPSec的使用完全限制在一个只有少量主机或者网关的组织中时,相同的观点也适用。尽管存在其他方法,手动管理技术经常使用静态配置的对称的密钥。
4.6.2 自动SA和密钥管理
IPSec的广泛传播和使用要求一个Internet标准的,可升级的自动SA管理协议。这样的支持为面向用户和面向会议的加密,可以使AH和ESP抗重播特性的使用更容易,可以供应SAs的随选生成。(注意对SA“二次加密”的概念实际上意味着用一个新的SPI生成一个新的SA,通常意味着一个自动SA/密钥管理协议的使用的过程。)
IPSec使用的缺省自动密钥管理协议是IPSec域解释的 [Pip98]的IKE协议[MSST97,Orm97,HC98]。其他自动SA管理协议也可以使用。
当使用一个自动SA/密钥管理协议时,对于一个单一ESP SA,此协议的输出可用来生成多个密钥。出现这种情况因为:
* 加密算法使用多个密钥(例如,三层的DES)
* 认证算法使用多个密钥
* 加密算法和认证算法都被使用
密钥管理系统为每一个密钥提供了一个独立的比特串,或者生成一个比特串,所有密钥都从其中取出。如果提供一个单一比特串,则需要保证:将比特串映射到密钥的系统部分在SA两端以相同方式工作。为了保证IPSec实现在SA的每一端为相同密钥使用相同比特,而且不管系统哪部分将比特串分为单个的密钥,加密密钥必须从第一个比特取出而且认证密钥必须从剩下的比特取出。每一个密钥的比特数由相关RFC规范定义。在多加密密钥或者多认证密钥情况下,算法规范必须指定使用提供给算法的单一比特串的相关选择顺序。
4.6.3 定位一个安全网关
本节讨论主机如何知道有关安全网关的存在,以及当一个主机与这些安全网关连接时如何知道这些是正确的安全网关。所需信息存储地点的细节是本地事件。
考虑这样的情形,一个远程主机(H1)使用Internet访问服务器或者其他机器(H2),H1的传输必须通过一个安全网关,例如一个防火墙。这样的实例可以是一个通过Inte

rnet访问该组织防火墙(SG2)的移动主机。(可参见4.5节“安全连接的基础组合”例4)这样的情形会引起以下问题:
1. H1如何知道安全网关SG2的存在?
2. 它如何认证SA2,一旦它认证SG2,它如何证实SG2已被认证可以代表H2?
3. SG2如何认证 H1和确定H1已被认证可以连接到H2?
4. H1如何知道可以提供到H2可选路径的备份网关?
为解决这些问题,主机或者安全网关必须有一个管理接口,允许用户/管理者为任何将要使用的目的地址集配置安全网关的地址。这包括配置的能力:
* 定位和认证安全网关,以及确认其认证可以代表目的主机的所需信息。
* 定位和认证备份网关,以及确认其认证可以代表目的主机的所需信息。
假定SPD已经使用策略信息配置过了,而策略信息包含了关于到达安全网关和目的主机路径的所有其他IPSec要求。
本文档不讨论如何使安全网关的发现/确认自动化。
4.7 安全连接和多播
在点播传输中,安全连接的面向接收者机制意味着,目的端系统通常会选择SPI值。通过SPI值的目的端选择,不论手动配置的SA对于自动配置的SA,或者来自多源的SA相互之间,都没有优势可言。对于多播传输,每一个多播组有多个目的系统。所以一些系统或者个人需要代表每一个多播组,在所有多播组中协调选择SPI,然后通过这里没有定义的机制将该组的IPSec信息传递给该多播组的所有合法成员。
当使用一个对称密钥加密算法或者认证算法,一个多播组的多个发送者应该为对该组的所有传输使用一个单一的安全连接。这样情况下,接收者只知道消息来源于一个为该多播组处理密钥的系统。这样情况下,接收者通常不能认证发送多播传输的系统。其他规范,更多一般多播实例将在后面的IPSec文档中讨论。
当规范发布时,多播密钥分配的自动协议作为标准还成熟。对于相对地只有较少成员的多播组,手动密钥分配或者已存在的点播密钥分配算法,如已修改的Diffie-Hellman,看来是可行的。对于很大的组,则需要新的可升级的技术。现在这一领域使用的是组密钥管理协议(GKMP)[HM97]。
5.IP传输处理
前面4.4.1节提到“安全策略数据库(SPD)”中,所有的传输(输入或者输出)处理都必须查阅SPD,包括非IPSec的传输。如果SPD中找不到相应策略来处理该包,则该包必须丢弃。
注意:IPSec中使用的加密算法希望其输入符合网络字节顺序(可参见RFC791附录),并产生符合网络字节顺序的输出。IP包同样以网络字节顺序传送。
5.1输出IP传输处理
5.1.1选择使用一个SA或者SA束
在一个安全网关或BITW实现(在许多BITS实现)中,每个输出包都会被与SPD中

比较以决定如何处理该包。如果包将被丢弃,这是一个审查事件。如果传输被允许通过IPSec处理,该包将在IPSec处理环境中继续其“正常”处理过程。如果要求IPSec处理,该包将映射到一个已存在的SA(或者SA束),或者再为该包生成一个相应的SA(或者SA束)。由于一个包的选择符可能匹配多个策略或者多个现存的SA,而且SPD是有序的SAD却无序,所以IPSec必须满足:
1. 根据SPD中的外部策略,匹配该包的选择符域,以确定第一个合适的策略。这将指向SAD中的零个或多个SA束。
2. 根据1中找到的SA束的选择符域,匹配该包的选择符域,以定位第一个匹配的SA束。如果没有SA匹配,生成相应的SA束,并将SPD的入口链接到SAD的入口。如果没有发现密钥管理实体,放弃该包。
3. 使用2中发现或者生成的SA束执行所需的IPSec处理,例如:认证和加密。
在一个基于SOCKETS实现IPSec的主机中,任何一个新SOCKET的生成都将查阅SPD以决定将在该SOCKET传送上执行哪种IPSec处理,如果有的话。
注意:一个顺应的实现必须拒绝接受一个既没有加密算法也没有认证算法的ESP SA。任何试图接受这样SA的行为都是一个审查事件。
5.1.2隧道模式的头结构
本节介绍内部IP头、外部IP头、扩展头,以及AH和ESP隧道的选项的处理。包括如何构造封装(外部)IP头,如何处理内部IP头的各个域,和其他一些将要采取的措施。基本上遵循RFC2003中提到的,“IP封装”:
* 外部IP头的源地址和目的地址确定隧道的“终结点”(封装和拆封)。内部IP头的源地址和目的地址分别确定数据报的源发送者和接收者(从该隧道的角度看来)。(封装源IP地址的更多资料可参见5.1.2.1脚注3)
* 除了在下面提到的TTL递减中,内部IP头通常不会改变,并在到隧道出口点的传输过程中保持不变。
* 封装数据报在隧道的传输过程中,内部头的IP选择和扩展头保持不变。
* 如果需要,其他协议头如IP认证头会插入内外IP头之间。
下面小节的表中显示了对不同的头/选项域的处理(“已构造”为内外部域值独立设置)
5.1.2.1 IPv4——隧道模式的头结构
<-- 内部头如何与外部头关联 -->
IPv4 封装者的外部头 封装者的内部头
头域 ----------------------- ---------------------------
版本 4(1) 未变
头的长度 构造 未变
TOS 从内部头(5)复制 未变
全长 构造 未变
ID 构造 未变
标识(DF,MF) 构造,DF(4) 未变
段溢出 构造 未变
TTL 构造 递减
协议 AH,ESP,路由器报文头 未变
校验和 构造

相关主题
相关文档
最新文档