Re: Last Call: IPSec DOI Proposed Standard
"Theodore Y. Ts'o" <tytso@MIT.EDU> Thu, 23 April 1998 20:59 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 NAA00074 for <ippcp-archive-file@ftp-eng.cisco.com>; Thu, 23 Apr 1998 13:59:15 -0700 (PDT)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by jindo.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id NAA13636 for <extdom.ippcp@aliashost.cisco.com>; Thu, 23 Apr 1998 13:59:05 -0700 (PDT)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id NAA26795 for <ippcp@external.cisco.com>; Thu, 23 Apr 1998 13:59:03 -0700 (PDT)
Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id NAA06934 for <ippcp@external.cisco.com>; Thu, 23 Apr 1998 13:58:59 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu(18.69.0.28) by proxy3.cisco.com via smap (V2.0) id xma006927; Thu, 23 Apr 98 20:58:55 GMT
X-SMAP-Received-From: outside
Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA12155; Thu, 23 Apr 98 16:55:09 EDT
Received: by dcl.MIT.EDU (SMI-8.6/4.7) id QAA17248; Thu, 23 Apr 1998 16:55:03 -0400
Date: Thu, 23 Apr 1998 16:55:03 -0400
Message-Id: <199804232055.QAA17248@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 Wed, 22 Apr 1998 21:48:28 -0700, <3.0.2.32.19980422214828.006b0c78@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 21:48:28 -0700 From: Avram Shacham <shacham@cisco.com> In a simple analogy to IPSec, the 16-bit CPI of IPComp is the equivalent of the 32-bit SPI, and the 6-bit IPCOMP Transform Identifiers, which define well-known compression algorithms, are similar to the 8-bit ESP and AH Transform Identifiers. IPSec DOI provides the numeric and symbolic definitions for all those Identifiers. Thanks for setting me straight for how the IPCOMP was used. It wasn't immediately obvious to me from reading the IPCOMP draft. Stupid question --- what was the reason why IPCOMP limited the number of transform identifiers to 6-bits? If we changed the number of transform identifiers to 8-bits, it decreases the number of CPI's available for dynamically assigned CPI's from 61,376 to 61,184. I wouldn't think that the range of dynamically assigned CPI's would be drastically decreased if we were to lower that range by 192 transforms. As for the numeric range of the IPComp Transform Identifiers - in Munich, the IPPCP working-group decided - given the number of existing compression algorithms - to allocate the IDs 1-63 for such known algorithms. The decision is reflected in the IPComp I-D. The DOI document did not follow this decision. Our apologies. Both I and the DOI editor were not aware of this decision. That being said, could you enlighten us as to why the ippcp wg made that decision? We can very easily make the DOI document state that the number of transforms is limited to the range 0-63 (despite the fact that the ISAKMP protocol has room for 8 bits), with say 0-53 to be assigned by the IANA, and 54-63 to be used by mutually consenting implementations. It would seem to me to be limiting the number space unnecessarily, though. Our other choice would be to change the IPCOMP draft to align with the DOI draft. This increases the number of static transforms from 64 to 256, and means that ISAKMP implementations should only hand out CPI's which are in the range 256 to 61439. (instead of using the range 63 to 61439). Although I'm not an expert on the issues which the ippcp group is facing, it would seem to me that increasing the number of static transforms would be a good thing. I've gotten nervous about the fact that we only have 8 bits for some of the other ISAKMP negotiated fields, which is why the IANA consideration is extremely miserly about how those numbers are handed out, lest we run out. However, if the IPPCP group feels strongly about this, we can go ahead and make the change to the DOI. (This is otherwise known as "your funeral, not mine, if we run out of ipcomp transform id's." :-) - Ted
- RE: Last Call: IPSec DOI Proposed Standard Avram Shacham
- Re: Last Call: IPSec DOI Proposed Standard Theodore Y. Ts'o
- Re: Last Call: IPSec DOI Proposed Standard Avram Shacham
- Re: Last Call: IPSec DOI Proposed Standard Naganand Doraswamy
- Re: Last Call: IPSec DOI Proposed Standard Derrell D. Piper
- Re: Last Call: IPSec DOI Proposed Standard Theodore Y. Ts'o
- Re: Last Call: IPSec DOI Proposed Standard Avram Shacham
- Re: Last Call: IPSec DOI Proposed Standard Theodore Y. Ts'o
- Re: Last Call: IPSec DOI Proposed Standard Avram Shacham
- Re: Last Call: IPSec DOI Proposed Standard Naganand Doraswamy