[secdir] SecDir review of draft-ietf-grow-blackholing

"Paul Hoffman" <paul.hoffman@vpnc.org> Mon, 27 June 2016 00:14 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0DA12D090 for <secdir@ietfa.amsl.com>; Sun, 26 Jun 2016 17:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 ljZ-aXY4lJlV for <secdir@ietfa.amsl.com>; Sun, 26 Jun 2016 17:14:43 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FB012B01C for <secdir@ietf.org>; Sun, 26 Jun 2016 17:14:43 -0700 (PDT)
Received: from [10.32.60.91] (142-254-17-215.dsl.dynamic.fusionbroadband.com [142.254.17.215]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u5R0EeaO057095 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <secdir@ietf.org>; Sun, 26 Jun 2016 17:14:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 142-254-17-215.dsl.dynamic.fusionbroadband.com [142.254.17.215] claimed to be [10.32.60.91]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: secdir <secdir@ietf.org>
Date: Sun, 26 Jun 2016 17:14:40 -0700
Message-ID: <E4ABD59D-0CFE-43BA-AD61-20F5C058BAFF@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/TMZrS0tiI-fsciWNmXmj9QtcCok>
Subject: [secdir] SecDir review of draft-ietf-grow-blackholing
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <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, 27 Jun 2016 00:14:44 -0000

This draft, "BLACKHOLE BGP Community for Blackholing", describes a new 
optional BGP community with the specific semantics of "please blackhole 
this traffic for me". The idea is to have a single common community 
instead of all the ad hoc communities that ISPs have created for this 
semantic.

The beginning of the security considerations section is daunting in that 
it says, in essence, "BGP has no authentication, so injecting dangerous 
messages is trivial; thus this new dangerous community is not a 
problem". It then goes on to say "and this new community can be used as 
a DoS by your downstream peers because they can tell you lies, but you 
were already susceptible to those lies". And then "and this can be used 
for CPU exhaustion against you if you're not careful" without saying how 
to be careful.

There are currently two active threads on ietf@ about security 
implications of this draft. There are questions about whether this draft 
lacks enough specificity to prevent CPU exhaustion attacks even from 
well-meaning peers, whether it should be standards track given that it 
is underspecified, whether it should suggest that IXPs should implement 
it, and other questions seem to be coming up.

I think that this document *might* be OK as an Informational RFC if 
there is more discussion about how to prevent a CPU exhaustion attack 
for recipients and more MUSTs instead of SHOULDs for what other 
communities need to be applied to these messages.

--Paul Hoffman