Re: [GROW] Last Call: <draft-ietf-grow-blackholing-00.txt> (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

Randy Bush <randy@psg.com> Mon, 04 July 2016 00:08 UTC

Return-Path: <randy@psg.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1F512B061; Sun, 3 Jul 2016 17:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 k0ukci8W-jpb; Sun, 3 Jul 2016 17:08:14 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9F412B024; Sun, 3 Jul 2016 17:08:14 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from <randy@psg.com>) id 1bJrQp-000422-3f; Mon, 04 Jul 2016 00:08:11 +0000
Date: Mon, 04 Jul 2016 09:08:07 +0900
Message-ID: <m2oa6eb6zc.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: heasley <heas@shrubbery.net>
Subject: Re: [GROW] Last Call: <draft-ietf-grow-blackholing-00.txt> (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
In-Reply-To: <20160703184947.GB98756@shrubbery.net>
References: <20160701111544.GL4253@22.rev.meerval.net> <57765693.4090407@foobar.org> <m2wpl5ee36.wl%randy@psg.com> <93821709-33a1-3320-e3f2-9ca8b67ecf23@bogus.com> <m2inwpdnk7.wl%randy@psg.com> <20160702103723.GN744@22.rev.meerval.net> <m2k2h4cob1.wl%randy@psg.com> <20160703184947.GB98756@shrubbery.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/yDTE2-Na0TCNq57hPVG-MfhJxrA>
Cc: GMO Crops <grow@ietf.org>, IETF Disgust List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jul 2016 00:08:15 -0000

>> no.  non-transitiveness through local naming, the reason this has not
>> allowed serious damage in current practice.
> 
> a receiving operator could limit scope, if they chose.  something like
> 
> route-map foo p 10
>  match community blackhole
>  match as-path ^([0-9]+_){1,2}$
>  set ip next-hop null0
> route-map foo d 20
>  match community blackhole
> route-map foo ...

yes, they *could* if they so chose.

the problem is that most won't.  as we know, unintentional (or more
correctly, thoughtless) leakage of all sorts of garbage is rampant
today.  weaponizing (you gotta love american verbing of nouns)
well-known communities that will assuredly be leaked; what could
possibly go wrong?

randy