Possibly a small glitch with logging. Need some confirmation, please. (IPv6)

I appreciate support for IPv6/ICMPv6 is still incomplete in the current version (no support for ICMv6 Types and Codes) however, I’ve been playing around with the best ways to cater for the protocols needs, come the day it’s fully supported.

As you probably realise, the need for ICMPv6 when deploying IPv6 is significant, basically, unless ICMPv6 is allowed to communicate quire freely, things will break. This leads us to a small problem with CIS. Before I get to that, consider for a moment how ICMPv6 is controlled by the firewall in Windows 7.

Essentially, ICMPv6 isn’t tied to a specific service or application. The rules basically allow the protocol to be used by any application/service that needs it and this is quite reasonable, as any application/service can use the protocol for a variety of reasons. However, there also needs to be some control. This is from rfc-4890:

When a network supports IPv6 [RFC2460], the Internet Control Message Protocol version 6 (ICMPv6) [RFC4443] plays a fundamental role including being an essential component in establishing and maintaining communications both at the interface level and for sessions to remote nodes. This means that overly aggressive filtering of ICMPv6 by firewalls may have a detrimental effect on the establishment and maintenance of IPv6 communications. On the other hand, allowing indiscriminate passage of all ICMPv6 messages can be a major security risk. This document recommends a set of rules that seek to balance effective IPv6 communication against the needs of site security.

So, assuming we wanted to simulate this in CIS, we would need an application rule that would allow ICMPv6, for arguments sake, OUT, so that the rule could be used by all applications and services. This would obviate the need to apply an identical rule to each process and application.

Unfortunately, this approach doesn’t really give us a great deal of control, unless CIS, in a future release, includes support for ICMPv6 Types and Codes.

Also, this approach wouldn’t work if implemented as a Global rule, as each process/application would still require a rule that allows them to initiate the message in the first place.

To Wit: Create a rule to place at the top of Application Rules - For the All Applications group:

Action - Allow and Log
Protocol - IP (I do hope this changes to ICMPv6)
Direction - OUT
Source Address - ANY
Destination Address - ANY
IP Details - ICMPv6 (Hopefully this will change to Type and Code)

Having created and applied our rule, we monitor the logs for ICMPv6 traffic… Alas, there is none! But wait, when we crank-up Wireshark and monitor for ICMPv6 traffic, we see quite a lot. So what’s going on. Well it appears the rule is working correctly, because if I disable it, I immediately get a request from a service or application for NS, NA, RS, MLD etc, but the events are not being captured in the log, even though logging is enabled.

If anyone can confirm this behaviour I’ll post a bug report, assuming that’s what it actually is…

Thank you :slight_smile:

Edit: As an addendum, the essence of rfc-4890 suggests the following:

Traffic That Must Not Be Dropped:
Types 1,2,3,4,128,129,130,131,132,143,148,149,151,152,153,133,134,135,136,141,142

Traffic That Normally Should Not Be Dropped:
Types Type 3 - Code 1, Type 4 - Code 0

Traffic That Will Be Dropped Anyway – No Special Attention Needed:
Types 138,144,145,146,147

Traffic for Which a Policy Should Be Defined:
Types 137,139,140,5-99,102,126