Subject: IPsec -- new versions of AH and ESP

From: Karen Seo <[email-masked]>
Date: Sun, 2 Mar 2003 02:11:10 -0500

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.