Re: Last Call: IPSec DOI Proposed Standard
"Theodore Y. Ts'o" <tytso@MIT.EDU> Thu, 23 April 1998 02:28 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA05741 for ipsec-outgoing; Wed, 22 Apr 1998 22:28:27 -0400 (EDT)
Date: Wed, 22 Apr 1998 22:37:16 -0400
Message-Id: <199804230237.WAA16620@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Avram Shacham <shacham@cisco.com>
Cc: "'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 11:52:40 -0700, <3.0.2.32.19980422115240.006d40d4@pita.cisco.com>
Subject: Re: Last Call: IPSec DOI Proposed Standard
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Date: Wed, 22 Apr 1998 11:52:40 -0700 From: Avram Shacham <shacham@cisco.com> 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
- 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