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

Project Presentation (1) Implementation of a dynamic membership protocol  In a multicast protocol, several processes form a multicast group. Each process in the group exchanges messages with the other group members. In a secure implementation, where every message is digitally signed by its creator, each group member must hold public keys corresponding to the other members.  When a new member joins the group, its key must be propagated among the other processes, and the other processes must send their keys to the newly joined member. Conversely, when a user leaves the system, the corresponding public key should be deleted from the other users' databases.

Project Presentation (2) Implementation of a dynamic membership protocol  The project's goal is to design and implement an efficient dynamic membership protocol for such a scenario, in a hostile environment.  The project is developed in Java, as an extension to an existing system.

The join mechanism 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 leave mechanism 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 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.