Implementing dynamic membership in a secure multicast protocol Ilana Sarfati and Orna Dutech Winter 2005 Supervisor : Gal Badishi הטכניון – מכון טכנולוגי לישראל הפקולטה להנדסת חשמל המעבדה לתוכנה

Summary  Introduction  Project Presentation  The Join Mechanism  The Leave Mechanism  The Ping Feature  Experiments and Results

Introduction (1) In a multicast protocol, several processes form a multicast group. In a multicast protocol, several processes form a multicast group. Each process in the group exchanges messages with the other group members (through pull and push operations). Each process in the group exchanges messages with the other group members (through pull and push operations). The implementation is secure : The implementation is secure :  every message is digitally signed by its creator using its private key.  to validate other members’ messages, each group member must hold the other members’ public key.

Introduction (2) The implementation is static: The implementation is static: It is based on the assumption that every member knows every other member and no host can be added or removed from the group in running time.

Project Presentation Implementation of a dynamic membership protocol The system should permit the joining and leaving of members in running time. The challenge was to permit a fluent communication between the newly joined members and existing ones, and conversely to inform every member about the leaving of one of them. The solution had to be scalable and preserve the safety of the system (against DoS attacks…).

The join mechanism

The join mechanism (1) When a new member joins the group :  its certificate (containing its public key, its ip address, its port…) must be propagated among the other processes.  it must receive the certificates of the already connected processes. A join request is the message sent by the new host to some members to indicate them that it wants to join. It contains the new host certificate.  It is the only non signed message in the system.

The join mechanism (2) The joining host has a partial (little) view of the system which is composed of a fixed subset of (hopefully) connected members. The joining host has a partial (little) view of the system which is composed of a fixed subset of (hopefully) connected members. Its Joiner thread sends to all of them a join request. It will terminate as soon as a request is answered by a member. If no one is answered after a while, other requests will be sent. This process eventually ends (c.f. the ping feature). Its Joiner thread sends to all of them a join request. It will terminate as soon as a request is answered by a member. If no one is answered after a while, other requests will be sent. This process eventually ends (c.f. the ping feature). One JoinWaiter thread is created by the Joiner thread for each join request. Its role is to wait for an answer of a particular member. If it receives an answer, the host becomes an official member. One JoinWaiter thread is created by the Joiner thread for each join request. Its role is to wait for an answer of a particular member. If it receives an answer, the host becomes an official member.

The join mechanism (3) Each member runs a JoinReceiver thread which is in charge of receiving the join requests of new hosts. Each member runs a JoinReceiver thread which is in charge of receiving the join requests of new hosts. When a join request is received, it adds the new host certificate in its database and sends the certificates of all the hosts it holds in its database to the corresponding JoinWaiter thread of the new host. When a join request is received, it adds the new host certificate in its database and sends the certificates of all the hosts it holds in its database to the corresponding JoinWaiter thread of the new host. The JoinWaiter thread then inserts those certificates into the new host database and terminates. The JoinWaiter thread then inserts those certificates into the new host database and terminates. The new host is now able to validate signed message of members in the group. The new host is now able to validate signed message of members in the group.

Propagation of a join message  Apart of adding the new certificate to its database, the JoinReceiver thread also adds the join request in the message database so that it will be propagated as a normal message using push and pull operations.  Every host that receives a join request in push / pull operations updates its database with the new certificate. By this mean, the new host certificate is propagated among all members of the group. The new host can generate messages and all the members will be able to validate them. By this mean, the new host certificate is propagated among all members of the group. The new host can generate messages and all the members will be able to validate them.

Class diagram for the join mechanism

Sequence diagram for the join mechanism

The leave mechanism

The leave mechanism (1) When a user leaves the system, its public key should be deleted from the other users' database. When a user leaves the system, its public key should be deleted from the other users' database.  The goal is to ensure that every host has a view of active members so that it will not send messages to hosts who have left. A leave request is the message sent by a host to a member to indicate that it wants to leave. It is an empty message which is identified by its type.

