IPComp editorial comments (Re: Working Group Last Call IKEv2)
Abraham Shacham <shacham@trpz.com> Mon, 09 June 2003 00:04 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04161 for <ipsec-archive@lists.ietf.org>; Sun, 8 Jun 2003 20:04:56 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25838 Sun, 8 Jun 2003 17:45:28 -0400 (EDT)
Message-ID: <3EE3AD34.5090600@trpz.com>
Date: Sun, 08 Jun 2003 14:40:04 -0700
From: Abraham Shacham <shacham@trpz.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Barbara Fraser <byfraser@cisco.com>, ipsec@lists.tislabs.com
CC: tytso@mit.edu, ippcp <ippcp@external.cisco.com>
Subject: IPComp editorial comments (Re: Working Group Last Call IKEv2)
References: <4.3.2.7.2.20030603102719.050c84c8@mira-sjc5-4.cisco.com>
In-Reply-To: <4.3.2.7.2.20030603102719.050c84c8@mira-sjc5-4.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit
Attached please find the IPComp editorial comments for IKEv2, including in RFC editor format. Regards, avram shacham@trpz.com shacham@shacham.net (*) Footnote to the bored reader of this repeated message: The I-D is in wg last call, so at the most a single repeat is due -- during ietf last call ;-< Barbara Fraser wrote: > Hi, > > This is a working group last call for comments on the IKEv2 draft, > draft-ietf-ipsec-ikev2-08.txt, for progression to Proposed Standard: > > This last call will expire in three weeks on June 23, 2003. > > thanks, > Barb and Ted > > > -------- Original Message -------- > Subject: IKEv2-05: IPComp (editorial) comments > Date: Mon, 03 Mar 2003 00:21:59 -0800 > From: Abraham Shacham <shacham@trpz.com> > To: IP Security List <ipsec@lists.tislabs.com> > CC: ippcp <ippcp@external.cisco.com> > > > s/IPcomp/IPComp/ > s/RFC 2393/RFC 3173/ > > In page 54: > > The Transform IDs currently defined are: > Name Number Defined In > RESERVED 0 > IPCOMP_OUI 1 > IPCOMP_DEFLATE 2 (RFC2394) > IPCOMP_LZS 3 (RFC2395) > > Following RFC-3051, add: > > IPCOMP_LZJH 4 (RFC3051) > > > > Thanks, > avram > === the above comments in RFC editor format === page 2: Old: 2.22 IPcomp.................................................34 New: 2.22 IPComp.................................................34 page 4: Old: match fashion. IKE can also negotiate use of IPcomp [RFC2393] in connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". New: match fashion. IKE can also negotiate use of IPComp [RFC3173] in connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". page 11: Old: SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPcomp, then with ESP, and finally with AH between the same pair of endpoints, all of the SAs MUST be deleted New: SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPComp, then with ESP, and finally with AH between the same pair of endpoints, all of the SAs MUST be deleted page 34: Old: 2.22 IPcomp New: 2.22 IPComp Old: implementations of this specification MUST NOT accept an IPcomp algorithm that was not proposed, MUST NOT accept more than one, and New: implementations of this specification MUST NOT accept an IPComp algorithm that was not proposed, MUST NOT accept more than one, and Old: A side effect of separating the negotiation of IPcomp from cryptographic parameters is that it is not possible to propose New: A side effect of separating the negotiation of IPComp from cryptographic parameters is that it is not possible to propose pp 65, 66: Old: IPCOMP_SUPPORTED 24581 This notification may only be included in a message containing an SA payload negotiating a CHILD_SA and indicates a willingness by its sender to use IPcomp on this SA. The data associated with this notification includes a two octet IPcomp CPI followed by a one octet transform ID optionally followed by attributes whose length and format is defined by that transform ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED notifications to indicate multiple supported algorithms. A message accepting an SA may contain at most one. The transform IDs currently defined are: NAME NUMBER DEFINED IN ----------- ------ ----------- RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 values 4-240 are reserved to IANA. Values 241-255 are for private use among mutually consenting parties. New: IPCOMP_SUPPORTED 24581 This notification may only be included in a message containing an SA payload negotiating a CHILD_SA and indicates a willingness by its sender to use IPComp on this SA. The data associated with this notification includes a two octet IPComp CPI followed by a one octet transform ID optionally followed by attributes whose length and format is defined by that transform ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED notifications to indicate multiple supported algorithms. A message accepting an SA may contain at most one. The transform IDs currently defined are: NAME NUMBER DEFINED IN ----------- ------ ----------- RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051 values 5-240 are reserved to IANA. Values 241-255 are for private use among mutually consenting parties. page 83: Old: IPcomp Transform IDs New: IPComp Transform IDs page 85: Old: [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998. New: [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. === eom ===
- Working Group Last Call IKEv2 Barbara Fraser
- IPComp editorial comments (Re: Working Group Last… Abraham Shacham
- Re: Working Group Last Call IKEv2 Francis Dupont
- Re: Working Group Last Call IKEv2 Francis Dupont
- Identity protection [Re: Working Group Last Call … Scott G. Kelly
- RE: Identity protection [Re: Working Group Last C… Pagliusi PS