Use of the IPv6 Flow Label as a Transport-Layer Nonce draft-blake-ipv6-flow-nonce-02 Steven Blake IETF 76 November 2009

2 IPv6 Flow Label IPv6 introduced the concept of an internetworking-layer flow. Flow Label: 20 bit field in IPv6 header Flow identity defined as (RFC 3697)‏ We want to utilize the Flow Label as a per-connection nonce, to increase the work factor for off-path spoofing attackers. Randomization of Flow Label, SRCPORT, and ISN increases entropy to > 51 bits.

3 Hidden Agenda Flow label originally conceived to enable router optimizations: Simplified packet classification (i.e., less need to go digging past extension headers). It would be nice to be able to use the Flow Label as part of the ECMP load balancing key, for instance. Hosts won't automatically set non-zero Flow Label values for packets without some end-to-end incentives. This proposal provides one such incentive. Goal is to define the requirements in such a way that it does not preclude other flow label applications to be used simultaneously.

4 RFC 3697 Flow Label Rules Source MUST keep Flow Label constant for the duration of a flow. Flow Label MUST remain unchanged end-to-end. Source SHOULD assign each transport connection or application datastream to a unique flow. Source SHOULD select an unused Flow Label if not explicitly selected by an application. Flow Labels MUST be unique at a source host at any instant in time. Source MUST NOT reuse the same Flow Label to the same destination for a quarantine period after flow termination (>= 120 seconds).

5 Flow Label Nonce Use Each host assigns each transport connection to a flow. Host selects an outgoing Flow Label per-connection. Host records the incoming Flow Label from the peer and checks it against every received packet in the connection. Host silently discards packets with invalid Flow Labels. Excessive Flow Label errors SHOULD be logged. Scheme is incrementally deployable: If a destination does not check Flow Label, nothing broken (but attack resistance not improved). If source does not support this scheme, Flow Label = 0. Destination check will not fail.

6 Additional Flow Label Rules Host MUST assign each transport connection to a new flow. Host MUST be able to select unused Flow Labels when the application does not request a specific value. Flow Label MUST be practically unguessable (e.g., selected by a RFC 4086-compliant RNG). Host MUST clean-up flow state when cleaning up transport state. Quarantine period must be no less than the duration where transport state may linger (e.g., TIME_WAIT state).

7 Changes from -01 Clarified that this mechanism is mostly useless as a security mechanism for multicast. Corrected language regarding UDP-Lite: scheme is equally applicable for UDP and UDP-Lite. Added NAT considerations section. Added proposal for sub-flow support.

8 NAT Considerations Since when did we have to start worrying about NATs in IPv6? For stateless NAT mechanisms such as NAT66, GSE, etc.: There is no N:1 address multiplexing (on the outbound path, at least). Therefore, Flow Label values SHOULD NOT be changed by the NAT device. For an IPv6 NAPT (yuck), there will be address multiplexing: The flows emerging from the NAPT have to obey the same Flow Label rules as a host. Therefore, some Flow Label values may have to be modified, to avoid collisions.

9 Sub-flow Support One-ended approach to TCP multi-path does not change the receiver, but wants to set different Flow Label values on sub- flows, and use the Flow Label as part of the ECMP load balancing key, to split the sub-flows across multiple network paths. This will break if the receiver implements this proposal. Propose loosening the receiver behavior, so that it only checks the lower 16 bits of INCOMING_FLOW_ID. This allows the source host to split the traffic in a TCP connection across up to 16 Flow Label values, without breaking the receiver verification test. Not sure if this is such a great idea!

10 Further Work Examine applicability to SCTP, DCCP, and RTP (over UDP or DCCP). Suggestions welcome. Finish Linux prototype.

11 Backup‏

12 TCP Operation (1)‏ Client TCP stack selects OUTGOING_FLOW_ID at connection creation. Compute at same time as SRCPORT and ISN. Save OUTGOING_FLOW_ID in connection TCB. Client sends SYN with its OUTGOING_FLOW_ID. Server records SYN packet's Flow Label as INCOMING_FLOW_ID in connection TCB (ignoring SYN cache/cookie case here). Server selects OUTGOING_FLOW_ID (same procedure as client). Value can (but does not have to) equal INCOMING_FLOW_ID. Server sends SYN-ACK with its OUTGOING_FLOW_ID. Client records SYN_ACK packet's Flow Label as INCOMING_FLOW_ID in connection TCB.

13 TCP Operation (2)‏ Both ends always send packets with their OUTGOING_FLOW_ID. Both ends always check received packet's INCOMING_FLOW_ID. If the INCOMING_FLOW_ID check fails, silently discard the packet. When the connection closes, Flow Label cannot be reused to the same destination for MAX(2 x MSL, 120 sec).

14 Applicability to UDP Also useful for UDP & UDP-Lite, since they only have source port randomization as an obfuscation technique. Ex/ use Flow Label as nonce in DNS queries to protect against DNS cache poisoning attacks. DNS server sends the reply with the same Flow Label as used in the query. Client verifies the received Flow Label. Issues: UDP/IP stack does not have the equivalent of a TCP connection TCB (except for connected sockets). Ergo, setting/checking of Flow Label needs to happen in the application (above the socket API). No standard sockets API for setting/retrieving Flow Label.