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

[Anoop Ghanwani <[e-mail]>]

Yoav,

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

On Mon, Apr 28, 2014 at 6:47 AM, Yoav Nir <[e-mail]> 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