Re: [secdir] [GROW] Secdir last call review of draft-ietf-grow-bgp-session-culling-04

Job Snijders <> Mon, 25 September 2017 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3A501344EE for <>; Mon, 25 Sep 2017 09:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OYu1yXfIsvLN for <>; Mon, 25 Sep 2017 09:36:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DE8F1344ED for <>; Mon, 25 Sep 2017 09:36:15 -0700 (PDT)
Received: by with SMTP id m72so21531691wmc.1 for <>; Mon, 25 Sep 2017 09:36:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=U17jD/RsnOZBpsGw4aDf87Gr+BQHGSEysR6CNsmhG18=; b=dKPXROknMV25jpR5pdzTcC47HqQmd2mVGD633KPd9l6/0nIqA3w3G5m8qINhoBxh9T wylEBj6JoW2oblbg6/R+U/aYrZGL6MlvGjBI09djR+Bqx0o3qEaU27BVYYKjLCTcWUsK vLSeLOTIRFq3D7BYy64xVoxcF64MuzddCw4NKFw9+ggKEspDw7hCvqUPn/FGC2wbaXy5 TtPNl688nQk33UoXVeiOWmUjJ4corC3frEHvXfE913EBgZHWjEHPk713q65SDx7pShI+ d8byIbgzFxzSQlZuywv4xSeD42svHI80J4dLLMUvGbr8NhiAbPzVcHgr76tFa2ZYsLo3 Lp8g==
X-Gm-Message-State: AHPjjUgk9ah7QXTZODitoxz9i5J+t2/EkBdUq1bQL39bKAUQZJbNRBMt NhFEeornirXfXwPXyqet4fcTNw==
X-Google-Smtp-Source: AOwi7QC9ALXRO9tHnWsdGpdbYya7S2+mTnvBovvVSKF2VmvoLsR40fzhQ24YH1DpikQvprFfCb3LNQ==
X-Received: by with SMTP id r53mr15069670edd.174.1506357373461; Mon, 25 Sep 2017 09:36:13 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:1533:ae60:ce69:5c07]) by with ESMTPSA id 26sm4134513eds.5.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 09:36:12 -0700 (PDT)
Date: Mon, 25 Sep 2017 18:36:11 +0200
From: Job Snijders <>
To: Will Hargrave <>
Cc: Paul Wouters <>,,,,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170912 (1.9.0)
Archived-At: <>
Subject: Re: [secdir] [GROW] Secdir last call review of draft-ietf-grow-bgp-session-culling-04
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Sep 2017 16:36:25 -0000

On Mon, Sep 25, 2017 at 04:29:24PM +0000, Will Hargrave wrote:
> On 25 Sep 2017, at 16:45, Paul Wouters wrote:
> > This document basically states that people doing network maintenance
> > so often make mistakes that leak into the global BGP table, that it
> > would be a good idea to just firewall all the BGP traffic going out
> > of your network edge as a preventive measure. It's a sad state of
> > software/firmware that an external firewalling process is deemed
> > necessary to properly (re)configure BGP.
> Hi Paul,
> I am afraid you have got the wrong end of the stick here. This
> technique is intended for IXP and other L2 operators, not those who
> operate BGP speakers / IP networks.

Small nit pick: section 3.1 applies to those who operate BGP speakers /
IP networks. But yes, it appears that the review is based on a
misunderstanding about the layering of the ISO model and how the IP
filters trigger rerouting as (desired) second order effect.

> It is a workaround to unwanted blackholing of traffic as a result of
> the dataplane being broken whilst waiting for BGP holdtimers to expire
> - nothing to do with actual BGP route policy.
> I gave a presentation earlier this year at the UK Network Operators
> Forum which attempts to explain this

I'd also like to note that the techniques described in the culling
document have nothing to do with 'leaking' of any sort, nor is the BCP
attempting or purposed to describe firewalling best practises from a
general perspective.

Kind regards,