Re: Last Call: IPSec DOI Proposed Standard

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

Return-Path: tytso@MIT.EDU
Received: from jindo.cisco.com (jindo.cisco.com [171.69.43.22]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA03477 for <ippcp-archive-file@ftp-eng.cisco.com>; Wed, 22 Apr 1998 19:50:10 -0700 (PDT)
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by jindo.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA23450 for <extdom.ippcp@aliashost.cisco.com>; Wed, 22 Apr 1998 19:49:31 -0700 (PDT)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id TAA24301 for <ippcp@external.cisco.com>; Wed, 22 Apr 1998 19:49:30 -0700 (PDT)
Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id TAA28100 for <ippcp@external.cisco.com>; Wed, 22 Apr 1998 19:46:11 -0700 (PDT)
Received: from south-station-annex.mit.edu(18.72.1.2) by proxy3.cisco.com via smap (V2.0) id xma028095; Thu, 23 Apr 98 02:46:06 GMT
X-SMAP-Received-From: outside
Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA19871; Wed, 22 Apr 98 22:37:17 EDT
Received: by dcl.MIT.EDU (SMI-8.6/4.7) id WAA16620; Wed, 22 Apr 1998 22:37:16 -0400
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

   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