[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Daemon Recovery
Hi Derrell,
You previously stated:
Ah, I see the confusion. There isn't a separate DOI for ISAKMP. You
say
that the message is directed at an ISAKMP SA if the message ID field
(back
in the generic ISAKMP header) is zero.
However below you state that new ISAKMP SA's are established, therefore
the notify would be protected under that SA. If it is the Message-ID
field would be a random number for the IV seed/sync.
The protocol ID field in the notify payload should do the trick,
although you might want to add text that when sent for this message type
the SPI length and value should be zero (or ignored).
If you want to specify that only ISAKMP SAs were lost send protocol ID
== PROTO_ISAKMP, if you want to specify all set it to 0 or define a new
value PROTO_ALL?
Having said that I am fine with the interpretation meaning 'purge all'
and not interpreting the protocol ID field of the notify payload.
Bye.
----
Greg Carter, Entrust Technologies
greg.carter@entrust.com
Get FREE FIPS-140-1 Validated Crypto for the desktop
http://www.entrust.com/solo.htm
>----------
>From: Derrell Piper[SMTP:piper@cisco.com]
>Sent: Wednesday, October 08, 1997 8:17 PM
>To: Roy Pereira
>Cc: 'Matt Thomas'; 'ipsec@tis.com'
>Subject: Re: Daemon Recovery
>
>Roy and Matt,
>
>The Notification Message in question is associated with a new ISAKMP SA
>between the two hosts. It's secured by the new ISAKMP SA. It's not
>relevant here just what caused the new SA to be established. It could
>have happened from either side for a variety of reasons.
>
>If you restart your ISAKMP deamon, as Matt's suggesting, then one of two
>things happens: 1) if the host who rebooted re-initiates, the other side
>presumably just responds to him and communication is established under the
>new SA's; 2) if the host who didn't reboot initiates, say because a Phase
>II SA expired and we need a new QM, then the host who did reboot is going
>to send an INVALID-COOKIE in response to the QM proposal. If the host who
>gets the INVALID-COOKIE is smart, he's probably going to assume that the
>other host has restarted and initiate a new Main Mode with him. Assuming
>that then completes, the old SA's can be tossed.
>
>It's the first case this notification message addresses: it allows the host
>who did not reboot to purge its stale IPSEC SA's for a zombie association.
>
>Does this make sense to the other ISAKMP developers here?
>
>Derrell
>
Follow-Ups: