[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Daemon Recovery
> Matt,
>
> >Be careful. If your ISAKMP daemon dies and restarts AND your IPSEC SAs
> >are kept elsewhere (kernel, another daemon, whatever) you only want to
> >the remote ISAKMP daemon to forget about ISAKMP SAs. It should leave
> >the IPSEC SAs alone.
>
> Oh yeah, agreed.
Actually, let's revisit this. How would you propose to differentiate
between a host that has actually rebooted and lost both its ISAKMP and
IPSEC SA's from one where only the ISAKMP service has been restarted? Is
it really worth having two separate Notification status messages?
> >The messages (I'd call it RESTART) should send include the DOI for which
> >the SAs should be forgotten. Multiple RESTART notification payloads can
> >be included if more than one DOI needs to flushed.
>
> The DOI is included in the Notification Payload. If you wanted to flush
> more than one DOI, you could include more than one Notification Payload
> in a single informational exchange.
>
> Assuming we went this route...
>
> Derrell
I've written the following so far, which assumes one message for both:
4.6.3.3 INITIAL-CONTACT
The INITIAL-CONTACT status message may be used when one side wishes to
inform the other that this is the first SA being established with the
remote system. The receiver of this Notification Message might then elect
to delete any existing SA's it has for the sending system under the
assumption that the sending system has rebooted and no longer has access to
the orignal SA's and their associated keying material. When used, the
content of the Notification Data field SHOULD be null (i.e. the Payload
Length should be set to the fixed length of Notification Payload).
Follow-Ups: