Re: AH and mutable fields, how deep to look?

[Markku Savela <msa@burp.tkv.asdf.org>]

> From: Stephen Kent <kent@bbn.com>
> The intent was to treat everything after AH as opaque, in IPv6 as 
> well as IPv4. What change to the graphics would help convey this 
> better?

Using draft-ietf-ipsec-rfc2402bis-05.txt as a source, the current
graphics in 3.1.1 is:

      ------------------------------------------------------------
IPv6  |             |hop-by-hop, dest*, |    | dest |     |      |
      |orig IP hdr  |routing, fragment. | AH | opt* | TCP | Data |
      ------------------------------------------------------------
      |<---- authenticated except for mutable fields ----------->|

It does sort of give possibility to interpretation that the mutable
field processing applies also below AH. The text in 3.3.3

----------------------------
3.3.3  Integrity Check Value Calculation

   The AH ICV is computed over:
        o IP header fields that are either immutable in transit or that
          are predictable in value upon arrival at the endpoint for the
          AH SA
        o the AH header (Next Header, Payload Len, Reserved, SPI,
          Sequence Number (low order 32 bits), and the Integrity Check
          Value (which is set to zero for this computation), and
          explicit padding bytes (if any))
        o the next level protocol data, which is assumed to be immutable
          in transit
        o the high order bits of the ESN (if employed), and any implicit
          padding required by the integrity algorithm
----------------------------

does imply (after you stare it long enough), that headers below AH are
immutable. You do have to make a realization that "next level protocol
data" refers to possible extension header (and not to the TCP). Also,
the first bullet only talks about IP header.

To make it clear, perhaps change the graphics into (not too happy with
this, but):

      ------------------------------------------------------------
IPv6  |             |hop-by-hop, dest*, |    | dest |     |      |
      |orig IP hdr  |routing, fragment. | AH | opt* | TCP | Data |
      ------------------------------------------------------------
      |<-- mutable fields processing -->/////<--immutable------->|
      |<---- authenticated except for mutable fields ----------->|

(I'm not sure how mark AH itself in this mutable/immutable
issue). Similar change to the tunnel example.

For 3.3.3 text, clarification

1st bullet:

   o IP header fields that are ...

into

   o IP or extension header fields before the AH that are ...

3rd bullet:

   o the next level protocol data, which is assumed to be immutable
     in transit

into..

   o everything below AH is assumed to be immutable in transit


---------------

Unrelated nit about the text:
------------------------
2.2  Payload Length

   This 8-bit field specifies the length of AH in 32-bit words (4-byte
   units), minus "2".  (This means of expressing the length of AH was
   selected to allow its use as an IPv6 extension header. Thus the
   length computation is consistent with the algorithm described in RFC
   2460 [DH98].) 
-------------

The last sentence is incorrect. The length computation IS NOT
consistent with algorithm described in RFC 2460. In there the length
is computed using 8 octet units, in AH the unit is 4 octets. The
original RFC-2402 has it right.