malicious nodes can mount two kinds of attacks against FUSE: the dropped notification attack and the unnecessary notification attack. In the overlay topology used by our FUSE implementa- tion, these attacks can be mounted by malicious group members or delegates. The SV tree application han- dles the dropped notification attack above the FUSE layer by using redundant content-distribution trees. It handles the unnecessary notification attack by re-creating FUSE groups with different sets of members.
The first alternative topology we consider is per-group spanning trees without an overlay. By routing liveness checking traffic directly between members, this topology eliminates the threat of delegates launching attacks on FUSE. The scalability tradeoff for this additional secu- rity is that the overhead of liveness checking traffic may be additive in the number of FUSE groups – the opportu- nities to share liveness checking traffic will depend on the degree of overlap in FUSE group membership.
The second alternative topology we consider is per- group all-to-all pinging (again, without an overlay). This improves security even further; all-to-all pinging is robust to dropped notification attacks from members because no member relies on any other node to forward failure notifi- cations. However, this topology requires n2 messages for a group of size n – significantly more than the per-group spanning tree topology. An added benefit of the all-to-all topology is that worst-case failure notification latency is reduced to twice the pinging interval.
The final topology we consider is using a central server to ping all nodes. This may be an appropriate topology for using FUSE within a data center environment. From a se- curity standpoint, this server represents a single point of trust, which may be easier to secure than a larger collec- tion of machines. If the server is compromised, attacks can be launched against any FUSE group in the system. If not, the security guarantees are the same as in the all- to-all pinging topology. For settings than span multiple administrative domains, the use of a single trusted server may not be appropriate. The scalability of this topology is limited: all FUSE traffic passes through the server, which can be a bottleneck for a large number of FUSE partici- pants. However, the load on each group member is min- imal: each group member only pings the central server during each ping interval.