rfc2406.txt

很多RFC的中文文档

必须作为非法而将接收的IP数据报丢弃；这是可审核事件。日志数据应该包括SPI值、接收的
日期/时间、源地址、目的地址、序列号和（IPv6中）明文信息流ID。

   讨论：

      从删除和保存ICV值（验证数据字段）开始。下一个检查除去验证数据字段之后的ESP
整个长度。如果由于验证算法的块大小而要求隐式填充，把0填充的字节直接附加到下一个头字
段之后的ESP分组尾部。执行ICV计算，采用算法规范定义的比较规则来把结果与保存的值比
较。（例如，如果ICV计算采用数字签名和单向散列，匹配过程更复杂。）

3.4.5  分组解密

   在3.3.2节“分组加密”中，由于格式化的含意，在那里我们依据经常采用的加密讲述。需要
理解使用NULL加密算法提供“非机密性”。因此，接收方：

       1. 采用SA指明的密钥、加密算法、算法模式和加密同步数据（如果存在）解密ESP有
效载荷数据、填充、填充长度和下一个头。
       - 如果指明显式加密同步数据，例如IV，则从有效载荷字段得到加密同步数据，并按照
算法规范将其输入到解密算法中。
       - 如果指明是隐式加密同步数据，例如IV，则构建本地版本IV，并按照算法规范将其输
入到解密算法中。
       2.处理所有加密算法规范中指定的填充。如果采用默认的填充方案（参看2.4节），接收
方应该在把已解密数据传送给下一层之前，以及删除填充之前，检查填充字段。
         
       3. 重新构建原始IP数据报，利用：reconstructs the original IP datagram from:
        -传送模式—原始IP头和ESP有效载荷字段中原始上层协议信息                                                 
- 隧道模式 – 隧道IP头+ESP有效载荷字段中整个IP数据报。

   重新构建原始数据报的确切步骤依赖于模式（传送或者隧道），在安全架构文档中描述。最小
程度上，IPv6环境中，接收方应该确保已解密数据是8字节对齐，使下一个头字段标识的协议
更容易进行处理。

   如果选择验证，确认和解密可以逐个或者并行实现。如果逐个实现，那么ICV验证应该首先
执行。如果并行执行，验证必须在已解密分组被传递进行更进一步处理之前完成。这种处理顺序
利于在解密分组之前，接收方迅速检测和重播分组或伪造分组拒绝，因此潜在地降低了服务拒绝
攻击的影响。

   注意：如果接收方执行解密且与验证并行，小心避免对分组访问和已解密分组重构可能的竞
争条件。

   注意解密“失败”的几种情形：Note that there are several ways in which the decryption can "fail":

        a. 已选择的SA可能不正确—由于SPI，目的地址或者IPsec协议类型字段被篡改而错
误地选择了SA。如果这样的错误把分组映射到另一个现存的SA，则它们将无法辨别已被破坏
的分组，（c情况）。篡改SPI可以通过验证的使用而被检测出来。但是，由于IP目的地址或者
IPsec协议类型字段被篡改，SA不匹配仍然可能发生。

        b. 填充长度或者填充值可能是错误的—不管是否进行验证，错误的填充长度或者填充
值可以被检测出来。

        c. 已加密的ESP分组可能被破坏—如果SA选择进行验证，这可以检测出来。

   在 (a) 或者 (c)情况下，解密操作的错误结果（一个非法IP数据报或者传送层帧）将不必要
被IPsec检测出来，这是后面协议处理的责任。

4.  审核

   不是所有实现ESP的系统实现审核。但是，如果把ESP合并到一个支持审核的系统中，那么
ESP实现必须支持审核，必须允许系统管理员激活或者禁止ESP审核。大部分而言，审核的粒
度是本地的问题。然而，本规范中标识了几个可审核事件，对于这些事件中的每一个，定义了应
该包含在审核日志中的一组最少信息，当然也可以包含额外的信息。本规范中没有明确指出的额
外事件也可以产生审核日志表项。
   
   这里没有要求接收方把任何信息传送给声称的发送方响应审核事件的检测，因为这样做可能
导致服务拒绝。

5.  一致性要求

   要求与本规范一致性或者顺应性的实现必须实现ESP语法和这里描述的处理过程，它必须遵
照安全架构文档的所有要求。如果计算ICV使用的密钥手工分发，抗重播服务的正确提供要求
发送方计数器状态的正确维护，直到密钥更新，如果计数器溢出即将发生，有可能没有自动恢复
措施。因此一个顺应实现不应该与手工键入的SA联合来提供抗重播服务。一个顺应ESP实现必
须支持下列强制实现的算法：

             - CBC模式的DES [MD97]
             - HMAC - MD5 [MG97a]
             - HMAC - SHA-1 [MG97b]
             - NULL 验证算法
             - NULL 加密算法

   因为ESP加密和验证是可选的，对两个“NULL”算法的支持要求维护与协商这些服务的方
式的一致性。注意验证和加密可以单独是“NULL”，但是不允许两者同时是“NULL”。

6. 安全考虑事项

   安全是这个协议设计的中心，因此安全考虑事项贯穿整个规范。使用IPsec协议额外的安全
相关内容在安全架构文档中讨论。

7.  与 RFC 1827的不同

   本文档在几个重要方面不同与RFC 1827 [ATK95] 。主要的不同是，本文档试图为ESP指定
一个完整的框架和上下文，而RFC 1827提供了一个“shell”，通过转换的定义来完善。转换的增
加促进ESP规范重新完善为一个更全面的文档，加入ESP上下文中提供的安全服务选项。因此，
之前在转换文档中定义的字段现在是该基础ESP规范的一部分。例如，用于支持验证（和抗重
播）的字段现在这里定义，即使该服务是可选项。
    
   支持加密的填充字段和下一个协议验证的填充字段现在也在此定义。与这些字段定义一致的
分组处理也包含在文档中。.

致谢

   Many of the concepts embodied in this specification were derived from
   or influenced by the US Government's SP3 security protocol, ISO/IEC's
   NLSP, or from the proposed swIPe security protocol.  [SDNS89, ISO92,
   IB93].

   For over 3 years, this document has evolved through multiple versions
   and iterations.  During this time, many people have contributed
   significant ideas and energy to the process and the documents
   themselves.  The authors would like to thank Karen Seo for providing
   extensive help in the review, editing, background research, and
   coordination for this version of the specification.  The authors
   would also like to thank the members of the IPsec and IPng working
   groups, with special mention of the efforts of (in alphabetic order):
   Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David
   Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina
   Yuan.

参考书目

   [ATK95]   Atkinson, R., "IP Encapsulating Security Payload (ESP)",
             RFC 1827, August 1995.

   [Bel96]   Steven M. Bellovin, "Problem Areas for the IP Security
             Protocols", Proceedings of the Sixth Usenix Unix Security
             Symposium, July, 1996.

   [Bra97]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Level", BCP 14, RFC 2119, March 1997.

   [HC98]    Harkins, D., and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

   [IB93]    John Ioannidis & Matt Blaze, "Architecture and
             Implementation of Network-layer Security Under Unix",
             Proceedings of the USENIX Security Symposium, Santa Clara,
             CA, October 1993.

   [ISO92]   ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
             DIS 11577, International Standards Organisation, Geneva,
             Switzerland, 29 November 1992.

   [KA97a]   Kent, S., and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [KA97b]   Kent, S., and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

   [MD97]    Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
             Algorithm With Explicit IV", RFC 2405, November 1998.

   [MG97a]   Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
             ESP and AH", RFC 2403, November 1998.

   [MG97b]   Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
             ESP and AH", RFC 2404, November 1998.

   [STD-2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
             1700, October 1994.  See also:
             http://www.iana.org/numbers.html

   [SDNS89]  SDNS Secure Data Network System, Security Protocol 3, SP3,
             Document SDN.301, Revision 1.5, 15 May 1989, as published
             in NIST Publication NIST-IR-90-4250, February 1990.

Disclaimer

   The views and specification here 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
   specification.

作者信息

   Stephen Kent
   BBN Corporation
   70 Fawcett Street
   Cambridge, MA  02140
   USA

   Phone: [phone]
   EMail: [e-mail]

   Randall Atkinson
   @Home Network
   425 Broadway,
   Redwood City, CA  94063
   USA

   Phone: [phone]
   EMail: [e-mail]

Full Copyright Statement

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

   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.

 
[ Index | Search | What's New | Comments | Help ] 
RFC 2406 IP Encapsulating Security Payload (ESP)                  IP 封装安全有效载荷 (ESP)


1
RFC文档中文翻译计划