This paper proposes a secure multicast routing protocol that deals with several Byzantine attacks, including black hole, wormhole, and flood rushing.

Curtmola and Nita-Rotaru exploit hash chain mechanisms “to prevent tree nodes from claiming to be at a smaller hop distance from the group leader than they actually are.” In addition, a route discovery algorithm, a multicast route activation algorithm, and a selective data forwarding mitigation strategy are proposed. Eventually, the simulation indicates the Byzantine-resillient secure multicast routing (BSMR) protocol that outperforms A-MAODV on attack resilience for black hole attacks, wormhole attacks, and protocol overhead.

This paper adopts several well-known wireless security schemes to secure multicast routing packets. For example, the authors apply TESLA to tackle the source authenticity of the received data, public key infrastructure (PKI) for certificate management on authorizing mobile nodes, and pairwise shared key scheme for tree neighbors.

The paper has, however, a few major defects.

First, in the authentication framework in Section 5.2, the paper never mentions the method by which mobile nodes obtain certificates or public/private keys from the system. If malicious nodes or former nodes with that information can officially join the multicast tree, they can perform Byzantine attacks. In wireless networks, in particular, mobile nodes are always changing. The authors presume that the group leader takes control of the certificate management and key agreement, and any authentication operations are performed before mobile nodes join the multicast tree; otherwise, several relevant security schemes applied in this paper lack a complete security framework and, thus, the readers only perceive portions of the security perspective.

Second, in hop count authentication, the paper adopts a hash chain function to verify the actual hop distance. The equation h^max-d = h^max(S), where h^max-d is the hop count authenticator, seems unreasonable. If so, S is a random number and the authenticator is a node’s ID. After performing the hash function several times, it is impossible for the equation to obtain the same result. If not, the paper should describe the detailed meaning of the hop count authenticator.

The third defect is in Sections 5.3, 5.4, and 5.5: if a malicious node periodically broadcasts a tree token, how does the system identify the actual token using f (tree token)? The malicious behavior will confuse the other members, since the signature and the private key encryption of the group leader don’t protect the token. Additionally, during the propagation of multicast activation (MACT) messages, in the case without a certificate authority (CA) server, tree neighbors cannot obtain the public key to establish a pairwise shared key.

Finally, the paper considers key agreement and certificate management and proposes a practical security multicast routing protocol. Too many security schemes are adopted and involved; the paper lacks a detailed presentation of how they work cooperatively.

In the future, the authors should try to emphasize the multicast routing aspect based on a CA server (group leader) with proper key agreement and certificate management, assuming they are already in place. They should focus on dealing with insider threats and malicious attacks. The paper should be resubmitted at a later stage of research.