use of the ipv6 flow label as a transport-layer nonce draft-blake-ipv6-flow-nonce-02 steven blake...
TRANSCRIPT
Use of the IPv6 Flow Label as a Transport-
Layer Nonce
draft-blake-ipv6-flow-nonce-02
Steven [email protected]
IETF 76November 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.
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.