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

From: Brian Weis <[email-masked]>
Date: Fri, 1 Jul 2011 16:56:33 -0700

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

---

From: Jari Arkko <[email-masked]>
Date: Sat, 02 Jul 2011 11:24:40 +0200

Thanks for your review, Brian. I do agree that the issue that you 
mention should be explained better. Authors, please suggest some text.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Jul 2011 00:13:07 +1200

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

> (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:
>> 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.)
>>

---

From: Brian Weis <[email-masked]>
Date: Tue, 5 Jul 2011 11:22:27 -0700

Hi Brian C,

> 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 

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Jul 2011 07:25:51 +1200

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

Yes, I agree and that really belongs in the 3697bis draft, whose Last Call is
running a bit behind this one. I will come up with some wording before the
I-D cutoff.

     Brian

---

From: Brian Weis <[email-masked]>
Date: Tue, 5 Jul 2011 12:44:34 -0700

> running a bit behind this one. I will come up with some wording before the

That's fine with me.

Thanks,
Brian Weis