[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
On Wed, 08 Aug 2001 13:31:43 PDT you wrote
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> > Sent: Wednesday, August 08, 2001 10:49 AM
> > To: Ari Huttunen
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: Simplifying IKE
> >
> >
> > My tentative text on the subject is to get rid of the commit bit and
> > have a 3 message exchange. The problem with the existing 3 message
> > exchanage (w/o the commit bit being used) is that the Responder will not
> > instantiate her SAs until receipt of the 3rd message from the Initiator
> > to avoid a resource consumption attack but the Initiator will instantiate
> > his SAs upon receipt of the 2nd message from the Responder. This results
> > in a race between the first few IPsec-protected packets and the final
> > message. If the former win they get dropped.
> >
> > My proposal is that the Responder instantiate the SAs when she sends
> > the 2nd message back to the Initiator. She will be setting a timer to
> > deal with non-receipt of the 3rd message and if the timer fires
> > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> > and she can delete these SAs from her SADB.
>
> What happens if the initiator starts sending data before the responder
> receives the third message?
Nothing. That's the whole idea.
> Will the ipsec packet from initiator be processed since responder has
> established the SA on receipt of the second message? If so, can the
> responder treat succesful processing of the data packet as succesful
> authentication of the initiator and mark the SA as valid(basically
> treat the condition same as processing a successful third message).
I prefer not to make such a linkage (between the IPsec processing engine
and the key management system) since there is still a message that IKE must
process and receipt of that message will dictate whether the SAs stay
or go.
> Personally I prefer a 4 packet exchange model for QM.
What shortcoming in the scheme I described is solved with a 4 packet
exchange?
Dan.
Follow-Ups:
References: