[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Racing QM Initiator's

>  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.
>

I was talking about the case where the the selectors are same.

I did not mean 'drop a simultaneous negotiation' to be part of the
protocol. What I was wondering was the could QM states have been 
arranged such that the resulting exchanges could have resulted 
in one SA rather than two.

My first thought was 
A QM Initiator can be equated to an active TCP open.
A QM Responder can be equated to a passive TCP open (listener).
So analogus to TCP the in QM state machine it should be possible
for two QM initiators to arrive at a connected state.

On furthur reflection I understand that they are different.
The initiator and responder have a clear role to play to complete
the negotiation of crypto parameters. TCP has no such clear distinction.


I was thinking along these lines of how simultaneous QM exchange
could happen between two parties.

I have not through it fully and there may many flaws.

First Exchange
--------------

HDR*, HASH(1), SA, Ni1,                HDR*, HASH(1), SA, Ni2
[, KE], [, IDci, IDcr] ----->    <---- [, KE], [, IDci, IDcr] 

Second Exchange
---------------

HDR*, HASH(2), SA, Ni1,                HDR*, HASH(2), SA, Ni2
[, KE ], [, IDci, IDcr]----->    <-----  [, KE ], [, IDci, IDcr]

Third Exchange
-------------

HDR*, HASH(3)          ----->    <-----HDR*, HASH(3)
                      

If we assume an SA list is proposed in the first exchange is in
ordered list with the most preferred one in the beginning,
then we can assume that both parties will arrive at the same
preferred SA in exchange 2. 


I am perfectly comfortable with the current protocol definition and
I see no reason to change it.

My questions are more of out of curiosity.

'Is there any special benefit to defining a protocol exchange which
 allows simultaneous opens w.out dropping a connection (assume same
selectors)?'
'If there is, is it worthwhile for QM exchanges to have been defined
 that way?'
'Is it possible for QM exchanges to have been defined that way?'


>  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.
>
>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