RE: problems with draft-jenkins-ipsec-rekeying-06.txt
"Mason, David" <David_Mason@nai.com> Thu, 13 July 2000 21:18 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 OAA09452; Thu, 13 Jul 2000 14:18:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01685 Thu, 13 Jul 2000 16:00:24 -0400 (EDT)
Message-ID: <447A3F40A07FD211BA2700A0C99D759B78910E@md-exchange1.nai.com>
From: "Mason, David" <David_Mason@nai.com>
To: IPsec List <ipsec@lists.tislabs.com>
Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt
Date: Thu, 13 Jul 2000 13:07:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Of course this is way late, but it would have been nice if the draft had given some discussion on the alternative loss-less rekey implementation method suggested in RFC 2408 (the NOTE: in section 3.1). The implementation note is extremely sketchy and it would have been nice if this draft could have provided some additional details on this method. This is how I interpreted the suggestion: Incoming IPsec packets with unrecognized SPIs are treated in a similar fashion to packet fragment collection (e.g., queued up with a time limit and memory consumption limit - the time limit is much smaller than one would use in fragment collection). The IKE daemon is informed of the reception of the unknown SPI (with less frequency than some specified minimum so as not to flood the daemon). If the SPI/protocol/addresses match that of a phase 2 exchange that's waiting for a third QM (or notify connected) message then the system "sets up" the SA (inbound and outbound) as if it had received the message it was waiting for and the queued unrecognized SPI packets are then processed. Otherwise it's a bogus SPI and the packets are thrown away and the event logged (if an IKE SA exists with the source of the packet a delete notify can optionally be sent). This method doesn't require pre-setup or a splitting of the inbound and outbound SAs and seems to handle the dropped 3rd QM, dropped connected notify, and out-of-order QM3/IPsec problems nicely. This method also helps for the case where a delete notify was dropped (if the peer continues to use that SPI it will get another delete notify). -dave
- problems with draft-jenkins-ipsec-rekeying-06.txt D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Tim Jenkins
- procedural RE: problems with draft-jenkins-ipsec-… Henry Spencer
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- Re: procedural RE: problems with draft-jenkins-ip… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Mason, David
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Henry Spencer
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- RE: problems with draft-jenkins-ipsec-rekeying-06… andrew.krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Henry Spencer
- RE: problems with draft-jenkins-ipsec-rekeying-06… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… andrew.krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk