[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
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.
Follow-Ups:
References: