RFC4303 日本語訳
4303 IP Encapsulating Security Payload (ESP). S. Kent. December 2005. (Format: TXT=114315 bytes) (Obsoletes RFC2406) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Kent Request for Comments: 4303 BBN Technologies Obsoletes: 2406 December 2005 Category: Standards Track
Network Working Group S. Kent Request for Comments: 4303 BBN Technologies Obsoletes: 2406 December 2005 Category: Standards Track
IP Encapsulating Security Payload (ESP)
IP Encapsulating Security Payload (ESP)
Status of This Memo
Status of This Memo
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.
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 Notice
Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
Abstract
Abstract
This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998).
This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998).
Table of Contents
Table of Contents
1. Introduction ....................................................3
2. Encapsulating Security Payload Packet Format ....................5
2.1. Security Parameters Index (SPI) ...........................10
2.2. Sequence Number ...........................................12
2.2.1. Extended (64-bit) Sequence Number ..................12
2.3. Payload Data ..............................................13
2.4. Padding (for Encryption) ..................................14
2.5. Pad Length ................................................15
2.6. Next Header ...............................................16
2.7. Traffic Flow Confidentiality (TFC) Padding ................17
2.8. Integrity Check Value (ICV) ...............................17
3. Encapsulating Security Protocol Processing .....................18
3.1. ESP Header Location .......................................18
3.1.1. Transport Mode Processing ..........................18
3.1.2. Tunnel Mode Processing .............................19
1. Introduction ....................................................3 2. Encapsulating Security Payload Packet Format ....................5 2.1. Security Parameters Index (SPI) ...........................10 2.2. Sequence Number ...........................................12 2.2.1. Extended (64-bit) Sequence Number ..................12 2.3. Payload Data ..............................................13 2.4. Padding (for Encryption) ..................................14 2.5. Pad Length ................................................15 2.6. Next Header ...............................................16 2.7. Traffic Flow Confidentiality (TFC) Padding ................17 2.8. Integrity Check Value (ICV) ...............................17 3. Encapsulating Security Protocol Processing .....................18 3.1. ESP Header Location .......................................18 3.1.1. Transport Mode Processing ..........................18 3.1.2. Tunnel Mode Processing .............................19
Kent Standards Track [Page 1] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 1] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
3.2. Algorithms ................................................20
3.2.1. Encryption Algorithms ..............................21
3.2.2. Integrity Algorithms ...............................21
3.2.3. Combined Mode Algorithms ...........................22
3.3. Outbound Packet Processing ................................22
3.3.1. Security Association Lookup ........................22
3.3.2. Packet Encryption and Integrity Check Value
(ICV) Calculation ..................................22
3.3.2.1. Separate Confidentiality and
Integrity Algorithms ......................23
3.3.2.2. Combined Confidentiality and
Integrity Algorithms ......................24
3.3.3. Sequence Number Generation .........................25
3.3.4. Fragmentation ......................................26
3.4. Inbound Packet Processing .................................27
3.4.1. Reassembly .........................................27
3.4.2. Security Association Lookup ........................27
3.4.3. Sequence Number Verification .......................28
3.4.4. Integrity Check Value Verification .................30
3.4.4.1. Separate Confidentiality and
Integrity Algorithms ......................30
3.4.4.2. Combined Confidentiality and
Integrity Algorithms ......................32
4. Auditing .......................................................33
5. Conformance Requirements .......................................34
6. Security Considerations ........................................34
7. Differences from RFC 2406 ......................................34
8. Backward-Compatibility Considerations ..........................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
Appendix A: Extended (64-bit) Sequence Numbers ....................38
A1. Overview ...................................................38
A2. Anti-Replay Window .........................................38
A2.1. Managing and Using the Anti-Replay Window ............39
A2.2. Determining the Higher-Order Bits (Seqh) of the
Sequence Number ......................................40
A2.3. Pseudo-Code Example ..................................41
A3. Handling Loss of Synchronization due to Significant
Packet Loss ................................................42
A3.1. Triggering Re-synchronization ........................43
A3.2. Re-synchronization Process ...........................43
3.2. Algorithms ................................................20 3.2.1. Encryption Algorithms ..............................21 3.2.2. Integrity Algorithms ...............................21 3.2.3. Combined Mode Algorithms ...........................22 3.3. Outbound Packet Processing ................................22 3.3.1. Security Association Lookup ........................22 3.3.2. Packet Encryption and Integrity Check Value (ICV) Calculation ..................................22 3.3.2.1. Separate Confidentiality and Integrity Algorithms ......................23 3.3.2.2. Combined Confidentiality and Integrity Algorithms ......................24 3.3.3. Sequence Number Generation .........................25 3.3.4. Fragmentation ......................................26 3.4. Inbound Packet Processing .................................27 3.4.1. Reassembly .........................................27 3.4.2. Security Association Lookup ........................27 3.4.3. Sequence Number Verification .......................28 3.4.4. Integrity Check Value Verification .................30 3.4.4.1. Separate Confidentiality and Integrity Algorithms ......................30 3.4.4.2. Combined Confidentiality and Integrity Algorithms ......................32 4. Auditing .......................................................33 5. Conformance Requirements .......................................34 6. Security Considerations ........................................34 7. Differences from RFC 2406 ......................................34 8. Backward-Compatibility Considerations ..........................35 9. Acknowledgements ...............................................36 10. References ....................................................36 10.1. Normative References .....................................36 10.2. Informative References ...................................37 Appendix A: Extended (64-bit) Sequence Numbers ....................38 A1. Overview ...................................................38 A2. Anti-Replay Window .........................................38 A2.1. Managing and Using the Anti-Replay Window ............39 A2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number ......................................40 A2.3. Pseudo-Code Example ..................................41 A3. Handling Loss of Synchronization due to Significant Packet Loss ................................................42 A3.1. Triggering Re-synchronization ........................43 A3.2. Re-synchronization Process ...........................43
Kent Standards Track [Page 2] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 2] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
1. Introduction
1. Introduction
This document assumes that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Ken-Arch], hereafter referred to as the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by the Encapsulating Security Payload (ESP) and the IP Authentication Header (AH), the concept of Security Associations, the ways in which ESP can be used in conjunction with AH, and the different key management options available for ESP and AH.
This document assumes that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Ken-Arch], hereafter referred to as the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by the Encapsulating Security Payload (ESP) and the IP Authentication Header (AH), the concept of Security Associations, the ways in which ESP can be used in conjunction with AH, and the different key management options available for ESP and AH.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6 [DH98]. ESP may be applied alone, in combination with AH [Ken-AH], or in a nested fashion (see the Security Architecture document [Ken-Arch]). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [Ken-Arch].
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6 [DH98]. ESP may be applied alone, in combination with AH [Ken-AH], or in a nested fashion (see the Security Architecture document [Ken-Arch]). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [Ken-Arch].
The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below.
The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below.
ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology.
ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology.
Using encryption-only for confidentiality is allowed by ESP. However, it should be noted that in general, this will provide defense only against passive attackers. Using encryption without a strong integrity mechanism on top of it (either in ESP or separately via AH) may render the confidentiality service insecure against some forms of active attacks [Bel96, Kra01]. Moreover, an underlying integrity service, such as AH, applied before encryption does not necessarily protect the encryption-only confidentiality against active attackers [Kra01]. ESP allows encryption-only SAs because this may offer considerably better performance and still provide
Using encryption-only for confidentiality is allowed by ESP. However, it should be noted that in general, this will provide defense only against passive attackers. Using encryption without a strong integrity mechanism on top of it (either in ESP or separately via AH) may render the confidentiality service insecure against some forms of active attacks [Bel96, Kra01]. Moreover, an underlying integrity service, such as AH, applied before encryption does not necessarily protect the encryption-only confidentiality against active attackers [Kra01]. ESP allows encryption-only SAs because this may offer considerably better performance and still provide
Kent Standards Track [Page 3] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 3] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
adequate security, e.g., when higher-layer authentication/integrity protection is offered independently. However, this standard does not require ESP implementations to offer an encryption-only service.
adequate security, e.g., when higher-layer authentication/integrity protection is offered independently. However, this standard does not require ESP implementations to offer an encryption-only service.
Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity". (This term is employed because, on a per-packet basis, the computation being performed provides connectionless integrity directly; data origin authentication is provided indirectly as a result of binding the key used to verify the integrity to the identity of the IPsec peer. Typically, this binding is effected through the use of a shared, symmetric key.) Integrity-only ESP MUST be offered as a service selection option, e.g., it must be negotiable in SA management protocols and MUST be configurable via management interfaces. Integrity-only ESP is an attractive alternative to AH in many contexts, e.g., because it is faster to process and more amenable to pipelining in many implementations.
Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity". (This term is employed because, on a per-packet basis, the computation being performed provides connectionless integrity directly; data origin authentication is provided indirectly as a result of binding the key used to verify the integrity to the identity of the IPsec peer. Typically, this binding is effected through the use of a shared, symmetric key.) Integrity-only ESP MUST be offered as a service selection option, e.g., it must be negotiable in SA management protocols and MUST be configurable via management interfaces. Integrity-only ESP is an attractive alternative to AH in many contexts, e.g., because it is faster to process and more amenable to pipelining in many implementations.
Although confidentiality and integrity can be offered independently, ESP typically will employ both services, i.e., packets will be protected with regard to confidentiality and integrity. Thus, there are three possible ESP security service combinations involving these services:
Although confidentiality and integrity can be offered independently, ESP typically will employ both services, i.e., packets will be protected with regard to confidentiality and integrity. Thus, there are three possible ESP security service combinations involving these services:
- confidentiality-only (MAY be supported)
- integrity only (MUST be supported)
- confidentiality and integrity (MUST be supported)
- confidentiality-only (MAY be supported) - integrity only (MUST be supported) - confidentiality and integrity (MUST be supported)
The anti-replay service may be selected for an SA only if the integrity service is selected for that SA. The selection of this service is solely at the discretion of the receiver and thus need not be negotiated. However, to make use of the Extended Sequence Number feature in an interoperable fashion, ESP does impose a requirement on SA management protocols to be able to negotiate this feature (see Section 2.2.1 below).
The anti-replay service may be selected for an SA only if the integrity service is selected for that SA. The selection of this service is solely at the discretion of the receiver and thus need not be negotiated. However, to make use of the Extended Sequence Number feature in an interoperable fashion, ESP does impose a requirement on SA management protocols to be able to negotiate this feature (see Section 2.2.1 below).
The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in a fashion that conceals the ultimate source and destination addresses of correspondents, e.g., in tunnel mode between security gateways, and only if sufficient traffic flows between IPsec peers (either naturally or as a result of generation of masking traffic) to conceal the characteristics of specific, individual subscriber traffic flows. (ESP may be employed as part of a higher-layer TFC system, e.g., Onion Routing [Syverson], but such systems are outside the scope of this standard.) New TFC features present in ESP facilitate efficient generation and discarding of dummy traffic and better padding of real traffic, in a backward- compatible fashion.
The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in a fashion that conceals the ultimate source and destination addresses of correspondents, e.g., in tunnel mode between security gateways, and only if sufficient traffic flows between IPsec peers (either naturally or as a result of generation of masking traffic) to conceal the characteristics of specific, individual subscriber traffic flows. (ESP may be employed as part of a higher-layer TFC system, e.g., Onion Routing [Syverson], but such systems are outside the scope of this standard.) New TFC features present in ESP facilitate efficient generation and discarding of dummy traffic and better padding of real traffic, in a backward- compatible fashion.
Kent Standards Track [Page 4] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 4] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Section 7 provides a brief review of the differences between this document and RFC 2406.
Section 7 provides a brief review of the differences between this document and RFC 2406.
2. Encapsulating Security Payload Packet Format
2. Encapsulating Security Payload Packet Format
The (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the ESP header SHALL contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web page at http://www.iana.org/assignments/protocol-numbers). Figure 1 illustrates the top-level format of an ESP packet. The packet begins with two 4-byte fields (Security Parameters Index (SPI) and Sequence Number). Following these fields is the Payload Data, which has substructure that depends on the choice of encryption algorithm and mode, and on the use of TFC padding, which is examined in more detail later. Following the Payload Data are Padding and Pad Length fields, and the Next Header field. The optional Integrity Check Value (ICV) field completes the packet.
The (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the ESP header SHALL contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web page at http://www.iana.org/assignments/protocol-numbers). Figure 1 illustrates the top-level format of an ESP packet. The packet begins with two 4-byte fields (Security Parameters Index (SPI) and Sequence Number). Following these fields is the Payload Data, which has substructure that depends on the choice of encryption algorithm and mode, and on the use of TFC padding, which is examined in more detail later. Following the Payload Data are Padding and Pad Length fields, and the Next Header field. The optional Integrity Check Value (ICV) field completes the packet.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |ered* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |ered* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Top-Level Format of an ESP Packet
Figure 1. Top-Level Format of an ESP Packet
* If included in the Payload field, cryptographic synchronization
data, e.g., an Initialization Vector (IV, see Section 2.3),
usually is not encrypted per se, although it often is referred
to as being part of the ciphertext.
* If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext.
Kent Standards Track [Page 5] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 5] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
The (transmitted) ESP trailer consists of the Padding, Pad Length, and Next Header fields. Additional, implicit ESP trailer data (which is not transmitted) is included in the integrity computation, as described below.
The (transmitted) ESP trailer consists of the Padding, Pad Length, and Next Header fields. Additional, implicit ESP trailer data (which is not transmitted) is included in the integrity computation, as described below.
If the integrity service is selected, the integrity computation encompasses the SPI, Sequence Number, Payload Data, and the ESP trailer (explicit and implicit).
If the integrity service is selected, the integrity computation encompasses the SPI, Sequence Number, Payload Data, and the ESP trailer (explicit and implicit).
If the confidentiality service is selected, the ciphertext consists of the Payload Data (except for any cryptographic synchronization data that may be included) and the (explicit) ESP trailer.
If the confidentiality service is selected, the ciphertext consists of the Payload Data (except for any cryptographic synchronization data that may be included) and the (explicit) ESP trailer.
As noted above, the Payload Data may have substructure. An encryption algorithm that requires an explicit Initialization Vector (IV), e.g., Cipher Block Chaining (CBC) mode, often prefixes the Payload Data to be protected with that value. Some algorithm modes combine encryption and integrity into a single operation; this document refers to such algorithm modes as "combined mode algorithms". Accommodation of combined mode algorithms requires that the algorithm explicitly describe the payload substructure used to convey the integrity data.
As noted above, the Payload Data may have substructure. An encryption algorithm that requires an explicit Initialization Vector (IV), e.g., Cipher Block Chaining (CBC) mode, often prefixes the Payload Data to be protected with that value. Some algorithm modes combine encryption and integrity into a single operation; this document refers to such algorithm modes as "combined mode algorithms". Accommodation of combined mode algorithms requires that the algorithm explicitly describe the payload substructure used to convey the integrity data.
Some combined mode algorithms provide integrity only for data that is encrypted, whereas others can provide integrity for some additional data that is not encrypted for transmission. Because the SPI and Sequence Number fields require integrity as part of the integrity service, and they are not encrypted, it is necessary to ensure that they are afforded integrity whenever the service is selected, regardless of the style of combined algorithm mode employed.
Some combined mode algorithms provide integrity only for data that is encrypted, whereas others can provide integrity for some additional data that is not encrypted for transmission. Because the SPI and Sequence Number fields require integrity as part of the integrity service, and they are not encrypted, it is necessary to ensure that they are afforded integrity whenever the service is selected, regardless of the style of combined algorithm mode employed.
When any combined mode algorithm is employed, the algorithm itself is expected to return both decrypted plaintext and a pass/fail indication for the integrity check. For combined mode algorithms, the ICV that would normally appear at the end of the ESP packet (when integrity is selected) may be omitted. When the ICV is omitted and integrity is selected, it is the responsibility of the combined mode algorithm to encode within the Payload Data an ICV-equivalent means of verifying the integrity of the packet.
When any combined mode algorithm is employed, the algorithm itself is expected to return both decrypted plaintext and a pass/fail indication for the integrity check. For combined mode algorithms, the ICV that would normally appear at the end of the ESP packet (when integrity is selected) may be omitted. When the ICV is omitted and integrity is selected, it is the responsibility of the combined mode algorithm to encode within the Payload Data an ICV-equivalent means of verifying the integrity of the packet.
If a combined mode algorithm offers integrity only to data that is encrypted, it will be necessary to replicate the SPI and Sequence Number as part of the Payload Data.
If a combined mode algorithm offers integrity only to data that is encrypted, it will be necessary to replicate the SPI and Sequence Number as part of the Payload Data.
Finally, a new provision is made to insert padding for traffic flow confidentiality after the Payload Data and before the ESP trailer. Figure 2 illustrates this substructure for Payload Data. (Note: This
Finally, a new provision is made to insert padding for traffic flow confidentiality after the Payload Data and before the ESP trailer. Figure 2 illustrates this substructure for Payload Data. (Note: This
Kent Standards Track [Page 6] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 6] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
diagram shows bits-on-the-wire. So even if extended sequence numbers are being used, only 32 bits of the Sequence Number will be transmitted (see Section 2.2.1).)
diagram shows bits-on-the-wire. So even if extended sequence numbers are being used, only 32 bits of the Sequence Number will be transmitted (see Section 2.2.1).)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | IV (optional) | ^ p +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a | Rest of Payload Data (variable) | | y ~ ~ | l | | | o + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a | | TFC Padding * (optional, variable) | v d +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Substructure of Payload Data
Figure 2. Substructure of Payload Data
* If tunnel mode is being used, then the IPsec implementation
can add Traffic Flow Confidentiality (TFC) padding (see
Section 2.4) after the Payload Data and before the Padding
(0-255 bytes) field.
* If tunnel mode is being used, then the IPsec implementation can add Traffic Flow Confidentiality (TFC) padding (see Section 2.4) after the Payload Data and before the Padding (0-255 bytes) field.
If a combined algorithm mode is employed, the explicit ICV shown in Figures 1 and 2 may be omitted (see Section 3.3.2.2 below). Because algorithms and modes are fixed when an SA is established, the detailed format of ESP packets for a given SA (including the Payload Data substructure) is fixed, for all traffic on the SA.
If a combined algorithm mode is employed, the explicit ICV shown in Figures 1 and 2 may be omitted (see Section 3.3.2.2 below). Because algorithms and modes are fixed when an SA is established, the detailed format of ESP packets for a given SA (including the Payload Data substructure) is fixed, for all traffic on the SA.
The tables below refer to the fields in the preceding figures and illustrate how several categories of algorithmic options, each with a different processing model, affect the fields noted above. The processing details are described in later sections.
The tables below refer to the fields in the preceding figures and illustrate how several categories of algorithmic options, each with a different processing model, affect the fields noted above. The processing details are described in later sections.
Kent Standards Track [Page 7] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 7] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Table 1. Separate Encryption and Integrity Algorithms
Table 1. Separate Encryption and Integrity Algorithms
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M Y plain
Seq# (low-order bits) 4 M Y plain p
------ a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher[3] |-l
TFC padding [4] variable O Y Y cipher[3] | o
------ a
Padding 0-255 M Y Y cipher[3] d
Pad Length 1 M Y Y cipher[3]
Next Header 1 M Y Y cipher[3]
Seq# (high-order bits) 4 if ESN [5] Y not xmtd
ICV Padding variable if need Y not xmtd
ICV variable M [6] plain
What What What # of Requ'd Encrypt Integ is bytes [1] Covers Covers Xmtd ------ ------ ------ ------ ------ SPI 4 M Y plain Seq# (low-order bits) 4 M Y plain p ------ a IV variable O Y plain | y IP datagram [2] variable M or D Y Y cipher[3] |-l TFC padding [4] variable O Y Y cipher[3] | o ------ a Padding 0-255 M Y Y cipher[3] d Pad Length 1 M Y Y cipher[3] Next Header 1 M Y Y cipher[3] Seq# (high-order bits) 4 if ESN [5] Y not xmtd ICV Padding variable if need Y not xmtd ICV variable M [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] ciphertext if encryption has been selected
[4] Can be used only if payload specifies its "real" length
[5] See section 2.2.1
[6] mandatory if a separate integrity algorithm is used
[1] M = mandatory; O = optional; D = dummy [2] If tunnel mode -> IP datagram If transport mode -> next header and data [3] ciphertext if encryption has been selected [4] Can be used only if payload specifies its "real" length [5] See section 2.2.1 [6] mandatory if a separate integrity algorithm is used
Kent Standards Track [Page 8] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 8] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Table 2. Combined Mode Algorithms
Table 2. Combined Mode Algorithms
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M plain
Seq# (low-order bits) 4 M plain p
--- a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher |-l
TFC padding [3] variable O Y Y cipher | o
--- a
Padding 0-255 M Y Y cipher d
Pad Length 1 M Y Y cipher
Next Header 1 M Y Y cipher
Seq# (high-order bits) 4 if ESN [4] Y [5]
ICV Padding variable if need Y [5]
ICV variable O [6] plain
What What What # of Requ'd Encrypt Integ is bytes [1] Covers Covers Xmtd ------ ------ ------ ------ ------ SPI 4 M plain Seq# (low-order bits) 4 M plain p --- a IV variable O Y plain | y IP datagram [2] variable M or D Y Y cipher |-l TFC padding [3] variable O Y Y cipher | o --- a Padding 0-255 M Y Y cipher d Pad Length 1 M Y Y cipher Next Header 1 M Y Y cipher Seq# (high-order bits) 4 if ESN [4] Y [5] ICV Padding variable if need Y [5] ICV variable O [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] Can be used only if payload specifies its "real" length
[4] See Section 2.2.1
[5] The algorithm choices determines whether these are
transmitted, but in either case, the result is invisible
to ESP
[6] The algorithm spec determines whether this field is
present
[1] M = mandatory; O = optional; D = dummy [2] If tunnel mode -> IP datagram If transport mode -> next header and data [3] Can be used only if payload specifies its "real" length [4] See Section 2.2.1 [5] The algorithm choices determines whether these are transmitted, but in either case, the result is invisible to ESP [6] The algorithm spec determines whether this field is present
The following subsections describe the fields in the header format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of an ICV (see Section 2.7). Whether or not an option is selected is determined as part of Security Association (SA) establishment. Thus, the format of ESP packets for a given SA is fixed, for the duration of the SA. In contrast, "mandatory" fields are always present in the ESP packet format, for all SAs.
The following subsections describe the fields in the header format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of an ICV (see Section 2.7). Whether or not an option is selected is determined as part of Security Association (SA) establishment. Thus, the format of ESP packets for a given SA is fixed, for the duration of the SA. In contrast, "mandatory" fields are always present in the ESP packet format, for all SAs.
Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix of RFC 791 [Pos81]) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order.
Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix of RFC 791 [Pos81]) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order.
Kent Standards Track [Page 9] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 9] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
ESP does not contain a version number, therefore if there are concerns about backward compatibility, they MUST be addressed by using a signaling mechanism between the two IPsec peers to ensure compatible versions of ESP (e.g., Internet Key Exchange (IKEv2) [Kau05]) or an out-of-band configuration mechanism.
ESP does not contain a version number, therefore if there are concerns about backward compatibility, they MUST be addressed by using a signaling mechanism between the two IPsec peers to ensure compatible versions of ESP (e.g., Internet Key Exchange (IKEv2) [Kau05]) or an out-of-band configuration mechanism.
2.1. Security Parameters Index (SPI)
2.1. Security Parameters Index (SPI)
The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. The SPI field is mandatory.
The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. The SPI field is mandatory.
For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Because the SPI value is generated by the receiver for a unicast SA, whether the value is sufficient to identify an SA by itself or whether it must be used in conjunction with the IPsec protocol value is a local matter. This mechanism for mapping inbound traffic to unicast SAs MUST be supported by all ESP implementations.
ユニキャストにおいて、SAを指定するのにSA、SPIをそれ自体で使用できますか、またはそれはIPsecプロトコルタイプ(この場合超能力)に関連して使用されるかもしれません。 SA、SPI値がユニキャストのために受信機によって生成されるので、値自体がSAを特定できるかどうかくらいIPsecプロトコル価値に関連してそれを使用しなければならないかどうかが、地域にかかわる事柄です。 すべての超能力実装でユニキャストSAsにインバウンドトラフィックを写像するためのこのメカニズムをサポートしなければなりません。
If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.
IPsec実装がマルチキャストをサポートするなら、本国行きのIPsecデータグラムをSAsに写像するのに以下のアルゴリズムを使用して、それは、マルチキャストがSAsであるとサポートしなければなりません。 ユニキャストトラフィックだけをサポートする実装はこの逆多重化アルゴリズムを実装する必要はありません。
In many secure multicast architectures (e.g., [RFC3740]), a central Group Controller/Key Server unilaterally assigns the group security association's SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that comprise the group. Consequently, it is possible that a group security association and a unicast security association can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions.
多くの安全なマルチキャストアーキテクチャ(例えば、[RFC3740])では、中央のGroup Controller/主要なServerは一方的にグループセキュリティ協会のSPIを割り当てます。 このSPI課題は、グループを包括する個々のエンドシステムにあるかぎ管理(例えば、IKE)サブシステムで、交渉もされませんし、調整もされません。 その結果、グループセキュリティ協会とユニキャストセキュリティ協会が同時に同じSPIを使用できるのは、可能です。 マルチキャストできるIPsec実装は反-正しくSPI衝突の文脈さえにおけるインバウンドトラフィックを多重送信しなければなりません。
Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows:
Security Association Database(SAD)[ケン-アーチ]の各エントリーは、SAルックアップが目的地か、目的地とソースを利用するかどうかを示さなければなりません、IPアドレス、SPIに加えて。 マルチキャストSAsにおいて、プロトコル分野はSAルックアップに使われません。 それぞれの本国行きの、そして、IPsecによって保護されたパケットに関しては、実装がSADの検索を行わなければならないので、それは「最も長い」SA識別子に合っているエントリーを見つけます。 このような関係においては、2つ以上のSADエントリーがSPI値、次にまた、目的地か、目的地とソースに基づいて合っているエントリーに基づいて合っているなら、アドレス比較(SADエントリーにみられるように)は「最も長い」マッチです。 これは以下のSAD検索の論理的な注文を含意します:
Kent Standards Track [Page 10] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[10ページ]RFC4303IP
1. Search the SAD for a match on {SPI, destination address,
source address}. If an SAD entry matches, then process the
inbound ESP packet with that matching SAD entry. Otherwise,
proceed to step 2.
1. マッチのためにSPI、送付先アドレス、ソースアドレスをSADを捜してください。 SADエントリーが合っているなら、そんなに合っているSADエントリーで本国行きの超能力パケットを処理してください。 さもなければ、ステップ2に進んでください。
2. Search the SAD for a match on {SPI, destination address}.
If the SAD entry matches, then process the inbound ESP
packet with that matching SAD entry. Otherwise, proceed to
step 3.
2. マッチのためにSPI、送付先アドレスをSADを捜してください。 SADエントリーが合っているなら、そんなに合っているSADエントリーで本国行きの超能力パケットを処理してください。 さもなければ、ステップ3に進んでください。
3. Search the SAD for a match on only {SPI} if the receiver has
chosen to maintain a single SPI space for AH and ESP, or on
{SPI, protocol} otherwise. If an SAD entry matches, then
process the inbound ESP packet with that matching SAD entry.
Otherwise, discard the packet and log an auditable event.
3. 受信機が、別の方法でAHと超能力か、SPI、プロトコルの上のただ一つのSPIスペースを維持するのを選んだなら、SPIだけの上のマッチのためにSADを捜してください。 SADエントリーが合っているなら、そんなに合っているSADエントリーで本国行きの超能力パケットを処理してください。 さもなければ、パケットを捨ててください、そして、監査可能イベントを登録してください。
In practice, an implementation MAY choose any method to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list are kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers are sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available Ternary Content-Addressable Memory (TCAM) features.
実際には、実装はこの検索を加速するどんなメソッドも選ぶかもしれません、外部的に目に見える振舞いが上記のオーダーをSADを捜したのに機能上同等でなければなりませんが。 例えば、ソフトウェアベースの実装はSPIでハッシュ表に索引をつけることができました。 それぞれのハッシュ表バケツの繋がっているリストにおけるSADエントリーは最初にその繋がっているリストで最も長いSA識別子で分類されて、それらのSADエントリーを持つように保たれます。 持っている中でSA識別子最も短いそれらのSADエントリーが分類されるので、それらは繋がっているリストで最後のエントリーです。 ハードウェアベースの実装は本質的に最も長いマッチ検索に作用できるかもしれません、一般的に利用可能なTernary Contentアドレス可能なMemory(TCAM)の特徴を使用して。
The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier.
ソースと目的地がマッチングを扱うかどうかしるしが、手動のSA構成か交渉使用を通したSA管理プロトコル、例えば、IKEの副作用かInterpretationのGroup Domainとしてのセットが(GDOI)であったに違いない[RFC3547]なら本国行きのIPsecトラフィックをSAsに写像するのに必要です。 通常、Source特有のMulticast(SSM)[HC03]グループはSPIで構成された3-tuple SA識別子、送付先マルチキャストアドレス、およびソースアドレスを使用します。 Any-ソースMulticastグループSAは識別子としてSPIと送付先マルチキャストアドレスだけを必要とします。
The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation might use the zero SPI value to mean "No Security Association Exists"
範囲1〜255のSPI値のセットは今後の使用のためにインターネットAssigned民数記Authority(IANA)によって予約されます。 割り当てられたSPI価値の使用がRFCで指定されないと、通常、予約されたSPI値はIANAによって割り当てられないでしょう。 (0)がないSPI値を地方の実装特定的用法のために予約して、ワイヤに送ってはいけません。 (例えば、かぎ管理実装はSPIが「セキュリティ協会は全く存在しません」と意味するために評価するゼロを使用するかもしれません。
Kent Standards Track [Page 11] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[11ページ]RFC4303IP
during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.)
IPsec実装が、かぎ管理実体が新しいSAを設立するよう要求しましたが、SAがまだ設立されていない期間。)
2.2. Sequence Number
2.2. 一連番号
This unsigned 32-bit field contains a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number. For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. Sharing an SA among multiple senders is permitted, though generally not recommended. ESP provides no means of synchronizing packet counters among multiple senders or meaningfully managing a receiver packet counter and window in the context of multiple senders. Thus, for a multi-sender SA, the anti-replay features of ESP are not available (see Sections 3.3.3 and 3.4.3.)
この未署名の32ビットの分野は各パケットあたり1つによる増加が送った対価を含んでいます、すなわち、1SAあたり1つのパケット一連番号。 ユニキャストのために、SAか独身の送付者マルチキャストSA、送付者があらゆる伝えられたパケットのためのこの分野を増加しなければなりません。 一般に推薦されませんが、複数の送付者の中でSAを共有するのは受入れられます。 超能力は複数の送付者の中でパケットカウンタを連動させるか、または意味深長に受信機パケットカウンタと窓を管理する手段を全く複数の送付者の文脈に提供しません。 したがって、マルチ送付者SAには、超能力の反再生機能は利用可能ではありません。(.3にセクション3.3 .3と3.4を見ます)
The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, but all ESP implementations MUST be capable of performing the processing described in Sections 3.3.3 and 3.4.3. Thus, the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section (3.4.3) below).
受信機が、特定のSAのために反再生サービスを可能にするのを選ばないでも、分野は、義務的であり、いつも存在していなければなりません。 受信機の裁量にはSequence Number分野の処理がありますが、すべての超能力実装がセクション3.3.3と3.4で.3に説明された処理を実行できなければなりません。 その結果、送付者がいつもこの野原を伝えなければなりませんが、受信機がそれに作用する必要はない、(「本国行きのパケット処理」セクションでのSequence Number Verificationの議論を見てください、(3.4、.3、)、)以下に
The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.3 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.
SAが設立されるとき、送付者のカウンタと受信機のカウンタは0に初期化されます。 (与えられたSAが使用させられた最初のパケットは1の一連番号を持つでしょう; 一連番号がどう発生しているかに関するその他の詳細に関してセクション3.3.3を見てください。) 反再生が可能にされるなら(デフォルト)、伝えられた一連番号を決して循環させてはいけません。 したがって、SAにおける2^第32パケットのトランスミッションの前に送付者のカウンタと受信機のカウンタをリセットしなければなりません(新しいSAとその結果新しいキーを設立することによって)。
2.2.1. Extended (64-bit) Sequence Number
2.2.1. (64ビット)の拡張一連番号
To support high-speed IPsec implementations, Extended Sequence Numbers (ESNs) SHOULD be implemented, as an extension to the current, 32-bit sequence number field. Use of an ESN MUST be negotiated by an SA management protocol. Note that in IKEv2, this negotiation is implicit; the default is ESN unless 32-bit sequence numbers are explicitly negotiated. (The ESN feature is applicable to multicast as well as unicast SAs.)
高速IPsec実装、Extended Sequence民数記(ESNs)SHOULDをサポートするために、実装されてください、現在の、そして、32ビットの一連番号分野への拡大として。 使用、ESN MUSTでは、SA管理プロトコルで、交渉されてください。 IKEv2では、この交渉が暗に示されていることに注意してください。 32ビットの一連番号が明らかに交渉されない場合、デフォルトはESNです。 (ESNの特徴はユニキャストSAsと同様にマルチキャストに適切です。)
Kent Standards Track [Page 12] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[12ページ]RFC4303IP
The ESN facility allows use of a 64-bit sequence number for an SA. (See Appendix A, "Extended (64-bit) Sequence Numbers", for details.) Only the low-order 32 bits of the sequence number are transmitted in the plaintext ESP header of each packet, thus minimizing packet overhead. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV (if the integrity service is selected). If a separate integrity algorithm is employed, the high order bits are included in the implicit ESP trailer, but are not transmitted, analogous to integrity algorithm padding bits. If a combined mode algorithm is employed, the algorithm choice determines whether the high-order ESN bits are transmitted or are included implicitly in the computation. See Section 3.3.2.2 for processing details.
ESN施設は64ビットの一連番号のSAの使用を許します。 (Appendix A、「(64ビット)の拡張一連番号」を詳細に関して見てください。) 一連番号の下位の32ビットだけがそれぞれのパケットの平文超能力ヘッダーで伝えられます、その結果、パケットオーバーヘッドを最小にします。 高位32ビットは、一連番号カウンタの一部として送信機と受信機の両方によって維持されて、ICVの計算に含まれています(保全サービスが選択されるなら)。 別々の保全アルゴリズムが採用しているなら、高位のビットは、内在している超能力トレーラに含まれていますが、伝えられません、保全アルゴリズム詰め物ビットに類似しています。 結合したモードアルゴリズムが採用しているなら、アルゴリズム選択は、高位ESNビットが計算に伝えられるか、またはそれとなく含まれているかを決定します。 処理のための.2が詳しく述べるセクション3.3.2を見てください。
2.3. Payload Data
2.3. 有効搭載量データ
Payload Data is a variable-length field containing data (from the original IP packet) described by the Next Header field. The Payload Data field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data is carried explicitly in the Payload field, but it is not called out as a separate field in ESP, i.e., the transmission of an explicit IV is invisible to ESP. (See Figure 2.) Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. (Typically, the IV immediately precedes the ciphertext. See Figure 2.) If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the algorithm definition RFC. (If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV), usually is not encrypted per se (see Tables 1 and 2), although it sometimes is referred to as being part of the ciphertext.)
有効搭載量DataはNext Header分野によって説明されたデータ(オリジナルのIPパケットからの)を含む可変長の分野です。 有効搭載量Data分野は、義務的であり、長さが不可欠のバイト数です。 ペイロードを暗号化するのに使用されるアルゴリズムが暗号の同期データ、例えば初期設定Vectorを必要とするなら(IV)、このデータは有効搭載量分野で明らかに運ばれますが、すなわち、別々の分野として超能力では明白なIVのトランスミッションが超能力に目に見えないと大声で叫ばれません。 (図2を参照してください。) そのような1パケットあたりの明白な同期データを必要とするどんな暗号化アルゴリズムもアルゴリズムが超能力と共にどう使用されるかを指定するRFCの一部として長さ、そのようなデータのためのどんな構造、およびこのデータの位置も示さなければなりません。 (通常、IVはすぐに、暗号文に先行します。 図2を参照してください。) そのような同期データが暗黙であるなら、データを引き出すためのアルゴリズムはアルゴリズム定義RFCの一部であるに違いありません。 (有効搭載量分野に含まれているなら、通常、暗号の同期データ(例えば、初期設定Vector(IV))はそういうものとして暗号化されません(Tables1と2を見てください)、それは時々暗号文の一部であると呼ばれますが。)
Note that the beginning of the next layer protocol header MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes.
以下の超能力ヘッダーの始まりに比例して次の層のプロトコルヘッダーの始まりを並べなければならないことに注意してください。 IPv4に関しては、この整列は4バイトの倍数です。 IPv6に関しては、整列は8バイトの倍数です。
With regard to ensuring the alignment of the (real) ciphertext in the presence of an IV, note the following:
IVの面前で(本当)の暗号文の整列を確実にすることに関して、以下に注意してください:
o For some IV-based modes of operation, the receiver treats
the IV as the start of the ciphertext, feeding it into the
algorithm directly. In these modes, alignment of the start
of the (real) ciphertext is not an issue at the receiver.
o いくつかのIVベースの運転モードのために、受信機は暗号文の始まりとしてIVを扱います、直接アルゴリズムにそれを入れて。 これらのモードで、(本当)の暗号文の始まりの整列は受信機の問題ではありません。
Kent Standards Track [Page 13] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[13ページ]RFC4303IP
o In some cases, the receiver reads the IV in separately from
the ciphertext. In these cases, the algorithm specification
MUST address how alignment of the (real) ciphertext is to be
achieved.
o いくつかの場合、受信機は別々に中で暗号文からIVを読みます。 これらの場合では、アルゴリズム仕様は(本当)の暗号文の整列がどう達成されるかことであることを扱わなければなりません。
2.4. Padding (for Encryption)
2.4. 詰め物(暗号化のための)
Two primary factors require or motivate use of the Padding field.
2つの主要な要素が、Padding分野の使用を必要である、または動機づけます。
o If an encryption algorithm is employed that requires the
plaintext to be a multiple of some number of bytes, e.g.,
the block size of a block cipher, the Padding field is used
to fill the plaintext (consisting of the Payload Data,
Padding, Pad Length, and Next Header fields) to the size
required by the algorithm.
o 暗号化アルゴリズムが使われて、それは、平文が何らかのバイト数の倍数であることを必要とします、例えば、ブロック暗号のブロック・サイズということであるなら、Padding分野が、平文(有効搭載量Data、Padding、Pad Length、およびNext Header分野から成る)をアルゴリズムによって必要とされたサイズにいっぱいにするのに使用されます。
o Padding also may be required, irrespective of encryption
algorithm requirements, to ensure that the resulting
ciphertext terminates on a 4-byte boundary. Specifically,
the Pad Length and Next Header fields must be right aligned
within a 4-byte word, as illustrated in the ESP packet
format figures above, to ensure that the ICV field (if
present) is aligned on a 4-byte boundary.
o 詰め物も、暗号化アルゴリズム要件の如何にかかわらず結果として起こる暗号文が4バイトの境界で終わるのを保証するのに必要であるかもしれません。 明確に、Pad LengthとNext Header分野は4バイトの単語の中でまさしく並べなければなりません、ICV分野(存在しているなら)が4バイトの境界で並べられるのを保証するためにパケット・フォーマットが上で計算する超能力で例証されるように。
Padding beyond that required for the algorithm or alignment reasons cited above could be used to conceal the actual length of the payload, in support of TFC. However, the Padding field described is too limited to be effective for TFC and thus should not be used for that purpose. Instead, the separate mechanism described below (see Section 2.7) should be used when TFC is required.
それを超えてそっと歩くのがアルゴリズムに必要であった、またはペイロードの実際の長さを隠すのに上で引用された整列理由は使用できました、TFCを支持して。 しかしながら、説明されたPadding分野を、TFCに有効であるように思えないほど制限していて、その結果、そのために使用するべきではありません。 TFCが必要であるときに、代わりに、以下(セクション2.7を見る)で説明された別々のメカニズムは使用されるべきです。
The sender MAY add 0 to 255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, subject to the requirements noted above, but all implementations MUST support generation and consumption of padding.
送付者は0〜255バイトの詰め物を加えるかもしれません。 超能力パケットでのPadding分野の包含は上に述べられた要件を条件として任意ですが、すべての実装が詰め物の世代と消費をサポートしなければなりません。
o For the purpose of ensuring that the bits to be encrypted
are a multiple of the algorithm's block size (first bullet
above), the padding computation applies to the Payload Data
exclusive of any IV, but including the ESP trailer
fields. If a combined algorithm mode requires transmission
of the SPI and Sequence Number to effect integrity, e.g.,
replication of the SPI and Sequence Number in the Payload
Data, then the replicated versions of these data items, and
any associated, ICV-equivalent data, are included in the
computation of the pad length. (If the ESN option is
o 暗号化されるべきビットがアルゴリズムのブロック・サイズ(上の最初の弾丸)の倍数であることを確実にする目的のために、詰め物計算はしかし、どんなIV、包含も排他的な有効搭載量Dataに超能力トレーラ分野を適用します。 結合したアルゴリズムモードが、SPIとSequence Numberのトランスミッションが保全、例えば有効搭載量Dataにおける、SPIとSequence Numberの模写に作用するのを必要とするなら、これらのデータ項目の模写されたバージョン、およびどんな関連していて、ICV同等なデータもパッドの長さの計算に含まれています。 (ESNオプションはそうです。
Kent Standards Track [Page 14] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[14ページ]RFC4303IP
selected, the high-order 32 bits of the ESN also would enter
into the computation, if the combined mode algorithm
requires their transmission for integrity.)
選択されています、ESNの高位32ビットも計算に入るでしょう、結合したモードアルゴリズムが保全のための彼らのトランスミッションを必要とするなら。)
o For the purposes of ensuring that the ICV is aligned on a
4-byte boundary (second bullet above), the padding
computation applies to the Payload Data inclusive of the IV,
the Pad Length, and Next Header fields. If a combined mode
algorithm is used, any replicated data and ICV-equivalent
data are included in the Payload Data covered by the padding
computation.
o ICVが4バイトの境界(上の2番目の弾丸)で並べられるのを確実にする目的のために、詰め物計算はIV、Pad Length、およびNext Headerを包含有効搭載量Dataに分野を適用します。 結合したモードアルゴリズムが使用されているなら、どんな複製データとICV同等なデータも詰め物計算でカバーされた有効搭載量Dataに含まれています。
If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, .... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.)
Paddingバイトが必要ですが、暗号化アルゴリズムが詰め物コンテンツを指定しないなら、以下のデフォルト処理を使用しなければなりません。 Paddingバイトがシリーズで初期化される、(未署名である、1バイト) 整数値。 平文に追加された最初の詰め物バイトは番号付の1です、その後の詰め物バイトが単調に増加する系列を作っていて: 1, 2, 3, .... この詰め物体系が採用しているとき、受信機SHOULDはPadding分野を点検します。 (相対的な簡単さ、ハードウェアの実装の容易さのためそれが他の保全測定がないとき、ある形式の「カットアンドペースト」攻撃に対する限定保護を提供するのでこの体系は選択されました、受信機が復号化の詰め物値をチェックするなら。)
If an encryption or combined mode algorithm imposes constraints on the values of the bytes used for padding, they MUST be specified by the RFC defining how the algorithm is employed with ESP. If the algorithm requires checking of the values of the bytes used for padding, this too MUST be specified in that RFC.
暗号化か結合したモードアルゴリズムが詰め物に使用されるバイトの値に規制を課すなら、アルゴリズムが超能力と共にどう使われるかを定義するRFCはそれらを指定しなければなりません。 アルゴリズムが、チェックするのを必要とするなら、バイトの値が詰め物に使用されて、そのRFCでこれも指定しなければなりません。
2.5. Pad Length
2.5. パッドの長さ
The Pad Length field indicates the number of pad bytes immediately preceding it in the Padding field. The range of valid values is 0 to 255, where a value of zero indicates that no Padding bytes are present. As noted above, this does not include any TFC padding bytes. The Pad Length field is mandatory.
Pad Length分野はすぐにPadding分野でそれに先行するパッドバイトの数を示します。 有効値の範囲は、0〜255です。(そこで、ゼロの値はどんなPaddingバイトも存在していないのを示します)。 上で述べたように、これはバイトを水増しする少しのTFCも含んでいません。 Pad Length分野は義務的です。
Kent Standards Track [Page 15] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[15ページ]RFC4303IP
2.6. Next Header
2.6. 次のヘッダー
The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP.
Next Headerは例えば、有効搭載量Data分野に保管されていたデータかIPv4かIPv6パケットか、次の層のヘッダーとデータのタイプを特定する義務的で、8ビットの分野です。 この分野の値はIANAのウェブページで定義されたIPプロトコル民数記のセットから選ばれています、そして、例えば、4の値はIPv4を示します、そして、41の値はIPv6を示します、そして、6の値はTCPを示します。
To facilitate the rapid generation and discarding of the padding traffic in support of traffic flow confidentiality (see Section 2.4), the protocol value 59 (which means "no next header") MUST be used to designate a "dummy" packet. A transmitter MUST be capable of generating dummy packets marked with this value in the next protocol field, and a receiver MUST be prepared to discard such packets, without indicating an error. All other ESP header and trailer fields (SPI, Sequence Number, Padding, Pad Length, Next Header, and ICV) MUST be present in dummy packets, but the plaintext portion of the payload, other than this Next Header field, need not be well-formed, e.g., the rest of the Payload Data may consist of only random bytes. Dummy packets are discarded without prejudice.
交通の流れ秘密性(セクション2.4を見る)を支持して詰め物トラフィックを急速な世代と捨てることを容易にするなら、「ダミー」のパケットを指定するのに、プロトコル値59(「いいえ、次のヘッダー」を意味します)を使用しなければなりません。 送信機は次のプロトコル分野でこの値でマークされたダミーのパケットを生成することができなければなりません、そして、そのようなパケットを捨てるように受信機を準備しなければなりません、誤りを示さないで。 このNext Header分野を除いて、ペイロードの平文部分が整形式である必要はない、他のすべての超能力ヘッダーとトレーラ分野(SPI、Sequence Number、Padding、Pad Length、Next Header、およびICV)はダミーのパケットに出席しているに違いありませんが、例えば、有効搭載量Dataの残りは無作為のバイトだけから成るかもしれません。 ダミーのパケットは偏見なしで捨てられます。
Implementations SHOULD provide local management controls to enable the use of this capability on a per-SA basis. The controls should allow the user to specify if this feature is to be used and also provide parametric controls; for example, the controls might allow an administrator to generate random-length or fixed-length dummy packets.
実装SHOULDは、1SAあたり1個のベースにおけるこの能力の使用を可能にするために現地管理職者コントロールを提供します。 コントロールで、ユーザは、この特徴が使用されて、また、パラメトリックコントロールを提供するかどうかことであると指定できるべきです。 例えば、コントロールで、管理者は、無作為の長さか固定長がダミーのパケットであると生成することができるかもしれません。
DISCUSSION: Dummy packets can be inserted at random intervals to mask the absence of actual traffic. One can also "shape" the actual traffic to match some distribution to which dummy traffic is added as dictated by the distribution parameters. As with the packet length padding facility for Traffic Flow Security (TFS), the most secure approach would be to generate dummy packets at whatever rate is needed to maintain a constant rate on an SA. If packets are all the same size, then the SA presents the appearance of a constant bit rate data stream, analogous to what a link crypto would offer at layer 1 or 2. However, this is unlikely to be practical in many contexts, e.g., when there are multiple SAs active, because it would imply reducing the allowed bandwidth for a site, based on the number of SAs, and that would undermine the benefits of packet switching. Implementations SHOULD provide controls to enable local administrators to manage the generation of dummy packets for TFC purposes.
議論: ダミーのパケットによる無作為に挿入されて、実際の不在にマスクをかける間隔が取引するということであることができます。 また、1つは、ダミーのトラフィックが分配パラメタによって書き取られるように加えられる何らかの分配に合うように実際のトラフィックを「形成できます」。 Traffic Flow Security(TFS)のためのパケット長詰め物施設なら、最も安全なアプローチはSAで一定のレートを維持するのに必要であるどんなレートでもダミーのパケットを生成するだろうことです。 パケットがちょうど同じサイズであるなら、SAは固定ビットレートデータ・ストリームの外観を提示します、リンク暗号が層1か2で提供するものに類似しています。 しかしながら、これが多くの文脈で実用的でありそうにない、減少を含意するでしょう、例えば、複数のSAsがあるとき、アクティブであることで、したがって、SAsの数に基づくサイトへの許容帯域幅とそれはパケット交換について利益を弱体化させるでしょう。 実装SHOULDは、地元の管理者がTFC目的のためにダミーのパケットの世代を経営するのを可能にするためにコントロールを提供します。
Kent Standards Track [Page 16] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[16ページ]RFC4303IP
2.7. Traffic Flow Confidentiality (TFC) Padding
2.7. 交通の流れ秘密性(TFC)詰め物
As noted above, the Padding field is limited to 255 bytes in length. This generally will not be adequate to hide traffic characteristics relative to traffic flow confidentiality requirements. An optional field, within the payload data, is provided specifically to address the TFC requirement.
上で述べたように、Padding分野は長さ255バイトに制限されます。 一般に、これは、交通の流れ機密保持の要求事項に比例してトラフィックの特性を隠すために適切にならないでしょう。 特にTFC要件を扱うためにペイロードデータの中で任意の野原を供給します。
An IPsec implementation SHOULD be capable of padding traffic by adding bytes after the end of the Payload Data, prior to the beginning of the Padding field. However, this padding (hereafter referred to as TFC padding) can be added only if the Payload Data field contains a specification of the length of the IP datagram. This is always true in tunnel mode, and may be true in transport mode depending on whether the next layer protocol (e.g., IP, UDP, ICMP) contains explicit length information. This length information will enable the receiver to discard the TFC padding, because the true length of the Payload Data will be known. (ESP trailer fields are located by counting back from the end of the ESP packet.) Accordingly, if TFC padding is added, the field containing the specification of the length of the IP datagram MUST NOT be modified to reflect this padding. No requirements for the value of this padding are established by this standard.
IPsec実装SHOULD、有効搭載量の終わりのバイト後にDataを加えることによって、トラフィックをそっと歩くことができてください、Padding分野の始まりの前に。 しかしながら、有効搭載量Data分野がIPデータグラムの長さの仕様を含んでいる場合にだけ、この詰め物(今後TFC詰め物と呼ばれる)を加えることができます。 これは、トンネルモードでいつも本当であり、次の層のプロトコル(例えば、IP、UDP、ICMP)が明白な長さの情報を含んでいるかどうかに依存する交通機関で本当であるかもしれません。 この長さの情報は、受信機が有効搭載量Dataの真の長さが知られているのでそっと歩くTFCを捨てるのを可能にするでしょう。 (超能力トレーラ分野は超能力パケットの端から数え返すことによって、見つけられています。) それに従って、TFC詰め物が加えられるなら、この詰め物を反映するようにIPデータグラムの長さの仕様を含む分野を変更してはいけません。 この詰め物の値のための要件は全くこの規格によって確立されません。
In principle, existing IPsec implementations could have made use of this capability previously, in a transparent fashion. However, because receivers may not have been prepared to deal with this padding, the SA management protocol MUST negotiate this service prior to a transmitter employing it, to ensure backward compatibility. Combined with the convention described in Section 2.6 above, about the use of protocol ID 59, an ESP implementation is capable of generating dummy and real packets that exhibit much greater length variability, in support of TFC.
原則として、既存のIPsec実装は以前に、見え透いたファッションでこの能力を利用したかもしれません。 しかしながら、受信機がこの詰め物に対処するように準備されていないかもしれないので、後方の互換性を確実にするのにそれを使って、SA管理プロトコルは送信機の前でこのサービスを交渉しなければなりません。 プロトコルID59の使用に関する上のセクション2.6で説明されるコンベンションに結合されています、超能力実装ははるかにすばらしい長さの可変性を示すダミーの、そして、本当のパケットを生成することができます、TFCを支持して。
Implementations SHOULD provide local management controls to enable the use of this capability on a per-SA basis. The controls should allow the user to specify if this feature is to be used and also provide parametric controls for the feature.
実装SHOULDは、1SAあたり1個のベースにおけるこの能力の使用を可能にするために現地管理職者コントロールを提供します。 コントロールで、ユーザは、この特徴が使用されて、また、パラメトリックコントロールを提供するかどうかことであると特徴に指定できるべきです。
2.8. Integrity Check Value (ICV)
2.8. 保全チェック価値(ICV)
The Integrity Check Value is a variable-length field computed over the ESP header, Payload, and ESP trailer fields. Implicit ESP trailer fields (integrity padding and high-order ESN bits, if applicable) are included in the ICV computation. The ICV field is optional. It is present only if the integrity service is selected and is provided by either a separate integrity algorithm or a combined mode algorithm that uses an ICV. The length of the field is
Integrity Check Valueは超能力ヘッダー、有効搭載量、および超能力トレーラ分野に関して計算された可変長の分野です。 暗黙の超能力トレーラ分野(保全詰め物と高位ESNビットの、そして、適切な)はICV計算に含まれています。 ICV分野は任意です。 保全サービスを選択して、ICVを使用する別々の保全アルゴリズムか結合したモードアルゴリズムのどちらかで提供する場合にだけ、存在しています。 分野の長さはそうです。
Kent Standards Track [Page 17] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[17ページ]RFC4303IP
specified by the integrity algorithm selected and associated with the SA. The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
SAに選択されて、関連づけられた保全アルゴリズムで、指定されます。 保全アルゴリズム仕様は合法化のためのICVの長さ、比較規則、および処理ステップを指定しなければなりません。
3. Encapsulating Security Protocol Processing
3. セキュリティがプロトコル処理であるとカプセル化します。
3.1. ESP Header Location
3.1. 超能力ヘッダー位置
ESP may be employed in two ways: transport mode or tunnel mode.
超能力は2つの方法で使われるかもしれません: モードかトンネルモードを輸送してください。
3.1.1. Transport Mode Processing
3.1.1. 交通機関処理
In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the next layer protocol. (If AH is also applied to a packet, it is applied to the ESP header, Payload, ESP trailer, and ICV, if present.) (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (This and subsequent diagrams in this section show the ICV field, the presence of which is a function of the security services and the algorithm/mode selected.)
交通機関に、超能力はIPヘッダーの後と例えば、次の層のプロトコル、TCP、UDP、ICMPなどの前に挿入されます。 IPv4の文脈では、これはIPヘッダー(そして、それが含むどんなオプションも)の後に超能力を置くのにもかかわらずの、次の層のプロトコルの前に翻訳されます。 (また、AHがパケットに適用されるなら、超能力ヘッダー、有効搭載量、超能力トレーラ、およびICVに適用されていて、存在しています。) (使用をTCPとUDPに制限するのが用語「輸送」モードに誤解されるべきでないことに注意してください。) 以下のダイヤグラムは基礎「前後」のときにaで典型的なIPv4パケットのための超能力交通機関位置決めを例証します。 (このセクションのこれとその後のダイヤグラムはICV分野を示しています。)その存在は、セキュリティー・サービスの機能と選択されたアルゴリズム/モードです。
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
超能力を適用する前に---------------------------- IPv4|orig IP hdr| | | |(どんなオプションも)| TCP| データ| ----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
超能力を適用した後に------------------------------------------------- IPv4|orig IP hdr| 超能力| | | 超能力| 超能力| |(どんなオプションも)| Hdr| TCP| データ| トレーラ| ICV| ------------------------------------------------- | <、-、-、-- 暗号化---->| | <、-、-、-、-、-、-、-- 保全------->|
In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. Destination options extension header(s) could appear before, after, or both before and after the ESP header depending on the semantics desired. However, because ESP protects only fields after the ESP header, it generally will be desirable to place the destination options header(s) after the ESP header. The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet.
IPv6文脈では、超能力は、終わりから終わりへのペイロードとして見なされて、その結果、ルーティング、およびホップごとの断片化拡張ヘッダーの後に現れるべきです。 目的地オプション拡張ヘッダーはヘッダー後ヘッダー前、または意味論を当てにする超能力ヘッダーのともに前後必要に見えることができました。 しかしながら、超能力が超能力ヘッダーの後に分野だけを保護するので、一般に、目的地オプションヘッダーを超能力ヘッダーの後に置くのは望ましいでしょう。 以下のダイヤグラムは典型的なIPv6パケットのための超能力交通機関位置決めを例証します。
Kent Standards Track [Page 18] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[18ページ]RFC4303IP
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
超能力を適用する前に--------------------------------------- IPv6| | ext hdrs| | | | orig IP hdr|現在| TCP| データ| ---------------------------------------
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------>|
超能力を適用した後に--------------------------------------------------------- IPv6| orig|ホップごとのdest*| |dest| | | 超能力| 超能力| |IP hdr|断片| ルーティング、超能力|*を選んでください。|TCP|データ|トレーラ| ICV| --------------------------------------------------------- | <、-、-- 暗号化---->| | <、-、-、-、-、-- 保全------>|
* = if present, could be before ESP, after ESP, or both
* = 存在しているなら、超能力、または両方の後の超能力の前に、あるかもしれません。
Note that in transport mode, for "bump-in-the-stack" or "bump-in- the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.
または、交通機関で「スタックでの隆起」ゆえそれに注意してください、「中で突き当たる、-、-配線してください、」 実装、Security Architectureドキュメントで定義されるように、本国行きの、そして、外国行きのIP断片はこの仕様に従って、透明なIPsecにサポートを供給するために付加的なIP再アセンブリ/断片化を実行するためにIPsec実装を必要とするかもしれません。 特別な注意が、複数のインタフェースが使用中であるときに、これらの実装の中でそのような操作を実行するのに必要です。
3.1.2. Tunnel Mode Processing
3.1.2. トンネル・モード処理
In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets.
トンネルモードで、「内側」のIPヘッダーは究極の(IP)ソースと送付先アドレスを運びます、「外側」のIPヘッダーはIPsec「同輩」のアドレスを含んでいますが、例えば、セキュリティゲートウェイのアドレス。 すなわち、内側の、そして、外側のIPバージョンが許容されているMixed、IPv6の上のIPv4とIPv4の上のIPv6。 トンネルモードで、超能力は全体の内側のIPヘッダーを含む全体の内側のIPパケットを保護します。 外側のIPヘッダーに比例して、トンネルモードにおける超能力の位置は交通機関における超能力のように同じです。 以下のダイヤグラムは、典型的なIPv4とIPv6のためにパケットを置きながら、超能力トンネルモードを例証します。
Kent Standards Track [Page 19] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[19ページ]RFC4303IP
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
超能力を適用する前に---------------------------- IPv4|orig IP hdr| | | |(どんなオプションも)| TCP| データ| ----------------------------
AFTER APPLYING ESP
超能力を適用した後に
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|
----------------------------------------------------------- IPv4| 新しいIP hdr*| | orig IP hdr*| | | 超能力| 超能力| |(どんなオプションも)| 超能力| (どんなオプションも) |TCP|データ|トレーラ| ICV| ----------------------------------------------------------- | <、-、-、-、-、-、-、-、-- 暗号化--------->| | <、-、-、-、-、-、-、-、-、-、-、-、-- 保全------------>|
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
超能力を適用する前に--------------------------------------- IPv6| | ext hdrs| | | | orig IP hdr|現在| TCP| データ| ---------------------------------------
AFTER APPLYING ESP
超能力を適用した後に
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
------------------------------------------------------------ IPv6| 新しい*|新しいext| | orig*|orig ext| | | 超能力| 超能力| |IP hdr| hdrs*|超能力|IP hdr| hdrs*|TCP|データ|トレーラ| ICV| ------------------------------------------------------------ | <、-、-、-、-、-、-、-、-- 暗号化---------->| | <、-、-、-、-、-、-、-、-、-、-、-- 保全------------>|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.
* = 存在しているなら、Security Architectureドキュメントで外側のIP hdr/拡大の工事と内側のIP hdr/拡大の変更について議論します。
3.2. Algorithms
3.2. アルゴリズム
The mandatory-to-implement algorithms for use with ESP are described in a separate RFC, to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for ESP, MAY be supported. Note that although both confidentiality and integrity are optional, at least one of these services MUST be selected, hence both algorithms MUST NOT be simultaneously NULL.
超能力との使用のための実装するために義務的なアルゴリズムは、プロトコルからアルゴリズム要件を独自にそういうものとしてアップデートするのを容易にするために別々のRFCで説明されます。 追加アルゴリズムは超能力のために強制されたものを超えてサポートされるかもしれません。 秘密性と保全の両方が任意ですが、少なくともこれらのサービスの1つを選択しなければならなくて、したがって、両方のアルゴリズムが同時にNULLであるはずがないことに注意してください。
Kent Standards Track [Page 20] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[20ページ]RFC4303IP
3.2.1. Encryption Algorithms
3.2.1. 暗号化アルゴリズム
The encryption algorithm employed to protect an ESP packet is specified by the SA via which the packet is transmitted/received. Because IP packets may arrive out of order, and not all packets may arrive (packet loss), each packet must carry any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the plaintext portions of the (outer IP or ESP) packet header. (Note that if plaintext header information is used to derive an IV, that information may become security critical and thus the protection boundary associated with the encryption process may grow. For example, if one were to use the ESP Sequence Number to derive an IV, the Sequence Number generation logic (hardware or software) would have to be evaluated as part of the encryption algorithm implementation. In the case of FIPS 140-2 [NIST01], this could significantly extend the scope of a cryptographic module evaluation.) Because ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Note that because encryption (confidentiality) MAY be an optional service (e.g., integrity-only ESP), this algorithm MAY be "NULL" [Ken-Arch].
超能力パケットを保護するのに使われた暗号化アルゴリズムはを通したパケットが伝えられるか、または受け取られているSAによって指定されます。 IPパケットが故障していた状態で到着するかもしれなくて、すべてのパケットが到着するかもしれないというわけではないので(パケット損失)、各パケットは受信機が復号化のための暗号の同期を確立するのを許容するのに必要であるデータを運ばなければなりません。 このデータはペイロード分野で明らかに運ばれるかもしれません、例えば、IVとして(上で説明されるように)、または、(外側のIPか超能力)パケットのヘッダーの平文一部からデータを得るかもしれません。 (平文ヘッダー情報がIVを引き出すのに使用されるなら、その情報がセキュリティ重要になるかもしれなくて、その結果、暗号化プロセスに関連している保護境界が成長するかもしれないことに注意してください。 例えば、1つがIVを引き出すのに超能力Sequence Numberを使用するなら、Sequence Number世代論理(ハードウェアかソフトウェア)は暗号化アルゴリズム実装の一部として評価されなければならないでしょうに。 FIPS140-2[NIST01]の場合では、これは暗号のモジュール評価の範囲をかなり広げるかもしれません。) 超能力が平文の詰め物に備えるので、超能力と共に使われた暗号化アルゴリズムはブロックかストリームモードの特性のどちらかを示すかもしれません。 暗号化(秘密性)が任意のサービスであるかもしれないのでそれに注意してください、(例えば、保全、唯一の超能力)、このアルゴリズムは「ヌルであるかもしれない」[ケン-アーチ]。
To allow an ESP implementation to compute the encryption padding required by a block mode encryption algorithm, and to determine the MTU impact of the algorithm, the RFC for each encryption algorithm used with ESP must specify the padding modulus for the algorithm.
超能力実装がブロックモード暗号化アルゴリズムによって必要とされた暗号化詰め物を計算して、アルゴリズムのMTU影響を決定するのを許容するために、超能力と共に使用されるそれぞれの暗号化アルゴリズムのためのRFCは詰め物係数をアルゴリズムに指定しなければなりません。
3.2.2. Integrity Algorithms
3.2.2. 保全アルゴリズム
The integrity algorithm employed for the ICV computation is specified by the SA via which the packet is transmitted/received. As was the case for encryption algorithms, any integrity algorithm employed with ESP must make provisions to permit processing of packets that arrive out of order and to accommodate packet loss. The same admonition noted above applies to use of any plaintext data to facilitate receiver synchronization of integrity algorithms. Note that because the integrity service MAY be optional, this algorithm may be "NULL".
ICV計算に使われた保全アルゴリズムはを通したパケットが伝えられるか、または受け取られているSAによって指定されます。 暗号化アルゴリズム、超能力で採用しているアルゴリズムが故障していた状態で到着するパケットの許可証処理への条項を作らなければならないどんな保全も、パケット損失を収容するケースのように。 上に述べられた同じ訓戒は、保全アルゴリズムの受信機同期を容易にするのをどんな平文データの使用にも適用します。保全サービスが任意であるかもしれないのでこのアルゴリズムが「ヌルであるかもしれない」と述べてください。
To allow an ESP implementation to compute any implicit integrity algorithm padding required, the RFC for each algorithm used with ESP must specify the padding modulus for the algorithm.
超能力実装が詰め物が必要とした暗黙の保全アルゴリズムを計算するのを許容するために、超能力と共に使用される各アルゴリズムのためのRFCは詰め物係数をアルゴリズムに指定しなければなりません。
Kent Standards Track [Page 21] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[21ページ]RFC4303IP
3.2.3. Combined Mode Algorithms
3.2.3. 結合したモードアルゴリズム
If a combined mode algorithm is employed, both confidentiality and integrity services are provided. As was the case for encryption algorithms, a combined mode algorithm must make provisions for per- packet cryptographic synchronization, to permit decryption of packets that arrive out of order and to accommodate packet loss. The means by which a combined mode algorithm provides integrity for the payload, and for the SPI and (Extended) Sequence Number fields, may vary for different algorithm choices. In order to provide a uniform, algorithm-independent approach to invocation of combined mode algorithms, no payload substructure is defined. For example, the SPI and Sequence Number fields might be replicated within the ciphertext envelope and an ICV may be appended to the ESP trailer. None of these details should be observable externally.
結合したモードアルゴリズムが採用しているなら、秘密性と保全サービスの両方を提供します。 暗号化アルゴリズム、必須が備える結合したモードアルゴリズムのためのケース、-、パケットの暗号の同期、故障していた状態で到着するパケットの復号化を可能にして、パケット損失を収容するために。 結合したモードアルゴリズムがペイロード、SPI、および(広げられる)の系列Number分野に保全を供給する手段、異なったアルゴリズム選択のために異なるかもしれません。 ユニフォーム、結合したモードアルゴリズムの実施へのアルゴリズムから独立しているアプローチを提供するために、ペイロード基礎は全く定義されません。 例えば、暗号文封筒の中にSPIとSequence Number分野を模写するかもしれません、そして、超能力トレーラにICVを追加するかもしれません。 これらの詳細のいずれも外部的に観察可能であるべきではありません。
To allow an ESP implementation to determine the MTU impact of a combined mode algorithm, the RFC for each algorithm used with ESP must specify a (simple) formula that yields encrypted payload size, as a function of the plaintext payload and sequence number sizes.
超能力実装が結合したモードアルゴリズムのMTU影響を決定するのを許容するために、超能力と共に使用される各アルゴリズムのためのRFCは平文ペイロードと一連番号サイズの関数として暗号化されたペイロードサイズをもたらす(簡単)の公式を指定しなければなりません。
3.3. Outbound Packet Processing
3.3. 外国行きのパケット処理
In transport mode, the sender encapsulates the next layer protocol information between the ESP header and the ESP trailer fields, and retains the specified IP header (and any IP extension headers in the IPv6 context). In tunnel mode, the outer and inner IP header/extensions can be interrelated in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document.
交通機関で、送付者は、次の層が超能力ヘッダーと超能力トレーラ分野の間のプロトコル情報であることをカプセルに入れって、指定されたIPヘッダー(そして、IPv6文脈のどんなIP拡張ヘッダーも)を保有します。 トンネルモードで、外側の、そして、内側のIPヘッダー/拡大はさまざまな方法で相関的である場合があります。 カプセル化プロセスの間の外側のIPヘッダー/拡大の工事はSecurity Architectureドキュメントで説明されます。
3.3.1. Security Association Lookup
3.3.1. セキュリティ協会ルックアップ
ESP is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for ESP processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document.
IPsec実装が、パケットが超能力処理を求めるSAに関連していることを決定した後にだけ超能力は外国行きのパケットに適用されます。 アウトバウンドトラフィックに適用されたIPsec処理がどんなであるも何であるかを決定するプロセスはSecurity Architectureドキュメントで説明されます。
3.3.2. Packet Encryption and Integrity Check Value (ICV) Calculation
3.3.2. パケット暗号化と保全チェック価値(ICV)の計算
In this section, we speak in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm (RFC 2410). There are several algorithmic options.
このセクションでは、私たちは形式含意のためにいつも適用される暗号化で話します。 NULL暗号化アルゴリズムを使用することによって「秘密性がありません」を提供するという条件でこれをします(RFC2410)。 いくつかのアルゴリズムのオプションがあります。
Kent Standards Track [Page 22] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[22ページ]RFC4303IP
3.3.2.1. Separate Confidentiality and Integrity Algorithms
3.3.2.1. 別々の秘密性と保全アルゴリズム
If separate confidentiality and integrity algorithms are employed, the Sender proceeds as follows:
別々の秘密性と保全アルゴリズムが採用しているなら、Senderは以下の通り続きます:
1. Encapsulate (into the ESP Payload field):
- for transport mode -- just the original next layer
protocol information.
- for tunnel mode -- the entire original IP datagram.
1. 要約してください(超能力有効搭載量分野に): - モードを輸送してください--まさしく次のオリジナルの層のプロトコル情報。 - モードにトンネルを堀ってください--全体のオリジナルのIPデータグラム。
2. Add any necessary padding -- Optional TFC padding and
(encryption) Padding
2. 任意のTFC詰め物と(暗号化)がそっと歩いて、あらゆる必要な詰め物を加えてください。
3. Encrypt the result using the key, encryption algorithm,
and algorithm mode specified for the SA and using any
required cryptographic synchronization data.
- If explicit cryptographic synchronization data,
e.g., an IV, is indicated, it is input to the
encryption algorithm per the algorithm specification
and placed in the Payload field.
- If implicit cryptographic synchronization data is
employed, it is constructed and input to the
encryption algorithm as per the algorithm
specification.
- If integrity is selected, encryption is performed
first, before the integrity algorithm is applied, and
the encryption does not encompass the ICV field.
This order of processing facilitates rapid detection
and rejection of replayed or bogus packets by the
receiver, prior to decrypting the packet, hence
potentially reducing the impact of denial of service
(DoS) attacks. It also allows for the possibility of
parallel processing of packets at the receiver, i.e.,
decryption can take place in parallel with integrity
checking. Note that because the ICV is not protected
by encryption, a keyed integrity algorithm must be
employed to compute the ICV.
3. SAに指定されて、どんな必要な暗号の同期データも使用することでキー、暗号化アルゴリズム、およびアルゴリズムモードを使用して、結果を暗号化してください。 - 明白な暗号の同期データ(例えば、IV)が示されるなら、それは、アルゴリズム仕様あたりの暗号化アルゴリズムに入力されて、有効搭載量分野に置かれます。 - 暗黙の暗号の同期データが採用しているなら、それは、アルゴリズム仕様に従って暗号化アルゴリズムに組み立てられて、入力されます。 - 保全が選択されるなら、暗号化は最初に実行されます、保全アルゴリズムが適用されていて、暗号化がICV分野を取り囲まない前に。 処理のこの注文は受信機で再演されたかにせのパケットの急速な検出と拒絶を容易にします、パケットを解読する前に、したがって、サービス(DoS)攻撃の否定の影響を潜在的に減少させて。 また、それは受信機でパケットの並列処理の可能性を考慮します、すなわち、復号化が保全の照合と平行して行われることができます。 ICVが暗号化で保護されないのでICVを計算するのに合わせられた保全アルゴリズムを使わなければならないことに注意してください。
4. Compute the ICV over the ESP packet minus the ICV field.
Thus, the ICV computation encompasses the SPI, Sequence
Number, Payload Data, Padding (if present), Pad Length, and
Next Header. (Note that the last 4 fields will be in
ciphertext form, because encryption is performed first.) If
the ESN option is enabled for the SA, the high-order 32
bits of the sequence number are appended after the Next
Header field for purposes of this computation, but are not
transmitted.
4. 超能力パケットの上でICV分野を引いてICVを計算してください。 したがって、ICV計算はSPI、Sequence Number、有効搭載量Data、Padding(存在しているなら)、Pad Length、およびNext Headerを取り囲みます。 (暗号化が最初に実行されるので、ベスト4分野が暗号文フォームにあることに注意してください。) SAのためにESNオプションを可能にするなら、一連番号の高位32ビットをNext Header分野の後にこの計算の目的のために追加しますが、伝えません。
Kent Standards Track [Page 23] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[23ページ]RFC4303IP
For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a block size specified by the algorithm. If the length of ESP packet (as described above) does not match the block size requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet. (This padding is added after the Next Header field, or after the high-order 32 bits of the sequence number, if ESN is selected.) The block size (and hence the length of the padding) is specified by the integrity algorithm specification. This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this question, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's block size.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.
いくつかの保全アルゴリズムのために、ICV計算が実行されるバイトストリングはアルゴリズムで指定されたブロック・サイズの倍数でなければなりません。 超能力パケット(上で説明されるように)の長さがアルゴリズムのためのブロック・サイズ要件に合っていないなら、超能力パケットの端まで暗黙の詰め物を追加しなければなりません。 (この詰め物はNext Header分野の後、または一連番号の高位32ビットの後に加えられます、ESNが選択されるなら。) ブロック・サイズ(そして、したがって、詰め物の長さ)は保全アルゴリズム仕様で指定されます。 この詰め物はパケットで伝えられません。 上で説明されるように暗黙の詰め物が必要であるかどうか決定するために保全アルゴリズムを定義するドキュメントを参照しなければなりません。 ドキュメントがこの質問の答えを指定しないなら、デフォルトは暗黙の詰め物が必要であると仮定する(アルゴリズムのブロック・サイズにパケット長を合わせるのが必要であるので)ことです。 詰め物バイトが必要ですが、アルゴリズムが詰め物コンテンツを指定しないなら、詰め物八重奏には、ゼロの値がなければなりません。
3.3.2.2. Combined Confidentiality and Integrity Algorithms
3.3.2.2. 結合した秘密性と保全アルゴリズム
If a combined confidentiality/integrity algorithm is employed, the Sender proceeds as follows:
結合した秘密性/保全アルゴリズムが採用しているなら、Senderは以下の通り続きます:
1. Encapsulate into the ESP Payload Data field:
- for transport mode -- just the original next layer
protocol information.
- for tunnel mode -- the entire original IP datagram.
1. 超能力有効搭載量Data分野に要約してください: - モードを輸送してください--まさしく次のオリジナルの層のプロトコル情報。 - モードにトンネルを堀ってください--全体のオリジナルのIPデータグラム。
2. Add any necessary padding -- includes optional TFC padding
and (encryption) Padding.
2. 任意のTFC詰め物を含んで、そっと歩いて(暗号化)、あらゆる必要な詰め物を加えてください。
3. Encrypt and integrity protect the result using the key
and combined mode algorithm specified for the SA and using
any required cryptographic synchronization data.
- If explicit cryptographic synchronization data,
e.g., an IV, is indicated, it is input to the
combined mode algorithm per the algorithm
specification and placed in the Payload field.
- If implicit cryptographic synchronization data is
employed, it is constructed and input to the
encryption algorithm as per the algorithm
specification.
- The Sequence Number (or Extended Sequence Number, as
appropriate) and the SPI are inputs to the
algorithm, as they must be included in the integrity
check computation. The means by which these values
are included in this computation are a function of
3. そして、暗号化、保全は、SAに指定されて、どんな必要な暗号の同期データも使用することで主要で結合したモードアルゴリズムを使用することで結果を保護します。 - 明白な暗号の同期データ(例えば、IV)が示されるなら、それは、アルゴリズム仕様あたりの結合したモードアルゴリズムに入力されて、有効搭載量分野に置かれます。 - 暗黙の暗号の同期データが採用しているなら、それは、アルゴリズム仕様に従って暗号化アルゴリズムに組み立てられて、入力されます。 - Sequence Number、(または、Extended Sequence Number、適宜)、SPIはアルゴリズムへの入力です、保全チェック計算にそれらを含まなければならないとき。 これらの値がこの計算に含まれているのが、機能であるというどれのことであるかを意味します。
Kent Standards Track [Page 24] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[24ページ]RFC4303IP
the combined mode algorithm employed and thus not
specified in this standard.
- The (explicit) ICV field MAY be a part of the ESP
packet format when a combined mode algorithm is
employed. If one is not used, an analogous field
usually will be a part of the ciphertext payload.
The location of any integrity fields, and the means
by which the Sequence Number and SPI are included in
the integrity computation, MUST be defined in an RFC
that defines the use of the combined mode algorithm
with ESP.
使われて、この規格でこのようにして指定されなかった結合したモードアルゴリズム。 - 結合したモードアルゴリズムが採用しているとき、(明白)のICV分野は超能力パケット・フォーマットの一部であるかもしれません。 1つが使用されていないと、通常、類似の分野は暗号文ペイロードの一部になるでしょう。 超能力との結合したモードアルゴリズムの使用を定義するRFCでどんな保全分野の位置、およびSequence NumberとSPIが保全計算に含まれている手段も定義しなければなりません。
3.3.3. Sequence Number Generation
3.3.3. 一連番号世代
The sender's counter is initialized to 0 when an SA is established. The sender increments the sequence number (or ESN) counter for this SA and inserts the low-order 32 bits of the value into the Sequence Number field. Thus, the first packet sent using a given SA will contain a sequence number of 1.
SAが設立されるとき、送付者のカウンタは0に初期化されます。 送付者はこのSAと差し込みのためにSequence Number分野への価値の下位の32ビットで一連番号(または、ESN)カウンタを増加します。 したがって、与えられたSAが使用させられた最初のパケットは1の一連番号を含むでしょう。
If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the sequence number to cycle. An attempt to transmit a packet that would result in sequence number overflow is an auditable event. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID.
反再生が可能にされるなら(デフォルト)、送付者は、新しい値を差し込む前にカウンタがSequence Number分野を循環させていないのを保証するためにチェックします。 言い換えれば、そうするのが一連番号を引き起こすなら、送付者はサイクルまでパケットをSAに送ってはいけません。 一連番号オーバーフローをもたらすパケットを伝える試みは監査可能イベントです。 このイベントSHOULDのための監査ログエントリーはSPI値、現在の日付/時間、Source Address、Destination Address、および(IPv6の)cleartext Flow IDを含んでいます。
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3). Thus, typical behavior of an ESP implementation calls for the sender to establish a new SA when the Sequence Number (or ESN) cycles, or in anticipation of this value cycling.
別の方法で受信機によって通知されない場合、送付者は、反再生がデフォルトとして可能にされると仮定します(セクション3.4.3を見てください)。 したがって、超能力実装の典型的な振舞いはSequence Number(または、ESN)が循環するとき新しいSAを設立する送付者、またはこの値のサイクリングを予測して呼びます。
If the key used to compute an ICV is manually distributed, a compliant implementation SHOULD NOT provide anti-replay service. If a user chooses to employ anti-replay in conjunction with SAs that are manually keyed, the sequence number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced. (See Section 5.)
ICVを計算するのに使用されるキーが手動で分配されるなら、SHOULD NOTが反再生サービスを提供する対応する実装です。 ユーザが、手動で合わせられるSAsに関連して反再生を使うのを選ぶなら、地方のリブートなどの向こう側に正しく送付者の一連番号カウンタを維持しなければなりません、キーを取り替えるまで。 (セクション5を見てください。)
If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter. However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside
反再生は障害があるなら(上で述べたように)、送付者は、カウンタをモニターするか、またはリセットする必要はありません。 しかしながら、送付者はまだカウンタを増加しています、そして、最大値に達すると、カウンタはゼロにひっくり返って戻ります。 (反再生でないならこの振舞いがマルチ送付者、マルチキャストSAsのために推薦される、外のメカニズム
Kent Standards Track [Page 25] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[25ページ]RFC4303IP
the scope of this standard are negotiated between the sender and receiver.)
この規格の範囲は送付者と受信機の間で交渉されます。)
If ESN (see Appendix) is selected, only the low-order 32 bits of the sequence number are transmitted in the Sequence Number field, although both sender and receiver maintain full 64-bit ESN counters. The high order 32 bits are included in the integrity check in an algorithm/mode-specific fashion, e.g., the high-order 32 bits may be appended after the Next Header field when a separate integrity algorithm is employed.
ESN(Appendixを見る)が選択されるなら、一連番号の下位の32ビットだけがSequence Number分野で伝えられます、送付者と受信機の両方が完全な64ビットのESNカウンタを維持しますが。 保全チェックにモードアルゴリズム/特有のファッションで高位32ビットを含んでいます、別々の保全アルゴリズムが採用しているとき、例えば、Next Header分野の後に高位32ビットを追加するかもしれません。
Note: If a receiver chooses to not enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Use of ESN creates a need for the receiver to manage the anti-replay window (in order to determine the correct value for the high-order bits of the ESN, which are employed in the ICV computation), which is generally contrary to the notion of disabling anti-replay for an SA.
以下に注意してください。 受信機が、SAのために反再生を可能にしないのを選ぶなら、受信機SHOULD NOTはSA管理プロトコルでESNを交渉します。 ESNの使用は受信機が一般にSAのための反再生の無効にすることの概念とは逆にある反再生ウィンドウ(正しい値をICV計算で使われるESNの何高位のビットも決定するために)を管理する必要性を作成します。
3.3.4. Fragmentation
3.3.4. 断片化
If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, which may be a fragment of an IP datagram. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments.
必要なら、断片化は超能力処理の後にIPsec実装の中で実行されます。 その結果、モードを輸送してください。超能力は全体のIPデータグラム(IPに断片化しない)だけに適用されます。 超能力が適用されたIPパケットがそうするかもしれない、それ自体、トンネルモードで、超能力がIPパケットに適用されるということになってください。断片化されて、途中ルータ、および断片がそうしなければならないそのようなものによって超能力処理の前に受信機で組み立て直されてください。(パケットはIPデータグラムの断片であるかもしれません)。 例えば、セキュリティゲートウェイか「スタックでの隆起」か「ワイヤでの隆起」IPsec実装(Security Architectureドキュメントで定義されるように)がトンネルモードを適用するかもしれません。そのような断片への超能力。
NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet.
以下に注意してください。 セクション3.1.1の終わりに言及されるようにモードを輸送してください、スタックで突き当たってください、ワイヤでの隆起実装が最初にローカルアイピー層によって断片化されたパケットを組み立て直し、次に、IPsecを適用し、次に、結果として起こるパケットを断片化しなければならないかもしれないので。
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing.
以下に注意してください。 断片化ヘッダーとしたがって、それがいるかどうか決定するためにすべての拡張ヘッダーを調べるのに、パケットが、IPsec処理の前に組み立て直す必要であるのがIPv6、スタックでの隆起とワイヤでの隆起実装に、必要になるでしょう。
Fragmentation, whether performed by an IPsec implementation or by routers along the path between IPsec peers, significantly reduces performance. Moreover, the requirement for an ESP receiver to accept fragments for reassembly creates denial of service vulnerabilities. Thus, an ESP implementation MAY choose to not support fragmentation and may mark transmitted packets with the DF bit, to facilitate Path MTU (PMTU) discovery. In any case, an ESP implementation MUST
IPsec実装かIPsec同輩の間の経路に沿ったルータによって実行されるか否かに関係なく、断片化は性能をかなり抑えます。 そのうえ、超能力受信機が再アセンブリのために断片を受け入れるという要件はサービスの弱点の否定を作成します。 したがって、超能力実装は、Path MTU(PMTU)発見を容易にするために断片化をサポートしないのを選んで、DFビットで伝えられたパケットをマークするかもしれません。 どのような場合でも、超能力実装はそうしなければなりません。
Kent Standards Track [Page 26] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[26ページ]RFC4303IP
support generation of ICMP PMTU messages (or equivalent internal signaling for native host implementations) to minimize the likelihood of fragmentation. Details of the support required for MTU management are contained in the Security Architecture document.
断片化の見込みを最小にするICMP PMTUメッセージ(または、ネイティブのホスト導入のための同等な内部のシグナリング)の世代をサポートしてください。 MTU管理に必要であるサポートの詳細はSecurity Architectureドキュメントに含まれています。
3.4. Inbound Packet Processing
3.4. 本国行きのパケット処理
3.4.1. Reassembly
3.4.1. Reassembly
If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID.
必要なら、再アセンブリは超能力処理の前に実行されます。 処理のために超能力に提供されたパケットがIP断片であるように見えるか、すなわち、OFFSET分野が非ゼロであるまたはMORE FRAGMENTS旗が設定されるなら、受信機はパケットを捨てなければなりません。 これは監査可能イベントです。 このイベントSHOULDのための監査ログエントリーはSPI値、日付/受付時刻、Source Address、Destination Address、Sequence Number、および(IPv6の)Flow IDを含んでいます。
NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zeroing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet.
以下に注意してください。 パケット再アセンブリに関しては、現在のIPv4仕様はOFFSET分野のゼロかMORE FRAGMENTS旗の開拓地のどちらかを必要としません。 組み立て直されたパケットがIPsec(見かけの断片として捨てられることと対照的に)によって処理されるように、パケットを組み立て直した後にIPコードはこれらの2つのことをしなければなりません。
3.4.2. Security Association Lookup
3.4.2. セキュリティ協会ルックアップ
Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.1. If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.1. (This process is described in more detail in the Security Architecture document.) The SAD entry for the SA also indicates whether the Sequence Number field will be checked, whether 32- or 64-bit sequence numbers are employed for the SA, and whether the (explicit) ICV field should be present (and if so, its size). Also, the SAD entry will specify the algorithms and keys to be employed for decryption and ICV computation (if applicable).
超能力Headerを含むパケットを受け取り次第、受信機はSADのルックアップで適切な(単方向)SAを決定します。 SA、この決断に基づいているユニキャストのために、SPIかSPIがそのうえ、分野について議定書の中で述べます、セクション2.1で説明されるように。 また、実装がマルチキャストトラフィックをサポートするなら、送付先アドレスはルックアップ(SPIに加えた)で使われます、そして、送付者アドレスも使われるかもしれません、セクション2.1で説明されるように。 (このプロセスはさらに詳細にSecurity Architectureドキュメントで説明されます。) そうだとすれば、そして、また、SAのためのSADエントリーは、Sequence Number分野がチェックされるかどうかを示します、32か64ビットの一連番号がSAに使われて、(明白)のICV分野が存在しているべきであるか否かに関係なく(サイズ) また、SADエントリーは、復号化とICV計算に使われるためにアルゴリズムとキーを指定するでしょう(適切であるなら)。
If no valid Security Association exists for this packet, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the cleartext Flow ID.
どんな有効なSecurity Associationもこのパケットのために存在していないなら、受信機はパケットを捨てなければなりません。 これは監査可能イベントです。 このイベントSHOULDのための監査ログエントリーはSPI値、日付/受付時刻、Source Address、Destination Address、Sequence Number、および(IPv6の)cleartext Flow IDを含んでいます。
Kent Standards Track [Page 27] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティが有効搭載量(超能力)であるとカプセル化するケント標準化過程[27ページ]RFC4303IP
(Note that SA management traffic, such as IKE packets, does not need to be processed based on SPI, i.e., one can demultiplex this traffic separately based on Next Protocol and Port fields, for example.)
(すなわち、SPI、1に基づいてIKEパケットなどのようにSA管理トラフィックが処理される必要はないというメモはこのトラフィックが別々にNextプロトコルに基づかせて、例えばPortがさばく「反-マルチプレックス」をそうすることができます)
3.4.3. Sequence Number Verification
3.4.3. 一連番号検証
All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the ESP integrity service also is enabled for the SA, because otherwise the Sequence Number field has not been integrity protected. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below.
すべての超能力実装が、反再生がサービスであるとサポートしなければなりません、使用は、1SAあたり1個のベースで受信機によって可能にされるか、または無効にされるかもしれませんが。 超能力保全サービスもSAのために可能にされない場合、このサービスを可能にしてはいけません、Sequence Number分野がさもなければ、保護された保全でないので。 反再生はマルチキャストSAsと同様にユニキャストに適切です。 しかしながら、この規格はマルチ送付者SA(ユニキャストかマルチキャスト)のための反再生の提供にメカニズムを全く指定しません。 そのようなSAのための反再生メカニズムの交渉(または、手動の構成)がないとき、SAのための一連番号の送付者と受信機の照合が無効にされるのは(交渉か手動の構成で)、お勧めです、以下に述べられるように。
If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.3), if an SA establishment protocol is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection.
受信機がSAのために反再生を可能にしないなら、どんな本国行きのチェックもSequence Numberに実行されません。 しかしながら、送付者の見解から、デフォルトは反再生が受信機で可能にされると仮定することです。SA設立プロトコルが採用しているなら送付者に不要な一連番号モニターとSAセットアップ(セクション3.3.3を見る)をさせるのを避けるために、受信機SHOULDは送付者に通知します、SA設立の間、受信機が反反復操作による保護を提供しないなら。
If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first ESP check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets.
パケットカウンタを受けてください。受信機がこのSAのために反再生サービスを可能にしたならいつのゼロを合わせるかために初期化されて、SAが設立されるというSA MUSTに関する、ことになってください。 それぞれの容認されたパケットに関しては、受信機は、パケットがこのSAの寿命の間に受け取られたいかなる他のパケットのSequence NumberもコピーしないSequence Numberを含むことを確かめなければなりません。 このSHOULD、それが写しパケットの拒絶を促進するためにSAに合わせられた後にパケットに適用された最初の超能力チェックになってください。
ESP permits two-stage verification of packet sequence numbers. This capability is important whenever an ESP implementation (typically the cryptographic module portion thereof) is not capable of performing decryption and/or integrity checking at the same rate as the interface(s) to unprotected networks. If the implementation is capable of such "line rate" operation, then it is not necessary to perform the preliminary verification stage described below.
ESP permits two-stage verification of packet sequence numbers. This capability is important whenever an ESP implementation (typically the cryptographic module portion thereof) is not capable of performing decryption and/or integrity checking at the same rate as the interface(s) to unprotected networks. If the implementation is capable of such "line rate" operation, then it is not necessary to perform the preliminary verification stage described below.
The preliminary Sequence Number check is effected utilizing the Sequence Number value in the ESP Header and is performed prior to integrity checking and decryption. If this preliminary check fails,
The preliminary Sequence Number check is effected utilizing the Sequence Number value in the ESP Header and is performed prior to integrity checking and decryption. If this preliminary check fails,
Kent Standards Track [Page 28] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 28] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
the packet is discarded, thus avoiding the need for any cryptographic operations by the receiver. If the preliminary check is successful, the receiver cannot yet modify its local counter, because the integrity of the Sequence Number has not been verified at this point.
the packet is discarded, thus avoiding the need for any cryptographic operations by the receiver. If the preliminary check is successful, the receiver cannot yet modify its local counter, because the integrity of the Sequence Number has not been verified at this point.
Duplicates are rejected through the use of a sliding receive window. How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.
Duplicates are rejected through the use of a sliding receive window. How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.
The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain sequence numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. If the ESN option is selected for an SA, only the low-order 32 bits of the sequence number are explicitly transmitted, but the receiver employs the full sequence number computed using the high-order 32 bits for the indicated SA (from his local counter) when checking the received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for a single SA as large as 2**32-1 packets. If a larger gap occurs, additional, heuristic checks for re-synchronization of the receiver sequence number counter MAY be employed, as described in the Appendix.)
The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain sequence numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. If the ESN option is selected for an SA, only the low-order 32 bits of the sequence number are explicitly transmitted, but the receiver employs the full sequence number computed using the high-order 32 bits for the indicated SA (from his local counter) when checking the received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for a single SA as large as 2**32-1 packets. If a larger gap occurs, additional, heuristic checks for re-synchronization of the receiver sequence number counter MAY be employed, as described in the Appendix.)
If the received packet falls within the window and is not a duplicate, or if the packet is to the right of the window, and if a separate integrity algorithm is employed, then the receiver proceeds to integrity verification. If a combined mode algorithm is employed, the integrity check is performed along with decryption. In either case, if the integrity check fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the integrity verification succeeds. (If a combined mode algorithm is being used, then the integrity protected Sequence Number must also match the Sequence Number used for anti-replay protection.)
If the received packet falls within the window and is not a duplicate, or if the packet is to the right of the window, and if a separate integrity algorithm is employed, then the receiver proceeds to integrity verification. If a combined mode algorithm is employed, the integrity check is performed along with decryption. In either case, if the integrity check fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the integrity verification succeeds. (If a combined mode algorithm is being used, then the integrity protected Sequence Number must also match the Sequence Number used for anti-replay protection.)
A minimum window size of 32 packets MUST be supported when 32-bit sequence numbers are employed; a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the minimum) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The receive window size
A minimum window size of 32 packets MUST be supported when 32-bit sequence numbers are employed; a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the minimum) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The receive window size
Kent Standards Track [Page 29] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 29] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
should be increased for higher-speed environments, irrespective of assurance issues. Values for minimum and recommended receive window sizes for very high-speed (e.g., multi-gigabit/second) devices are not specified by this standard.
should be increased for higher-speed environments, irrespective of assurance issues. Values for minimum and recommended receive window sizes for very high-speed (e.g., multi-gigabit/second) devices are not specified by this standard.
3.4.4. Integrity Check Value Verification
3.4.4. Integrity Check Value Verification
As with outbound processing, there are several options for inbound processing, based on features of the algorithms employed.
As with outbound processing, there are several options for inbound processing, based on features of the algorithms employed.
3.4.4.1. Separate Confidentiality and Integrity Algorithms
3.4.4.1. Separate Confidentiality and Integrity Algorithms
If separate confidentiality and integrity algorithms are employed processing proceeds as follows:
If separate confidentiality and integrity algorithms are employed processing proceeds as follows:
1. If integrity has been selected, the receiver computes the
ICV over the ESP packet minus the ICV, using the specified
integrity algorithm and verifies that it is the same as the
ICV carried in the packet. Details of the computation are
provided below.
1. If integrity has been selected, the receiver computes the ICV over the ESP packet minus the ICV, using the specified integrity algorithm and verifies that it is the same as the ICV carried in the packet. Details of the computation are provided below.
If the computed and received ICVs match, then the datagram
is valid, and it is accepted. If the test fails, then the
receiver MUST discard the received IP datagram as invalid;
this is an auditable event. The log data SHOULD include the
SPI value, date/time received, Source Address, Destination
Address, the Sequence Number, and (for IPv6) the cleartext
Flow ID.
If the computed and received ICVs match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (for IPv6) the cleartext Flow ID.
Implementation Note:
Implementation Note:
Implementations can use any set of steps that results in the
same result as the following set of steps. Begin by
removing and saving the ICV field. Next check the overall
length of the ESP packet minus the ICV field. If implicit
padding is required, based on the block size of the
integrity algorithm, append zero-filled bytes to the end of
the ESP packet directly after the Next Header field, or
after the high-order 32 bits of the sequence number if ESN
is selected. Perform the ICV computation and compare the
result with the saved value, using the comparison rules
defined by the algorithm specification.
Implementations can use any set of steps that results in the same result as the following set of steps. Begin by removing and saving the ICV field. Next check the overall length of the ESP packet minus the ICV field. If implicit padding is required, based on the block size of the integrity algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field, or after the high-order 32 bits of the sequence number if ESN is selected. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification.
2. The receiver decrypts the ESP Payload Data, Padding, Pad
Length, and Next Header using the key, encryption algorithm,
algorithm mode, and cryptographic synchronization data (if
any), indicated by the SA. As in Section 3.3.2, we speak
here in terms of encryption always being applied because of
2. The receiver decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. As in Section 3.3.2, we speak here in terms of encryption always being applied because of
Kent Standards Track [Page 30] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 30] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
the formatting implications. This is done with the
understanding that "no confidentiality" is offered by using
the NULL encryption algorithm (RFC 2410).
the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm (RFC 2410).
- If explicit cryptographic synchronization data, e.g.,
an IV, is indicated, it is taken from the Payload
field and input to the decryption algorithm as per
the algorithm specification.
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification.
- If implicit cryptographic synchronization data is
indicated, a local version of the IV is constructed
and input to the decryption algorithm as per the
algorithm specification.
- If implicit cryptographic synchronization data is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification.
3. The receiver processes any Padding as specified in the
encryption algorithm specification. If the default padding
scheme (see Section 2.4) has been employed, the receiver
SHOULD inspect the Padding field before removing the padding
prior to passing the decrypted data to the next layer.
3. The receiver processes any Padding as specified in the encryption algorithm specification. If the default padding scheme (see Section 2.4) has been employed, the receiver SHOULD inspect the Padding field before removing the padding prior to passing the decrypted data to the next layer.
4. The receiver checks the Next Header field. If the value is
"59" (no next header), the (dummy) packet is discarded
without further processing.
4. The receiver checks the Next Header field. If the value is "59" (no next header), the (dummy) packet is discarded without further processing.
5. The receiver reconstructs the original IP datagram from:
5. The receiver reconstructs the original IP datagram from:
- for transport mode -- outer IP header plus the
original next layer protocol information in the ESP
Payload field
- for tunnel mode -- the entire IP datagram in the ESP
Payload field.
- for transport mode -- outer IP header plus the original next layer protocol information in the ESP Payload field - for tunnel mode -- the entire IP datagram in the ESP Payload field.
The exact steps for reconstructing the original datagram
depend on the mode (transport or tunnel) and are described
in the Security Architecture document. At a minimum, in an
IPv6 context, the receiver SHOULD ensure that the decrypted
data is 8-byte aligned, to facilitate processing by the
protocol identified in the Next Header field. This
processing "discards" any (optional) TFC padding that has
been added for traffic flow confidentiality. (If present,
this will have been inserted after the IP datagram (or
transport-layer frame) and before the Padding field (see
Section 2.4).)
The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field. This processing "discards" any (optional) TFC padding that has been added for traffic flow confidentiality. (If present, this will have been inserted after the IP datagram (or transport-layer frame) and before the Padding field (see Section 2.4).)
If integrity checking and encryption are performed in parallel, integrity checking MUST be completed before the decrypted packet is passed on for further processing. This order of processing facilitates rapid detection and rejection of replayed or bogus
If integrity checking and encryption are performed in parallel, integrity checking MUST be completed before the decrypted packet is passed on for further processing. This order of processing facilitates rapid detection and rejection of replayed or bogus
Kent Standards Track [Page 31] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 31] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks.
packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks.
Note: If the receiver performs decryption in parallel with integrity checking, care must be taken to avoid possible race conditions with regard to packet access and extraction of the decrypted packet.
Note: If the receiver performs decryption in parallel with integrity checking, care must be taken to avoid possible race conditions with regard to packet access and extraction of the decrypted packet.
3.4.4.2. Combined Confidentiality and Integrity Algorithms
3.4.4.2. Combined Confidentiality and Integrity Algorithms
If a combined confidentiality and integrity algorithm is employed, then the receiver proceeds as follows:
If a combined confidentiality and integrity algorithm is employed, then the receiver proceeds as follows:
1. Decrypts and integrity checks the ESP Payload Data, Padding,
Pad Length, and Next Header, using the key, algorithm,
algorithm mode, and cryptographic synchronization data (if
any), indicated by the SA. The SPI from the ESP header, and
the (receiver) packet counter value (adjusted as required
from the processing described in Section 3.4.3) are inputs
to this algorithm, as they are required for the integrity
check.
1. Decrypts and integrity checks the ESP Payload Data, Padding, Pad Length, and Next Header, using the key, algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. The SPI from the ESP header, and the (receiver) packet counter value (adjusted as required from the processing described in Section 3.4.3) are inputs to this algorithm, as they are required for the integrity check.
- If explicit cryptographic synchronization data, e.g.,
an IV, is indicated, it is taken from the Payload
field and input to the decryption algorithm as per
the algorithm specification.
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification.
- If implicit cryptographic synchronization data, e.g.,
an IV, is indicated, a local version of the IV is
constructed and input to the decryption algorithm as
per the algorithm specification.
- If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification.
2. If the integrity check performed by the combined mode
algorithm fails, the receiver MUST discard the received IP
datagram as invalid; this is an auditable event. The log
data SHOULD include the SPI value, date/time received,
Source Address, Destination Address, the Sequence Number,
and (in IPv6) the cleartext Flow ID.
2. If the integrity check performed by the combined mode algorithm fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the cleartext Flow ID.
3. Process any Padding as specified in the encryption algorithm
specification, if the algorithm has not already done so.
3. Process any Padding as specified in the encryption algorithm specification, if the algorithm has not already done so.
4. The receiver checks the Next Header field. If the value is
"59" (no next header), the (dummy) packet is discarded
without further processing.
4. The receiver checks the Next Header field. If the value is "59" (no next header), the (dummy) packet is discarded without further processing.
5. Extract the original IP datagram (tunnel mode) or
transport-layer frame (transport mode) from the ESP Payload
Data field. This implicitly discards any (optional) padding
5. Extract the original IP datagram (tunnel mode) or transport-layer frame (transport mode) from the ESP Payload Data field. This implicitly discards any (optional) padding
Kent Standards Track [Page 32] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 32] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
that has been added for traffic flow confidentiality. (If
present, the TFC padding will have been inserted after the
IP payload and before the Padding field (see Section 2.4).)
that has been added for traffic flow confidentiality. (If present, the TFC padding will have been inserted after the IP payload and before the Padding field (see Section 2.4).)
4. Auditing
4. Auditing
Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined.
Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined.
- No valid Security Association exists for a session. The
audit log entry for this event SHOULD include the SPI value,
date/time received, Source Address, Destination Address,
Sequence Number, and (for IPv6) the cleartext Flow ID.
- No valid Security Association exists for a session. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (for IPv6) the cleartext Flow ID.
- A packet offered to ESP for processing appears to be an IP
fragment, i.e., the OFFSET field is non-zero or the MORE
FRAGMENTS flag is set. The audit log entry for this event
SHOULD include the SPI value, date/time received, Source
Address, Destination Address, Sequence Number, and (in IPv6)
the Flow ID.
- A packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID.
- Attempt to transmit a packet that would result in Sequence
Number overflow. The audit log entry for this event SHOULD
include the SPI value, current date/time, Source Address,
Destination Address, Sequence Number, and (for IPv6) the
cleartext Flow ID.
- Attempt to transmit a packet that would result in Sequence Number overflow. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination Address, Sequence Number, and (for IPv6) the cleartext Flow ID.
- The received packet fails the anti-replay checks. The audit
log entry for this event SHOULD include the SPI value,
date/time received, Source Address, Destination Address, the
Sequence Number, and (in IPv6) the Flow ID.
- The received packet fails the anti-replay checks. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID.
- The integrity check fails. The audit log entry for this
event SHOULD include the SPI value, date/time received,
Source Address, Destination Address, the Sequence Number, and
(for IPv6) the Flow ID.
- The integrity check fails. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (for IPv6) the Flow ID.
Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the
Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the
Kent Standards Track [Page 33] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 33] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
5. Conformance Requirements
5. Conformance Requirements
Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here for unicast traffic, and MUST comply with all additional packet processing requirements levied by the Security Architecture document [Ken-Arch]. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service requires correct maintenance of the counter state at the sender (across local reboots, etc.), until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus, a compliant implementation SHOULD NOT provide anti-replay service in conjunction with SAs that are manually keyed.
Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here for unicast traffic, and MUST comply with all additional packet processing requirements levied by the Security Architecture document [Ken-Arch]. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service requires correct maintenance of the counter state at the sender (across local reboots, etc.), until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus, a compliant implementation SHOULD NOT provide anti-replay service in conjunction with SAs that are manually keyed.
The mandatory-to-implement algorithms for use with ESP are described in a separate document [Eas04], to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for ESP, MAY be supported.
The mandatory-to-implement algorithms for use with ESP are described in a separate document [Eas04], to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for ESP, MAY be supported.
Because use of encryption in ESP is optional, support for the "NULL" encryption algorithm also is required to maintain consistency with the way ESP services are negotiated. Support for the confidentiality-only service version of ESP is optional. If an implementation offers this service, it MUST also support the negotiation of the "NULL" integrity algorithm. NOTE that although integrity and encryption may each be "NULL" under the circumstances noted above, they MUST NOT both be "NULL".
Because use of encryption in ESP is optional, support for the "NULL" encryption algorithm also is required to maintain consistency with the way ESP services are negotiated. Support for the confidentiality-only service version of ESP is optional. If an implementation offers this service, it MUST also support the negotiation of the "NULL" integrity algorithm. NOTE that although integrity and encryption may each be "NULL" under the circumstances noted above, they MUST NOT both be "NULL".
6. Security Considerations
6. Security Considerations
Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the Security Architecture document.
Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the Security Architecture document.
7. Differences from RFC 2406
7. Differences from RFC 2406
This document differs from RFC 2406 in a number of significant ways.
This document differs from RFC 2406 in a number of significant ways.
o Confidentiality-only service -- now a MAY, not a MUST.
o Confidentiality-only service -- now a MAY, not a MUST.
Kent Standards Track [Page 34] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 34] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
o SPI -- modified to specify a uniform algorithm for SAD lookup
for unicast and multicast SAs, covering a wider range of
multicast technologies. For unicast, the SPI may be used
alone to select an SA, or may be combined with the protocol,
at the option of the receiver. For multicast SAs, the SPI is
combined with the destination address, and optionally the
source address, to select an SA.
o Extended Sequence Number -- added a new option for a 64-bit
sequence number for very high-speed communications. Clarified
sender and receiver processing requirements for multicast SAs
and multi-sender SAs.
o Payload data -- broadened model to accommodate combined mode
algorithms.
o Padding for improved traffic flow confidentiality -- added
requirement to be able to add bytes after the end of the IP
Payload, prior to the beginning of the Padding field.
o Next Header -- added requirement to be able to generate and
discard dummy padding packets (Next Header = 59)
o ICV -- broadened model to accommodate combined mode
algorithms.
o Algorithms -- Added combined confidentiality mode algorithms.
o Moved references to mandatory algorithms to a separate
document.
o Inbound and Outbound packet processing -- there are now two
paths: (1) separate confidentiality and integrity
algorithms and (2) combined confidentiality mode
algorithms. Because of the addition of combined mode
algorithms, the encryption/decryption and integrity sections
have been combined for both inbound and outbound packet
processing.
o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA, or may be combined with the protocol, at the option of the receiver. For multicast SAs, the SPI is combined with the destination address, and optionally the source address, to select an SA. o Extended Sequence Number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. o Payload data -- broadened model to accommodate combined mode algorithms. o Padding for improved traffic flow confidentiality -- added requirement to be able to add bytes after the end of the IP Payload, prior to the beginning of the Padding field. o Next Header -- added requirement to be able to generate and discard dummy padding packets (Next Header = 59) o ICV -- broadened model to accommodate combined mode algorithms. o Algorithms -- Added combined confidentiality mode algorithms. o Moved references to mandatory algorithms to a separate document. o Inbound and Outbound packet processing -- there are now two paths: (1) separate confidentiality and integrity algorithms and (2) combined confidentiality mode algorithms. Because of the addition of combined mode algorithms, the encryption/decryption and integrity sections have been combined for both inbound and outbound packet processing.
8. Backward-Compatibility Considerations
8. Backward-Compatibility Considerations
There is no version number in ESP and no mechanism enabling IPsec peers to discover or negotiate which version of ESP each is using or should use. This section discusses consequent backward-compatibility issues.
There is no version number in ESP and no mechanism enabling IPsec peers to discover or negotiate which version of ESP each is using or should use. This section discusses consequent backward-compatibility issues.
First, if none of the new features available in ESP v3 are employed, then the format of an ESP packet is identical in ESP v2 and v3. If a combined mode encryption algorithm is employed, a feature supported only in ESP v3, then the resulting packet format may differ from the ESP v2 spec. However, a peer who implements only ESP v2 would never negotiate such an algorithm, as they are defined for use only in the ESP v3 context.
First, if none of the new features available in ESP v3 are employed, then the format of an ESP packet is identical in ESP v2 and v3. If a combined mode encryption algorithm is employed, a feature supported only in ESP v3, then the resulting packet format may differ from the ESP v2 spec. However, a peer who implements only ESP v2 would never negotiate such an algorithm, as they are defined for use only in the ESP v3 context.
Kent Standards Track [Page 35] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 35] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Extended Sequence Number (ESN) negotiation is supported by IKE v2 and has been addressed for IKE v1 by the ESN Addendum to the IKE v1 Domain of Interpretation (DOI).
Extended Sequence Number (ESN) negotiation is supported by IKE v2 and has been addressed for IKE v1 by the ESN Addendum to the IKE v1 Domain of Interpretation (DOI).
In the new ESP (v3), we make two provisions to better support traffic flow confidentiality (TFC):
In the new ESP (v3), we make two provisions to better support traffic flow confidentiality (TFC):
- arbitrary padding after the end of an IP packet
- a discard convention using Next Header = 59
- arbitrary padding after the end of an IP packet - a discard convention using Next Header = 59
The first feature is one that should not cause problems for a receiver, since the IP total length field indicates where the IP packet ends. Thus, any TFC padding bytes after the end of the packet should be removed at some point during IP packet processing, after ESP processing, even if the IPsec software does not remove such padding. Thus, this is an ESP v3 feature that a sender can employ irrespective of whether a receiver implements ESP v2 or ESP v3.
The first feature is one that should not cause problems for a receiver, since the IP total length field indicates where the IP packet ends. Thus, any TFC padding bytes after the end of the packet should be removed at some point during IP packet processing, after ESP processing, even if the IPsec software does not remove such padding. Thus, this is an ESP v3 feature that a sender can employ irrespective of whether a receiver implements ESP v2 or ESP v3.
The second feature allows a sender to send a payload that is an arbitrary string of bytes that do not necessarily constitute a well- formed IP packet, inside of a tunnel, for TFC purposes. It is an open question as to what an ESP v2 receiver will do when the Next Header field in an ESP packet contains the value "59". It might discard the packet when it finds an ill-formed IP header, and log this event, but it certainly ought not to crash, because such behavior would constitute a DoS vulnerability relative to traffic received from authenticated peers. Thus this feature is an optimization that an ESP v3 sender can make use of irrespective of whether a receiver implements ESP v2 or ESP v3.
The second feature allows a sender to send a payload that is an arbitrary string of bytes that do not necessarily constitute a well- formed IP packet, inside of a tunnel, for TFC purposes. It is an open question as to what an ESP v2 receiver will do when the Next Header field in an ESP packet contains the value "59". It might discard the packet when it finds an ill-formed IP header, and log this event, but it certainly ought not to crash, because such behavior would constitute a DoS vulnerability relative to traffic received from authenticated peers. Thus this feature is an optimization that an ESP v3 sender can make use of irrespective of whether a receiver implements ESP v2 or ESP v3.
9. Acknowledgements
9. Acknowledgements
The author would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827. Karen Seo deserves special thanks for providing help in the editing of this and the previous version of this specification. The author also would like to thank the members of the IPSEC and MSEC working groups who have contributed to the development of this protocol specification.
The author would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827. Karen Seo deserves special thanks for providing help in the editing of this and the previous version of this specification. The author also would like to thank the members of the IPSEC and MSEC working groups who have contributed to the development of this protocol specification.
10. References
10. References
10.1. Normative References
10.1. Normative References
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
Kent Standards Track [Page 36] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 36] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
10.2. Informative References
10.2. Informative References
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security
Protocols", Proceedings of the Sixth Usenix Unix Security
Symposium, July, 1996.
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996.
[HC03] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", Work in Progress, November 3, 2002.
[HC03] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress, November 3, 2002.
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[Ken-AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[Ken-AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[Kra01] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (Or: How Secure Is SSL?)",
CRYPTO' 2001.
[Kra01] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)", CRYPTO' 2001.
[NIST01] Federal Information Processing Standards Publication 140-2
(FIPS PUB 140-2), "Security Requirements for Cryptographic
Modules", Information Technology Laboratory, National
Institute of Standards and Technology, May 25, 2001.
[NIST01] Federal Information Processing Standards Publication 140-2 (FIPS PUB 140-2), "Security Requirements for Cryptographic Modules", Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[Syverson] P. Syverson, D. Goldschlag, and M. Reed, "Anonymous
Connections and Onion Routing", Proceedings of the
Symposium on Security and Privacy, Oakland, CA, May 1997,
pages 44-54.
[Syverson] P. Syverson, D. Goldschlag, and M. Reed, "Anonymous Connections and Onion Routing", Proceedings of the Symposium on Security and Privacy, Oakland, CA, May 1997, pages 44-54.
Kent Standards Track [Page 37] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Kent Standards Track [Page 37] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Appendix A: Extended (64-bit) Sequence Numbers
Appendix A: Extended (64-bit) Sequence Numbers
A1. Overview
A1. Overview
This appendix describes an extended sequence number (ESN) scheme for use with IPsec (ESP and AH) that employs a 64-bit sequence number, but in which only the low-order 32 bits are transmitted as part of each packet. It covers both the window scheme used to detect replayed packets and the determination of the high-order bits of the sequence number that are used both for replay rejection and for computation of the ICV. It also discusses a mechanism for handling loss of synchronization relative to the (not transmitted) high-order bits.
この付録は64ビットの一連番号を使いますが、下位の32ビットだけがそれぞれのパケットの一部として伝えられるIPsec(超能力とAH)と共に使用の拡張配列番号(ESN)計画について説明します。 それは再生拒絶とICVの計算に使用される再演されたパケットを検出するのに使用される窓の計画と一連番号の高位のビットの決断の両方をカバーしています。 また、それは(伝えられません)高位のビットに比例して同期の取り扱いの損失でメカニズムについて議論します。
A2. Anti-Replay Window
A2。 反再生ウィンドウ
The receiver will maintain an anti-replay window of size W. This window will limit how far out of order a packet can be, relative to the packet with the highest sequence number that has been authenticated so far. (No requirement is established for minimum or recommended sizes for this window, beyond the 32- and 64-packet values already established for 32-bit sequence number windows. However, it is suggested that an implementer scale these values consistent with the interface speed supported by an implementation that makes use of the ESN option. Also, the algorithm described below assumes that the window is no greater than 2^31 packets in width.) All 2^32 sequence numbers associated with any fixed value for the high-order 32 bits (Seqh) will hereafter be called a sequence number subspace. The following table lists pertinent variables and their definitions.
受信機は、サイズW.Thisウィンドウの反再生ウィンドウが遠くにオーダーを、パケットがどう使い果たすことができたかを制限すると主張するでしょう、今までのところ認証された中で最も高い一連番号があるパケットに比例して。 (要件は全く最小の、または、お勧めのサイズのためにこの窓に確立されません、値が既に32ビットの一連番号ウィンドウに確立した32と64パケットを超えて。 しかしながら、implementerがESNオプションを利用する実現で支持されるインタフェース速度と一致したこれらの値をスケーリングすることが提案されます。 また、以下で説明されたアルゴリズムは、窓が幅が2以下^31のパケットであると仮定します。) 高位32ビット(Seqh)でどんな一定の価値にも関連しているすべての2^32の一連番号が今後一連番号部分空間と呼ばれるでしょう。 以下のテーブルは適切な変数と彼らの定義を記載します。
Var. Size
Name (bits) Meaning
---- ------ ---------------------------
W 32 Size of window
T 64 Highest sequence number authenticated so far,
upper bound of window
Tl 32 Lower 32 bits of T
Th 32 Upper 32 bits of T
B 64 Lower bound of window
Bl 32 Lower 32 bits of B
Bh 32 Upper 32 bits of B
Seq 64 Sequence Number of received packet
Seql 32 Lower 32 bits of Seq
Seqh 32 Upper 32 bits of Seq
var. サイズ名(ビット)の意味---- ------ --------------------------- T64Highest一連番号が今までのところ認証した窓、T B64Lowerの32ビットが縛ったSeqのSeq Seqh32Upper32ビットの容認されたパケットSeql32Lower32ビットのB Seq64Sequence NumberのB Bh32Upper32ビットのウィンドウBl32Lower32ビットのT Th32UpperのウィンドウTl32Lower32ビットの上限のW32サイズ
Kent Standards Track [Page 38] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティ有効搭載量(超能力)を要約するケント標準化過程[38ページ]RFC4303IP
When performing the anti-replay check, or when determining which high-order bits to use to authenticate an incoming packet, there are two cases:
反再生チェックを実行するとき、入って来るパケットを認証するのにどの高位のビットを使用したらよいかを決定するとき、2つのケースがあります:
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 1)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 2)
+ ケースA: Tl>=(W--1)。 この場合、1つの一連番号部分空間の中に窓があります。 (図1を参照します) + ケースB: Tl<(W--1)。 この場合、窓は2つの一連番号部分空間にかかります。 (図2を参照します)
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
以下の数字、結論、(「----」、)、ゼロがそれぞれの部分空間の始まりを示していて、2つの連続した一連番号部分空間を示しています。 それの上の2つより少ない線は適用される高次なビットを示しています。 「The」====「窓を表します。」 ****、」 将来の一連番号、すなわち、向こうの現在の最も高い一連番号が認証したもの(ThTl)を表します。
Th+1 *********
+1 *****第****
Th =======*****
th=======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
--0--------+-----+-----0--------+-----------0-- Bl Tl Bl (Bl+2^32) mod 2^32
Figure 1 -- Case A
図1--ケースA
Th ====**************
th====**************
Th-1 ===
-1番目===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
--0-----------------+--0--+--------------+--0-- Bl Tl Bl (Bl+2^32) mod 2^32
Figure 2 -- Case B
図2--ケースB
A2.1. Managing and Using the Anti-Replay Window
A2.1。 反再生ウィンドウを管理して、使用します。
The anti-replay window can be thought of as a string of bits where `W' defines the length of the string. W = T - B + 1 and cannot exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and the top-most bit corresponds to T, and each sequence number from Bl through Tl is represented by a corresponding bit. The value of the bit indicates whether or not a packet with that sequence number has been received and authenticated, so that replays can be detected and rejected.
'W'がストリングの長さを定義する一連のビットとして反再生ウィンドウを考えることができます。 Wは、T--B+1と等しく、値における2^32--1を超えることができません。 最も下部ビットはBに対応しています、そして、最も最高ビットはTに対応しています、そして、BlからTlの各一連番号は対応するビットによって表されます。 ビットの価値は、その一連番号があるパケットが受け取られて、認証されたかどうかを示します、再生を検出して、拒絶できるように。
Kent Standards Track [Page 39] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティ有効搭載量(超能力)を要約するケント標準化過程[39ページ]RFC4303IP
When a packet with a 64-bit sequence number (Seq) greater than T is received and validated,
64ビットの一連番号(Seq)がTより大きいパケットが受け取られて、有効にされるとき
+ B is increased by (Seq - T)
+ (Seq - T) bits are dropped from the low end of the window
+ (Seq - T) bits are added to the high end of the window
+ The top bit is set to indicate that a packet with that sequence
number has been received and authenticated
+ The new bits between T and the top bit are set to indicate that
no packets with those sequence numbers have been received yet.
+ T is set to the new sequence number
+ Bによる(Seq--T)+(Seq--T)によって増加されて、ビットがその一連番号があるパケットが示してください+ トップビットが設定される窓の上位ですが、受け取って、+ (Seq--T)ビットが加えられる窓のローエンドから落とされて、認証されて、+ Tとトップビットの間の新しいビットが、それらの一連番号があるパケットが全くまだ受け取られていないのを示すように設定されるということです。 + Tは新しい一連番号に設定されます。
In checking for replayed packets,
再演されたパケットがないかどうかチェックする際に
+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <=
Tl, then check the corresponding bit in the window to see if
this Seql has already been seen. If yes, reject the packet. If
no, perform integrity check (see Appendix A2.2. below for
determination of Seqh).
+ 場合A:の下で Seql>がBl(どこBl=Tl--W+1)と等しいか、そして、Seql<がTlと等しいなら窓で対応するビットをチェックして、このSeqlが既に見られたかどうか確認してください。 はいなら、パケットを拒絶してください。 いいえなら、保全チェックを実行してください(Seqhの決断における、以下のAppendix A2.2を見てください)。
+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <=
Tl, then check the corresponding bit in the window to see if
this Seql has already been seen. If yes, reject the packet. If
no, perform integrity check (see Appendix A2.2. below for
determination of Seqh).
場合Bの下における+: Seql>=Bl(どこBl=Tl--W+1)OR Seql<がTlと等しいかなら窓で対応するビットをチェックして、このSeqlが既に見られたかどうか確認してください。 はいなら、パケットを拒絶してください。 いいえなら、保全チェックを実行してください(Seqhの決断における、以下のAppendix A2.2を見てください)。
A2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number
A2.2。 一連番号の高次なビット(Seqh)を測定します。
Because only `Seql' will be transmitted with the packet, the receiver must deduce and track the sequence number subspace into which each packet falls, i.e., determine the value of Seqh. The following equations define how to select Seqh under "normal" conditions; see Section A3 for a discussion of how to recover from extreme packet loss.
'Seql'だけ、がパケットで伝えられて、受信機が各パケットが落ちる一連番号部分空間を推論して、追跡しなければならないので、すなわち、Seqhの値を決定してください。 以下の方程式は「正常な」条件のもとでSeqhを選択する方法を定義します。 極端なパケット損失からどう回復するかに関する議論に関してセクションA3を見てください。
+ Under Case A (Figure 1):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ 下のケースA(図1): Seql>がBl(どこBl=Tl--W+1)と等しいかならSeqhがIf Seql<第Bl(どこBl=Tl--W+1)、当時のSeqh=と等しいか、+ 1番目
+ Under Case B (Figure 2):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
場合B(図2)の下における+: Seql>がBl(どこBl=Tl--W+1)、当時のSeqh=と等しいか、第--、1If Seql<Bl(どこBl=Tl--W+1)、当時の第Seqh=
Kent Standards Track [Page 40] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティ有効搭載量(超能力)を要約するケント標準化過程[40ページ]RFC4303IP
A2.3. Pseudo-Code Example
A2.3。 中間コードの例
The following pseudo-code illustrates the above algorithms for anti- replay and integrity checks. The values for `Seql', `Tl', `Th' and `W' are 32-bit unsigned integers. Arithmetic is mod 2^32.
以下の中間コードは反再生のための上のアルゴリズムを例証します、そして、保全はチェックします。 'Seql'、'Tl'、'Th'、および'W'のための値は32ビットの符号のない整数です。 演算はモッズ風の2^32です。
If (Tl >= W - 1) Case A
If (Seql >= Tl - W + 1)
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else
Seqh = Th + 1
If (pass integrity check)
Tl = Seql (shift bits)
Th = Th + 1
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else Case B
If (Seql >= Tl - W + 1)
Seqh = Th - 1
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Seql Passに対応している、(保全チェックを通過します)セットがElse廃棄物パケットElse廃棄物パケットElse If(保全チェックを通過する)Tlの上のパケットに噛み付いて、Seql Passに対応していたなら(パス再生チェック)がSeql(シフトビット)セット・ビットと等しいなら(Tl>=W--1)ケースA If(Seql>=Tl--W+1)Seqhが第If(Seql<はTlと等しい)と等しいなら+ Elseの廃棄物のパケットのElse Seqhの=の1If(保全チェックを通過する)の第Tlの上のパケットがSeqlと等しい、(シフトビット)第等しさ、+ 1番目; セットがElse廃棄物パケットElse Case B If(Seql>=Tl--W+1)Seqh=の上のパケットに噛み付いて、Seql Passに対応していた、第--(パス保全チェック)が(パス再生チェック)であるなら(パス保全チェック)であるならElse廃棄物パケットElse廃棄物パケットElse Seqh=第If(Seql<はTlと等しい)でSeql Passパケットに対応するビットを設定するなら1If(再生チェックを通過する)がElse廃棄物パケットElse廃棄物パケットでSeql Passパケットに対応するビットを設定する
Kent Standards Track [Page 41] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティ有効搭載量(超能力)を要約するケント標準化過程[41ページ]RFC4303IP
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
ほかに、If(保全チェックを通過する)Tl=Seql(シフトビット)はElse廃棄物パケットでSeql Passパケットに対応するビットを設定します。
A3. Handling Loss of Synchronization due to Significant Packet Loss
A3。 Significant Packet LossによるSynchronizationの取り扱いLoss
If there is an undetected packet loss of 2^32 or more consecutive packets on a single SA, then the transmitter and receiver will lose synchronization of the high-order bits, i.e., the equations in Section A2.2. will fail to yield the correct value. Unless this problem is detected and addressed, subsequent packets on this SA will fail authentication checks and be discarded. The following procedure SHOULD be implemented by any IPsec (ESP or AH) implementation that supports the ESN option.
2^32以上の連続したパケットの非検出されたパケット損失が独身のSAにあると、送信機と受信機は高位のビットの同期を失うでしょう、すなわち、セクションA2.2の方程式。正しい値をもたらさないでしょう。 この問題が検出されて、記述されないと、このSAの上のその後のパケットは、認証チェックに失敗して、捨てられるでしょう。 以下の手順SHOULD、ESNオプションをサポートするあらゆるIPsec(超能力かAH)実現で、実行されてください。
Note that this sort of extended traffic loss is likely to be detected at higher layers in most cases, before IPsec would have to invoke the sort of re-synchronization mechanism described in A3.1 and A3.2. If any significant fraction of the traffic on the SA in question is TCP, the source would fail to receive ACKs and would stop sending long before 2^32 packets had been lost. Also, for any bi-directional application, even ones operating above UDP, such an extended outage would likely result in triggering some form of timeout. However, a unidirectional application, operating over UDP, might lack feedback that would cause automatic detection of a loss of this magnitude, hence the motivation to develop a recovery method for this case. Note that the above observations apply to SAs between security gateways, or between hosts, or between host and security gateways.
多くの場合、この種類の拡張交通の損失が、より高い層に検出されそうに注意してください、IPsecがA3.1とA3.2で説明された再同期メカニズムの種類を呼び出さなければならない前に。 問題のSAにおける交通のどれか重要な部分がTCPであるなら、2つの^32パケットが失われたずっと前に、ソースは、ACKsを受け取らないで、発信するのを止めるでしょう。 また、どんな双方向のアプリケーション、UDPの上で作動するもののためにさえも、そのような拡張供給停止はおそらく何らかのフォームのタイムアウトの引き金となるのに結果として生じるでしょう。 しかしながら、UDPの上で作動して、単方向のアプリケーションはこの大きさの損失の自動検出を引き起こすフィードバック、このような場合回復方法を開発するしたがって、動機を欠くかもしれません。 上の観測がセキュリティゲートウェイか、ホストか、ホストとセキュリティゲートウェイの間のSAsに適用されることに注意してください。
The solution we've chosen was selected to:
私たちが選んだ解決策による以下のことが選択されました。
+ minimize the impact on normal traffic processing
+は通常の交通処理への影響を最小にします。
+ avoid creating an opportunity for a new denial of service attack
such as might occur by allowing an attacker to force diversion of
resources to a re-synchronization process
+は、攻撃者が再同期の過程にリソースの転換を強制するのを許容することによって起こるかもしれないようなサービス攻撃の新しい否定の機会を作成するのを避けます。
+ limit the recovery mechanism to the receiver -- because anti-
replay is a service only for the receiver, and the transmitter
generally is not aware of whether the receiver is using sequence
numbers in support of this optional service, it is preferable for
recovery mechanisms to be local to the receiver. This also
allows for backward compatibility.
+は回収機構を受信機に制限します--反再生が受信機のためだけのサービスであり、送信機が受信機がこの任意のサービスを支持して一連番号を使用しているかどうかを一般に意識していないので、回収機構が受信機にローカルであることは、望ましいです。また、これは後方のために互換性を許容します。
Kent Standards Track [Page 42] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティ有効搭載量(超能力)を要約するケント標準化過程[42ページ]RFC4303IP
A3.1. Triggering Re-synchronization
A3.1。 再同期の引き金となります。
For each SA, the receiver records the number of consecutive packets that fail authentication. This count is used to trigger the re- synchronization process, which should be performed in the background or using a separate processor. Receipt of a valid packet on the SA resets the counter to zero. The value used to trigger the re- synchronization process is a local parameter. There is no requirement to support distinct trigger values for different SAs, although an implementer may choose to do so.
各SAに関しては、受信機は認証に失敗する連続したパケットの数を記録します。 このカウントは、バックグラウンドで実行されるべきである再同期の過程の引き金となるのに使用されるか、または別々のプロセッサを使用しています。 SAの上の有効なパケットの領収書はゼロにカウンタをリセットします。 再同期の過程の引き金となるのに使用される値はローカルのパラメタです。 implementerは、そうするのを選ぶかもしれませんが、異なったSAsのために異なった引き金の値を支持するという要件が全くありません。
A3.2. Re-synchronization Process
A3.2。 再同期の過程
When the above trigger point is reached, a "bad" packet is selected for which authentication is retried using successively larger values for the upper half of the sequence number (Seqh). These values are generated by incrementing by one for each retry. The number of retries should be limited, in case this is a packet from the "past" or a bogus packet. The limit value is a local parameter. (Because the Seqh value is implicitly placed after the ESP (or AH) payload, it may be possible to optimize this procedure by executing the integrity algorithm over the packet up to the endpoint of the payload, then compute different candidate ICVs by varying the value of Seqh.) Successful authentication of a packet via this procedure resets the consecutive failure count and sets the value of T to that of the received packet.
上の引き金のポイントに達しているとき、「悪い」パケットは、どの認証が一連番号(Seqh)の上半分に相次ぎより大きい値を使用することで再試行されるかために選択されます。 これらの値は、各再試行あたり1つ増加することによって、発生します。 再試行の数は、これが「過去」のパケットかにせのパケットからのパケットであるといけないので、制限されるべきです。 制限値はローカルのパラメタです。 (Seqh値が超能力(または、AH)ペイロードの後にそれとなく置かれるので、パケットの上で保全アルゴリズムをペイロードの終点まで実行することによってこの手順を最適化して、次に、Seqhの値を変えることによって異なった候補ICVsを計算するのは可能であるかもしれません。) この手順を通したパケットのうまくいっている認証は、容認されたパケットのものに連続した失敗カウントをリセットして、Tの値を設定します。
This solution requires support only on the part of the receiver, thereby allowing for backward compatibility. Also, because re- synchronization efforts would either occur in the background or utilize an additional processor, this solution does not impact traffic processing and a denial of service attack cannot divert resources away from traffic processing.
この解決策は単に受信機側の支持を要して、その結果、後方のために互換性を許容します。 再同期の努力は、バックグラウンドで起こるか、または追加プロセッサを利用するでしょう、また、したがって、この解決策が交通処理に影響を与えません、そして、サービス不能攻撃は交通処理から遠くにリソースを紛らすことができません。
Author's Address
作者のアドレス
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
スティーブンケントBBN技術10モールトン・通りMA02138ケンブリッジ(米国)
Phone: +1 (617) 873-3988 EMail: kent@bbn.com
以下に電話をしてください。 +1 (617) 873-3988 メールしてください: kent@bbn.com
Kent Standards Track [Page 43] RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2005年12月にセキュリティ有効搭載量(超能力)を要約するケント標準化過程[43ページ]RFC4303IP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kent Standards Track [Page 44]
ケント標準化過程[44ページ]
一覧
スポンサーリンク
