[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
I'm obviously explaining myself poorly and that's not a good way
to start of this discussion....
On Wed, 08 Aug 2001 19:04:25 PDT you wrote
>
>
> > -----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).
No, they are not dropped in any case. They are properly received because
the Responder has instantiated the SAs before she sends the 2nd message.
> 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.
No it doesn't matter how fast the Initiator sends packets (assuming you
mean IPsec-protected packets) because the Responder will have properly
instantiated SAs _before_ the Initiator has. By the time the Initiator
has all the information to instantiate his own SAs the Responder will
already have instantiated hers. No packet loss.
> 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.
I think you're misunderstanding what I'm proposing. If the Responder
instantiates her SAs when she sends the 2nd message then what's the
problem? How does this not work? The Responder has SAs ready before
the Initiator does so there is no packet loss.
> > > 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.
If you can come up with a 2 message solution I think we will all be
happy. Please do so; I cannot come up with one that is simpler than the
3 message one I'm proposing.
> > > 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.
I don't see a shortcoming above. Can you describe to me a situation that
will not work with what I propose but will work with a 4 message exchange?
Dan.
Follow-Ups:
References: