Subject: [IPsec] Issue #177

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Apr 2010 11:49:07 +0300

Hi all.

As the previous discussion on this topic showed, the WG would like a more thorough taxonomy in section 2 of the HA/LS draft. Here's what I have come up with so far. Please send comments to the list.

2.  Terminology

   "Single Gateway" is an implementation of IKE and IPsec enforcing a
   certain policy, as described in [RFC4301].

   "Cluster" is a set of two or more gateways, implementing the same
   security policy, and protecting the same domain.  Clusters exist to
   provide both high availability through redundancy, and scalability
   through load sharing.

   "Member" is one gateway in a cluster.

   "High Availability" is a condition of a system, not a configuration
   type.  A system is said to have high availability if its expected
   down time is low.  High availability can be achieved in various ways,
   one of which is clustering.  All the clusters described in this
   document achieve high availability.

   "Fault Tolerance" is a condition related to high availability, where
   a system maintains service availability, even when a specified set of
   fault conditions occur.  In clusters, we expect the system to
   maintain service availability, when one of the cluster members fails.

   "Completely Transparent Cluster" is a cluster where the occurence of
   a fault is never visible to the peers.

   "Partially Transparent Cluster" is a cluster where the occurence of a
   fault may be visible to the peers.

   "Hot Standby Cluster", or "HS Cluster" is a cluster where only one of
   the members is active at any one time.  This member is also referred
   to as the the "active", whereas the others are referred to as "stand-
   bys".  [VRRP] is one method of building such a cluster.

   "Load Sharing Cluster", or "LS Cluster" is a cluster where more than
   one of the members may be active at the same time.  The term "load
   balancing" is also common, but it implies that the load is actually
   balanced between the members, and we don't want to even imply that
   this is a requirement.

   "Failover" is the event where a one member takes over some load from
   some other member.  In a hot standby cluster, this hapens when a
   standby memeber becomes active due to a failure of the former active
   member, or because of an administrator command.  In a load sharing
   cluster this usually happens because of a failure of one of the
   members, but certain load-balancing technologies may allow a
   particular load (an SA) to move from one member to another to even
   out the load, even without any failures.

   "Tight Cluster" is a cluster where all the members share an IP
   address.  This could be accomplished using configured interfaces with
   specialized protocols or hardware, such as VRRP, or through the use
   of multicast addresses, but in any case, peers need only be
   configured with one IP address in the PAD.

   "Loose Cluster" is a cluster where each member has a different IP
   address.  Peers find the correct member using some method such as DNS
   queries or [REDIRECT].

   "Synch Channel" is a communications channel among the cluster
   members, used to transfer state information.  The synch channel may
   or may not be IP based, may or may not be encrypted, and may work
   over short or long distances.  The security and physical
   characteristics of this channel are out of scope for this document,
   but it is a requirement that its use be minimized for scalability.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 13 Apr 2010 13:17:07 +0300

Looks good. A few comments down below.

	Yaron

>    maintain service availability, when one of the cluster members fails.

one or more

>    bys".  [VRRP] is one method of building such a cluster.

[Please ignore if you're sick and tired of terminology discussions:] I
look at the term "hot standby" as contrasted with "warm/cold
standby" (see http://www.webopedia.com/TERM/H/hot_standby.html). This is
not what we mean here. Can we use "active-standby" instead?
>    out the load, even without any failures.

The parenthetical "an SA" implies that SAs are never shared between
members. I suggest that the initial definition of "cluster" mention
whether we expect IKE and IPsec SAs to be shared between members.

>    address.  Peers find the correct member using some method such as DNS

Upon failure, members' IP addresses are reallocated to other members.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Apr 2010 14:52:46 +0300

>>   maintain service availability, when one of the cluster members fails.

Agreed. Fixed.

> not what we mean here. Can we use "active-standby" instead?

I can live with that. What do other think?

> whether we expect IKE and IPsec SAs to be shared between members.

That is not part of terminology. It's mentioned in section 3. How about I change the parenthetical remark to "such as all the flows associated with a particular SA" ?

> Upon failure, members' IP addresses are reallocated to other members.

They are?

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 13 Apr 2010 16:42:57 +0300

[snip]
> That is not part of terminology. It's mentioned in section 3. How about I change the parenthetical remark to "such as all the flows associated with a particular SA" ?

OK, with a nit: "such as all the flows associated with a particular IKE
SA".

> > Upon failure, members' IP addresses are reallocated to other members.
OK, not necessarily (but it's one reasonable way to reduce the fail-over
time): Upon failure, members' IP addresses may be reallocated to other
members.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Apr 2010 17:20:16 +0300

> OK, with a nit: "such as all the flows associated with a particular IKE

I was thinking of an IPsec SA.

But it's just an example (or a "such as") anyway.