Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-large-flow-load-balancing-11

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 13 Jun 2014 17:50:59 -0700

Yoav,

Thanks for the review.  We have just posted an updated version.

On Mon, Apr 28, 2014 at 6:47 AM, Yoav Nir <[email-masked]> 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.
>
> tl;dr version: the document is ready.
>
> I was a little surprised by the way the document is organized, and I'm not
> sure who the target audience is. On the one hand it is very verbose on
> explanations (that's a good thing!) and I could very well understand it
> even though I lack any background on the matter.  On the other hand, the
> order in which things are explained seems strange:
>
> The introduction talks about large flows vs small flows, long-lived flows
> vs short-lived flows, and Large flows vs Small flows (no, I'm not repeating
> myself, capitalize Large is different from lower-case large and in fact
> means both "large" and "long-lived").

This is actually explained in the introduction.  We only use large flow (no
capitalization needed) to mean large, long-lived flow.  Everything else is
a small flow.

> But three things are totally missing: What is a flow? How large does a
> flow have to be to be considered "large" (lower case), and how long must a
> flow continue to be considered "long-lived". Even the terminology section
> (1.2) defines Large, Small and small again, but not what a flow is.  These
> concepts are finally explained in sections 4.1, 4.3.1, and 4.3.2.

> The document describes how load balancing can be achieved by moving large
> flows around between links and by removing loaded links from the hash
> table, so that Small (or actually un-classified) new flows will not go to
> overloaded links. This is an improvement over the assumed default that is
> statically assigning flows to links based on a hash.
>
> The document has a short security considerations section that says that it
> does not impact the security of the Internet infrastructure or
> applications. I tend to agree, because the parts of the network where these
> protocols tends to be mostly stateless, so moving flows from one component
> to another should not make a difference. It would be different if there
> were supposed to be firewalls on the nodes.
> The security considerations also says that load balancing might help in
> resisting DoS attacks, for example if an attacker can create traffic where
> the hash would collide with some Large flow. With load balancing either the
> attacker's flow or the Large flow is moved, eliminating the contention.
> Again, I tend to agree, although this will allow a more powerful attacker
> to overload all the links, not just the ones they can target with the hash
> function. Still, an attacker powerful enough to overload all the links is
> likely to be able to create traffic that collides with all links anyway.
>

We have added to the security section based on comments from the GEN-ART
review.

>
> I don't think there's anything missing from the security considerations.
>
> Hope this helps
>
> Yoav
>

Thanks,
Anoop

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 13 Jun 2014 17:57:18 -0700

On Thu, May 1, 2014 at 9:25 PM, Chris Inacio <[email-masked]> wrote:

>
>
> After reading Yoav's review, I was curious about this document.
>
> I would agree, roughly, with Yoav's comments on flow description.  The
> table at the beginning of the document (section 2) I feel would be much
> better served with its Y axis labeled as bandwidth, and not flow scale.
>

We have modified the figure to show this as "Bandwidth.

>
> From a technical point of view, the only issue I have with the document is
> that I feel that it misses how long lived flows are identified.  I
> understand the technical challenge that this presents: how should a middle
> box understand/guess the intention of the end points for the duration of a
> flow?  There are likely to be some heuristics that could be
> developed/included that would be likely to have some indication as to the
> lifetime.  For example, SSH keep alives with an otherwise minimal (smallest
> of small) flow, or VPN identification.  (Of course with VPN, the flow can
> quickly switch from small to large and back to small.)  Devices with
> enhanced flow inspection can obviously label the traffic via inspection.
>
> I have 2 possible security considerations:
>
> Assuming the multi paths might lead to equal but diverse Internet
> connections (anycast), does moving flows between paths provide an attacker
> who has already penetrated an enterprise, the possibility to further evade
> detection of border monitoring devices via flow flopping?  Possibly evading
> stateful inspection at the border?
>

This would be unlikely since the the packets still follow the same path
that other regular packets follow.  It is just pinned to a specific path
rather than being allow to use whatever the hash algorithm dictates.

>
> And less likely: From a security point of view, sophisticated attackers,
> persistent attackers, like to map their target environment (hosts and
> network) before attempting their actual attack (DoS, exfiltration,
> destruction, etc.).  Does the movement of flows across otherwise redundant
> links expose more network structure, especially with respect to traceroute
> for an attacker.
>

The traceroute itself probably wouldn't be a large flow so that by itself
shouldn't be affected by this scheme.

We have augmented the security section based on comments from the GEN-ART
review.

Anoop