IPsec -- new versions of AH and ESP

[Karen Seo <kseo@bbn.com>]

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.