rfc4301翻译第五章到第八章.docx

rfc4301翻译第五章到第八章.docx

《rfc4301翻译第五章到第八章.docx》由会员分享，可在线阅读，更多相关《rfc4301翻译第五章到第八章.docx（10页珍藏版）》请在冰豆网上搜索。

rfc4301翻译第五章到第八章

5.IPTrafficProcessing

5.1.OutboundIPTrafficProcessing（protected-to-unprotected）

Figure2.ProcessingModelforOutboundTraffic

IPsecMUST按以下步骤来处理出方向的包：

Step1.当包从保护区接口进来，调用SPD选择功能来获得SPD-ID，用这个SPD-ID来选择合适的SPD。

（如果设备只需用一个SPD，那该步可以忽略）

Step2.用该包的头来匹配从第一步中得到的SPD的缓存。

注意这个缓存包含了SPD-O和SPD-S中的记录。

Step3.

a.如果匹配上，用匹配上的缓存记录来确定该包是要被透传、丢弃或是被AH/ESP保护。

如果IPsec处理应用后，就会产生一个从SPD缓存记录到SAD缓存记录的链接（用于指定模式、加密算法、密钥、SPI、PMTU等），注意SAPMTU值，和分配状态检查标志位（出方向包的IP头中的DF位）来决定是要在IPsec处理前分片还是处理后分片，或者必须丢弃掉用ICMPPMTU消息发送。

b.如果没有找到匹配的缓存，则查找SPD-ID指定的SPD（SPD-S和SPD-O部分）。

如果SPD记录说是要透传或是丢弃，那么就创建一个或多个新的出方向SPD缓存记录；如果SPD记录说是要保护，也就是说要创建一个SA，那么就要用密钥管理机制（如IKEv2）来生产一个SA，如果SA成功生成，就创建一条新的出方向（SPD-S）缓存记录以及出方向和入方向的SAD记录；如果不能成功生成SA，就丢弃这个包。

Step4.这个包被传送到出口转发功能，来选择包要出去的接口。

这个功能也许会使这个包被传回到IPsec边界，进行另外的IPsec处理，比如说支持嵌套SAs。

如果是这样，MUST在SPD-I数据库中有一条记录，允许入方向透传这个包，否则这个包将被丢弃。

5.1.1.HandlinganOutboundPacketThatMustBeDiscarded

如果出方向的包要被丢弃，那么SHOULD有能力产生并发生一个ICMP消息给发生方，来表明这个包已被丢弃。

丢弃原因需要记录在审计日志里。

审计日志应该包括原因、当前时间/日期、包中的选择器值。

ThetypeandcodeoftheICMP的设定如下：

a.与包的选择器匹配上的SPD要求丢弃这个包时：

IPv4Type=3（destinationunreachable）Code=13

（CommunicationAdministrativelyProhibited）

IPv6Type=1（destinationunreachable）Code=1

（Communicationwithdestinationadministratively

prohibited）

b1.IPsec系统成功到达对端，但是无法协商出SPD记录所需的SA来与包进行匹配时：

IPv4Type=3（destinationunreachable）Code=13

（CommunicationAdministrativelyProhibited）

IPv6Type=1（destinationunreachable）Code=1

（Communicationwithdestinationadministratively

prohibited）

b2.由于无法联系到交换中的另一端IPsec对等体，而导致IPsec系统无能建立SPD所需的SA来匹配这个包时：

IPv4Type=3（destinationunreachable）Code=1（host

unreachable）

IPv6Type=1（destinationunreachable）Code=3（address

unreachable）

注意当安全网关后的攻击者模仿从源地址W.X.Y.Z发包给IPsec实体，导致IPsec实体给真正的W.X.Y.Z发送ICMP消息。

这样就创建了一个机会，使得网关后的主机间受到denialofservice（DoS）攻击，所以，安全网关SHOULD有一个管理控制来允许管理员配置在这种情况下IPsecimplementation是否发送ICMP消息，如果这个机制被选择，就会大大限制这种ICMP响应的传输。

5.2.ProcessingInboundIPTraffic（unprotected-to-protected）

入方向的SPD缓存（SPD-I）只用于透传或丢弃传输量。

如果从非保护区接口来的包是IPsec分片，要在IPsec处理前重新组装。

（*）=缓存在这里。

如果没有命中缓存，那么就检查SPD。

如果没有命中缓存不要求实现缓存这个包。

（**）=这个处理包括用这个包的SPI等，在SAD中查找SA，形成了一个入方向包的SPD缓存。

见下面的step3a。

（***）=step4中涉及到的SAD检查。

在AH或ESP处理前，任何通过非保护区接口的IP分片都要被重新组装（byIP）。

IPsec处理将被应用于每个入方向的IP数据报，它被IPNextProtocol域中的AH或ESP值（或IPv6上下文中把AH或ESP当做一个nextlayerprotocol）来标识。

IPsec必须按以下步骤执行：

1.当一个包到达时，如果有必要支持多重SPD和SPD-I缓存关联，这个包可能会被它所到达的接口（physicalorvirtual）的ID打上标签，。

（TheinterfaceIDismappedtoacorrespondingSPD-ID.）

2.这个包被检测并分离成下面两类中的一种：

-如果这个包是要被IPsec保护的并且是发送给这台设备的，尝试通过SAD把它映射到一个活跃的SA。

注意这台设备可能会有多重IP地址，这些地址将被用于SAD的查找，如，在SCTP协议的情况下。

-如果通信量不是发送到这台设备的，或者是发送给这台设备的但是不是AH或ESP，直接进行SPD-I的查找。

（这暗示了IKE流量MUST在SPD有一个明确的BYPASS记录。

）如果用多重SPD，把第一步中的标签分配给这个包用于选择合适的SPD-I（和缓存）用来查找。

SPD-I的查找决定了这个包是要被丢弃或是透传。

3a.如果这个包要发送到IPsec设备，并且指定AH或ESP为协议，这个包在SAD中被查找。

对于单播通信量，只用SPD（或SPD+协议），对于组播通信量，用SPI+目的地址或SPI+目的地址和源地址，如4.1节描述。

如果没有匹配的，就丢弃。

这是一个审计事件，这个事件的审计日志SHOULD包含当前时间/日期，SPI，包的源和目的地址，IPsec协议，和其他这个包中可用的选择器值。

如果包在SAD中找到就按步骤4中描述进行处理。

3b.如果这个包不是发送到这台设备或是是发送到这台设备但是不是AH或ESP，在（合适的）SPD-I缓存中查找这个包的头。

如果匹配上，这个包被丢弃或透传。

如果没有缓存匹配，在correspondingSPD-I中查找这个包，并且创建一条适当的缓存记录。

（这种方式，接收到一个需要IPsec保护的包也不会创建SA，只能创建透传或丢弃缓存记录。

）如果没有匹配，丢弃这个通信量。

这是一个审计时间，应该记录当前时间或日期，可用的SPI，可用的IPsec协议，包的源和目的地址，和其他这个包中可用的选择器值。

3c.处理ICMP消息假定发生在IPsec边界的非保护端。

非保护ICMP消息被检查，并且本地策略被应用于决定是否接收或拒绝这些消息，如果接收作为结果采用什么行动。

如，如果一个不可达ICMP消息被接收，这个实现必须决定是否在其上采取行动或拒绝他，或有约束的行动。

（SeeSection6）

4.使用指定的AH或ESP，用step3a中选择的SAD记录。

然后用这个包和SAD记录指定的入方向选择器匹配，来验证这个接收到的包适用于这个SA，通过这个SA这个包被接收。

5.如果一个IPsec系统接收到一个SA上的入方向的包，这个包头域与SA选择器不一致，必须丢弃这个包。

这是一个审计时间，审计日志中需要记录当前时间，SPI，IPsec协议，包的源和目的地址，包中可用的任何其他选择器，和有关的SAD记录中的悬着器值。

系统应该可用生成或发送一个IKE通知INVALID_SELECTORS给发生者（IPsecpeer）这个接收到的包被丢弃的原因是没有通过选择器检查。

为了将DoS攻击或mis-configuredpeer减到最少，IPsec系统应该包含一个管理控制功能来允许管理员配置IPsec实现发送或不发送IKE通知，如果这个机制被选择就会限制传输这样的通知。

通信量被透传或通过IPsec处理后，要被入方向转发功能的处理。

这个功能可能会导致这个包发送到IPsec边界再做一次入方向IPsec处理。

如支持嵌套SA的情况就是这样。

然后就像所有出方向流量一样如果要被透传，这个包必须与SPD-O记录匹配。

最终这个包会被转发到目的主机或processfordisposition。

6.ICMPProcessing

有两种ICMP传输：

错误消息errormessages（e.g.,type=destinationunreachable）

非错误消息non-errormessages（e.g.,type=echo）

应该提供一个管理机制，允许管理员记录导致ICMP错误消息（selected,all,ornone）的原因来帮助定位诊断问题。

6.1.ProcessingICMPErrorMessagesDirectedtoanIPsecImplementation

6.1.1.ICMPErrorMessagesReceivedontheUnprotectedSideoftheBoundary

Figure3inSection5.2展示了一个明显的IPsec边界非保护端的ICMP处理模型，处理发送到IPsec设备的ICMP消息（errororotherwise），这些消息没有经过AH或ESP的保护。

这种ICMP消息是没有经过认证的，并且它的处理可能会导致拒绝或降低服务。

所以建议忽略这种消息。

然而，许多非源的ICMP消息将被主机或安全网关接收，如公网上的路由器。

忽略这些ICMP消息会降低服务，如处理PMTU消息失败和重定向消息。

因此仍然有接收ICMP消息的动机。

一个兼容的IPsec实现MUST允许一个本地管理员配置是要接收还是要拒绝非认证的ICMP流量。

这个控制必须是基于ICMPtype或ICMPcode和ICMPtype的。

另外一个实现还应该机制和参数来处理这样的流量。

如，可以有为通信量（onaperdestinationbasis）建立最小PMTU的能力用于阻止接收一个非认证ICMP不把PMTU设置为没有意义的大小。

如果上述的ICMPPMTU消息通过了，并且被配置后的系统接收了，有两种可能。

1.如果这个实现把分片应用在边界的密文一边（ciphertextside），那么这个被接收的PMTU信息被转发模块（outsideoftheIPsecimplementation）通过，这个转发模块用于管理出方向的包分片。

2.如果这个实现被配置为影响明文侧（plaintextside）的分片，那么这个PMTU信息被传到明文一侧并且如8.2节描述进行处理。

6.1.2.ICMPErrorMessagesReceivedontheProtectedSideoftheBoundary

这些ICMP消息没有被认证，但他们确实是来自IPsec边界的保护端。

主要的安全隐患是有一台被攻破的主机或路由器也许会发出错误的ICMP错误消息，这样也许会降低安全网关后其他设备的服务，或这会破坏机密性。

如一个安全网关用了一个假冒的ICMP重定向，可能会导致保护端转发表被修改，从而吧流量发送到一个网关后不适当的目的。

因此实现MUST提供允许本地管理员限制边界的保护端的ICMP错误消息的接收，指向这个IPsec实现。

如6.1.1中的描述，非保护端也需要这样的控制。

6.2.ProcessingProtected,TransitICMPErrorMessages

当一个ICMP错误消息通过一个SA传输到IPsec实现后的一台设备上时，在访问控制的角度来看，这个载荷和这个ICMP消息头要被检查。

IPsec实现MUST可以配置检查载荷头信息是否和载荷所到达的SA一致。

（意思是这个载荷头，与源和目的地址、反转的端口域一起，匹配SA的传输选择器。

）不是所有上下文都需要这个检查，所以有必要让本地管理员来配置是否实行这项检查。

为了适应所有（both）策略，采用下面的规定：

如果一个管理员想要允许ICMP错误消息不经过载荷检查就被一个SA携带，那么配置一个SPD记录表明要携带这样的传输量。

如果一个管理员想要IPsec来检查这个ICMP错误消息载荷的一致性，那么不创建任何SPD条目来携带这样的机遇ICMP包头的交通量。

这个规定促使了下面的处理。

IPsec发送者和接收者MUST支持如下ICMP错误消息的处理。

这些消息是通过SA被接收或发送的。

如果一个与出方向ICMP错误消息适应的SA存在，那么这个消息被映射到这个SA并且只有IP和ICMP头被检查，正如对其他流量一样。

如果不存在与关于ICMP错误消息的传输选择器匹配的SA，那么就查找SPD来决定是否要建立这样的一个SA。

如果建立了SA，那么这个ICMP错误消息就通过这个SA进行传输。

接收的时候，这个消息被接收者的常用的传输选择器的检查。

如果一个IPsec实现接收一个SA上的ICMP错误消息，这个消息的IP和ICMP头不与这个SA的传输选择器匹配，接收者MUST用特定的方式来处理这个接收到的消息。

具体的，接收者必须从ICMP载荷中抽出这个触发包的头和反转域如上面描述的那样来决定是否这个包和接收到ICMP错误码的SA的选择器相适应。

如果这个包检查失败，IPsec实现MUSTNOT转发这个ICMP消息到目的地。

这是一个审计事件。

7.HandlingFragments（ontheprotectedsideoftheIPsecboundary）

这节描述一个实现怎样处理IPsec分界线保护端的出方向明文分片的处理。

特别的，如下所述：

o把出方向non-initial分片映射到一个对的SA上。

（或者在对的SPD记录中查找）

o验证一个接收到的non-initial分片是否被接收它的SA认证。

o把出方向和入方向的non-initial分片映射到对的SPD-O或SPD-I记录上，或相应的缓存记录上，为了丢弃或透传流量。

注：

"non-trivial"被用来表示选择器的值为OPAQUE或ANY意外的值。

注：

"non-trivial"在这里被用于指明一个分片不包含访问控制可能需要的搜有选择器值。

如4.4.1节中所说，取决于NextLayerProtocol，除了端口，ICMP消息type/code或移动头类型可以被non-initial分片丢掉。

同样的，对于IPv6，尽管第一个分片可能不包含NextLayerProtocol或端口（orICMPmessagetype/code,orMobilityHeadertype）这是由现有的扩展头号和种类决定的。

如果一个non-initial分片包含了端口（orICMPtypeandcodeorMobilityHeadertype）但是不包含NextLayerProtocol，那么除非有一个SPD记录与Local/Remoteaddresses有关，WithANYfortheNextLayerProtocolandPort（orICMPtypeandcodeorMobilityHeadertype），这个分片不会包含所有访问控制所需的选择器信息。

为了描述以上问题，定义了3种方法：

o载有initial和non-initial分片的隧道模式SA（SeeSection7.1.）。

onon-initial分片各自的隧道模式SA（SeeSection7.2.）

o分片状态检查（SeeSection7.3.）

7.1.TunnelModeSAsthatCarryInitialandNon-InitialFragments

多有的实现MUST支持隧道模式SA，不考虑通过的传输量的portfield（orICMPtype/codeorMobilityHeadertype）的值。

如果这个SA携带的是指定协议的传输量，这个SA选择器的设置必须指定portfields（orICMPtype/codeorMobilityHeadertype）为ANY。

这种形式的一个SA将携带所有的传输量，包括initial和non-initial分片用于表示Local/RemoteaddressesandspecifiedNextLayerprotocol（s）。

如果SA携带传输量不考虑指定的协议值（（i.e.,ANYisspecified）来作为（NextLayer）协议选择器值），那么这个端口域值就为么有定义的并且MUST也被设为ANY。

（Asnotedin4.4.1,ANYincludesOPAQUEaswellasallspecificvalues.）

7.2.SeparateTunnelModeSAsforNon-InitialFragments

一个实现也许支持隧道模式SA，它只携带non-initial分片，把non-initial包和initial分片分开。

用OPAQUE值来标识一个携带这种分片的SA的port（orICMPtype/codeorMobilityHeadertype）fieldselectors。

接收者必须对IPv4（non-initial）分片执行一个最小偏移检查用于保护交叉分片攻击，当SA用这种类型的时候。

因为这种检查不能在IPv6non-initial分片上执行，为了安全起见，实现者也许会选择不在IPv6传输上支持这种SA。

同样的，一个这种SA将携带所有的与一个特定的Local/Remoteaddresspairandprotocolvalue匹配的non-initial分片，换言之，这个SA上携带的分片属于没有分片的包，这些分片可能属于不同的SA用于不同的安全。

因此，建议用户和管理员用ESP（withintegrity）和"strongest"完整性和加密算法来保护这个两个对等体间的通信流。

特定的port（orICMPtype/codeorMobilityHeadertype）selectorvalue将被用于定义携带initialfragments和non-fragmented包的SA。

这个可以被用于如果一个用户或管理员想要在同样的本地/对端地址间创建一个或多个隧道模式的SA，相同的地址用port（orICMPtype/codeorMobilityHeadertype）fields区别。

这些SA必须有non-trivialprotocolselectorvalues，否则要用上面的方法1.

7.3.StatefulFragmentChecking

实现将在一个传输模式SA上传输non-initial分片，用non-trivialport（orICMPtype/codeorMHtype）selectors必须通过IKENOTIFYNON_FIRST_FRAGMENTS_ALSO载荷通知给一个对等体。

接收者必须丢弃到达一个有non-trivialport（orICMPtype/codeorMHtype）selectorvalues的SA的non-initial分片，除非这个特性已经被协商了。

接收者也必须丢弃这样的non-initial分片，它不符合应用于整个包的安全策略。

丢弃这种包是一个审计事件。

注意在网络配置中的包的分片可能通过不同的安全网关或BITWimplementations,被发送或接收，跟踪分片的状态策略可能会失败。

7.4.BYPASS/DISCARDTraffic

透传一个明文，non-initial分片到一个IPsec实现上，会破坏指向相同目的的IPsec保护的流量的安全性。

在网络配置中的包的分片可能通过不同的安全网关或BITWimplementations,被发送或接收，跟踪分片的状态策略可能会失败。

8.PathMTU/DFProcessing

对出方向包的AH或ESP的应用会增加一个包的大小，这样可能会导致一个包的大小超出了传输这个包的SA的PMTU大小。

一个IPsec实现也可能接收一个非保护的ICMPPMTU消息，如果它选择处理这个消息，这将会影响出方向流量的处理，这节就是描述了一个IPsec实现怎么处理这两种PMTU问题。

8.1.DFBit

所有的IPsec实现必须支持DF位从一个出方向包复制到传输它的隧道模式头。

当一个传输量被一个隧道模式SA携带时，这意味着它必须可以为每个SA配置实现的DF位的处理（set,clear,copyfrominnerheader），这个应用于内部头和外部头都为IPv4的SA。

8.2.PathMTU（PMTU）Discovery

这节讨论IPsec处理非保护的PathMTUDiscovery消息。

这里用到的ICMPPMTU引用一个ICMP消息为：

IPv4（RFC792[Pos81b]）:

-Type=3（DestinationUnreachable）

-Code=4（FragmentationneededandDFset）

-Next-HopMTUinthelow-order16bitsofthe

secondwordoftheICMPheader（labeled"unused"

inRFC792）,withhigh-order16bitssettozero）

IPv6（RFC2463[CD98]）:

-Type=2（PacketTooBig）

-Code=0（Fragmentationneeded）

-Next-HopMTUinthe32-bitMTUfieldoftheICMP6

message

8.2.1.PropagationofPMTU

当一个IPsec实现接收到一个没有认证的PMTU消息，并且它被配置为处理（而不是忽略）这样的消息，它把这个消息映射到它对应的SA。

这个消息决定的PMTU被用于更新SADPMTU域，考虑到应用于AH或ESP头的大小，任何加密同步数据和一个强加的额外的IP头，在隧道模式SA的情况下。

对于所