Detections
Analytics

NET-IPV6-017 - IPv6 Routing Header is not blocked - 'permit type 2'

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

The network element must be configured to ensure the routing header extension type 0, 1, and 3-255 are rejected in an IPv6 enclave.

 The Routing header is used by an IPv6 source to specify a list of intermediate nodes that a packet has to traverse on the path to its destination. If the packet cannot take the path, it is returned to the source node in an ICMPv6 unreachable error message. This header supports a function very similar to the IPv4 packet Loose Source Routing. The routing header can be used maliciously to send a packet through a path where less robust security is in place, than through the presumably preferred path by routing protocols. Use of the routing extension header has few legitimate uses other than as implemented by Mobile IPv6. The Routing header is identified by a Next Header value of 43 and should be filtered by type using an ACL.

 The Type 0 Routing Header (RFC 5095) is dangerous because it allows attackers to spoof source addresses and get traffic in response, rather than to the real owner of the address. Secondly, a packet with an allowed destination address could be sent through a Firewall only to bounce to a different node once inside using the Routing Header functionality. If the Type 0 Routing Header must be used, it must be used in conjunction with either the IPsec AH or the IPsec Encapsulation Security Payload (ESP) headers. The Routing Header is identified by a Next Header value of 43 (0x2B) and can be filtered by type using an ACL similar to: deny ipv6 any routing-type 0 log.

 The Type 1 Routing Header is defined by an abandoned specification called 'Nimrod Routing'. Assuming that most implementations will not recognize the Type 1 Routing Header, it must be dropped. When IETF standards explicitly require nodes to gracefully rejected invalid or deprecated options, in the case of Routing Headers, however, under certain conditions the specification allows a node to 'ignore the Routing Header and proceed to the next header in the packet' [RFC 2460, section 4.4 para 2]. This allows a spurious data channel of arbitrary size and must not be allowed.

 The Type 3 through 255 Routing Header values in the routing type field are currently undefined and should also be dropped inbound and outbound. The Routing Header is identified by a Next Header value of 43 (0x2B). To drop all types including type 2 Mobile IPv6 (MIPv6) a filter can be defined to drop the Routing Header 43 (0x2B). If MIPv6 is required a permit will be required for Routing Header 43 (0x2B) Type 2, and then drop the remaining Routing Headers 43 (0x2B).

 NOTE: Change 'IPV6_INGRESS_ACL' to the access control list for IPv6 inbound connection filtering.

Solution

IPv6 traffic with a Routing Header Type 0, 1, 3-255 must be dropped by all external router interfaces.

See Also

https://iasecontent.disa.mil/stigs/zip/U_Network_Perimeter_Router_L3_Switch_V8R32_STIG.zip

Item Details

Category: SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|SC-7, CAT|II, Rule-ID|SV-15363r2_rule, STIG-ID|NET-IPV6-017, Vuln-ID|V-14685

Plugin: Cisco

Control ID: 4f17057297f486996e370be04a11a6d3941686d53d82dfa1350a90084abbbf6d