[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPSEC in High Availability scenarios



Suren,

I understand, your solution is only for outbound 
sequence number. I see one problem with this 
solution. IPSec Packet may be processed 
before IKE INFO packet though it may arrive before
IPSec packet. You may have few dropped packets. 
BTW what will be the sequnce number on these IPSec 
packets. Are you planning to reset it or have 
regular updates and use last known value?

Another possible solution is to update the backup
at regular intervals with the current state of
the window. After failover, just advance the outgoing
sequnce number (the value depends on rate of 
traffic and update interval). In this case, some 
sequence numbers may not be used. I think lot of
people do this. 

Regarding, FIPS certification for transferring
keying material between HA pairs, I think it is
OK for Level 2, if the key is encrypted. We are 
planning to use IKE SA between HA pair to 
secure HA traffic and we think it is good 
enough for FIPS 140-2 Level 2.

-Rajesh Mohan


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of suren
> Sent: Tuesday, May 06, 2003 6:57 AM
> To: Stephen Kent; ipsec@lists.tislabs.com
> Subject: Re: IPSEC in High Availability scenarios
> 
> 
> Hi Stephen,
>      Thank you for the response. You stated that the backup SA
>      can be created to avoid the transferring SA key material and
>      thereby avoiding transfer sequence number information.
>      This works fine, if backup device has IP address different
>      from the master device. Also, it requires peer to have
>      knowledge of backup IP address for a given tunnel.
> 
>      In the case, which I was referring in my last email, 
> backup device
>      inherits the IP address of master device, when master fails. We 
> understand
>      that transferring the keying material is not a good thing. But...
> 
>      Notification message:
>      SYNCH_SEQUENCE notification message can be sent
>      on IKE SA with Protocol ID as ESP or AH and notification data
>      containing sequence number of this notification message and
>      inbound SA's SPI on the peer.
> 
> We have following options:
>     1. Mandate that backup device has new IP address.
>         I am not sure it flies as customers use backup device 
> for state 
> transfer
>         of other applications such as NAT/Firewall/QoS etc.. 
> This requires
>         that backup device inherits the IP address.
>         ==> It means that backup SA may not be possible in this case.
>    2. Have some sort of detection mechanism, beyond Peer detection ie
>        Dead Tunnel detection ( as mentioned by Ravi ) so that 
> Peer eventually
>        knows that tunnel is no longer exist and create new 
> Tunnel and this
>        time it goes to backup device. But in this case, there 
> may not be
>        any communication for the period Dead Peer Tunnel detection and
>        time it takes to establish the tunnel.
>    3. SA Transfer:  It does not seem to be good thing... By the way,
>        our proprietary method is not patented.
>    4. Any new proposal from the members in this list?
> 
> Thanks
> Suren
> 
> 
> 
> 
> At 06:24 PM 5/5/2003 -0400, Stephen Kent wrote:
> >At 3:31 PM -0700 5/2/03, 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.
> >
> >Perhaps this is not a good model. The backup SG, in order to 
> be able to 
> >take over the SAs from the primary SG must have access to 
> all the keys in 
> >use, and the movement of keys between the two may create security 
> >assurance problems.  For example, are any of the 
> implementations that 
> >support this approach evaluated under FIPS 140-1/2 at level 3 or 4?
> >
> >An alternative would be to have backup SAs created at the 
> same time as the 
> >primary SAs, but homed to the backup SG, at its own address, 
> and then move 
> >the traffic to the existing, backup SAs, which would avoid 
> the sequence 
> >number problem you noted.
> >
> >>
> >>   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?
> >
> >I'm not saying this can't be done securely, but you have no provided 
> >sufficient detail to know. For example, is this new message 
> sent over the 
> >IKE SA or over the subscriber SA?  If via IKE, then there 
> may be problems 
> >matching the SYNCH-SEQUENCE to the data path sequence 
> numbers. If via the 
> >subscriber SA, then how is this message accepted out of 
> order? Also, is 
> >this proprietary mechanism patented?
> >
> >Steve
> 
***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************