[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simultaneous connection attempts
hi,
I believe the case is rather common (at least, I've met that several times). As long as both systems keep both SA's, that does not matter.
Regarding initial contact, RFC 2407 says (4.6.3.3 INITIAL-CONTACT)
[...] The receiver of this Notification Message might
then elect to delete any existing SA's it has for the sending system
under the assumption that the sending system has rebooted and no
longer has access to the original SA's and their associated keying
material.[...]
notice the _might_ delete (stronger than "may").
And a heuristic tells the hosts that the other side has always been alive (at least from time t) since (taking the names in your example) host A received packets from B regarding SA0 _after_ some non-(CKi,0) (i.e. non initial phase 1) packets from B regarding SA1 were received. (converse is true for B). If B had died somewhere, it would have forgotten about SA0 and stopped responding to SA0 related exchanges for ever.
This works since the notification is done under the protection of a phase 1 SA. There are different cases but I think for any situation, both peers _can_ realize they are under a "Simultaneous connection" situation.
I do not know a standard "workaround" (provided this is seen as a problem, which it is not really). As far as resource efficiency is concerned, I agree it would be nice to discard one of the SA's at that point.
regards,
Frederic Detienne
jari.arkko@ericsson.com wrote:
>
> Hi. I'm trying to understand the ISAKMP/IKE specifications with
> respect to what happens when, for some reason, both hosts start
> initiating a connection at the same time.
>
> My first concern when I started looking at this was a system where
> something - memory, CPU, or user interface - places limits on the
> number of SAs open to a particular host. In such a system it would not
> be desireable to hold open two ISAKMP SAs. Rather, it would be nice if
> the other SA creation could simply be refused. However, it is not
> clear to me if this is possible. If both ends implement a scheme where
> they e.g. refuse another incoming ISAKMP connection from a host they
> have themselves just started negotiating with, then both attempts will
> fail. That is, if both hosts start their initiating-side negotiations
> at the same time or within end-to-end delay time, then both think they
> were the first. I would appreciate pointers or comments from the
> members of this list regarding how such situations should be handled,
> if they can be handled. It is also necessary that any mechanism for
> this purpose allows renegotiation of expiring SAs, and works both
> for phase 1 and phase 2.
>
> Secondly, it is not clear to me how INITIAL-CONTACT works in this
> particular case. If both sides think they are the first, then they
> must include INITIAL-CONTACT as a part of the phase 1 negotiation.
> Wouldn't this mean that both sides will delete their own connection
> as they receive the final packets from the connection initiated by
> the other host? Here's the sequence of events (assuming main mode
> and INITIAL-CONTACT as a part of the last message):
>
> Time What
> ------------
> t+0 A initiates SA0 by sending the first request packet
> B initiates SA1 by sending the first request packet
>
> t+1 B receives first packet of request for SA0
> A receives first packet of request for SA1
>
> t+2 ... (negotiations proceed) ...
>
> t+3 B is ready with SA0, sends A the last message,
> and deletes SA1 because A said INITIAL-CONTACT
> A is ready with SA1, sends B the last message,
> and deletes SA0 because B said INITIAL-CONTACT
>
> t+4 A receives the final packet for already deleted SA0
> B receives the final packet for already deleted SA1
>
> In the end both hosts have one side of an SA ready, but not matching
> sides of the same SA! Is this a problem or have I missed something?
>
> Jari Arkko
> Ericsson
--
------------------------- * oOo * -------------------------
CiscoSystems
Frederic Detienne, CDE
Security & Network Services
Tel 32 2 705 55 55
References: