The router must be configured to reject the Routing Header extension types 0, 1, and 3

The router must be configured to reject the Routing Header extension types 0, 1, and 3 - 255 in an IPv6 enclave.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
SRG-NET-000205-RTR-000100	SRG-NET-000205-RTR-000100	SRG-NET-000205-RTR-000100_rule		Medium

Description
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 receive, rather than the real owner of the address, traffic in response. 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. IETF standards explicitly require nodes to reject 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).

Description

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 receive, rather than the real owner of the address, traffic in response. 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. IETF standards explicitly require nodes to reject 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).

STIG	Date
Router Security Requirements Guide	2013-07-30

Details

Check Text ( C-SRG-NET-000205-RTR-000100_chk )
Review the router configuration and verify that a filter for IPv6 traffic has been defined to deny packets that include a Routing Header of types 0, 1, and 3 - 255 on all external interfaces. If the external interfaces do not have a filter defined that denies packets that include a Routing Header of types 0, 1, and 3 - 255, this is a finding.

Fix Text (F-SRG-NET-000205-RTR-000100_fix)
Configure filters so that IPv6 traffic with Routing Header types 0, 1, 3-255 must be dropped by all external router interfaces.