[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ack-ed NOTIFY in "dangling" implementations
Thanks Tero - that also matches my understanding.
The problem I am trying to solve - is to use Ack-NOTIFY as a mechanism for
periodic keep-alive exhchanges, which looks like will force my implementation
to maintaining continuous (or almost-continous) IKE SA channel :((. It
doesn't seem will work well with non-continuous channels (unless we can live
with unprotected keep-alives when protection is not available - do you have an
opinion on that?)
Tero Kivinen wrote:
> Bronislav Kavsan writes:
> > It looks like that there may be an issue with "dangling" implementations
> > and Ack-ed NOTIFY - where IKE SA channel may not be around to send
> > Acknowledged NOTIFY (which looks like always requires protection).
> > Should IKE SA re-negotiated on-demand when Ack-ed NOTIFY needs to be
> > sent?
> If you want to send something having IKE SA protection, and you don't
> have one, you need to create one. So answer is yes, you need to
> re-negotiate if you want to send acknowledged notify. Another option,
> is not to send the notification at all, or send is using unprotected,
> unacknowledged notify.
> > Seems like a bit of waste just for sending simple NOTIFY message
> > and may cause some catch 22 problem.
> If you had temporary resource problem few hours ago, and you removed
> the IKE SA because of that, you might have enough resources now to
> recreate it without problems.
> I am not saying that we should always remove the IKE SA, I am saying
> that we should keep that option, so we can do it in case we need it.
> kivinen@xxxxxx Work : +358-9-4354 3218
> SSH Communications Security http://www.ssh.fi/
> SSH IPSEC Toolkit http://www.ssh.fi/ipsec/