[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC in High Availability scenarios
Title:
Suren,
This is one of the problem I am trying to solve for one of my customers.
But fortunately, we don't have requirement of using same tunnel when
the backup takes over.
Even without having to have new tunnel to be established, I did not see
any proper and interoperable solution. This is one of the reason I propose
to have 'Dead Peer Tunnel (SA) detection'. With this, the other party
know eventually that tunnel got terminated on other side and creates
new tunnel.
SA transfer may not be a good idea for several reasons.
A. Keying material also has to be sent. There may be security issues
with this.
B. SA is not stateful. If it is not there, IPSEC nodes creates new SA.
No connection will be terminated.
It is not like Firewall/NAT sessions, where some state information
needs to be syn'ed up for smooth takeover.
I don't see any requirement for this with my limited knowledge.
But if there is need for it, then the proposal you suggested seems
one possible solution.
Regards
Ravi
suren wrote:
Hi,
Small introduction:
We find the IPSEC is being used in critical applications and
high availability is one of requirements of customers. Typically
two SGs are used - one acting as Master and other acting as
backup device. VRRP like kind of utilities are used to detect
the aliveness of master SG. Backup SG inherits the same IP
address. In these cases, the remote peers don't know that
that there are two SGs and control is transferred from master
to backup device.
Problem:
Due to critical timing nature of applications run on IPSEC tunnels,
customers are increasingly asking for SA transfer between master and backup
so that backup can take over tunnel when master fails (To avoid new tunnel
establishment).
There is a problem when anti-replay is enabled on SAs, which is MUST in
most of the cases. Transferring this change of sequence number
information between master and backup device,might have performance
implications and some times not practical.
Solution:
Today, we have proprietary mechanism to solve this problem, but
it works between same kind of implementations. We are trying to
see if there is any inter-operable solution for this problem. We feel that
backup device can send notification message (when tunnels in backup
device get activated) indicating to the peer that it can accept the
packets with some specific sequence number. Basically, synchronizing
the sequence numbers in the tunnel.
What do others think of this solution: Having SYNCH-SEQUENCE
notification message. We can force that this has to be protected message.
Also, we can have sequence number information for detecting replaying
of this notification message.
Do you see any problem with this approach? Or Is there any inter-operable
solution already defined?
Thank you for you time.
Suren
Intoto Inc.
3160, De La Cruz Blvd #100
Santa Clara, CA
www.intotoinc.com
--
signature
The views presented in this mail are completely mine. The company is not
responsible for whatsoever.
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335
1214 / 1175 / 1184
ROC home page