Subject: Re: [Gen-art] Gen-ART review of draft-ietf-opsawg-large-flow-load-balancing-11

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 5 Jun 2014 20:29:40 -0700

Martin,

Apologies for the delayed response.  Got busy with too many other things.

The only thing remaining is the security issue.  Would the following text
added to the security section address your concern?

It is possible for a sophisticated attacker with knowledge of the details
of large flow recognition algorithm (packet fields used and parameters of
the algorithm) and the network topology to launch an attack in which
sufficient traffic is generated so as to result in the flow being
recognized as a large flow resulting the the installation of a PBR rule.
 Subsequently, the attacker can generate traffic for other such flows
resulting in consuming entries in the PBR table until the older, inactive
flows are removed.

Thanks,
Anoop

On Wed, May 7, 2014 at 1:25 PM, Martin Thomson <[email-masked]>
wrote:

> Inline...
>
> On 6 May 2014 19:16, Anoop Ghanwani <[email-masked]> wrote:
> >> There's not a lot of discussion about the costs of maintaining an
> >> exception list for rebalanced flows.  A hash-based distribution is
> >> going to cost essentially zero state because the outbound path can be
> >> determined on a per-packet basis, but as soon as you start
> >> redistributing, there is an added state cost (and potential increase
> >> in lookup times).  That probably needs some discussion.
> >>
> >
> > We could probably add another subsection to Section 6 which discusses
> > operational considerations.  Would the following address this concern?
> >
> > 6.3 Forwarding Resources
> >
> > Hash-based techniques used for load balancing with LAG/ECMP
> > are usually stateless.  The mechanisms described in this document
> > require additional resources in the forwarding plane of routers for
> creating
> > PBR rules that are capable of overriding the forwarding decision from
> > the hash-based approach.  These resources may limit the number of
> > flows that can be rebalanced and may also impact the latency experienced
> > by packets due to the additional lookups that are required.
>
> Yep, that's perfect.
>
> >> This plays into the security considerations, which I think need to
> >> highlight this as a potential DoS vector.  Implementing automatic
> >> redistribution on top of a hash-based stateless distribution is
> >> vulnerable to attack if the hash function used is predictable.
> >>
> >
> > Can you say something more about this attack?  Is it that an attacker
> > would send large flows that map to the same link in order to consume
> > resources in the PBR table?
>
> That's exactly the concern.  Similar concerns arise in hash tables
> that are predictable.  If an attacker wants to mount a DoS attack, one
> vector they have open to them is to overload a single bucket, forcing
> lookup times to increase from O(1) to O(N).  There's some research on
> the matter, http://cr.yp.to/papers/surf.pdf for example.
>
> > Yes, we have had issues with this when converting from Word and
> > keep forgetting to adjust the .txt before submitting.
>
> It's probably too late for this, but you might find this useful in
> future: https://github.com/cabo/kramdown-rfc2629 (see it in action
> here: https://github.com/tlswg/tls13-spec)
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Jun 2014 07:47:28 -0700

On 5 June 2014 20:29, Anoop Ghanwani <[email-masked]> wrote:
> It is possible for a sophisticated attacker with knowledge of the details of
> large flow recognition algorithm (packet fields used and parameters of the
> algorithm) and the network topology to launch an attack in which sufficient
> traffic is generated so as to result in the flow being recognized as a large
> flow resulting the the installation of a PBR rule.  Subsequently, the
> attacker can generate traffic for other such flows resulting in consuming
> entries in the PBR table until the older, inactive flows are removed.

I had a little trouble parsing this, perhaps:

An attacker with knowledge of the large flow recognition algorithm and
any stateless distribution method can generate flows that are
distributed in a way that overloads a specific path.  This could be
used to cause the creation of PBR rules that exhaust the available
rule capacity on nodes.  If PBR rules are consequently discarded, this
could result in congestion on the attacker-selected path.
Alternatively, tracking large numbers of PBR rules could result in
performance degradation.

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 12 Jun 2014 12:11:26 -0700

Thanks Martin.

We should have an updated document shortly.

Anoop