As SLRP is a first generation protocol at the time of this writing, there are inevitably problems with it. As mentioned in Section 3, a slave node may be vulnerable to attack by having its original cookie intercepted. However, since the cookie never passes through the PLAN network proper but rather only along the administrative links to the master, such attacks cannot occur at the PLAN network layer. While this is certainly a concern for a physically deployed PLAN network, this security hole has been left open for the time being.
Secondly, there is no provision for preventing a malicious node from simply reporting that its neighbors are down and having them removed from the network (other than the case of the master). Such unwittingly disconnected nodes would then presumably find their neighbors not checking in, and report them, and so on. It is entirely possible that if the ``host down'' messages also contained the name of the reporting host (they currently do not), such incorrect disconnections could be either traced or avoided.
Finally, it is not very convenient to stop and restart a node, as the node must wait to be removed from the current network. One alternate solution would be to arrange for a node to report itself down before shutting down, thus allowing a graceful exit from the network.
Despite these problems, SLRP provides an interface which should allow others to easily add and remove PLAN nodes in an experimental network without requiring direct (human) central maintenance. It is hoped that this will encourage the growth of a fairly large wide-area network of participating research nodes.