Subject: (IPng 7504) Re: Last Call: IPv6 Jumbograms to Proposed Standa rd

From: Brian Zill <[email-masked]>
Date: Mon, 10 May 1999 23:41:36 -0700

> From: Craig Metz [mailto:[email-masked]]
> A dictatorial edict that we aren't supporting
> bump-in-the-wire and we're modeling
> the assembly of the headers a certain way
> would solve the problem.

I believe specifying how we're modeling the assembly of headers would be
enough to ensure interoperability when nesting AH inside of another
transport mode security header.  As you pointed out in an earlier message,
transport mode bump-in-the-wire can only work if we model the assembly of
headers as "incremental".  It's a shame the AH spec isn't clearer on this
issue.

There are two places in the AH spec (RFC 2402) where it discusses how to
handle the AH ICV calculation in the face of subsequently applied IPsec
headers.  One is in section 3.3 (which Aaron quoted earlier), the other is
in section 3.4.  Both speak of "ignoring" the subsequently applied headers,
with clarifications stating not to zero/predict/use the contents of those
headers.  I had taken this to mean to just skip over them when performing
the ICV calculation.  Logically removing them, on the other hand, involves
modifying the previous header's next header field to be that of the
subsequent header and also decreasing the IPv6 header's Payload Length field
by the appropriate amount when calculating the ICV.  If I understand
everyone's mail so far, NRL, KAME and Mentat all take this latter approach.
If that's the consensus, I suppose we'll switch our interpretation to match
everybody else's.  Anyone with an IPSec implementation who hasn't spoken up
yet?

Getting back to Itojun's original comment about AH with Jumbograms, they
still seem problematic to me.  I don't see a good way to support
bump-in-the-wire implementations adding transport mode AH Jumbograms.
Unlike fragmentation headers, which can be applied later (on transmit) and
removed before (on receive) any IPsec is performed, the hop-by-hop jumbo
payload option is not specified to be added and later removed transparently.
If a bump-in-the-wire implementation finds itself in a situation (such as
Itojun's example) where it needs to add a jumbo payload option to hold an
AH2, the ICV value in the previously calculated AH1 won't reflect this
included option and the ICV check will fail on the receive side.  There's
currently no mention in the specs of logically removing the jumbo payload
option on receive, and I don't think that's a good idea in any event.

On the other hand, if we ignore this strange bump-in-the-wire case, I don't
see any problem.  As long as a single stack is adding both the AH1 and the
AH2 header, it can pre-calculate the eventual size of the final datagram and
know to insert the jumbo payload option in the hop-by-hop header (and the
hop-by-hop header itself if there are no other hop-by-hop options already in
the packet) prior to calculating AH1's ICV.  The only anomaly here is that
the value of the "Jumbo Payload Length" field used to calculate AH1's ICV
might be less than 65,535, however, this wouldn't violate the spec as that
value would never be seen on the wire.  Implementation would be thornier
than as in the pure "incremental" approach, but seems possible.

--Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------