Re: [secdir] secdir review of draft-ietf-grow-filtering-threats-06

Pierre Francois <> Wed, 08 July 2015 15:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 538201A0023; Wed, 8 Jul 2015 08:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7psFJPxpIuKE; Wed, 8 Jul 2015 08:05:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB1701A001A; Wed, 8 Jul 2015 08:05:33 -0700 (PDT)
Received: from localhost (localhost []) by (imdea mail daemon) with ESMTP id 2955B1B922E; Wed, 8 Jul 2015 17:03:44 +0200 (CEST)
X-Virus-Scanned: by antispam-antivirus system at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZyWl-H44u7ZM; Wed, 8 Jul 2015 17:03:43 +0200 (CEST)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by (imdea mail daemon) with ESMTPSA id A45A01B922D; Wed, 8 Jul 2015 17:03:40 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_37852847-3CCF-4EC3-AC65-76D922BB1648"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Pierre Francois <>
In-Reply-To: <>
Date: Wed, 8 Jul 2015 17:05:26 +0200
Message-Id: <>
References: <>
To: Tom Yu <tlyu@MIT.EDU>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
X-Mailman-Approved-At: Wed, 08 Jul 2015 08:08:22 -0700
Subject: Re: [secdir] secdir review of draft-ietf-grow-filtering-threats-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jul 2015 15:05:49 -0000


Thanks a lot for your review. Comments inline.


> On 07 Jul 2015, at 21:10, Tom Yu <tlyu@MIT.EDU> 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.
> Summary: Ready with nits
> Consider adding text to the Introduction mentioning malicious activity
> as a possible cause of these unexpected traffic flows, rather than
> leaving it toward the end of the document in the Security
> Considerations.
> The Security Considerations (Section 6) text describes possible
> malicious activity by an AS to deliberately cause unexpected traffic
> flow through another AS.  Although the first paragraph of the Security
> Considerations says "The objective of this document is to inform on this
> potential routing security issue", there appears to be no prior mention
> in this document of possibility of maliciously induced unexpected
> traffic flow.  The current Introduction characterizes the unexpected
> traffic flows primarily as side effects of filtering or other
> configuration, but appears not to include the possibility of a malicious
> cause.

We agree. However, we got feedback in the past that the same technical situation can occur without malicious intent and so were asked to reword
the draft without implying malicious intent. We heard at the mic “I’ve done it and I am not evil”, “This is traffic engineering, not an attack”.

Still, we were recommended to put this explanation in the security consideration section because, well, it can also happen due to malicious intent
(gaining reach for cheap through another party's network).

I’m afraid that by changing this again, I’d be starting another revolution (in the mathematical sense) here… but what about:


OLD: The objective of this draft is to shed light on possible side effects associated with more specific prefix filtering. This document presents examples of such side effects and discusses approaches towards solutions to the problem.

NEW:  The objective of this draft is to shed light on possible side effects associated with such more specific prefix filtering.
Such actions can be explained by traffic engineering action, misconfiguration, or malicious intent.
This document presents examples of such side effects and discusses approaches towards solutions to the problem.

> Editorial:
> In the second paragraph of Section 1: "While BGP" should be "Although
> BGP", to avoid implying dependency or temporal coincidence.
> In the first two paragraphs of Section 3.1, "his" should be "its".
> Please avoid the unnecessary use of gendered pronouns.
> In the first paragraph of Section 3.2, delete "data" from "as much data
> information as possible".
> For the title of Section 4, consider dropping one instance of the word
> "traffic".
> In the last paragraph of Section 4.1, in the sentence "...neighboring
> AS... opposes the peering agreement", consider replacing "opposes" with
> "contravenes", "infringes", or another synonym.

Thank you !