[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
<c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970722142031Z-5156@tsntsrv2.timestep
.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>, "'Karen Seo'" <kseo@bbn.com>
Subject: RE: New draft -- IPSEC ESP
Date: Tue, 22 Jul 1997 10:20:31 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
Wasn't "draft-ietf-ipsec-esp-04.txt", released on May 30 as shown below?
From: Karen Seo[SMTP:kseo@bbn.com]
Sent: Friday, May 30, 1997 5:08 PM
To: ipsec@tis.com
Cc: kseo@bbn.com
Subject: New draft -- IPSEC ESP
Network Working Group Stephen Kent, BBN
Corp
Internet Draft Randall Atkinson, @Home
Network
draft-ietf-ipsec-esp-04.txt 30 May
1997
>----------
>From: Karen Seo[SMTP:kseo@bbn.com]
>Sent: Monday, July 21, 1997 6:33 PM
>To: ipsec@tis.com
>Subject: New draft -- IPSEC ESP
>
>
>
>
>Network Working Group Stephen Kent, BBN Corp
>Internet Draft Randall Atkinson, @Home Network
>draft-ietf-ipsec-esp-04.txt 21 July 1997
>
>
>
>
>
>
> IP Encapsulating Security Payload (ESP)
>
>
>
>
>Status of This Memo
>
> This document is an Internet Draft. Internet Drafts are working
> documents of the Internet Engineering Task Force (IETF), its Areas,
> and its working groups. Note that other groups may also distribute
> working documents as Internet Drafts.
>
> Internet Drafts are draft documents valid for a maximum of 6 months.
> Internet Drafts may be updated, replaced, or obsoleted by other
> documents at any time. It is not appropriate to use Internet Drafts
> as reference material or to cite them other than as "work in
> progress".
>
> This particular Internet Draft is a product of the IETF's IPsec
> working group. It is intended that a future version of this draft be
> submitted to the IPng Area Directors and the IESG for possible
> publication as a standards-track protocol.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Kent, Atkinson [Page 1]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
>Table of Contents
>
> 1. Introduction......................................................3
> 2. Encapsulating Security Payload Packet Format......................4
> 2.1 Security Parameters Index....................................5
> 2.2 Sequence Number .............................................5
> 2.3 Payload Data.................................................5
> 2.4 Padding (for Encryption).....................................6
> 2.5 Pad Length...................................................7
> 2.6 Next Header..................................................7
> 2.7 Authentication Data..........................................7
> 3. Encapsulating Security Protocol Processing........................7
> 3.1 ESP Header Location..........................................7
> 3.2 Outbound Packet Processing..................................10
> 3.2.1 Security Association Lookup............................10
> 3.2.2 Sequence Number Generation.............................10
> 3.2.3 Packet Encryption......................................10
> 3.2.3.1 Scope of Encryption................................10
> 3.2.3.2 Encryption Algorithms..............................11
> 3.2.4 Integrity Check Value Calculation......................11
> 3.2.4.1 Scope of Authentication Protection................11
> 3.2.4.2 Authentication Padding............................11
> 3.2.4.3 Authentication Algorithms.........................12
> 3.2.5 Fragmentation..........................................12
> 3.3 Inbound Packet Processing...................................12
> 3.3.1 Pre-ESP Processing Overview............................12
> 3.3.2 Security Association Lookup............................12
> 3.3.3 Sequence Number Verification...........................13
> 3.3.4 Integrity Check Value Verification.....................14
> 3.3.5 Packet Decryption......................................15
> 4. Auditing.........................................................15
> 5. Conformance Requirements.........................................16
> 6. Security Considerations..........................................16
> 7. Differences from RFC 1827........................................16
> Acknowledgements....................................................17
> References..........................................................17
> Disclaimer..........................................................19
> Author Information..................................................19
>
>
>
>
>
>
>
>
>
>
>
>Kent, Atkinson [Page 2]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
>1. Introduction
>
> The Encapsulating Security Payload (ESP) header is designed to
> provide a mix of security services in IPv4 and IPv6. ESP may be
> applied alone, in combination with the IP Authentication Header (AH)
> [KA97b], or in a nested fashion, e.g., through the use of tunnel mode
> (see "Security Architecture for the Internet Protocol" [KA97a],
> hereafter referred to as the Security Architecture document).
> 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 [KA97a].
>
> The ESP header is inserted after the IP header and before the upper
> layer protocol header (transport mode) or before an encapsulated IP
> header (tunnel mode). These modes are described in more detail
> below.
>
> 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. The
> set of services provided depends on options selected at the time of
> Security Association establishment and on the placement of the
> implementation. Confidentiality may be selected independent of all
> other services. However, use of confidentiality without
> integrity/authentication (either in ESP or separately in AH) may
> subject traffic to certain forms of active attacks that could
> undermine the confidentiality service (see [Bel96]. Data origin
> authentication and connectionless integrity are joint services
> (hereafter referred to jointly as "authentication) and are offered as
> an option in conjunction with confidentiality. The anti-replay
> service may be selected only if data origin authentication is
> selected, and its election is solely at the discretion of the
> receiver. Traffic flow confidentiality requires selection of tunnel
> mode, and is most effective if implemented at a security gateway,
> where traffic aggregation may be able to mask true source-destination
> patterns.
>
> It is assumed that the reader is familiar with the terms and concepts
> described in the Security Architecture document. In particular, the
> reader should be familiar with the definitions of security services
> offered by ESP and AH, the concept of Security Associations, the ways
> in which ESP can be used in conjunction with the Authentication
> Header (AH), and the different key management options available for
> ESP and AH. (With regard to the last topic, the current key
> management options required for both AH and ESP are manual keying and
>
>
>Kent, Atkinson [Page 3]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> automated keying via Oakley/ISAKMP.)
>
>2. Encapsulating Security Payload Packet Format
>
>
> The protocol header (IPv4, IPv6, or Extension) immediately preceding the
> ESP header will contain the value 50 in its Protocol (IPv4) or Next
> Header (IPv6, Extension) field [STD-2].
>
> 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) | ^
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth.
> | Sequence Number |
>|Coverage
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | -----
> | Payload Data* (variable) | | ^
> ~ ~ | |
> | | | |
> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid.
> | | Padding (0-255 bytes) |
>|Coverage*
> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
> | | Pad Length | Next Header | v v
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------
> | Authentication Data (variable) |
> ~ ~
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> * If included in the Payload field, cryptographic synchronization
> data, e.g., an IV, usually is not encrypted per se, although it
> often is referred to as being part of the ciphertext.
>
>
>
>
> The following subsections define 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. Whether or not an option
> is selected is defined 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.
>
>
>
>
>
>Kent, Atkinson [Page 4]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
>2.1 Security Parameters Index
>
> The SPI is an arbitrary 32-bit value that uniquely identifies the
> Security Association for this datagram, relative to the destination
> IP address contained in the IP header (with which this security
> header is associated) and relative to the security protocol employed.
> 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. It is ordinarily selected
> by the destination system upon establishment of an SA (see the
> Security Architecture document for more details). (A zero value may
> be used within an ESP implementation for local debugging purposes,
> but no ESP packets should be transmitted with a zero SPI value.) The
> SPI field is mandatory.
>
>2.2 Sequence Number
>
> This unsigned 32-bit field contains a monotonically increasing
> counter value (sequence number). 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.2.2 for more details on how the Sequence Number
> is generated.) 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 2^32nd packet on an SA.
>
> The Sequence Number is mandatory. It is always included in an ESP
> packet, to ensure alignment of the Payload field on an 8-byte
> boundary (in support of IPv6). Even if authentication is not
> selected as a security service for the SA, or if ESP is employed in
> an IPv4 environment, this field MUST be present.
>
> Processing of the Sequence Number field is at the discretion of the
> receiver, i.e., 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 Processing" section below).
>
>
>2.3 Payload Data
>
> Payload Data is a variable-length field containing data 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 MAY be carried explicitly
>
>
>Kent, Atkinson [Page 5]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> in the Payload field. 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. If such
> synchronization data is implicit, the algorithm for deriving the data
> MUST be part of the RFC.
>
>2.4 Padding (for Encryption)
>
> Several factors require or motivate use of the Padding field.
>
>
> 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, Pad Length and
> Next Header fields, as well as the Padding) to the size required
> by the algorithm.
>
> 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 figure above.
>
> Padding beyond that required for the algorithm or alignment
> reasons cited above, may be used to conceal the actual length of
> the payload, in support of (partial) traffic flow
> confidentiality. However, inclusion of such additional padding
> has adverse bandwidth implications and thus its use should be
> undertaken with care.
>
>
> The transmitter MAY add 0-255 bytes of padding. Inclusion of the
> Padding field in an ESP packet is optional, but all implementations
> MUST support generation and consumption of padding.
>
> As a default, 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.)
>
>
>Kent, Atkinson [Page 6]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> Any encryption algorithm that requires Padding other than the default
> described above, MUST define the Padding contents (e.g., zeros or
> random data) and any required receiver processing of these Padding
> bytes in an RFC specifying how the algorithm is used with ESP. In
> such circumstances, the content of the Padding field will be
> determined by the encryption algorithm and mode selected and defined
> in the corresponding algorithm RFC. The relevant algorithm RFC MAY
> specify that a receiver MUST inspect the Padding field or that a
> receiver MUST inform senders of how the receiver will handle the
> Padding field.
>
>2.5 Pad Length
>
> The Pad Length field indicates the number of pad bytes immediately
> preceding it. The range of valid values is 0-255, where a value of
> zero indicates that no Padding bytes are present. The Pad Length
> field is mandatory.
>
>2.6 Next Header
>
> The Next Header is an 8-bit field that identifies the type of data
> contained in the Payload Data field, e.g., an extension header in
> IPv6 or an upper layer protocol identifier. The value of this field
> is chosen from the set of IP Protocol Numbers defined in the most
> recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned
> Numbers Authority (IANA). The Next Header field is mandatory.
>
>2.7 Authentication Data
>
> The Authentication Data is a variable-length field containing an
> Integrity Check Value (ICV) computed over the ESP packet minus the
> Authentication Data. The length of the field depends upon the
> authentication function selected. The mandatory-to-implement
> authentication algorithms, HMAC with MD5 or SHA-1, both yield 96-bit
> ICV's because of the truncation convention (see Section 3.2.4.3)
> adopted for use in IPsec. The Authentication Data field is optional,
> and is included only if the authentication service has been selected
> for the SA in question.
>
>3. Encapsulating Security Protocol Processing
>
> 3.1 ESP Header Location
>
> Like AH, ESP may be employed in two ways: transport mode or tunnel
> mode. The former mode is applicable only to host implementations and
> provides protection for upper layer protocols, but not the IP header.
> (In this mode, note that for "bump-in-the-stack" or "bump-in-the-
>
>
>Kent, Atkinson [Page 7]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> 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.)
>
> In transport mode, ESP is inserted after the IP header and before an
> upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other
> IPsec headers that have already been inserted, e.g., AH. In the
> context of IPv4, this translates to placing ESP after the IP header
> (and any options that it contains), but before the upper layer
> protocol. (Note that the term "transport" mode should not be
> misconstrued as restricting its use to TCP and UDP. For example, an
> ICMP message MAY be sent using either "transport" mode or "tunnel"
> mode.) The following diagram illustrates ESP transport mode
> positioning for a typical IPv4 packet, on a "before and after" basis.
> (The "ESP trailer" encompasses any Padding, plus the Pad Length, and
> Next Header fields.)
>
> BEFORE APPLYING ESP
> ----------------------------
> IPv4 |orig IP hdr | | |
> |(any options)| TCP | Data |
> ----------------------------
>
> AFTER APPLYING ESP
> -------------------------------------------------
> IPv4 |orig IP hdr | ESP | | | ESP | ESP|
> |(any options)| Hdr | TCP | Data | Trailer |Auth|
> -------------------------------------------------
> |<----- encrypted ---->|
> |<------ authenticated ----->|
>
>
> 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. The destination options extension header(s) could appear
> either before or after the ESP header depending on the semantics
> desired. However, since ESP protects only fields after the ESP
> header, it generally may 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.
>
>
>
>
>
>
>Kent, Atkinson [Page 8]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> BEFORE APPLYING ESP
> ---------------------------------------
> IPv6 | | ext hdrs | | |
> | orig IP hdr |if present| TCP | Data |
> ---------------------------------------
>
>
> AFTER APPLYING ESP
> ---------------------------------------------------------
> IPv6 | orig |hxh,rtg,frag|dest|ESP|dest| | | ESP | ESP|
> |IP hdr|if present**|opt*|Hdr|opt*|TCP|Data|Trailer|Auth|
> ---------------------------------------------------------
> |<---- encrypted ---->|
> |<---- authenticated ---->|
>
> * = if present, could be before ESP, after ESP, or both
> ** = hop by hop, routing, fragmentation headers
>
> Tunnel mode ESP may be employed in either hosts or security gateways.
> When ESP is implemented in a security gateway (to protect subscriber
> transit traffic), tunnel mode must be used. In tunnel mode, the
> "inner" IP header carries the ultimate source and destination
> addresses, while an "outer" IP header may contain distinct IP
> addresses, e.g., addresses of security gateways. 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.
>
> -----------------------------------------------------------
> IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
> |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
> -----------------------------------------------------------
> |<--------- encrypted ---------->|
> |<----------- authenticated ---------->|
>
> ---------------------------------------------------------------
> IPv6 | new* | ext hdrs*| | orig*| ext hdrs*| | | ESP | ESP|
> |IP hdr|if present|ESP|IP hdr|if present|TCP|Data|Trailer|Auth|
> ---------------------------------------------------------------
> |<---------- encrypted ----------->|
> |<----------- authenticated ---------->|
>
> * = construction of outer IP hdr/extensions and modification
> of inner IP hdr/extensions is discussed below.
>
>
>
>Kent, Atkinson [Page 9]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
>3.2 Outbound Packet Processing
>
> In transport mode, the transmitter encapsulates the upper layer
> protocol information in the ESP header/trailer, 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 inter-related in a variety of ways. The construction of the
> outer IP header/extensions during the encapsulation process is
> described in the Security Architecture document.
>
>3.2.1 Security Association Lookup
>
> 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.
>
>3.2.2 Sequence Number Generation
>
> As noted in Section 2.2, the Sequence Number field is always included
> in ESP packets, even if the anti-replay service, or the
> authentication service, have not been enabled for the SA. The
> sender's counter is initialized to 0 when an SA is established. The
> transmitter increments the Sequence Number for this SA, checks to
> ensure that the counter has not cycled, and inserts the new value
> into the Sequence Number field. Thus the first packet sent using a
> given SA will have a Sequence Number of 1. A transmitter 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. (Note that this approach to
> Sequence Number management does not require use of modular
> arithmetic.)
>
>3.2.3 Packet Encryption
>
>3.2.3.1 Scope of Encryption
>
> In transport mode, the transmitter encapsulates the original upper
> layer protocol information into the ESP payload field, adds any
> necessary padding, and encrypts the result (Payload Data, Padding,
> Pad Length, and Next Header) using the key, encryption algorithm, and
> algorithm mode indicated by the SA. In tunnel mode, the transmitter
> encapsulates and encrypts the entire original IP datagram (plus the
> Padding, Pad Length, and Next Header).
>
> If authentication is selected, encryption is performed first, before
>
>
>Kent, Atkinson [Page 10]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> the authentication, and the encryption does not encompass the
> Authentication Data 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 attacks. It also allows for the
> possibility of parallel processing of packets at the receiver, i.e.,
> decryption can take place in parallel with authentication. Note that
> since the Authentication Data is not protected by encryption, a keyed
> authentication algorithm must be employed to compute the ICV.
>
>3.2.3.2 Encryption Algorithms
>
>The encryption algorithm employed is specified by the SA. ESP is
>designed for use with symmetric encryption algorithms. Because IP
>packets may arrive out of order, 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 packet header. Since ESP makes provision for
>padding of the plaintext, encryption algorithms employed with ESP may
>exhibit either block or stream mode characteristics.
>
>At the time of writing, one mandatory-to-implement encryption algorithm
>and mode has been defined for ESP. It is based on the Data Encryption
>Standard (DES) [NIST77] in Cipher Block Chaining Mode [NIST80]. Details
>of use of this mode are contained in [MS97].
>
>
>3.2.4 Integrity Check Value Calculation
>
>3.2.4.1 Scope of Authentication Protection
>
> If authentication is selected for the SA, the transmitter computes
> the ICV over the ESP packet minus the Authentication Data. Thus the
> SPI, Sequence Number, Payload Data, Padding (if present), Pad Length,
> and Next Header are all encompassed by the ICV computation. Note
> that the last 4 fields will be in ciphertext form, since encryption
> is performed prior to authentication.
>
>3.2.4.2 Authentication Padding
>
> For some authentication algorithms, the byte string over which the
> ICV computation is performed must be a multiple of a blocksize
> specified by the algorithm. If the length of this byte string does
> not match the blocksize requirements for the algorithm, implicit
> padding MUST be appended to the end of the ESP packet, prior to ICV
> computation. The padding octets MUST have a value of zero. The
>
>
>Kent, Atkinson [Page 11]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> blocksize (and hence the length of the padding) is specified by the
> algorithm specification. This padding is not transmitted with the
> packet.
>
>3.2.4.3 Authentication Algorithms
>
> The authentication algorithm employed for the ICV computation is
> specified by the SA. For point-to-point communication, suitable
> authentication algorithms include keyed Message Authentication Codes
> (MACs) based on symmetric encryption algorithms (e.g., DES) or on
> one-way hash functions (e.g., MD5 or SHA-1). For multicast
> communication, one-way hash algorithms combined with asymmetric
> signature algorithms are suitable. As of this writing, the
> mandatory-to-implement authentication algorithms are based on the
> former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5
> [Riv92]. The output of the HMAC computation is truncated to the
> leftmost 96 bits. Other algorithms, possibly with different ICV
> lengths, MAY be supported.
>
>3.2.5 Fragmentation
>
> 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, the
> payload of which may be a fragmented IP packet. 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.
>
>3.3 Inbound Packet Processing
>
>3.3.1 Pre-ESP Processing Overview
>
> If required, reassembly is performed prior to ESP processing.
>
>3.3.2 Security Association Lookup
>
> Upon receipt of a (reassembled) packet containing an ESP Header, the
> receiver determines the appropriate (unidirectional) SA, based on the
> destination IP address and the SPI. (This process is described in
> more detail in the Security Architecture document.) The SA indicates
> whether the Authentication Data field should be present, and it will
> specify the algorithms and keys to be employed for decryption and ICV
> computations (if applicable).
>
>
>Kent, Atkinson [Page 12]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> If no valid Security Association exists for this session (for
> example, the receiver has no key), 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, Source Address,
> Destination Address, and (in IPv6) the cleartext Flow ID.
>
>3.3.3 Sequence Number Verification
>
> All ESP implementations MUST support the anti-replay service, though
> its use may be enabled or disabled on a per-SA basis. This service
> MUST NOT be enabled unless the authentication service also is enabled
> for the SA, since otherwise the Sequence Number field has not been
> integrity protected. (Note that there are no provisions for managing
> transmitted Sequence Number values among multiple senders directing
> traffic to a single, multicast SA. Thus the anti-replay service
> SHOULD NOT be used in a multi-sender multicast environment that
> employs a single, multicast SA.) If an SA establishment protocol
> such as Oakley/ISAKMP is employed, then the receiver SHOULD notify
> the transmitter, during SA establishment, if the receiver will
> provide anti-replay protection and SHOULD inform the transmitter of
> the window size.
>
> If the receiver enables 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.
>
> 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.) A MINIMUM window size of 32 MUST be supported; but a
> window size of 64 is preferred and SHOULD be employed as the default.
> A window size of 64 or larger MAY be chosen by the receiver. If a
> larger window size is chosen, it MUST be a multiple of 32. If any
> window size other than the default of 64 is employed by the receiver,
> it MUST be reported to the transmitter during SA negotiation.
>
> 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. An efficient means for
> performing this check, based on the use of a bit mask, is described
>
>
>Kent, Atkinson [Page 13]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> in the Security Architecture document.
>
> If the received packet falls within the window and is new, or if the
> packet is to the right of the window, then the receiver proceeds to
> ICV verification. If the ICV validation 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, Source Address, Destination Address, the Sequence
> Number, and (in IPv6) the Flow ID. The receive window is updated
> only if the ICV verification succeeds.
>
> DISCUSSION:
>
> Note that if the packet is either inside the window and new, or is
> outside the window on the "right" side, the receiver MUST
> authenticate the packet before updating the Sequence Number window
> data.
>
>3.3.4 Integrity Check Value Verification
>
> If authentication has been selected, the receiver computes the ICV
> over the ESP packet minus the Authentication Data using the specified
> authentication algorithm and verifies that it is the same as the ICV
> included in the Authentication Data field of the packet. Details of
> the computation are provided below.
>
> If the computed and received ICV's 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, and (in IPv6) the
> cleartext Flow ID.
>
> DISCUSSION:
>
> Begin by removing and saving the ICV value (Authentication Data
> field). Next check the overall length of the ESP packet minus the
> Authentication Data. If implicit padding is required, based on
> the blocksize of the authentication algorithm, append zero-filled
> bytes to the end of the ESP packet directly after the Next Header
> field. Perform the ICV computation and compare the result with
> the saved value. (For the mandatory-to-implement authentication
> algorithms, HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5
> [Riv92], the output of the HMAC computation is truncated to the
> leftmost 96 bits. Other algorithms may have different ICV
> lengths.) (If a digital signature and one-way hash are used for
> the ICV computation, the matching process is more complex and will
>
>
>Kent, Atkinson [Page 14]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> be described in the algorithm specification.)
>
>
>3.3.5 Packet Decryption
>
> The receiver decrypts the ESP Payload Data, Padding, Pad Length, and
> Next Header using the session key that has been established for this
> traffic. If an explicit IV is present in the Payload Field, it is
> input to the decryption algorithm as per the algorithm specification.
> If an implicit IV is employed, a local version of the IV is
> constructed and input to the decryption algorithm as per the
> algorithm specification. (Decryption may take place in parallel with
> authentication, but care must be taken to avoid possible race
> conditions with regard to packet access and reconstruction of the
> decrypted packet.)
>
> After decryption, the original IP datagram is reconstructed and
> processed per the normal IP protocol specification. The exact steps
> for reconstructing the original datagram depend on the mode (tunnel
> vs transport) 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.
>
> Note that there are two ways in which the decryption can "fail". The
> selected SA may not be correct or the encrypted ESP packet could be
> corrupted. (The latter case would be detected if authentication is
> selected for the SA, as would tampering with the SPI. However, an SA
> mismatch might still occur due to tampering with the IP Destination
> Address.) In either case, the erroneous result of the decryption
> operation (an invalid IP datagram or transport-layer frame) will not
> necessarily be detected by IPsec, and is the responsibility of later
> protocol processing.
>
>
>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. 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
>
>
>Kent, Atkinson [Page 15]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> result in audit log entries. There is no requirement for the
> receiver to transmit any message to the purported transmitter in
> response to the detection of an auditable event, because of the
> potential to induce denial of service via such action.
>
>5. Conformance Requirements
>
> Implementations that claim conformance or compliance with this
> specification MUST implement the ESP syntax and processing described
> here and MUST comply with all requirements of the Security
> Architecture document. If the key used to compute an ICV is manually
> distributed, correct provision of the anti-replay service would
> require correct maintenance of the counter state at the transmitter,
> 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 this service in
> conjunction with SAs that are manually keyed. A compliant ESP
> implementation MUST support the following mandatory-to-implement
> algorithms (specified in [KBC97] and in [MS97].
>
> - DES in CBC mode
> - HMAC with MD5
> - HMAC with SHA-1
>
>
>
>6. Security Considerations
>
> Security is central to the design of this protocol, and this security
> considerations permeate the specification. Additional security-
> relevant aspects of using IPsec protocol are discussed in the
> Security Architecture document.
>
>
>7. Differences from RFC 1827
>
> This document differs from RFC 1827 [ATK95] in several significant
> ways. The major difference is that, this document attempts to
> specify a complete framework and context for ESP, whereas RFC 1827
> provided a "shell" that was completed through the definition of
> transforms. The combinatorial growth of transforms motivated the
> reformulation of the ESP specification as a more complete document,
> with options for security services that may be offered in the context
> of ESP. Thus, fields previously defined in transform documents are
> now part of this base ESP specification. For example, the fields
> necessary to support authentication (and anti-replay) are now defined
> here, even though the provision of this service is an option. The
>
>
>Kent, Atkinson [Page 16]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> fields used to support padding for encryption, and for next protocol
> identification, are now defined here as well. Packet processing
> consistent with the definition of these fields also is included in
> the document.
>
>
>Acknowledgements
>
> Many of the concepts embodied in this specification were derived from
> or influenced by the US Government's SP3 security protocol, ISO/IEC's
> NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92
> IB93].
>
> For over 2 years, this document has evolved through multiple versions
> and iterations. During this time, many people have contributed
> significant ideas and energy to the process and the documents
> themselves. The authors would like to thank Karen Seo for providing
> extensive help in the review, editing, background research, and
> coordination for this version of the specification. The authors
> would also like to thank the members of the IPSEC and IPng working
> groups, with special mention of the efforts of (in alphabetic order):
> Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David
> Mihelcic, Hilarie Orman, William Simpson and Nina Yuan.
>
>References
>
>
> [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC
> 1827, August 1997.
>
> [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP
> Protocol Suite", ACM Computer Communications Review, Vol.
> 19, No. 2, March 1989.
>
> [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security
> Protocols", Proceedings of the Sixth Usenix Unix Security
> Symposium, July, 1996.
>
> [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing
> Attacks and Hijacked Terminal Connections", CA-95:01,
> January 1995. Available via anonymous ftp from
> info.cert.org.
>
> [DH95] Steve Deering & Robert Hinden, Internet Protocol Version 6
> (Ipv6) Specification, RFC 1883, December 1995.
>
> [IB93] John Ioannidis & Matt Blaze, "Architecture and
>
>
>Kent, Atkinson [Page 17]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> 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] Steve Kent, Randall Atkinson, "Security Architecture for
> the Internet Protocol", Internet Draft, ?? 1997.
>
> [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header",
> Internet Draft, ?? 1997.
>
> [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC:
> Keyed-Hashing for Message Authentication", RFC-2104,
> February 1997.
>
> [Ken91] Steve Kent, "US DoD Security Options for the Internet
> Protocol (IPSO)", RFC-1108, November 1991.
>
> [MS97] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform",
> RFC-xxxx, August 1997.
>
> [NIST77] US National Bureau of Standards, "Data Encryption
> Standard", Federal Information Processing Standard (FIPS)
> Publication 46, January 1977.
>
> [NIST80] US National Bureau of Standards, "DES Modes of Operation"
> Federal Information Processing Standard (FIPS) Publication
> 81, December 1980.
>
> [NIST81] US National Bureau of Standards, "Guidelines for
> Implementing and Using the Data Encryption Standard",
> Federal Information Processing Standard (FIPS) Publication
> 74, April 1981.
>
> [NIST88] US National Bureau of Standards, "Data Encryption
> Standard", Federal Information Processing Standard (FIPS)
> Publication 46-1, January 1988.
>
> [Riv92] Ronald Rivest, "The MD5 Message Digest Algorithm," RFC-
> 1321, April 1992.
>
> [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995
>
> [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20
>
>
>Kent, Atkinson [Page 18]
>
>
>Internet Draft IP Encapsulating 21 July 1997
> Security Payload (ESP)
>
>
> October 1994.
>
> [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons,
> New York, NY, 1994. ISBN 0-471-59756-2
>
> [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3,
> Document SDN.301, Revision 1.5, 15 May 1989, as published
> in NIST Publication NIST-IR-90-4250, February 1990.
>
>
>Disclaimer
>
> The views and specification here are those of the authors and are not
> necessarily those of their employers. The authors and their
> employers specifically disclaim responsibility for any problems
> arising from correct or incorrect implementation or use of this
> specification.
>
>
>
>Author Information
>
> Stephen Kent
> BBN Corporation
> 70 Fawcett Street
> Cambridge, MA 02140
> USA
> E-mail: kent@bbn.com
> Telephone: +1 (617) 873-3988
>
> Randall Atkinson
> @Home Network
> 385 Ravendale Drive
> Mountain View, CA 94043
> USA
> E-mail: rja@inet.org
>
>
>
>
>
>
>
>
>
>
>
>
>
>Kent, Atkinson [Page 19]
>
>
>