(Active)
+-------+
| SGW 1 |
+-------+
+-------+------- Internet -------- | SGW
3 |
+-------+-------/
+-------+
| SGW 2 |
+-------+
(Backup)
SGW = Secure Gateway
If SGW 1 dies SGW doesn't have a clue about the SPIs that SGW 3
is sending. How he will inform the other end?
About the problem on routing. This is intermitment problem and
if there is no connectivity for more that X seconds it's a good idea to
delete the SA. What if somebody re-routed connection to somewhere and getting
packets with the intent to crack the key? If SGW start sending only UDP
500 IKE clean-text messages he will be doomed
Bill Sommerfeld wrote:
As several people brought up in the meeting, "keepalives" under the
wrong circumstances tend to turn into "make-deads". IKE and IPSEC
implementations should not delete SA's prior to their normal
expiration merely because they haven't heard from the other end in a
while.There appear to be two different properties people are looking for
from heartbeats/keepalives:First, rapid recovery from loss of state on one end of a security
association (due to power loss/reboot/reset), so a new IKE SA can be
initiated on one end or the other. Once this happens, the half-dead
state on one end can be garbage collected as a result of an
affirmative indication (IKE INITIAL-CONTACT) that the other side lost
state.Second, detection of loss of connectivity between two security
gateways so that traffic can be rerouted through an alternate gateway.
This is really a dynamic routing problem and could (and probably
should) be done without prematurely tearing down IKE SA's and IPSEC
SA's which may still exist and may still be useful once the
connectivity comes back.It's not clear that the same protocol feature can/should provide both
of these properties..- Bill
--
Vlado Zafirov
RADWare, INC
Technical Support Engineer
Tel: (202) 625-1505
Fax: (202) 625-1506
Confidentiality note: This message, and any attachments to it, contains
privileged/confidential information of RADWARE Ltd./RADWARE Inc.
and may
not be disclosed, used, copied, or transmitted in any form or by
any means
without prior written permission from RADWARE. If you are not the
intended
recipient, delete the message and any attachments from your system
without
reading or copying it, and kindly notify the sender by e-mail.
Thank you.