[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Theodore Y. Ts'o: Re: forward progress on IPSec AH]


I meant to sent the following to the working group lists, sorry.

						- Ted


------- Forwarded Message

Date: Tue, 5 May 1998 01:21:50 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Thomas Narten <narten@raleigh.ibm.com>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Steve Bellovin
	<smb@research.att.com>,
        jis@MIT.EDU, rgm-sec@htt-consult.com, mleech@nortel.ca
In-Reply-To: Thomas Narten's message of Fri, 01 May 1998 09:34:54 -0400,
	<199805011334.JAA19312@cichlid.raleigh.ibm.com>
Subject: Re: forward progress on IPSec AH
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091

   Date: Fri, 01 May 1998 09:34:54 -0400
   From: Thomas Narten <narten@raleigh.ibm.com>

   What needs to be done to get closure on these documents?

OK, what to do...

   1) The mutable bit semantics discussion in IPv6 options is (I believe)
   mostly an IPng discussion. In a sense, IPSec just needs to do what the
   IPng documents say. I'd like to wait for input from Deering (he's
   ACKed me that he will do so RSN). If the end result is leave things as
   currently defined, the issue goes away.

Deering has weighed in to not change the mutable bit semantics for
options.  Assuming that we go with his recommendation, the IPSEC and
IPNG drafts seem to be in agreement here, so the issue goes away.

I think part of the confusion is caused by rather confusing terminology.
There are Extensions (which are sometimes called options, I think
incorrectly), as well as sets of individual options (taken from a
different number space than the Extension headers) for the Hop by Hop
and Destination options Extensions.  As near as I can tell, calling the
other extension headers "options" is a misnomer.  Some extension headers
are _optional_, but they should not be called _options_.

Some of this confusion is in the AH spec, but I've seen it in other
places as well.  I think we will eventually want to clean up the text,
before we go to draft standard, but I don't think we necessarily need to
clear this up now.

   2) The interoperability issue I raised with regards to whether the
   sender includes a "new" extension header in the AH check needs some
   sort of resolution. This problem is largely independent of 1). I
   believe that this is an IPSec decision to make. Just pick the least
   worst solution, it would seem. 

It looks like the IPV6 drafts very explicitly say that new extension
headers cause the packet to be rejected.  If we are to harmonize with
this position, then the following text in section 3.3.3.1 of the
auth-header document must be changed:

   If the IPsec implementation encounters an extension header that it
   does not recognize, it MUST zero the whole header except for the Next
   Header and Hdr Ext Len fields.  The length of the extension header
   MUST be computed by 8 * Hdr Ext Len value + 8.

... since there's no good way to determine where the next header and
header length fields were.  (It would have been good if the location for
next header and header-length were fixed for all non-terminal header,
which apparently originally was a design goal, but several IPV6 folks
have claimed that this is now a bad assumption to make.)

If this is true, I don't see how to what else BITS or BITW
implementations can do besides reject packets if they don't know what to
do with an extension header which comes before the AH or ESP header.
Processing has to stop, since there's no way to continue.

Proposed replacement text for the above text in 3.3.3.1:

   If the IPsec implementation encounters an extension header that it
   does not recognize, it MUST reject it per section 4 of RFC 1883.

Again, in the future, we may want to harmonize the terminology so that
there aren't any confusion between how the IPV6 specs says things and
the IPSEC spec says thing.  We probably need to make more explicit that
some IPV6 extension headers may appear before the Authentication Header,
and some may appear afterwards, and that all extension headers appearing
after the AH are included in the ICV.  This is strongly implied, and
apparently assumes this is the case, but it is not actually stated
explicitly.

Comments on the above approach for moving forward?  (Leave the
mutability text alone, and harmonize with the RFC-1883 position which
says that unknown extension headers cause an ICMP code 2 packet.)

						- Ted







------- End Forwarded Message