Subject: IPsec -- new versions of AH and ESP

From: Karen Seo <[email-masked]>
Date: Mon, 3 Mar 2003 14:04:39 -0500

My apologies for the previous line-noise version of this email.  It 
looked fine on my screen but the intervening mail forwarding systems 
mangled it.  Hopefully, this version will be more readable.

Folks,

We just submitted new versions of the AH and ESP IDs to the IETF secretariat.
This email describes the changes that were made and one as yet unresolved
issue.
	A. multicast
		+ how should one demux inbound multicast traffic?
		+ how should sequence numbering/anti-replay be
		  handled
	B. tunnel vs transport mode -- when should each mode be used?
	C. mandatory algorithms -- should these be removed from the
	   AH and ESP drafts in a manner analogous to their removal
             from IKE?
	D. miscellaneous other changes, e.g.,:
	     AH
		- correction to table describing header fields
		- changed text re: use of 51 in Protocol or Next
		  Header field from "will" to "SHALL"

	     ESP
		- correction to tunnel mode processing in Section
		  3.4.4.1

	     AH & ESP
		- added text to ESP to define byte order within cypher
		  block. This is already stated in 2401, but someone
		  requested that it also be put in ESP.

Some edits to the two IDs are not included in this email, e.g., correcting
typos, simplifying/clarifying text, updating references, etc.

Thank you,
Karen

****************************************************************************

A. Multicast:  Based on discussion with the multicast security working
     group, we have made the following changes:

     Authentication Header (AH)
     ==========================

     2.4 Security Parameters Index (SPI) -- paragraph 1, last sentence

     From:
       The SPI field is mandatory.

     To:
       The SPI field is mandatory and the mechanism for mapping inbound
       traffic to unicast SAs described above MUST be supported by all
       AH implementations.

     2.4 Security Parameters Index (SPI) -- paragraph 2

     From:
       For multicast SAs, the SPI (and optionally the protocol ID) in
       combination with the destination address is used to select an SA.
       This is because multicast SAs are defined by a multicast
       controller, not by each IPsec receiver. (See the Security
       Architecture document for more details.)

     To:
       IPsec implementations SHOULD be prepared to support both unicast
       and multicast SAs using the following algorithm for mapping inbound
       IPsec datagrams to SAs. Each entry in the Security Association
       Database (SAD) [KA97a] must indicate whether the SA lookup makes
       use of the source and destination IP addresses, in addition to the
       SPI (and, optionally, the protocol field). Nominally, this
       indication can be represented by two bits, one associated with the
       source IP address and the other for the destination IP address. A
       "1" value for each bit indicates the need to match against the
       corresponding address field as part of the SA lookup process. Thus,
       for example, unicast SAs would have both bits set to zero, since
       neither the source nor destination IP address is used for SA
       matching. (Only the SPI, and, optionally, the protocol field are
       employed.) For multicast methods that rely only on the destination
       address to specify a multicast group, only the second bit would be
       set to "1," implying the need to use the destination address plus
       the SPI (and, optionally the protocol) to determine the appropriate
       SA. For multicast methods (e.g., SSM [HCO3]) that also require the
       source address to identify a multicast group, both bits would be
       set to "1." (There is no current requirement to support SA mapping
       based on the source address but not the destination address, thus
       one of the possible four values is not meaningful.) The indication
       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.

     2.5.1 Extended (64-bit) Sequence Number -- paragraph 1, added
           sentence at end of paragraph

     Added:
       (The ESN feature is applicable to multicast as well as unicast
       SAs.)

     3.2  Integrity Algorithms -- paragraph 1

     From:
       The authentication algorithm employed for the ICV computation is
       specified by the SA. For point-to-point communication, suitable
       integrity algorithms include keyed Message Authentication Codes
       (MACs) based on symmetric encryption algorithms (e.g., AES [AES]
       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 appropriate, though performance and space
       considerations currently preclude use of such algorithms.....

     To:
       The integrity algorithm employed for the ICV computation is
       specified by the SA.  For point-to-point communication, suitable
       integrity algorithms include keyed Message Authentication Codes
       (MACs) based on symmetric encryption algorithms (e.g., AES [AES]
       or on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.).
       For multicast communication, a variety of cryptographic strategies
       for providing integrity have been developed and research continues
       in this area.....

     3.3.2  Sequence Number Generation -- paragraph 4, added sentence

     From:
       If anti-replay is disabled (as noted above), the sender does not
       need to monitor or reset the counter, e.g., in the case of manual
       key management (see Section 5).  However, the sender still
       increments the counter and when it reaches the maximum value, the
       counter rolls over back to zero.

     To:
       If anti-replay is disabled (as noted above), the sender does not
       need to monitor or reset the counter, e.g., in the case of manual
       key management (see Section 5).  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
       the scope of this standard are negotiated between the sender and
       receiver.)

     3.4.2  Security Association Lookup -- paragraph 1

     From:
       Upon receipt of a packet containing an IP Authentication
       Header, the receiver determines the appropriate (unidirectional)
       SA, based on the destination IP address, security protocol (AH),
       and the SPI.....

     To:
       Upon receipt of a packet containing an IP Authentication 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.4.  For multicast SAs, the destination address is also
       employed in the lookup (in addition to the SPI and, optionally
       the protocol), and the sender address also may be employed, as
       described in Section 2.4....

     3.4.3  Sequence Number Verification -- paragraph 1

     From:
       All AH implementations MUST support the anti-replay service,
       though its use may be enabled or disabled by the receiver on a
       per-SA basis.  (Note that there are no provisions for managing
       transmitted Sequence Number values among multiple senders
       directing traffic to a single SA (irrespective of whether the
       destination address is unicast, broadcast, or multicast).  Thus
       the anti-replay service SHOULD NOT be used in a multi-sender
       environment that employs a single SA.)

     To:
       All AH implementations MUST support the anti-replay service,
       though its use may be enabled or disabled by the receiver on a
       per-SA basis. 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.

     7.  Differences from RFC 2402 -- first bullet

     From:
       o SPI -- modified to better reflect the differences between
       unicast and multicast SA lookups.  For unicast, the SPI may be
       used alone to select an SA; for multicast, the SPI is combined
       with destination address to select an SA.

     To:
       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; for multicast, the SPI is combined with the destination
       address, and optionally the source address, to select an SA.  If
       the receiver (unicast) or the multicast controller (multicast)
       opted to use the security protocol (AH) in selecting the SPI,
       then the security protocol is also used in the lookup.

       (I had the security protocol as (ESP) -- am I correct to
       assume that was a boo-boo?)

     7.  Differences from RFC 2402 -- second bullet

     From:
       o Sequence number -- added a new option for a 64-bit sequence
       number for very high-speed communications.

     To:
       o 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.

     Encapsulating Security Payload (ESP)
     ====================================

     2.1  Security Parameters Index -- 1 and 2

     From:
       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). Since the SPI value is generated by the receiver,
       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.

     To:
       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. 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).
       Since, for unicast SAs, the SPI value is generated by the receiver,
       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. The SPI field is mandatory and the
       mechanism for mapping inbound traffic to unicast SAs described
       above MUST be supported by all ESP implementations.

    2.1 Security Parameters Index (SPI) -- paragraph 3

     From:
       For multicast SAs, the SPI (and optionally the protocol ID) in
       combination with the destination address is used to select an SA.
       This is because multicast SAs are defined by a multicast
       controller, not by each IPsec receiver. (See the Security
       Architecture document for more details.)

     To:
       IPsec implementations SHOULD be prepared to support both unicast
       and multicast SAs using the following algorithm for mapping inbound
       IPsec datagrams to SAs. Each entry in the Security Association
       Database (SAD) [KA97a] must indicate whether the SA lookup makes
       use of the source and destination IP addresses, in addition to the
       SPI (and, optionally, the protocol field). Nominally, this
       indication can be represented by two bits, one associated with the
       source IP address and the other for the destination IP address. A
       "1" value for each bit indicates the need to match against the
       corresponding address field as part of the SA lookup process. Thus,
       for example, unicast SAs would have both bits set to zero, since
       neither the source nor destination IP address is used for SA
       matching. (Only the SPI, and, optionally, the protocol field are
       employed.) For multicast methods that rely only on the destination
       address to specify a multicast group, only the second bit would be
       set to "1," implying the need to use the destination address plus
       the SPI (and, optionally the protocol) to determine the appropriate
       SA. For multicast methods (e.g., SSM [cite]) that also require the
       source address to identify a multicast group, both bits would be
       set to "1." (There is no current requirement to support SA mapping
       based on the source address but not the destination address, thus
       one of the possible four values is not meaningful.) The indication
       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.

     2.2.1 Extended (64-bit) Sequence Number -- paragraph 1, added
           sentence at end of paragraph

     Added:
       (The ESN feature is applicable to multicast as well as unicast
       SAs.)

     3.3.3  Sequence Number Generation -- paragraph 4, added sentence

     From:
       If anti-replay is disabled (as noted above), the sender does not
       need to monitor or reset the counter, e.g., in the case of manual
       key management (see Section 5).  However, the sender still
       increments the counter and when it reaches the maximum value, the
       counter rolls over back to zero.

     To:
       If anti-replay is disabled (as noted above), the sender does not
       need to monitor or reset the counter, e.g., in the case of manual
       key management (see Section 5).  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
       the scope of this standard are negotiated between the sender and
       receiver.)

     3.4.2  Security Association Lookup -- paragraph 1

     From:
       Upon receipt of a packet containing an ESP Header, the
       receiver determines the appropriate (unidirectional) SA, based
       on the SPI alone (unicast) or SPI combined with destination IP
       address (multicast)....

     To:
       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.  For
       multicast SAs, the destination address is also employed in the
       lookup (in addition to the SPI and, optionally the protocol),
       and the sender address also may be employed, as described in
       Section 2.1.....

     3.4.3  Sequence Number Verification -- paragraph 1

     From:
       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. (Note that there are no provisions for managing
       transmitted Sequence Number values among multiple senders
       directing traffic to a single SA (irrespective of whether the
       destination address is unicast, broadcast, or multicast).  Thus
       the anti-replay service SHOULD NOT be used in a multi-sender
       environment that employs a single SA.)

     To:
       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, since 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.

     7.  Differences from RFC 2402 -- second bullet

     From:
       o SPI -- modified to better reflect the differences between
       unicast and multicast SA lookups.  For unicast, the SPI may be
       used alone to select an SA; for multicast, the SPI is combined
       with destination address to select an SA.

     To:
       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; for multicast, the SPI is combined with the destination
       address, and optionally the source address, to select an SA.  If
       the receiver (unicast) or the multicast controller (multicast)
       opted to use the security protocol (ESP) in selecting the SPI,
       then the security protocol is also used in the lookup.

     7.  Differences from RFC 2402 -- third bullet

     From:
       o Sequence number -- added a new option for a 64-bit sequence
       number for very high-speed communications.

     To:
       o 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.

