Re: Racing QM Initiator's
"Valery Smyslov" <svan@trustworks.com> Thu, 14 October 1999 11:03 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 EAA15380; Thu, 14 Oct 1999 04:03:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA27314 Thu, 14 Oct 1999 05:29:48 -0400 (EDT)
Message-Id: <199910140931.NAA21314@relay1.trustworks.com>
From: Valery Smyslov <svan@trustworks.com>
Organization: TWS
To: Sankar Ramamoorthi <Sankar@vpnet.com>, Dan Harkins <dharkins@network-alchemy.com>
Date: Thu, 14 Oct 1999 13:31:21 +0400
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: Racing QM Initiator's
CC: "'Scott G. Kelly'" <skelly@redcreek.com>, Jan Vilhuber <vilhuber@cisco.com>, Ben McCann <bmccann@indusriver.com>, ipsec@lists.tislabs.com
In-reply-to: <199910140435.VAA22465@Potassium.Network-Alchemy.COM>
References: Your message of "Wed, 13 Oct 1999 20:46:03 PDT." <D899E9E27BE9D211842200805FA67B431B9575@vpnet.com>
X-mailer: Pegasus Mail for Win32 (v3.12a)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On 13 Oct 99, at 21:35, Dan Harkins wrote: > A TCP service (which, if you read the Stevens chapter is bound to > both a source and destination port) can get away with having only one > connection with simultaneous opens because that service only does one > thing. A different example is BGP in which one side can be both doing a > connect to a particular host and an accept on the BGP tcp port. The > connect and accept can both happen "simultaneously" but only one > particular connection results (the unpreferable connection will be > dropped). > > But IKE is different. In IKE there can be 2 simultaneous Quick > Modes which could be the result of different packets hitting different > selectors both of which would need IPSec SAs but both can multiplex > off the same existing IKE SA. You can't just arbitrarily drop a > negotiation because you're already negotiating with that IKE peer. Dan, it's OK with simultaneous phase 2 negotiations. But what about simultaneous phase 1 negotiations? Is there any reason (besides implementation simplicity) not to drop one of negotiation (of course, with some clear rule to decide which one, for examble, based on IP addresses comparison)? 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? > Basically, you have to allow simultaneous negotiation or else you > would not be able to support a configuration which had different > traffic selectors (optionally using different IPSec policy) to the > same gateway. > > Dan. Regards, Valera. > > On Wed, 13 Oct 1999 20:46:03 PDT you wrote > > While I agree with the notion of supporting multiple independent SAs > > > > this question is more out of curiosity. > > > > >From Richard Steven's TCP/IP Volume 1 Chapter 18.8 paragraph 4 > > > > 'TCP was purposely designed to handle simultaneous opens and the rule is > > only one > > connection results from this, not two connections. (Other protcol suites, > > notably the OSI transport layer, create two connections in this scenario, > > not one).' > > I believe there is similiar wording in RFC 793 emphasising simultaneous > > open. > > > > I don't know if there is a particular advantage to this feature. > > During the initial design of IKE did such an approach (simultaneous > > connections > > resulting in one connection) come up in the discussions? Is it worthwhile > > or feasible for a security protocol? > > > > Thanks, > > > > -- sankar -- > > > > > > > > -----Original Message----- > > From: Scott G. Kelly [mailto:skelly@redcreek.com] > > Sent: Wednesday, October 13, 1999 6:27 PM > > To: Radha Gowda > > Cc: Jan Vilhuber; Ben McCann; ipsec@lists.tislabs.com > > Subject: Re: Racing QM Initiator's > > > > > > Radha Gowda wrote: > > > > > > To the list at large: > > > > > > > > Why can't we put verbiage like this into the RFC? Is there some reason > > this > > > > is a bad thing to do? > > > > > > I also would like to point out to the list that Diffie-Hellman calculation > > does > > > not > > > come cheap for some of us (atleast for now). > > > > I think the point is that we must be able to support independent > > simultaneous SAs between security gateways. Otherwise, how will we > > provide PFS? If you cannot handle the DH calculation, then I suppose > > that you can serialize these, but this is not a good argument for > > dumbing down the standard, is it? > > > > Scott >
- Re: Racing QM Initiator's Radha Gowda
- Re: Racing QM Initiator's Ben McCann
- Re: Racing QM Initiator's Will Price
- Racing QM Initiator's Ben McCann
- Re: Racing QM Initiator's Radha Gowda
- Re: Racing QM Initiator's Radha Gowda
- Re: Racing QM Initiator's Dan Harkins
- Re: Racing QM Initiator's Scott G. Kelly
- Re: Racing QM Initiator's Kanta Matsuura
- RE: Racing QM Initiator's Sankar Ramamoorthi
- Re: Racing QM Initiator's Dan Harkins
- Re: Racing QM Initiator's Valery Smyslov
- Re: Racing QM Initiator's Radha Gowda
- Re: Racing QM Initiator's Jan Vilhuber
- Re: Racing QM Initiator's Jan Vilhuber
- Re: Racing QM Initiator's Shawn Mamros
- Re: Racing QM Initiator's Vipul Gupta
- Re: Racing QM Initiator's Scott G. Kelly
- Re: Racing QM Initiator's Scott G. Kelly
- RE: Racing QM Initiator's Sankar Ramamoorthi
- RE: Racing QM Initiator's Andrew Krywaniuk
- Re: Racing QM Initiator's Valery Smyslov
- Re: Racing QM Initiator's Valery Smyslov
- Re: Racing QM Initiator's Markku Savela
- Re: Racing QM Initiator's Scott G. Kelly
- Re: Racing QM Initiator's Paul Koning