Re: Last Call: IPSec DOI Proposed Standard

"Theodore Y. Ts'o" <tytso@MIT.EDU> Fri, 24 April 1998 18:33 UTC

Return-Path: tytso@MIT.EDU
Received: from brittany.cisco.com (brittany.cisco.com [171.69.1.168]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id LAA02322 for <ippcp-archive-file@ftp-eng.cisco.com>; Fri, 24 Apr 1998 11:33:17 -0700 (PDT)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by brittany.cisco.com (8.6.12/8.6.5) with ESMTP id LAA11399 for <extdom.ippcp@aliashost.cisco.com>; Fri, 24 Apr 1998 11:32:32 -0700
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id LAA00577 for <ippcp@external.cisco.com>; Fri, 24 Apr 1998 11:32:30 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id LAA00551 for <ippcp@external.cisco.com>; Fri, 24 Apr 1998 11:32:26 -0700 (PDT)
Received: from south-station-annex.mit.edu(18.72.1.2) by proxy1.cisco.com via smap (V2.0) id xma000528; Fri, 24 Apr 98 18:32:20 GMT
X-SMAP-Received-From: outside
Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA02083; Fri, 24 Apr 98 14:28:31 EDT
Received: by dcl.MIT.EDU (SMI-8.6/4.7) id OAA17558; Fri, 24 Apr 1998 14:28:30 -0400
Date: Fri, 24 Apr 1998 14:28:30 -0400
Message-Id: <199804241828.OAA17558@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Avram Shacham <shacham@cisco.com>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, "'iesg@ns.ietf.org'" <iesg@ietf.org>, ipsec@tis.com, ippcp@external.cisco.com
In-Reply-To: Avram Shacham's message of Thu, 23 Apr 1998 21:52:51 -0700, <3.0.2.32.19980423215251.006d74c0@pita.cisco.com>
Subject: Re: Last Call: IPSec DOI Proposed Standard
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091

   Date: Thu, 23 Apr 1998 21:52:51 -0700
   From: Avram Shacham <shacham@cisco.com>

   Please do.  After all, six weeks ago the IESG approved the publication of
   IP Payload Compression Protocol (IPComp) _only_ as a Proposed Standard (but
   waiting for two IPSec docs.)  If future experience proves the IPCOMP
   Transform Identifiers range is too narrow, there is always room for
   improvements.

Actually, it will be much, much harder to change this in the future if
there are implementations which start assigning CPI's in the range
64-255.  This will prevent us from expanding the range in the future for
static transforms, since they will be used for dynamically assigned
values.

It's clear we will need to make a change to one or the other document,
both of which have been voted on and approved by the IESG (the IPSEC
documents modulo some fixups, including this one).

One compromise position that we might explore would involve putting text
in the IPSEC documents that reserve the range 64-255 for future
expansion, and so implementations MUST NOT assign CPI's in that range.
This at least gives us the opportunity to allow more "well-known"
transforms in the future.    What do people think about this?

You're right that with only four compression algorithms, this isn't a
big deal either way, and shouldn't be used to delay the documents.  On
the other hand, I can't think of any architectural justification to
artificially constrain the ability to expand the number space at this
point in time.  It'd be like the original IP designers saying that IP
addresses should be only 28 bits, instead 32, because surely we would
*never* need 2**28 addresses --- never mind that 4 bytes gives you 32
bits and the cost is the same whether you use 28 or 32 bits.

Taking the analogy back to IPPCP, if we have 1 full byte available to
us, why not use the whole 8 bits, instead of stopping at 6?  Surely we
can spare 192 dynamically assigned CPI's out of over 61,000.  (Note that
the compromise I suggested above reserves these 192 dynamically assigned
CPI's so that we have the option in the future to expand the range.)

							- Ted