[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Racing QM Initiator's
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
>
Follow-Ups:
References: