IETF Logo Mail Archive

Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]

Bill Sommerfeld <sommerfeld@East.Sun.COM> Mon, 17 July 2000 10:54 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11516; Mon, 17 Jul 2000 03:54:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA13390 Mon, 17 Jul 2000 05:27:51 -0400 (EDT)
Message-Id: <200007170936.e6H9a2J113489@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: Valery Smyslov <svan@trustworks.com>
cc: sommerfeld@East.Sun.COM, hugh@mimosa.com, Dan Harkins <dharkins@cips.nokia.com>, Henry Spencer <henry@spsystems.net>, IPsec List <ipsec@lists.tislabs.com>, Hugh Daniel <hugh@toad.com>, John Gilmore <gnu@toad.com>
Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
In-reply-to: Your message of "Mon, 17 Jul 2000 08:23:13 +0400." <000d01bfefa6$ba8744e0$a7253ac3@elvis.ru>
Reply-to: sommerfeld@East.Sun.COM
Date: Mon, 17 Jul 2000 05:36:02 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

> Nothing prevents implementation from keeping last received packet
> (or hash of it) in SA state and discarding any incoming packet if it
> is identical to the packet kept. At least our implementation behaves
> this way and we have never encountered your problem.

You'll still get wind up with garbled decryptions of a retransmission
if the network reorders packets on you..  i.e., if you recieve packet
1, then packet 2, then a duplicate/retransmission of packet 1.

(maybe you've not played with flakeways and other similarly "abusive"
test environments..)

						- Bill

v2.23.0 | Report a Bug | By Email