[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.
Follow-Ups: