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

Re: Last Call: IPSec DOI Proposed Standard



   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



Follow-Ups: References: