Re: IKEv2 (son-of-ike) draft - IPComp-related comments

Abraham Shacham <shacham@juniper.net> Mon, 26 November 2001 05:13 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQ5Dh817730; Sun, 25 Nov 2001 21:13:43 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26367 Sun, 25 Nov 2001 23:25:11 -0500 (EST)
Message-ID: <3C01C5B0.7020902@juniper.net>
Date: Sun, 25 Nov 2001 20:31:44 -0800
From: Abraham Shacham <shacham@juniper.net>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011019
X-Accept-Language: en-us
MIME-Version: 1.0
To: dharkins@tibernian.com
CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com
Subject: Re: IKEv2 (son-of-ike) draft - IPComp-related comments
References: <20011118071052.0F71654C53@tailor.sailpix.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

dharkins@tibernian.com wrote:

 > Please send comments to the list.


Attached are few IPComp-related, mostly editorial, comments.

Thanks,
avram

 >1.1 The IKE Protocol
 >
 >   IKE performs mutual authentication between two parties and
 >   establishes an IKE security association that includes shared secret
 >   information that can be used to efficiently establish SAs for ESP
 >   (RFC 2406), AH (RFC 2402) and/or IPcomp (RFC 2393).

s/IPcomp/IPComp/
s/RFC 2393/RFC 3173/

 >7.3.1 Proposal Substructure
[...]
 >      o  SPI Size (1 byte) - During phase 1 negotiation this field
 >         MUST be zero. During phase 2 negotiation it is equal to the
 >         size, in bytes, of the SPI of the corresponding protocol
 >         (4 for ESP and AH, 2 for IPcomp).

Current implementations are divided on the size of SPI for IPComp,
leading to a compromise where two-octet field is a SHOULD,
four-octet a MAY, and the receiving node MUST be able to process both
forms (see RFC3173, 4.1. Use of IKE).

A single field size of two-octet could simplify the matter, no doubt,
but such change should first gain implementors' support.


 >7.3.2 Transform Substructure
[...]
 >   For Transform Type 6 (Compression), defined Transform-IDs are:
 >
 >          Name                     Number                 Defined In
 >          RESERVED                   0
 >          IPCOMP_OUI                 1 (w/attributes)
 >          IPCOMP_DEFLATE             2
 >          (RFC2394)
 >          IPCOMP_LZS                 3
 >          (RFC2395)
 >
 >          values 4-240 are reserved to IANA. Values 241-255 are for
 >          private use among mutually consenting parties.

Following RFC 3051, the above should read:

    For Transform Type 6 (Compression), defined Transform-IDs are:

           Name                     Number                 Defined In
           RESERVED                   0
           IPCOMP_OUI                 1 (w/attributes)
           IPCOMP_DEFLATE             2                    (RFC2394)
           IPCOMP_LZS                 3                    (RFC2395)
           IPCOMP_LZJH                4                    (RFC3051)

           values 5-240 are reserved to IANA. Values 241-255 are for
           private use among mutually consenting parties.

=== eom ===

 
> 
> 
>