[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Simplifying IKE
> -----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?
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).
Personally I prefer a 4 packet exchange model for QM.
>
> In addition to this text there is new text instructing implementations
> to deal with receipt of an offer to create an IPsec SA with a SPI that
> is currently in use as an error, and new text instructing the Initiator
> to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in case
> it is dropped and he receives a retransmitted 2nd message from the
> Responder.
>
> This is much simpler than what we have and solves the race problem.
> What it does, though, is allow for some resources to be temporarily
> consumed due to the replay of an old message. I don't view this as that
> big of a problem though since it is temporary (RETRANSMIT_TIME *
> RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> the SADB) and the number of possible packets that can be replayed is
> limited and bounded by the life of the IKE SA.
>
> Thoughts?
>
> Dan.
>
> On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> >
> > Dan McDonald wrote:
> > >
> > > > >From the Schneier and Ferguson analysis we get:
> > > >
> > > > Can we drop the commit bit?
> > >
> > > Who uses it?
> >
> > I guess someone in past figured out that running IKE on satellite lines
> > is necessary, so they decided to optimize as much as possible.
> The result
> > was that both aggressive mode and quick mode both have three messages.
> > The problem with three messages is that the initiator will
> often start sendin
> >g
> > actual traffic too soon, or quick mode packets, before the
> responder is ready
> >. Thus
> > the need for packet buffers, commit bit, whatever. This
> optimization causes d
> >esign
> > complications that I'd very much prefer to get rid of.
>
Follow-Ups:
References: