Subject: Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 17 Apr 2013 13:28:11 +0200

Hello,

Here are some additional comments on the above draft. Section 4 suggests 
the utilisation of a hash to perform the load balancing based on the 
source-address/flow label pair. Hash functions are often used in load 
balancing applications. I think that it could be useful to point the 
advantages and the drawbacks of using hash functions for load balancing 
purposes.

The main advantage of hash functions is that they usually exhibit the 
avalanche effect, i.e. a small change in the input causes a large change 
in the output of the function. Simulations show that this effect is 
important to correctly balance real traffic.

However, with hash functions, this advantage comes with a drawback. It 
is difficult to predict the set of inputs that would provide a specific 
output. Being able to predict which decision will be taken by a load 
balancer is important for monitoring applications for example. If a 
network operator wants to verify the round-trip-time between two hosts 
when there is a load balancer in between, he/she should take into 
account this load balancing when defining his/her probes. A similar 
situation happens when a network operator wants to use traceroute to 
detect block holes on a load-balanced path.

It should be noted that there exist functions that exhibit the avalanche 
effect without being one-way functions like the classical hash 
functions. If used in load-balancers, these functions would provide both 
  good load balancing and predictibility which is desired for many 
monitoring applications. A recent paper shows how such load-balancing 
can be performed efficiently by using block ciphers instead of hash 
functions. The solution proposed in this paper could be adapted to 
utilise the IPv6 flow label :

http://inl.info.ucl.ac.be/publications/revisiting-flow-based-load-balancing-stateless-path-selection-data-center-networks

Best regards,

Olivier Bonaventure

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Apr 2013 14:43:54 +0100

Hello Olivier,

On 17/04/2013 12:28, Olivier Bonaventure wrote:
> output. 

That is an advantage from the security point of view, since it
prevents an attacker from biasing the load balancing in order to
focus a DOS attack on a single server. I believe that's discussed
in the flow label spec.

> Being able to predict which decision will be taken by a load

True, but there's likely to be little sympathy from the load balancer's
operator, for the reason just given.

> http://inl.info.ucl.ac.be/publications/revisiting-flow-based-load-balancing-stateless-path-selection-data-center-networks

We'll have a look, thanks for the reference.

I believe, from the research I had to do personally when working on
this draft, that there is scope for an RFC giving a general overview
of load balancing. That would certainly have been a precious reference
for the current draft.

Regards
   Brian

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 17 Apr 2013 19:45:10 +0200

Brian,
> focus a DOS attack on a single server. I believe that's discussed

Well, partially. Since by design all packets with the same pair will 
always reach the same server, once you have found a victim server, you 
can send lots of packets to it. I agree that a DDoS from multiple 
sources could be a bit more difficult since the attacker would need to 
find the flow label for each source address to reach a given server.

> operator, for the reason just given.

The block cipher algorithm that is described below uses a key. This key 
can be fixed by the operator. If the key is secret, then only the 
operator can send packets over specific parts. For attackers, the 
load-balancing function is similar to a non-invertible hash. This should 
answer some of your security concerns (at least it's not worst than 
hash-based
load balancing)

> of load balancing. That would certainly have been a precious reference

Yes and the interactions between load balancing and networking protocols 
is worth being discussed as well.

Olivier