IPv6 NPD (firewall and IDS/IPS) Testing Procedures and Issues

NPD testing presents issues not found with other parts of the USGv6 testing program. While protocol conformance and interoperability can be more or less exactly defined, determining sufficiency for security testing is more a matter of judgment. Here we address some of these judgment issues which have arisen in the NPD testing program.

1. IDS/IPS vulnerability selection criteria and schedule

Intrusion detection systems are required to have "a configurable capability to detect suspicious traffic based on known attack patterns ..." ( In order to define tests for this capability, we here list the criteria used in selecting the vulnerabilities whose "known attack patterns" the IDS must be capable of detecting.

To bound the scope of testing, and to make it more relevant to USG needs, we limit our list to attacks on vulnerabilities which are (a) relatively recent (within the last two years), (b) found in systems commonly deployed in government networks, (c) capable of being exploited over IPv6 networks, and (d) for which actual exploits are known to exist. Specifically, we select the following vulnerabilities from the National Vulnerability Database:

Disclaimer: Please note that the CPEs selected are merely intended to be representative of the types of hardware/software found in government networks. This is by no means an exhaustive list; presence on (or absence from) this list does not represent any sort of endorsement on the part of NIST.

To keep the list of vulnerabilities current, it is regenerated every six months, beginning May 1, 2010. After generation, it is then open for review and editing for a one month period, becoming valid for testing at the end of that period. The following are the vulnerability lists generated to date:
List generated Valid from Valid to
May 1, 2010 June 1, 2010 Jan 12, 2010
Dec 13, 2010 Jan 13, 2011 May 31, 2011

Note that these are lists of all vulnerabilities meeting the criteria above which are theoretically exploitable over an IPv6 network. However, for many of them, no known exploits may as yet exist. Only those with known attack vectors will be used for IDS/IPS testing.

2. Sophistication of known attack detection testing

In attempting to exploit a known vulnerability, an attacker may use any number of methods. In the Metasploit Framework, for example, most exploits offer a variety of "evasion" options and can attempt to send a variety of payloads. Realistic IDS/IPS testing needs to mimic this variety, and so the attack traffic generated by the testing lab must use a variety of exploitation techniques and payloads. With this, a real attack detection capability (and not some simple pattern-matching) by the IDS/IPS will be demonstrated.

Hence, some sophistication in the testing procedures is required. On the other hand, it is to be expected that testing will be automated to the extent possible. Typically, attack traffic is generated (using exploit tools and the like) once, recorded, and then replayed (with possible minor modifications) when testing each system. While a testing lab would of course strive to make the pre-recorded traffic look as much like a live attack as possible, it may happen in some instances that a sophisticated IDS/IPS could differentiate the replay of recorded traffic from an actual attack, and not react in the case of the former.

This is a special case of a type of concern about the validity of testing that seems more likely to arise in the context of testing NPDs, with the greater complexities involved, than in other areas. As with all such concerns, they will have to be resolved on a case-by-case basis between the testing lab and the vendor. Where an actual issue with the validity of a test exists, the testing lab may need to use another approach, such as a live exploit test against a vulnerable system, in place of the automated test. For efficiency of testing, it is to be hoped that few such cases will exist.

3. Malformed packet detection for IDS/IPS

In, the USGv6 profile requires that IDS/IPS systems be able to detect a variety of packets which are improper or malformed at the protocol level. While many current systems do have such a detection capability, others do not, under the assumption that some other device (such as a firewall) will have already screened out all such packets.

In simple network setups, where for example a single combined firewall/IPS sits between the protected network and the outside world, obviously a system with this capability is required. However, in more complex setups, where the IDS/IPS is only one of several systems in the border to the outside, such a capability may not be relevant. IDS/IPS systems intended for the latter environment often offer other desirable features, such as the ability to coordinate with other network protection and monitoring devices, which are not covered by the requirements in the USGv6 profile. Hence, in some environments, the latter may be preferred, even with the lack of malformed packet detection.

Given this disparity in potential deployment scenarios and needs, in future versions of the profile, malformed packet detection/prevention will be factored out as a separate configuration option, which may be applicable to either firewalls or IDS/IPS systems. A secure IPv6 deployment should have this capability present somewhere, but the possible locations can vary with the specifics of the deployment.

In the near term, since is not yet factored out as an option in the current profile, all IDS/IPS testing and vendor SDOCs coordinated with this version of the profile must of course report the presence or absence of this feature. But given that this will be made a separate configuration option in the future, this may be reported in a fashion essentially equivalent to that for the presence/absence of other configuration options - e.g., that the device passes all the requirements for IPS except, or that it passes all the requirements for IPS including Government agencies may then, in their procurements, decide whether the capability is needed in their environment.

While similar detailed reporting could theoretically be done on the presence or absence of other features, in practice this is unlikely to be useful; all the other requirements seem too integral to the nature of an IDS/IPS for their absence to be tolerable in any real deployment scenario.

4. Splitting of the "application firewall" category

The application firewall category in the USGv6 profile essentially exists as a placeholder to cover the functionality of an emerging class of devices. Current trends suggest that such devices - which operate at a higher level than ordinary firewalls, but which offer more sophisticated filtering capabilities for traffic at that level - will tend to be specialized for particular protocols/traffic types.

Reflecting this, we anticipate that future versions of the profile will split the current "application firewall" category into a set of configuration options - web gateway, mail gateway, and possibly others.

To return to the IPv6 software distribution main page:

Point Of Contact:

Last update: Mon Dec 13 2010.