RE: Heartbeats draft (fwd)

[Rajesh Mohan <RMohan@xxxxxxxxx>]

If IKE does not have heartbeats, what is the best we can do within the
framework of current standards for peer synchronization? Here is a possible
solution which in the worst case, will force tunnel end points to have Phase
1 SAs with all other known tunnel end points. By known tunnel endpoints, I
mean those IKE peers with known IP Address.

So, for a Security G/W, we will have few known tunnel end points for
site-to-site traffic & lot of unknown tunnel end points for each remote
client.

For Remote Client Software, there will be few known tunnel end points and
probably no unknown tunnel endpoints.

Also, if you receive an INVALID SPI notification for a SA that is not old
enough (local policy issue), you may ignore it as it may be spoofed NOTIFY
message or the box rebooted immediately after establishing phase 1 SA. In
either case, there is no need to change your behavior.


Based on the assumptions, let us consider three cases 

1.	Security G/W to Security G/W (site-to-site) when one of the boxes
reboot
2.	Security G/W to Remote Client when the Security G/W reboots
3.	Security G/W to Remote Client when Remote client reboots.



Case 1:

H1  -------------- [ S G/W 1 ] ------ [ S G/W 2 ] ---------- H2

The G/Ws have phase2 SAs & for some reason, G/W 2 reboots. For traffic from
H1 to H2, G/W2 will send an INVALID SPI notification. If the G/W 2 can find
from it's database that the destination of INVALID SPI is part of the VPN
that is defined and it does not have phase 1 SA with this G/W 1, then
establish a phase 1 SA with G/W 1 & send INVALID SPI. This may also result
in sending INITIAL-CONTACT message which will help the two to synchronize. 

Case 2:

RC1 -------  [ S G/W ] -------------- H1


S G/W reboots. Secure traffic arrives from RC1 for H1. S G/W sends INVALID
SPI. It looks in its database & does not any knowledge about the RC1 IP
Address. Sends the notify in clear.

RC1 receives INVALID SPI in clear from S G/W. It looks for phase 1 & phase 2
SAs with  S G/W. It should atleast find Phase 2 SA. If the time difference
since the SA was created was old enough (local policy decision depending on
the seriousness of DOS attack on Clients), create new Phase 1 SA with S G/W.
It should receive INITIAL-CONTACT message from S G/W which will help the
peers to synch.


Case 3:

RC1 --------- [ S G/W ] --------------- H1

RC1 reboots. No big deal. Happens all the time. Ignore it.


There may be dead lock when [S G/W 1] has phase 1 SA with [S G/W2] that is
different from [S G/W2] having phase 1 SA with [S G/W1].

- Rajesh M


	----------
	From:  CHINNA N.R. PELLACURU [SMTP:pcn@cisco.com]
	Sent:  Thursday, March 30, 2000 4:27 PM
	To:  Henry Spencer
	Cc:  IP Security List
	Subject:  RE: Heartbeats draft (fwd)

	What I am trying to point out is that, it is possible (efficient) to
do it
	in an implementation specic way, within the framework of the current
	IKE/IPSec standards. Heartbeats is not the only solution to the
problem,
	and heartbeats are not efficient.

	-chinna

	On Thu, 30 Mar 2000, Henry Spencer wrote:

	> On Wed, 29 Mar 2000, CHINNA N.R. PELLACURU wrote:
	> > I think, everybody is aware of atleast one implementation that
elegantly
	> > provides high availability, in the current framework of IKE and
IPSec. So,
	> > I feel that high availability can be acheived in an efficient
way if we do
	> > it in an implementation specific way.
	> 
	> Uh, no, not everybody is aware of such an implementation.  Please
be more
	> specific instead of vaguely alluding to it.  Explanations of
exactly how it
	> is done would also be welcome.
	> 
	>                                                           Henry
Spencer
	>
henry@spsystems.net
	> 
	> 
	> 

	chinna narasimha reddy pellacuru
	s/w engineer