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

RE: Commit Bit Processing

Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617

> -----Original Message-----
> From: Derrell D. Piper [mailto:ddp@Network-Alchemy.COM]
> Sent: March 31, 1999 9:34 AM
> To: S. B. Kulkarni
> Cc: ipsec@lists.tislabs.com; skelly@redcreek.com; 
> rpereira@TimeStep.com;
> kivinen@ssh.fi; tjenkins@TimeStep.com
> Subject: Re: Commit Bit Processing 
> > * Can the initiator set the commit bit in case of Quick 
> mode, because what
> > RFC says is, who ever sets the commit bit should send the 
> CONNECT notify,
> > and there is no point in sending the CONNECT notify along 
> with the third
> > message of quick mode.
> Again the RFCs are ambigous on this, but it only makes sense 
> as something set
> by the responder.

There are applications that want to consider using the commit bit
in both directions. One of the specific ones I've seen is for key
recovery. See <draft-kra-ipsec-isakmp-04.txt>, for example.

> The other ambiguity (from previous bake-off experience) is whether the
> initiator should reflect the COMMIT bit back in his final 
> message.  While
> there's no real value to it, there were implementations that 
> expected this,
> and so most implementations do so.
> Derrell

I agree that there's much confusion with this bit. (I would argue
that reflecting back the commit bit is wrong, since it implies the
initiator also wants to send a CONNECTED notification.)

I'll be releasing an update to the re-keying document within a week,
and the commit bit gets a fair amount of discussion in this document.