组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：尹欣 袁磊 陈代兵（theredfox xyin@ccnu.edu.cn）
译文发布时间：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．１文档内容摘要 4
1．2阅读对象 4
1.3 相关文档 5
2设计目标 5
2．１目的／目标／需求／问题描述 5
2．２警告和假设 5
3．系统概况 6
3．１IPsec能做什么 6
3．２IPsec怎样工作 6
3.３IPsec实现方式 7
4．安全连接(SECURITY ASSOCIATION) 7
4．１定义和范围 7
4．２安全连接的功能性 8
4．３安全连接的组合 9
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．１文档内容摘要
本备忘录定义了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．１目的／目标／需求／问题描述
IPsec被设计成为能够为IPv4和IPv6提供可交互操作的高质量的基于加密的安全。安全服务集提供包括访问控制、无连接的完整性、数据源认证、抗重播(replay)保护（序列完整性(sequence integrity)的一个组成部分）、保密性和有限传输流保密性在内的服务。这些服务是基于IP层的，提供对IP及其上层协议的保护。
这些目标是通过两大传输协议：头部认证(AH)、封装安全负载(ESP)和通过密钥管理过程和协议的使用来完成的。使用于任何环境中的IPsec协议集及其使用的方式是由用户、应用程序、和/或站点、组织对安全和系统的需求来决定。
当正确的实现、使用这些机制时，它们不应该对不使用这些安全机制保护传输的用户、主机和其他英特网部件产生负面的影响。这些机制也被设计成算法独立的。这一模块性允许选择不同的算法集而不影响其他部分的实现。例如：如果需要，不同的用户通讯可以采用不同的算法集。
定义一个缺省的标准集使全球英特网更容易交互。这些算法辅以IPsec传输保护和密钥管理协议的使用为系统和应用开发者采用基于IP层的高质量的加密的安全技术提供了途径。
2．２警告和假设
IPsec协议及相关缺省算法为英特网传输提供高质量的安全。但是，采用这些协议所提供的安全最终依赖于它们实现的质量，其外在表现为标准集的范围。此外，一个计算机系统或网络的安全是由许多因素决定的，它包括人、物、流程、有危险的散发(compromising emanations)以及计算机安全经验(practice)。因此IPsec仅仅只是综合性系统安全结构的一个组成部分。
最终，使用IPsec提供的安全很大程度上依赖于IPsec实现执行时操作所处操作环境中的诸多因素。例如，操作系统安全缺陷，较差质量的随机数源、不良的系统管理协议和经验等等都能降低使用IPsec所提供的安全。以上这些环境因素均不在这一或其他IPsec标准的讨论范围内。
3．系统概况
本节提供IPsec工作原理、系统构成以及如何组合提供上述安全服务的进一步说明。这一描述的目的是使读者对整个流程、系统有一个全貌，了解它是怎样适应IP环境的，为本文档的后续章节提供一个简述。在后续章节中将对每一个部分作更详细的描述。
IPsec实现工作于一个主机或一个安全网关的环境中，对IP传输提供保护。所提供的保护是基于：由用户或系统管理员建立和维护的安全策略数据库(SPD)所定义的需求；由用户或系统的管理员建立的具有约束性应用操作所定义的需求。通常，通过基于同数据库(SPD)入口相匹配的IP层和传输层头部信息的三种处理模式之一来选择包。 每一个包或被给予IPsec安全服务或被丢弃或被允许通过IPsec，这都基于选择符定义的相应数据库策略。
3．１IPsec能做什么
IPsec为IP层提供安全服务，它使系统能按需选择安全协议，决定服务所使用的算法及放置服务所需密钥到相应位置。IPsec用来保护一条或多条主机与主机间、安全网关与安全网关间、安全网关与主机间的路径。（在IPsec 文档中，“安全网关”指的是执行IPsec协议的中间系统(intermediate system)。例如，路由器或实现了IPsec的防火墙，我们称之为“安全网关”）
IPsec能提供的安全服务包括访问控制、无连接的完整性、数据源认证、抗重播(replay)保护、保密性和有限传输流保密性在内的服务。因为这些服务均在IP层提供，所以任何高层协议均能使用它们。例如，TCP，UDP，ICMP，BGP等等。
IPsec DOI也支持IP压缩协商[SMPT98]。当在IPsec中使用加密而阻碍低层压缩的有效性时，IP压缩协商被激活。
3．２IPsec怎样工作
IPsec使用两个协议来提供传输安全――头部认证(AH)、封装安全负载(ESP)。这两个协议都在各自的RFCs[KA98a，KA98b]中有详细的描述。
* IP头部认证(AH) [KA98a]提供无连接的完整性验证、数据源认证、选择性抗重播服务。
* 封装安全负载(ESP) [KA98b]提供加密、有限传输流加密。它也提供无连接的完整性验证、数据源认证、抗重播服务。（无论ESP什么时间被调用，这些安全服务的某一集合必须被应用）
* AH和ESP均是基于密钥的分布和与这些安全协议相关的传输流管理，AH和ESP均可作为访问控制的媒介物
这些协议或者独立使用或者组合使用以提供IPv4和IPv6环境下所需的安全服务集。每一个协议支持两种使用模式：传输模式，隧道模式。在传输模式下，协议为高层提供基本的保护；在隧道模式下，协议使IP包通过隧道传输。两种模式的区别将在第４章节讨论。
IPsec允许用户（系统管理员）控制安全服务的粒度(granularity)。例如，用户可以在两个安全网关间创建单一加密隧道传输所有信息，也可以为每一通过这些网关通讯的主机对的每一个TCP连接创建一个独立的加密隧道。IPsec管理必须体现下列特性：
* 使用哪些安全服务及在哪种组合中被使用
* 指定安全保护应该使用的粒度
* 对基于加密的安全产生影响的算法
因为这些安全服务使用共享的安全值（密钥），IPsec依赖一组独立的机制来存放这些密钥。（这些密钥用作认证、完整性验证及加密服务。）本文档需要支持手动、自动两种分配方式。它为自动密钥管理定义了一个特殊的基于公共密钥的方法(IKE-[MSST97，Orm97，HC98])，但其他自动密钥分配技术也可以(MAY)使用。
3.３IPsec实现方式
在主机上或路由器、防火墙（创建安全网关）的连接处，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．１定义和范围
安全连接(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．２安全连接的功能性
由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．３安全连接的组合
穿过独立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．４安全连接数据库
在一个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的<Destination IP Address, IPsec Protocol, SPI>元组中的“目的地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@foo.bar.com
b． X．500 著名的名称，例如，C = US，SP = MA，O = GTE网际互连，CN = Stephen T.Kent
2． 系统名称（主机，安全网关，）
a． 一个有完全权限的DNS名称，例如，foo.bar.com
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的传输必须通过一个安全网关，例如一个防火墙。这样的实例可以是一个通过Internet访问该组织防火墙（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,路由器报文头 未变
校验和 构造 构造(2)
源地址 构造(3) 未变
目的地址 构造(3) 未变
选项 未复制 未变
1．封装头中的IP版本可以和内部头中的值不同。
2．内部头中的TTL在转发之前会被封装者递减，转发之后被拆封者递减。（TTL变化时校验和也变化。）
注意：TTL递减是转发一个包时常用的方式。当发送节点只生成包却并不转发时，和封装者产生于同一节点的包没有递减其TTL。
3．源地址和目的地址取决于SA，SA用来决定目的地址，目的地址又用来决定转发包的源地址（网络接口）。
注意：原则上，已封装的IP源地址可以是封装者接口地址的任何一个，甚至可以是不同于封装者任何IP地址的其他地址，（例如NAT），尽管从包发出的环境来看通过封装该地址是可以到达的。由于涉及封装IP头的源地址，当前IPSec没有任何输入处理要求，这样做不会引起错误。因此当接收隧道端提取封装IP头中的目的地址时，它仅仅提取内部（已封装的）IP头中的源地址。
4．配置决定是否从内部头中复制（仅限IPv4），清除或者设置DF。
5．如果内部Hdr是IPv4（Protocol = 4），复制TOS。如果内部Hdr是IPvv6（Protocol = 41），将Class映射到TOS。5．1．2．2IPv6——隧道模式的头结构
可参见5．1．2节注释1—5
<-- 内部Hdr如何与外部Hdr关联 -->
IPv6 封装者的外部头 封装者的内部头
头域 -------------------------- ---------------------
版本 6(1) 未变
级别 复制或者配置（6） 未变
流ID 复制或者配置 未变
长度 构造 未变
下一个头 AH，ESP，路由器地址 未变
跳限制 构造（2） 递减（2）
源地址 构造（3） 未变
目的地址 构造（3） 未变
扩展头 不复制 未变
6．如果内部Hdr是IPv6（Next Header = 41），复制Class。如果内部Hdr是IPv4（Next Header = 4），将TOS映射到Class。
5．2 输入IP传输处理
在完成AH或者ESP处理之前，任何IP分段都可以重组。每个将进行IPSec处理的输入IP数据报由其IP NEXT协议域的AH或者ESP值（或者Ipv6环境中作为扩展头的AH或ESP）标识。
注意：附录C中有32位报文窗口掩码校验的源代码，可以用于实现抗重播服务。
5．2．1 选择使用一个SA或者SA束
由于AH或者ESP头中SPI的存在，将IP数据报映射到合适SA的工作可以更简化。注意选择符校验在内部头中完成，而不是外部头中。其步骤如下：
1． 使用包的目的地址（外部IP头）、IPSec协议和SPI在SPD中搜索SA。如果SA搜索失败，丢弃该包并报告/记录出错。
2． 使用1中找到的SA执行IPSec处理，例如认证和解密。这一步包括在SA中将该包（如果在隧道中的，则是内部头）的选择符和SA的选择符进行匹配。本地策略决定SA选择符的细节（单值、列表、范围、通配符）。一般地，一个包的源地址必须匹配SA选择符的值。但是，SA隧道模式下接收的ICMP包可能有一个不同于SA的源地址，但是这样的包作为特例应该可以通过检验。在ICMP包中，封装问题包（源地址、目的地址以及端口应该相互调动）的选择符应该根据SA选择符进行校验。注意由于为了加密或者ICMP包中能携带的问题包的字节数有限，这些选择符中的一些或者全部可能不能访问。可参见第6节。
对每个IPSec头重复1和2步操作，直到遇到不适合该系统的传输协议头或者IP头。记录用到的SA及其使用的顺序。
3． 在SPD中寻找一个匹配该包的输入策略。例如，可以使用从SAs到SPD的回调指针来完成，也可以通过根据SPD中策略入口的选择符匹配该包的选择符来完成查找。
4． 检验所需的IPSec处理是否已进行，即确定在1和2中找到的SA符合3中策略所需的类型及使用顺序。
注意：正确的“匹配”策略不一定是找到的第一个内部策略。如果4中校验失败，重复3和4直到所有策略入口都被检验或者校验通过。
以上步骤之后，将处理后的包传送到传输层或者转发该包。注意任何按照上述步骤处理过的IPSec头都有可能已经被删除。但是相关的信息，例如采用的SAs的类型和顺序，在后面的IPSec处理或者防火墙处理都将用到。
注意：在一个安全网关实例中，如果通过一个激活的IPSec能力的接口转发报文导致一个包的无效，将会采用附加的IPSec处理。
5．2．2 AH和ESP隧道的处理
内外IP头，扩展头以及AH和ESP隧道选项的处理按照5．1节表中描述的方法完成。
6．ICMP处理（IPSec相关内容）
本节主要讲ICMP错误消息的处理。其他ICMP传输，例如Echo/Reply，与其他传输大致相同，在以一般方式运用SAs的端到端传送中可以得到保护。由路由器生成、受AH或者ESP保护的ICMP错误消息应该在SA隧道模式中处理和转发。本地策略决定它是否接受在隧道的目的端路由器的源地址校验。注意如果隧道发送端的路由器是转发其他路由器的ICMP错误消息，则源地址校验会出错。由路由器生成、受AH或者ESP保护的ICMP错误消息必定不能在SA传送模式下转发（除非为路由器建立的SA作为主机，例如一个Telnet连接用来管理一个路由器）。
由主机生成的ICMP消息，应该根据与消息到达端SA有关的源IP地址选择符对其进行校验。注意即使ICMP错误消息源得到认证，返回的IP头也可能是无效的。相应的，应该校验IP头中的选择符值以保证它们和接受ICMP消息端SA的选择符值一致。
附录D描述了主机生成的或者路由器生产的，未知的和未标记的ICMP消息。最后两类ICMP消息应该由接收方策略处理。没有被AH或者ESP保护的ICMP消息不会得到认证，该消息的处理和传送会导致此次服务的失败。一般情况下，建议不要忽略此类消息。但是可以想象许多路由器不会对传送传输进行IPSec处理，如果严格执行该规则，又会引起许多ICMP消息的丢弃。导致一些重要IP功能丢失，例如重定向和PMTU处理。因此接受或者拒绝ICMP传输必须可以由每一个本地策略配置IPSec实现来决定。
本节后面的部分讨论PMTU处理如何必须在主机和安全网关完成。它讨论认证的和非认证的ICMP PMTU消息的处理。但是正如上面提到的，非认证的ICMP消息可能被本地策略丢弃。
6．1 PMTU/DF的处理
6．1．1 DF 位
如果一个系统（主机或者网关）增加一个封装头（ESP隧道或者AH隧道），它必须支持将DF位从源报文复制到该封装头（而且处理ICMP PMTU消息）的选项。这意味着它必须能够为每个接口配置系统DF位（设置、清除，从封装头中复制）。（可参见附录B）
6．1．2 Path MTU发现 （PMTU）
本节讨论Path MTU发现消息的IPSec处理。ICMP PMTU在这里用来参考一个ICMP信息：
IPv4（RFC792）：
—TYPE=3（目的不可到达）
—CODE=4（需要分段，DF设置）
—ICMP头的第二个字的下16位中的下一跳MTU（RFC792中标记为“未用”），其上16位设为0
IPv6（RFC1885）：
—TYPE=2（报文太大）
—CODE=0（需要分段）
—ICMP6消息的32位MTU域的下一跳MTU
6．1．2．1 PMTU的传播
ICMP PMTU消息携带的信息总数有限，将影响进一步传播PMTU信息时提供哪些选择符。（可参见附录B相关细节）
* 携带64位IPSec头的PMTU消息——如果ICMP PMTU消息仅仅包含64位IPSec头（Ipv4的最小标准），安全网关必须在每个SPI/SA上支持如下选项：
a.如果源主机可以确定（或者可能的主机数限定在一定范围内），给所有可能的源主机发送PM信息。
b.如果源主机不能确定，存储PMTU和SA直到从源主机发来的下一个包到达相关的安全连接。如果此包大于PMTU，丢弃该包，用新包重组ICMP PMTU消息，更新PMTU向源主机发送相关ICMP消息。为随后到达的消息保留该PMTU信息。（参见6．1．2．4“PMTU计时”）
* 携带大于64位IPSec头的PMTU消息——如果ICMP消息包含更多来自源报文的信息，就有足够信息立即决定向哪个主机传播ICMP/PMTU消息，并提供给该系统五个域（源地址、目的地址、源端口、目的端口、传输协议）以决定在何处存储或者更新PMTU。相同环境下，安全网关必须根据从此路径下一个结点接收到的ICMP PMTU立即生成一个ICMP PMTU消息。
* 向传输层发送PMTU——将已更新PMTU送到传输层的主机机制没变，仍然如RFC1191中指定的（Path MTU发现）。
6．1．2．2 PMTU的计算
一个ICMP PMTU的 PMTU计算必须考虑任何IPSec头的附加项——AH传输，ESP传输，AH/ESP传输，ESP隧道，AH隧道。（可参见附录B的相关讨论）
注意：某些情况下，IPSec头的附加项会导致一个有效的PMTU（主机或者应用程序看来）变得不可接受的小。为了避免这个问题，实现必须建立一个阀值，低于此阀值时不会报告已减小的PMTU。这样的情况下，实现将要运用IPSec，依照PMTU对处理过的报文进行分段，使提供的带宽得到更有效的利用。
6．1．2．3 PMTU处理的粒度
在主机端， ICMP PMTU处理的粒度随着实现环境不同而不同。主机端有三种与PMTU事件有关的有利情形（可参见附录B）
a． 原IP中嵌入IPSec的实现。
b． 堆栈中的块实现，在已实现的TCP/IP协议栈下实现IPSec，在原IP和本地网络驱动器之间。
c． 非IPSec实现——一个安全网关向主机回送PMTU信息时，与这种情况有关，故包含在内。
只有a中PMTU数据才能采用与通信联合相同的粒度。a和b中，IP层只能以与源、目的IP地址相同的粒度维持PMTU数据，如在RFC1191中定义的。这是非常重要的区别，因为不止一个通信联合可以映射到相同的源、目的IP地址，而且每一个通信联合可以有不同数目的IPSec头。（例如，由于不同的传输机制或者不同的算法）。
PMTU计算的实现，和以单个通信联合粒度支持PMTUs是本地事件。但是主机中基于IPSec的一个SOCKET实现应该在每一个SOCKET上保留该信息。堆栈中的块系统必须向主机IP实现传送一个ICMP PMTU，在为这些系统增加的所有IPSec头调整过ICMP PMTU之后。其上的计算应该由SPI分析和返回的ICMP PMTU消息中其他选择符信息决定的。
6．1．2．4 PMTU 计时
在所有实现IPSec和保留PMTU信息的系统中，与安全连接有关的PMTU必须“计时”，而且为了即时更新PMTU也需要采取一些机制，特别是如果PMTU比所需的小而为了发现PMTU时。一个给定的PMTU必须保留足够长的时间，以将从安全连接源端得到的包传给安全连接另一端的系统，如果当前PMTU太大则传回一个ICMP错误消息。注意如果有嵌套隧道，使ICMP消息传回一个封装者或者源主机可能需要多个包和循环传输次数。系统应该使用Path MTU发现文档中描述的路径（RFC1191，6．3节），它建议定期将PMTU重设为第一跳的数据链接的MTU，并根据需要让正常PMTU发现过程更新PMTU。此过程应该是可配置的。
7．审查
不是所有实现IPSec的系统都实现审查。多数情况下，审查的粒度是本地的事件。但是一些审查事件已在AH和ESP规范中被确认。对于这些事件中的每一个，一个应该包含在一个审查日志中的信息最小集已经定义。同样对于这些事件中的每一个，附加的信息也可以包含在审查日志里。而且附加事件，本规范中没有明确提出，也可以引起审查日志入口启动。接收端没必要将任何消息都传送到与审查事件检查有关的传输部件，因为这样做可以减少拒绝服务的情况。
8．在支持信息流安全的系统中的运用
各种灵敏度层次的信息可以由单一的网络传输。信息标记（例如未分级的，公司专有，秘密）[DoD85,DoD87]经常用来分辨这样的信息。标记的使用会使信息的分级更容易。在支持信息流安全模式中，例如Bell-LaPadula模式[BL73]。这样的模式以及相关支持技术用来阻止未经认证的敏感信息流，甚至对付特洛伊木马攻击。一般的，自由访问控制机制（DAC），例如基于访问控制列表，不能有效地支持这样的策略，而且如SPD这样的设备在此环境下也不能有效工作。在军事环境下，支持这样模式的技术通常与多级安全有关。如果计算机和网络支持与信息流安全策略结合的标记数据的分离，经常被称为“多级安全”。虽然这项技术远不止用于军事运用，但是文档依然“MLS”来简称它，与一些现存的文献保持一致。
IPSec机制可以轻易地支持MLS网络。MLS网络需要使用强命令访问控制，非特权用户或者非特权处理无法控制或者违背。本节仅讨论MLS环境下IP安全机制的使用本节没有任何内容可以应用于没有声称能提供MLS的系统。
如同在本节用到的，“灵敏性信息”可以包含定义实现的层次，目录，和可公开的信息。
AH可以提供强认证用来支持MLS环境中的命令访问控制决定。如果使用直接的IP灵敏性信息，而且在特定操作环境下机密性被认为已无必要，AH可以用来认证IP头中灵敏性标记与IP负载（包括用户数据）的结合。已标记的IPv4网络安全性有显著提高，灵敏性信息都可信赖，即使IP头和用户数据没有认证或者加密。Ipv4网络可以使用直接的标记，也可以不使用。IPv6通常使用隐含性的灵敏性信息，这是IPSec安全连接的一部分，但是随着每一个包传输的是直接的灵敏性信息而非隐含性的灵敏性信息。使用ESP或者AH或者两者时，所有直接的IP灵敏性信息必须得到认证。
即使所有主机都在一个受到保护的环境下，加密也是有用的和可取的，例如，在防火墙或者与任何外部连通不相连的结点的背后。为了支持DAC和MAC，ESP可以在与加密算法及合适密钥管理的接合中使用。（加密算法和认证算法的选择，以及一个IPSec实现的保证级别将决定一个环境，在此环境的实现被认为可以有效的满足MLS的需要。）密钥管理可以利用灵敏性信息提供MAC。在声称可提供MLS的系统上，IPSec实现应该能够为基于IP的通信提供MAC。
8．1 安全连接与灵敏性数据的关系
封装的安全负载和认证头都可以与合适的安全连接策略结合以提供多级安全网络。此例中，每个SA（或者SA束）通常为一个单一的灵敏性信息实例使用。例如“PROPRIETARY——搜索引擎”必须与 “PROPRIETARY——金融”的一个不同的SA有关。
8．2 灵敏度一致校验
一个MLS实现可以将灵敏性信息或者一个灵敏性信息的范围与一个接口相关联，或者将已配置的IP地址与它的相关前缀关联（后者时常当作一个逻辑接口或者接口别名）。如果这些性能存在，一个实现应该将与该包相关的灵敏性信息，和与接口或者与包（将要）被发来的地址/前缀有关的灵敏性信息做比较。校验将确认灵敏度匹配，或者确认在接口或者地址/前缀的范围内包的灵敏性会失效。
校验应该在内部和外部处理时完成。
8．3 SPD的附加MLS属性
在4．4节讨论过两种安全连接数据库（安全策略数据库SPD和安全连接数据库SAD），联合的策略选择符和SA属性。MLS网络介绍了一个附加的选项符/属性：
——灵敏性信息
灵敏性信息有助于选择合适的算法和密钥长度，因此传输中的重要信息和灵敏性信息（如8．3节中描述的）可得到相应级别的保护。灵敏性信息的精确语法在实现中定义。
8．4 MLS网络的附加输入处理步骤
输入报文通过IPSec处理后，在向上一层协议传递或者转发数据报之前，如8．2节中描述的，一个MLS实现应该首先检验包的灵敏性是否与接口或者地址/前缀相符合。
MLS系统必须保留一个IPSec保护报文中接收数据和用于处理的SA或者SAs中的灵敏性信息之间的联结，所以当向一个应用程序传递数据报或者转发引擎时可以做出合适的策略决定。维持联结的方式是特定的实现。
8．5 MLS网络的附加输出处理步骤
IPSec的MLS实现必须完成两个附加校验除了5．1．1节提到的通常的步骤外。当查阅SPD或者SAD以寻找一个外部安全连接时，MLS实现必须使用数据的灵敏度选择一个合适的输出SA或者SA束。在向目的地转发报文之前进行第二个校验，即8．2节提到的灵敏性一致校验。
8．6 安全网关的附加MLS处理
一个MLS安全网关必须遵守前面提到的输入和输出处理规则，就象在MLS环境下完成对包的中级保护的附加处理。
一个安全网关可以作为一个输出代理，为那些由网关转发源报文的MLS系统生成SAs。这样的MLS系统可以直接标记将要转发的报文，或者整个源网络可以有与它相关联的灵敏性特性。安全网关必须为AH/ESP或者为两者生成并使用合适的SAs以保护它的转发传输。
类似地这种网关应该接受并处理输入AH或者ESP包，做相应地转发，使用直接报文标记，或者依赖目的网络的灵敏性特性。
9．性能问题
IPSec使用将计算性能开销强加在实现这些协议的主机或者网关上。这些开销与IPSec代码和数据结构所需的内存、完整性校验值的计算、加密解密、增加的每一个包的处理等有关。每一个包的开销由增加的延时表明，也可能用吞吐量的减少来表示。一些SA/密钥管理协议的使用，特别是公共密钥加密的协议，也增加了IPSec使用的计算性能开销。每个联合计算开销应该用联合建立中的增加的延时表明。多数主机期望基于软件的密码术不会相当大地减少吞吐量，但是网关和一些主机需要硬件。
IPSec使用将带宽利用开销强加在Internet下层结构的传输、交换和路由等部件上，那些不实现IPSec的部件。这归因于报文大小的增加，与密钥管理协议相关的包传输的增加。AH头和ESP头的附加，AH和ESP隧道的附加，都会导致报文大小的增加。在多数实例中，增加的带宽命令不会明显影响Internet下层结构。但是，在一些实例中，影响也会很明显，例如在ESP传输将一个拨号连接上的传输加密，否则可能可能会压缩传输。
注意：其上初始化的SA建立会在第一个包完成。延迟会影响传输层和应用程序。例如，会导致TCP在ISAKMP交换完成之前重传SYN。延迟对TCP和UDP的影响不同。因为除了SYN，TCP不会传送任何信息直到连接建立，而UDP会继续传送除了第一个包之外的数据。
注意：正如先前谈到的，IP以上各层也可以压缩。这是一个IETF工作组，其工作是制定“协议规范，在加密协议处理负载之前可以对单个负载完成无损压缩。协议允许负载的压缩操作优先于IPSec协议加密操作”。
10．遵守的要求
所有声称实现IPSec的IPv4系统必须遵守所有安全结构文档的要求。所有的IPv6系统必须遵守所有安全结构文档的要求。
11．安全考虑
这份文档着眼于安全，所以安全考虑渗透整个规范。
12．与RFC1825的不同
这份结构文档在细节和组织上完全不同于FEC1825，但是基本概念未变。本文档以后续规范的形式提供了重要的附加细节。它介绍了SPD，SAD，以及SA选择符的概念。与新版本的AH和ESP定位一致，也不同于RFC1825。支持AH和ESP组合的特定要求，以及PMTU的管理细节也是新提出的。
附录A——词汇表
本节定义文档中用到的一些关键术语。其他文件提供一些与该技术有关的术语定义和背景信息，例如，[VK83，HA94]。词汇表中包含安全服务类，安全机制类以及IPSec特定类的术语。
访问控制：
访问控制是一种安全服务，它可以防止一个资源的未经认证的使用，包括防止以未经认证的方式使用一个资源。在IPSec上下文中，访问受到控制的资源经常是：
* 对于主机，可计算的循环或者数据
* 对于安全网关，网关后的网络或者此网络的带宽
抗重播：
参见后面的“完整性”
认证：
此术语用来解释两种表面上看来不同的安全服务，数据源认证和无连接的完整性。可参见后面两个服务的定义。
有效性：
有效性，作为安全服务来看，定位于安全，由攻击否定或者拒绝服务的网络而产生。例
如，在IPSec上下文中，AH和ESP中抗重播机制的使用支持有效性。
机密性：
机密性是保护数据不被未经认证的使用。多数实例中最基本的机密性是应用级数据的未经认证的使用，一些情况下通信外部特性的使用也包含在内。传输流的机密性就是定位后者的服务，通过隐藏源地址、目的地址、消息长度、或者通信频率的方法。在IPSec上下文中，
在隧道模式中使用ESP，特别是在安全网关，可以提供一些传输流机密性的级别。（参见后面的传输分析。）
加密：
加密是一种安全机制，用于将数据从一种可理解的格式转变为一种不可理解的格式，以提供机密性。相反的转变过程称为解密。有时加密用来代指这两种过程。
数据源认证：
数据源认证是一种安全服务，用来确认数据声称的源的身份。经常和无连接完整性服务结合使用。
完整性：
完整性保证数据的修改是可觉察的。根据应用的需要有各种不同的完整性。IPSec支持两种完整性：无连接完整性和部分次序格式的完整性。无连接完整性可以觉察单个IP数据报的修改，与一个传输流中数据报的顺序无关。IPSec中提供的部分次序格式完整性，和抗重播完整性一样，它能觉察重复IP数据报（在一个强制窗口）。与面向连接完整性相比，它更加严格限制传输次序，以觉察丢失或者重发的消息。尽管认证和完整性服务常常独立地提到，实际上它们连接紧密，串行提供。
安全连接：
一种简单的逻辑连接，为了安全的目的而生成的。一个SA上的所有传输提供相同的安全处理。IPSec中，SA是一个抽象的中间层，由使用AH或者ESP来实现。
安全网关：
一个安全网关就是一个中间系统，作为两个网络之间的通信接口。安全网关外部的主机（网络）被认为是不可信的（或者不太全信的），而安全网关内部的主机和网络被认为是可信的（或者更可信的）。安全网关服务的内部子网和主机，由于共享一个共同的本地的安全管理，假定为可信的。（参见可信的子网。）在IPSec上下文中，一个安全网关就是一点，在那里实现AH和ESP以为内部主机集服务，当它们与采用IPSec的外部主机通信时为其提供安全服务。
SPI：
“安全参量索引（Security Parameters Index）”的缩写。一个目的地址，一个安全协议，和一个SPI的结合唯一的确定了一个安全连接（参见SA）。SPI在AH和ESP协议中实现，使接收系统可以在处理一个接收包时选择SA。一个SPI只有本地意义，由SA的生成者定义（通常是包的接收者实现SPI）；因此一个SPI通常被当作不可见的比特流。但是SA的生成者会选择解释比特流，使本地处理变得容易。
传输分析：
为了减少对对手有用的信息，进行网络传输流分析。例如传输频率，谈话方标识，包的大小，流标识等等。
可信的子网：
子网，其中的主机和路由器相互信任不会从事积极的或者消极的攻击。假定下面的隧道不会被其他方式攻击。
附录B PMTU/DF/分段问题的分析与讨论
B.1 DF 位
在一个系统（主机或网关）增加一个封装头（如：ESP隧道）的例子中，是否应该/必须把原始包中的DF位拷贝到封装头中呢？
在某些场合分段好象是正确的，例如：在有一个非常小的MTU网上，对包分段是正确的；这些MTU如： 包无线传播网络，到移动节点的移动电话跳，但传回一个用于路径的其余节点小PMTU是不合适的。其他情况下，为了从更后的路由器上得到有关需要分段的PMTU限制而设置DF位，这样做可能是合适的。两种情况的存在，使一个系统决定在特殊的网络“连接“上是否分段存在争论，即是说，需要一个实现，它能拷贝DF位(和处理ICMP PMTU报文)，并且使它成为一个选择符，可在每个基本接口上选择。换句话说，管理者应该能为每个接口配置DF位的路由处置方式。
注：如果IPsec的堆栈中的块实现企图应用基于源/目的端口不同的IPsec算法,那么应用Path MTU调整是困难的。
B.2 分段
在IPsec实现里，若需要，IP分段发生在IPsec处理之后。所以，传输模式AH或ESP仅用在整个IP数据报(而不是IP分段)中。已经应用了AH或ESP的IP包可能被路由中的路由器自己分段，并且，在接收端，这些分段必须优先于IP处理重组。在隧道模式中，AH或ESP应用于IP包，它的有效载荷可能是一个分段的IP包 。例如，安全网关，堆栈中的块 （BITS）或者电缆中的块（bump-in-the-wire,BITW） IPsec实现可能应用通道模式AH到这些分段中。注意，BITS 或BITW是主机层IPsec实现可能收到应用隧道模式的分段的例子。但是，如果用隧道传输模式，这些实现必须优先于应用IPsec重组分段。
注：IPsec必须指出封装IP头域。这与往哪里插入IPsec无关，并且与IPsec的定义是有本质区别的。所以任何没有集成到IP实现的IPsec实现必须包括用来构造必需的IP头的代码（如IP2）。:
o AH-tunnel --> IP2-AH-IP1-Transport-Data
o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer
*********************************************************************
综上所述，上述的分段/重组方法对所有已经测试的例子是有效的。
AH Xport AH 隧道 ESP Xport ESP 隧道
实现方法 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
----------------------- ---- ---- ---- ---- ---- ---- ---- ----
主机 (integr w/ IP 堆栈) 是 是 是 是 是 是 是 是
主机 (betw/ IP 和驱动器) 是 是 是 是 是 是 是 是
S. Gwy (integr w/ IP 堆栈) 是 是 是 是
Outboard 加密处理器 *
*若加密处理器系统有自己的IP地址，则安全网关盒(case)会覆盖它。这个盒子从主机接收包并且完成IPsec处理。它必须能处理一个安全网关能处理相同的AH、ESP和相关的IPv4/IPv6隧道处理。若没有自己的地址，则它与在IP和网络设备层之间的堆栈中的块相似。
对下面的分析作如下假定：
1． 一个给定的堆栈里只有一个IPsec模块；不存在IPsec模块A（因增加ESP/加密而）隐藏来自IPsec模块B的传输协议、源端口和目的端口。
2．有几个地方能够IPsec被实现（如上表所述）。
a. 集成IPsec到本地IP实现的主机。实现器访问堆栈的源。
b. 有堆栈中的块实现的主机，IPsec在IP和本地网络设备层之间实现。堆栈中的源访问是不可获得的。但有定义好的接口允许IPsec代码与系统兼容。
c. 安全网关和把IPsec集成到堆栈的外部（outboard）加密处理器。
3．上述方法并不是对所有主机都是可行的。但是假定每种方法，都有主机用该方法可行。
对上面3种类，每种都有IPv4和IPv6，AH传输和隧道模式与ESP传输和隧道模式，总共有种24情况（3×2×4）。
这里列出每参考的一些头域和接口域——没按头顺序，但列出来可以在列间对比。（*=不被AH认证覆盖。ESP认证不覆盖在它（*=）之前的任何头。）
IP/传输接口
IPv4 IPv6 (RFC 1122 -- 3.4节)
---- ---- ----------------------
Version = 4 Version = 6
Header Len
*TOS Class,Flow Lbl TOS
Packet Len Payload Len Len
ID ID (optional)
*Flags DF
*Offset
*TTL *Hop Limit TTL
Protocol Next Header
*Checksum
Src Address Src Address Src Address
Dst Address Dst Address Dst Address
Options? Options? Opt
? 表示：AH可以覆盖Option-Type和Option-Length, 但不可以覆盖Option-Data。
这20种情况的结果在下面显示（“有效”是指：当系统分段在外出IPsec处理之后，在进入IPsec处理之前重组时是有效的）。注解表明了实现问题。
a. Hosts (集成在IP堆栈中)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 - 有效
- IPv6 -- 有效
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- 有效
- IPv6 -- 有效
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- 有效
- IPv6 -- 有效
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- 有效
- IPv6 -- 有效
b.主机（堆栈中的块 ）——把IPsec放在IP层和网络设备层之间。此例中，IPsec模块要为分段和重组做一些下面的工作：
-自己做分段/重组工作，直接从网络层发送/接收包。在AH或ESP传输模式中，这是优良的。在隧道终端位于最终目的地的隧道模式中，这也是优良的。但是有这样的AH或ESP传输模式：隧道终端不同于最终目的地并且源主机有多个地址，在这种模式中，这种方法会导致子最佳路由（sub-optimal routing）,因为IPsec模块不能获得需要的信息（LAN接口和下一跳(next-hop)网关）来指示数据到适当的网络接口。对最终目的地和隧道终端而言，如果接口和下一跳是相同的，则不存在这个问题。然而如果不同，则IPsec需要知道隧道终端的LAN接口和下一跳。(注意：隧道终端(安全网关)最有可能在通向最终目的机的有规律的路径上。但也有可能不止一条路径到目的地，例如，主机可能在有两个防火墙的组织里。并且所用的路径可能包括不常用的防火墙。)或者
-把IPsec包（IPsec'd）传回到IP层，在那里,一个额外的IP头将终止先前未决的（pre-pended）,并且IPsec模块必须核对才让IPsec分段通过。或者
- 把包内容用格式传送到IP层，这方便IP层重新创建一个适当的IP头。
在网络层，IPsec模块将访问来自包的如下选择符-SRC address、DST address、Next Protocol，如果有传输层头，还包括SRC port、DST port。不能假定Ipsec可访问了Name。假定可获得的选择符信息很充分，用它们能够计算出相对安全策略入口(entry)和安全关联。
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 - 有效
- IPv6 -- 有效
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- 有效
- IPv6 -- 有效
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- 有效
- IPv6 -- 有效
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- 有效
- IPv6 -- 有效
c.安全网关-把IPsec集成到IP堆栈中
注解：IPsec模块将访问来自包的如下选择符-SRC address、DST address、Next Protocol，如果有传输层头，还包括SRC port、DST port。它不会访问User ID（只有主机访问了User ID信息）。不象一些堆栈中的块实现里，安全网关能够查看DNS里的Source Address来提供系统名，例如，在涉及动态指定IP地址和动态更新DNS条目入口的情况下，如果有一个ESP头或者它不是分段消息的首个分段，它也不访问传输层信息。假定可获得的选择符信息很充分，用它们能够指定相关安全策略入口和安全关联。
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 - 有效
- IPv6 --有效
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- 有效
- IPv6 -- 有效
**********************************************************************
B.3 Path MTU 发现
如前所述，“ICMP PMTU"指的是用于Path MTU发现的ICMP消息。
在下面的B.3.1和B.3.3（不是B.3.2）里的图表说明是：
==== =安全连接(AH或ESP,传输和隧道)
---- =connectivity (或如果已标记,则为 administrative boundary)
.... = ICMP message (此后用来指ICMP PMTU) 对 IPv4:
- Type = 3 (目的地不能到达)
- Code = 4 (需要分段和DF位设置)
- Next-Hop MTU 在ICMP头的第二字节的低16位(在RFC 792里，标签未用),高16位置0
IPv6 (RFC 1885):
- Type = 2 (包太大)
- Code = 0 (需要分段和DF位)
- Next-Hop MTU 在ICMP6的32位MTU域里
Hx = 主机 x
Rx = 路由器 x
SGx = 安全网关 x
X* = X 支持 IPsec
B.3.1 标识原始（originating）主机
ICMP消息携带的信息量是有限的，这影响了可获得的选择符标识安全关联、源主机等，这些选择符用于进一步传播PMTU消息。
简而言之，ICMP报文必须包括来自“攻击”包的以下信息：
- IPv4 (RFC 792) -- IP 头加上一个64位最小值
相应的，在IPv4上下文环境里，ICMP PMTU可能仅仅认证第一个（outermost）安全关联。这是因为在IP头之外，ICMP PMTU仅仅容纳64位“攻击“报文，它只能捕获来自AH或ESP的第一个SPI。在IPv6上下文环境里，ICMP PMTU可能提供所有SPI和在IP头里的选择符，但是尽可能没有SRC/DST端口和封装协议（TCP、UDP等）。而且，如果用ESP，传输端口和协议选择符应加密。
看看下面关于安全网关隧道的图表（如其他地方提到的一样，安全网关不用传输模式）...
H1 =================== H3
\ | | /
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^ | \
H2 |........| H4
对所有在主机H0,H1,H2和主机H3,H4,H5之间的通信来说，假定SG1的安全策略是用单个SA到SG2。并假定H0发送一个包到H5,这导致R1发送一个ICMP PMTU消息到SG1。如果PMTU只有SPI,那么SG1能查找SA并发现可能的主机名单(H0,H1,H2,通配符)；但是SG1没有办法确定H0发送触发ICMP PMTU消息的传输。
源包 在IPsec ICMP
处理之后 包
-------- ----------- ------
IP-3 头 (S = R1, D = SG1)
ICMP 头 (includes PMTU)
IP-2 头 IP-2 头 (S = SG1, D = SG2)
ESP 头 64 位 ESP hdr最小值 (*)
IP-1 头 IP-1 头
TCP 头 TCP 头
TCP 数据 TCP 数据
ESP 追踪者（trailer）
(*) 64位要包括足够的ESP(AH)头，以能够容纳SPI。
- ESP -- SPI (32位), 序列号(32位)
- AH - 下一个头 (8位), 净载长度（Payload）(8位),
保留(16位), SPI (32位)
ICMP消息携带的信息量的限制产生了一个问题，这问题在于如何为包识别源主机（以便知道进一步往哪里传ICMP PMTU信息）。如果ICMP信息仅容纳64位的IPsec头(IPv4的最小值)，那么IPsec选择符（如，源和目标地址、下一协议、源和目标端口等）将丢失。但是ICMP错误消息仍然把SPI、PMTU信息和相关安全连接的源和目的地网关提供给SG1。目的地安全网关和SPI只定义一个安全连接，这安全连接反过来定义一个可能源主机的集合。按这个观点，SG1能：
a. 发送PMTU消息到所有可能的源主机。如果主机名单是通配符或者大多数（许多）主机不发送到SG1，那就运行不太好。但如果SPI/目的地等恰恰映射到一个或少量主机，就可以运行。
b. 存储有SPI的PMTU并且一直等到下一个包从相关安全连接的源主机到来。如果它（它们）大于PMTU，就丢掉包，用新包和更新的PMTU构成ICMP PMTU消息，把有关此问题的ICMP PMTU消息发给源主机。这里涉及到通知源主机的延时，但避免了(a)的问题。
既然只有后一个方法在所有场合可行，那安全网关就必须提供此类“支持“（support），作为一个选项。但是，如果ICMP消息能容纳更多的来自源报文的信息，那就有足够的信息来立即确定传ICMP消息到哪一台主机，并且提供需要带有5个域（源地址、目标地址、源端口、目标端口和传输协议）的系统，以决定在哪里存储/更新PMTU。在这种情况下，安全网关必须立即产生ICMP PMTU消息，这个消息在从进一步路径来的ICMP PMTU收据之上。注意："下一协议"(Next protocol)域可以不包含在ICMP消息中，ESP加密的应用可以隐藏已经加密的选择符域。
B.3.2 PMTU的计算
来自ICMP PMTU的PMTU计算必须考虑经过H1的任何IPsec头的附加---AH和ESP传输，或ESP/AH隧道。在单个主机里，多个应用程序可以共享一个ESP，并且安全连接的嵌套可能发生（参看4.5节 安全连接的基本组合的必须支持的组合描述）。下面的图例描述了两个主机之间的安全连接的例子（与从多个主机中一个主机的透视中看到的一样）。(ESPx 或AHx = 传输模式)
Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet
为了能够确定映射到SPI-B的每个套接口的PMTU，有必要有从SPI-B到这两条中任一条通向它-Socket 1或Socket 2/SPI-A的路径的回调指针(backpointer)。
B.3.3 维护PMTU数据的粒度（granularity）
在主机中，做PMTU ICMP处理用的粒度随实现环境不同而各异。看看一台主机,关于PMTU问题有三种情况有意思。
a. 把IPsec集成到原有IP实现里。
b. 堆栈中的块实现，在本地IP和本地网络设备层之间,IPsec在已有的TCP/IP协议栈的实现的下面实现。
c. 非IPsec实现-这种情况之所以存在是因为它与安全网关把信息发回主机的情况是有关的。
只有情况（a）时，PMTU数据才以与通讯联合相同的粒度维护。其它情况下，与RFC1191描述的一样，IP层在源和目的IP地址的粒度里维持PMTU数据。这点是重要的区别，因为不止一个通讯联合可以映射到源和目的IP地址，在每个联合之上可以有不同数量的IPsec头(例如，由于用不同的转换或不同的算法)。下面的例子阐述了这种情况。
在情况(a)和(b)里，假设你有如下条件。H1正发数据到H2并且从R1传送到R2的包超过它们之间的网络跳的PMTU。
==================================
| |
H1* --- R1 ----- R2 ---- R3 ---- H2*
^ |
|.......|
如果R1配置成不分段的签署者传输(subsciber traffic),那么R1发送带有适当的PMTU 的ICMP PMTU消息给H1。H1的处理与实现的本质不同。在情况(a)下（原有IP），安全服务绑定在套接口或其对等实体上。这里H1里的IP/IPsec实现能够为联合套接口存储/更新PMTU。在情况(b)下,H1的IP层能够存储/更新PMTU，但是如上面谈到的一样，只在源和目的地址的粒度和可能的TOS/Class上。因此这结果是次最佳的，因为给定了源/目的/TOS/Class的PMTU是最大数量的IPsec头的减少,这个头用于给定的源和目的地之间的所有通信联合。
在情况(c)下，必须有一个安全网关来做任何的IPsec处理。因此假定你有下面的条件，H1正发数据到H2并且从SG1到R的包超过它们之间的网络跳的PMTU。
================
| |
H1 ---- SG1* --- R --- SG2* ---- H2
^ |
|.......|
如上面描述的情况(b)一样，H1的IP层能够存储/更新PMTU，但是如上面谈到的一样，只在源和目的地址的粒度和可能的TOS/Class上。因此这结果是次最佳的，因为给定了源/目的/TOS/Class的PMTU是最大数量的IPsec头的减少,这个头用于给定的源和目的地之间的所有通信联合。
B.3.4 PMTU的每个套接口维护
PMTU的计算的实现(B3.2节)和以单个“通信联合”的粒度对PMTU的支持（B.3.3）都是本地事件。但是在主机中的基于套接口的IPsec的实现应该维持信息在每个套接口基础上。堆栈中的块系统必须在调整这些系统增加的IPsec头的ICMP PMTU之后，把它传送给主机IP实现。其上的决定应该由返回的ICMP PMTU消息里的SPI分析和当前的别的选择符信息来确定。
B.3.5 通向传输层的PMTU数据的传输
与RFC1191(PMTU的发现)里规定的一样,获得到传输层的修改了的PMTU的主机机制是不变的。
B.3.6 PMTU数据的生命期
这个主题在6.1.2.4节里讲过了。
附录C 序列空间窗口代码（Sequence Space Window Code）例子
本附录包含了实现32位报文窗口的位掩码(bitmask)校验的常用程序。它由James Hughes(jim_hughes@stortek.com)和Harry Varnis (hgv@anubis.network.com)提供，并且作为实现的例子。注意这些代码既做重播(replay)校验又修改窗口。所以下面的算法只有在包得到认证后才能调用。在计算ICV之前，实现者可能要考虑分割代码来做重播(replay)校验。如果包不是重播，代码将计算ICV，（丢弃任何坏包）。如果包完好就更新窗口。
#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;
enum {
ReplayWindowSize = 32
};
u_long bitmap = 0; /* session state - must be 32 bits */
u_long lastSeq = 0; /* session state */
/* Return 0 if packet disallowed,return 1 if packet permitted */
int ChkReplayWindow(u_long seq);
int ChkReplayWindow(u_long seq) {
u_long diff;
if (seq == 0) return 0; /* first == 0 or wrapped */
if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* in window */
bitmap <<= diff;
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; /* this packet has a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
bitmap |= ((u_long)1 << diff); /* mark as seen */
return 1; /* out of order but good */
}
char string_buffer[512];
#define STRING_BUFFER_SIZE sizeof(string_buffer)
int main() {
int result;
u_long last, current, bits;
printf("Input initial state (bits in hex, last msgnum):\n");
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value to test (current):\n");
while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", ¤t);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
}
Appendix D -- Categorization of ICMP messages
The tables below characterize ICMP messages as being either host
generated, router generated, both, unassigned/unknown. The first set
are IPv4. The second set are IPv6.
IPv4
Type e/Codes Reference
=========================================================
HOST GENERATED:
3 Destination Unreachable
2 Protocol Unreachable [RFC792]
3 Port Unreachable [RFC792]
8S ource Host Isolated [RFC792]
14 Host Precedence Violation [RFC1812]
10 Router Selection [RFC1256]
References
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report M74-
244, The MITRE Corporation, Bedford, MA, May 1973.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[DoD85] US National Computer Security Center, "Department of
Defense Trusted Computer System Evaluation Criteria", DoD
5200.28-STD, US Department of Defense, Ft. Meade, MD.,
December 1985.
[DoD87] US National Computer Security Center, "Trusted Network
Interpretation of the Trusted Computer System Evaluation
Criteria", NCSC-TG-005, Version 1, US Department of
Defense, Ft. Meade, MD., 31 July 1987.
[HA94] Haller, N., and R. Atkinson, "On Internet Authentication",
RFC 1704, October 1994.
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[HM97] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, July 1997.
[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[IB93] John Ioannidis and Matt Blaze, "Architecture and
Implementation of Network-layer Security Under Unix",
Proceedings of USENIX Security Symposium, Santa Clara, CA,
October 1993.
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-
Layer Security for IP", presentation at the Spring 1993
IETF Meeting, Columbus, Ohio
[KA98a] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[Ken91] Kent, S., "US DoD Security Options for the Internet
Protocol", RFC 1108, November 1991.
[MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[Pip98] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John
Wiley & Sons, New York, NY, 1994.
[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, published in
NIST Publication NIST-IR-90-4250, February 1990.
[SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, August
1998.
[TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-
level Networks", ACM Computing Surveys, Vol. 15, No. 2,
June 1983.
Disclaimer
The views and specification expressed in this document are those of
the authors and are not necessarily those of their employers. The
authors and their employers specifically disclaim responsibility for
any problems arising from correct or incorrect implementation or use
of this design.
Author Information
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson
@Home Network
425 Broadway
Redwood City, CA 94063
USA
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
版权说明
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
RFC2401 Security Architecture for the Internet Protocol RFC2401 IP层协议安全结构
1
1
ＲＦＣ文档中文翻译计划