Last Call Review of draft-ietf-6man-flow-ecmp-
review-ietf-6man-flow-ecmp-secdir-lc-weis-2011-07-09-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

Intermediate systems in a routing system perform load balancing of packets
between a pair of nodes based on values in the packet. This I-D defines a safe
method by which the IPv6 flow label can be one of those values. A necessary
condition is that flow labels that have a uniform distribution, and the method
is restricting to use by IPv6 tunnel endpoints that are more trusted to apply
this method to packets they encapsulate.

The Security Considerations section describes a single availability attack,
which is an attacker able to "selectively overload a particular path". I assume
that this can happen if the hash calculation of the intermediate systems will
send too many packets down one path and overload it rather than properly load
balancing across the paths. The values used by the intermediate system come
from packet headers, and the calculation is deterministic. If the flow label
computed by the tunnel endpoint is included in the calculation, and it is also
deterministic, then it seems that an attacker knowing the method used by the
tunnel endpoint to create flow labels can engage in this attack. That is, the
attacker crafting packets that will result in the tunnel end point computing
one or more flow labels that cause the intermediate system to include in its
hash calculation, which results in it routing over the same path. This may be
feasible for an informed attacker controlling a suitable size botnet. So making
the tunnel endpoint flow label calculation unpredictable would be important to
stop this attack.

The I-D recommends computing the flow label according to
[I-D.ietf-6man-flow-3697bis], and also states in Section 3 that the result
"will be hard for a malicious third party to predict". If so, then this attack
seems mitigated when the recommendation is taken. But it would be helpful if
the Security Considerations could also mention the need for unpredictability,
and perhaps also mention how the unpredictability is added. As far as I can
tell, the recommendation in [I-D.ietf-6man-flow-3697bis] is to build the flow
label from values in the packet being encapsulated, which the attacker itself
may have generated. If the attacker can provide all of the inputs, and it knows
the tunnel endpoint flow label calculation, then there doesn't seem to be any
unpredictability. (The I-D says to see [I-D.ietf-6man-flow-3697bis] for further
discussion of this threat. I can't seem to find it, but if it's there simply
pointing to that discussion would be fine too.)

Other than clarifying how that attack is mitigated I do not see the need for
any changes.

Brian