Re: comments on draft-ietf-ipsec-new-esp-00
Stephen Kent <kent@bbn.com> Sat, 05 April 1997 13:28 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17475 for ipsec-outgoing; Sat, 5 Apr 1997 08:28:35 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v03007805af6bfed24032@[128.89.30.3]>
In-Reply-To: <01BC4020.D79923C0@Tastid.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 05 Apr 1997 08:14:08 -0500
To: adams@cisco.com
From: Stephen Kent <kent@bbn.com>
Subject: Re: comments on draft-ietf-ipsec-new-esp-00
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Rob, Some more responses to your additional comments: >Section 2.3: > >The draft should probably state that the IV should always be a multiple of >32 bits. >Or require multiples of 64 for IPv6. Well, this is really an algorithm independence issue. We don't get to pick IV lengths; they are defined by the algorithms. However, we can require this field to be a multiple of 32 bits and note that if the real IV does not conform to this requiremend, then the algorithm spec will describe how padding is performed. >Section 2.4: > >To solve the alignment problem, could we always simply require the replay >field. >Don't use it if you don't have AH but leave it there with random trash >otherwise >to preserve alignment. I don't believe I'm saying this... %) Yes, we could, but I hesitate to adopt that approach. It wastes space in an IPv4 context, and the presence/absence of an IV also affects the overall alignment problem, so always requiring the sequence number does not fix this in all cases anyway. For example, if one uses the 32-bit IV (for DES CBC) that is part of the original RFCs, and one allocates 32 bits for the anti-replay sequence counter, we have an IPv6 alignment problem anyway! Steve
- comments on draft-ietf-ipsec-new-esp-00 Rob Adams
- Re: comments on draft-ietf-ipsec-new-esp-00 Stephen Kent
- Re: comments on draft-ietf-ipsec-new-esp-00 Steven Bellovin