****************************************************************************

B. Tunnel vs Transport mode -- A design team is still discussing how
     IPsec should deal with tunneling in various contexts.  It seems
     likely that we will change the current processing flow in 2401,
     and redefine the rules on when to use tunnel mode vs. transport
     mode, e.g., to better accommodate overlay nets, PPVPN
     applications, etc.  However, to facilitate moving the AH and ESP
     specs to Last Call, we have:
	a. changed "upper layer protocol" to "next layer protocol"
	   throughout these 2 specs
	b. removed the text in these two specs that says WHEN to use
	   these modes and deferred that to the Architecture spec
	   (2401bis). The AH and ESP specs will continue to discuss
	   the transport and tunnel mechanisms and the Architecture
	   spec will describe when to use them.

     Authentication Header (AH)
     ==========================

     1. Introduction -- paragraph 3

     From:
       AH may be applied alone, in combination with the IP Encapsulating
       Security Payload (ESP) [KA97b], or in a nested fashion through the
       use of tunnel mode (see "Security Architecture for the Internet
       Protocol" [KA97a], hereafter referred to as the Security
       Architecture document).

     To:
       AH may be applied alone, in combination with the IP Encapsulating
       Security Payload (ESP) [KA97b], or in a nested fashion (see
       "Security Architecture for the Internet Protocol" [KA97a],
       hereafter referred to as the Security Architecture document).

     3.1  Authentication Header Location -- paragraph 1

     From (some of this text was moved to Section 3.1.1 -- see below)
       Like ESP, AH 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, in addition to
       selected IP header fields.  (In this mode, note that 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.)

     To:
       Like ESP, AH may be employed in two ways: transport mode or tunnel
       mode.  (See the Security Architecture document for a description of
       when each should be used.)

     3.1  Authentication Header Location -- paragraph 2, sentence 1

     From:
       AH provides authentication for as much of the IP header as
       possible, as well as for upper level protocol data....

     To:
       AH provides authentication for as much of the IP header as
       possible, as well as for next level protocol data....

     3.1.1 Transport Mode -- paragraph 1, sentences 1 and 2

     From:
       In transport mode, AH 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.  In the
       context of IPv4, this calls for placing AH after the IP header
       (and any options that it contains), but before the upper layer
       protocol.....

     To:
       In transport mode, AH is inserted after the IP header and before
       a next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any
       other IPsec headers that have already been inserted.  In the
       context of IPv4, this calls for placing AH after the IP header
       (and any options that it contains), but before the next layer
       protocol.....

     3.1.1 Transport Mode -- paragraph 1, deleted sentence 5

     From:
       (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.)

     To:
       (Note that the term "transport" mode should not be misconstrued
       as restricting its use to TCP and UDP.)

     3.1.1 Transport Mode -- added at the end of this section some of
     the text removed from 3.1 (see above)

       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.

     3.1.2 Tunnel Mode

     From:
       Tunnel mode AH may be employed in either hosts or security gateways
       (or in so-called "bump-in-the-stack" or "bump-in-the-wire"
       implementations, as defined in the Security Architecture document).
       When AH is implemented in a security gateway (to protect 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, AH protects the
       entire inner IP packet, including the entire inner IP header. The
       position of AH in tunnel mode, relative to the outer IP header, is
       the same as for AH in transport mode.  The following diagram
       illustrates AH tunnel mode positioning for typical IPv4 and IPv6
       packets.

     To:
       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. In tunnel mode, AH protects the entire inner
       IP packet, including the entire inner IP header. The position
       of AH in tunnel mode, relative to the outer IP header, is the
       same as for AH in transport mode.  The following diagram
       illustrates AH tunnel mode positioning for typical IPv4 and IPv6
       packets.

     3.3  Outbound Packet Processing -- paragraph 1, sentence 1

     From:
       In transport mode, the sender inserts the AH header after the IP
       header and before an upper layer protocol header, as described
       above.....

     To:
       In transport mode, the sender inserts the AH header after the IP
       header and before a next layer protocol header, as described
       above.....

     3.3  Outbound Packet Processing -- paragraph 2

     Deleted (To be addressed in Architecture document):
       If there is more than one IPsec header/extension required, the
       order of the application of the security headers MUST be defined
       by security policy.  For simplicity of processing, each IPsec
       header SHOULD ignore the existence (i.e., not zero the contents or
       try to predict the contents) of IPsec headers to be applied later.
       (While a native IP or bump-in-the-stack implementation could
       predict the contents of later IPsec headers that it applies
       itself, it won't be possible for it to predict any IPsec headers
       added by a bump-in-the-wire implementation between the host and
       the network.)

     3.3.3  Integrity Check Value Calculation -- paragraph 1, bullet 3

     From:
       The AH ICV is computed over:
         o....
         o....
         o the upper level protocol data, which is assumed to be
           immutable in transit

     To:
       The AH ICV is computed over:
         o....
         o....
         o the next level protocol data, which is assumed to be
           immutable in transit

     3.3.4  Fragmentation -- paragraph 2

     From:
       NOTE: For transport mode -- As mentioned at the beginning of Section
       3.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.

     To:
       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.

     Encapsulating Security Payload (ESP)
     ====================================

     1.  Introduction -- paragraph 1, sentence 2

     From:
       ESP may be applied alone, in combination with the IP
       Authentication Header (AH) [KA98b], or in a nested fashion, e.g.,
       through the use of tunnel mode (see "Security Architecture for
       the Internet Protocol" [KA98a], hereafter referred to as the
       Security Architecture document).

     To:
       ESP may be applied alone, in combination with the IP
       Authentication Header (AH) [KA98b], or in a nested fashion,
       (see "Security Architecture for the Internet Protocol" [KA98a],
       hereafter referred to as the Security Architecture document).

     1.  Introduction -- paragraph 2, sentence 1

     From:
       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).

     To:
       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).

     1.  Introduction -- paragraph 8

     From:
       The traffic flow confidentiality (TFC) service generally is
       effective only if ESP is employed in tunnel mode between
       security gateways, and only if sufficient traffic flows between
       these gateways to conceal the characteristics of specific,
       individual subscriber traffic flows.

     To:
       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.

     2.3  Payload Data -- paragraph 2

     From:
       Note that the beginning of the transport header (transport mode)
       or the beginning of the encapsulated IP datagram (tunnel mode)
       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.

     To:
       Note that the beginning of 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.

     2.4  Padding (for Encryption) -- paragraph 1, 3rd bullet has been
     modified and changed to be a regular paragraph, not a bullet.

     From:
       Three factors require or motivate use of the Padding field.
	o .....
	o .....
	o 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 TFC. The padding field
            described here offers limited opportunity for concealing the
            length of the plaintext and thus a new, separate mechanism
            is described below for use when TFC is required (see Section
            2.7).
     To:
       Two factors require or motivate use of the Padding field.
	o .....
	o .....

       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 new, separate mechanism
       described below (see Section 2.7) should be used when TFC is
       required.

     2.6  Next Header -- paragraph 1

     From:
       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 an upper layer header and data.

     To:
       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.

     2.7  Traffic Flow Confidentiality (TFC) Padding -- paragraph 4

     Deleted:
       In transport mode, this facility generally will not be available,
       consistent with the earlier admonition that effective TFC service
       in IPsec generally requires use of tunnel mode between security
       gateways.

     3.1  ESP Header Location

     From:
       ESP may be employed in two ways: transport mode or tunnel mode.
       The former mode is applicable 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-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.)

     To:
       ESP may be employed in two ways: transport mode or tunnel mode. (See
       the Security Architecture document for description of when each should
       be used.)

     3.1.1  Transport Mode Processing -- paragraph 1, sentence 1 and 2

     From:
       In transport mode, ESP is inserted after the IP header and before
       an upper 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 upper layer
       protocol.....

     To:
       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.....

     3.1.1 Transport Mode -- paragraph 1, deleted sentence 5

     From:
       (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.)

     To:
       (Note that the term "transport" mode should not be misconstrued
       as restricting its use to TCP and UDP.)

     3.1.1 Transport Mode -- added text

     Added at the end of this section some of the text removed from 3.1

       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.

     3.1.2  Tunnel Mode Processing

     From:
       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. (Transport mode MAY be used
       to protect management or similar traffic terminating at a security
       gateway.) In tunnel mode, the "inner" IP header carries the ultimate
       source and destination addresses, while an "outer" IP header contains
       the addresses of the IPsec peers.  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.

     To:
       In tunnel mode, the "inner" IP header carries the ultimate
       source and destination addresses, while an "outer" IP header contains
       the addresses of the IPsec peers.  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.

       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. 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.

     3.3  Outbound Packet Processing -- paragraph 1, sentence 1

     From:
       In transport mode, the sender encapsulates the upper 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).

     To:
       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).

     3.3  Outbound Packet Processing -- paragraph 1

     Deleted last sentence (to be addressed in Architecture document)
       If more than one IPsec header/extension is required by security
       policy, the order of the application of the security headers MUST
       be defined by security policy.

     3.3.2.1 Separate Confidentiality and Integrity Algorithms --
       paragraph 1, step 1

     From:
       If separate confidentiality and integrity algorithms are employed,
       the sender:
          1. encapsulates (into the ESP Payload field):
                  - for transport mode -- just the original upper layer
                    protocol information.

     To:
       If separate confidentiality and integrity algorithms are employed,
       the sender:
          1. encapsulates (into the ESP Payload field):
                  - for transport mode -- just the original next layer
                    protocol information.

     3.3.2.2 Combined Confidentiality and Integrity Algorithms --
       paragraph 1, step 1

     From:
       If a combined confidentiality/integrity algorithm is employed,
       the sender:
          1. encapsulates into the ESP Payload Data field:
                  - for transport mode -- just the original upper layer
                    protocol information.

     To:
       If a combined confidentiality/integrity algorithm is employed,
       the sender:
          1. encapsulates into the ESP Payload Data field:
                  - for transport mode -- just the original next layer
                    protocol information.

     3.3.4  Fragmentation -- paragraph 2

     From:
       NOTE: For transport mode -- As mentioned at the beginning of Section
       3.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.

     To:
       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.4.4.1 Separate Confidentiality and Integrity Algorithms --
       paragraph 1, step 5

     From:
        5. the receiver reconstructs the original IP datagram from:
                  - for transport mode -- original IP header plus the
                    original upper layer protocol information in the ESP
                    Payload field
     To:
        5. the receiver reconstructs the original IP datagram from:
                  - for transport mode -- original IP header plus the
                    original next layer protocol information in the ESP
                    Payload field

****************************************************************************

C. Mandatory Algorithms -- Does the working group want to remove the
     text that describes the mandatory algorithms and move them to
     another document?  If yes, then the following sections would be
     removed/edited.

     Authentication Header (AH)
     ==========================

     3.2  Integrity Algorithms -- paragraph one, sentence 4

       .... The mandatory-to-implement integrity algorithms are
       described in Section 5 "Conformance Requirements". Other
       algorithms MAY be supported.

     5.  Conformance Requirements -- paragraph one, sentence 4

      .... A compliant AH implementation MUST support the following
      mandatory-to-implement algorithms:

	- HMAC with MD5 [MG97a]
	- HMAC with SHA-1 [MG97b]

     Encapsulating Security Payload (ESP)
     ====================================

     3.2  Algorithms -- first 2 sentences

       The mandatory-to-implement algorithms are described in Section 5,
       "Conformance Requirements." Other algorithms MAY be supported....

     5.  Conformance Requirements -- paragraph one, sentence 4

       .... A compliant ESP implementation MUST support the following
       mandatory-to-implement algorithms:

           - AES (with 128-bit keys) in CBC mode
           - HMAC with MD5 [MG98a]
           - HMAC with SHA-1 [MG98b]
           - NULL Encryption algorithm (RFC 2410)

