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

Re: Simplifying IKE



I agree with Derrell - if you remove commit bit, you must add a
mandatory fourth qm message (which would be fine with me).

Scott

Derrell Piper wrote:
> 
> The other property that commit-bit processing buys you is that the third
> message of QM is now protected by the IKE retransmit timer and thus QM is
> guaranteed to complete enough for both sides to generate IPsec SA's, even
> when the last message (the ISAKMP Notify "CONNECTED") is lost.  If you
> don't use commit-bit processing, the last message of QM can be dropped and
> this leaves you in the particularly bad state where one side has SA's and
> the other doesn't.
> 
> Personally, I would rather burn a full network exchange to ensure that my
> really expensive key agreement protocol actually completes instead of
> having to just hope that the network didn't drop my last packet, which is
> what you're betting on today when you don't use the commit-bit.
> 
> Derrell
> 
> --On Wednesday, August 8, 2001 12:19 PM +0300 Ari Huttunen
> <Ari.Huttunen@F-Secure.com> wrote:
> 
>  >> >     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
>  > sending 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 design  complications that I'd very
>  > much prefer to get rid of.
>  >
>  > Thus my preference would be to have a four packet phase 1 (base mode) and
>  > a four packet quick mode.
>  >
>  > The other reason I prefer base mode is that the responder can select the
>  > proper policy based on the first packet.
>  >
>  > If main mode had the possibility to send a group identity in packet one
>  > and actual identity in packet five, I wouldn't object to just having main
>  > mode, since it does have an even number of packets.


References: