rfc2401.txt

283个中文RFC文档

* 认证算法使用多个密钥
* 加密算法和认证算法都被使用
密钥管理系统为每一个密钥提供了一个独立的比特串，或者生成一个比特串，所有密钥都从其中取出。如果提供一个单一比特串，则需要保证：将比特串映射到密钥的系统部分在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，与