The leave mechanism (2) The leaving host creates a new thread called Leaver. The leaving host creates a new thread called Leaver. This thread sends to a view of members a leave request. It will terminate as soon as a request is answered by a member. If no one is answered after a while, other requests will be sent (to a new view). This process eventually ends (c.f. the ping feature). This thread sends to a view of members a leave request. It will terminate as soon as a request is answered by a member. If no one is answered after a while, other requests will be sent (to a new view). This process eventually ends (c.f. the ping feature). One LeaveWaiter thread is created by the Leaver thread for each leave request. Its role is to wait for an ack from a particular member. One LeaveWaiter thread is created by the Leaver thread for each leave request. Its role is to wait for an ack from a particular member.

The leave mechanism (3) Each member runs a LeaveReceiver thread which is in charge of receiving the leave request of other hosts. Each member runs a LeaveReceiver thread which is in charge of receiving the leave request of other hosts. When a leave request is received, it removes the certificate of the host sending the request from its database and sends an ack to the corresponding LeaveWaiter thread. When a leave request is received, it removes the certificate of the host sending the request from its database and sends an ack to the corresponding LeaveWaiter thread. The Leaver thread then terminates. The Leaver thread then terminates. The leaving host can now quit the system. The leaving host can now quit the system.

Propagation of a leave message  Apart from removing the certificate of the leaving host from its database, the LeaveReceiver thread also adds the leave request in the message database so that it will be propagated as a normal message using push and pull operations.  Every host that receives a leave request in push / pull operations updates its database by removing the certificate of the leaving host. By this mean, all members will be informed that a host has left the group, and will have their database updated. By this mean, all members will be informed that a host has left the group, and will have their database updated.

Class diagram for the leave mechanism

Sequence diagram for the leave mechanism

The ping feature

The ping feature : Motivation  Problem: If a host cannot answer anymore to requests (maybe because it failed), the other members should know about it so that they’ll not try to communicate with it anymore. Solution : Solution : If host B doesn’t answer to the requests of member A during a long time, it has to be removed from A’s database.

The ping feature parameters A host B is suspect to A if it has not answered at least one of A’s requests. A host B is suspect to A if it has not answered at least one of A’s requests. If host B doesn’t answer a maximal number (NPingBound) of successive requests from A, it is removed from A’s database. If host B doesn’t answer a maximal number (NPingBound) of successive requests from A, it is removed from A’s database. If it answers to one of A’s requests, it is not a suspect member anymore. If it answers to one of A’s requests, it is not a suspect member anymore. When A selects a view for its next request, it includes a certain percentage (PPingView) of suspect members. When A selects a view for its next request, it includes a certain percentage (PPingView) of suspect members.

The ping feature implementation There is no specific ping message. Instead, every member keeps a list of the suspect hosts and a counter that counts the number of successive unanswered requests for each host. There is no specific ping message. Instead, every member keeps a list of the suspect hosts and a counter that counts the number of successive unanswered requests for each host. The regular protocols of sending requests and messages between members are used to update this list: The regular protocols of sending requests and messages between members are used to update this list:  The threads JoinWaiter, LeaveWaiter, PullWaiter, PushWaiter, PullReceiver and PushReceiver are in charge of updating this list.  They can increment the counter, add a new host, remove a host if it has answered a request, or remove a host from the database when NPingBound was reached.

Experiments and results

Experiments and Results (1) I. Joining mechanism and propagation of join requests The experiment consists of one host running alone. Nine other hosts join one by one by sending a join request to the host that has just joined the group (approximately there is a join all 2 seconds).

Experiments and Results (2) II. Leaving mechanism and propagation of leave requests The experiment consists of 10 hosts running. They know each other. No one generate messages. The hosts 6, 7, 8, 9, and 10 leave the group after 75 seconds, by sending leave requests.

Experiments and Results (3) III. Ping feature The experiment consists of 10 hosts running. They know each other. No one generate messages. The even hosts fail (they do not send leave requests before leaving) after 50 sec.