Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <0D637AC0-FD4F-4865-8D14-ADB75BAB072E@gmail.com>
Date: Thu, 16 Oct 2014 23:31:03 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1BF5DC9-43D6-4EEE-8D25-ECD374D50123@gmail.com>
References: <0D637AC0-FD4F-4865-8D14-ADB75BAB072E@gmail.com>
To: draft-ietf-opsawg-large-flow-load-balancing.all@tools.ietf.org,
 "<secdir@ietf.org>" <secdir@ietf.org>,
 "<iesg@ietf.org> IESG" <iesg@ietf.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nBrTxdi3zLRglz_YVrSNQiy8eYw
Subject: Re: [secdir] Secdir review of
 draft-ietf-opsawg-large-flow-load-balancing-11
Precedence: list

I=92ve been asked to re-review version 15 of this draft.  I thought that =
-11 was ready, and I still think that about -15.=20

My comments have been addressed with the exception that the definition =
of =93flow=94 is still in section 4.3.1, while flows and different types =
of flows are discussed throughout the document. It=92s 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@gmail.com> wrote:

> Hi
>=20
> 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.
>=20
> tl;dr version: the document is ready.
>=20
> I was a little surprised by the way the document is organized, and I=92m=
 not sure who the target audience is. On the one hand it is very verbose =
on explanations (that=92s 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:
>=20
> The introduction talks about large flows vs small flows, long-lived =
flows vs short-lived flows, and Large flows vs Small flows (no, I=92m =
not repeating myself, capitalize Large is different from lower-case =
large and in fact means both =93large=94 and =93long-lived=94).  But =
three things are totally missing: What is a flow? How large does a flow =
have to be to be considered =93large=94 (lower case), and how long must =
a flow continue to be considered =93long-lived=94. 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.
>=20
> 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.
>=20
> 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=92s 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.
>=20
> I don=92t think there=92s anything missing from the security =
considerations.
>=20
> Hope this helps
>=20
> Yoav
>=20
>=20
>=20