Telechat Review of draft-ietf-opsawg-large-flow-load-balancing-15
review-ietf-opsawg-large-flow-load-balancing-15-secdir-telechat-nir-2014-10-23-00

I’ve been asked to re-review version 15 of this draft.  I thought that -11 was
ready, and I still think that about -15.

My comments have been addressed with the exception that the definition of
“flow” is still in section 4.3.1, while flows and different types of flows are
discussed throughout the document. It’s a strange ordering, but the document is
understandable as it is.

Hope this helps

Yoav

On Apr 28, 2014, at 4:47 PM, Yoav Nir <ynir.ietf at gmail.com> wrote:

> Hi
>
> 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”).  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. > > I don’t think there’s anything
missing from the security considerations. > > Hope this helps > > Yoav > > >