So this is the third part of our little series on securing IPv6 in enterprise environments. In the first part we tried to develop an understanding of threats in IPv4 networks as a kind-of baseline while analyzing the main differences induced by IPv6 and in the second part we laid out protection strategies on the infrastructure level, focusing on network isolation on the routing layer. Today I’ll dive into discussing IPv6-specific filtering of network traffic.
Let’s start with some
Preliminary Notes on the Performance Impact of Filtering and Logging
Before deciding on the exact filtering rules to be applied at individual network intersection points some aspects potentially impacting the performance of devices involved have to be considered. From a somewhat simplified angle (and looking mainly at Cisco space) on high-end enterprise (or service provider) edge platforms, such as Cisco ASR 1K routers, usually a route processor (RP) performs certain tasks in software whereas other elements (like the Embedded Service Processor [ESP] on ASR 1K platforms or the Policy Feature Card [PFC] on Catalyst 6500 platforms) perform a number of different tasks in hardware. From an operations perspective it is usually desirable to keep the number of software based tasks small in order to avoid performance overload or bottlenecks (given those tasks are considerably slower than hardware based tasks).
In general ACLs are processed in hardware (see for example this doc for Cat 6500) but there are some exceptions to keep in mind (for most platforms):
- The generation of log messages resulting from ACLs is done by the RP (=> in software).
- The generation of ICMPv6 Type 1 (“Destination Unreachable”) Code 1 (“Communication with destination administratively prohibited”) resulting from “deny” statements in ACLs is performed in software.
- Certain types of ACLs (e.g. ACLs with [layer 4] protocol numbers/next header values, like “deny 0 any any”. I’ll get back to the usefulness [or not] of such ACLs at a later point) might get processed in software on some platforms. For example on ASR 1K platforms usually ACLs are implemented in TCAM memory, but for this purpose individual entries have to be compressed to 320 bits which only works (according to a conversation with Cisco TAC from a customer environment) as long as the following fields are involved (else the ACLs would be programmed in – slower – DRAM memory):
“- IPV6 src address
– IPV6 dest address
– protocol field
ipv6, icmp, igmp, tcp, udp, ipinip, ipv6inip, gre, nigrp, ospf, nos, pim, pcp, sctp, hbh
– (tos, dscp) or TCP flags (not both in the same ACL)
– l4 src & dest ports & port ranges (TCP, UDP src & dst ports)
– ipv6 icmp header types (like pkt too big, echo req etc.,)
– ipv6 RH presence
– ipv6 DH presence
– fragments.”
To minimize the performance impact of these tasks two approaches are possible:
- Avoid the respective operation at all, e.g. by not logging any denied packets or by disabling the generation of ICMPv6 Type 1 messages by means of the command “no ipv6 unreachables”.
- Limit the rate the respective operation is either handed over to the RP or is performed as a whole.
Hence most often something along the lines of the following approach is considered reasonable and can be observed in networks we work in:
- Logging of denied packets is not performed at all at perimeter/edge devices, but instead NetFlow (or the mere inspection of ACL counters) is used to detect anomalies or attacks.
- While the generation of ICMPv6 Type 1 Code 1 is not disabled as a whole, the number of respective packets (which could be generated) gets rate-limited.
- ACLs which involve protocol numbers/next-header values not covered by keywords (like “deny $NUMBER any any”) are avoided. Here it should be noted that such ACLs are not supposed to be used for IPv6 extension headers anyway, as presumably the extension header chain is only parsed when the respective keywords (like “dest-option”) are used. At some point IPv6 ACL Chaining (introduced since IOS XE 3.11S on ASRs) might come in handy, but we’ve not yet seen this in the wild.
Given the implementation details depend on the individual platforms in use and actually vary between different vendors, careful consideration must be applied when choosing a strategy and we strongly recommend to discuss the specific (planned) implementation with technical engineers of the respective vendors before deploying it.
That said, now let’s focus on
Filtering ICMPv6
For the seamless operation of an IPv6 network, on network intersection points (as opposed to traffic on the local-link where additionally ICMPv6 types 133–137 and 130-132 + 143 for MLD will have to be allowed) only the following types of ICMPv6 Packets are needed:
- Type 1 Destination Unreachable
- Type 2 Packet Too Big
- Type 3 Time Exceeded
- Type 4 Parameter Problem
- Type 128 Echo Request
- Type 129 Echo Reply
Those should never be filtered on network on transit. Especially ICMPv6 Type 2 (Packet Too Big) must never be filtered, because this will result in inefficient/unstable network operations. Furthermore it should be kept in mind that even in transit/uplink networks most often NS/NA messages have to be exchanged with neighbors on the local-link which is why these have to be permitted, too (on Cisco devices usually respective rules are added implicitly [at the end of an ACL] but will not be reached once an explicit “deny” statement appears there).
A sample ACL implementing the above approach for Cisco devices looks like this:
permit icmp any any unreachable
permit icmp any any packet-too-big
permit icmp any any hop-limit
permit icmp any any parameter-problem
permit icmp any any echo-request
permit icmp any any echo-reply
permit icmp any any nd-ns
permit icmp any any nd-na
deny icmp any any log-input
It should be noted that, with regard to ICMPv6 Type 3 (“Time Exceeded”), the third entry only permits Code 0 (“hop limit exceeded in transit”), but not Code 1 (“fragment reassembly time exceeded”). We don’t see a need for the latter and RFC 4890 also somewhat suggests this approach. Furthermore it must be carefully considered if logging of all other (denied) ICMPv6 packets is desirable from a (security) operations perspective, see also our earlier discussion.
Thank you for reading so far ;-); in the next part of the series I’ll discuss filtering of IPv6 extension headers and/or fragmented packets and filtering of bogus/martian addresses. At this point I’d like to thank Eric Vyncke for some very helpful feedback and comments on the above, and I’m happy he already confirmed to be a speaker at next year’s IPv6 Security Summit.
Everybody have a great week
Enno