IPv6-related Requirements for Security Devices

This is the sequel to the similar post on “IPv6-related Requirements for the Internet Uplink or MPLS Networks“. As mentioned there these requirements were created in the course of an RfP for network security services. The goal of this document was to provide a check list of IPv6-related requirements that security devices being part of the individual providers’ offerings have to fulfill in order to fully support the future IPv6 network. 

As sources of inspiration we used the RIPE-554 “Requirements for IPv6 in ICT Equipment” document and the (meanwhile expired) IETF draft on “Requirements for IPv6 Enterprise Firewalls“. Given, at least from our perspective, RIPE-554 is somewhat less specific/helpful in the area of security devices than when it comes to network devices, we’d be happy if the list we compiled could also serve as input for the “RIPE 554bis process” (see also discussion here).

Here’s the initial list we came up with:

• All security controls enabled/used for XY will support IPv6 to a full extent.
• In case the answer to question no.1 is “no”, there is exact documentation which features fully support IPv6 and which do not.
• Vendor is able to provide test reports of devices in dual-stack or IPv6-only settings.
• Full support of all device IPv6 capabilities for both native and tunneled IPv6 traffic.
• Devices in question fully support their respective specification as of the RIPE-554 requirements document.
• Performance (e.g. throughput) of devices processing IPv6 traffic meets or exceeds similar parameters for IPv4 traffic.
• Running devices in dual-stack mode does not have a negative impact on overall performance when compared with single-protocol processing mode.
• All management interfaces (vendor proprietary, SSH, SNMP etc.) fully support IPv6.
• All logging mechanisms (vendor proprietary, syslog etc.) fully support IPv6 for the protocol transport.
• All logging mechanisms (vendor proprietary, syslog etc.) fully support IPv6 as for the logging format/content (RFC 5952 notation, logging of IPv6 extension headers present in packets etc.).
• High-availability mechanisms (clustering, state synchronisation etc.) fully support IPv6.
• For devices performing traffic filtering: there must be a configuration option to block specific IPv6 extension header types.
• For devices performing traffic filtering: there must be a configuration option to block fragmented IPv6 traffic.
• For devices performing (stateless) traffic filtering: there must be a configuration option to enforce RFC 7112 like behavior (drop packets if upper-layer header not included in 1st fragment), similar to “undetermined-transport” keyword in Cisco ACLs. Alternatively do this by default (without configuration option).
• For devices performing traffic filtering: there must be configuration option to drop packets with IPv6 extension headers once order and number of headers violates RFC 2460 recommendation. Alternatively do this by default (without configuration option).
• For devices performing packet inspection which requires full packets (e.g. to check against signatures): there must be an option to limit overall number of IPv6 extension headers present in packets. [ed. like Snort does in the interim as discussed here]
• For devices performing packet inspection which requires full packets (e.g. to check against signatures): there must be an option to limit overall number of fragments of a given packet. Once this is exceeded/violated, generate appropriate alert.
• For stateful devices and proxies: ability to map received ICMPv6 Packet Too Big (PTB) messages to the respective sessions and forward to affected end systems appropriately.

Again, we’re happy to receive feedback/comments from our readers.

Please note further that the Troopers IPv6 Security Summit will include an update of our Black Hat talks on IDPS evasion with IPv6 extension headers and fragmentation (details here), so you might meet us there for a chat on the above requirements and any other IPv6 security topics.
Have a good one

Enno