Re: AH and ESP Orthogonality

Ran Atkinson <rja@cisco.com> Tue, 12 March 1996 22:50 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24601; 12 Mar 96 17:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24597; 12 Mar 96 17:50 EST
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa13614; 12 Mar 96 17:50 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa22987; 12 Mar 96 17:30 EST
Received: from relay.tis.com by neptune.TIS.COM id aa22973; 12 Mar 96 17:25 EST
Received: by relay.tis.com; id RAA11122; Tue, 12 Mar 1996 17:27:42 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011120; Tue, 12 Mar 96 17:27:13 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20559; Tue, 12 Mar 96 17:26:12 EST
Received: by relay.tis.com; id RAA11117; Tue, 12 Mar 1996 17:27:12 -0500
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma011115; Tue, 12 Mar 96 17:26:58 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA29380; Tue, 12 Mar 1996 14:28:07 -0800
Date: Tue, 12 Mar 1996 14:28:07 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199603122228.OAA29380@puli.cisco.com>
To: ipsec@tis.com
Subject: Re: AH and ESP Orthogonality
In-Reply-To: <5053.wsimpson@greendragon.com>
Organization: cisco Systems, Inc., Menlo Park, Ca.
Cc:
X-Orig-Sender: ipsec-request@neptune.tis.com
Precedence: bulk

In article <5053.wsimpson@greendragon.com> Bill Simpson wrote:

>    Date: Thu, 22 Feb 1996 12:29:13 -0800
>    Message-Id: <199602222029.MAA00276@puli.cisco.com>
>
>    5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted.
>       It is WAY outside the scope of Bill's draft to modify any standards
>       track protocol and the attempt to do so is more than sufficient grounds
>       to bar publication as ANY kind of RFC until that section is deleted.
>
>So, the chairs are rather vehemently against adding replay protection,
>even as a negotiated option.

Bill,

  Not true.  The chairs are opposed to a key management protocol changing
the specification of material that is outside the scope of that key
management protocol specification.  Any attempt by any key management
specification to change the specifications contained in RFC-1825 thru
RFC-1827 is out of order.  Key management proposals MUST conform with
RFC-1825 through RFC-1827 and MUST NOT alter those specifications.

  Changes to RFC-1825 through RFC-1827 may be made only by the working
group as a whole.  If such changes are to be made, they will be reflected
in the revisions of RFC-1825 through RFC-1829 (which I will prepare in I-D
form presently).  If replay protection is added, then the key management
proposals can be modified to reflect that change afterwards.

Ran
rja@cisco.com