Rfc2406: IP encapsulation security payload (ESP)

Organization: China Interactive publishing network (http://www.china-pub.com /)
RFC document Chinese Translation Plan (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: ouyang@china-pub.com
Sword zxl1025@chinese.com (sword)
Release date:
Copyright: The copyright of this Chinese translation document belongs to China Interactive publishing network. This document can be freely reproduced for non-commercial purposes, but the translation and copyright information of this document must be kept.

Network Working Group
Request for comments: 2406
Obsoletes: 1827
Category: Standards track

S. Kent
BBN Corp
R. Atkinson
@ Home Network
November 1998

Memorandum status

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 information

Copyright (c) the Internet Society (1998). All rights reserved.

1. Introduction

Encapsulation security load header provides a hybrid security service in IPv4 and IPv6. ESP can be applied separately, used together with the IP address Authentication Header (AH), or nested, for example, tunnel mode (see "security architecture for the Internet Protocol" [ka97a], the "security architecture document" is used in place below ). Security services can be implemented between one communication host, one communication security gateway, or one security gateway and one host. For more information about how to use ESP and AH in various network environments, see the security architecture documentation.

The ESP header can be inserted after the IP header, before the upper-layer protocol header (Transfer Mode), or before the encapsulated IP header (tunnel mode ). The following describes the modes in detail.

ESP provides confidentiality, data source verification, connectionless integrity, anti-replay Service (a form of partially sequential integrity), and limited information stream confidentiality. This set of services provided is determined by the options and implementation location selected during SA creation. The selection of confidentiality is independent of all other services. However, ensuring confidentiality without integrity/verification (in ESP or in AH alone) may make information vulnerable to attacks that disrupt the confidentiality service of an activity (see [bel96]). Data source verification and connectionless integrity (collectively referred to as "verification") are interrelated services that are provided to users as an option in combination with confidentiality (optional. The anti-replay service can be selected only when the data source is selected for verification. The recipient determines the selection of the anti-replay service separately. (Although the sender is required to increase the serial number used by the anti-replay service by default, the service is valid only when the receiver checks the serial number .) The tunnel mode is required for the confidentiality of information flows. If the confidentiality of information flows is most effective on the security net, information aggregation can conceal the real source-destination mode. Note that although confidentiality and authentication are optional, at least one of them must be selected.

It is assumed that the reader is familiar with the terms and concepts described in the security architecture document. In particular, readers should be familiar with the definitions of security services provided by ESP and AH. The SA definition can be used in combination with the authentication (AH) header, and different key management options used by ESP and AH. (For the last item, the current key management options required by ESP and Ah are manually created and automatically created using Ike [hc98].)

Keyword must, must not, required, shall, shall not, shocould, shocould not, recommended, May, and optional. When they appear in this document, the description in rfc2119 explains their meaning [bra97].

2. encapsulation security payload group format

After the ESP header is closely followed by the protocol header (IPv4, IPv6, or extension), the protocol header's protocol field (IPv4) will be 50, or the next protocol header (IPv6, extension) field [STD-2] value is 50.

 

* If data is encrypted and synchronized, for example, the initialization vector (IV, see Section 2.3) is included in the payload field, it is usually not encrypted, although it is often used as part of the ciphertext.

The following section defines fields in the header format. "Optional" means that this field is ignored if it is not selected. That is, it is neither included in the transfer group nor included in the calculation of the Integrity check value (icv, see 2.7. When a SA is created, it determines whether to select an option. Therefore, the format of the ESP group is determined for the given SA, and the SA survival period is also determined. Relatively speaking, the mandatory field always appears in the ESP group format, for all SAS.

2.1 security parameter index SPI

SPI is an arbitrary 32-bit value. It is combined with the destination IP address and Security Protocol (ESP) to uniquely identify the SA of the datagram. The SPI values from 1 to 255 are reserved for future use by Internet Assigned Numbers Authority (IANA). Except for the use of the assigned SPI values, generally, IANA does not allocate reserved SPI values. Generally, SPI is selected for the target system when the SA is created (for details, see the security architecture document ). The SPI field is mandatory.

If the SPI value is 0, it is reserved for local use and specific implementation, and cannot be sent online. For example, the key management implementation can use the value 0 of SPI to indicate that when the IPsec implementation requires its key management entity to create a new SA, but the SA is still not created, "No SA exists ".

2.2 serial number sequence number

This unsigned, 32-bit field contains a monotonically increasing counter value (serial number ). It is mandatory, even if the receiver does not choose to activate a specific SA's anti-replay service, it always exists. The serial number field is processed by the receiver, that is, the sender must always transmit this field, but the receiver does not need to perform operations on it (see the discussion on serial number confirmation in "inbound group processing" below ).

The sender's counter and the receiver's counter are initialized to 0 when a SA is created. (The serial number 1 of the first group sent with the given SA; for details about how the serial number is generated, see section 3.3.3.) If the anti-replay service is activated (by default), the transmitted serial number must never allow loops. Therefore, before sending a 2nd 32-Power Group to SA, the sender counter and receiver counter must be reset (by creating a new SA and getting a new key)

2.3 payload data

The payload data is a variable-length field that contains the data described in the next header field. The payload data field is mandatory, and its length is an integer multiple of the byte. If the payload encryption algorithm requires data encryption and synchronization, such as the initialization vector (IV), this data can be explicitly loaded in the payload field. Any encryption algorithm that requires such clarity and Data Synchronization in each group must specify the length, structure, and location of the synchronized data, which is part of an RFC that specifies how the algorithms in ESP use. If the data to be synchronized is implicit, the algorithm for deriving data must be part of the RFC.

Note that when IV exists (actual), ciphertext alignment:
For some operations based on the IV mode, the receiver uses the IV as the beginning of the ciphertext and directly transmits the IV to the algorithm. In these modes, whether or not the (actual) ciphertext begins to be aligned is not important to the receiver.
In some cases, the receiver reads IV separately from the ciphertext. In this case, the algorithm specification must address the (actual) Implementation of ciphertext alignment.

2.4 fill (for encryption)

Several factors require or enable the use of fill fields.
If the encryption algorithm used requires that the plaintext be a multiple of a certain number of bytes, such as the block size of block cipher, fill in the plaintext (including the payload data, fill length, next header field, and fill) with the fill field to achieve the length required by the algorithm.
Regardless of the encryption algorithm requirements, you can also fill fields to ensure that the result ciphertext ends at a 4-byte boundary. In particular, the fill length field and the next header field must be right aligned within 4 bytes, as shown in the ESP grouping format, to ensure that the validation data field (if any) is aligned with a 4-byte boundary.
In addition to algorithm requirements or the alignment reasons mentioned above, the filling field can be used to hide the actual length of the payload and support (partial) information stream confidentiality. However, this extra fill field occupies a certain amount of bandwidth, so use it with caution.

The sender can add 0 to 255 bytes. Fields in the ESP group are optional, but all implementations must support generating and consuming fields.
To ensure that the encryption bit is a multiple of the size of the algorithm block (the First Weighting number above), the fill calculation is applied to the payload data, fill length, and next header field except the IV.
To ensure that the verification data is aligned with a 4-byte boundary (the second inner number above), the fill calculation is applied to the payload data that contains IV, the fill length, and the next header field.

If you need to fill in the byte, but the encryption algorithm does not specify the filling content, you must use the following default processing. The padding byte is initialized using a series of (unsigned, 1 byte) integer values. The first filling byte appended to the plain text is 1, and the following filling byte increases monotonically: 1, 2, 3 ,.... When this fill scheme is used, the receiver should check the fill field. (This scheme is selected because it is relatively simple and easy to implement in hardware. In the absence of other integrity measures, if the receiver checks the decrypted padding value, this solution breaks down some form of "cut and paste" attacks and provides limited protection .)

Any encryption algorithm that requires field filling, but different from the above default method, must define the field filling content (for example, 0 or random number) in an RFC that specifies how the ESP algorithm uses) and all requests from the receiver to process these padding bytes. In this case, the content of the filled field is determined by the encryption algorithm and mode defined and selected by the corresponding algorithm RFC. Related algorithm RFC can specify that the receiver must check the filled field or the receiver must notify the sender receiver how to handle the filled field.

2.5 fill length pad length

The fill length field specifies the number of bytes that are filled immediately before it. The valid value ranges from 0 to, indicating that no Bytes are filled. Filling length fields are mandatory.

2.6 next Header

The next header is an 8-bit field that identifies the Data Type contained in the payload field, for example, an extended header in IPv6 or an upper-layer protocol identifier. This field value is selected from the IP protocol number set defined by Internet Assigned Numbers Authority (IANA) latest "Assigned Numbers" [STD-2] RFC. The next header field is mandatory.

2.7 verification data

Verification data is a variable length field that contains an integrity check value (icv). The calculation of this value in the ESP group does not contain the verification data. The field length is specified by the selected verification function. The verification data field is optional. Only the authentication service selected by SA contains the verification data field. To verify the algorithm specification, you must specify the length of the icv, the comparison rules for verification, and the processing steps.

3. encapsulation security protocol processing

3.1 ESP header Positioning

Similar to Ah, esp can be used in either the transfer mode or tunnel mode. The former is only implemented in the host, providing protection for upper-layer protocols, and not protection for IP headers. (In transfer mode, pay attention to the implementation of "Block in stack" or "Block in line" defined in the security architecture document, inbound and Outbound IP address fragmentation may require IPSec to implement additional IP address reorganization/fragmentation to provide transparent IPSec support in accordance with this specification. When multiple interfaces exist, be especially careful when performing these operations internally .)

In transfer mode, ESP is inserted after the IP header, before the upper-layer protocol, such as TCP, UCP, ICMP, or before any inserted IPSec header. In IPv4, ESP is placed after the IP header (and any other options it contains), but before the upper-layer protocol. (Note that the term "transmission" should not be misinterpreted as limiting its application to TCP or UDP. For example, ICMP messages may be sent in transmission or tunnel mode .) The following figure shows the location of the ESP transmission mode in a typical IPv4 group, which is based on "representing a sharp contrast in the field. (The "ESP tail" contains all fills, plus the fill length and the next header field .)

 

In IPv6, ESP is regarded as an end-to-end payload. Therefore, it should appear after the hop-by-hop, route, and fragment extension headers. The target option extension header can be either before or after the ESP header, which is determined by the expected semantics. However, because ESP only protects fields after ESP, it may be willing to put the destination option header behind the ESP header. The following figure shows the location of the ESP transfer mode in a typical IPv6 group.

 

* = If yes, the ESP should be followed by ESP, or the ESP and Ah headers should be combined in various modes. The IPSec architecture document describes the SA combinations that must be supported.

Tunnel mode ESP can be implemented on the host or security net. ESP must adopt tunnel mode when implementing security gateway (protecting user transmission traffic. In tunneling mode, the "internal" IP header loads the final source and destination addresses, while the "external" IP header may contain different IP addresses, such as the security gateway address. ESP protects the entire internal IP group, including the entire internal IP address header. Compared with the external IP address header, the ESP position in tunnel mode is the same as that in transport mode. The following figure shows the location of the ESP tunnel mode in the classic IPv4 and IPv6 groups.

 

* = If any, the structure of the external IP Address Header/extension and the modification of the internal IP Address Header/extension are discussed below.

3.2 Algorithm

The mandatory implementation algorithm is described in Section 5th, "consistency requirements ". However, other algorithms are supported. Note that although confidentiality and authentication are optional, You must select at least one of the two services. Therefore, the two algorithms cannot be both null.

3.2.1 Encryption Algorithm

The encryption algorithm is specified by SA. ESP uses symmetric encryption algorithms. Because the IP groups that arrive may be out of order, each group must carry all the required data to allow the recipient to decrypt and establish encrypted synchronization. This data may be explicitly loaded in the payload field, for example, as IV (described above), or the data can be derived from the grouping header. Because ESP is filled with plain text, the encryption algorithm used by ESP can display block or stream mode features. Note that encryption (confidentiality) is optional. This algorithm can be "null"

3.2.2 Verification Algorithm

The verification algorithm used by icv computing is specified by SA. During point-to-point communication, the appropriate verification algorithms include symmetric encryption algorithms (such as des) or one-way hash functions (such as MD5 or SHA-1)-based key message authentication code (MAC ). For multi-point transmission communication, the one-way hashing algorithm and asymmetric digital signature algorithm are suitable for use, although the current performance and space considerations prevent the use of this algorithm. Note that verification is optional. This algorithm can be "null ".

3.3 Outbound group processing

In transmission mode, the sender encapsulates the upper-layer protocol information in the ESP Header/tail, and retains the specified IP header (and all IP address extension headers in IPv6 ). In tunneling mode, external and internal IP addresses/extension headers are related in various ways. The construction of the external IP header/extension header during encapsulation processing is described in the security architecture document. If the security policy requires more than one IPSec header extension, the security header application sequence must be defined by the security policy.

3.3.1 SA search

ESP is applied to an outbound group only when the IPsec implementation is determined to be associated with a SA that calls ESP processing. The security architecture document describes the IPsec processing process for the Outbound group.

3.3.2 Group encryption

In this section, due to the meaning of formatting, we will describe it based on the frequently used encryption algorithms. You need to understand the "no confidentiality" provided by the null encryption algorithm ". Therefore, the sender:

1. encapsulation (to the ESP payload field ):
Transfer Mode-only original upper-layer protocol information is available.
Tunnel mode-the entire original IP datagram.

2. Add all the required fills.

3. Use the keys, encryption algorithms, algorithm modes, and encrypted data synchronization (if needed) as specified by SA to encrypt the results.
If explicitly encrypted synchronization data, for example, IV, is entered to the encryption algorithm through algorithm specifications and placed in the payload field.
If it is indicated that implicit encryption is used to synchronize data, for example, IV, it is created and entered through the encryption algorithm specification.

The exact steps for building an external IP header depend on the mode (transport or tunnel) and are described in the security architecture document.

If verification is selected, encryption is performed before verification, and encryption does not contain verification data fields. This processing sequence is easy for the receiver to quickly detect and reject group replay or counterfeit groups before group decryption, thus potentially reducing the impact of denial-of-service attacks. At the same time, it also considers the possibility of parallel grouping processing by the receiver, that is, encryption can be executed concurrently with verification. Note that because the verification data is not encrypted and protected, you must use a key verification algorithm to calculate icv.

3.3.3 generation of serial numbers

When SA is created, the sender's counter is initialized to 0. The sender adds a serial number to the SA and inserts the new value into the serial number field. The first group sent with the given SA has serial number 1.

If the anti-replay service is activated (default), the sender checks to ensure that the counter has no loops before the serial number field inserts a new value. In other words, the sender is not allowed to send a group that causes serial number loops on a SA. An audit event is an attempt to transmit a group that may cause serial number overflow. (Note that this serial number management method does not require a modulo operation)

The sender assumes that the anti-replay service is supported by default, unless otherwise announced by the recipient (see 3.4.3 ). Therefore, if the counter is already circulating, the sender creates a new SA and key (unless SA is configured as a manual key management ).

If the anti-replay service is disabled, the sender does not need to monitor or set the counter to a bit. For example, in the case of manual key management (see section 5th ). However, the sender still adds the counter value. When it reaches the maximum value, the counter returns 0 and starts.

3.3.4 integrity check Value Calculation

If SA selects verification, the sender calculates icv on the ESP group but does not contain verification data. Therefore, SPI, serial number, payload data, fill (if any), fill length, and the next header field are included in the icv calculation. Note that because encryption is performed before verification, the last four fields will be in the ciphertext format.

In some verification algorithms, the byte string used for icv calculation must be a multiple of the block size specified by the algorithm. If the length of this Byte string does not match the block size required by the algorithm, you must add implicit padding at the end of the ESP group (after the next header field) before the icv calculation. The value of filling the eight-digit group must be 0. The algorithm specification specifies the block size (and thus the fill length ). This fill is not transmitted with the group. Note that the MD5 and SHA-1 padding protocols are regarded as 1-byte blocks.

3.3.5 multipart

If necessary, IPSec implements internal ESP processing and then performs sharding. Therefore, the transfer mode ESP is applied to the entire IP datagram (instead of the IP segment ). The groups processed by ESP can be sliced by the router on the way. The receiver of such segments must be restructured before the ESP processing. In tunneling mode, ESP is applied to an IP group, and its payload may be a sharded IP group. For example, the security gateway, the block in the stack, or the IPsec Implementation of the block on the line (defined in the security architecture documentation) can apply the tunnel mode ESP to such fragments.

Note: As mentioned in Transfer Mode-section 3.1, the block implementation on the block and line in the stack can be performed by the local IP layer first to reorganize the sharded group, and then apply IPSec, then, the results are grouped into parts.

Note: For block implementation in the IPv6-stack block and On-line block, it is necessary to check all the extension headers to determine whether there is a shard header, so as to determine whether the group needs to be restructured before IPSec processing.

3.4 inbound group processing

3.4.1 restructuring

If required, reorganize before ESP processing. If the group to be processed by ESP is an IP segment, that is, the value of the Offset field is not 0, or the position of the more fragments flag, the receiver must discard the group. This is an Audit Event. The audit log entries of this event should include the SPI value, receipt date/time, source address, Destination Address, serial number, and (IPv6) information stream ID.

Note: For group reorganization, the current IPv4 specification does not require the offset field to be cleared as 0 or more fragments. In order for the reorganized group to be processed by IPSec (which is opposite to discarding a partition in appearance), the IP code must complete these two tasks after reorganizing a group.

3.4.2 SA search

When receiving a (restructured) group containing the ESP header, the receiver determines the appropriate (untargeted) SA Based on the destination IP address, security protocol (ESP), and SPI. (More detailed information about this process is described in the security architecture document.) SA indicates whether the serial number field is verified to verify whether the data field exists. It will specify decryption and icv calculation (if applicable) algorithm and key used.

If the current session does not have a valid SA (for example, the receiver does not have a key), the receiver must discard the group. This is an auditable event. The audit log entries of this event should include the SPI value, received date/time, source address, Destination Address, serial number, and (IPv6) plaintext information stream ID.

3.4.3 confirm serial number

All ESP implementations must support the anti-replay service, although it can be activated or disabled by the receiver based on each SA. If SA's authentication service is not activated, this service cannot be activated. Otherwise, the serial number field is not fully protected. (When multiple senders control traffic to a single SA (whether the destination address is unicast, broadcast, Or multicast), note that there is no measure to manage the serial number value transmitted between these senders. Therefore, the anti-replay service should not be used in environments where multiple senders use a unique SA)

If the receiver does not activate SA's anti-replay service, the serial number is not checked for inbound traffic. However, from the sender's point of view, it is assumed that the receiver activates the anti-replay service. To avoid unnecessary serial number monitoring by the receiver and SA establishment (see 3.3.3), if a protocol such as Ike is established using SA, if the receiver does not provide anti-replay protection during SA establishment, then the receiver should notify the sender.

If the receiver has activated the anti-replay service for this SA, the SA receiving group counter must be initialized to 0 when the SA is created. For each receiving group, the receiver must confirm that the group contains the serial number, and the serial number does not repeat the serial number of any other group that has been received during the SA lifecycle. This should be the first ESP test performed on the group after the group matches a SA to accelerate the rejection of repeated groups.

The Group repetition is rejected by sliding the Receiving Window. (How to implement a window is a local task, but the following describes the functions that must be displayed.) The minimum window size of 32 bits must be supported. However, the 64-bit window size is preferred, it should be used by default. Other window sizes (larger than the minimum window size) are selected by the receiver. (The recipient will not announce the size of the sender's window .)

The "right" boundary of the window represents the highest valid serial number value received by the SA. The group whose serial number is smaller than the "Left" boundary of the window is rejected. Groups that fall into the window are verified by the list of received groups in the window. This test is described in the security architecture document based on the bit mask.

If the received group falls into the window and is new, or if the group is on the right side of the window, the Receiver performs icv validation. If the icv validity fails, the receiver must discard the received IP datagram as illegal; this is an auditable event. This event audit log table item should include the SPI value, received date/time, source address, Destination Address, serial number, and (in IPv6) information stream ID. Only when icv is confirmed to be successful, the recipient will be updated in the window.

Discussion:

Note: If the group is both in the window and new, or in the "right" outside the window, the receiver must verify the group before updating the serial number window data.

3.4.4 integrity check value validation integrity check value verification

If verification is selected, the receiver uses the specified verification algorithm to calculate icv for the ESP group, but does not contain the verification data field. Make sure it is the same as the icv contained in the group verification data field. The computing details are provided below.

If the calculated value matches the received icv, the datagram is valid and can be received. If the test fails, the receiver must discard the received IP datagram as an invalid one; this is an auditable event. The log data should include the SPI value, received date/time, source address, Destination Address, serial number, and (in IPv6) plaintext information stream ID.

Discussion:

Start from deleting and saving the icv value (verifying the data field. The entire ESP length after the verification data field is removed from the next check. If implicit padding is required because of the block size of the verification algorithm, the bytes with 0 padding are directly appended to the end of the ESP group after the next header field. Perform the icv calculation and compare the result with the saved value using the comparison rules defined by the algorithm specification. (For example, if icv computing uses digital signatures and one-way hashes, the matching process is more complex .)

3.4.5 group decryption

In section 3.3.2 "group encryption", due to the meaning of formatting, we often use encryption to describe it. Null encryption algorithms must be used to provide "non-Confidentiality ". Therefore, the receiver:

1. Use the key, encryption algorithm, algorithm mode, and encrypted synchronization data (if any) specified by SA to decrypt ESP payload data, fill, fill length, and next header.
If explicit encryption is used to encrypt and synchronize data, for example, IV, the data is encrypted from the payload field and entered into the decryption algorithm according to the algorithm specifications.
If it indicates that the data is implicitly encrypted and synchronized, for example, IV, the local version IV is constructed and entered into the decryption algorithm according to the algorithm specifications.

2. process the filling specified in all encryption algorithm specifications. If the default filling scheme is used (see section 2.4), the receiver should check the filling fields before transmitting the decrypted data to the next layer and before deleting the filled data.

3. Re-construct the original IP datagram using: reconstructs the original IP datainfrom:
Transfer Mode-original upper-layer protocol information in the original IP header and ESP payload field
Tunnel mode-the whole IP datagram in the tunnel IP header + ESP payload field.

The exact steps for rebuilding the original datagram depend on the mode (transfer or tunnel) as described in the security architecture document. To the minimum extent, in the IPv6 environment, the receiver should ensure that the decrypted data is 8-byte alignment, making the protocol of the next header field identification easier to process.

If verification is selected, validation and decryption can be performed one by one or in parallel. If you implement them one by one, icv verification should be performed first. For parallel execution, the verification must be completed before the decrypted group is passed for further processing. This processing sequence facilitates the receiver to quickly detect and replay groups or counterfeit group dentions before decryption groups, thus potentially reducing the impact of Service Denial attacks.

Note: If the receiver decrypts the data and is in parallel with the verification, be careful not to compete for group access and restructuring of decrypted groups.

Note the following situations: note that there are several ways in which the decryption can "fail ":
The selected SA may be incorrect-Sa is incorrectly selected due to SPI, destination address, or IPSec protocol type field tampering. If such an error maps the group to another existing SA, they cannot identify the destroyed group (Case C ). The tampered SPI can be detected through verification. However, sa mismatch may still occur because the IP address or the IPSec protocol type field is tampered.
The fill length or fill value may be incorrect-whether or not verification is performed, the wrong fill length or fill value can be detected.
Encrypted ESP groups may be damaged-this can be detected if SA chooses to verify.

In the case of (a) or (c), the incorrect decryption result (an illegal IP datagram or transport layer frame) will not be detected by IPSec, this is the responsibility of subsequent protocol processing.

4. Review

Not all systems that implement ESP are audited. However, if you merge ESP into a system that supports audit, the ESP implementation must support audit and must allow the system administrator to activate or disable ESP audit. In most cases, the audit granularity is local. However, this specification identifies several auditable events. For each of these events, it defines a minimum set of information that should be included in the audit log. Of course, it can also contain additional information. Additional events not explicitly stated in this specification can also generate audit log table items.

The receiver is not required to send any information to the claimed sender in response to the detection of the Audit Event, because this may cause service denial.

5. Consistency requirements

The implementation of consistency or compliance with this specification must implement the ESP syntax and the process described here, which must comply with all requirements in the security architecture documentation. If the keys used by the calculation icv are manually distributed, the correct provision of the anti-replay service requires that the sender's counter status be properly maintained until the key is updated. If the Counter Overflow is about to happen, there may be no automatic recovery measures. Therefore, an adaptation implementation should not be combined with manually typed SA to provide the anti-replay service. An algorithm compliant with ESP must support the following mandatory implementations:
CBC mode des [md97]
HMAC-MD5 [mg97a]
HMAC-SHA-1 [mg97b]
Null Verification Algorithm
Null Encryption Algorithm

Because ESP encryption and verification are optional, the support for the two "null" algorithms requires consistency between the maintenance and negotiation methods of these services. Note that authentication and encryption can be "null", but both are not allowed to be "null ".

6. security considerations

Security is the center of this protocol design, so security considerations run through the entire specification. Additional security related content using the IPSec protocol is discussed in the security architecture document.

7. Different from RFC 1827

This document differs from RFC 1827 [atk95] in several important aspects. The main difference is that this document attempts to specify a complete framework and context for ESP, while RFC 1827 provides a "shell" that can be improved through the definition of conversion. The addition of conversion promotes the re-improvement of the ESP specification into a more comprehensive document, and adds the security service options provided in the ESP context. Therefore, fields previously defined in the conversion document are now part of this basic ESP specification. For example, fields that support verification (and anti-replay) are defined here, even if the service is optional.

The fields that support encryption and the filling fields for the next protocol verification are also defined here. The group processing that is consistent with the definition of these fields is also included in the document ..

Thank you

Authorization of the concepts embodied in this specification were derived from or influenced by the US government's SP3 security protocol, ISO/IEC's nlsp, or from the proposed swipe security protocol. [sdns89, iso92, ib93].

For over 3 years, this document has evolved through multiple versions and iterations. during this time, please people have contributed significant ideas and energy to the process and the specified ents themselves. the authors wowould like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the Specification. the authors wocould also like to thank the members of the IPsec and IPng Working Groups, with special mention of the efforts of (in alphabetic order): Steve bellovin, Steve Deering, Phil Karn, perry Metzger, David mihelcic, hilarie Orman, Norman Shulman, William Simpson and Nina yuan.

Bibliography
[Atk95] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[Bel96] Steven M. bellovin, "problem areas for the IP Security Protocols", Proceedings of the sixth usenix UNIX Security Symposium, July, 1996.
[Bra97] bradner, S., "key words for use in rfcs to indicate requirement level", BCP 14, RFC 2119, March 1997.
[Hc98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Ib93] John ioannidis & Matt blze, "Architecture and Implementation of Network-layer security under Unix", Proceedings of the usenix Security Symposium, Santa Clara, CA, October 1993.
[Iso92] ISO/IEC JTC1/SC6, network layer security protocol, ISO-IEC dis 11577, international standards organisation, Geneva, Switzerland, 29 November 1992.
[Ka97a] Kent, S., and R. Atkinson, "security architecture for the Internet Protocol", RFC 2401, November 1998.
[Ka97b] Kent, S., and R. Atkinson, "ip Authentication Header", RFC 2402, November 1998.
[Md97] Madson, C., and N. doraswamy, "the ESP DES-CBC Cipher Algorithm with explicit IV", RFC 2405, November 1998.
[Mg97a] Madson, C., and R. Glenn, "the use of HMAC-MD5-96 within ESP and ah", RFC 2403, November 1998.
[Mg97b] Madson, C., and R. Glenn, "the use of HMAC-SHA-1-96 within ESP and ah", RFC 2404, November 1998.
[STD-2] Renault, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[Sdns89] SDNs secure data network system, security protocol 3, SP3, document sdn.301, Revision 1.5, 15 May 1989, as published in NIST publication NIST-IR-90-4250, February 1990.

Disclause

The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems specification.

Author Information

Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Phone: + 1 (617) 873-3988
Email: kent@bbn.com

Randall Atkinson
@ Home Network
425 Broadway,
Redwood City, CA 94063
USA
Phone: + 1 (415) 569-5000
Email: rja@corp.home.net

Full copyright statement

Copyright (c) the Internet Society (1998). All rights reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are supported ded on all such copies and derivative works. however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, cannot T as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet standards process must be followed, or as required to translate it into versions ages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "as is" basis and the Internet Society and the Internet Engineering Task Force disclaims all warranties, express or implied, including but not limited to any warranty that the use of the information herein will not infringe any rights or any implied warranties of merchantability or fitness for a particle purpose.