Re: Last Call: IPSec DOI Proposed Standard

"Theodore Y. Ts'o" <tytso@MIT.EDU> Thu, 23 April 1998 02:28 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA05741 for ipsec-outgoing; Wed, 22 Apr 1998 22:28:27 -0400 (EDT)
Date: Wed, 22 Apr 1998 22:37:16 -0400
Message-Id: <199804230237.WAA16620@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Avram Shacham <shacham@cisco.com>
Cc: "'iesg@ns.ietf.org'" <iesg@ietf.org>, ipsec@tis.com, ippcp@external.cisco.com
In-Reply-To: Avram Shacham's message of Wed, 22 Apr 1998 11:52:40 -0700, <3.0.2.32.19980422115240.006d40d4@pita.cisco.com>
Subject: Re: Last Call: IPSec DOI Proposed Standard
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

   Date: Wed, 22 Apr 1998 11:52:40 -0700
   From: Avram Shacham <shacham@cisco.com>

   The document <draft-ietf-ipsec-ipsec-doi-08> is inconsistent with the IP
   Payload Compression Protocol (IPComp) as defined in
   <draft-ietf-ippcp-protocol-05>.

Thanks for catching this.  I think that the draft we need to change is
the IPComp draft, though.  It assumes that the transform identifiers are
16-bits:

        16-bit index.  The CPI is stored in network order.  The values
        0-63 define well-known compression algorithms, which require no
        additional information, and are used for manual setup.  The
        values themselves are identical to IPCOMP Transform identifiers
        as defined in [SECDOI].  Consult [SECDOI] for an initial set of
        defined values and for instructions on how to assign new values.
        The values 64-61439 are negotiated between the two nodes in
        definition of an IPComp Association, as defined in section 4.
        Note:  When negotiating one of the well-known algorithms, the
        nodes MAY select a CPI in the pre-defined range 0-63.  The
        values 61440-65535 are for private use among mutually consenting
        parties.

However, ISAKMP only supports 8 bits worth of transform id's.  Hence,
the text in IPComp needs fixing.  In harmonizing the IPComp draft with
the DOI draft, it would seem to me that the way to do this is to adopt
the IANA considerations in the DOI draft.  The IPCOMP draft doesn't have
an IANA considerations, and as stated previously, it incorrectly assumes
that transform ID's were 16-bits instead of 8 bits in ISAKMP.

Comments?

						- Ted