RE: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
"D. Hugh Redelmeier" <hugh@mimosa.com> Mon, 17 July 2000 16:06 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 JAA17718; Mon, 17 Jul 2000 09:06:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14983 Mon, 17 Jul 2000 10:50:23 -0400 (EDT)
X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs
Date: Mon, 17 Jul 2000 11:01:03 -0400
From: "D. Hugh Redelmeier" <hugh@mimosa.com>
Reply-To: hugh@mimosa.com
To: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>
cc: Henry Spencer <henry@spsystems.net>, 'Dan Harkins' <dharkins@cips.nokia.com>, 'Jan Vilhuber' <vilhuber@cisco.com>, '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: <003901bfecfa$28ec57e0$d23e788a@andrewk3.ca.newbridge.com>
Message-ID: <Pine.LNX.4.21.0007171057050.23915-100000@redshift.mimosa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
| From: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com> | Date: Thu, 13 Jul 2000 14:42:55 -0400 | Hugh: | | > One complaint about enforcing uniqueness of Message IDs is that it | > appears to require an unbounded amount of state in an ISAKMP SA to | > store all the used Message IDs. Although the state for each Message | > ID is small (4 octets), there might be a very large number of them. | > | > It turns out that there is a simple way to prune this state: | > negotiate a new ISAKMP SA and delete the old one. At this point, none | > of the state matters any more. It was only used to enforce uniqueness | > of future Message IDs for exchanges under the protection of the old | > ISAKMP SA, and there will be none. | | IMHO, we have already passed up one opportunity to have a technically | clever, fully stateless protocol and we should not do it again. | | Requiring the peer to keep track of an array of unsolicited data that you | generate breaks the general rule of thumb that a host should be able to | control the bound on the amount of data he stores. Forcing a rekey to remedy | this situation is not acceptable IMO. As I understand it, the point of statelessness in Photuris was so that a Bad Guy could not put a heavy burden on the keying agent. This is a much less severe problem in IKE Phase 2: the peer has already authenticated itself. So a random Bad Guy would not be able to trigger this buildup of state. Have I missed the point of statelessness? Of course, the protocol isn't stateless in any interesting way. We've got several IPsec SAs as the product of each Quick Mode, and each of them has state that is significantly larger than the 4 octets of a Message ID. Presumably a peer that can establish an ISAKMP SA will probably be able to create as many IPsec SAs as it wishes (perhaps duplicates). If a Bad Guy can build an ISAKMP SA, he can crush us with way more than a surfeit of Message IDs. It is true that (most) Informational exchanges and New Group modes consume a Message ID. But they are optional. An implementation could exploit this if space is at a premium -- ignore them and ignore their Message IDs. I just don't see that the 4 octets add up to a dominant requirement for memory. If replaying of Informational exchanges and New Group Modes is of no concern, uniqueness could be dropped as a requirement for them. Thus only Quick Mode Message IDs need be saved. I'm not sure I like this, but I point it out. If replaying of Informational exchanges and New Group Modes is of concern, is there any other mechanism to prevent a replay attack using them? Replaying an INITIAL_CONTACT, for example, is quite nasty; that is one reason why we recommend that it not be part of an Informational Exchange (Unacknowledged or Acknowledged). Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253
- simplifying rekeying [draft-jenkins-ipsec-rekeyin… D. Hugh Redelmeier
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Jan Vilhuber
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… D. Hugh Redelmeier
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Dan Harkins
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Jan Vilhuber
- RE: simplifying rekeying [draft-jenkins-ipsec-rek… Andrew Krywaniuk
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Henry Spencer
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Dan Harkins
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… D. Hugh Redelmeier
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Bill Sommerfeld
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Dan Harkins
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Valery Smyslov
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Bill Sommerfeld
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Paul Koning
- RE: simplifying rekeying [draft-jenkins-ipsec-rek… D. Hugh Redelmeier
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Valery Smyslov
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… David W. Faucher
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Dan Harkins
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… D. Hugh Redelmeier