Re: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-03

[Brian Weis <[e-mail]>]

Hi Brian C,

On Jul 2, 2011, at 5:13 AM, Brian E Carpenter wrote:

>> 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. 
> 
> That's correct, and means that if you are concerned about this risk,
> there needs to be an obfuscation step in the hash algorithm.

Right, but obfuscation is kind of a loaded word. Adding an input to the hash algorithm that the attacker is unlikely to guess will mitigate the risk, and this is probably what you meant.

Brian Weis 

> 
>> (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.)
> 
> I think it would be better to include any additional wording in 3697bis
> - can we look at this when we get the security review of that draft?
> I think Brian W is correct that it needs to be added.
> 
> Regards
>   Brian Carpenter
> 
> On 2011-07-02 21:24, Jari Arkko wrote:
>> Thanks for your review, Brian. I do agree that the issue that you
>> mention should be explained better. Authors, please suggest some text.
>> 
>> Jari
>> 
>> Brian Weis kirjoitti:
>>> 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
>>> 
>> 
>> 
>> 


-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: [phone]
Email: [e-mail]