Re: IPSEC in High Availability scenarios

[Ravi <ravivsn@roc.co.in>]

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 
>  
>

--


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