[secdir] Security review of draft-ietf-pals-congcons-01

"Hilarie Orman" <hilarie@purplestreak.com> Mon, 14 December 2015 20:23 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CE0BA1B2EA7; Mon, 14 Dec 2015 12:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.19
X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_FROM_12LTRDOM=0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id v9jKDT2NFy75; Mon, 14 Dec 2015 12:23:10 -0800 (PST)
Received: from out02.mta.xmission.com (out02.mta.xmission.com []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906951B2EA4; Mon, 14 Dec 2015 12:23:10 -0800 (PST)
Received: from in02.mta.xmission.com ([]) by out02.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1a8ZeF-0003sr-U1; Mon, 14 Dec 2015 13:23:07 -0700
Received: from [] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1a8ZeE-0005lN-GN; Mon, 14 Dec 2015 13:23:07 -0700
Received: from sylvester.rhmr.com (localhost []) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id tBEKMvUP007892; Mon, 14 Dec 2015 13:22:57 -0700
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id tBEKMuLp007891; Mon, 14 Dec 2015 13:22:56 -0700
Date: Mon, 14 Dec 2015 13:22:56 -0700
Message-Id: <201512142022.tBEKMuLp007891@sylvester.rhmr.com>
From: "Hilarie Orman" <hilarie@purplestreak.com>
To: secdir@ietf.org
X-XM-AID: U2FsdGVkX1/66kE78GgCXjAKaFg3uWbQ
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ******;secdir@ietf.org
X-Spam-Timing: total 1036 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 4.1 (0.4%), b_tie_ro: 3.0 (0.3%), parse: 0.99 (0.1%), extract_message_metadata: 5 (0.5%), get_uri_detail_list: 1.85 (0.2%), tests_pri_-1000: 4.6 (0.4%), tests_pri_-950: 2.1 (0.2%), tests_pri_-900: 1.72 (0.2%), tests_pri_-400: 55 (5.3%), check_bayes: 53 (5.1%), b_tokenize: 12 (1.2%), b_tok_get_all: 26 (2.5%), b_comp_prob: 3.5 (0.3%), b_tok_touch_all: 7 (0.7%), b_finish: 0.83 (0.1%), tests_pri_0: 933 (90.1%), check_dkim_signature: 0.75 (0.1%), check_dkim_adsp: 475 (45.8%), tests_pri_500: 25 (2.4%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/YjPr7frrsK0gsEAkaCKtzPxLLfc>
Cc: draft-ietf-pals-congcons@tools.ietf.org, iesg@ietf.org
Subject: [secdir] Security review of draft-ietf-pals-congcons-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
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: <https://mailarchive.ietf.org/arch/browse/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, 14 Dec 2015 20:23:12 -0000

Security review of
Pseudowire Congestion Considerations

Do not be alarmed.  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

The question that the draft addresses is whether or not TCP flows that
are bundled in a pseudowire (PW) need to have a special congestion
avoidance algorithm in order to co-exist with normal TCP flows.  The
answer seems to be a sort of analogy to the central limit theorem:
bundled TCP flows behave nearly as gracefully as a similar set of
non-bundled flows.

Whether or not I got that right, I do agree that this seems to
introduce no new security considerations.  I do wonder, though, about
whether or not an attacker needs to control more or fewer resources to
attack a network through a PW than without a PW.  I suspect that it
depends on the details of the network graph.  In any case, the
document in question does a good job of discussing the issue of
delays and capacity.

I think the formula for TCP throughput would be better expressed
by moving the common factor of 2p/3 outside the expression in
the denominator, but if all previous documents have used the
form given in this draft, it would only confuse people.