Subject: RE: Last Call: IPSec DOI Proposed Standard

From: Avram Shacham <[email-masked]>
Date: Wed, 22 Apr 1998 11:52:40 -0700

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>.

Regards,
avram

   4.4.5 IPSEC IPCOMP Transform Identifiers
 
      The IP Compression (IPCOMP) transforms define optional compression
      algorithms that can be negotiated to provide for IP compression
      before ESP encryption.
      ^^^^^^^^^^^^^^^^^^^^^  Is this very partial definition needed?

   6.6 IPSEC IPCOMP Transform Identifiers

      The IPSEC IPCOMP Transform Identifier is an 8-bit value which
                                                  ^^^^^I-D defines 1-63(6 bit)
      identifier a particular algorithm to be used to provide IP-level
      compression before ESP.  Requests for assignments of new IPCOMP
      ^^^^^^^^^^^^^^^^^^^^^^ see above
      transform identifiers must be accompanied by a standards-track RFC
      which describes how to use the algorithm within the IPCOMP framework
      ([IPCOMP]).  In addition, the requested algorithm must be published
      and in the public domain.  If the requested algorithm is not in the
      public domain, the addition must be approved by an IESG action.

      The values 249-255 are reserved for private use amongst cooperating
                 ^^^^^^^ 58-63?
      systems.

=== end of comments ===

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 22 Apr 1998 22:37:16 -0400

Date: Wed, 22 Apr 1998 11:52:40 -0700
   From: Avram Shacham <[email-masked]>

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

---

From: Avram Shacham <[email-masked]>
Date: Wed, 22 Apr 1998 21:48:28 -0700

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

---

From: "Derrell D. Piper" <[email-masked]>
Date: Thu, 23 Apr 1998 10:31:29 -0700

All,

The ISAKMP protocol defines the size of its Transform ID field as one octet.
The IPSEC DOI defines the legal values for this field when using IPSEC with
ISAKMP (as IPPCP does).  If IPPCP wants to use only six bits of the octet for
the compression transform identifier, that's fine, but it's still eight bits
on the wire in ISAKMP.  It can also be just six bits in the IPPCP protocol.

The current IPSEC DOI says that the values not defined in the IPSEC DOI are
reserved to IANA and that requests to IANA must be accompanied by a standards
track RFC, like IPPCP, that details the use of the requested allocation.

The only potential problem I see is that the IPSEC DOI does state that "the
values 249-255 are reserved for use private use amongst cooperating systems."
I will correct this in the next draft.

Derrell

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 23 Apr 1998 16:55:03 -0400

Date: Wed, 22 Apr 1998 21:48:28 -0700
   From: Avram Shacham <[email-masked]>

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.

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

---

From: Avram Shacham <[email-masked]>
Date: Thu, 23 Apr 1998 21:52:51 -0700

At 04:55 PM 4/23/98 -0400, Theodore Y. Ts'o wrote:
[...]
>decision.  

The DOI editor _is_ a member of the IPPCP mailing list from day one, so he
must have been aware of the wg decisions in Munich.  Also, I pointed these
inconsistencies to the DOI editor in several private email messages many
weeks ago.

>That being said, could you enlighten us as to why the ippcp
>wg made that decision?

Currently, the market offers 4 (four) compression algorithms. The IPPCP wg
felt that less than 50 (fifty) new algorithms are expected in the
foreseeable future.

>It would seem to me to be limiting the number space unnecessarily,

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.

Regards,
avram

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Fri, 24 Apr 1998 14:28:30 -0400

Date: Thu, 23 Apr 1998 21:52:51 -0700
   From: Avram Shacham <[email-masked]>

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

---

From: Avram Shacham <[email-masked]>
Date: Fri, 24 Apr 1998 12:13:26 -0700

Ted, I agree that your compromise is more flexible for future changes.

Unless other members of the IPPCP wg voice objections, I suggest that both
documents (DOI and IPComp) will be modified to reflect your suggestion.

Also, the DOI document should be modified to correct the non-accurate
wording describing the IPComp protocol: (a) deleting the words "before ESP
encryption" in section 4.4.5 and "before ESP" is 6.6, and (b) the term "IP
compression" should be modified to "IP payload compression."

I hope this process will not delay any of our documents.

Comments?
avram