[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
| 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
References: