Use of the IPv6 Flow Label as a Transport-Layer Nonce

1. Use of the IPv6 Flow Label as a Transport-Layer Nonce draft-blake-ipv6-flow-nonce-02 Steven Blake sblake@extremenetworks.com 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 <IPSA, IPDA, Flow Label> (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. 2

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. 3

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). 4

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. 5

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). 6

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. 7

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. 8

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! 9

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

11. Backup‏ 11

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. 12

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). 13

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. 14