RE: problems with draft-jenkins-ipsec-rekeying-06.txt
"Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com> Mon, 24 July 2000 23:53 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 QAA26062; Mon, 24 Jul 2000 16:53:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15530 Mon, 24 Jul 2000 18:48:23 -0400 (EDT)
Reply-To: andrew.krywaniuk@alcatel.com
From: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>
To: hugh@mimosa.com
Cc: 'Henry Spencer' <henry@spsystems.net>, 'Andrew Krywaniuk' </o=TimeStepCorporation/ou=TIMESTEP/cn=Recipients/cn=akrywaniuk@newbridge.com>, 'Tim Jenkins' <TJenkins@Catena.com>, 'IPsec List' <ipsec@lists.tislabs.com>, 'Hugh Daniel' <hugh@toad.com>, 'John Gilmore' <gnu@toad.com>
Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt
Date: Mon, 24 Jul 2000 18:51:49 -0400
Message-Id: <005e01bff5c1$c1317380$d23e788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <Pine.LNX.4.21.0007231533110.13507-100000@redshift.mimosa.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> | Replacing unbounded state creation with unbounded rekeying > frequency is no > | solution. Fine, so this problem is kind of academic, but > you are endagering > | the ability of a host to be fully self-stablizing (and that > is of academic > | interest to me). > > Can you expand on this? Sure, I guess (although I suspect many people are getting bored of this topic). As I said, this is of mainly academic interest to me. I believe that a networking protocol should allow compliant implementations to be robust. If you want to be fully self-stabilizing then you need to be able to predict and control your behaviour, even while under heavy load or attack. Relying on dynamic memory allocation under low memory conditions can make a system very unpredictable. The proof of self-stabilization is akin to mathematical induction. Instead of merely stating that abnormal situation S_t shouldn't happen, you assume S_(t-1) is stable and show that S_t = S(t, S_(t-1)) is also stable. [Note than I am distinguishing between "abnormal" and "unstable" states here. (An abnormal situation should not cause unstable behaviour in a robust implementation.)] One important key to ensuring the predictability of your behaviour is that YOU (rather than the peer) get to decide how to bound your CPU consumption and memory usage. That's why it's best to avoid statements like "the host MUST store each X" or "the host MUST reply to (unsolicited) messages of type X". As I'm sure you're aware, the danger of an unstable system under heavy load is that after it corrects its behaviour (usually by crashing and rebooting), the situation which created the heavy load still exists (and is often worsened by the increased demand which is generated by the temporary outage). This may cause the instability to re-manifest itself. Witness the famous AT&T crash of 1990 or the recent DDoS attacks on websites or the Bill Clinton chatroom bug. Or consider the well-known logging bug where an application has a log message for "log is full" but they forget to reserve space in the log for this abnormal condition. A similar bug often manifiests itself on Windows systems when a careless implementer stores the "Out of Memory" message in the stringtable resource. It's easy for a system to be stable if it has very limited functionality. The danger here is that most of us want to make the most of the resources we have. Right now, we can't determine ahead of time exactly how much memory will be required to negotiate and store an SA of either type (although the SA footprints have much less size variance than the dynamic memory required during negotiation). However, once an SA has been created, it's size never needs to change. That's the beauty of bounded connection state. Even if you run out of dynamic memory, your existing SAs are not affected. You are also able to ignore unsolicted messages from the peer. If the peer sends a QM and you don't have the memory or the CPU power to handle the message, you can simply ignore it with no bad consequences. Now let's consider what happens if you need to process a QM under heavy load conditions: 1) A QM comes in and you don't have the CPU resources to parse it. You drop the message but the peer assumes you have received it, so the message id lists for the Isakmp SA get out of synch. or 2) A QM comes in and you don't have enough memory to store the message id. Therefore, you delete the Isakmp SA and renegotiate. However, the negotiation fails because you don't have enough memory to complete it. Now you have lost an SA that used to work + the peer will probably continue to retry the negotiation and it will continue to fail, thus wasting additional CPU resources. or 3) As above, except that the renegotiation of the Isakmp SA succeeds. Then the peer resends the QM and you don't have enough memory to store the message id, so you delete the Isakmp SA, attempt to renegotiate, and end up thrashing endlessly (this is particularly bad if it happens to multiple SAs simultaneously). And, of course, if you are susceptible to this problem under heavy load, then this behaviour can also be exploited by a malicious intermediate router (particularly if you store the message ids of info modes in addition to QMs). On the other hand, a counter (which was also proposed as a solution to the replay attack) does not require any additional memory allocation, nor does it require you to process every packet from the peer. Therefore, there is no potential for the counter to create unstable behaviour. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable.
- 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