Roadmap
Even if NDPMon is stable, performs the same monitoring tasks as ArpWatch, and includes the detection of a few attacks against the Neighbor Discovery Protocol, it is in an early stage of its development. In this page, we present the improvements we are planning to add in the tool. Of course, we haven't thougth about all the possibilities. If you notice something we are missing, please let us know, via the mailing lists, via the forums or directly by mail.
Packaging
NDPMon is already available in FreeBSD ports. Debian and RPM (Fedora, Red Hat, Mandriva...) are available in the Download section. The next step will be to integrate the tool in the official repositories... If you want to help us to do so, don't hesitate to contact us: frederic.beck@loria.fr.
Portability
NDPMon is known to work under Linux, FreeBSD, NetBSD, OpenBSD and Mac OS X. Sole a small problem encountered while testing the mail functionnality under OpenBSD subsists. We are now considering the porting under Windows XP SP2 and Vista.
Attack Detection
NDPMon detects attacks and misbehaviors of the Neighbor Discovery Protocol, as defined in RFC 3756. Nevertheless, other attacks then the ones clearly identified in this RFC can be performed.
For example, a replay attack can be performed by resending a RA received, keeping the same Ethernet and IPv6 addresses, but reverting the Autoconfiguration flag. Thus, if the Address Autconfiguration was enabled and is now disabled, the hosts will try to reach DHCPv6 servers and won't perform the autoconfiguration, which could block their addressing and prevent them from communicating over the WEB. Another example could be the Path MTU. If is is set to a very low value, as IPv6 does not use fragmentation, this could end in a situation were many packets are sent instead of only a few, and could heavily harm the performances of the network and/or the hosts.
Better said, all the options in the Router Advertisement should be checked, as most of them can be used to perform an attack against the network.
WEB Interface and Statistics
The neighbors discovered by the tool are stored in an XMl database. This file can quickly become unreadable if many hosts are monitored. Thus, we are planning to develop a WEB interface to display these informations. This interface will allow to use filters on the list, to select only a subset of the hosts depending on their specificities (last activity, MAC vendor...). A first version has been released to display these informations and a few statistics. We will continue to add features to this interface.
This WEB interface would be also a good place to put a statistic module for the tool itself, but also for Neighbor Discovery Protocol (NDP) activities. This module would give information such as the evolution of the number of monitored hosts, the number of alerts sent, of attacks detected... It can lead also to the definition of new alerts. By monitoring NDP activities, like the Router Advertisements frequency for example, we can detect replay attacks.
Learning Phase
The learning phase is one of the tool features, but is also a delicate point. Actually, this phase is meant to discover the routing infrastructure on the link and the neighbors. But as its duration is depending from the hosts activity and the RA frequency, its duration is unpredictible. Moreover, during this phase, all the information seen on the link is trusted by the daemon as legitimate routing information. The idea is to send solicitations to trigger the sending of advertisements (RA and NA) to shorten this learning phase.
Code Cleaning
The code has been already cleaned, but there is always something to do. We want to check all possible buffer overflow and other known problems with could lead to troubles. Moreover, we would like to add more error handling, for return values from "popen" like in the function "do_exec_pipe_program" and from "fputs" in the function "mail" for example. Finally, we would like to apply the advices from the article "http://en.wikipedia.org/wiki/Const-correctness" to more places in the sources, for example by adding the key word "const" to the type specifiers for parameters. -
Distributed Version
If NDPMon is deployed on a big network with many subnet, and no monitor port on the main switch gives acces to all subnets, several instances of NDPMon should be deployed, which means several neighbor databases. In another way, the same problem occurs if several instances are deployed on the same subnet, it will result in having several databases once again. By developing a distributed version of NDPMon, we would solve this problem, and ease the display of the collected data on the WEB interface.