Re: Last Call: IPSec DOI Proposed Standard

[Avram Shacham <[e-mail]>]

Theodore,

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.

In IPComp, the Transform Identifiers can also serve as CPI, with the
benefit of saving the receiving node the CPU cycles to locate the
compression algorithm by CPI. This method is also handy for manually
configured nodes.

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.

In IPSec/IKE bakeoff in March 98, several vendors successfully negotiated
IPComp using IKE, so I see no conflict here. Also, IANA did read and
provided comments to the IPComp I-D and those comments were incorporated in
the document. 

Therefore, the right way to go is to correct the DOI doc.

Regards,
avram

At 10:37 PM 4/22/98 -0400, Theodore Y. Ts'o wrote:
>   Date: Wed, 22 Apr 1998 11:52:40 -0700
>   From: Avram Shacham <[e-mail]>
>
>   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
>
>