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

RE: Simplifying IKE

>   In addition to this text there is [...]
> 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.


This is in fact what my implementation has been doing for quite some time. I
had never thought that this "new behaviour" was disallowed by the existing
RFCs. It seemed like the logical thing to do... But as I pointed out in
another message, the replay problem should still be quenched at the source
by providing a counter.

Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> Sent: Wednesday, August 08, 2001 6:49 PM
> 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.
>
>   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.
>
>
References: