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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx mailing lists by 2016-07-04. Exceptionally, comments may be
> > sent to iesg@xxxxxxxx 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]