****************************************************************************

D. Other Changes

     Authentication Header (AH)
     ==========================

     2.  Authentication Header Format -- paragraph 1

     From:
       The protocol header (IPv4, IPv6, or IPv6 Extension) immediately
       preceding the AH header will contain the value 51 in its
       Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2].

     To:
       The protocol header (IPv4, IPv6, or IPv6 Extension) immediately
       preceding the AH header SHALL contain the value 51 in its Protocol
       (IPv4) or Next Header (IPv6, Extension) field [STD-2]. Figure 1
       illustrates the format for AH.

     2.  Authentication Header Format -- table

     From: (removed "D" = dummy from Requ'd column for "IP datagram".
     There is a "dummy" value in ESP, but not in AH.)

                                                   What    What
                                   # of     Requ'd  Integ    is
                                   bytes     [1]    Covers  Xmtd
                                   ------   ------  ------  ------
        IP Header                  variable    M     [2]    plain
        Next Header                   1        M      Y     plain
        Payload Len                   1        M      Y     plain
        RESERVED                      2        M      Y     plain
        SPI                           4        M      Y     plain
        Seq# (low order 32-bits)      4        M      Y     plain
        ICV                        variable    M      Y[3]  plain
        IP datagram [4]            variable  M or D   Y     plain
        Seq# (high order 32-bits)     4      if ESN   Y     not xmtd
        ICV Padding                variable  if need  Y     not xmtd

        [1] - M = mandatory; D = dummy

     To:
                                                   What    What
                                   # of     Requ'd  Integ    is
                                   bytes     [1]    Covers  Xmtd
                                   ------   ------  ------  ------
        IP Header                  variable    M     [2]    plain
        Next Header                   1        M      Y     plain
        Payload Len                   1        M      Y     plain
        RESERVED                      2        M      Y     plain
        SPI                           4        M      Y     plain
        Seq# (low order 32-bits)      4        M      Y     plain
        ICV                        variable    M      Y[3]  plain
        IP datagram [4]            variable    M      Y     plain
        Seq# (high order 32-bits)     4      if ESN   Y     not xmtd
        ICV Padding                variable  if need  Y     not xmtd

        [1] - M = mandatory

     2. Authentication Header Format -- added the following text at
     the end of this section.

       "Note:  All of the cryptographic algorithms used in IPsec
       expect their input in canonical network byte order (see
       Appendix in RFC 791) and generate their output in canonical
       network byte order.  IP packets are also transmitted in
       network byte order."

     3.3.4  Fragmentation -- paragraph 1, sentence 3 (and added a
     parenthetical sentence after sentence 3.)

     From:
        .....An IP packet to which AH has been applied may itself be
        fragmented by routers en route, and such fragments must be
        reassembled prior to AH processing at a receiver....

     To:
        .....An IPv4 packet to which AH has been applied may itself
        be fragmented by routers en route, and such fragments must be
        reassembled prior to AH processing at a receiver.  (This does
        not apply to IPv6, where there is no router-initiated fragmentation.)

     3.4.2  Security Association Lookup -- added paragraph at end

       (Note that SA management traffic, e.g., IKE packets, does not
       need to be processed based on SPI, i.e., one can demultiplex
       this traffic separately, e.g., based on Next Protocol and Port
       fields.)

     Encapsulating Security Payload (ESP)
     ====================================

     2. Encapsulating Security Payload Packet Format -- added the
     following text at the end of this section.

       "Note:  All of the cryptographic algorithms used in IPsec
       expect their input in canonical network byte order (see
       Appendix in RFC 791) and generate their output in canonical
       network byte order.  IP packets are also transmitted in
       network byte order."

     3.4.4.1 Separate Confidentiality and Integrity Algorithms,
     paragraph 1, step 5 -- corrected tunnel mode processing

     From:
        5. the receiver reconstructs the original IP datagram from:
                  - for transport mode -- original IP header plus the
                    original next layer protocol information in the ESP
                    Payload field
                  - for tunnel mode -- tunnel IP header + the entire IP
                    datagram in the ESP Payload field.

     To:
        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.