Cascaded Events Sample Clauses

Cascaded Events. Since network disruptions are random and unpredictable, it is natural to consider the possibility of so-called cascaded membership events. (In fact, cascaded events and their impact on group protocols are often considered in group communication literature, but, alas, not often enough in the security literature.) A cascaded event occurs, in its simplest form, when one membership change occurs while another is being handled. Event here means any of: join, leave, partition, merge or a combination thereof. For example, a partition can occur while a prior partition is being dealt with, resulting in a cascade of size two. In principle, cascaded events of arbitrary size can occur if the underlying network is highly volatile. As discussed before, STR protocol requires at most two rounds. One might wonder why robustness against cascaded failure is important for only a 2-round protocol. We give couple of examples that illustrate (potential) failure of the STR protocol. Suppose a network partition breaks a group into groups and . The sponsor needs to compute missing keys and bkeys. While computing these keys, another partition breaks into two other groups (containing ) and . Based on the partition protocol description, the members in group still wait for the message from to process the previous partition. Suppose a merge event happens whereby groups and to form a single group . The sponsors and in each group broadcast their tree information. In the next round, while a sponsor computes the missing bkeys, a member originally in group leaves the group. If the leaving member is the sponsor, the STR protocol cannot proceed for every other member is waiting for the message from this member. The protocols described above cannot cope with these situations. However, we can modify the protocol in Fig. 9 to handle such cascaded events. We claim that the STR protocol is self-stabilizing, i.e., robust against cascaded network events. This is quite rare as most multi-round cryptographic protocols are not geared towards handling of such events. In general, self-stabilization is a very desirable feature since lack thereof requires extensive and complicated protocol ”coating” to either 1) shield the protocol from cascaded events, or 2) ▇▇▇▇▇▇ it sufficiently to make the protocol robust with respect to cascaded events (essentially, by making it re-entrant). The high-level pseudocode for the self-stabilizing protocol is shown in Fig. 10. The changes from Fig. 9 are minimal (lines 15 – ...