Re: Racing QM Initiator's

"Scott G. Kelly" <skelly@redcreek.com> Thu, 14 October 1999 17:49 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA24356; Thu, 14 Oct 1999 10:49:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29589 Thu, 14 Oct 1999 12:18:49 -0400 (EDT)
Message-ID: <380603B8.6A9BF0C6@redcreek.com>
Date: Thu, 14 Oct 1999 09:24:24 -0700
From: "Scott G. Kelly" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Valery Smyslov <svan@trustworks.com>
CC: Sankar Ramamoorthi <Sankar@vpnet.com>, Dan Harkins <dharkins@network-alchemy.com>, Jan Vilhuber <vilhuber@cisco.com>, Ben McCann <bmccann@indusriver.com>, ipsec@lists.tislabs.com
Subject: Re: Racing QM Initiator's
References: Your message of "Wed, 13 Oct 1999 20:46:03 PDT." <D899E9E27BE9D211842200805FA67B431B9575@vpnet.com> <199910140931.NAA21314@relay1.trustworks.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

Valery Smyslov wrote:

<trimmed...> 
> Another curious point - how IKE handles self-connect. Let us assume
> we have IPsec host A and an attacker injects IKE packet (src_ip = A,
> dst_ip = A, CKY-I = xxx, CKY-R = 0) into the network. A receives this
> packet and (naively) begins to act as responder creating state and
> replying with packet (src_ip = A, dst_ip = A, CKY-I = xxx, CKY-R =
> yyy). Then it receives this packet back, binds it to that very state
> and, most likely, rejects it (possibly with some error notification)
> because it is malformed from his (responder's) point of view. After
> some time state will die due to timeout. Is this scenario correct? I
> understand that this situation causes no particular harm and it is
> very easy to avoid by simple sanity check (compare IP addresses), but
> still, IKE seem to have no special treatment of it, have it?

Assuming policy is correctly configured (and implemented), this packet
should never reach the IKE implementation, should it?

Scott