[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: Thursday, August 09, 2001 1:00 AM
> To: sankar ramamoorthi
> Cc: ipsec@lists.tislabs.com
> Subject: 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.
>
Got it. I misunderstood this part.
Does it mean the bogus SAs even though they are short-lived can receive
packets? This is the part that bothers me. If packets can be received on
the bogus SA, what prevents some one to replay data packets through the
bogus SA (If QM message 1 can be replayed then it is possible for ipsec
packets from a previous session to be replayed as well). Such packets will
then be accepted as valid packets. Does it not open up a security hole?
What am I missing?
> > 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.
So for this short duration all SA(including bogus SAs) are treated equal
ie: the responder assumes the SAs are properly instantiated even though
the third message is not received yet.
>
> > 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.
>
References: