6. Security Considerations

The Flow Label field is in an unprotected part of the IPv6 header, which means that it can be modified by any node along the path without detection. This section discusses the security implications of using the Flow Label field and provides guidance on how to mitigate potential security risks.

General Security Properties

The Flow Label has the following security properties:

1. No Integrity Protection: The Flow Label is not covered by any checksum or authentication mechanism in the IPv6 header. Changes to the Flow Label value cannot be detected by examining the packet alone.

2. No Confidentiality: The Flow Label value is transmitted in cleartext and can be observed by any node along the path.

3. No Authentication: There is no mechanism to verify that the Flow Label was set by the claimed source.

These properties mean that the Flow Label should not be used for security-critical functions without additional protection mechanisms.

6.1. Covert Channel Risk

The Flow Label field could potentially be used as a covert channel for transmitting information. An attacker could encode data in the Flow Label values of packets, and a receiver could extract this data.

Mitigation

To mitigate the risk of covert channels:

• Network administrators MAY choose to clear the Flow Label field at security boundaries (e.g., at the edge of an administrative domain).

• Security devices (firewalls, intrusion detection systems) SHOULD be aware of the potential for covert channels in the Flow Label field.

• When clearing the Flow Label is necessary for security reasons, it SHOULD be done consistently for all packets to avoid creating a side channel based on which packets have their Flow Label cleared.

Operational Considerations

Clearing the Flow Label field may impact the performance of load distribution mechanisms that rely on the Flow Label. Network administrators should weigh the security benefits against the operational impact when deciding whether to clear the Flow Label.

6.2. Theft and Denial of Service

An attacker could potentially exploit the Flow Label field to cause denial of service or to "steal" resources allocated to a flow.

Flow Label Guessing

If an attacker can guess or observe the Flow Label value used by a legitimate flow, the attacker could:

1. Inject Packets: Send packets with the same Flow Label, Source Address, and Destination Address as a legitimate flow, causing these packets to be treated as part of that flow.

2. Resource Theft: In a stateful scenario where resources are allocated based on the Flow Label, an attacker could steal resources by using the same Flow Label as a legitimate flow.

Mitigation

To mitigate these risks:

• Unpredictability: Source nodes SHOULD use a pseudo-random function to generate Flow Label values, making it difficult for an attacker to guess the Flow Label of a legitimate flow. The function SHOULD include a secret component (e.g., a per-host secret key) to prevent attackers from predicting Flow Label values.

• Rate Limiting: Nodes that allocate resources based on Flow Labels SHOULD implement rate limiting to prevent resource exhaustion attacks.

• Authentication: For flows that require strong security guarantees, higher-layer authentication mechanisms (e.g., IPsec, TLS) SHOULD be used in addition to the Flow Label.

Denial of Service through Flow State Exhaustion

In stateful scenarios, an attacker could attempt to exhaust the flow state storage of a node by creating a large number of flows with different Flow Label values.

Mitigation

To mitigate flow state exhaustion attacks:

• Nodes that maintain flow state SHOULD implement limits on the number of flows and the amount of state per flow.

• Flow state SHOULD have a reasonable timeout to prevent stale state from accumulating.

• Nodes SHOULD implement mechanisms to detect and respond to flow state exhaustion attacks, such as prioritizing flows or dropping state for suspicious flows.

6.3. IPsec and Tunneling Interactions

The Flow Label field has specific interactions with IPsec and tunneling protocols that must be considered.

IPsec Transport Mode

In IPsec transport mode, the Flow Label is not protected by IPsec authentication or encryption. An attacker could modify the Flow Label without detection, even if the rest of the packet is protected by IPsec.

IPsec Tunnel Mode

In IPsec tunnel mode, the original IPv6 header (including the Flow Label) is encapsulated within a new IPv6 header. The Flow Label in the outer header may be different from the Flow Label in the inner header.

Recommendations:

• The outer header Flow Label SHOULD be set based on the inner header Flow Label and other fields, to preserve the flow identification properties across the tunnel.

• Tunnel endpoints SHOULD NOT simply copy the inner Flow Label to the outer Flow Label, as this could create security vulnerabilities or operational issues.

Other Tunneling Protocols

Similar considerations apply to other tunneling protocols (e.g., GRE, L2TP). The Flow Label in the outer header should be set in a way that preserves flow identification while not creating security vulnerabilities.

6.4. Security Filtering Interactions

Security devices such as firewalls and intrusion detection systems may need to inspect packets based on flow identification. The Flow Label can assist in this process, but security devices must be aware of the limitations.

Firewall Considerations

Firewalls that perform stateful packet filtering may use the Flow Label as part of their flow identification mechanism. However:

• Firewalls MUST NOT rely solely on the Flow Label for security decisions, as the Flow Label can be spoofed.

• Firewalls SHOULD use the Flow Label in combination with other header fields (source and destination addresses, port numbers, etc.) for flow identification.

• Firewalls MAY choose to clear or randomize the Flow Label for packets crossing security boundaries.

Intrusion Detection Systems

Intrusion detection systems (IDS) may use the Flow Label to track flows and detect anomalies. However:

• IDS systems MUST be aware that the Flow Label can be modified by attackers.

• IDS systems SHOULD use the Flow Label as one of many indicators, not as a definitive identifier.

• IDS systems SHOULD be capable of detecting anomalies in Flow Label usage, such as unexpected changes in Flow Label values within a flow.

Summary

The Flow Label field provides useful functionality for flow identification and load distribution, but it has limited security properties. Implementations should:

• Use unpredictable Flow Label values to prevent guessing attacks.
• Not rely solely on the Flow Label for security-critical decisions.
• Be aware of the potential for covert channels and take appropriate mitigation measures.
• Consider the interactions with IPsec and tunneling protocols.
• Use higher-layer security mechanisms (IPsec, TLS) when strong security guarantees are required.