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

Yoav Nir <ynir.ietf@gmail.com> Mon, 28 April 2014 13:47 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659821A09F9; Mon, 28 Apr 2014 06:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I18Mori3r218; Mon, 28 Apr 2014 06:47:55 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 771411A0795; Mon, 28 Apr 2014 06:47:55 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id x12so880493wgg.11 for <multiple recipients>; Mon, 28 Apr 2014 06:47:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=dUxyjYw1Z/RZNGea6uoZKSVPTcSLV1lvpjbMhREijQM=; b=GnLrF3KA8+y3bjrf8ckAN3y4XDUazr6mxNZ4tUJPpkeAiiNUsyOujCQsnxY1mv9Uwr J/oi9tkdi0+APJtpU1YrveIrV156kSR+nvmJu3Ki4BrX/T3/Ux7mCnCYTWpnVG1HcQGk eO3VF9Ki76AyntQlylIO4V7qIz0VBgyUZUrCooywq7NQX02+sV1CJ95ut/G6COj8VrP2 qxIW1SvKTPMBnNtlrq4n6h0cx1Aw1coMQXu0Gy/vckk5REJJQS/VsGHBOAs3x72UME2f 0uhUouajL4nq3uRcK64TWwYOhvvi88Uk+PKWnL06HYDm53mJPQJhMdFWIPCzhv8e9i6c AO+Q==
X-Received: by 10.180.228.42 with SMTP id sf10mr15688006wic.48.1398692874352; Mon, 28 Apr 2014 06:47:54 -0700 (PDT)
Received: from [172.24.248.99] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id h3sm17880253wiz.16.2014.04.28.06.47.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 06:47:53 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D637AC0-FD4F-4865-8D14-ADB75BAB072E@gmail.com>
Date: Mon, 28 Apr 2014 16:47:48 +0300
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>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MNAntvFB8zf9WqHP-Bk8k67IikQ
Subject: [secdir] Secdir review of draft-ietf-opsawg-large-flow-load-balancing-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Apr 2014 13:47:57 -0000

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