ietf
[Top] [All Lists]

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

2016-06-26 09:02:00
Dear Nick,

On Sun, Jun 26, 2016 at 02:38:33PM +0100, Nick Hilliard wrote:
The IESG wrote:
The IESG has received a request from the Global Routing Operations WG
(grow) to consider the following document:
- 'BLACKHOLE BGP Community for Blackholing'
  <draft-ietf-grow-blackholing-00.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2016-07-04. Exceptionally, 
comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

<snip>

I don't think this is an appropriate document for standards track, or
even for publication as an RFC.
The reason for this is that section 3.4 creates the expectation that
IXPs could or should be involved in facilitating blackholing of IP
addresses.

You are correct, IXPs _could_ be involved in facilitating blackholing of
traffic. This draft does not change today's reality.

Follow-up question: without section 3.4 - would you still object?

The problem is layer 9: if a mechanism of this form is standardised,
it will be viewed by governments, courts and law-enforcement a
centralised big red button which can be pressed at will to block IP
access to their bêtes-noires du jour.  And it turns out that there are
lots of things that governments, courts and LEAs don't like, ranging
from file sharing to witchcraft (one of the default blocking
categories in the UK) to youtube (lots of countries) to google
(france), to whatever. It's not just DDoS that will be targeted here.

This is a stifling argument. A blackhole mechanism is already today
standardized as RFC 5635. This draft merely exists to standardize a
codepoint. 

The proposal itself has raised an unusual level of disquiet among the
IXP community, which seems to be split down the middle about whether
standardising blackhole communities in an RFC is a good idea or not.
Some IXPs think it's great.  Others think it's a terrible idea.  For
sure, there is no consensus about this in the IXP world.

There is also the carrier community to consider. Currently a ton of
carriers have implemented their own codepoint to trigger blackholing, a
very incomplete overview follows of communities currently in use by
carriers for the purpose of blackholing: 2914:666, 209:0, 701:9999,
1239:66, 1273:666, 1299:999, 1759:666, 2828:1650, 3212:9999, 3257:2666,
65000:0, 3327:666, 3356:9999, 6762:666, 3561:666, 4323:187, 5580:666,
6461:5990, 7029:4506, 7922:666, 8100:6666, 8218:9999, 8220:63999,
8708:9999, 49544:666, 11537:911, 15756:666, 19401:911, 23265:666 and
286:66.

It is long overdue to standardize all these towards 65535:666 (BLACKHOLE).

Kind regards,

Job

<Prev in Thread] Current Thread [Next in Thread>