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

From: Markku Savela <[email-masked]>
Date: Tue, 9 Dec 2003 12:18:47 +0200

[I tried to send a message about this last week, but it disappeared...]

With following

   IP Ext.-Headers1 AH Ext.-Headers2 ...

TAHI test assumes that the "mutable field" processing is also done for
the Ext.Headers2. I always had the misconception(?), and my
implementation also has it, that the payload after AH is treated as
opaque bits, and immutable.

I find my interpretation, of course, saner (and simpler). However, AH
RFC seems to support TAHI's interpretation (at least the ASCII
graphics).

If my interpretation is wrong, then the followup question is: how deep
you are supposed to scan? Say,

   IP ext1 AH ext2 IP-tunnel ext3 ...etc..

Then, an unknown (to the SG) extension header inside ext3 would
totally unnecessarily break the IPSEC...

---

From: Dan McDonald <[email-masked]>
Date: Tue, 9 Dec 2003 10:08:08 -0500

> TAHI test assumes that the "mutable field" processing is also done for the
> Ext.Headers2.  I always had the misconception(?), and my implementation
> also has it, that the payload after AH is treated as opaque bits, and
> immutable.
> 

We do the same in Solaris in that we treat a post-AH header as opaque.  It
makes sense from a parsing point of view and it gives the forwarding path
a clear stopping point (i.e. stop at AH as you would TCP, UDP, or ESP).

> totally unnecessarily break the IPSEC...

If we're supposed to behave like TAHI, then the first inner-IP you hit in
this case is where you stop.

Ambiguous situations like this, BTW, are why I like treating tunnel mode as a
degenerate case of transport mode, or why we should agree with Joe Touch and
treat IP like any other transport protocol!

Dan

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Dec 2003 18:11:32 -0500

>totally unnecessarily break the IPSEC...

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?

Steve

---

From: Markku Savela <[email-masked]>
Date: Thu, 11 Dec 2003 11:52:05 +0200

> From: Stephen Kent <[email-masked]>

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.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 12 Dec 2003 11:28:10 +0900 (JST)

> To make it clear, perhaps change the graphics into (not too happy with

	this is important, when implementing multiple AH on a packet
	(crazy example but possible, and we had interop problem in Connectathon
	between KAME and Solaris)

itojun

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Dec 2003 09:42:21 -0500

>	between KAME and Solaris)

I'm not sure I understand your comment. Are you saying that the 
diagram above is right and handles nested AH instances as you would 
like, or that it is not right?

Steve

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 13 Dec 2003 04:42:30 +0900 (JST)

> like, or that it is not right?

	we can have multiple AH in a packet, like
		IPv6 AH1 AH2 payload
	and when we compute cipher checksum for AH1, AH2 should be handled
	as an immutable header.

itojun