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

RE: Simplifying IKE





> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Wednesday, August 08, 2001 6:32 PM
> To: sankar ramamoorthi
> Cc: Ari Huttunen; ipsec@lists.tislabs.com
> Subject: 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.

which means in the worst case packets from the sender will be dropped for
the duration (RETRANSMIT_TIMER_LIMIT * round-trip-time).

This leads to an ambiguous state where the packets may or not be dropped
by the responder. It is also possible that if initiator is sending data
at a high rate, it could affect the responder from retransmitting message2
and getting message3.

With a 4 packet exhange scheme, each party knows for sure the other side
has the SA established before sending data. The state transitions seem
to be much cleaner here.

Both solutions require that the COMFORT_LEVEL_TIME is set be greater
than equal to (RETRANSMIT_TIMER_LIMIT * round-trip-time) to ensure the
initiator keeps the state around long enough for the responder to
move from processed-message1-state to processed-message3-state
(or processed-message2-state to processed-message4-state in the case of
4 packet exchange).


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

I agree - this was just an idea that I threw around to see if
it is possible to come up with a 2 message solution.

> > Personally I prefer a 4 packet exchange model for QM.
>
> What shortcoming in the scheme I described is solved with a 4 packet
> exchange?
>

see above.

>   Dan.
>



Follow-Ups: References: