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

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.



Follow-Ups: References: