Nowadays, the Internet is vulnerable to denial of service attacks such as flooding or spamming. And the development of multicast makes this attack even simpler and more powerful. A malicious host can just send any junk to the multicast group address. It can cause a big traffic load and all the end-hosts in the multicast group will be annoyed. One possible solution is that we can use sender authorization. So when the packet is forwarded from the network layer to the application layer, the application layer will do the authorization of the sender. If it's an unauthorized sender, the application will automatically drop the packet. In this case, the end-user won't notice the garbage data, but the computation power of the end-host will be wasted as well as the network resource. Also the billing based on network usage will be difficult since client won't like to pay for the garbage. So it will be more and more urgent to find a solution to prevent spamming.
Since we can't prevent malicious hosts from sending garbage packets, the spamming problem can't be solved end-to-end. The only way to prevent this is that the Internet routers can drop unauthorized packets. The current routing process forwards a multicast packet based on its routing table for this multicast group. This is called passive forwarding. Instead, we need intelligent routers to be able to check the validity of the packets. Via research on IPv6 and active networks, we propose a solution using the IP authentication header and the active network.
IPv6 includes security in its design goal. One new mechanism is the IP Authentication Header [Atk95]. End-hosts can either use a symmetric or asymmetric authentication algorithm to sign the entire IP packet except for the fields or the options that will be changed in transition (e.g. ``hop count''). A separate IP Authentication key management component is used to create and maintain a logical table containing the security parameters for each current security association. Upon reading the security parameters from the logical table, a host can do the authentication on the datagram containing an Authentication Header. The receiver can use the Authentication Header to authenticate the sender of the packet.
In active networks [WGT98], intermediate routers are intelligent. Instead of doing passive forwarding, routers can do computation and processing according to the corresponding packet protocol. Though the security concern and the processing cost of the packet throw doubts on the development of active networks, the rich functionality which can be provided is very attractive. In our approach, the routers can do the IP Header Authentication and drop the unauthenticated packets.
Using IPv6 and active networks, we propose a solution for preventing spamming in secure multicast. The solution differs a little bit from the architecture we gave earlier in this paper.
For architecture 1, since everybody can send and the receiver will decide who it wants to listen to by its own access control list, there's no need to prevent spamming inside the network.
For architecture 2, all the group members share the same group session key and everybody in the group can send. We want to prevent from malicious people who are outside of the group to flood the multicast group. So in addition to the group session key, the server also generates a group authentication key which is used in generating the IP Authentication Header and distribute it to every group member when it joins the group. And several changes need to be done for the protocol. When a group member wants to send a message, after the normal encryption using the group session key, the IP layer needs to add the IP Authentication Header using the group authentication key. On the receiver side, the IP layer will first check the IP Authentication Header before it hands the packet to upper layers. The server will also need to register an entry in the IP Authentication Key Management's logical table that this group authentication key is associated with this multicast group address. When the group key is updated, the group authentication key also needs to be updated. The server will send out the new group authentication key together with the new group session key using the same method as described before which almost requires no extra cost. But the server also needs to update the entry in the IP Authentication Key Management's logical table. The routers will do IP header authentication based on the group authentication key. So if people outside of the group send packets using this multicast group address as destination address and didn't do the IP authentication, the router will drop the packet when it sees it. Therefore, we can prevent spamming to this multicast group.
For architecture 3, only authorized people in the multicast group are allowed to send. We gave two schemes in architecture 3.
One scheme is all the authorized senders share the same sending key (public key). To prevent from spamming, the server also needs to generate a group sender authentication key which is used in the IP authentication as same as we described in the previous paragraph. When an end-host joins the group and has the permit to send, it will get the group sender authentication key as well as the group sending key. The sender, receiver, router and server will do the same thing as described in the previous paragraph. And the group sender authentication key update is similar to the sending key update. The only difference to the solution for architecture 2 is that the server registers the group sender authentication key to the IP Authentication Key Management.
The second scheme is that all the senders will send their packets first to the server and then the server does authentication and then multicasts the packet. In this case, only the server needs to have the IP authentication key. So the server just generates an IP authentication key for itself and register it to the IP Authentication Key Management. And the server usually doesn't need to update this key in case that the session key gets updated. The other issues are similar to the ones we described before.
Since we have the active network to check the IP Authentication Header and drop garbage packets, we prevent spamming to the secure multicast group. The protocol for the server to register the entry in the IP Authentication Key Management is still an open issue since there's no specification for the IP Authentication Key Management. But once given the specification of the IP Authentication Key Management, the protocol for the server to register will be feasible.